Thanks to Mike Leahy for spotting this:
http://blog.gemserk.com/2012/02/02/how-we-use-box2d-with-artemis/
…a short blog post (with code) on how a team is integrating Box2D (a very well known open source physics lib) with Artemis (a java implementation of Entity Systems which starts from the same point as my Entity Systems posts, but fleshes it out)
2 replies on “Entity Systems: integrating Box2D with Artemis”
For sure… Here is the particular post I was referring to in the other ES thread regarding the relative difficulty of recycling components when one combines an ES or in general a component architecture with a heavily OOP based framework like libgdx or really any OOP bound API / framework. I think this is definitely going to be a case to discuss as none of the publicly available Java based ES efforts do so yet; I’m taking a solid stab at it, but is also a reason why I’m still working on my efforts vs a public release. Good to see the Gemserk folks making their Artemis mods publicly available though!
http://blog.gemserk.com/2012/01/03/reusing-artemis-entities-by-enabling-disabling-and-storing-them/
Pretty much any 3rd party library one has to be mindful of how data/system components aggregate OOP bound objects including say the Android SDK which has provided its many “bundles of joy” to untangle. IMHO the majority of the Android SDK is hastily created, already shows the general failures of OOP, and real trouble spots w/ some underlying Harmony implementation _still_ plagues Android 3.5+ years on even w/ ICS – Google is more interested in adding new features _still_ instead of shoring up the bases and reducing technical debt instead of piling it on… (uh oh did I just go on another Android rant; love it). If you are lucky the objects are not just bound by DI or constructor injection; IE they are more POJO in nature and / or have getters / setters so that when an aggregate component is recycled these explicitly composed objects can be set with fresh data.
The Gemserk folks sort of cheat by simply disabling unused entities in their aggregated state and enabling them again when they are needed. This certainly works, but unfortunately is not much of an improvement over a heavyweight object pool.
As Mike said, our solution is a bit of a hack/cheat, it works well for games where the objects are well defined and don’t change in runtime, otherwise it starts having problems since you can’t store all the different possibilities for the aggregated objects, or at least our current solution don’t support that really well, maybe we could adapt ourselves to support that even if we store aggregated objects.
In our current framework, we have the concept of EntityTemplate which is used to set components and values when the entity is created. For example, we could have the OrcTemplate which creates a PositionComponent, MovementComponent and RenderableComponent when it is applied to an entity. EntityTemplates support parameters, so you can customize an entity applying the same template with different parameters.
This approach of applying templates is great (or at least I like it), but when working with stores it is not clear what to use to identify the aggregated object. We started by using the templates as the identifier, but the problem is that different parameters when applying a template means different data on the components of the entity. Also, we allow applying multiple templates to the same entity, so in the end they can’t be stored as the same entity and can’t be reused as the same entity. So our current problem is to easy identify a template+parameters, and in the case the we use too customizable templates then we start to store tons of different aggregated entities with small differences between them.
I believe a better solution could be to be more modular in what to store as Mike suggested in our blog, but we have that not so clear yet so we didn’t try it yet.
Thanks both for referring our blog.