Before I start making a game, I'm trying to figure out how I will manage things. One of the first things I'm not sure about is how to manage entities (enemy, player, projectile...)

I'm going to be using either C, C++, Java, or C#

One of the ideas I have is to use one array for projectiles and one for enemies. Each time I have a new entity, I grow my array. Here is the problem: If player/enemy is firing, that creates a new entity which means the projectile array is growing.

Suppose its projectile #2053, when it hit something, I free it, then in my loop to check which projectiles are to do something, like getting closer to there target, I check if every # of my array to see if its null, if not, check is trajectory. But the problem is that the array will grow each time a new projectile is fired, and I will get a memory problem at the end.

So how should I manage my entities?

I need an awnser that covers both object oriented and procedural, since I mainly do things in C.


1 Answer 1


In general, you want to avoid freeing objects in your game. Generally, games are designed in such a way that when you load a level, the maximum number of objects are created while loading and only destroyed when exiting the level (sometimes, even that is not done so that the next level, which uses the same player/enemy classes loads even faster without an increase in the amount of memory used). Most games have pre-determined limits which the programmers can then work with (e.g. decal limits, maximum enemies, maximum bullet shells, maximum particle count) and sometimes this can be adjusted by the player.

Of course, this done not work for bigger games, such as Mass Effect, in which case complex memory pools are setup specifically for the purpose of avoiding memory fragmentation, lowering load times or eliminating them altogether (e.g. God of War).

I would recommend to start off by marking your projectiles as active or inactive instead of destroying them. The simplest memory pool will be a vector array where you reserve, let's say, 3000 projectiles[*]. Each projectile has a variable which lets you know when to update (alternatively, you can have your vector store std::pair<bool, projectile> where the first variable of the pair will let you know if an update is required).

In your update loop, simply iterate over the projectiles and update only the ones that require updating. You may think this is slow, but it is very very fast. I myself initially thought this sort of thing would be very slow and though a list would be better. Problem with list is that you lose cache coherency and you end up taking a hit by all the cache misses (no idea what I am talking about? Don't worry! :).

EDIT: I just saw your tag, which is C and not C++ in which case you will not be able to use vector containers. That is not a show stopper. See the answers to this question for libraries that simplify management of arrays (among other things).

[*] Use resize() to create the projectiles as well. If you are using pointers to projectiles, then reserve() and push_back 3000 new projectiles. If your projectiles are big objects, I would store pointers rather in the vector.

  • \$\begingroup\$ So every game as a limit of projectile/enemy/weapon lying on the ground... ? Or is there game where the limit change dynamically? \$\endgroup\$ Feb 20, 2012 at 1:27
  • \$\begingroup\$ There are games where it changes, but the underlying memory management is quite complex. One such example is Little big planet where they had to de-fragment their memory pools at runtime because of the amount of recycling. They wrote custom code to visualize the memory usage in order to identify problem areas (I can't find the article for this, if someone has the link, please comment) \$\endgroup\$
    – Samaursa
    Feb 20, 2012 at 1:39
  • \$\begingroup\$ Theoretically speaking, the memory is the limit: Even without programmed in limits, you could only create as many objects as fit into your RAM. Even if you start using the hard drive when RAM is full... your HD would be full too, eventually. ;) \$\endgroup\$
    – Exilyth
    Feb 20, 2012 at 8:40

You must log in to answer this question.

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