Happy new year with a new devlog about the progress on ncJump. I spent some time on refactoring the Entity source code that were becoming too monolithic, and improving tileset and tilemap by using entities instead of raw sprites for both tile prototypes and concrete tiles. So let us jump into the details.

Everything is entity

An important consideration is that everything is an entity. Characters are entities, tiles are entities, triggers are entities, and so on. So how do you distinguish between them? Every entity can have multiple components, whether it is an image or a state machine or a physics body, therefore different set of components will determine all the different kinds of entities which will populate a game scene. In this devlog we are going to explore the various components needed for the second iteration of the ncJump development.

| component | optional |
|-----------|----------|
| Transform | no       |
| Graphics  | yes      |
| Physics   | yes      |
| State     | yes      |

Transform

The transform component is simply a wrapper around a ncine::SceneNode. Everything else is supposed to be related to this node, so if we want to move the overall entity, we can just update the node of the transform component. It is worth mentioning that we use a unique pointer to store the node on the heap to make sure its memory would not move. This is needed as the nCine scene graph works with pointers.

Physics

The physics component as well as acting as an abstraction layer between the game and Box2D, it holds values like the maximum velocity, jumping strength, and so on. Most importantly it keeps track of a handle to a b2Body which is the mean to query the current physical state of the entity.

Graphics and State

At the base level we have a graphics component with one single image or animation, and a state component with one single state which never changes. These are possibly the most common among the entities of a game.

Now we need to consider the concept of a moving character with states like idle, move, jump, and fall. This set of states is also very common so we implement it directly in C++. The result is the following class hierarchy.

| Subclass       | states                 |
|----------------|------------------------|
| SingleState    | IDLE                   |
| CharacterState | IDLE, MOVE, JUMP, FALL |

It follows that a CharacterState class is closely coupled to its related graphics component, which we define as CharacterGraphics, so the graphics components class hierarchy is quite similar to the previous one.

| Subclass          | graphics               |
|-------------------|------------------------|
| SingleGraphics    | IDLE                   |
| CharacterGraphics | IDLE, MOVE, JUMP, FALL |

As a final consideration, while a state component should be unique for each entity, a graphics component could be shared between multiple entities so to avoid duplicating these kinds of heavy objects.