4
\$\begingroup\$

I studied computer engineering before but have been lagging in the technical aspects as of late.

Seeing as I think it would be to my advantage as a designer to understand how resources are used and calculated. I would like to ask if people here know of methods to compute to a certain degree how much power/resource a design would entail? (i.e. how many polygons per scene, how many AI running, how many physics components, particles etc.)?

\$\endgroup\$
1
  • \$\begingroup\$ Ask yourself: What kind of resources do you need to make this game awesome? Then shoot for that, and rub hard against your limits. Otherwise your game will never become what you want it to become. \$\endgroup\$
    – Ipsquiggle
    Sep 1, 2010 at 21:39

5 Answers 5

4
\$\begingroup\$

This is a pretty wide open question. Can you be more specific?

In my experience, and I'm probably doing it wrong, there is a lot of dead reckoning and adjustment with performance. AI too expensive? run it less often. UI? optimize and hack. etc. So the things that are hard to do this with you have to get right early.

Graphics budgets tend to be the most important things to get right because they're the most expensive to revisit. Environments are harder than characters.

If you want to see what other games are doing, I believe PIX will tell you what is going on (there's a windows version). Your have different limitations across different generations of cards as well.

If you're PC, just make sure you get a min-spec machine, and keep it working on that.

Also, and maybe in line with what you're asking, I know the God of War guys give each designer a flexible budget for things like RAM, processing, etc. so they can choose what to emphasize for their levels. These are techniques and not solid numbers, but may be useful to you.

\$\endgroup\$
4
  • 1
    \$\begingroup\$ Yeah I'm looking for approaches that would help me ascertain resources prior to prototyping. This way I can easily go into creating levels/scenes while the programmers prototype the project. \$\endgroup\$
    – Wight
    Sep 1, 2010 at 6:24
  • 1
    \$\begingroup\$ @Wight Usually prototyping finds (or finds ways around) limits, and not the other way around. \$\endgroup\$
    – Ipsquiggle
    Sep 1, 2010 at 21:38
  • \$\begingroup\$ If you didn't get the drift I know about prototyping and it's uses. I want to speed things up cause I think there is room for improvement. \$\endgroup\$
    – Wight
    Sep 2, 2010 at 5:31
  • \$\begingroup\$ The best approach to resource management in game design isn't to do it before you even write your prototypes... it's a flawed question. \$\endgroup\$
    – Rushyo
    Sep 2, 2010 at 13:23
2
\$\begingroup\$

In my experience, there's two major ways of doing it.

1) Dead reckoning. Got someone on-staff who's written that kind of game before? Got someone who has really good instincts? Maybe they can tell you. If you're real lucky, their response will bear at least vague similarity to reality.

2) Prototype it and find out. The only reliable way.

There's a third, if you're using a well-established engine in a way that many other people have used that same engine, and not planning on doing anything fancy or out-of-the-ordinary:

3) See what they did, then do the same thing.

but that only really works if you're, say, making a first-person shooter with Unreal Engine 3.

\$\endgroup\$
2
\$\begingroup\$

As this question seems to be coming from a designer, my response would be: design isn't about numbers, it's about ideas.

Don't concentrate on the nitty gritty reality of how many polys you can render per frame. Once you have a design that must be made into a game, you will be able to work with a programmer to write up what gets resources and what gets stripped.

Real games have limited budgets, and programmers work with designers to provide information about what each feature costs. Poly counts and AI time are features that can be optimized so you can stretch a little, and normally, a programmer can provide an alternative solution that provides the effect the design requires without actually implementing the specified feature that a designer may have assumed was necessary.

As a designer, your role is to make the best usability model of the game problem. You must iterate through different control layouts or strategies, and try to mentally play through the game numerous times, trying out different progressions. Some designers I've worked with even wrote out paper versions of games they were developing just to see the flow better.

In Conclusion, don't sweat what isn't your domain, but be prepared to prioritize your features.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ I've mentioned this in another question - the view that optimization is orthogonal to game design is only true for certain types of games. Dead Rising's core mechanic requires a certain amount of graphical and AI power. WoW's core mechanic requires a certain minimum database concurrency. Sometimes, the very ability to scale way way up is what makes the game fun, so knowing your budgets when prototyping is more important. \$\endgroup\$
    – user744
    Sep 1, 2010 at 11:14
  • \$\begingroup\$ @Joe Right, but: In the Dead Rising case, the visionary on the project said, "We need 120 zombies onscreen at all times!" And then it became a technical requirement to meet. I highly doubt it would have become the same game if the designer had said, "How many zombies can I get?" and a programmer replied, "Oh, I don't know.. 10? 20?" \$\endgroup\$
    – Ipsquiggle
    Sep 1, 2010 at 21:35
  • \$\begingroup\$ I'm not sure what way either of the comments are aiming here, but in the case of Dead Rising, the designer just needs to prioritize the 120 zombies on screen in their feature list. Assuming your budgets are immovable can detract from a potentially great idea, and programmers can't tell you exactly how many polys you can have until they know about most of the other uses of the machine's resources. It's always a trade-off, and usually one that a non-programmer can't reason about with any accuracy. \$\endgroup\$ Sep 2, 2010 at 9:47
  • 1
    \$\begingroup\$ @Ipsquiggle: If the designer says "We need 120 zombies onscreen at all times!" that designer is thinking about numbers. Richard's claim that "design isn't about numbers, it's about ideas" is sometimes true, but sometimes not. Such a game would've been flat-out impossible on the Atari 2600, NES, SNES, etc. Realities of budgets close off certain game designs a priori. Designers need to be aware of this. \$\endgroup\$
    – user744
    Sep 2, 2010 at 10:28
  • \$\begingroup\$ "Realities of budgets close off certain game designs a priori" but the only way to really know is to thrash it out with a programmer. katamari damacy might seem impossible to do at first glance, but a mindset of levels of detail provided the technical trickery to afford a solution to the apparently insoluble. \$\endgroup\$ Sep 2, 2010 at 11:14
2
\$\begingroup\$

As a designer what you need to focus on is the priority of your features, and the minimum bar needed to pull each of them off. As you start prototyping and learning the various costs of certain mechanics, you'll use those priorities to figure out what gets cut back and what is axed completely.

You aren't expected to know exactly how many resources will be allocated to each aspect of the game before you get started, although you should have a rough idea. But a team does expect you to be able to react intelligently to learning that some feature costs twice what was expected and that means it either needs to go away, be redesigned in a simpler fashion, or something else gets cut to make room.

In time with experience you can better anticipate where stumbling blocks will occur. The more you work with an engine or hardware you get a feel for it's limitations and the relative cost of different features.

\$\endgroup\$
1
  • \$\begingroup\$ Actually I already do those things now but do feel theres a better way of doing it rather than gut feel butI guess it has served me well enough in the past. \$\endgroup\$
    – Wight
    Sep 2, 2010 at 1:34
1
\$\begingroup\$

Rather than guessing blind, one thing you can do is implement budgeting tools early in development. Get a test machine, get out your budgeting tool, and start seeing where performance falls over. Make the budgeting tool yell at programmers/artists/designers if they go over the limits.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .