TIGSource Forums

Hi guys,

Since Develop Brighton, I have been bull-charging development on the Legena Engine (a turn based RPG engine that I intend to release to public after the Legena trilogy). And boy it hasn't even reached a month and the Battle Engine is finalized, as well as the Weather system and the Text Engine.

As we all know, there is an obscene amount of text in today's games as well as data. As a result, I have to take RAM into consideration when developing this engine and the games as well. So what I'm doing is basing my RAM limitations on a Android Phone. I've done my research and the earliest Android OS the game will run is 2.1 so I took the first phone of that version (HTC Nexus One) and based my RAM usage on that. This is 512MB.

So I have my number. But to use all of that is ridiculous. So what I want to know is what you, as developers would use of that in terms of % of the RAM usage? It would be good to know how much RAM your games have used (if you know of course).

My gut feeling is to limit to 128MB. But I wanted to run it by you guys to ensure I have my thoughts right.

If I remember correctly, trying to allocate more than around 200mo on any mobile phone will certainly make the OS kill your program. So, indeed, targetting 128mo seems reasonable.

That being said, if you target PC, I think that 1go is OK, as most PC now have at least 3go, even in 32bit mode, and the OS will take a bit less than 2.
However if you can manage to keep your memory under 512 you'll certainly get better performance because of less chances to have memory cached on disk.

i think anything up to 1gb is fine on PC's, yeah. if you get more than 1gb then your computer may have problems on old computers and netbooks, so unless it's a game with very high-end graphics that people would expect to not work on their 5 year old netbook try to keep the ram below 1gb of use

Actually come to think, I never asked this. What would use RAM in a game? Obviously Graphics, Objects, Variables and Audios would take up RAM. Anything else that would?

variables use almost no ram. even huge arrays that are 32000 elements big only use like 64000 bytes or so, which is basically nothing. objects also use up almost no ram

but most ram is used by audio and graphics that are loaded into memory, yeah

I think a game with high end graphics would not necessarily stress the RAM, or maybe if the graphics are constantly evolving like in Skyrim for example. However if it contains tons of text and want it all available at all time (which frankly I think isn't that necessary...) or if there is huge amount of data to process each frame (think Supreme Commander kind of unit count) then yeah it's easy to begin targeting 1go or more.

I think my game (which is more or less an RTS) will, in some edge cases, require quite a big amount of data so I'm making it scale well and hopefully it will also be provided with 64bit version for people wanting to do very big battles, allowing several giga of data to be processed without a problem (if the hardware follows).

But frankly it's a edge case for a niche audience in an extreme scenario, so yeah less than 1Go is really more than OK.

Damn I now remember working on NDS, less than 4Mo to make a tycoon-like game, that was a challenge but in the end if the OS isn't in the way and you know how to setup memory correclty it's not even hard to do.

By the way if you use a managed language, don't forget to count the vm memory too.

Do you mean that you always keep graphics in RAM? Most cases I've worked on, most graphics are loaded in the GPU and vanish from RAM. Maybe it depends on the kind of game.

text doesn't use up that much ram, i'm not sure what you are talking about with text. even 1000 pages of text takes up about 2mb of ram, which is basically nothing. there's also no reason to keep text loaded all at once, almost no game does that, since it's rarely used it's easy to just load the particular dialogue file you need at the time

I was thinking more about text which contain more data but even like that you're right it's not text itself that is costly in memory. Or you have shitload of it, but it's unlikely for indie games.


Indeed.

My game has recently hit around 90MB of usage, and that frankly freaks me out, it seems way too high to me.

What kind of game is it?

Turn based tactics.

Is it a big game? Does it have alot of graphics?

I must just be too old school or something, but needing 1 gig of ram seems incredible. Anyway, to touch on the point about mobile, an iPad 1 has 256 MB of RAM, which seems outwardly fine, but that is shared VRAM/RAM. So whereas graphic memory effectively uses no RAM on most PCs (except for the brief period to decompress before uploading) it becomes a hindrance quickly on mobile. Also, you can't use all 256 MB - not even close. In my tests, low memory warnings would throw anywhere between 80-100 MB of usage, and going into the 100+ MB would crash now and then (depending on the state of the device prior to launching the app.)

As a point of reference (on PC) DD currently uses around the following amounts of RAM at any given time:
Databases: 2 MB
Other Misc Data: 300 KB
Sounds: 32 MB
Audio Buffers: 8 MB
Program Data: ~20 MB
Static memory: haven't profiled

We use a lot of VRAM: ~ 128 MB in SD mode and closer to 512 MB in HD mode. Because of the VRAM usage the only way I can get the game to run on an iPad 1 is with 16 bit textures....so iPad 1 is probably out for us.

the main reason my game uses a lot of ram is because game maker is really bad at ram management. it actually stores *two* copies of every image/texture in ram, not one. it's somewhat ridiculous

Isn't this one of those things that you can't control and the OS decides what to do with it based on what priority level you assign to it?

As we were saying it's a extreme case for PC.

Nope, it depends on what language you use and how you use to allocate resources. From the OS point of view it's all memory, there is no difference except memory that is said to be read-only from the begin to the end of the app, but even that it's just all memory, no special priority or whatever.

However if you load images, either they are loaded in RAM and stay there, either you put them in the graphic card memory (if the language or engine or tool you use allow you to do this) and can release the RAM used by the image. Anyway, you are in control of where things goes OR the engine on which you base your game is in control OR the vm - and if you have no vm and control the whole code, you do whatever you want.
But even if you do whatever you want, you are still constrained by the context of your game: if it's a game with always the same graphics, there is no point in unloading them at any point. If it's a long game and you need for example room graphcis when you are in a room and other graphics when you are in the street, which mean if either you have it all in the RAM or you load data as they are necessary. Worse case is Skyrim/MMos where you need to load and unload thing constantly, streaming data as much as possible.

Basically, you are in control of what happen in memory -if your tools allow it. But your game tells you a lot about what you might do and what you should do if you want to limit memory usage.

The "supreme commander" style of game I was talking about imply thousands of units, dynamic decorations and bullets all with physics that have to be simulated in real time. Just the simulation requires at least double buffering of the state of the game, then if you have several thousands units playing with all physics data it begins to be a lot of units with AI data etc.
This is an extreme case where most devs would use techniques to manage memory tightly.

But this kind of edge case really is rare around here. Assuming you're doing a game with native code, most of the time it will not go over 100mo. If you're using a managed language, on PC ere will be something like a handred mo allocated even before you start running the game. On android it's part of the OS so you don't have to count it as memory used. Not on PC. If you use an engine, well it depends on how the engine works.

Something to consider is the performance impact of memory use when you're using a garbage collector. Unfortunately I can't find the original article about it (Chrome has a surprisingly weak history search), but there's an important relationship between the fraction of available memory your program uses and the performance of garbage collection compared to 'manually' handled memory.

It varies with usage patterns, but basically if your program is actively using more than ~60% of available memory the garbage collector will become an increasingly significant drain on performance. In simple terms if you don't have much free overhead, the garbage collector has to clean up more aggressively so that you don't run out of available memory. The effect can be very significant, with garbage collected programs being faster(!) than manual allocation if they're operating in an environment with plenty of free memory, but an order of magnitude slower if it's rubbing against the memory limit. And of course that memory overhead is going to be part of the memory allocated to your program, not just random free memory on the device. So it might be wise to allocate yourself as much memory as you can get away with, if you don't mind your program being a resource hogging bully.

Is Game Maker hardware accelerated? If it is (and I would hope it is) and the storage case is the uploaded texture in VRAM and a copy in RAM, I can at least see a few reasons why they might do that (allow for image manipulation which would be on the CPU without shaders, reloading from memory versus disk on device restoration, etc) but it's still pretty lame that you can't control that. If the above is not the case, I can't think of any sane reason to do that. It sort of boggles my mind.


Needing that much memory still seems pretty crazy to me - I'd think at that point the actual processing of all that data is a huge problem. But I've basically no experience with making an RTS proper, let alone a modern one geared towards hard core PC players. The example of streaming massive worlds is definitely a valid one and I can see that being a huge memory hog. It shall be interesting to see what big console dev teams are able to do moving from 512 MB to 8 GB, in some ways catching up to modern PC specs.

If I understand you correctly you intend to let other people use your engine to make their own game? In that case hard coding the amount of RAM your engine allow to use is not something I would give other people to develop their games with.
Each game has it's own requirements of memory and so you need to give the game developer the tools to allocate and free assets dynamically and let him manage how much memory he wants to use.

To be honest, when you say something like RPG games can have a lot of text thinking this will somehow strain the memory I don't really think you are capable of creating an engine anyone will want to use besides yourself(at this point).
But you can do whatever you want...

I think there was a bit of confusion. It's my own fault, I should have explained. The RAM limitations are for my games. I was just giving the background on the game.

i believe it is, since GM6, which came out around 2005. however, GM doesn't use shaders (at least not until the latest version of game maker studio last month, and it's still beta, and the storing two copies of all the graphics in memory was the case for years before that). i don't think it does any image manipulation, aside from changing drawing tint and rotation / scaling -- would stuff like that require two copies of images held in memory? my guess was just that it's bad programming

Most definitely not. I'd be really interested in hearing the rationale for that decision, or perhaps you are right and it wasn't a "decision" at all, which is just, yeah, yuck.

For a long time Direct3D9 was the default. Or even worse: D3D8. Both lose all video ram resources at special system events, for example when the user alt+tabs out of a fullscreen application. Therefore most applications of that era kept a second copy of the resources in main memory.

ah, that makes sense. vanilla game maker uses directx8 still, i believe studio uses directx9.

Not at all, the simplest way is the most efficient: everything in large arrays, keep the last cycle data with read-only access to update next cycle, avoid branches as much as possible and you're good. It's actually fast and simple if you can keep the memory in RAM.


That being said, I see no reason why a indie dev wanting to make RTS (like me) could not, if the design requires it, fall in this case of massive scale of units. The real challenge is on the game design side really as you need to figure ways for the player to not have to micromanage his/her "swarm" army. It's feasible but you need to have good gameplay reasons to do this, which is why it's not that common.


Both PS3 and XBox360 forces constantly streaming resources actually, it's not new or uncommon at all in big console games, whatever the type. However for example the Xbox360 having unified memory means that you decide how much memory will be graphic memory and what will be RAM.