Each system operates on a set of entities. Usually the order in which systems are executed matters. A simple way to introduce multithreading to ES is to split the set into multiple sets each handled by a different thread. Once processing one system is done by all threads, another system can be executed in parallel and so on.
This can be done by a design and completely transparent to the programmer writing the systems.
Thatâs all JME-specific visualization stuff. To run it in another thread youâd have to have twice as much code constantly enqueuing things in the JME thread. It doesnât make sense. If feels like you are trying to find problems to fit a solution. Iâm not sure why.
Here, take sim-eth-es. Instead of running the GameSystemManager on a server, run it in your actual app using the GameLoop object. Tada: multithreaded systems.
Edit: because note that all of your current examples, being so heavily based on standard non-ES JME stuff, arenât going to make very good examples. BetterCharacterControl automatically implies that you are running JMEâs Bullet physic support which is quite likely already running on its own thread. It makes no sense (and buys you nothing except a lot of trouble) to try to multithread that. Itâs hardly doing anything but reacting to things ON THE SCENE GRAPH THREAD. There is nothing to put on another thread.
Maybe you should wait until you actually have a use-case instead of trying to manufacture one from things that donât fit?
Okay. I am going to wait for better use cases.
For now i have written a few systems for my game which all are view level systems.
I will not make any of those multi threaded (for now) as you said to avoid making much troubles for my self.
And the fact is i will have many view level systems in my game core library because my game will use jbullet for all physic stuff and also will use Accelerated library from The Leo for physics prediction.
Actually first i am writing my core library which i am designing for MMORPG games, then i am going to use that core library to implement my games.
There is not much game logic in core library but extensions to JME specific tools like physic , animation , ⌠and i should do my best to keep a good separation between them and ES. ES stuffs will show themselves when i start to create the actual game story.
And it seems it is soon for me to think of multi threading at the moment.
And thanks a lot for all your helps.
Also i could find some very nice tools from your SiO2 here
specially for sim package.
It would be great if you can add wiki for them and explain the concept .
I could not understand much from javadoc.
Thanks
I divided visual states in main thread and game logic stuff in another thread. game logic do not even need 60 updates 10 or so are far enough 
and it works perfect 
Yep, I do the same.
Yeah, I will get to it soon I hope.
In the mean time, the sim-eth-* examples use a lot of that stuff but especially the sim package.
Thanks so much.
I would like to see some patterns like
also for level design it is great to be able to give things names and beeing able to link to those names)patterns and not solutions because they mostly depend on the use case. Iâm sure you know more of them. I think that would be great (but also a lot of work). Maybe I start another series of blog posts on my http://fprintf.logdown.com/ blog and if you like the idea port it to your wiki.
@ia97lies You mentioned about this book âGame Programming Patternsâ in your blog which you finished reading it.
May I ask a question.
Are those patterns from book applicable for ES design ? Will they help you to better practice/manage with ES in your game ?
Want to know all your idea about it
Thanks
Not for ES in particular. It is all about OO desing patterns from the gang of four. But that doesnât mean it is useless! There is plenty of stuff beside ES in a game.
I personally enjoyed that book a lot for example the command pattern to handle input action.
But can components depend on other components? Say, you have component âgun batteryâ which stores, among everything, whatever container of components âgunâ. Then it possibly can calculate, say, overall firepower transiently, doesnât this mean âdoing stuffâ?
Thatâs another good question, does that mean that if youâre not using bullet and scene graph at all (say, server doesnât have to have to deal with whatâs related to rendering anyway) - you have to implement your own collision detector, collision shapes etc in pure math by hand?
This would be mixing both object oriented and data oriented. You could break it down and say the entity has component âgun batteryâ and component âgunâ - whatever result those two should output is calculated in the system that handles the result. There should be no logic inside components, only in the consuming services.
Yes. If you want to move entirely to the data oriented scheme, then you would have to implement a system that handles collisions (by detecting overlaps in collision shapes).
But if component âGun batteryâ is nothing but a combined set of other components, then you really dont need Gun Battery.
As has been correctly pointed out, thatâs an odd relationship for an ES based game. But Iâm also not sure I understand what you mean.
It sounds like there would be some kind of gun battery holding entity that then points to its gun holding entity children⌠but thatâs backwards.
Well, I mean gun component can be used by itself for a stand-alone gun, but also can be used as part of a battery. This is sort of hierarchy, yes. And if gun battery just summarizes data i.e. changes data representation, not modifying data itself - does this contradict ES principles?
The guns would have a component that pointed to the battery. Some system would have an EntitySet of guns that point to batteries and another EntitySet of batteries. It would loop over the set of guns that point to batteries and update its batteryâs stats.
Thatâs the data-oriented way.
Edit: note that it has the nice side effect that it is impossible to accidentally put a gun in more than one battery.
Hmm I need to try it this way, thanks for the replies!
You can still use bullet but with in a system if you want this for collision detection. The same for scene graph. You will then have - beside a model - also a collision shape component. The physic system is then interessed in all entities with Position and CollisionShape and sets the ne Position. I think in the end such a system is even easier to understand than in the OO way.
Thanks, I implemented a very thin detector already, which surprisingly works (though there are no compound bounding volumes, arbitrary rotated boxes and other hardcore stuff). Now I wonder about where to create new entities. Every time I think I finally understood ES, Paul gives me a brand new response that needs further thinking Now I am not sure again. Well, we have gun and target. Gun fires. Now the fired entity (say, a projectile) is created (and got its components such as speed, energy etc. populated) in system that handles guns. According to the Rules of Thumb⢠this system shall also handle projectile all the way till its disappearance, as if component with speed was created here it must be modified only here. So if collision occurs during the flight, I have to attach Collision component in collision detection system and then handle it again here in gun system. Wonât it be too much for one system? Funny, most of the questions that appear to me are not âwhatâ or âhowâ to do, but âwhereâ
I think you misunderstood it. The one which generates the bullet, doesnât need to handle the propagation. I used a Bullet System for that, but it turned out to be way much more generic and it was actually more a Move System in the end. The Bullet system do change the position upon tpf and speed the bullet has.
NOTE: My Bullet System has nothing to do with the physic lib bullet 
more with the topic that I move a bullet.
For remove the bullet I used a Decay System (I got that idea from @pspeed and it was gold, still my favorit system). The Decay system handles all Entities with a Decay component and removes the entity if that time is used up. My bullet needed around 2.5 seconds to cross the screen so it was save to delete them after 3 or so seconds.
Rule of Dump means you should not have two system which both change the Position! But the one which instantiate the initial bullet with Position, Speed, Damage, ⌠does not count of course (in my Invader game in my Blog article do spawn the bullet in the ControllAppState).
I hope it is more clearâŚ