Building an Entity Manager

The entity management system in a game engine shouldn’t care what type of object you add to it, as long as that object is derived from a base entity. You should be able to subclass an entity into as many different entity types as you want to use in your game! For our game engine, we’ll modify the Sprite and Mesh classes (created in previous chapters) so they can be used as entities. You probably wouldn’t want to treat things such as lights and cameras as entities because those are part of the props and equipment of a game, not entities. But, if you’re interested in experimenting, you could technically add those types of objects to the entity manager—I’m just not sure how useful that would be.

An entity should provide base properties and methods that will be shared by all entities (regardless of its actual functionality in the game). We want to be able to add an entity by name or identifier number, among other things, and the entity class should provide these facilities.

An entity manager will automatically process the entities and then report the results to the game (or rather, to you, the programmer). This will only work if the entities are properly initialized before they are added. The properties will affect how each entity is drawn, moved, animated, and so forth. If we set an entity’s properties a certain way, it should automatically move and animate. In the future, we may want to add behavior to game entities so they interact with their environment in an even higher level of automation (which is the subject of A.I.). Before that will be possible, however, the entity manager must be programmed with the basic logistics of managing entities.

The entity manager should make it easy to manipulate entities once they’re in the system. We need functionality that makes it possible to add, find, and delete entities from the game code. In the engine itself, we need to automatically move, animate, and draw entities based on their properties. This is the part where game programming really starts to get fun, because at this point we’re working at a higher level, more in the realm of designing gameplay than doing low-level stuff like rendering. This automated functionality is possible through the use of the Standard Template Library; specifically, an std::list. We could use a std::vector, which is faster at consecutive iteration. In other words, when the entity manager goes through the group of entities and processes each one, in a sequential manner, a vector is faster than a list. You may not notice any difference until there are a few tens of thousands of entities, and really it’s a matter of preference. In the end, we need to use an std::list because it is better at deleting items, which is more challenging with an std::vector (which tends to complain quite a bit if you remove an item while it’s iterating through its members).