Chapter 7. Entities

The difference between a real game engine and an SDK wrapper is the level of abstraction evident in the game code. Up to this point, we have merely been writing more convenient C++ classes for key game library components, such as rendering, input, audio, and so forth. Those classes do not make a game engine, they are merely tools. A true engine must run, for one thing! Imagine it this way: You have a block, crankshaft, heads, camshafts, pistons, spark plugs, a fuel injection intake, and a throttle body; do these parts individually produce power? An engine performs work. Every component is crucial to the correct running of the engine, but the engine is far more than just the sum of its parts. Let’s follow the same analogy when thinking about our game engine, and then work on putting the components together, from individual pieces to a whole machine that can produce work.

An entity can be just about any thing you can imagine, but in the context of game development, an entity is usually an instance of an encapsulated system that performs some function. For instance, you might think of a sound effect as an entity, and that might be a valid description, but it doesn’t quite fit. I think of a sound effect as a result of some action performed by an entity, not as an entity itself. What types of objects in a game are likely to perform actions or interact in some way? Most likely, only a mesh or a sprite is likely to interact in a game. So, let’s imagine that mesh and sprite objects share at least one behavior—they are both entities in a game. By sharing basic properties, such as position and velocity, we can manipulate both sprites and meshes using a single call to shared function names. This takes the form of virtual methods in the class definition. Pure virtuals are methods declared with = 0 in the definition, which is equivalent to setting the function pointer to null. On the technical side of C++, class function names are actually pointers to the shared function code in memory, and a pure virtual means that the subclasses override the base class’ function names. I’m using the word “function” to describe the process, while “method” is the proper name for functions defined within a class.