In this chapter, and for the entire length of this book, we are going to be using these resources:

Let us start with the basics. Most (if not all) entities in any game we build are going to be positioned within the world. Let us ignore the corner cases of special types of entities for now. In order to represent the entity position, we are going to be creating a position component like so:

class C_Position : public C_Base{ 
public: 
  C_Position(): C_Base(Component::Position), m_elevation(0){} 
 
  void ReadIn(std::stringstream& l_stream){ 
    l_stream >> m_position.x >> m_position.y >> m_elevation; 
  } 
 
  sf::Vector2f GetPosition() const { ... } 
  sf::Vector2f GetOldPosition() const { ... } 
  unsigned int GetElevation() const { ... } 
  void SetPosition(float l_x, float l_y){ ... } 
  void SetPosition(const sf::Vector2f& l_vec){ ... } 
  void SetElevation(unsigned int l_elevation){ ... } 
  void MoveBy(float l_x, float l_y){ ... } 
  void MoveBy(const sf::Vector2f& l_vec){ ... } 
private: 
  sf::Vector2f m_position; 
 ...

The code we have written so far would only produce a static, unmoving scene. Since that isn't very exciting, let's work on adding potential for entity movement. Since it calls for more data being stored, we need another component type to work with:

class C_Movable : public C_Base{ 
public: 
  C_Movable() : C_Base(Component::Movable), 
    m_velocityMax(0.f), m_direction((Direction)0){} 
 
  void ReadIn(std::stringstream& l_stream){ 
    l_stream >> m_velocityMax >> m_speed.x >> m_speed.y; 
    unsigned int dir = 0; 
    l_stream >> dir; 
    m_direction = static_cast<Direction>(dir); 
  } 
  ... 
  void SetVelocity(const sf::Vector2f& l_vec){ ... } 
  void SetMaxVelocity(float l_vel){ ... } 
  void SetSpeed(const sf::Vector2f& l_vec){ ... } 
  void SetAcceleration(const sf::Vector2f& l_vec){ ... } 
  void SetDirection(const Direction& l_dir){ ... } 
  void AddVelocity(const sf::Vector2f& l_vec){ ... } 
  void ApplyFriction...

In order to make the game we're making feel like more than just entities moving across a static background with no consequences, collisions have to be checked for and handled. Within the ECS paradigm, this can be achieved by implementing a collidable component. For more flexibility, let's define multiple points that the collision box can be attached to:

enum class Origin{ Top_Left, Abs_Centre, Mid_Bottom }; 

The TOP_LEFT origin simply places the collision rectangle's top-left corner to the position provided. ABS_CENTRE moves that rectangle's centre to the position, and the MIDDLE_BOTTOM origin places it halfway through the x axis and all the way down the y axis. Consider the following illustration:

With this information, let us work on implementing the collidable component:

class C_Collidable : public C_Base{ 
public: 
  C_Collidable(): C_Base(Component::Collidable),  
    m_origin(Origin::Mid_Bottom), m_collidingOnX(false), 
    m_collidingOnY(false){} 
 
  void ReadIn...

Since we have already laid down the code foundation, it's now possible to focus on controlling the entities on the screen. Whether they're being controlled as player avatars by means of a keyboard, or through some sort of artificial intelligence (AI), they still need to have this basic component:

class C_Controller : public C_Base{ 
public: 
  C_Controller() : C_Base(Component::Controller){} 
  void ReadIn(std::stringstream& l_stream){} 
}; 

As you can tell, we have absolutely no data that gets stored here so far. For now, it can simply be considered just a specific signature that lets the ECS know it can be controlled.

S_Control::S_Control(SystemManager* l_systemMgr) 
  : S_Base(System::Control,l_systemMgr) 
{ 
  Bitmask req; 
  req.TurnOnBit((unsigned int)Component::Position); 
  req.TurnOnBit((unsigned int)Component::Movable); 
  req.TurnOnBit((unsigned int)Component...

Having entities that are able to move around now implies they can either be standing still or moving. This quickly brings about the issue of entity states. Luckily, we have an elegant way of dealing with that, by introducing another component type and a system. Let's start by enumerating all possible entity states, and using the enumeration to establish a component type:

enum class EntityState{ Idle, Walking, Attacking, Hurt, Dying }; 
 
class C_State : public C_Base{ 
public: 
  C_State(): C_Base(Component::State){} 
  void ReadIn(std::stringstream& l_stream){ 
    unsigned int state = 0; 
    l_stream >> state; 
    m_state = static_cast<EntityState>(state); 
  } 
 
  EntityState GetState() const { ... } 
  void SetState(const EntityState& l_state){ ... } 
private: 
  EntityState m_state; 
}; 

That's all we have to keep track of inside the component class. Time to move on to the system!

One of the objects sensitive to state changes is the sprite sheet animation system. Knowing an entity's state is of paramount importance, if we desire to apply animations that describe its current action:

S_SheetAnimation::S_SheetAnimation(SystemManager* l_systemMgr) 
  : S_Base(System::SheetAnimation,l_systemMgr) 
{ 
  Bitmask req; 
  req.TurnOnBit((unsigned int)Component::SpriteSheet); 
  req.TurnOnBit((unsigned int)Component::State); 
  m_requiredComponents.push_back(req); 
 
  m_systemManager->GetMessageHandler()-> 
    Subscribe(EntityMessage::State_Changed,this); 
} 

As you can see, all we need are two component types and a subscription to a message type of State_Changed. So far, so good!

Updating the sprite sheets can get a little involved, so let us delve right into it:

void S_SheetAnimation::Update(float l_dT){ 
  EntityManager* entities = m_systemManager->GetEntityManager(); 
  for(auto &entity : m_entities){ 
    auto sheet = entities-> 
  ...

Just like states, an entity can emit multiple different types of sound. Each different type must also have certain parameters associated with it:

enum class EntitySound{ None = -1, Footstep, Attack, 
  Hurt, Death, COUNT }; 
 
struct SoundParameters{ 
  static const int Max_SoundFrames = 5; 
  SoundParameters(){ 
    for (int i = 0; i < Max_SoundFrames; ++i){ m_frames[i] = -1; } 
  } 
  std::string m_sound; 
  std::array<int, Max_SoundFrames> m_frames; 
}; 

struct SoundParameters simply stores the name of the sound, as well as an array of integers for the maximum number of sound frames. A sound frame is the glue between sounds and sprite sheets, as it defines during which animation frames the sound is emitted.

class C_SoundEmitter : public C_Base{ 
public: 
  C_SoundEmitter():C_Base(Component::SoundEmitter),m_soundID(-1){} 
  void ReadIn(std::stringstream& l_stream...

With most of the backend already covered, we're ready to move towards the front, and start working on more interactive aspects of the project, such as interfaces. Let's start by creating a main menu:

void State_MainMenu::OnCreate(){ 
  auto context = m_stateMgr->GetContext(); 
  GUI_Manager* gui = context->m_guiManager; 
  gui->LoadInterface("MainMenu.interface", "MainMenu"); 
  gui->GetInterface("MainMenu")->SetPosition( 
    sf::Vector2f(250.f, 168.f)); 
  EventManager* eMgr = context->m_eventManager; 
  eMgr->AddCallback("MainMenu_Play", &State_MainMenu::Play, this); 
  eMgr->AddCallback("MainMenu_Quit", &State_MainMenu::Quit, this); 
} 

All of these classes have already been covered in Chapter 1 , Under the Hood - Setting up the Backend, but let us have a quick rundown of what this does once more. After we obtain the shared context, a main menu interface is loaded and positioned on screen. The m_eventManager is then used to bind...