Adam Martin's entity system series

[CaptainJester]

Adam has a new article out in his entity system series.  This one provides some concrete code and he did on Android.

http://t-machine.org/index.php/2010/05/09/entity-system-1-javaandroid/

[Roquen]

I commented on performance issues which such systems in another thread.

"...  so I had to make some substantial performance improvements, and now it’s happily rendering 300 things all flying around at 20-30 FPS"

Android or not, really, need I say more than the author?

[appel]

I commented on performance issues which such systems in another thread.

"...  so I had to make some substantial performance improvements, and now it’s happily rendering 300 things all flying around at 20-30 FPS"

Android or not, really, need I say more than the author?

So, because it runs at 20-30 fps on an android phone, it must be a inherently slow design? I don't agree with that assessment.

Games published by our own members! Check 'em out!

[CaptainJester]

I commented on performance issues which such systems in another thread.

"...  so I had to make some substantial performance improvements, and now it’s happily rendering 300 things all flying around at 20-30 FPS"

Android or not, really, need I say more than the author?

Notice he said the Java implementation on Android has serious performance problems.  The standard Java implementation would have no problem with this.

[Roquen]

So, because it runs at 20-30 fps on an android phone, it must be a inherently slow design?

Short answer: No, but it's a strong indication.  300 active entities is ridiculously small set.

Med. answer:
1) Expanded memory requirements (vastly if components are fine grain)
2) Increased pointer traversal
3) Dictionary lookup per component
4) No control over memory layout = no access pattern can be cache oblivious

= explosion of cache misses, in addition to extra code complexity.

1   2   3   4   5

Entity e = entitySystem.get(globalId);   e.getAs(Position.class).x = 5;   e.getAs(Damage.class).hitpoints = 145;   e.getAs(Renderable.class).foregroundColour = Color.red;

7 dictionary look-ups and something like 7 cache misses (on average) if this is in a tight loop...I'm too lazy to figure the upper bound.

Notice he said the Java implementation on Android has serious performance problems.  The standard Java implementation would have no problem with this.

Relatively, I'd expect to the impact to be larger on JIT Java-a-likes.  Interp will tend to hide the cost of cache misses.

[lhkbob]

I've implemented an entity system myself that uses array accesses to look up the components on an entity.  Indices within the system to perform iteration over entities with specific component types are also maintained.  Together these things are performant enough for me to render 10000+ things at about the same framerates I used to on an older engine that didn't use entities (and combined everything together).  It tends to be 1-3 ms slower but that may also be changes in rendering.

Either way, the point is that entity systems can be faster than what he presented.  I also believe he strongly recommended using something other than a plain Map for the storage.

[princec]

I can't quite see the use of this system over fairly ordinary composition and visitor patterns, which is fast as hell and totally memory efficient...? I mean, just how complex do we imagine game entities actually are?

Cas

[appel]

Yes, using Map to lookup components in each iteration is a bad way to go IMO. I can't see how each of the system can keep references that each component needs, it will always have to look it up in the map for the entity. There has to be more knowledge in the components than just pure data, as adam suggests, e.g. references to other objects at least.

In my "entity system" each component has a initialize method. In it I resolve all dependencies that the component needs, so when it's updated I don't need to ask the map.