Entity system help

[Empire_Phoenix]

The entity system i use/create has some non quite default modifications, that make sense IN MY CASE (carfeull here for what you want to do), keep this in mind as this is special for mine and not necessarly following the clean concept of an es.

Basically my systems (whatever they are) are threads, that have a central CyclicBarrier. In the cycilcbariers runnable all changes are synchronized with the live data (I only use immutable objects, to easy multithreading, and allow delayed concurrent processing for special systems.
Basically assume a queue that collects changes in the current itteration and before the next they will be applied.

-> Other implications I have, only one system is allowed to write at a specific component, but multiple may read at any time.
-> Only one write per component is valid per iteration! (This hugly changes on how stuff can be approached, but makes the synching between ticks nearly free.
-> No matter when I read I get a consistent state, eg i will never get a half updated entity.
-> There is absolutly no gurantee on the order in wich systems will process Entities, and wich Thread will actually do the work, but it is guranteed that any system intrested will process each intresting entity once a tick.
-> Adding removing entities happens between ticks.

One downside is that I have a higher performance base hit per iteration, however since everything is truly concurrent, it scales nearly with factor 1 per cpu core.
Other stuff:
-> JME on the client is only a system, the es is independet, i could just disable that system and it would still run.
-> Networking is independet, on the server and the client is a system that manages everything else depending on annotations present
-> I do no runtime detection of those, I wrote a small precompiler that does all registering of entities systems (network message types ect) by writing a simple java class out of it. (while a bit strange, this greatly reduces problems with forgot to register)
[An average networked component that can be persistent in my system has to be registerd with up to 5 systems currently (Database so tables are generated and ESQLCriterions (yes i made a own Criterion based language for ES), Network to prepare caches, and custom serializers, universe so the component gets an id based on type ect.]

Now after that basics to your question (on how i would handle this, note that pspeed is probably way more using a clean es than i)
-> I would have a PhysicSystem, DamageApplierSystem, HealthComponent,ResitanceComponent.
-> PhysicSystem will provide all collision data, and (for example via userdata the id of the entitys affected) in my case not via a component but directly
-> DamageApplier will read all entities with collision, filter for entites with health
-> At this point I then would be able to calcualte the new health and set it, since I have all data potentiall affecting health available (remember limitation of my Es to only set once per tick)

One recommendation:
Download Artemis (another Es not reall being a clean one) and their example verticalshooter
Now after you understood that eample, modify the game such that

1. The enemys get a random velocity at spawn and move into the direction
2. The enemys can shoot back (cooldown and maybee based on size of them?)
3. You can get damage, and have a small shield that can take 1 hit /10 seconds
4. Make larger enemys fire different bullets that do more damage, see how the shield reacts to this without changing any code.(Report this back as I wonder how you will do this step and I can imagine different implementation based outcomes)

After this think about all connections between components and systems and if they are the minimal ones necessary.

Also throw out all normal design patters you know when thinking about an ES, while without a problem possible to make a system for example like a state machine, try to not think into , as it will always have a limiting context, ES is like OO a own paradigmen that my seem similar in many points but is not.

Also there are almost no real clean ES out there, mine has that thread implications, pspeeds cannot handle multiple entity generating servers (as i understood form an earlier discussion about what to use as an id, simply because it is not required) ,artemis has a limited idea of systems, ect. each is modified a bit for it’s use case and personal likings as well as some crude performance based choices.

Well yes, thats quite longer than i expected to write, I hope it helps you, especially the part about doing a bit of work with artemis might be the most important, as that was when it suddenly made a loud click in my head.

[pspeed]

@Empire Phoenix said: Also there are almost no real clean ES out there, mine has that thread implications, pspeeds cannot handle multiple entity generating servers (as i understood form an earlier discussion about what to use as an id, simply because it is not required) ,artemis has a limited idea of systems, ect. each is modified a bit for it's use case and personal likings as well as some crude performance based choices.

Technically mine could handle per-server entity ID sets. The entity ID generator is pluggable and you could use some of the 64 bit ID for a server ID. In a federated cluster of servers, these IDs could be assigned automatically at startup. The EntityIds are based on a 64 bit ID and that is pretty hard-coded on some levels (like the SQL layer, etc.) but really 64 bits it a lot of bits.

[Empire_Phoenix]

Yes thats why i inculded the not required part, since I assumed you could change that at any time without to much hassle.

[pspeed]

@Empire Phoenix said: Yes thats why i inculded the not required part, since I assumed you could change that at any time without to much hassle.

Yeah, I did abstract entity Id generation into a strategy object some time back so it’s easy to swap them out. An in-memory ES just increments the value from 0. The persistent one reads from the DB first during init, etc…

[Empire_Phoenix]

@pspeed said: Yeah, I did abstract entity Id generation into a strategy object some time back so it's easy to swap them out. An in-memory ES just increments the value from 0. The persistent one reads from the DB first during init, etc..

Well since my components/entities cannot know (should not care) wheter they can be persistet, and i found that logic is not required at all in the es I simply use a mixture of timestamp,threadlocal counter and nodeid, so that i can generate the id’s concurrent without first reading from db. (downside longer keys). The Database as well as the network is just a system that can be given tasks to persist an entity (via a safetask component) Sicne they are timefrozen this can then happen in the background.

[abies]

I have done changes you have requested in below patch.
I was trying to extend existing approach without major refactoring, so shield feels a bit wrong - it is handled in collision system, same as previously damage was. This is not using any of the concepts discussed above - but example system also doesn’t do it, so if felt most natural to extend it this way.
I supppose we can start from that.
(sorry for System.exit on player death, but implementing lifes/gameover screen is bit outside of exercise I suppose)

Edit:
Patch got broken due to special characters so cannot embed it inline, it is here

es.txt

[abies]

@Empire Phoenix said: DamageApplier will read all entities with collision, filter for entites with health At this point I then would be able to calcualte the new health and set it, since I have all data potentiall affecting health available (remember limitation of my Es to only set once per tick)

Ok, so first point is that you have a barrier which waits for every system to receive every updated entity/component before progressing to next tick. Do you have something like IntervalEntityProcessingSystem from Artemis in your solution? How does it play with barrier/tick system - is it becoming a part of barrier acceptors only when it’s delay ticks?

But I still don’t understand second part of the solution - how do you know in DamageApplier that collission was already processed? Does it happen only in a single tick and after that Physics system is already not reporting it? If you were to pass collisions through entity system, would it be physics system which would then remove the collission entity on next tick or would you have some kind of generic TTL on entity?

[atomix]

Ok, as @Empire Phoenix said , i also recommend 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 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.

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 things for 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:
  

[Empire_Phoenix]

@abies said: I have done changes you have requested in below patch. I was trying to extend existing approach without major refactoring, so shield feels a bit wrong - it is handled in collision system, same as previously damage was.

Looks good :), I hope it helped to work a bit with an already exisitng es.
I totally agree with how the example handles damage, as this greatly reduces the ability to make the system more complex in comparision to a seperate module. Eg if you would add different shield types, armour ect it would quickly become a complexity explosion there.
I usually try to keep things so seperated that a developer could change the implementation and purpose of one system without breaking any other.

[Empire_Phoenix]

1. Ok, so first point is that you have a barrier which waits for every system to receive every updated entity/component before progressing to next tick. Do you have something like IntervalEntityProcessingSystem from Artemis in your solution?
   -> Well the intro point to my systems is a tick() method, only a subtype has the conept of traversing entitys based on aspect, the tick is free to return without doing any work. So you could do a timer that just does tickccount++ if tickount > 20 do work reset tickcount. Pro its deterministic, if the es lags due to overload it will still be called as exepcted and not suddenly a tick earlier.

How does it play with barrier/tick system - is it becoming a part of barrier acceptors only when it’s delay ticks?
Always a empty run does not really use that much processing power.

But I still don’t understand second part of the solution - how do you know in DamageApplier that collission was already processed?
The physic system provieds based on processing of the physicspace of last tick collisions, now all systems that are intrested can do work with them on their own.So basically if the DamageApplier can see it, it was not processed so far.

Does it happen only in a single tick and after that Physics system is already not reporting it?
One tick delayed, so that every system has excatly one chacne to see it.

If you were to pass collisions through entity system, would it be physics system which would then remove the collission entity on next tick or would you have some kind of generic TTL on entity?

I would do this in between the ticks. (eg add, tickswitch start,remove old,add the newly ones,tickswitch end, This way i can gurantee that they exist only one tick, but excactly one tick.

[pspeed]

@Empire Phoenix said: Well since my components/entities cannot know (should not care) wheter they can be persistet, and i found that logic is not required at all in the es I simply use a mixture of timestamp,threadlocal counter and nodeid, so that i can generate the id's concurrent without first reading from db. (downside longer keys). The Database as well as the network is just a system that can be given tasks to persist an entity (via a safetask component) Sicne they are timefrozen this can then happen in the background.

Maybe you misunderstood. The users of the ES don’t care how the ID was generated. They just create a new entity with the ES. It’s how the ES was setup that decides how the ID is generated, in this case with a pluggable EntityIdGenerator. In the case where components are persisted, during ES startup I query a special table in the database that has the ID of the last entity created. I could have used time stamp but then risk generating the same IDs again if the user’s clock has been rolled back since the last run or if in the last run the clock had sped forward for some reason (I’ve seen both in production apps on servers, non-ES).

Even in the persistent version, some components are persistent others are not. This is controlled with a tagging interface. This seemed like the easiest solution since most components will know that they should be persistent (whatever that means to the ES) and others will know that they definitely should not ever be persistent. (For example, I have some thread-safe mutable components that should never ever be persisted.)

Anyway, just different approaches. I probably had to write less code.

[t0neg0d]

Hmmm… is it my imagination, or do people seem to have different concepts of what an entity system does/should do/can do/will do and how it does it?

Who is considered the definitive guru on the subject of entity systems? (globally speaking here… if they reside on this forum… even better)

[pspeed]

@t0neg0d said: Hmmm... is it my imagination, or do people seem to have different concepts of what an entity system does/should do/can do/will do and how it does it?

Who is considered the definitive guru on the subject of entity systems? (globally speaking here… if they reside on this forum… even better)

I think those of us who have implemented an entity system are all on the same page. Empire and I are only discussing implementation details under the covers… not how it’s used.

[Empire_Phoenix]

Yes, i think we have the exactly same concept by now, but with a few different implications based on different approaches. However those might have some larger implications on how to use. Eg the only set each component at max 1 time per tick.

[abies]

@Empire Phoenix said: Yes, i think we have the exactly same concept by now, but with a few different implications based on different approaches. However those might have some larger implications on how to use. Eg the only set each component at max 1 time per tick.

As I understand, critical part here is about atomic update to all changed components between the ticks? From what I gather, in Artemis for example, depending on order of evaluation, I might get quite different results because of processes seeing data already modified during given tick.

[normen]

@t0neg0d said: Hmmm... is it my imagination, or do people seem to have different concepts of what an entity system does/should do/can do/will do and how it does it?

Who is considered the definitive guru on the subject of entity systems? (globally speaking here… if they reside on this forum… even better)

As paul didn’t want to answer I’ll say: Him and me We still argue to this day who told whom first about it and who grasped it fully first then

And without wanting to pad ourselves on the shoulder we are the ones that (at least here) put the red line and the defined terminology in. The info on the web is partially very confused as people wrote it when they were still in the understanding stages themselves. This is why we want to really have it sunk in inside the team and some parts of the community before we make any moves in that direction.

[pspeed]

@normen said: As paul didn't want to answer I'll say: Him and me :) We still argue to this day who told whom first about it and who grasped it fully first then ;) ;)

And without wanting to pad ourselves on the shoulder we are the ones that (at least here) put the red line and the defined terminology in. The info on the web is partially very confused as people wrote it when they were still in the understanding stages themselves. This is why we want to really have it sunk in inside the team and some parts of the community before we make any moves in that direction.

My memory of history:
You pointed me to the kool-aid, I initially had tongods reaction and then I read all of the t-system articles and comments. Then I started thinking about how to apply it to Mythruna… then I spent a weekend writing an ES. I totally drank the kool-aid.

Then you and I had several discussions where, in mild terms, I helped realign your thinking with respect to controls not being directly related to an ES but a mighty fine way of implementing a system. That was really the only sticking point and we got past that quickly. Though honestly, those discussions helped solidify things in my own mind, too. Basically, we were just hammering out the rules after one of us had actually done one. I shared the kool-aid. We all had a sip.

[t0neg0d]

So, I guess the question still remains:

What on the web would you consider definitive articles concerning the subject? @normen says it’s all confused. @pspeed says he had my reaction until reading… ??

So, where be the ?? in question It’s always nice to go to the source, as apposed to hearing a person’s interpretation of the source.

EDIT: Reason I say this is… if I am asking semi-educated questions based off of what you consider a concrete foundation on the subject, I stand to get specific answers to specific questions without irritating the masses more than I usually do.

[normen]

@t0neg0d said: So, I guess the question still remains:

What on the web would you consider definitive articles concerning the subject? @normen says it’s all confused. @pspeed says he had my reaction until reading… ??

So, where be the ?? in question It’s always nice to go to the source, as apposed to hearing a person’s interpretation of the source.

The posts in this forum where we explain it I think we picked up most major “ES threads”. If you want you can start putting together the wiki pages from that which we will do at some point anyway.

[t0neg0d]

@normen said: The posts in this forum where we explain it :) I think we picked up most major "ES threads". If you want you can start putting together the wiki pages from that which we will do at some point anyway.

So you are saying you wrote the documents that told you about entity systems in the first place? /boggle

I would think you read about prior to writing about them You both have come to some agreement on what you consider valid examples… I’m wondering what it is you read that made you come to these conclusions.