Why use an entity system framework for game development?

Following my previous post on entity systems for game development I received a number of good questions from developers. I answered many of them in the comments on that post, but one question stands out. It’s all very well explaining what an entity system framework is, and even building one, but why would you want to use one? In particular, why use the later component/system architecture I described and that I implement in Ash rather than the earlier object-oriented entity architecture as used, for example, in PushButton Engine.

So, in this post I will look more at what the final architecture is, what it gives us that other architectures don’t, and why I personally prefer this architecture.

The core of the architecture

First, it’s worth noting that the core of this architecture is the components and the systems. Components are value-objects that contain the state of the game, and systems are the logic that operates on that state, changing it as the game progresses. The other elements of the architecture are purely incidental, designed to make life easier.

The entity object is present to collect related components together. The relation between components is encapsulated by the concept of an entity and that is vital to the architecture, but it isn’t necessary to use an explicit Entity object for this. There are some frameworks that simply use an id to represent the entity, adding the entity id to every component to indicate which entity it belongs to. In this scenario there is no requirement for an entity object at all and entity based operations are performed through an entity manager, using the id to indicate which entity they are operating on.

As a concept, the entity is vital to the architecture. But as a code construct it is entirely optional. I include it because, when using an object-oriented language, the entity object makes life easier. In particular, it enables us to create the methods that operate on the entity as methods of an entity object and to track and manage the entity through this object, removing the need to track ids throughout the code.

While the concept of an entity is vital to the architecture, the concept of node objects is entirely incidental. The nodes are used as the objects in the collections of components supplied to the systems. We could instead provide each system with a collection of the relevant entities and let the systems pull the components they want to operate on out of the entities, using the get() method of the entity.

In Ash, the nodes serve two purposes. First they enable us to use a more efficient data structure in which the node objects that the systems receive are nodes in a linked list. This improves the execution speed of the framework.

Second, using the node objects enables us to apply strong, static typing throughout our code. The method to fetch a component from an entity necessarily returns an untyped object, which must then be cast to the correct component type for use in the game code. The properties on the node are already statically typed to the components’ data types, so no casting is necessary.

So, fundamentally, the entity architecture is about components and systems.

This is not object-oriented programming

We can build our entity architecture using an object-oriented language but, on a fundamental level, this is not object-oriented programming. The architecture is not about objects, it’s about data (components) and sub-routines that operate on that data (systems).

For many object-oriented programmers this is the hardest part of working with an entity system framework. Our tendency is to fall back to what we know and as an object-oriented programmer using an object-oriented language that means encapsulating data and operations together into objects. If you do this with a framework like Ash you will fail.

Data-Oriented Programming

Games tend to be about lots of fast changing state, with players, non-player characters, game objects like bullets and lasers, bats and balls, tables and chairs, and levels, scores, lives and more all having state that might include position, rotation, speed, acceleration, weight, colour, intention, goals, desires, friendships, enemies and more.

The state of the game can be encapsulated in this large mass of constantly changing data, and on a technical level the game is entirely about what this data is and how this data changes.

In a game a single little piece of this data may have many operations acting on it. Take, for example, a player character that has a position property that represents the character’s position in the game world. This single piece of data may be used by

  • The render system, to draw the player in the world.
  • The camera system, to position the camera relative to the player.
  • The AI systems of all non-player characters, to decide how they should react to the player.
  • The input system, which alters the player’s position based on user input.
  • The physics system, which alters the player’s position based on the physics of the game world.
  • The collision system, which tests whether the player is colliding with other objects and resolves those collisions.

and probably many more systems besides. If we try to build our game using objects that encapsulate data with the operations that act on that data, then we will build dependencies between all these different systems as they all want to be encapsulated with the player’s position data. This can’t be done unless we code the game as one single, massive class, so inevitably we break some parts of the game into separate systems and provide data to those systems – the physics system, the graphics system – while including other elements of the game logic within the entity objects themselves.

An entity architecture based on components and systems takes the idea of discrete systems to its logical conclusion. All operations are programmed as independent systems, and all game state is stored separately in a set of data components, which are provided to the systems according to their need.

The systems are decoupled form each other. Each system knows only about itself and the data it operates on. It knows and cares nothing at all about the other systems and how they may have affected by or used the data before or after this system gets to work with it.

Also, by embracing the system as the core logic of the architecture, we are encouraged to make many smaller and simpler systems rather than a few large complex ones, which again leads to simpler code and looser coupling.

This decoupling makes building your game much easier. It is why I enjoy working with this form of entity system so much, and why I built Ash.

Storing the game state

Another benefit of the component/system architecture is apparent when you want to save and restore the game state. Because the game state is contained entirely in the components, and because these are simple value objects, saving the game state is a relatively simple matter of serialising out the components, and restoring the game state involves just deserialising the data back in again.

In most cases, serialising a value-object is straightforward, and one could simply json-encode each component, with additional data to indicate its entity owner (an id) and its component type (a string), to save the game state.

Adam Martin wrote about comparing components in an entity system framework to data in a relational database (there’s lots of interesting entity related stuff on Adam’s blog), and emphasising that conversion between a relational database for long-term storage and components for game play doesn’t require any object/relational mapping, because components are simple copies of the relational database’s data structure rather than complex objects.

This leads further to the conclusion that a component/system architecture is ideal for an MMO game, since state will be stored in a relational database on the game servers, and much of the processing of that state will occur on the servers, where using a set of discrete, independent systems to process the data as the game unfolds is an excellent fit to both the data storage requirements of the state and the parallelism available on the servers.

Concurrency

Indeed, a component/system architecture is well suited to applying concurrency to a game. In most games, some of the systems are entirely independent of each other, including being independent of the order in which they are applied. This makes it easy to run these systems in parallel.

Further, most systems consist of a loop in which all nodes are processed sequentially. In many cases, the loop can be parallelised since the nodes can be updated independently of each other.

This gives us two places in the code where concurrency can be applied without altering the core logic of the game, which is inside the loop in the systems, or the core state of the game, which is in the components.

This makes adding concurrency to the game relatively simple.

We don’t need object-orientation

Finally, because the component/system architecture is not object-oriented, it lends itself to other programming languages that implement different programming paradigms like functional programming and procedural programming. While I created Ash as an Actionscript framework, this architecture would be well suited to Javascript for client side development or any of the many functional languages used for highly concurrent server side development.

Update: In-game editors

Tom Davies has pointed out that a very valuable benefit to him is how easy it is to create an in-game level editor when developing with an entity system framework like Ember or Ash. You can see his example here.

I agree with Tom, this is a very useful benefit of these frameworks. The complete separation of the game state and the game logic in an entity system framework makes it easy to create an editor that lets you alter the state (configuration, level design, AI, etc.) while playing the game. Add to this the easier saving and loading of state and you have a framework that is very well suited to in-game editing.

65 thoughts on “Why use an entity system framework for game development?

  1. Hello,

    I studied your framework and I understood all the principles.
    Although it is a good way to separate the Data from the Logic, I see at least one problem: The framework force me to create a system for each entity context, right?
    So, if I have, for instance, a game with characters, albeit I can have several “Moveable” objects or even several “Bullets”, I will hard have several “character” objects.
    I mean, every single character in the game will have his own logic and it could end up having one system for one entity only, with 1:1 relation.
    All that said, even if I like the idea very much, I probably prefer to use MVC or MVP patterns to achieve similar uncoupling between data e logic (and in this case even rendering)

  2. Hi Sebastiano

    Yes, if each character requires different logic you will need a system per character to handle that. However in an MVC architecture you will need a different controller or model for each character (depending which you put that logic in), so I don’t see the need for a discrete system per logically different character as an inconvenience.

  3. it is a pleasure to talk with you :).
    It is not an inconvenience at all, but it makes your solution less distinctive.
    However there is another thing that I personally (and I say personally) do not like: your approach is still an iterative based approach, that means that it is like having several main loops instead of just one.
    Personally I love event-based programming, because it allows me to simplify my logic (avoiding several “if-else” needed when the logic is processed every frame).
    Nevertheless I find your solution innovative and inspiring (I have already took some ideas from it :))

  4. For me it is very natural approach.

    Not sure how it would work for me in practice, but I will try it:)

    One thing I am curious, because I sometimes need to port my game to other languages (like c++). Richard, do you know any frameworks with similar philosophy like your Ash for other languages like C++?

  5. Hi, may I ask your something about state machine?
    If there is some state machine in a game to handle game logic(like ai, player animation, etc…), how could I port them to entity framework? Should I create different systems contain state machine to handle logic related to different game state which stored in components(such as a component store state of player walking or idle, another component store enemy idle or attacking, etc…)? Thanks!

  6. Hi Silver

    I would suggest you have two options.

    1. Create the state machine as a system. Store the data for the state machine, including the current state, in a component and map entities to the state machine based on that component. Then the state machine receives an update every frame and can update all the entities in the state machine.

    2. Create the state machine as a set of systems, one per state. Create a component to hold the data relevant to each state. An entity is processed by the states based on the presence of the appropriate component. You transition entities from one state to another by adding and removing state components from them.

    I prefer the second option. I am using it in a game I’m developing at the moment and it is working well for me.

  7. Hi, I noticed in your Ash code-base, with the approach of Family/System relationship through Game.getNodes() reflection, that you have to sometimes create dummy component classes to enforce unique formation of family groups. (eg. an empty Spaceship) marker class simply to identify a Friendly spaceship group. THis isn’t too ideal, but than again, i can’t seem to find a better way around this for now.

    Also, i feel the addIfMatch() implementation in http://github.com/richardlord/Ash/blob/master/src/net/richardlord/ash/core/Family.as may potentially have overhead in terms of performance, having to iterate through a dictionary list of component classes to get a “matching candidate”, and than untyped value assignments into the newly instantiated node classes. This is automated partial dependency injection into public variables of an unknown instance. Wouldn’t there be overhead in that, albeit less boilerplate hard-coding/registering into different systems?

    Assuming a game only contains up to 32 families and 32 components, it may be possible to store componentIds:uint and familyIds:uint bitmask in Entity and componentIds:uint bitmask in Family , so matchmaking can quickly be done between a newly added entity with each family with componentIds, and entity.familyIds bitmask can check if the entity was already registered within a particular family. However, one would still required to be forced to iterate through all Families in the Game…

    I guess there’s no real way to avoid this? After all, if one knows an Entity is bound to have certain component types, why nto just register directly to those families without having to iterate and match-make? Additionally, just because an etntity may have a combination of certain components (eg. Position, Color), may not necessarily mean i’d want to be registered to (eg. a Radar system ) within a BlipNode family. THere may be exceptions to such a case.

  8. Assuming Families within a Game are set up to be immutable, it may be possible to create Factory/Pool class instance to help spawn/unspawn entities and their components, and register them to those respective families which the systems require after a 1-time reflection of the entire Game state.

    That way, everything can be precomputed beforehand, saved in a factory instance, and that factory can also support pooling/recyling as well. What do you think?

  9. In any case, if i were to spawn a 3d smoke puff trail entity every 15 miiseconds, when a mortar round travels in the air, I’d don’t want to create unnecessary iteration per smoke puff creation. THat would be expensive. Even precomputated lists may not match up against hard-coding the spawn procedure into the required systems.

  10. Hi Glidas

    Yes, there are some areas in Ash where performance could possibly be improved. I have focused on optimising the game loop rather than the less frequent adding and removing of components and systems, but would like to optimise those eventually. I would be very pleased to receive code contributions – please do fork the GitHub project.

    I did consider using bit masks for matching entities to systems, but as you point out the 32 bit maximum is a significant limitation. It could be extended by using multiple integers but that felt unnecessarily complex at these early stages.

    Thank you for the feedback.
    Richard

  11. Hi Glidas

    Regarding dummy entities, I too am unhappy about them. It could be considered a flaw in my implementation of the Asteroids game – I’m creating state by the presence or absence of a component rather than by the contents of that component – but it seems to work better than having a friend/foe property on a collision component, which would require me to split the node collection into friends and foes every frame.

    Richard

  12. Hi, i can’t really understand why do we need Family class… We can just create Dictionary with one nodeList per each nodeClass, and return appropriate nodeList when getNodeList() called. I can see that there was a reason to create Family class, but there is no comments in it.

  13. hi, can you make a example of Ash, that integrate the State Machine…
    when it come to state machine, become much complex.

  14. Hi tamt, Richard provided me some advice on implement state machine:
    “Create the state machine as a set of systems, one per state. Create a component to hold the data relevant to each state. An entity is processed by the states based on the presence of the appropriate component. You transition entities from one state to another by adding and removing state components from them.”

    Currently it works for me. I think one thing need to be noticed is that if we remove the state component from entity, it also removed from the nodelist in system, we need to take care of the node.next so that it would point to a right successor.

  15. Hi Silver

    Thanks for passing that on to tamt. Regarding the nodelist, when a node is removed from the nodelist Ash doesn’t alter it’s next property, so node.next will still point to what was the next node in the list when this one was removed. This is deliberate, to enable you to remove a node without losing the reference to the next node.

  16. Hi Daniel

    I haven’t had time to document all the classes. I didn’t worry about documenting the Family class for now because it’s an internal class which is only of interest if you want to pick through the inner workings of Ash. In that context, the code is the best documentation.

    The Family class interfaces between the game and the NodeList. It manages the creation of the NodeLists and the addition and removal of nodes from the list. Its functionality could be rolled into the NodeList but I think it sits better in its own class.

    This clear separation of responsibilities keeps both classes simpler and also simplifies the public interface of Ash because of the two only the NodeList, a simple linked list, is public.

  17. Got a question. Say I have an Obj3DUpdate system that contains a linked list of Obj3DNode(s), having a reference to a Position component and an Object3D component. However, in some entities, there is only Position, while some have Position & Rotation, while another has Position & Rotation & Scale, while another may just have Position & Scale, etc. How do I handle this in Ash? Am I forced to create 3 or more rendering systems to account for the combinations, (eg. Ob3DUpdate_P, Ob3DUpdate_PR and Ob3DUpdate_PRS) or is it better to encapsulate the this in some Obj3DUpdater(…dependencies) component base class and have the system call a virtual update() on it? Unfortunately, since the framework is always using the concrete classname of the component instance to do direct matching to Family node fields, this can’t be done, as the concrete classname won’t match with the abstract class name found in the Node field, and I guess that’s not what the framework encourages anyway, which emphasises more on doing purely homoegenous operations over component datas rather than delegating tasks to abstract method calls. The problem with abstract methods/classes, is that if the engine changes, the concrete Obj3DUpdate component implementation for every entity would have to change(eg. some 3d engines might use y and z differently when it comes to up vs forward..eg. Alternativa3D vs Away3D). As a result, dependency injection or resource locators is often used in reponse to such a problem (ie. of mapping the right annotated Obj3DUpdate implementation dependency like: mapValue(Obj3DUpdate, “position/rotation”, SomeUpdater) can be done into the Entity from the context’s IInjector, and than into a Family Node from an Entity’s IInjector (a possible try-case to determine if injection into a Family Node is possible can be done). But this process is very different compared to simply just changing the 3 rendering systems (P, PR, PRS) in the game.

    I wonder though, what might be the performance difference when running 3 inline homogenous operation loops (with potentially more dot accesses) vs a single loop of remote update() calls?

    I guess, when it comes to something like rendering, some standard combinatino of components may have to be used even though an entity might not require it. Eg. Position. Rotation and Scale for 3d models, and Position, Scale for 3d sprites, if i want to keep the no. of systems below 3.

    But i guess having lots of systems wouldn’t do too much harm? I guess that’s the only way to handle such an approach with top-down programming.

    I did toy with the idea that whether annotated dependency injection is used or not, or simply direct concrete classname/family public var field matching being done like in Ash, that assuming all Families within a Game and all Components for an Entity are immutable (might not be in some games though..), it’s possible to precompute all these though a save button, and create a hardcoded .as class that can be saved to help in out entity creation and wiring their components to the right systems. This often produces a fixed entity list, which may be necessary as well for determining what resources (images, models, etc.) to preload.

    However, there’s still an issue with how a framework should entity life cycle, possible pooling, else garbage collection. (Could some components be reused? Which entities could be reused?).

    On a sidenote, to allow certain Family nodes to contain custom fields used by solely by a a given system, which aren’t linked to the components, (since public var fields are always used to match against the components of an entity), you would have to use a custom namespace for the variable (eg. import somePackagePath.system; system var neighbors:Vector.; use namespace system), so it won’t show up in describeType() reflection.

  18. Hi Glidias

    My inclination is, if you want to use different methods to render different entities then you should probably have different systems. That’s not a hard-fast rule, however.

    I have toyed with whether to require annotations in node classes. Something like [required], [optional] and [ignore]. I haven’t yet decided whether that’s a good idea, and which would be the default. There are other solutions that may help you.

    You can subclass a component class and add the derived class but maintain it internally as if it’s the base class. You do this by passing the base class type in as the second parameter when adding the component to the entity.

    Ash only looks at public variables in nodes. It ignores getter/setter methods. So you can add additional data behind getter methods and Ash will ignore it.

    I have added (I’ll commit it later today) pooling for node instances. This is easier than pooling other objects since nodes are created and destroyed by the core classes of Ash. Entities and components are not, so they’re harder to pool in Ash but also open to the user to pool.

  19. Hmm.. yea, missed the base class parameter.

    But I do prefer custom namespaces though as it avoids the overhead/unnecessity of using getters/setters.

    Regarding AI states, if I create it as a set of systems from a strict top-down approach, I’d probably end up with the following:

    IdleSystem, IdleNode
    MoveSystem, MoveNode
    SkulkMoveSystem, SkulkMoveNode
    EngageSystem, EngageNode
    ZombieEngageSystem, ZombieEngageNode
    SkulkEngageSystem, SkulkEngageNode
    WaitSystem, WaitNode
    TakeDamageSystem, TakeDamageNode
    DieSystem, DieNode
    AttackSystem, AttackNode
    ShuffleSystem, ShuffleNode
    FlyingBatAttackSystem, FlyingBatAttackNode
    FLyingFoxAttackSystem, FLyingFoxAttackNode
    FlyingBatShuffleSystem, FlyingBatShuffleNode
    BruteAttackSystem, BruteAttackNode
    BossWaitSystem, BossWaitNode
    BossDieSystem, BossDieNode

    and possibly a whole lot more, with variations depending on whether the AI character is a player, monster, boss, different creature type, etc. As such, it may be best to automatically remove such system from the Game (or parent System) so long as the node list is found empty, and only assign it back once it’s detected to have nodes in order to prevent iterating through many empty states. Because states can change often among numerous monsters (imagine a crowd of enemies), a general parenting AISystem must be in place above all these to ensure transitioning between states is fairly optimized, including the removal of state systems (which shouldn’t be a problem as it’s already a doubly-linked list). Another thing to consider is how state-changes and triggers within a particular state, etc. can affect other components, such as a AnimationManager component which handles switching of animation clips to be played based on state, the duration of the animation which can affect cooldown, or a cooldown stat value which can affect speed of animation and possibly frame/queue-point notifiers to indicate when damage should attempt to be inflicted in melee attack mode. Obviously, an entity could possibly dispatch a signal or something to possibly do some notification, since each node contains a reference to the entity:Entity. Additinally, a Health component which has a takeDamage or die signal, could indirectly force a state switch for the entity, interuptting the current state.

    However, the ability to assign a BaseComponent class does allow one to use a single AISystem to simply update all abstract state machine nodes in a traditional fashion. THis ignores the fact that it might be still necessary to feed in required information on the world situation (eg. neighbours/obstacles/player location(s)), etc. to a given concrete state machine strategy. This often means 1 additional field dependency per node.

  20. Hi Richard! I have encountered a problem with entity systems. If we have a number of systems in our game, and we forgot to add one little component to our entity (so one of the systems cant handle that entity) – then we can’t debug such situation (we can’t really know if specific system must handle specific entity). Otherwise, if we add all required components to the entyties – then all game systems will handle all entyties, and this is also unacceptable. What do you think? Cheers!

  21. Hi Maxim

    I don’t have any specific recommendations for debugging that issue. Naming your entities (Ash has an optional “name” property on the entities for this, that isn’t used internally) can help with debugging in general. But beyond that…

    What I would say is that this shouldn’t, in theory, happen (although I can see why, in practice, it does). You shouldn’t be adding components to your entities so that they will be processed by a particular system. You should be adding components to your entities because those components define what the entity is. For example, if an entity should have a velocity component that’s not because you want it to be processed by the physics system, it’s because the entity moves, so it needs velocity within its data set.

    Now, I admit that we tend to build these games system by system, and that means adding a component or two, a system that uses them, and then adding the components to the appropriate entities. If you miss an entity at this stage, you will get the problem you describe. So it’s natural that it happens.

    Maybe recognising that the entity not being processed by a system is a side effect of the real problem, which is not defining all the properties of the entity correctly, will suggest some other debugging technique. Sorry I can’t help more.

  22. Thank you for the answer! I think that with big amount of entities and systems i have HUGE chance to get this problem again :( . Will search for good solution then, cheers!

  23. The thing you have to rmb though, entities don’t get registered to Systems directly, they get registered to Families, which hold groups of entities sharing the same behaviour-set. This is actually a good thing since multiple Families’ data structures (in the case of Ash, restricted to NodeLists) can be used from a given system.

    When it comes to bug tracking, the Game class stores an entity list called “entities” by dfault, because it assumes new families could be added (as a result of adding new systems) midway in the game. You can run through all entities in the list (maybe provide a public getter from the Game), with your Debug system and trace which families the entities belong to.

  24. Also regarding dummy node fields and dummy components, my Haxe version of Ash I’m developing allows direct registration of families into a given system,since Families (now extending from a base class Family) can be custom strictly typed Generics and own custom data structures that are also strictly typed.). DUe to the fact that declaration of custom families are explicit within the game, every Family base class can also have a typeMask:int variable discriminant that acts as a typemask against an entity’s typeMask:int variable. This allows Families to discriminant and only register entities if their components match and the entity’s type matches the Family if the family has a typeMask that isn’t zero. Anytime a typeMask changes or the component configuration changes within an Entity, Systems are responsible for notifying the Game directly of such a change (yes, I ditched the componentAdded and componentRemoved signals) in my version. I also have a FamilyTree class that extends from Family (like composite paterrn), to allow for nested families within a family, so a combination like Object3D+Position+Rotation will not get registered to a Object3D+Position family, because there’s a sub-family like Object3D+Position+Rotation available within the tree.

  25. Optional family64, family32, component64, component32 compile flags are also provided to allow the framework to use bitmasking for quicker component checks, albeit that would impose a 64 or 32 bit limit to the amount of families or components you may have in the game. For 64 bit, i just use 2 ints.

  26. I guess having an option to assert that an Entity should belong to a Family could be done, but that detracts from the purpose of Ash, which is to loosely couple the Game (families and systems), with the Entity and it’s components. However, I’m still considering the idea of allowing direct registration of entities to explicitly declared or implicitly available Families, in my Haxe version (with runtime checks to ensure all component field dependencies are met when running in developing mode),. I guess that could mean Family references could exist within the Factory, and not just within the Game’s lookup hash of families itself. If adding to Families is done beforehand by the factory, than the Game would simply only add the entity to the entities list, nothing more, by using another method to add the entity like Game._addToList(ent). However, using this approach would tightly couple the Factory (ie. creation of entities) to the Families.

  27. …which may actually be a good thing. But that would require explicit declaration on the developer’s part,often means a fixed strictly typed list of Families.

  28. Maybe bind a factory class or method with a strictly typed list of families. So, anything that comes out of that factory must belong to all those explicitly declared families. If it failed to match any of the given families, either a warning/error is shown or else the required components are added on the fly. That way, u won’t miss out any entities or have to configure any of them, if say, you have 100 entity types to run through….

  29. Anyway, here’s the Haxe modification. https://github.com/Glidias/HashDS . It doesn’t have the binding approach I described, but given the API, it should be quite easy to create your own family+factory combo utility with the ability to check if family._matches() at runtime prior to confirm-adding an entity into the family. As for now, I need to do simple tests with the framework first before I consider it stable.

  30. Hey Richard,

    first of all thx for the great posts about entity systems, it really makes the point clear about it.

    can you tell what the difference is between ash and ember2?

  31. I have one question about ash.How to combine ash to Starling framework.
    Level editor, etc.

  32. The state machine problem exposed by Glidias is exactly what I am trying to figure out. A solution I might try is passing the entity itself to the different states, so that they can retrieve whatever components they need to operate on, but it sure seems like it defeats the purpose of this framework.

  33. Pingback: Games And Entity Systems | Shaun Smith

  34. Indirect state/family registration has it’s advantage in being able to focus on customizing entities and letting the systems “auto-wire” them accordingly.

    For example:

    – AttackFamily, AttackNode
    – FlyingBatFamily, FlyingBatAttackNode

    With a type mask identifier/Class component-marker for:
    – attack
    – flyingBat

    If an entity contains flyingBat + attack, he incidentally falls under the FlyingBatAttackNode family, overriding the default AttackNode as his chosen family. Note that this only works if you’re using some sub-family functionality (that HashDS provides). In regular Ash, he’ll end up being registered to both systems simultatenously, which isn’t what you want. ( In an object-oriented system, this typically involves overriding base class methods and rewriting the implementation again for the extended base class)

    There’s overhead in auto-wiring, but i guess it “may” be possible to hardcode/pre-define certain “registrations” in a truth table once all components/entities/families/systems are finalised (ie. no longer being developed).

    However, registering entities directly to Families not all that wrong either and many entity-component based frameworks out there also do that (whether manually or via dependency injection), with runtime checks to ensure dependencies are valid. The only problem with such a method is that Families/Systems can’t easily be removed at will at runtime, without having to touch entities’ codes.

    I guess it depends on what suits best in what situation.

  35. Hi Glidias

    There’s a branch in Ash that allows developers to swap the Family implementation for different purposes. This will be merged to master as soon as I have time to refactor the tests in a more appropriate way.

    Further, Mikhal has built on this to allow entities to be excluded from families if they have a specific component type. This would allow the bat to be excluded from AttackNode if he has a FlyingBat component.

  36. hi,richardlord! I am glad to study the new game framework ash created by you. It is so powerful that
    i want use it to my project.Also i have written a page for
    thinking ash.
    If you can read chinesse please go link:http://www.the3frames.com/?p=704.

    you fans!
    harry

  37. Pingback: Box Hacker » Blog Archive » Using an entity component system in AS3

  38. Seeing that the Ash framework is AS3, is it possible to ‘shoehorn’ Box2D or Nape physics into it? I could see implementing a System that wraps Box2D and calls step() during update(), but how would Rigid Bodies be created and assigned ?

  39. richpixel –

    It should be possible to wrap a physics engine as a system (although the ideal is a physics engine written specifically for this architecture). The rigid bodies would presumably be properties of the entities, and as such they would be assigned as properties of a component and the components attached to the entities. These components would likely be instances of the component class that causes the entity to be processed by the physics engine.

    So, for example, the Physics component class has a rigidBody property. And all entities with a Physics component and a Position component are processed by the PhysicsSystem, which is the wrapper around the physics engine.

  40. OK thanks! Just looking at the asteroids example now (I’m not fully up to speed yet)… I’m guessing the PhysicsSystem would replace the MovementSystem in the asteroid example (?) I really like the idea of the PhysicsComponent dealing with the messiness of Box2D rigid bodies under the covers and just providing clean position data in a standard x,y format.

    Anyway, very nice framework…! I’ll be looking at it further.

  41. The asteroid example has all the onscreen entities extending Sprite or Shape objects. I would like to add a Textfield, and update the TF on every relevant System.update() call (e.g., a menu system, or statistics display). I am having some difficulty figuring out how to do this. Could you explain a bit more, or post some example code?

  42. @iND

    You would include the textfield in the display component, just as any other display object, so that the render system will draw it. You would also include the textfield in another component, lets call it the hud component, and then another system, call it the hud system, would update the textfield in its update.

  43. Nice read, thank you.

    What strikes me is you saying that this is not object oriented programming. For me it’s just that and a good example of it. You have bundled concrete properties into an encapsulating object that is not only shareable from now on but is also used where it is most needed. I see that most oop beginner examples say ‘encapsulate data and the functions that work on it in an object’ but in my opinion this is only the tip of the iceberg. When you dive deeper into oop and it’s pattern and overall structures (thinking composition here) it’s way more oop than the beginner examples. Whom am I telling this :-) but I’m just curious why you call it being NOT OOP.

  44. I say it’s not OOP because of the lack of encapsulation. In fact, this architecture doesn’t need an object-oriented language at all. It could be coded in C, for example, since all that’s needed is structs for the components, a linked list for the entities, and function pointers for the systems, which can each be simply an update function.

  45. It looks like youve made some android applications. Im trying to make one myself using this type of programming. My question, how exactly do the events and widgets of android programming fit? or possibly how can I make them work with it?

  46. Pingback: Tinkering With Ash - MikeCann.co.uk - mikey see, mikey do!

  47. In ComponentMatchingFamily, does `nodes : NodeList` only reflect the entities in `entities : Dictionary` in a linked list structure?
    Is this an iteration performance consideration, or are there other reasons to do this?

  48. @Caleb

    I don’t program android apps in Java, so my games are built as a single activity. I imagine if I did build them in Java, I would continue to create the game as a single activity, with an entity system as its core architecture, but use other widgets etc. as appropriate for menu systems, high score tables etc which will not use the entity system at all.

Leave a Reply

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