Resources for Entity System in jMonkey?

[simar_i3r]

@pspeed said: The mesh is visualization data. Associate it with the entity in the visualization layer.

I have provided a fully working example that illustrates this. Just hit the Zay-es links page and look for Asteroid Panic.

I have one more querry that will let me settle many of my other class of actions in my game. How should I handle pick/place with entities/components and systems.

Steps for pick and place.

1. When I click(with crosshairs) a spacial, the mesh disappears (with ray casting)
2. When I click on another spacial (say horizontal surface), the mesh appears on the new position.

How should I implement this:

1. I should remember the state that I have picked.2
2. When I click a spacial, event gets triggered, what should be next course of action?
3. How should I reach to entity concerned when a spacial gets clicked.

Please help me design the broader picture. How this can be achieved?

[pspeed]

@simar.i3r said: I have one more querry that will let me settle many of my other class of actions in my game. How should I handle pick/place with entities/components and systems.

Steps for pick and place.

1. When I click(with crosshairs) a spacial, the mesh disappears (with ray casting)
2. When I click on another spacial (say horizontal surface), the mesh appears on the new position.

How should I implement this:

1. I should remember the state that I have picked.2
2. When I click a spacial, event gets triggered, what should be next course of action?
3. How should I reach to entity concerned when a spacial gets clicked.

Please help me design the broader picture. How this can be achieved?

Presumably, clicking on an object means that the player has picked it up?

Step 1:
Player clicks the mouse… you detect the object has been clicked and so check its UserData for the entity ID.
If the player can only hold one entity at a time then maybe you have a “Holding” component attached to the player that points to this grabbed entity. Then remove the Position from the entity so it doesn’t appear in the world anymore.

Step 2:
Player clicks the mouse on the ground somewhere so you check to see if they are Holding something. They are in this case so you give the held entity a Position (where they clicked) and then remove the Holding component from the player because they are not holding it anymore.

When the system you have that is handling your spatials sees that step 1 has removed its Position component then it will detach the relevant spatial.

When this same systems sees that the Position component has been added back then it adds a spatial back to the scene (maybe the same one if you have a cache, or maybe a newly created one… doesn’t really matter)

If you are using something like Zay-ES then that system has an EntitySet containing all entities with Position and ModelInfo (or whatever). So it will see entities come and go from that set.

[simar_i3r]

@pspeed said: Presumably, clicking on an object means that the player has picked it up?

Step 1:
Player clicks the mouse… you detect the object has been clicked and so check its UserData for the entity ID.
If the player can only hold one entity at a time then maybe you have a “Holding” component attached to the player that points to this grabbed entity. Then remove the Position from the entity so it doesn’t appear in the world anymore.

Step 2:
Player clicks the mouse on the ground somewhere so you check to see if they are Holding something. They are in this case so you give the held entity a Position (where they clicked) and then remove the Holding component from the player because they are not holding it anymore.

When the system you have that is handling your spatials sees that step 1 has removed its Position component then it will detach the relevant spatial.

When this same systems sees that the Position component has been added back then it adds a spatial back to the scene (maybe the same one if you have a cache, or maybe a newly created one… doesn’t really matter)

If you are using something like Zay-ES then that system has an EntitySet containing all entities with Position and ModelInfo (or whatever). So it will see entities come and go from that set.

Thanks!!
I got it all. If you want feedback, I would suggest this type of workflows is what zay-es wiki needs.

This is what I wants to do…

This means that we must Attach/ Deattach/ change components during events. The systems that monitors continuously will perform the actions as required and as per the entity(with attached components). Say for example if I have a mobile phone, they system will find out whether display components is attached or not. If its there it can play a certain animation (say switch on) before removing it from scene. Similarly I can do for other components.

When the object gets picked I will move the game to another appstate, where I can interact with the object, shake it, rotate it etc. Many of these will be just animations. I guess, I will do this by checking components attached with the entity. I will play these animations in the event only without any systems.

When placing back, again I can assign position component as per my needs. Say for a drawer, I will set the position component to be some point inside it, for a box I can assign position component to be some point on top of it. This way I can handle my pick and place as per my needs, depending on the mesh and its properties.

[pspeed]

For reference and/or further investigation, here is the app state that handles adding and removing spatials for the Asteroid Panic game:
http://code.google.com/p/jmonkeyplatform-contributions/source/browse/trunk/zay-es/examples/AsteroidPanic/src/panic/ModelState.java

If you want to try the game out, you can get releases here:
http://code.google.com/p/jmonkeyplatform-contributions/source/browse/trunk/zay-es#zay-es%2Fexamples%2FAsteroidPanic%2Frelease

[simar_i3r]

I’m looking at it already.
Thanks for your help!!

[simar_i3r]

I hope zay-es and other es systems does not become a overhead for android due to the kind of implementation that they have (Systems running continuously in update loop).

[toolforger]

All games run continuously in an update loop
Mildly old Androids have trouble keeping up with programs that generate lots of inaccessible objects, their garbage collection is bad for that, maybe that’s why people think continuously running loops are bad on Android. But you can avoid generating (and losing) objects by doing as much in-place updates as possible.
(In-place updates tend to get fragile for large and complicated data structures, so this doesn’t scale for all projects. But then the data structures for an ES tend to stay relatively simple, so YMMV.)

[atomix]

@toolforger:
You got a “right and concise” point there: The data structure of ES “can be cache efficient and naturally be an objects pool” is a wise sollution for Android and mem trouble some devices.

Even pure data ES replaced with new object frequently; it still better than pulling a object out of no where randomly. So the trade off between do it “discretionary” but “arbitrarily” or “limited way” but “assured” is clear.

Anyway, other aspects should be under heavily concern if trying to do mobile games: Its layers and its indirect linking overhead. As my experience, i always count in “battle tested” and “bullet proof” collection libraris to put my trust if I do mobile games. Sometimes home grown collection crash randomly because of memory troubles. Without a method to inspect and profiling the game on the phone, you almost doomed. Note i’m talking about pretty “big” game, which may need ES anyway. For smaller game, when even normal OOP paradigm work well, ES should not procedure any problem i suppose.

[toolforger]

I doubt that cache locality helps that much in Java.
Even with a HashMap<Id,Vector3f>, the Vector3f data will be scattered across the address space. (The Id objects will be scattered, too.)

One could do better with a home-grown long->Vector3F hashmap where the Id is a long, but you’re quite correct - it’s somewhat hard to iron out all the kinks in a container data structure, one should expect to invest several person-months into getting them right. (I think the Collections library took several person-decades.)

[atomix]

@toolforger said: I doubt that cache locality helps that much in Java. Even with a HashMap<Id,Vector3f>, the Vector3f data will be scattered across the address space. (The Id objects will be scattered, too.)

It's not the case, Android's dalvik and the standard JVM share some same concepts in handling memory i believe (not the way their implemented them) .

The problem of fragments is not because of object address are scattered, but the way the allocation command of the JVM are queued and executed, it’s like be more effecient to allocate and aquire all of them in initial run, then handle with a pool or a map. Some underlying details also not very clear for me, but as “my company” use to do native memory allocate; aquire at first consider the most obvious solution. Read here for some insight:

http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/vi//events/io/2011/static/notesfiles/MemoryManagement.pdf

One could do better with a home-grown long->Vector3F hashmap where the Id is a long, but you're quite correct - it's somewhat hard to iron out all the kinks in a container data structure, one should expect to invest several person-months into getting them right. (I think the Collections library took several person-decades.)

It’s not just about the functions of the Collection that save you but the performance and the stability of it. That’s why I still take careful steps to Zay-ES and other ES like Artemis for example. Because the ChangeSet, BitSet codes still written straight up, with no “good” comments (explain why It work like so) and a lot of bad comments (“changed because I feel bad some time”). Not to mention I’m also not a gurus of such things to understand if it was a brilliant idea just after reading them.

[pspeed]

At any rate, to the OP, in Zay-ES you only loop when you’d need to loop anyway. Otherwise, you are just checking for changes. I think only one system in Asteroid Panic loops with every update and that’s the physics loop that would need to loop anyway.

Edit: collision system does too… so only two systems I think.

[toolforger]

Something doesn’t quite connect here.

The only way of cache efficiency that I’m seeing right now is CPU cache locality.
I.e. keep all position data in one component so if you need to iterate over all positions, the iteration loop won’t pull so much unrelated interspersed data into the CPU’s L1 cache (which is typically organized in “lines” of 64 bytes fetched from contiguous RAM addresses).

For the heap management points you’re rising, yes newer Androids do a better job at managing memory, but I don’t see that affecting ES vs. non-ES at all - either way, you have lots of small objecs, and either way, you try to avoid creating and forgetting lots of them if you still target older Androids.

But… well, that’s what I understood, which isn’t necessarily what you meant.

[atomix]

Ehr, well I’m talking about software caching technique:

You have an object, that should be retrieve a lot of time but not changing internally. You save it to so call a “cache”. After a while, when it expire, it’s disappear like it should if no attention and interest on it recalled.
A lot of thing in game are modeled with states and in run-time we switch between states. With a pure data ES, you can definitely change the component but not make it hollow right away but cached it if need. So when you want to retrieve the same component (with that old data), you retrieve that instance from the cache. Because in ES, the reference it’s not really matter compare to its real data. That’s why it’s “cache efficient” much more than the same Entity in an ORM Database term.

So in fact we are talking about two different things.

[toolforger]

Ah okay, I understand.

It’s a trivial kind of support though. The ES gives me the HashMap that I need to do the caching, but that’s just a one-liner. The really complicated stuff with caching - releasing old stuff, noticing invalidated cache entries - would need to be coded in exactly the same way, whether it’s an ES component or a dedicated cache.
In a dedicated cache, I can do a WeakHashMap to allow the JVM to release cached stuff if it isn’t in use currently. In the (rather specific) case that you need that and the ES doesn’t have a way to use a WeakHashMap instead of a HashMap, the ES will actually be more complicated because the component will have to store the key instead of the cached object directly.

So my current thinking is that this is not an area where an ES will show benefits.

The areas that I do see are

• advantage: no impedance mismatch if saving to a database
• advantage: easy identification of components that need to go over the network
• advantage: easier component mixing-and-matching
• disadvantage: less guarantees about what components go together
• disadvantage: interacting components need to deal with the case of a missing “other” component
  I guess whether some set of class members should really be a component depends on how relevant these points are for that set of class members.
  E.g. if you want mixing-and-matching, you don’t care much about guarantees or availability, because, duh, you want to be able to leave a component out.
  I think the database and networking aspects are relevant in that components are supposed to be dumb data, which is already close enough to what databases and network sockets can handle to make the serialization trivial. Substantially better OO serialization support could eliminate this, e.g. db4o pretty much covers everything (it even solves network replication, though probably not in a fashion useful for a real-time game).

[atomix]

@toolforger said: In a dedicated cache, I can do a WeakHashMap to allow the JVM to release cached stuff if it isn't in use currently. In the (rather specific) case that you need that and the ES doesn't have a way to use a WeakHashMap instead of a HashMap, the ES will actually be more complicated because the component will have to store the key instead of the cached object directly.

because the component will have to store the key instead of the cached object directly.

… look like you do a guess here, “component will have to store the key”, is implementation depend.

So “Cache” can be considered as “how to retrieve an old created object efficiently” or more realistic and helpful “how to query- ask for a computed result again efficiently”.

Provide Cache method as a ChangeSet also an implementation among of others. but it’s obvious and efficient. Some ES, ORM did implemented ChangeSet, and have some special data structure, mostly in form of “key-value” collection to help better query, better lookup. Serialization come last, because I don’t want to go to deep into detail.

As my experience, some entity system implementations for game, especially mobile game (private used) is not very “generic” and “pure”. They use a lot of hard-linked group of Components, Aspects to have better query and better cache result. For things that should be retrieve in say 100 frames, they cache them like they should [Note: it’s very practical and useful to profile and tuneup upon run-time data and performance to see how much CPU, GPU through put and delay duration is appropriate, 100 is an bad example].

For example: We have thousands of Soldier NPC, each have 3 State(s) in a FSM AI, Stand, Run, Die. Stand and Run is used a lot from time to time, to create them from a “Template” or “Prefab” in real-time is not suitable because of number of creation for thousands entities is affordable. Therefore, using a cached component seem to be suitable in this scenerio. And also because “Component” in ES (if doing right) will almost have a “stateless” “memoryless” “timeless” attribute, they are very suite for this kind of job- so call cache efficient. And because of “stateless” is a little bit better than ORM’s Entity, whose component have to be stateful to support transaction and object-database synchronization (I’ve never tried db4o).

In my POV, talking about cache in ES, we’ve moved from concept to practice. A lot of “real” usecases refuse that “generic solution” is helpful but the mixing solution such as bringing cache and problematic hard-link, ad-hoc scripted link components and stuffs (dangerously break ES contract for concurency), Unity is one obvious example… but hey, we are making game anyway, aren’t we?

[toolforger]

I was assuming that you’re reusing the ID-to-component-instance hashmap as a cache. In that case, directly linking to the object is possible but you don’t use object pointers but entity IDs to link up the components that belong together.

If you don’t, then I really don’t understand how an ES helps caching - what it cached, where is the cache, how is the cache managed?

Also, I don’t understand how a component would be stateless/timeless with a pure ES.
You can make it so that this is the case, but that’s not ES-specific anymore, you can do that with OO-style data easily as well, so stateless does not imply ES.
The other way round, ES implying stateless, does not hold either: The core of an ES is segregating the components out from the OO objects and putting them into per-component-type hashmaps, and tieing them together via the entity ID; this is unrelated to whether the data is mutable or not.
(I’ll grant any day that using immutable data does have its advantages, but that is a general observation that seems independent of whether you’re using an ES or not to me.)

I understand “memoryless” even less. Even constant values need memory.

[atomix]

you’re reusing the ID-to-component-instance
… I’m not said so, i did say i want to retrieve the component by “the way it queried” or “computed”. via ID is just a simplest case.
ex:
a) I want to get back the “AStateLikeComponent” which “inside” of this Entity in the last 100 frame.
b) I want to get every Entities with this Aspect (defined as a group of components together)

ES help because the way an Entity layout its Component is very simple, that’s a flaten table. So to answer the question
a) The Cache save ID-to-component-instance entry to a “so call” Map. HashMap, or what every “key-value” dictionary is acceptable. If the situation happen in a relational database, you can see it as you just save the two index into a table “tblCache” along with a “type” or “aspect” field. The return of the component are also very simple as replace from that “tblCache” table to the in use table - the Entitie’s bag. ES is better than OO because there is no “deep” clone in any form here.

to answer quesion b) ES help because ES come with a simple “view” concept. “View concept” included so it’s also very easy to watch processes happen upon the ES data. I’m not going to mention “Processor” concept because it’s still under debate but say affectors to components are provided with “managed view” of ES components. If it change, remove, add or do anything in the “managed view”, the “view” will “reflect” into the real data and so on. The same thing happen in a common relational database. That’s why providing a “ResultSet” or a cached view is also simple and trivial. You almost can not see the design of ES win over OO in this point because it’s just come with a “view” as it’s supporter not defined to have such supporter.

• Stateless mean the state (changed status) is not exist or really matter for other functions to work over it. Every wheel component with size 4 will result the same in the gameplay, whenever it was replaced 10 times. Mainly because of no external reference.
• Timeless mean the time of creating, removing is not important, matter in the context, or for the functions to work over it. Because it’s managed, every system to do any contact with Component is via a “ensured working duration”.
• Memoryless mean the repository where the things is saved is not matter or transparent to the above. Mostly! Almost every System work with the facade of the Component not where is sited, how it’s located, when it’s binded and the a-like resolutions. Therefore the Component in the ES is also “memoryless” for its system, but of course it cost memory

Staless and Timeless is almost obviously help “Cache” because it can work under the hood and no one ever care!!! It’s can be as simple, as embeded as Object pool or a HashMap,… a ChangeSet, can even be event based collection (see Actor framework)
Memoryless helps mainly because of where/when the Component is located/layouted is not matter. a Cache can be obviously saved Component into simplier form to save memory, like Serialized it, run-length or batched save 500 of it and index, whatever zip algorimth you can call out.

I thought you want to talk more about concepts. I did try to raise some concepts, the nouns are not really obvious in this context thought.

[atomix]

After read my post, I realize that I still unclear why i compare ES and ORM:

ES is anti Object term. and ORM (Object relation mapping) is a efficient kind mapping between Object and a table. Which happen to be a “in between” of object oriented and “flatten layout data structure” like ES’s way of layouting its Components.

ES indeed assemble a lot of database concepts and its wisdom. but it’s much more simplier and least sotisphicated. A common database system also have “View” and “Trigger”. ES was born to be a child of real-time application so its blurry admit the existence of “Trigger”. In pure data ES, “Trigger” become a “contract of failure” for concurency as we diccussed sometime.

So, (Timeless, Stateless, Memoryless) are concepts appeared to be the contrast between ES and ORM - so call a OO application which have a lot of similarities in form with ES (We can not compare two totally different things)

So hope you get my points.

[toolforger]

Ah, I think I got it: you’re focussing on the relational-like data structures that you can get by using an ES, and how that is advantageous when loading stuff from a relational data base.
Caching does indeed make sense in that context.

I’ve been missing that because:
a) I consider this a mere side effect of an ES - it’s a nice one that can be exploited in various ways, including caching RDBMS data, running free-form queries, so it’s definitely relevant if you do your persistence via an RDBMS.
b) It’s irrelevant if you do not use an RDBMS (I favor RDBMS-less solutions if possible, simply because the gap is so huge - an ES would close that gap, but I’d have to do everything as an ES, and I’m not willing to make that leap currently).

Scenarios for living without an RDBMS could be, from simplest to most demanding:
b1) you don’t do any persistence at all;
b2) the persistent data is so simple that you don’t really need a database;
b3) you simply serialize out the world state to disk,
b4) you use an object database like db4o.
That’s enough variants (some of them even realistic) that I think the database aspect of an ES should be treated separately from its flexibility aspect.
In particular, I wouldn’t highlight an ES as particularly “pure” if it follows the relational model more closely; the primary purpose of an ES is its flexibility after all.

[atomix]

@toolforger said:

Scenarios for living without an RDBMS could be, from simplest to most demanding:
b1) you don’t do any persistence at all;
b2) the persistent data is so simple that you don’t really need a database;
b3) you simply serialize out the world state to disk,
b4) you use an object database like db4o.
That’s enough variants (some of them even realistic) that I think the database aspect of an ES should be treated separately from its flexibility aspect.
In particular, I wouldn’t highlight an ES as particularly “pure” if it follows the relational model more closely; the primary purpose of an ES is its flexibility after all.

Yes, talking all about the concept but without embeding any implementation is hard, “almost” impossible. I admitted.

One should think about this carefully if they want to go wild.

Without RDBMS for a “big” Java system is like go to the “wild”, without electricity and water supply. Of course there are non-rdbms persistence solution out there but apply them with ES front end is beyond my imagination for now. Few months ago, I eventually think about Neo4j stream to ES front. It’s not for a game anyway but social-like simulation. So basicly ES is just the data management method I use for visual facilities. That’s JME3. In other hand, Cayenne is one of my favorite ORM work perfectly with ES front. So as my experience, I see ORM back, ES front is the best couple.

ES in-memory caching layer can be thick or thin depend on each application. Eg: As flavour of each developers, some may cache AI, cache particles, cache database related info, cache delay signals (to interpolate network positions etc…); some may not doing it at all.

For a common game, DBA layer is usually pretty thick (a lot of work in synchronizing) because we just save in dozen thousands cycles of simulation. And in my simulation situation, It was thick.

I’ve tried to make DBA thiner, less cycle, less System working on save to DB, less Aspects concerning, try to do single Component type concerning at once… ect. But it will increase peformance load, even overwhelming if there is no ES in-memory caching wisdoms evolve. So it’s quite a challange and also a need of shared wisdoms in this area.