After having stumbled upon entity systems, I have been a little bit infatuated with the design concept. I decided to spike out a little game for fun and brush off my math skills; thus EStroids was born. It is just a quick and dirty little game, doesn't have all the defensive programming checks that would normally go into an app or game, but was pretty fun to write. (It also has things that will make a mathematician cry, such as multiplying a 4✗4 matrix and a vector3.)
I have the little project hosted on GitHub in case I decide to poke around it some more. Overall, it was just fun and nice to see how easily it is to put little games together. I have absolutely no real-world experience that tells me this sort of approach is scalable, but I do see merits to the approach.
And without further ado, the link: https://github.com/jjvdangelo/EStroids
Systems
Each of the systems inherit from SystemBase that just takes in a manager. (Like I said, just quick and dirty.)
public abstract class SystemBase
{
private readonly EntityManager _manager;
protected EntityManager Manager { get { return _manager; } }
public virtual void Initialize() { }
public virtual void Shutdown() { }
public abstract void Frame(double dt);
protected SystemBase(EntityManager manager)
{
_manager = manager;
}
}
Here's the "lifetime" system that manages objects that have a timed lifespan:
public class LifetimeSystem : SystemBase
{
public override void Frame(double dt)
{
var toDestroy = new List();
foreach (var entity in Manager.GetEntitiesWithComponent())
{
var expiration = entity.GetComponent();
expiration.TimeAlive += dt;
if (expiration.TimeAlive < expiration.MaxLifetime) continue;
toDestroy.Add(entity);
}
toDestroy.ForEach(x => Manager.DestroyEntity(x));
}
public LifetimeSystem(EntityManager manager)
: base(manager) { }
}
So much cleaner than trying to shove this into some base class and figure out where this behavior should live within an object oriented hierarchy.
Components
And this is a simple component (the Expiration component) used by the LifetimeSystem:
public class Expiration
{
public double TimeAlive { get; set; }
public double MaxLifetime { get; set; }
}
Basically, we work to separate the data away from the behavior and away from the entities themselves. This the complete opposite type of work that I've done for so many years trying to efficiently pull all of these things together. It is almost always a code smell when you have "Manager" objects, quickly leading to an anemic object model.
Make Sense?
For anybody who may experience with entity systems, does this make sense? Am I interpreting the intention of entity systems? I feel like I'm picking up the idea but it's always good to have a sanity check here and there!
