I did not link an article. I agree that you should use Aggregation/Composite over inheritance. I still have it 4 deep though.
J2ME support has 1+ billion devices strong so it will never die. In twenty years people will still have old BlueRay players that can run my games as JavaTV.
Android 1.x pretty small according to most but it still has more than 5% according to my high score servers. Although, 1.0 - < 1.5 is pretty much gone. So, it is still about 12 million or so 1.5 and 1.6 devices.
So you are correct that no one codes for them anymore except for me, but J2ME and early Android is far from dead.
Oups was talking about the link of theagentd
Since my main concern seems to be performance I made a small test, which might not be very accurate considering the results. Basically it’s this code
//Initializing an entity
Entity e = world.createEntity();
e.addComponent(new Position(0, 0, 0));
e.addComponent(new Velocity(1, 0, 0));
e.refresh();
//In MovementSystem
Entity entity = entities.get(i);
Position p = positionMapper.get(entity);
Velocity v = velocityMapper.get(entity);
p.setX(p.getX() + v.getVX() * world.getDelta());
p.setY(p.getY() + v.getVY() * world.getDelta());
p.setZ(p.getZ() + v.getVZ() * world.getDelta());
vs a combined position-velocity component:
//Initializing an entity
Entity e = world.createEntity();
e.addComponent(new PositionVelocity(0, 0, 0, 1, 0, 0));
e.refresh();
//In MovementSystem
Entity entity = entities.get(i);
PositionVelocity pv = pvMapper.get(entity);
pv.setX(pv.getX() + pv.getVX() * world.getDelta());
pv.setY(pv.getY() + pv.getVY() * world.getDelta());
pv.setZ(pv.getZ() + pv.getVZ() * world.getDelta());
I have 100k entities just updating movement. The results are weird:
With the Position + Velocity code, the FPS instantly goes to a stable ~501 FPS (1.996ms) and about 40 MBs of RAM usage.
With the combined component code the FPS sits at ~440 FPS and memory usage at about 27 MBs. ??? After running it for about 30 seconds it suddenly starts running at ~493 FPS (2.028ms) and RAM increases to 40MBs, very similar to Position + Velocity but still slightly slower. Well, 1 vs 2 components isn’t a very realistic scenario anyway… xD
I’m using the Server VM BTW, so that isn’t the problem. Next I’ll try a benchmark of a basic game object class (theoretical of course) VS Artemis entities to see how much performance loss(/gain?) there is.
Putting the performance issue aside, my main problem is the fact that I have never gotten a decent object system working. I tried to do it earlier using a pretty fat base class which was extended by other even fatter classes, which also had components which interacted and everything exploded into a world of bloody spaghetti. I have this kind of mental thing that I want everything to be perfect from the start, so I try to think out a lot of stuff before I start coding, but I could never come up with even a somewhat decent solution. I ended up rewriting and rewriting and eventually dropped the whole project (which was mostly for learning, but whatever). Of course I realize there is no perfect way of doing this, but to me it seems that Artemis comes pretty close to be honest. I think I could actually implement this in a pretty nice and readable way, which I think is THE most important thing for something that’s this hard to get right, at least for me.
So, an pure inheritance based system is pretty much out of the question. I’ve had so much problem with it spiraling out of control that I just want to try something else. Even if you guys think it would be “enough” for my game to use basic inheritance (which I don’t really agree with), I value the structuring and extendability more than performance. But like I said, if I’m doing things completely wrong then PLEASE stop me.
This seems very very similar to Artemis, but with that gigantic class split up into components. A component system seems a little bit more flexible though.
Yes, I really wish to multi-thread the CPU hogging parts. Multi-threading inside systems is completely overkill if you ask me, but running multiple systems at the same time would be awesome. I found this in the EntitySystem code:
if(checkProcessing()) {
begin();
processEntities(actives);
end();
}
All of these are abstract functions, so it seems to be all up to the coder to ensure that it is thread safe. The point is that Artemis shouldn’t have a problem with it at least.
I’ll be back with more benchmarks! Meanwhile, alternatives to Artemis and random thoughts are welcome! =D
EDIT:
A new benchmark. Doesn’t use Artemis.
//Initializing
ArrayList<Entity> entities = new ArrayList<Entity>();
for(int i = 0; i < 100000; i++){
entities.add(new Entity(0, 0, 0, 1, 0, 0));
}
//Update loop
for(Entity e : entities){
e.update(10);
}
//Entity update code
public void update(int delta){
x += vx*delta;
y += vy*delta;
z += vz*delta;
}
Much faster of course. I get 693 FPS (1.443ms) with this code. But really, I doubt that performance is very important here. I’ll probably not have much more than 1000 objects. If I were to go crazy I probably wouldn’t even have 10 000 objects, not to mention 100 000 objects! Considering the lightness of the updating (movement) I think this benchmark highlights the “low” performance in Artemis, but in the reality the overhead of Artemis is a lot smaller than the game logic. That’s what I think at least, and haven’t you guys been telling me not to do premature optimizations? 
EDIT 2:
A basic inheritance system performs approximately 1.5-2.2x as fast as Artemis for basic movement, depending on the number of entities, with Artemis closing in on inheritance systems as the number of entities increases.
A final benchmark, confirming my overhead hypothesis:
By changing the movement integration to something more CPU heavy the overhead of Artemis gets a lot smaller as it is memory bandwidth bottle necked. I changed the movement updating to:
//Artemis:
p.setX(p.getX() + Math.sqrt(v.getVX() * world.getDelta()));
//Same for Y and Z
//Inheritance:
x += Math.sqrt(vx*delta);
//Same for x and z
With up to 10 000 entities, Artemis performs exactly the same as basic inheritance. If I go over 10 000 Artemis starts to lose ground. At 1 000 000 entities, Artemis gets 45 FPS VS inheritance 61 FPS. I think I can live with these performance numbers though. 
I realize the Artemis system is amazing and this may be the most important thread for beginning game developers.
Personally I have position as permanent property. How many game objects don’t have position. The answer should be zero. So why have the extra method calls.
I look at your example and I think it has many method calls and uses abstract classes, but I love the Entity ideals.
I follow simple rules to keep performance and minimize complexity.
- Don’t use inheritance more than 4 deep per project. (Artemis obviously fixes this problem for game objects)
- Don’t let classes exceed 1200 lines.
- Don’t have more than 7 properties without converting it to yet another composite.
- Keep 90%+ of methods to less than 12 lines.
- Don’t make methods for less than 3 lines of code.
- Minimize static references. Yes they are slower than non static.
- Don’t cast to an interface or abstract class in the game loop.
- Don’t create objects in the game loop when in a gameplay state unless you really must
- Don’t have a collection of objects that don’t have a base class other than object unless object really is the base.
(This is one that Artemis breaks) - I have many more…
The point being that getting around the God class issue is important but don’t destroy sensibility in the process.
Just think through your current game object implementation and ask yourself does this make sense.
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
Can you redo your last sentence.
I said that if you can’t chose the data structure in which you store your Entity, performance will be bad.
A simple example. Imagine that you have a list of thousands of enemies and in that list you have a few like 4 or 5 that have some special behavior that you need to update into a different part of the code then the other enemies. If you have something like that iterating over your list of, let’s say, 10 000 Entity to get the 4 or 5 that you need is a very bad waste of ressources. Those 4 or 5 Entity should be store in a different list.
On another side, those 4 or 5 special Entity might need to be updated at the same time than other Entities for some behavior, so you need be able to iterate over all those in one time.
That’s a very simple example, but as soon as you begin to create something more complex you will find that a lot of those things happen. You need to carefully chose the datastructure to get good performance and I don’t think that Entity System can do that for you.
How can calling a method World.addEntity() or World.createEntity() can store that Entity in the best datastructure, sort it in the fastest possible way, giving access to it in the fastest possible way, being able to remove it in the fastest possible way, etc.
I just can’t see a way that all that can be true. Bad datastructure will be responsible for the majority of your performance problem, so not being able to decided exactly how the things are stored is a HUGE weakness.
In examples like this, all you really need is for the entity system to handle lists of entities based on having a component (or a set of components). You then move the special behavior for the 4-5 entities into a separate component (like AdvancedEnemy) and you can do your queries on them quickly. Since they’ll also have the plain Entity component, you can still process them with everything else.
Entity systems are tricky because they require a different way of thinking about how to solve your problems.
Guys, stop posting all the time when I’m trying to post! T___T
@Tberthel
I agree that having position as an (optional) component is kind of weird, but at the same time I think it’s really hard to know where to draw the line. I found it easy to always create some kind of exception to the base class. It’s also very hard to refactor if everything is built this way. Like I said, this is all just my opinions.
I see. I will probably try using Artemis and if I find some major flaw I might drop it. What is Appolon? Does it have a website? Is it even released?
EntitySystems filter out the entities that have all the required components (set in the constructor) and stores them in a Bag (an optimized ArrayList I think). There is no need to iterate over all entities just to find a few specific ones. And it’s not World.createEntity() that handles the data structure setup, it’s Entity.refresh() which you must call whenever the Components of an Entity changes. I think Artemis actually covers all or at least most of the problems you specified…
If I turn your criticism around: Do you have any examples on how to do this better than Artemis does?
I think you are looking for Apollo, briefly mentioned here.
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”?
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)
- data transfer (minimize data motion, notably CPU/GPU, CPU/storage, server/server, etc. and also scattering and gathering)
(edit: hit the wrong button. Opps!)
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.
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
Thanks for the interesting reply! I saw using a component based system (combined with Artemis’ way of separating data and logic) mostly as a way to simplify development…
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.
So you say that I Artemis would work?
???
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.
Cas