I'm currently working on a mid-size group of students developing a classic dungeon crawler game using own engine. I have the task to create a document where it tells:

  • What polycount and texture size limits artists should have
  • How much time each module of the engine should take

I know that this data is not to be exact by any meanings, because priorities would change depending of the needs of the game. I could try to drop some art in a scene, and seeing how much the framerate is impacted. I can take the 16 miliseconds of a 60fps game and distribute them among all modules, trusting my gut.

The problem is that I do not feel as this method is the correct, and I do not found any references of how I could distribute miliseconds (even for a blurry guide to follow), or how I could do some estimation of what limits the art (and the design) should have, based on our tech.

How can I make these estimates?


1 Answer 1


First you have to decide on your targets. For timings, this is usually easy as it's basically a factor of your desired stable frame rate: do you want a stable 30 FPS or a stable 60 FPS? For content it's a little more difficult, as the aesthetic goals of your title also factor into the decision, and the values for polygon count and texture size and so on also factor into your frame time.

But once you've decided on performance and quality bars you want to hit, you can move on to setting the actual details of the metrics. Generally you will do this through experiments. A common technique, for example, is to prototype out a scene that represents the most visually-dense, expensive part of your game.

Does this scene hit your performance targets? If so, great, you can derive your initial asset constraints from the assets used in the prototype. If not, you will have to start profiling the scene to determine what's making you miss your targets, and adjust accordingly.

For timing budgets, you can certainly start by giving every module an equal share of the frame time, although in practice they won't all need it and some will need significantly more (rendering, pathfinding, AI, usually). Profiling your prototypes is a good way to settle on some rough initial ideas for budget.

No matter what you pick, you may want to bias your initial estimates towards the pessimistic side of things to account for the fact that features and content tend to bloat as development goes on.

You will likely need to revise all of these numbers as the project goes on. Optimizations will shave off time in some system that can then be reallocated to the budget of another, or new content production techniques will lead to cheaper models than you had originally assumed, allowing you to spend a few more megabytes on high-impact textures.

The most important thing is to realize it is impractical to decide on all these metrics and guidelines once at the start and stick to them throughout: you will simply not have enough information about the details of your project (and these numbers are heavily influenced by the details of the project, which is why you don't find a lot of specific guidance about selecting them), and things always change during development.

So do what you can to make reasonable, evidence-based guesses at the start and use them to guide you gently, not rigidly, through the project as it grows.


You must log in to answer this question.

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