Using the example of the aircraft, we need to define a concrete entity class. We derive it from Entity. Since we have different airplanes in our game, it would be nice to have a data type that can store them. An enumeration comes in handy; we call it Type and make it a member of the Aircraft class. Therefore, we can now refer to it as Aircraft::Type, which is quite expressive when we see it in the code. Up to now, we have two distinct airplanes, we call them Eagle and Raptor. Each type of aircraft corresponds to an enumerator in our enum.

Furthermore, we declare a constructor for the aircraft that takes its current type as parameter. We also declare a member variable for the type in the following code:

class Aircraft : public Entity
{
    public:
        enum Type
        {
            Eagle,
            Raptor,
        };

    public:
        explicit        Aircraft(Type type);

    private:
        Type            mType;
};

The constructor's definition is straightforward; we let it initialize our mType member variable:

Aircraft::Aircraft(Type type): mType(type)
{
}

Now this is the fundament for our Aircraft class. During this book, we will continuously extend it and add new functionality.

You should be aware that a class hierarchy is not the only option to model game entities. There are always different possibilities to design a piece of software, all of which have its own advantages and drawbacks.

The hierarchy-based approach gets to its limits when we introduce many, slightly different entity types. Imagine a complex game with different kinds of vehicles, such as tanks, ships, submarines, airplanes, and more. Every entity type has different capabilities, such as flying, transporting people, carrying weapons, and diving. It may be tempting to create corresponding base classes TransportEntity, ArmedEntity, DivingEntity that all derive from Entity. A submarine could then inherit ArmedEntity and DivingEntity; an armed freighter could inherit TransportEntity and ArmedEntity. On one hand, this design leads hand to the so-called diamond of death, where the base class Entity is indirectly inherited multiple times, requiring virtual inheritance. On the other hand, the hierarchy becomes very deep and rigid. In order to reuse functionality for different entities, it is moved to base classes. This makes classes towards the root of the hierarchy a lot heavier than they should be. This in turn results in derived classes which inherit a lot of functions and data they never need. Eventually, objects become overly large, hence slower to process and more difficult to maintain.

In such a case, component-based design would be an alternative, meaning that abilities are aggregated as components in the single entities, instead of base classes. Each entity would then hold the abilities as members. But as you might expect, this approach is not the silver bullet, either. Components often depend more on each other than theory would like them to, and they need an efficient and flexible way to communicate with each other. While component-based approaches are certainly an option to consider for large-scale games, they are rather complex for the first game to develop. In our basic aircraft shooter, the typical problems of entity hierarchies do not show, so we chose this approach for the sake of simplicity.

If you are interested in a more detailed explanation on the topic of component-based game design, we recommend reading the article series on the following website:

http://stefan.boxbox.org/game-development-design.