I am developing a game together with Appel, and we are using it together with LibGDX. We are both updating Apollo, so it is not completely mature, more things needs to be done, and API refactoring is happening, but I assume that you are free to use it at your own risk . Not much of documentation or help is available though, but it is a bit "lighter" than Artemis, so it shouldn't be too bad if you already have studied that.

I work at the same company as Appel and we often have game dev discussions during coffee break. I have basically had most objections towards entity systems as has been mentioned here, when we were talking about Artemis (or entity systems in general), and I think that Apollo is a more appealing lib (no XML, less boilerplate, and simpler structure).

I can see Princecs point of view and where he is coming from, and I wouldn't use Entity systems in all games, but I think it is a nice tool when if fits. An RTS that isn't trivial, should be a pretty good fit. It is however a learning-curve to get through and you might not even write less code, but it in my opinion it will be easier to have it well organized. Loosely coupled code as it should end up being, could on the other hand be a bit tricky to get into for a new person if you are not used to it, so that is also something to think about.

Performance... I would imagine that it is a bit of a cost connected with using Apollo, but I doubt it is relevant. I just tested the game we are developing, and ran it with 2000 active enemy units on screen (1920x1080). It ran at ~1000FPS, so if you are in that range, you shouldn't have big problems.

I would suggest having a look at Apollo. It is not that big, so it should be easy enough to get a feel for it.

Ah, interesting. The approach used by Apollo is much more familiar to me. I did however have some problems with a similar system in the past... Component.getComponent(class) causes lots of weird dependencies that I think kind of kills the dynamic properties of a component system (I had a similar one). The performance cost of using Apollo (and probably Artemis too) is not really relevant. They both seem pretty fast.In the end I think I'll try out Artemis in an actual game, and if it doesn't work out or I suspect/realize that Apollo can do the same job but better or easier, I'll make my decision then. =S No matter which one I chose, it's free experience points anyway. xD

EDIT: Oh, right. I'm thinking of only using an entity system for dynamic units. Moving worker units, spell casters and turrets would be handled by Artemis/Apollo. Bullets and decorations will be handled differently as they are so simple and stupid. Is that "okay"?

EDIT: Oh, right. I'm thinking of only using an entity system for dynamic units. Moving worker units, spell casters and turrets would be handled by Artemis/Apollo. Bullets and decorations will be handled differently as they are so simple and stupid. Is that "okay"?

But what about when you want homing missile. You have tracking component and moving component but your simple and stupid bullets do not learn any new tricks so you need code everything again or use horrible clue code every where.

All missiles will be homing, either on a unit or a ground point, so that isn't a problem. Hehe. I could just use 2 Worlds if I want to have it that way, one for units and one for missiles, but I think that would introduce more problems than it solves...

There seems to be a level of confusion about the whole point of component based, which I can understand consider some of the misleading "tutorials". They do not increase flexibility, readability or maintainability. In general they are inferior to other solutions in these respects. The whole point is data segregation purely for optimization purposes (usually, but not always speed). The thing to remember here is that addressing data-flow issues (where in this case code is also considered data) is a pretty advanced topic and is best avoided by n00bs to intermediate programmers. This isn't intended as a slam against anyone..so-called expert programmers frequently get it horribly wrong. This is one of the big reasons that CPU vendors started to favor the more complex circuits of advanced branch prediction and the like instead of programmer controlled hints, delay slots, etc. And the behavior of branching in linear code is a hugely easier problem than what we're talking about here. Getting real gains in a component based system is difficult enough in a language like C/C++. Tie in the fact that java isn't well suited to the problem makes thing much worse. Note that this isn't just due to the (native) lack of getting linear memory chunks, but also missing various types of memory fences, cache loading hint and temporal load/stores. None of these are show stoppers, but remember you have to offset (and beat) the added complexity by lower the following:

cache misses (walking linear memory, separation of data which is not accessed together)

cache trashing (separation of data which is accessed by two or more CPUs with at least one writing)

If you're not attempting to address one of the above (or similar) concerns, then this is really the wrong solution for you. If you like the model of component based, but don't care about the above, then what you "really" want is a prototype based system, so simply code your entity system in something like javascript or lua. For most people that have zero experience with building entity systems it's really hard to beat a nice simple data driven model.

(sigh. Another edit)

Note that it is always possible to perform a hybrid solution if you know that you have data flow issues with a particular sub-set of entity data. Also note that I'm not commenting on the quality of either Apollo nor Artemis, neither of which I've looked at.

From a lot of tutorials and examples, I get the impression that a lot of components systems are designed to get away from C++ OO in particular. Even the Data Orientated Designs seems more of a reaction against the ugliness of C++ multi threaded OO.

Also I notice that a lot of the discussions seem to do the either OO or Components or Data bla bla....

I really don't see one approach as a anything special. Just suited to different problems, and throwing out OO seems like a baby bathwater thing.

My current game (it is *not* an engine) uses a shallow Entity Class hierarchy with very generic subclasses. Like 2d entity. Data determines what it is (tank, car, boat etc) not the class type. Then i have Operators (these are classes as proxies for functions as first class citizens) that operate on the data each game step and i use double dispatch. The Base entity class deals with the communications (I am using message passing) and that pretty much deals with the bulk of the core work with simple things getting communicated to the subclass state.

So far its working pretty well.

I have no special talents. I am only passionately curious.--Albert Einstein

The optimization issue is only one facet of component-based systems -- note the more generic term and not "entity systems". Any experienced programmer will tell you composition beats inheritance, and in a component system, composition is pretty much all you get. In fact, if you go by what inheritance is really for, it's like saying a cordless drill beats a hammer: they're made for different purposes. Subclasses are supposed to be substitutable, and aren't supposed to break any assumptions made by the parent class. Any change the subclass makes under the substitution model has to be completely invisible to the outside. Adding entirely new functionality isn't completely forbidden, but since it has to fall outside the contract made by the superclass, it doesn't really buy you anything that you dont get with composition anyway.

As for prototype models, the trait-based model used by languages like Self is very component-like, but having used a few less capable prototype models before, anything that doesn't give you that kind of mixin power almost inevitably results in deeper and worse inheritance hierarchies than your average class/instance model.

It's not "Components vs OO" -- composition is an embrace of OO principles, not a counter to it. There are certainly alternative approaches that aren't in the least bit OO, but trying to use them in Java or even C++ seems mighty silly indeed.

There seems to be a level of confusion about the whole point of component based, which I can understand consider some of the misleading "tutorials". They do not increase flexibility, readability or maintainability. In general they are inferior to other solutions in these respects. The whole point is data segregation purely for optimization purposes (usually, but not always speed). The thing to remember here is that addressing data-flow issues (where in this case code is also considered data) is a pretty advanced topic and is best avoided by n00bs to intermediate programmers. This isn't intended as a slam against anyone..so-called expert programmers frequently get it horribly wrong. This is one of the big reasons that CPU vendors started to favor the more complex circuits of advanced branch prediction and the like instead of programmer controlled hints, delay slots, etc. And the behavior of branching in linear code is a hugely easier problem than what we're talking about here. Getting real gains in a component based system is difficult enough in a language like C/C++. Tie in the fact that java isn't well suited to the problem makes thing much worse. Note that this isn't just due to the (native) lack of getting linear memory chunks, but also missing various types of memory fences, cache loading hint and temporal load/stores. None of these are show stoppers, but remember you have to offset (and beat) the added complexity by lower the following:

cache misses (walking linear memory, separation of data which is not accessed together)

cache trashing (separation of data which is accessed by two or more CPUs with at least one writing)

If you're not attempting to address one of the above (or similar) concerns, then this is really the wrong solution for you. If you like the model of component based, but don't care about the above, then what you "really" want is a prototype based system, so simply code your entity system in something like javascript or lua. For most people that have zero experience with building entity systems it's really hard to beat a nice simple data driven model.

(sigh. Another edit)

Note that it is always possible to perform a hybrid solution if you know that you have data flow issues with a particular sub-set of entity data. Also note that I'm not commenting on the quality of either Apollo nor Artemis, neither of which I've looked at.

After reading the Wikipedia article on prototype-based programming, I realized that that would be kind of fitting. As I'm making a RTS game, I will have several units of each unit type, so I will need some way of creating these units. I haven't really tackled that problem yet though. With prototyping I could construct a prototype of each unit type when loading the game and then just clone it when I need a new unit, right? You also mentioned creating the prototypes using a scripting language. How would that be done? By stitching together components? How do I specify the logic? In a script? Wouldn't that be very bad for performance, having a huge part of the game as scripts? I don't have any experience with this... >_< And how would a hybrid solution look like?

I've realized that asking for the best game object system of all time is kind of stupid, so I'll try to list some of the features I want so you can better see what I want to accomplish: - Every unit has a list of its stats, which contains only the needed ones for each unit. - Some units can move, some cannot. - Attacking, either melee or at range with projectiles. - A few units are spellcasters and have mana or energy or something. They also have 1 or more spells to cast. - Passive abilities and auras affecting nearby units. - Living units have a Warhammer 40k-like morale. Units and abilities can do "morale damage". Proximity to "scary" (a stat) enemies damages morale too.

Quite similar to Warcraft 3, now that I think about it. o_O All of the above (except stats) are optional things that all unit types don't have. For example spellcaster may be able to cast spells, but unable to attack "normally". The large number of combinations lead me to wanting to use components to build them up.

The optimization issue is only one facet of component-based systems -- note the more generic term and not "entity systems". Any experienced programmer will tell you composition beats inheritance, and in a component system, composition is pretty much all you get. In fact, if you go by what inheritance is really for, it's like saying a cordless drill beats a hammer: they're made for different purposes. Subclasses are supposed to be substitutable, and aren't supposed to break any assumptions made by the parent class. Any change the subclass makes under the substitution model has to be completely invisible to the outside. Adding entirely new functionality isn't completely forbidden, but since it has to fall outside the contract made by the superclass, it doesn't really buy you anything that you dont get with composition anyway.

As for prototype models, the trait-based model used by languages like Self is very component-like, but having used a few less capable prototype models before, anything that doesn't give you that kind of mixin power almost inevitably results in deeper and worse inheritance hierarchies than your average class/instance model.

It's not "Components vs OO" -- composition is an embrace of OO principles, not a counter to it. There are certainly alternative approaches that aren't in the least bit OO, but trying to use them in Java or even C++ seems mighty silly indeed.

That inheritance vs composition argument is only really true when you've got a language that actually supports it, unlike Java

Cas

I think I'm only getting deeper and deeper in braincrap here.

Composing stuff's fine if you don't then have to write loads of boilerplate to glue it all together. In C++ you can use multiple inheritance of base classes, which is a nice feature but C++ manages to make it rather fiddly and hard. In Java all you're allowed is interfaces, which means creating lots of little objects implementing the interfaces and then loads of annoying delegate methods to all the instances. It's such a mess it makes a mockery of the whole idea that it's supposed to be a better solution.

The only stitching I will have to do is for the AI. Basically going through a priority list of things that can be done and matching things with the available behaviors (= components). It'll only be an if(getComponent(x) != null) thing for a like 5 different things, so it should be fine. Everything else should be very easy to get done and be clear and nice...

EDIT: So I lightly started working on it, but had to start with actually creating units. I have to keep a prototype or a factory for each unit type, and a prototype or factory for each component. Keeping a whole prototype seemed kind of weird as my Stat class has some empty ArrayLists for modifiers, also a list of parents that would be invalid for a copy, cached values, e.t.c. so I think a component factory interface would be the most appropriate solution to creating components for objects. Creating an object would simply be creating an entity and calling each component factory to create their respective components. Does this seem like a good idea? I think it's much simpler than what I had before in my earlier projects.

Inasmuch as it's possible to create a game using it, sure. From what I've seen of java entity systems, I personally think they're ovengineered in all the wrong places and underengineered where they need it. I'm not sure there even can be a particularly elegant solution as composition-based solutions go in Java, but building an untyped relational database into the runtime doesn't strike me as the way to go about it.

I just felt like jumping in the conversation since I've been watching this for a while now:Why would you want to use a 3rd party component-based system and get restricted by it? You could just build your own personalized one and live happily ever after.

I've tried. Projects were killed. If I can use Artemis to get a better view of the problem, even if it doesn't work out I've tried something new and hopefully learned from it. In the end I aim at being able to make a good system myself, either for this game or my next. xd We'll see how it goes...

Artemis and Apollo aren't exactly big enough that they're going to put a straitjacket on your design. You could hack them them into completely different shapes in a day or two. They're a template for a design, not a framework.

I wouldn't mind seeing Google Guice used as a component system. It seems to be powerful enough to use in a lot of different ways, but lightweight enough (in both footprint and lack of global policy) to be acceptable for games.

Just a thought like that. Appel once tell me that he stopped using Artemis because it felt too restrictive and it was imposing on the coder to do things in a certain way while it would be better to do it otherwise (or easier).

Last time I check he was developing a new Entity system called Appolon.

Any way, can you sort your Entity in the data structure that you want with Artemis because if you can't your performance will be crap

Well, I haven't really stopped using it I've just been rather busy to actually do something proper with it, and it seems people in general like it.I was/am working on another entity framework which was more traditional, called Apollo. I'm already working on a few games using it and so far it's pretty productive. It's nothing releasable yet, as It's more oriented towards a specific game library currently, and 2D. Artemis and Apollo don't really compete with each other, they are different frameworks for different reasons and goals. You can do all the things you want in either, but differently.Artemis was fun to make, is a fun design, and I will definitely do something more with it later.

Measuring performance of Artemis by running million entities in a loop isn't really an accurate test. You have to consider what are the main performance hits in games (in the context of this discussion). When you have a lot going on in your game, hundreds and perhaps thousands of entities being created and destroyed every second, that's when you'll start go crazy over performance bottlenecks in your design.That's where Artemis is GREAT. So, instead of just iterating over million elements in an array, try adding, removing, all while having the entities (and components) organized in such a way it makes sense and is super fast to actually use them.In Artemis you can look up a component of any entity with virtually no performance hit, anytime and anywhere.

Artemis isn't just a data storage for your entities. ArrayList would have been enough if that was the case.

Overkill or not. Well... I think the most important thing here is if it helps you get your game going. I think having a consistent framework, from one game project to the next, is pretty good. You can easily resuse code from your previous projects. At least it will give you a fresh perspective.

I really like the concept of separating data and logic in Artemis. For me it's much easier to handle it, but I guess that for someone reading my code, it would be a little bit harder as they'd have to jump between components and systems to be able understand the flow and logic of it all.I just finished the basics of my unit factory, which is basically just a list of ComponentCreators (probably a bad name >_>) which can create a component each. I can then create multiple units of the same unit type with just a single line of code. I will in the actual game set up unit factories from some kind of external script or config file for each unit type. Everything is very straightforward, and every component is a clear distinct part without any dependencies, which is a goddamn miracle compared to my old attempts. Tying together things with EntitySystems in the end is just plain FUN. I can't remember programming being this fun for quite some time! I don't know, maybe I'm digging my own grave here, but I'm having fun doing it at least! xD

Sorry for the double post, but I just wanted to say "AWESOME!" again. I replaced my temporary Unit class with Artemis entities which supported stats and movement and got the exact same or (very marginally) HIGHER performance with the Artemis version. I like.

I'm very close to releasing a comprehensive component architecture framework as part of a platform for Java/Android called TyphonRT. There is an entity system (ES) extension as well. I've put a considerable amount of time into the component architecture and ES making it efficient and fast. While yes I'm indeed going to be charging for aspects of the larger platform the core component architecture and ES will be released under a slightly modified GPL classpath license allowing usage in any project.

I've spent a considerable amount of time on performance matters. Like Artemis and B^3's articles / reference implementation there is the component as data / system as logic separation. One performance aspect I'll mention though is the ability to recycle containers (an entity), components, & systems. Essentially this is a generic object pool such that when an entity goes away it is ripped apart and the container, components, and systems are recycled and when entities are composed they can pull them from the recycler. If the game is generally well tuned regarding entity lifecycle the recycler footprint can be kept low leading to none to minimal GC in runtime.

While yes there is a general performance concern when one is querying a container to receive a component (essentially a HashMap retrieval) even with the majority of code flow utilizing this method the bottleneck remains with fill rate for instance which isn't related to the ES / component architecture.

I'll be giving an all day workshop at AnDevCon II on Nov 6th and a large part of the discussion will be about entity systems and performance concerns. My main test case is a Quake3 class engine example, so it's reasonably comprehensive. I'll be doing to initial early access release at that time and am hoping to get to full public release by March. I've been working on TyphonRT for years, so it is well formed.

Like Cas mentions if you want to ship a game that is of low to moderate complexity with static unit types without being concerned too much about reuse for future games just go at it and don't worry about an ES. He's been successful with this approach for sure!

If you are an architecture wonk like me you spend years fine tuning and improving ones application of the larger craft; [edit] err games forthcoming! I happened to end up fully in the component architecture / composition camp after years of minimizing ties to OOP as core architecture. My ES went through the pain of OOP and eventually buckled. As things go a lot of the Java component oriented based ES popping up are not necessarily refined and serve more as a reference implementation for the general idea.

theagentd, or others interested in checking things out in Nov drop me an email at the contact email from the TyphonRT site or send me a PM here. The basic splash page up now while not inaccurate doesn't give away all the details of what TyphonRT has become as a platform which will be revealed on public launch. Anyway, I'd be glad to spend a reasonable amount of time to personally work with you regarding ES matters and TyphonRT in Nov as it should particularly serve well for RTS games.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org