@pspeed said:
Blindly using ConcurrentHashMap really isn't enough because now you will have a problem of inconsistent state.
The code that handles the threading and updates in Zay-ES is the trickiest part. It has also been described elsewhere in nauseating detail so I won’t regurgitate here.
The long and the short of it, each EntitySet is its own view of the entities. If you follow the rule that components are immutable (and only swapped out when changes) then each EntitySet is a fixed snapshot in time until applyChanges() is called which updates the contained entities to the latest view. This can be thought of as reissuing the entity set query but it’s actually way way faster than that because of internal optimizations.
But conceptually, that’s a way to think about it.
@Jarky
each EntitySet is its own view of the entities I've read your concerns about ES, this is a little magic words to help you have your "ahha" moment quick.
EntitySystem concepts may be clear for you; its implementation may be not.
Here ZayES implementation use a kind of collection called EntitySet to manage a “view” of entities for its interesters (obsevers). And because components are immutable, the access to it via Entity are guarantied/ approved about available and consistent even in multi thread enviroment.
1 - Access compoments via a “view” or (considered) a “channel” called ChangeSet, in which all the operation of the EntitySystem are protected about the avaiable (if you just do this kind of access). Access in ZayES actually compose of 3 operations insert-remove-update(broadcast) basis similar to a common database! — Becareful, this is the main source of pain, even in ZayES currently!
2 - the immutable of component cause the “reference-level of isolation”, is a solution for atomicity in Java language, in which if a reference slot is replaced with another (commonly via assign operator) is a atomic operation of the language.
Ex: Entity.slot1 = compoment1 … Entity.slot1 = component2 …
to guaranty multi thread enviroment will not cause contention or inconsistent. Note that this is just one “simple” but “briliant” solution for the concurent problems. Ex: Trasactional model use different level of atomicity. Actor model use “local memory” mailbox to handle communication…You can try Gpars to experiments your own algorimth.
Those 2 above are 2 main featur2es of ZayES compare to others.
Naturally ES design try to eliminate random routines and access, and its restrict linking between components and other kind of “reference” from entity to component. In fact, it depend on you, as far as I know. ZayES are go futher by using best practise about immutable component. It’s fine, also ZayES is relatively small and efficient.
After reading ZayES source code recently, I’ve found out it not pure as in the beginning after integrate network facilities: It not consider “update beat” as its philosophy anymore, this is interesting!
It’s not mean at the very first commit, there is one regular “update beat” or a internal timer but there is not an internal listener.
http://code.google.com/p/jmonkeyplatform-contributions/source/browse/trunk/zay-es/src/com/simsilica/es/EntityComponentListener.java
This also marked by @paulspeed as the “wild” part of his design (beside of some another minors). :roll:
The ChangeQueue in other hand, it make me a littble bit disappointed. Again to keep ZayES is relatively small, it’s fine… or not 8-O ? .
First it’s the use of HashSet<Class>, the second is “types.contains( change.getComponentType())” is properly not very efficient? 3rd, Generic Type can confused the system?
[java]
protected class QueueChangeListener implements EntityComponentListener {
private Set<Class> types = new HashSet<Class>();
public QueueChangeListener( Class... types ) {
this.types.addAll(Arrays.asList(types));
}
@Override
public void componentChange( EntityChange change ) {
if( types.contains( change.getComponentType() ) ) {
add(change);
}
}
}
[/java]
After a while reviewing his code, i also tent to write my own ES with annotations, Guice and Guava for better scale, higher performance and better internal communicating. But it come with cost.
For short, there is no “rules” to follow. Be wild, and learn from others, share knowledge. That make you better indeed! Cheers,
now consider you have over 20 yrs developed Java and you teach your kid to use: