An entity system

Here’s a cross-post from my Moonman devlog.

Update: Well it’s been a while, but here’s my first update for 2014. I haven’t touched MM code for a month but instead have been designing and implementing a cleaner and simpler entity system. I’ve been meaning to do this for quite a while now, but after using Unity and looking at other bits of code like entityx I decided to finally attempt it. This is helped in part by the new c++ support in VS2013. The system is also data-oriented — all components and entities are tightly packed in memory. I use a similar free list setup as in MM. I also had to use some c++ techniques I haven’t used before, such as variadic templates and typelists. But that is all behind the scenes, this is what the API looks like:

EntitySystem es;

// Create an entity
// and add some components
Entity& e = es.create();
e.add(Description(“An architecture-obsessed programmer.”));

// Create another entity
// with different components
// this time using intializer_list shorthand
Entity& chest = es.create();
chest.add(Transform(-4.5f, 0.8f));
 { Item::SWORD },
 { Item::POTION, 4 },
 { Item::POTION, 3 },
 { Item::ARROW, 64 }

// If we need to keep a reference to an entity
// then we use ID’s (uint32s)
ID chestId =;

// Then later on somewhere we can get the entity
// and do something with it, e.g.,
if (es.has(chestId)){
 Entity& ch = es.lookup(chestId);

 // Shift the chest one unit horizontally
 Transform& tr = ch.get();
 tr.x += 1;

// Iterating through all entities
// can be done with a range-based for loop
for (Entity& e : es.entities()){
 std::cout << e; } // Likewise, we can iterate through all // components of a particular type. For // example a PhysicsSystem might want to // process all the Physics components. for (auto p: es.components()){
 // Apply viscocity
 p.vy *= 0.9f;
 p.vx *= 0.9f;

 // Move entity
 Entity& e = es.lookup(p.entity);
 Transform& tr = e.get();
 tr.x += p.vx;
 tr.y += p.vy;

// Everything is done with references
// if e doesn’t contain C, then
// e.get() returns a blank component
// (which can be checked for validity)
Entity& e = es.lookup(id);
Health& health = e.get(); = 666;
if (health){
 // It’s valid

// Components themselves are just structs
// The CRTP gives them a unique class id
// that is used to store them in EntitySystem
struct Health: public Component {  
 float health;
 bool poisoned;
 Health(float health = 0.f, bool poisoned = false) :health(health), poisoned(poisoned){}

 std::string what() const; // human readable rep
 static const char* Name(); // name

// The logic of a component is implemented
// in a system. e.g., the HealthSystem might
// be responsible for decreasing a character’s
// health if they are poisoned.

class HealthSystem : public ISystem {
 bool implements(int componentIndex) override {
   return Health::Index()==componentIndex;

 void setup(Entity& e) override {
   e.get().health = 100;

 void update(EntitySystem& es, double dt) override {
   for (Health& h : es.components()){
     if (h.poisoned){ -= 0.1f * (float)dt;
       if ( <= 0){          // Create KILL EVENT        }      }    }  } }; [/cpp] Besides this I've also been thinking about having Script components. These will be a special type of component that uses traditional polymorphism and lambdas to offer a concise and easy way to implement special behaviours. For example, I could attach a custom c++ poison script to a entity like this: [cpp] Script* newPoisonerScript(Entity& e){  // variables to be captured by the lambdas  float* duration = new float(0.f);  float* timer = new float(0.f);  auto poisoner = new Script("poisoner");  poisoner->destroy = [duration, timer](Entity& e){
   Health& health = e.get();
   if (health) health.poisoned = false;
   delete duration;
   delete timer;

 poisoner->start = [](Entity&e){
   Health& health = e.get();
   if (health) health.poisoned = true;

 poisoner->update = [timer, duration](Entity& e, double dt){
   *duration += (float) dt;
   Health& health = e.get();
   if (health){
     if (health.poisoned){
       *timer -= (float) dt;
       if (*timer < 0){ -= 1;          *timer = 1.0f;        }      }    }  };  poisoner->finished = [duration](Entity& e){return *duration>1.5f;};
 return poisoner;

Anyway, once I’ve finalised the new system it’s going to take a couple of days to incorporate it into Moonman, but I definitely think it’s worth the deviation. Basically it means that I’ll turn macro’ed code that looks like this (see devlog for explanation of how it works):

ATTRIB(e, x) += 0.1f;
bool isOnGround = ATTRIB_OR(e, is_on_ground, false);
bool hasPhysics = HAS_ATTRIB(e, is_physics);

Into nicely autocompleting code that looks like this:

e.get().x += 0.1f;
// or with shorthand
e.transform().x += 0.1f;
// and
bool isOnGround = e.get().isOnGround;
bool hasPhysics = e.has();