Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

In an average game, there are hundreds or maybe thousands of objects in the scene. Is it completely correct to allocate memory for all objects, including gun shots (bullets), dynamically via default new()?

Should I create any memory pool for dynamic allocation, or is there no need to bother with this? What if the target platform are mobile devices?

Is there a need for a memory manager in a mobile game, please? Thank you.

Language Used: C++; Currently developed under Windows, but planned to be ported later.

share|improve this question
    
Hi Josh, thanks for corrections. –  Bunkai.Satori Feb 6 '11 at 19:54
    
Which language? –  Kylotan Feb 6 '11 at 22:07
    
@Kylotan: the language used: C++ currently developed under Windows but planned to be ported later. –  Bunkai.Satori Feb 6 '11 at 23:00
add comment

3 Answers 3

up vote 20 down vote accepted

In an average game, there are hundreds or maybe thousands of obects in the scene. Is it completely correct to allocate memory for all objects, includiding gun shots(bullets), dynamically via default new()?

That really depends what you mean by "correct." If you take the term quite literally (and ignore any concept of correctness of the implied design) then yes, it is perfectly acceptable. Your program will compile and run fine.

It may perform sub-optimally, but it still may also perform well enough to be a shippable, fun game.

Should I create any memory pool for dynamic allocation, or is there no need to bother with this? What if the target platform are mobile devices?

Profile and see. In C++, for example, dynamically allocation on the heap is usually a "slow" operation (in that it involves walking through the heap looking for a block of appropriate size). In C#, it's usually an extremely fast operation because it involves little more than an increment. Different language implementations have different performance characteristics with respect to memory allocation, fragmentation upon release, et cetera.

Implementing a memory pooling system can certainly bring about performance gains -- and since mobile systems are usually underpowered relative to desktop systems, you may see more of a gain on a particular mobile platform than you would on a desktop. But again, you'd have to profile and see -- if, currently, your game is slow but memory allocation/release doesn't show up on the profiler as a hot spot, implementing infrastructure to optimize memory allocation and access probably won't get you much bang for your buck.

Is there a need for a memory manager in a mobile game, please? Thank you.

Again, profile and see. Is your game running fine now? Then you may not need to worry.

All of that cautionary-speak aside, using dynamic allocation for everything isn't strictly speaking necessary and so it can be advantageous to avoid it -- both because of the potential performance gains, and because allocating memory that you need to track and eventually release means you have to track and eventually release it, possibly complicating your code.

In particular, in your original example you cited "bullets," which tend to be something that get created and destroyed frequently -- because many games involve lots of bullets, and bullets move fast and thus reach the end of their lifetime quickly (and often violently!). So implementing a pool allocator for them and objects like them (such as particles in a particle system) can usually result in efficiency gains and would likely be the first place to start looking at using pool allocation.

I am unclear if you are considering a memory pool implementation to be distinct from a "memory manager" -- a memory pool is a relatively well-defined concept, so I can say with some certainty that they can be a benefit if you implement them. A "memory manager" is a bit more vague in terms of its responsibility, so I would have to say that whether or not one is required depends on what you think that "memory manager" would do.

For example if you consider a memory manager to be a thing that just intercepts calls to new/delete/free/malloc/whatever and provides diagnostics on how much memory you allocate, what you leak, et cetera -- then that can be a useful tool for the game while it's in development to help you debug leaks and tune your optimal memory pool sizes, and so on.

share|improve this answer
    
Agreed. Code in a way that allows you to change things later. If in doubt, benchmark or profile. –  axel22 Feb 6 '11 at 19:59
    
@ Josh: +1 for excellent answer. What I would probably need to have is a combination of dynamic allocation, static allocation, and memory pools. However, the performance of the game will guide me in the proper mix of those three. This is clear candidate for the Accepted Answer for my question. However, I would like to keep the question open for a while, to see what others will contribute. –  Bunkai.Satori Feb 6 '11 at 20:03
    
+1. Excellent elaboration. The answer to almost every performance question is always "profile and see". Hardware is too complex these days to reason about performance from first principles. You need data. –  munificent Feb 6 '11 at 23:05
    
@Munificent: thanks for your comment. So the goal is making up the game working and stalbe. There is no need to worry too much about performance in the middle of the development. It all can and will be fixed after game completion. –  Bunkai.Satori Feb 6 '11 at 23:31
    
I think this is an unfair representation of C#'s allocation time- for example, every C# allocation also includes a sync block, the allocation of Object, etc. In addition, the heap in C++ requires modification only when allocating and freeing, whereas C# requires collections. –  DeadMG Feb 7 '11 at 0:48
add comment

I don't have much to add to Josh's excellent answer, but I'll comment on this:

Should I create any memory pool for dynamic allocation, or is there no need to bother with this?

There is a middle ground between memory pools and calling new on each allocation. For example, you can allocate a set number of objects in an array, then set a flag on them to 'destroy' them later. When you need to allocate more, you can overwrite the ones with the destroyed flag set. This kind of thing is only slightly more complex to use than new/delete (as you would have 2 new functions for that purpose) but is simple to write and can give you big gains.

share|improve this answer
    
+1 for nice addition. Yes, you are correct, that is a good way on managing simpler game elements such as: bullets, particles, effects. Especially for those, there would be no need to allocate memory dynamically. –  Bunkai.Satori Feb 6 '11 at 22:28
add comment

Is it completely correct to allocate memory for all objects, including gun shots (bullets), dynamically via default new()?

No, of course not. No memory allocation is correct for all objects. operator new() is for dynamic allocation, that is, it is appropriate only if you need the allocation to be dynamic, either because the object's lifetime is dynamic or because the type of the object is dynamic. If the type and lifetime of the object are known statically, you should allocate it statically.

Of course, the more information you have about your allocation patterns, the faster these allocations can be made via specialist allocators, such as object pools. But, these are optimizations and you should only make them if they're known to be necessary.

share|improve this answer
    
+1 for good answer. So to generalize, the correct approach would be: in the beginning of development, to plan, which objects can be allocated statically. During development, to allocate dynamically only those objects that absolutely have to be allocated dynamically. At the end, to profile, and adjust possible memory allocation performance issues. –  Bunkai.Satori Feb 7 '11 at 8:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.