Entity Systems: what makes good Components? good Entities?

Oh goody… More ES discussion! ;) I actually posted a bunch of thoughts in Paul’s post already several days ago. I brought up the use of interfaces as concrete types vs using getClass() internally to store components / systems, the ability to store collections of components by type, and one other trick I employ in my efforts to store components by a non-related interface (I also described this in the previous goliath ES post).

On more systems than components:
“However, it can also be an early-warning sign of a design or code-architecture bug.”

Well, once you can store a collection of systems a pattern in my work I’ve exploited is having at least one (or more) data component track state and iteration over a series of systems provides implementation details that may otherwise be done through an inheritance hierarchy. This is more possible in my efforts since I’ve generalized the ES approach described in your efforts. IE a generic component manager that stores components locally / interally as opposed to a global store. Data and system components can also be managers and contain their own components / systems.

A concrete example is say a collision system. While it may be possible to make a heavyweight collision system component that contains all the logic to test for an entity collision between the world and other entities in my efforts the collision system is a component manager itself. The collision system defines a “collide” method, but also a lifecycle system interface (IColliderLifecycle).

The method for the collision system manager is:
IExtEnum collide(@Nonnull IComponentManager source, @Nonnull IComponentManager clockDataManager);

In my efforts an entity (Entity / IEntity) is an IComponentManager by just reducing the method sig to just deal with IComponentManager reduces any specific hard connection between the collision system and entities. Anything can potentially be checked for collisions if the proper components are contained. The return parameter also is an extensible enum so any state can be returned including no operation.

The implementation of the collide method of CollisionManagerSystem looks like this:

public IExtEnum collide(@Nonnull IComponentManager source, @Nonnull IComponentManager clockDataManager);
{
CollidePointData cpd = source.getAs(DATA, CollidePointData.class);
if (cpd == null)
{
return NoOpEnum.NO_OP;
}

cpd.reset();

for (FastPIterator iter = getAsIterator(SYSTEM, IColliderLifecycle.class); iter.hasNext() && cpd.resolved == false;)
{
iter.next().collide(source, this, clockDataManager);
}

return cpd.collisionResult;
}

Essentially the above code will retrieve an iterator for the IColliderLifecycle systems stored in the CollisionManagerSystem and iterate over them until the CollidePointData.resolved boolean is true or iteration completes. If the source does not contain the required CollidePointData data component the collision check is immediately aborted with the NoOp extensible enum.

Each IColliderLifecycle system may provide a different collision check. In a simple 2D example the first one can collide the source entity against the world boundaries (say the 2D extents of the screen). The next IColliderLifecycle may do AABB or sphere checks between entities. Potentially in this case perhaps there is another data component stored in CollisionManagerSystem that stores intermediary entities that collided in the rough check. The final IColliderLifecycle could do a more extensive test between just the entities that collided in the previous step.

Previously before moving to iteration to handle more specific collision checks their were various CollisionSystems defined via inheritance / OOP such that there was a base implementation and the more extensive checks were defined in an inheritance hierarchy.

Obviously the great thing about iterating over collision lifecycle systems is that one can extend or even remove lifecycle systems increasing or reducing the collision checks dynamically.

Anyway, this is an example in my efforts where systems may outnumber data components for a particular use case. This patterns is used for movement, the rendering process, and in other ES lifecycle areas and beyond.

Indeed.. :) On a rough count of the data vs system components in the runtime and demos of TyphonRT the count is:
~240 for system components
~135 for data components

I’d attribute the extra system components to the pattern described above. As things go most of the “system of systems” approach is not entity related per se. Do recall I’ve generalized the ES approach into a general component architecture. I haven’t yet converted over the final two entity system areas (movement / collision detection) to iteration vs OOP super class invocation, but I don’t expect any negative affect given the current entity counts in the demos.

Regarding performance if memory recalls from the goliath ES thread I was fairly concerned on how nesting of components in a deep hierarchy vs single level as in your ES efforts will affect serialization. It would be kind of lame to have to traverse a deep component nesting hierarchy checking if each component has something to serialize each time. While I haven’t implemented the solution yet the “ACMC” AbstractComponentManagerControl feature (yeah can’t describe it again here for “brevity”! ;P Err basically it’s a special system that extends component managers that potentially executes for add/remove/set/unset operations) which I describe in the goliath ES thread is going to provide a good solution to be able when a component is added to an entity / component manager to determine if it is a serializable component thereby despite any nesting only the components that are known to be serializable are traversed.

—

Yes indeed.. The iteration method is significantly slower, but applied for the right reasons is more than fine. One can always create the OOP derived or heavyweight system component. The “system of systems” method offers extreme dynamism in exchange for a little performance.

I did run a micro-benchmark test and of course things are 25 times slower with the vanilla iteration loop compared to direct super class invocation on the desktop, but only 10 times slower on Android / G2X. I simply made an OOP structure of 5 deep with an “add” method invoked down the chain and iteration over 5 “AddSystem” components. As you probably can guess the method invocation costs are the primary culprit with the iteration angle, the map lookups aren’t horrible for the getAsIterator call. Though I tried to warm up the micro-benchmark it’s not clear if any JIT compilation kicks in, etc.

On the desktop a single instance of iteration over 5 systems vs OOP invocation (in seconds):
Iteration: 0.0000000675
OOP invocation: 0.00000000267

On Android / G2X:
Iteration: 0.0035
OOP invocation: 0.00036

Of course the cost on the desktop is negligible. On Android perhaps one must take this into consideration depending on the game. Consider Shadowgun and how few entities are actually on the screen at once. Depending on the game perhaps just the player controlled character has a dynamic collision system or if performance needs to be tuned develop the game with an iterated collision system then create an OOP based or fully integrated implementation for that particular system.

Now there are of course ways to tune anything including the iteration loop. Internally if fast addition / removal is not a goal a component manager can use ArrayLists instead of a linked list for stored collections. Loops can be unrolled. If iteration is to repeat several times consecutively the iterators in my collection API can be reset vs getting a new one when the end is reached. A rough break down is that half the time is due to the getAsIterator() call and the other half is consumed by the iterator next() and hasNext() calls. Since I have a custom collections API I’m considering adding a special next() method that returns null when the collection is at the end. IE a null check would have to be in the loop and associated break as necessary. This last change alone drops 1/4 of the time.

A huge performance win which of course makes this direction even possible is that iterators are recycled with my collections API. There is absolutely no way this would be performance oriented at all if one was creating / destroying iterators all the time.

Now whoa 10 times slower.. Well, it’s a trade off with dynamism and it may not be the best route every time. I am just experimenting with the collision system switch to iteration.

This certainly illuminates the data oriented design concerns with the trade offs of dynamism vs more static systems. One must also consider that for general particle systems are constructed in a more data oriented manner vs single entity per particle and certainly no collision detection for particles.

In the end fill rate / overdraw is always the main enemy for frame rate performance especially w/ mobile. Games w/ medium to high entity count should favor static systems. A game even as flashy as Shadowgun though would not be hurt so much per se by the dynamic approach considering a significantly lower entity count visible on screen.

Hello there. I’m a hobbyist using your articles to implement my own entity system in java. I had a question about components tho, maybe you could clear this up for me?

I know components can only hold data e.g. “int”, “String”, … and cannot contain methods. However sometimes it seems to be logical for a component to hold a class object.

I have a very concrete example. My collision detection class has static methods for calculating if polygons and circles overlap. Therefor I have 3 important classes: Polygon, Circle, Vector. Those classes hold a bit of data [ Vector.x and Vector.y for example ] and a few simple methods to do math [ Vector.add(Vector v) ]. They clearly do not contain game logic.

It seems logical to create a “Physical” component with field “shape” which holds e.g. a Polygon object.

The other way to do this I see right now is to give a “PhysicalPoly” component a list of x values and a list of y values and a center and when I run the CollisionSystem create new Polygon objects based on the data in the PhysicalPoly components I need to check and destroy them in the end. However this seems quite intensive to do each game tick.

What am I overlooking here?

On a side note: I named my (sub)systems differently by the name of “Process”. Every process has one public method “Process.run()”. The way I understand your concept of an ES that seemed like a better naming to me. E.g. I have a component “Position” and a process “Move”. So I call Move.run() on every Position component I want to move.

Another thing I did is create simple groups of entities. Instead of letting my Move process on all entities with a specific component (like a ‘Move’ component) I would let it process all entities who subscribed to the “Movable” group. So on entity creation I would add all components I want it to have and register the entity to all groups I want it to be processed in.

Here is an example of entity creation (I thought you might be interested):

// Create player
Integer player = em.createEntity();

// Add player to groups
em.addEntityToGroup(player, “PLAYER”); // Add player to group
em.addEntityToGroup(player, “MOVABLE”); // Add player to group
em.addEntityToGroup(player, “ACCEL”); // Add player to group
em.addEntityToGroup(player, “RENDERABLE”); // Add player to group

// Add components to player
Position pos = new Position(0, 0); // Create component
em.addComponent(player, pos); // Add component
Velocity vel = new Velocity();
em.addComponent(player, vel);
Accel acc = new Accel(30);
em.addComponent(player, acc);
Rendering ren = new Rendering(0);
em.addComponent(player, ren);

The problem with creating a PolygonCollidable component, for example, is that I can’t add methods to it. My collision code uses a polygon object with the method “projectAxis(Vector2d axis)”.

I’d like to seperate my collision code from the entity system. My “CollisionSystem” (or process in my implementation) should take data from the entity system, give it to a separate physics / collision engine, pull out results and create CollisionReaction components accordingly or update the data within the entity system.

What I want to avoid is to implement a set of collision algorithms that are dependent on a specific entity system component. How can I achieve this encapsulation of collision code so it doesn’t have to know the entity system or what components are?

Thank you both for your advice, it’s been very helpful to me.

I have one more question about systems and components. Currently I’m working with animations and how to handle them. I created an animation component to work with a rendering component. A generic “Animate” system simply updates the frame count in the animation component and passes rendering information to the rendering component (more specific: which rectangle on the sheet to draw).

However my question is about how to handle transitions between animations / animation states. Where would you put that logic? In one system that checks animation states and events to change a state, or diffuse over all systems? How should the states be saved? As a string in the a special component? Or as different components?

Undoubtedly my lack of experience puts me in a position where I’m not sure how to handle this while making sure to respect the Entity System Philosophy.

I noticed some one asked a similar question on one of your previous articles in the series, Adam. Oh, I just can’t seem to find it at the moment. On gamedev.stackexchange there was a similar question though. I wondered what you’d think about the answer, especially when you told us not to trust advice from that site :). http://gamedev.stackexchange.com/questions/25686/abstracting-entity- system-animation-states

You also mentioned in part 2: “The Animation system constantly looks out for anything that would trigger a new animation, or cause an existing animation to change (e.g. player changes direction mid-step), and updates the data of each affected Entity (of course, only those that actually have the Animatable Component, i.e. are animations).”

Could you help me out here and elaborate a bit on how that would work exactly? How does it “look out” for those triggers? A bunch of if-statements where we check keyboard input (while running, for example)? Where would a current animation state be stored? How would the absence / presence of a component play a role here?

Anyway, thanks for the advice you guys gave me and hopefully you’ll find the time to help me out again. It’s a learning process and I hope I’m not bothering you with boring details, I’m just trying to fit the pieces together.

@JS

I don’t see the difficulty here, can you say what the specific problem is?

If you’ve got something that plays an animation, then you already have some notion of gradually moving through an anim.

To add transitions, all you have to do is duplicate those items in your animation component, and prefix them something like “transitionTo…”, and add a 3rd framecounter, which is the “percentageOfTransitionCompleted”

On each frame, if you detect there’s a transition in progress, you take the frame in the old anim, and the frame in the new anim, and then you use the percentageOfTransition.. to morph between them (and update the percentageOfTransition… counter too).

Depending on how your anims work, you MIGHT need to keep updating the framecounters for the two anims too – e.g. if someone is “running’, and then hits “jump”, then you probably want to keep the legs moving in the source anim while you transition it to the other anim. (this works fine in 3D, where you can tween the individual bones of the legs. If you’re using 2D sprites with no bone info … it probably looks very strange / wrong)

@Adam: I apologize, it seems I am really bad at asking questions :D. I think one of the things that confused me most was a “polling” system for animation changes. By transitions I meant when an animation goes from standing idle to walking_left for example. An other thing that I was confused about was the entity system as a state machine itself. I wondered how that would be applicable here. — However after searching and searching I think I’ve been able to find most answers myself. I explain it here ( http://gamedev.stackexchange.com/questions/27079/data-driven-animation-states#comment44658_27079 ) if you’d be interested. Don’t feel obliged to check it out, though. It seems I am REALLY bad at asking questions ;).

@JS

Indeed.. I certainly came across a bit zealous on extensible enums. Though it certainly has been the solution for me in storing unrelated entity state and general enum / state sharing between code projects / modules reducing dependencies on concrete enum types between modules. Like Josh Bloch mentions in item 34 that extensible enums seem only useful for opcodes; it turns out that encoding unrelated entity state is a very similar problem. The benefit of a statically typed enum over strings and bit fields and being able to load and manipulate states via reflection and the various Class methods of Java are awesome. IE Class.getEnumConstants();

The benefit of ExtEnumSet is that you can pack it with entity state enums that are unrelated to each other, but maintain one location for storing all entity state instead of separate location / data components. All systems just need access to the single ExtEnumSet stored in the entity. Otherwise if you store state for each subsystem area specifically in it’s own component (say an animation data component) then every system that acts on those states also has to depend on all of the data components storing the various state. This can quickly void the benefit from a dependency angle of a component architecture for more complex games. There is also no way to enumerate over all these states in mass with state stored in separate components.

Also check out the item 32 & 33 of Effective Java and the EnumSet / EnumMap discussion. The phase change example can be extended / modified to encode and retrieve say animation transition states.

Now instead of polling with if conditional statements each frame consider storing additional helper systems (or just a callback interface / class type) in an EnumMap (or ExtEnumMap). IE an animation system component can store additional callbacks by transition state or perhaps just the normal entity states (run left, etc.) stored will also trigger callbacks when the EnumSet storing state is enumerated against the EnumMap storing the callbacks. I’m sure a little code example will make this clearer, but this seems like something to explore to complete an agnostic mechanism that can be loaded up in a data driven manner avoiding hard coded if conditional polling. This is at least how I will first approach a generic animation system. This basic mechanism should work for both 2D sprite sheets and bones or other 3D animation systems.

Granted if your game is simple and everything is known in advance and you don’t mind hard coding the if / conditional / polling then that certainly will be the quickest. In my efforts I’m building generic subsystems such as animation that are entirely data driven.

I don’t have an official blog yet, but will be launching one officially for my efforts at the TyphonRT link. I do post tech pontifications on G+ – https://plus.google.com/u/0/117904596907381647757/posts

@adam

I looked into bytebuffers, they are easier than I though but at the same time bring in some complexities that I’m not up to tackling right now so i’ll take a step back and try to use built in java types to create some custom system of storage work on making that fast. I am really shying away from trying to remake the wheel just for simplicity sake and avoiding bugs that I may introduce.

@Mike

Is that something that you can share? I was thinking of trying to mess with the collection API but I really don’t want to go that route, instead what I was thinking was to use two lists, one is a list of components and another is a list of entity id’s. Use the list of entity id as the rows of a table and the list of components as the columns to a table, that way I can pull out lists of components but Im not sure how well that would work, I’m still using a notepad to sketch that out right now.

@blubee

As things go I’m keeping things private for the most part until I can get the whole beast launched. I’ve actually been working on my efforts for over 9 years and it will definitely be 10 or 11 by the time things fully launch. I aim to make this a business / actual for pay platform, but with a healthy core bit open source like the JDK itself (including the component architecture & collections API). Unfortunately, I’m burdened with a day job presently and am toiling away on the weekends and nights. I’m about 4-6 months off of finishing the total framework if I could work full time on it. Pretty frustrating honestly to see the end of the tunnel, but be forced to crawl there. I’ve been working in waves full time between contracts for a while, but finally my luck ran out in big corp contract negotiation and the day job is here at least for a little while… doh… So long story short I wished I could get it out there sooner, but it is what it is…

I still recommend considering playing around with a cached iterator solution. It’s not as hard as you may think. Your question directly involves trouble with iterators of collections, so that is the pain point to work on… You only really need ArrayList / HashMap implementations at first for most cases. Start with the latest Android source code (re Apache Harmony) for ArrayList then HashMap and make just a few mods. Just add an array of iterators that is initialized when the collection is created. Make a new constructor which can specify the amount of iterators to cache. Make the current constructors default to 1. You also need to modify the iterators so that they can be “reset” after usage. This simply requires re-initializing them with the defaults that are already in the constructor via an additional reset method. Also consider passing back the iterator reference as the signature of the reset method (you’ll see why below). Further consider making a new interface that extends from Iterator, so that the reset method is exposed. Let’s call it IResetIterator, but name it whatever makes sense.

Perhaps leave the current iterator() method of the collections alone except for potentially providing a covariant return with the new iterator interface:

public IResetIterator iterator() {…} // etc

Add an iterator(boolean) method such that if it is true will pull from the cached iterators… This new iterator method looks something like this:

public IResetIterator iterator(boolean recycled)
{
if (recycled)
return iteratorCache[iterCntr++ % iterCacheSize].reset()
else
return new ResetArrayListIterator() // etc..
}

iterCntr simply provides the modulo calculation to find the index and iterCacheSize is well the size of the cache.

The above is not too much effort, but is a verifiable solution to your problem. It’s the “cheap car / Yugo” solution without frills and comes with the caveat of having to make sure you specify the correct number of iterators to cache for non-sequential access (nested for loops pulling from the same collection, etc.) otherwise you’ll be stealing iterators already in use.

This problem is a well known performance problem of Java collections and I was using the “Yugo” implementation from ’05 to this year when I replaced the solution with a “Ferrari” in my efforts, so it definitely works quite well.

—————————————————————–

Well, as to Adam’s mention of ByteBuffers I’m afraid they are not so useful. It would be one thing if one could make a byte array or ByteBuffer to an Object in a C / C++ struct like manner, but you can’t efficiently at the core language level at least in Java. If one was going to try and pack data into a byte array for data access and dealing with the serialization aspects a plain old byte array or even long array is better than a ByteBuffer due method invocation overhead especially on Android. For the most part things should be cleaned up with Android, but early on there were many slow downs with ByteBuffers on Android due to the non-performance implementation provided by Apache Harmony.

Sans byte array mapping like C/C++ I’m afraid we must still deal with concrete objects in Java as our component / data storage and the Collections API. This is OK though because just splitting data from system components is a big step forward IMHO. I also believe that having bare data classes / components that just define data fields provide a very long lived data declaration format that can be easily tracked over time / versions. It can also be programmatically introspected regarding reflection and all that jazz.

@blubee
“With that being said, I just finished a implementation. It’s looking pretty good so far. I’ll see how i feel about it after 3 more days.”

Cool… Let us know how it goes.. :) Once you get rid of GC churn the entity system / component oriented approach is pretty neat.

“I really don’t want to get that deep messing with the built in classes. I believe the java engineers are more proficient at designing data structures.”

They are not game developers for the most part and more often than not I don’t think performance for Java through its development has been thought about from the client side of things as opposed to the server side at least in general.

At some point you should get used to poking around in the Oracle JDK source code. At the same time it’s even more important to poke around in the Android SDK source code because it is based on Apache Harmony which is not all written by knowledgable engineers especially when it comes to performance and GC churn.

As things go there are a lot of legacy matters to consider with Java and performance. The Collections API implementation absolutely needs attention for near real time use and this has been the case on the desktop all along and most definitely on Android as Google is more interested in adding new features than fixing core performance problems or at least they only haphazardly assign engineers to look at things after enough outcry and even then don’t always fully address the problem (usually regarding Apache Harmony matters). It’s gotten better release over release, but this kind of peck and chose situation is what makes Android a bitch considering “real fragmentation”.

Other legacy ways of doing things like say serialization by the Serializable interface are not best practices and have been around for ages (’97 in the case of Serializable). Even a well known Java engineer, Josh Bloch who created the Collections API, says stuff like default serialization on Java is morally bankrupt.

An interesting article interviewing Bloch…
http://www.artima.com/intv/blochP.html

“In truth, you always do a bit of both. Programming is an iterative process. You try to do the best you can up front, but you don’t really know whether you have the API right until you use it. Nobody gets it right the first time, even if they have years of experience. Doug Lea [author of Concurrent Programming in Java] and I chat about this issue from time to time. We write stuff together, and, when we try to use it, things don’t always work. In retrospect, we make obvious API design mistakes.”

Everyone is potentially fallible when API design proceeds complete usage analysis.

A good video:
http://www.parleys.com/#st=5&id=2804&sl=1

Despite a lengthy process I have no regrets in not releasing my core API work early (as per conventional wisdom) until I am absolutely sure advanced entity system / component usage is 100% together from a performance and ease of use angle. This takes a bit longer as I’m working through extensive middleware creation spanning Oracle JDK & Android SDK on top of the core component architecture / entity system API all the way through full high performance game examples.

There are still major Java 5 language features like annotations that are highly impaired on Android due to Google’s inattention to fixing piss poor implementations in Apache Harmony / Android SDK. It helps to examine the source then understand how it can be worked around.

Just the other day I got my tail handed to me when I tuned a particular new change in my component architecture based on my knowledge of the Oracle JDK and the Android SDK happened to be nonconformant. This is the case of enum hash codes (Enum.java) whereby in the Oracle JDK nothing is done and the identity hash code is returned, but in Android due to Apache Harmony silliness the hash code of the name of the enum is return breaking the contract. I tried stuffing Class (.class) and enums into one data structure expecting things to be safe due to both supposedly having identity based hash codes and got clashes on Android that didn’t occur on the Oracle JDK, etc. I knew exactly where to look and luckily proceeded to confirming suspicions in Enum.java on both platforms and then had to switch to my version of IdentityHashMap. (An aside IdentityHashMap is horribly implemented in Apache Harmony / Android; lots of internal GC churn).

In short.. ;P It’s extremely helpful to look under the hood and while one is working solo or in a controlled state before wide release (considering APIs) adopting a fearless programming approach leads to great things; nothing is safe or off the table including Oracle JDK and / or Android SDK code.

@Adam
@Mike

Check it out, I really wanna get your feedback : http://www.teamblubee.com/2012/11/04/changing-the-game-reorganize-your-game-objects/

Hey!

I had a quick question about how you do things in terms of systems communicating with eachother, or handling inter-entity relationships? For example collision detection, where you need to check entities with each other (though in this case you can use the same system’s entity list to iterate through), or a bit tougher, a shooting system.

At first I thought I could use the same list, but not all entities carry guns but might still be hit by a bullet…so I somehow need to have a clean way of making the system’s interact. Is it as simple as just passing a reference of the bullet system to the gun system, and the gun system pushes bullet objects directly to the bullet system?

My whole mind boggle is probably over the question of are bullets entities? They could be, in the case of grenades, but I still just don’t know how to handle a grenade blast with surrounding entities that could be walls or other moving entities etc. etc.

I hope you have the time to shoot back a reply! I’m new to ES’s, and reading your blog has brought many insights! :)

P.

Good luck piecing together all of the responses on the blog posts.. ;P Here are my thoughts with perhaps some new ones based on my efforts this year.

@P Svilans
>how you do things in terms of systems communicating with eachother, or handling inter-entity relationships?

Depends on context. I switched to an event bus mechanism vs the old OOP entrenched listener / observable pattern which was the last highly OOP thing to go from my conversion to ES / COP (component oriented programming). In my efforts the event bus is a system component and there can be various ones scoped at say the application level, but since it is a system component consider an event bus for a particular section of a level.

One cool thing with my event bus system is that the source of an event needs to be a component, but it can also be an extensible enum component, so one can create extensible enums for the section IDs and entities can listen to all or specific events from a particular section ID. The movement system is responsible for changing entities section ID and potentially registering with the section event bus. Entities don’t necessarily register between themselves though it is quite possible since an event bus is a system therefore an entity can be given an event bus system too, but the idea is to have a separate event bus system per logical boundary / section of the game world.

Collision detection can be a little context dependent. If there are event buses for sections of a level the collision detection system can post to them. In other cases sometimes you directly access entities. I break up collision response / resolution into a separate runtime logic system that way it can be handled as appropriate for the game at hand.

>My whole mind boggle is probably over the question of are bullets entities?

Bullets are entities…

>how to handle a grenade blast with surrounding entities that could be walls or other moving entities

As always there are many solutions. An ES oriented one may be something like firing an event on the section event bus whose source is an area effect extensible enum w/ the grenade data components. Events happen to be component managers in my efforts, so they can take adhoc component additions. Entities are also “system” components in my efforts, one could just as easily attach and entity in whole making it actionable by any receiver. There could be an area effect system that listens on the event bus for area effect events that would then deal out the damage upon a further query (radius, etc.) of all entities in a particular section. Depending on the game consider a section like something as simple as a room or it could be a certain level of an octree, etc.

@P Svivans

>”I’ll reread what you wrote several times, but when you say “Events happen to be Component Managers, so they can take adhoc component additions”, could you explain that a bit more?”

This is the somewhat tricky thing when it comes to discussing ES on Adam’s blog as his reference implementation is different from my ES implementation. I generalized the component oriented API such that it can be used for an ES proper or in any other context. A big difference too is that I store the components directly in the container / entity vs a global storage location.

An event in my system simply extends “ComponentManager” and therefore it can accept components. Say the collision system could attach a data component that stores info on the collision variables (normal, force, etc.) The event itself is generic and not a specific “CollisionEvent” instance / object.

>”For events, does an EventComponent let’s say on an entity dispatch an event (flags itself), and that then gets picked up by an EventSystem? Or are the events dispatched between Systems ( 2 systems have access to an EventSystem that holds and queues all events).”

Your latter comment that systems (IE the logic / control flow) fire events is correct. This could be the collision / resolution system or any other system component.

In my efforts I also have a generic RuntimeSystem that is extended and can get called every frame. My entity manager also has a RuntimeSystem that coordinates movement / collision / any AI per frame in addition to triggering any RuntimeSystem components stored in entities per frame. These various systems just need to have access to a global EventSystem or whatever context specific EventSystem is current (say one for an area of a game level). The nice thing about the event bus mechanism is that all public / subscribe activities flow through one system vs a patchwork of listener callbacks (the traditional OOP way).

The event bus mechanism isn’t specifically a component oriented solution. I’ve adapted it for such use though. The use of extensible enums as a possibility for sources of events is great because there is no concrete per source instance. In my ES efforts each entity has an extensible enum component stored that acts like a type marker. You could have a system that can fire events based on this type and any subscribers to the event bus can register to receive all events from that entity type. There is no direct connection between an interested system and specific entity instances.

Compared to the Google Guava event bus mechanism there are many more levels of distribution available in my efforts. The Guava event bus simply sends all events dispatched to all subscribers to that particular event bus. My implementation allows scope, source, and type data to direct the dispatch of events to various lists of subscribers from one event bus.

This is also a Java specific implementation. The event bus direction seems like the next best step to take over the traditional listener implementation, but in other languages there are other solutions to examine too.

@Tom…

Ah… What follows is just a minor kerfuffle of sorts over the words “standard”, “definition”, & “implementation” being combined..

‘”…”‘ == ironic quotes.. ;P

I am curious as always… ‘”standard definition”‘? Who made what standard again? There isn’t a standard _implementation_ for ES. At least w/ Java there are a handful of basic reference implementations without thorough use cases (a lot of code based on a given API). I’m lucky to have a 175k SLOC highly modular code base running on top of my efforts w/ a basic 3D FPS game example as a use case and this has definitely informed performance and scalability concerns through providing the depth to make reasonable changes to the ‘”standard definition”‘. In my case things went down more like a parallel evolution.

There are however shared characteristics.. At the highest level that is focusing on the implicit has-a relationship. If there is only one standard in defining what constitutes an ES or component oriented API it is the focus on the implicit has-a relationship. That bar none is the only standard definition IMHO. The details on how one goes about this are far from standard and are implementation concerns. I happened to expound on the implicit has-a relationship and created a generic runtime API that embodies this relationship as a superset of my ES implementation, _because that idea is good_ and worth being promoted; IE not based on who wrote which blog post first.

I did after all mention that there are implementation differences in my efforts that could cause a little confusion if one hasn’t followed all the posts; even then.. :) I post here to suss things out publicly and float new ideas. It’s not like there is a whole lot of chatter around on ES and there is a whole lot opposition in some circles that I used to haunt more which I find rather sad… (JGO / javagaming.org)

Since this is a general discussion (for what it’s worth)… May I ask do you have any concerns with the event bus direction for passing events? It applies to ES just as well and I’m here to say it works extremely well and with some additional tweaks over Google Guava’s ‘”non-standard”‘ implementation is really powerful.

As things go certain questions like P Svilans lie too closely on the implementation details side of things… I provided my recent insights on the matter and what has worked for me.

I am interested to hear you share how you pass events in your ES efforts…

@Tom… Thanks for the link to Darren’s blog which I’ll be following as well.

While in the linked article Tom drops JMS and talks about distributed event systems a bit the event bus pattern (also known as the message bus or publish / subscribe pattern) is an in process / in JVM pattern for event distribution. It is also receiving adoption in the general Java community as being a superior publish / subscribe mechanism over the traditional OOP direct interface / listener approach where event tracking and distribution (storage + logic) is mixed in directly with heavyweight objects. Searching “event bus pattern” you’ll come across plenty of info.

The majority of my efforts and what is different w/ my event bus implementation is that I don’t use annotations or inheritance hierarchies of discrete events to direct and aid subsequent distribution. An example of an event inheritance based implementation is Google Guava’s event bus. I view it as moving in the right direction, but still w/ a foothold / entanglement in an inheritance bound implementation. Thus a majority of current event bus implementations are still bound by a more OOP related association. A big reason to avoid Java annotations in my implementation is the Android use case where unfortunately annotation support with all OS versions and to some extent reflection based inspection is extremely inefficient in a near real time context; a hold over from Apache Harmony as things go. This is why I break things out with explicit scope, category, source, and type parameters w/ any of these levels being able to be equally defined by extensible enums or discrete object / component instances; the former being the preferred route. Distribution can still be wild carded at each of those levels to deliver events to more than one concrete subscriber list.

The big boon to this approach is that distribution of events is separated from publishers and subscribers being mediated through one system component vs a patchwork of direct in process distribution. Also only system components should be publishers / subscribers. There are many benefits to this including being able to have one location where the connection of publishers / subscribers can be acted upon in bulk. I would also point out that an optimized event bus is much more data oriented vs the traditional OOP mechanism of combining event distribution in a concrete object along with other data / logic as a heavyweight abstraction.

In my efforts things are even more data oriented since event containers are generic and can be pulled from a global recycler system and once delivered are returned to the recycler system automatically therefore there are only as many generic event containers created as total synchronous events being delivered during runtime. This essentially connotes / describes a “high level data oriented design” pattern of which I respectively realize is not well used terminology yet either, but central to the architecture that I am finishing presently.

More or less distributed event / message bus systems like JMS have been around in the enterprise world for a bit, but uptake of the in process event bus pattern has been gaining ground for around 3-4 years, but the tipping point seemingly has been reached where it’s a fairly common pattern to drop in conversation like other tried a true design patterns.

>”One of the problems I have reading your frequent lengthy comments here is your use of vocabulary – not just that you use different terms than our host.”

Fair enough… :) This is why I’m posting here as to establish common vocabulary and test the terminology I am stringing together to describe my efforts. There isn’t too much common terminology yet for ES architectures. For that matter I think even using ESA to define explicitly the ES Architecture (IE the component oriented approach) is more handy over ES since entity systems can be built w/ other methodologies including failed ones like OOP for non-trivial / generic use cases. I suppose it doesn’t help that posts can’t be edited on this blog when little mistakes enter into posts like when I wrote “public / subscribe” above instead of “publish / subscribe”…

I’ll yap on about extensible enums and extensible enum components as being a panacea for opening up modular, data, & component oriented design patterns, but if you read the literature out there even Josh Bloch stops short of discussing expansions on the concept… See Effective Java item 34; not the whole content, but a link:
http://books.google.com/books?id=ka2VUBqHiWkC&pg=PA165&lpg=PA165&dq=josh+bloch+extensible+enums

I’m still codifying and trying to come up with explicit terminology for new architecture approaches I’m adopting.

Another post Darren makes I like:
http://onlinegametechniques.blogspot.co.uk/2012/05/essential-components-of-new-framework.html

In particular this statement:

“Done well, the Entity System can be used for more than just visible game objects, but could support administrative and configuration objects as well.”

This hits the nail directly on the head when I describe my component architecture implementation as being a superset to my ESA implementation. The methodology is useful for everything architecture wide and not explicitly just an entity system. My initial component oriented API work started internally to my ES then it became obvious that it was a powerful technique to generalize architecture wide.

Some helpful links that point to other event bus implementations and discussion are the following:
http://code.google.com/p/guava-libraries/wiki/EventBusExplained
http://codingjunkie.net/guava-eventbus/
http://eventbus.org/
http://code.google.com/p/simpleeventbus/
http://square.github.com/otto/
http://bwinterberg.blogspot.com/2009/05/eventbus-library.html
http://martinfowler.com/eaaDev/EventCollaboration.html (older description)

I know this is an older topic, but I’ve only recently ventured into the entity systems domain. I’ve looked at the beta code for the Entity System RDBMS but the one concept I see missing is the RDBMS. The data of course is structured in a way that would easily fit into the RDBMS, but the Entity Manager is built specifically to only create new entities.

So I’m curious, with the code structured the way it is, where would the data persistence go? I have some ideas of options of how I could do it, but I’m curious what was the design decision when creating the Entity Manager like it is now, or others experiences with persisting databases and how they communicate with components. For example, put saving and loading code in component, in a db manager, in the entity manager, etc.

I keep seeing this entity system lauded as the latest, greatest thing. I’m pretty sure this has been around forever, except an entity was called a client, and the system was called a server. How exactly does this differ from the client/server model?

Hi Adam,

Full Disclosure: I have no game programming experience, but lots of Business App Programming experience.

I am attempting to make a really simple game (Asteroids Clone) using an Entity System as the backbone. I have been reading your posts 1 -5 (over and over again) and checking out the other implementations on the wikidot site.

I suppose what I want to ask is how one would go about designing components, systems and how they relate to each other. Is there a design process you follow when thinking about them, certain questions you ask yourself about each aspect of the game? Im finding my lack of game dev experience has left me uncertain about how to structure the components and systems..

also one other question that will hopefully be much easier to answer. During my many attempts at designing component/system relationship, I had a system that was simply syncing data between certain (like two) components. Is the idea of a component sync system a bad idea?

Thanks for the time

_L