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)|
|GFX*1||Specific||256/249 (+32 *2)/286/32|
*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)|
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.
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.
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.