hxE2 + Entity Systems

[Update 2016.01.26] hxE2 is now deprecated in favour of Eskimo. If someone wants to try and fix issues, sure why not, but I’m not actively using or maintaining this!

[Update] hxE2 has been released in Alpha status here. It corresponds to the topics and improvements to hxE mentioned in this post. All feedback and comments are welcome! :)

I like talking about Entity Systems. And unlike most things I’ve talked about on this website, I have actually finished several implementations of different ECS designs.

My first one was pretty much a port from the Artemis ECS, which I’ve mentioned before, called hxE. But this design was very limited. Each System could only process 1 type of entity, and because of this, it could over complicate simple tasks like checking the distance between “Item” entities and “Inventory” entities. Ideally I would have looped over all <Item, Transform> entities, and checked the distance between all <Inventory, Transform> entities. Simple. The System limit of 1 entity type meant I needed to have 2 systems processing each type of entity, as well as some sort of communication between those systems, or further, generalize the concept of collisions which means more components…etc. etc.

[For those that didn’t understand much about what I just wrote, I recommend reading through the T-Machine blog posts on entity systems. He brings up the core concepts of how they work, as well as addressing common questions.]

Summed up, my ideology is a complete separation of Data and Logic. Systems are logic, and Components are data. What this means is that most components are PODs (Plain Old Data) with no functions, except where they are only helper functions in processing the data of that component. A System can be considered as anything that does work on components, though I usually formalize this concept as a class in most of my engines, simply to provide a common interface/reduce work required to have it running in the engine.

Moving onwards from hxE’s design, my current entity systems have the entity filtering detached from the systems. So now a System is just an empty shell with some function hooks to override (onWorldAdded, onWorldRemoved, process(delta:Float) … ). This means that a system can take in as many entity types as it needs to:

var items = new View2(world, Transform, Item);
var inventories = new View2(world, Transform, Inventory);
for (item in items.entities)
for (inventory in inventories.entities)
{
     var item_transform = items.get1(item);
     var inventory_transform = inventories.get1(inventory);
     var dx = item_transform.x - inventory_transform.x;
     var dy = item_transform.y - inventory_transform.y;
     if (dx * dx + dy * dy <= distance_to_pickup * distance_to_pickup) // add item to inventory and destroy item entity.
}
//var example = new View4(world, Transform, Mesh, Material, Input);

Not only does this make Systems much more flexible, but this also separates the concept of System, and a View into the World. At this point, System classes are helper classes rather than essential parts of the engine – a system can be anything the user wants it to be, interaction with the world is much more direct using Views.

Internally, things are setup to work well in a multithreaded environment. Each View holds a list of updates to process – once this point is made threadsafe, the rest of the interaction with the EntityWorld always happens through the View. This update pushing is also a slight concern for performance, but I will work on having performant, single threaded implementations at a later time if this happens impact projects more than I’m expecting it to.

Over the next few weeks I have a project that will be based on hxE2, and could be interesting to people using it. As I’m doing that, I’ll try to go into more details about specific parts of the hxE2 implementation, focusing on parts I get questions about etc., but for now, this is just a quick introductory post for hxE2 and my way of implementing an ECS!

Enjoi :)

P.

4 thoughts on “hxE2 + Entity Systems

  1. I’ve been using hxE for a while now and uses it extensively with my current game. Good to see a succcessor for hxE but not sure how it’s different regarding systems handling (single vs multiple) components. I notice in hxE, a system filters entities with a certain component pattern (Demand) but it doesn’t prevent me from registering other components as component slots (similar to nodes in Ash).

    For example, I have a CollisionSystem which requires a Collidable component. Ultimately this means the entities I’m dealing have at least thr Collidable component, but these entities may include other components as well. Inside processEntity, I would extract other related components from the entity and work on the logic from there. I can check if the entity has a Pickup component or a Sprite component and do whatever to the entity related to those components.

    Is that the incorrect way of doing things in hxE?

    1. I wouldn’t say it’s incorrect, but it’s not…”type safe” ECS-wise. Optional components is something I haven’t looked into a lot for handling, but generally I haven’t had the need. Generalizing the actions as much as possible helps.
      Views allow you to have a filter for each type of entity you’re going to process, so you can be sure that the required components will exist. Also, super glad to hear you’re using hxE! :) Please do share some screenshots etc. once it’s finished, or even in-dev.

  2. Hi! I couldn’t understand what system changes. Normally in an entity system you have data and systems. I think we have the same concept of data, just info without functionality. I think of systems as the logic part of an entity. Whats the dif between a system and a view.

    I’m working on my own entity system inspire by ash. I made the change of not auto linking entities into systems. I don’t like the idea of adding a property and adding functionality(adding the entity into a system) at the same time. This allows reuse of properties between different types of systems, and it makes it easier to change functionality.
    Removing the auto linking and using some smart macros I was able to removes the necessity of using RTTI.

    I’m still working on the API and workflow, before I release it.

Leave a Reply

Your email address will not be published. Required fields are marked *