---

Details: The Entities

Here you will find some detail about game entities: Entity types, Entity containers and Some warnings.

Entity types

It is likely you'll want entities of different types. In simple cases you can have one entity class, and fiddle with bit flags (like CMyEntity initially does). But there are more complex cases, where you'll want different classes for entities.

The first problem is: base game entity CEntity does not support virtual methods. You can't have them in your derived classes.

The second problem: if entity objects are of different sizes, it's not easy to hold them in fast container (array or pool).

We propose such method: you can have different classes for your entities. Just have them without virtual methods and put their objects into separate containers. Then, while processing entities, you process all the containers separately, hence practically no need for virtual methods. And as different class entities are in different containers, there's no problem with different object sizes.

Entity containers

You'll need to manage your entities somehow, so you'll need some container for them (keep in mind, that entity management is not engine's responsibility). Theoretically, you could have your entities wherever you like, and only register them for rendering via CEntityRenderer.

In practice, because we deal with lots of entities, some simple solutions just don't work:

• If you'll use new/delete every time you create/destroy an entity, it will be slow.
• If you'll use linked list (like std::list) of entities or pointers to entities, it will be slow because lists and CPU cache are enemies :)

Remaining possible solutions:

• Use pool of entities (CFixedPool). This is our proposed method, as it allows O(1) insertion/removal times, no need for new/delete, more cache friendliness than lists, and the entities are never moved around in memory. The downside is: it's maximum capacity is fixed, the objects must be equal in size, and slightly more expensive traversal than for arrays.
• Use compact array of entities. Every time you add an entity, add it to the end; and every time you remove, place the last in place of removed one. This has almost the same positive and negative aspects as a pool; with one good thing - traversal ir very cheap, and one bad thing - entities are moved around when removed. If you use this approach, keep in mind that every time you move entity in memory, you must remove it from renderer, move it, and add to renderer again (because renderer keeps pointers to entities).

Both of these methods don't preserve traversal order of the entities. That is, you are guaranteed to traverse all the entities, but can't be sure of traversal order.

Some warnings

When remove entity from CEntityRenderer, you lose all base CEntity information. In fact, nearly all CEntity methods become invalid and will cause a segmentation fault. If you want to preserve the information - remember it somewhere before removing the entity.

---

Prev: Details: Using the Grid.
Next: TBD.

---