Technical Director at Jury Rig Software Ltd. We produce a replacement memory allocator called Elephant Memory Manager. Elephant Memory Manager is a high performance allocator with many advanced memory debugging features.
Posts by Darren-Vine
  1. Interview Techniques ( Counting comments... )
  2. Allocation standards ( Counting comments... )
  3. One size fits all ( Counting comments... )
  4. Planning Memory Budgets (Part 2) ( Counting comments... )
  5. Using standard DLLs from C# ( Counting comments... )
  6. Planning Memory Budgets (Part 1) ( Counting comments... )
  7. Debugging builds from 6000 miles away ( Counting comments... )
  8. Is it time to ditch your allocator? (Part 2) ( Counting comments... )
  9. Is it time to ditch your allocator? (Part 1) ( Counting comments... )
Technology/ Code /

In the last part of this article I covered working out the basics of the memory you have available. I mentioned that the next stage is to break this into modules to help create an effective game budget.

Divide between generic and specific budgets

I divide the memory up into a number of modules.  Each of these modules is either platform agnostic or specific for each platform.  What do I mean by this?  Well some modules (Sound, GFX) will differ in size on different platforms.  For example the Sound module may be forced to use PCM data on one platform and MP3 on another.  Others are platform agnostic.

Typically only one or two modules truly fall into the last category.  I always have one called Game.  The Game module is the core part of your game that is the same on all platforms.  By this I mean the data and code is identical and is the area most of the team work on.  Surprisingly, this is not normally that big either because it doesn't contain the major memory hogs. A simplistic example is to take an iOS game. The HD version has higher quality GFX or better quality sound than the SD version.  The same goes for games on the Wii and XBox 360.  The actual assets differ but the game is the same.  Note: By same I am generally referring to a game developed in-house by the same team.  Often, if different platforms are developed by different companies this is not the case.

Other modules have the same size on multiple platforms where they share data, while one platform may use different assets to suit the size.  Animation on the PS3, PC and 360 are often the same and only differ on the Wii for example.  Mainly due to a reduced number of bones and key frames.

This is the list I created, along with some guesstimates.  This is based on experience and what I think is likely for the game about to enter development.  In this table I have added a Wii platform to demonstrate the differences a bit clearer.

Module Name Type ~MB (PC/PS3/XBox360/Wii)
Game Generic 8/8/8/8
Animation Specific 24/24/24/16
Physics Specific 64/64/64/32
Sound Specific 32/22/22/8
GFX*1 Specific 256/249 (+32 *2)/286/32
Network Specific 8/8/8/8
Totals 392/407/412/104

*1 GFX comes from the VRAM budget defined in the previous article.  For the platforms that have unified memory this is just taken from the general pool.

*2 I have used all the available VRAM for the PS3 but I also need extra for GPU buffers in main ram.

The astute among you will also have noticed that the Wii memory is way over budget.

Talk to your team members

At this point the list needs expanding.  I have the modules but don't know beyond reasonable guessing how big they really need to be.  Though I have a rough idea from the Game Design Document, I am not an expert on all areas. Speaking with the people responsible for these areas can help you break the down and build accurate results.  This means talking to the artists as well about what they would like to be able to have and how that ties in with the engines abilities.

After this I have a much better break down of the areas some of these may be split into.  I can also put some numbers together based on what I was told and technical aspects of the platform.

Module Name Sub Module ~MB (PC/PS3/XBox360/Wii)
Game General 8/8/8/8
Animation Char Animation 14/14/14/6
Level Animation 10/10/10/4
Physics General Use 16/16/16/4
Collision Mesh 22/22/22/5
Sound FX 24/18/18/6
Music 8/4/4/1
GFX System Required 0/32/32/0
Frame Buffers 32/22/22/6
Textures 192/203/206/30
Meshes 32/24/26/8
 Network General 4/4/4/4
 Total 362/377/382/82

It is possible to break this list down further but there isn't a lot of point doing that in my opinion.  Sometimes I do, but this is often just for my records to see how things progress.  Frame buffers are an example that is often good to know.  Either way, I try break the list into things that will be major issues.  The further you go more likely you are to get it wrong.  That just leads to issues later.  Also it doesn't have to exact.  It just has to be good enough so that you don't get into trouble and you foresee any problem areas early.

My Budgets

After talking to the artists, designers and programmers I have a pretty good list.  It fits on all platforms and leaves a decent amount of leeway.  With the list above I have a considerable amount of ram remaining on the larger consoles.  Sometimes you do and sometimes you don't, it can depend on a huge number of factors.  I have also just squeezed it in on the Wii.  I will repeat the steps a couple more times to refine it and ensure I havent missed anything.  After that I review the memory consumption throughout development every month or so.  You don't need to spend long on this, only enough time to ensure things are on track.

Obviously my budgets listed here have, to a large degree, been plucked out of thin air, though I based it on previous games I have worked on.

Summary

Hopefully this will give you some idea of how to approach creating sensible memory budgets.  It doesn't matter which platform you are working on or even how many.  At some point you may wish to expand to others and sticking to your budgets now will help with that.  With the number of people now targeting mobile platforms there is more hardware variations than ever before.  The more you can reach, the more money you can make.