Entity System with Artemis example

[atomix]

As said in another topic “Entity system helps” , i recommended who want to start with this “big-ass” ES topic, first try Artemis, cause it’s easier to understand and kind of naive (simplest form) approach to the problem. After all it’s just a way to manage data and Gameobjects!
The detail of architect and specification of such ES implementation you can find in Artemis website.

What I want to give you it’s … an example. That’s what you really need to start. After all, I saw you guys struggle to find what is right and wrong, but not what you need to start a game. And hey, it can be improve from time to time but first make it work!

Yeah, this link here, download the SpaceShooter of Artemis I converted to 3D. I also change some thing and add a cool way (GUI) to watch and handle Component and System in the style of Unity. That’s what I think you should start with. And I will make another topic answer for who interest in my approach.

Keep in mind I’m nothing near a Java gurus so I just want things to work. I used a lot of external libs that may be you don’t need but you can clean up if you want. You should download the libs to use cause I clean thoose to decrease the size. With every libs in the project as bis as 100MB.

Here is the link:

Dropbox - Error

For detail:
This example SHOW

• How to use a “entity framework” – here is Artemis to handle game data in JME3 game
• How to make an In-game GUI tool to help manage that data
• How to use POJO architect power to simplify all your need of DataStoring and DataDisplaying (Advanced)
  This example USE
• Artesmis for handling Game Objects
• Groovy for Scripting
• Groovy to make UI for an in game editor, MyDoggy for Docking Framework, Substance for LookAndFeels
• GlazedList helps work with List Event and such…
• Cayene for POJO storing, MetaWidget for POJO display
  Image:

May be when I get more familiar with the other ES approach of pspeed and the other guys i will port this example to the most popular one. Cause I also trying to learn that those “good but early stage” approachs so “zero” experience as everyone.

[ogerlord]

When pspeed and I come to an arrangement I have the plan to write a tutorial series on how to use our Entity System where I would explain the features.
Artemis is dangerous because it is often used if people are new to ES and do not understand them completly so they think the best way would be to use a simple and complete Entity System like Artemis.
In the Artemis concept and description they are missing some important points and Artemis works for small example games but would cause problems in larger projects.

[normen]

Yeah, I don’t think Artemis is a good point to start with an ES, the base of an ES is so minimal you can easily implement it yourself. Additionally Artemis has a few questionable specifics as mentioned.

[atomix]

I have to say I totally agree with those points which sum up to " We need a complete official supported ES"… but …

This example just work , may be not a start for a big and serious project but to get the ideas of the form of an ES.

Artemis also be used by someone who come up from 2D game. They could find it familiar somehow like when they start that orginal 2D example of Artermis, this example will be a bridge between that and the 3D world of JME. In fact I also use this to show the other how to port a 2D game to 3D. That’s my point of making this. :idea:

[t0neg0d]

I could use some help understanding if the system I came up with (not really knowing about entity systems) is essentially an entity system… or at least the start of one. I don’t think it encompasses all aspects, because of my lack of understanding. But, the basic idea was:

Every object in the game is a collection of Stats, States, Mods and Effects.
The four “entities” mention above are extremely generic and work as such:

• Stats can represent any value
• States represent behaviors… if the State exists, the behavior exists
• Mods effect Stats and States
• Effects define how Mods effect Stats and States
  Every object is capable of being any object by piecing together the the needed Stats, States, Mods & Effects.

I get the impression that this is generally what an entity system does, however… I’m not quite sure if there is more involved? Or?

Any suggestions, pointer, articles, etc is appreciated.

[Empire_Phoenix]

Nope that is not an normal Entity system, as you have some kind of artifical splitting in it.

[ogerlord]

The Entity System news - Attack of the Gelatinous Blob

Your system sounds difficult because mods affect states an states are influenced by effects ect.
Besides it sounds like you are using your system only to represent visual objects like units/missiles.
Do yourself a favor and read some more about ES because you cannot simply add an ES later to your project.

[t0neg0d]

@ogerlord said: http://www.moddb.com/games/attack-of-the-gelatinous-blob/news/the-entity-system

Your system sounds difficult because mods affect states an states are influenced by effects ect.
Besides it sounds like you are using your system only to represent visual objects like units/missiles.
Do yourself a favor and read some more about ES because you cannot simply add an ES later to your project.

1. They do… however, mods & effects represent how one object can effect another…
2. They can represent these (or encompass them), of course, however… in this case I’ve been able to develop my game without a single mesh added to the scene.
3. As I don’t really understand entity systems, I’ll definitely start reading up on them, however, hearing that it is a shift from OOP is a little disconcerting. I’m guessing this is not really an issue as they are widely used. It just seems very foreign. And there are so many different ways of storing/reusing data, I wonder why this approach (if the non-OOP aspect is correct) would be the approach of choice. Have to wonder if there wouldn’t potentially be some way of accomplishing the same thing in a more conventional way. But, like I said, I have nothing to base this off of.

[t0neg0d]

Ok… I realize that the description there is not the definitive on entity systems, however this sounds like what I put together. The major difference between the example stated in your link and my system is, I am storing system components as well as entities (mods & effects). However, I got the impression from the final discussion in the posted link that this is not uncommon.

Am I missing something here? Either I read the article the way I wanted to, or it was a 1 for 1 description of what I put together.

[t0neg0d]

@Empire Phoenix said: Nope that is not an normal Entity system, as you have some kind of artifical splitting in it.

Can you be a little more specific about artificial splitting? I don’t think I follow what you mean.

[Empire_Phoenix]

Well a entity is basically one an id, and (in primitve implementation) an array of components.
Components can be anything only containing data, no logic
Systesm modify components and wich components are at entities,
thats it.

[t0neg0d]

@Empire Phoenix said: Well a entity is basically one an id, and (in primitve implementation) an array of components. Components can be anything only containing data, no logic Systesm modify components and wich components are at entities, thats it.

Soooo… if your entities can help make your systems smarter, not by employing logic but by defining behavior as an entity itself, this is a bad thing?

EDIT Key word being defining… ya know… data

EDIT 2: Actually, threads on this subject are pretty freakin’ laughs. Watching everyone bitchslap each other with their ES prowess

That’s not ES you COW!
Fear meh ES /flex /flex
Sooo… the other day I was totally gettin’ my ES on… when this ES newb started dis’in ES and I was all like “F U!”… and she was all like “F U!” and so I punked her with a big ol’ fatty… ES style and shit. Yo?

Seriously though… whats the primary focus of an entity system? easy of maintainability? simplified code? It doesn’t seem like efficiency is high on the list… but /shrug… I’ve been wrong before (at least 8 times today alone)

[t0neg0d]

Maybe for the sake of learning (for myself and others), I’ll throw out a scenario and someone tell me why this would not be encompassed by an ES:

I have an entity called health
I have an entity called mana
I have an entity called stamina
I have an entity called damage

Now, damage can effect health, can effect mana, can effect stamina.

In your response to me, you have stated that by adding behavior definition, it would no longer be a normal ES. Even though the behavior is nothing more than another piece of data. It is data that tells the system HOW to handle any one damage entity, but it is data none the less. There is no logic tied to it, it just simply defines how damage will interact with other entities.

So… WHY is this not an ES?

[Empire_Phoenix]

Thrust me i went that way as well, with a fucked up es in the start. While it actually worked quite good (and your mgiht as well be a nice solution for your problem) it lacked flexibility. Don’t get this wrong not everything not an es is wrong or bad, it’s just that it seems to be a nice design pattern that on the long term produces better readably code.

All entities you listed, health,mana,stamina,damage are components, that for example a Entity representing a mage player might have. Add a damgeProcessorSystem that contains the effects damage has on health, and that part is more in the es way. Also your logic is now seperated from your data, making it easier to follow the flow of the programm. as I now only need to understand what damage helath and the processor is to know how it works. Prior i had to make sure that only damage affects health and must probably search any other class to ensure this.

Primary focus:
Seperation of concern,

eg imagine OO way
you have breakable objects, and you have burnable object, but you also want breakable burnable object, and boom multi inheritance.
Es way
burnableflag component
breakableflag component
Now two (or one) system processing the damage and burning/breaking entities depending ona pplied damagetype.

Pro:You can for example just add burnable to the above described player, and now he can burn without changing anything else. In a oo system you can get extremly bad dependency problems with huge refactoring.

Performance is a implementation thing, I would go so far and say a primitve es is slower than a oo system.
However in a es you can process all systems concurrently if done right, while in a oo system you get multiple problems with locking objects and event passing, that drag the scalability down.

Also flexibility, you can alter add or remove behaviour from entities rather easy by just interchanging components, while in a oo system you usually have to change code.
This goes so far, that by now adding multiplayer support to my base Es is just 2 lines of code. (and one class with a system doing the binding to the low level message based networking, also it can compress and create all messages multithreaded and by this improve ticktime)

Doesn't multiple inheritance solve all problems that entity systems do?

[pspeed]

@t0neg0d said: Maybe for the sake of learning (for myself and others), I'll throw out a scenario and someone tell me why this would not be encompassed by an ES:

I have an entity called health
I have an entity called mana
I have an entity called stamina
I have an entity called damage

Now, damage can effect health, can effect mana, can effect stamina.

In your response to me, you have stated that by adding behavior definition, it would no longer be a normal ES. Even though the behavior is nothing more than another piece of data. It is data that tells the system HOW to handle any one damage entity, but it is data none the less. There is no logic tied to it, it just simply defines how damage will interact with other entities.

So… WHY is this not an ES?

In an ES, those are components of an entity. An entity is a game object. The subtlety isn’t just in how the data is defined but how it is used.

For example, there could be an “apply health damage” system that all it does is iterate over entities with “health” and “damage” components and applies the damage to the entity. It’s like a database query. It says “give me all entities with health and damage” and it iterates over them and applies damage. This is a very very simplistic example, though.

A more complex example (already sort of discussed in those other threads by the way) would be where the damage dealing systems add “damage entities” to the target of the damage. So the first system can create an entity and give a DamageFor(player) component. Maybe it also adds a DamageType(fire) component. Now the damage dealing system selects all entities with DamageFor and DamageType components, it iterates over those entities and pulls the entity that it needs to apply damage to (the player in this case) and may then look up any resistance components that player entity might have, etc. before deciding how much damage points are actually applied.

This example doesn’t really show the benefits of an ES that well as it’s at the tail. The systems that do real stuff are more interesting… the ones creating the damage for example.

[pspeed]

I think we even started an ES manifesto somewhere but I don’t know where it is. Just a list of “you must/should have” things.

[t0neg0d]

@pspeed said: In an ES, those are components of an entity. An entity is a game object. The subtlety isn't just in how the data is defined but how it is used.

For example, there could be an “apply health damage” system that all it does is iterate over entities with “health” and “damage” components and applies the damage to the entity. It’s like a database query. It says “give me all entities with health and damage” and it iterates over them and applies damage. This is a very very simplistic example, though.

A more complex example (already sort of discussed in those other threads by the way) would be where the damage dealing systems add “damage entities” to the target of the damage. So the first system can create an entity and give a DamageFor(player) component. Maybe it also adds a DamageType(fire) component. Now the damage dealing system selects all entities with DamageFor and DamageType components, it iterates over those entities and pulls the entity that it needs to apply damage to (the player in this case) and may then look up any resistance components that player entity might have, etc. before deciding how much damage points are actually applied.

This example doesn’t really show the benefits of an ES that well as it’s at the tail. The systems that do real stuff are more interesting… the ones creating the damage for example.

I spent a couple hours this evening reading different peoples takes on what an ES is. And all I can say is… WTF??! I’ve never seen more contradiction in my entire life. I think I’m starting to settle in to what an ES should be and how it works, but my one concern really revolves around being so concerned about the system following the rules, that it starts to lack.

Here is what I mean:

No matter how self-contained your ES is, it still must be wrapped into OOP… there is no way around this… it starts as OOP, becomes ES and then is used in OOP. This is Java after all.

If you have 3 separate systems to manage damage, have you saved yourself anything at this point? Besides the 2 extra threads (that will eventually be locked and waiting their turn by the others to ensure you don’t corrupt the data) to manage a single component of some entity. On top of this, you have to collect the list of components 3 separate times… when you could have managed the data slightly differently by storing behavior data (which in all definitions of ES I read is discussed anyways) and ensuring your systems are smart enough to understand behavior components.

With behaviors, you now a single system for dealing with the damage component… a single lookup to collect the list of components… no competing thread wanting to manipulate the same entity component and an application that is just as easy to maintain.

[t0neg0d]

One last thing that makes me stand-off-ish about ES is… it’s become the latest fad… and that usually means that people will find a way to use the fad, whether or not it is a) appropriate or b) the best solution of task at hand.

Not saying I think they are not useful… especially in game development, however, it is hard to weed your way through the bullshit when people are saying it cures cancer AND contains your personal key to salvation… not to mention it is tasty on toast.

[abies]

They are not really ‘latest fad’. Seems that world is quite bend on them for MMO development for 5-10 years already. I think it is just on this forum where they became very visible recently. If you check t-machine blog which everybody here is referring here as starting point, it is from 2007 - and he starts it with “A few years ago, entity systems (or component systems) were a hot topic.”.

That said, while it seems that concept is already quite mature, frameworks are not. I get the impression that there more ES implementations than people using them - because everybody wrote few attempts on his own. Which means that there is no real tool ecosystem around that - for example, I think that ES debuggers could be quite nice things. Currently people are probably either using plain debuggers, which are not aware of all aspects of the system, or just browsing sql tables/whatever directly. Same for UML-like tools (generating graphs between systems and components they are reading and updating, for documentaton purposes) etc. But to achieve that there would have to be some standarization and for that, people would have to agree on some common denominator - and it seems that it is easy enough to write your own ES to not have to do that.

[t0neg0d]

@abies said: They are not really 'latest fad'. Seems that world is quite bend on them for MMO development for 5-10 years already. I think it is just on this forum where they became very visible recently. If you check t-machine blog which everybody here is referring here as starting point, it is from 2007 - and he starts it with "A few years ago, entity systems (or component systems) were a hot topic.".

That said, while it seems that concept is already quite mature, frameworks are not. I get the impression that there more ES implementations than people using them - because everybody wrote few attempts on his own. Which means that there is no real tool ecosystem around that - for example, I think that ES debuggers could be quite nice things. Currently people are probably either using plain debuggers, which are not aware of all aspects of the system, or just browsing sql tables/whatever directly. Same for UML-like tools (generating graphs between systems and components they are reading and updating, for documentaton purposes) etc. But to achieve that there would have to be some standarization and for that, people would have to agree on some common denominator - and it seems that it is easy enough to write your own ES to not have to do that.

What abies said… so elegantly!