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.

I'm currently reading the book Programming Game AI By Example.

The book mentions assigning unique ID numbers to each entity in the game. Often when entity A needs to contact entity B, A gets a reference to B by sending B's ID number to an EntityDatabase class. This class recieves ID numbers and returns references to the entities.

The ID numbers of some entities could also be fetched from a file containing the IDs of some of the entities (the main game characters).

My question is: Why would I do this? Why can't I work directly with references? Is it sometimes difficult to get a direct reference? Is using an ID system a common approach? Are there games that don't use IDs?

I'm new to game development. Please explain the benefits of working with an entity ID system. The advantages and disadvantages. Concrete examples would be great. Thanks

share|improve this question

2 Answers 2

up vote 16 down vote accepted

References work well for many situations. However, there are three important situations in which references won't work well:

  • Networking. When sending information about synchronizing the state of entities over the network, references can't be used. You'll need to identify the entity in some way so the remote machines know who you're talking about.
  • Saving/loading. When saving the state of your game to disk, the object references can't go with it. That means when you're loading the state, Entity A that had Entity B targeted by a reference no longer knows who to target. The memory locations are different, the objects are different.

  • Memory management. Having a central place to store references means that when deleting an entity, you don't have to go through all your entities and remove references to it for the memory to be cleaned up. References should only be used when needed, then removed in any other entity. Reducing reference counts ensures you don't have zombie entities that are only referenced by the last thing they interacted with or some other entity. This also helps to avoid null references with a standardized way of testing if an entity still exists.

share|improve this answer
last paragraph should be a bullet point of its own (memory management). There are situations where one class needs a reference to another entity for some time, but the entity reference may become invalid (ie projectile target entity died). By returning NULL when requesting an entity by ID each class takes responsibility to do the right thing (rather than crashing) when the entity reference becomes invalid. –  LearnCocos2D Apr 12 '14 at 15:27
Thanks for answering. A question to clarify. In general: In situations where entity A needs to get a reference to entity B (in order to attack it, send it a message, check collision with it, or any other reason at all) - Should I use the ID system in order to get it, or is it sometimes okay to obtain the reference directly? Meaning: Should entity A always get the reference from the EntityManager by sending it the ID of entity B (which cross-references entity-references and ID numbers), and only then contact entity B using the reference from EntityManager? Should I always use the ID system? –  Aviv Cohn Apr 12 '14 at 19:41
Or is it sometimes okay to obtain the reference directly? In other words, when should I entity A use the EntityManager to obtain the reference stored inside it, and when can entity A fetch a reference to B by whatever means it has? –  Aviv Cohn Apr 12 '14 at 19:42
There's no real correct answer to that. Personally, I would design the entity system to be independent from the game logic. That would mean the game logic doesn't even have access to direct entity references. Essentially, I would avoid maintaining any reference to an entity beyond the local scope of the current method. That means using the EntityManager every time before operating on an entity's components. –  Byte56 Apr 12 '14 at 20:36
I see. Let me use an example to see if I understand what you mean. Let's say I'm using a uniform grid to do collision detection. The grid is a 2d array. Each entity is checked for collision only with the entities in the same 'cell' in the grid. Using the "regular" approach, each cell would hold references to the GameEntity objects in the area it represents. Using the "ID system" approach, each cell would hold the ID numbers of the entities. These numbers would be sent to the EntityManager to receive the concrete references in order to do the collision detection. Is this a good understanding? –  Aviv Cohn Apr 12 '14 at 21:40

One last thing is that if you are using the Object Pool pattern and an entity gets reset because the creature died (for instance) and respawned somewhere else, a reference will still point to the same entity (fault) and an ID will no longer remain valid.

ID 5067 points to address 0x8765 creature dies and another spawns new creature ID is reset to 7073 Someone checks for ID 5067, it points to 0x8765 but that creature is now registered with the ID 7073 so the entity ID database knows you used an obsolete ID and informs you, the creature you have tried to reach is no longer active.

That and all the wonderful reasons Byte56 mentioned are why it is a good design to avoid using references directly.

share|improve this answer

Your Answer


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.