Some ES design questions

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.

1 Like

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?

1 Like

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.

1 Like

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.

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 :slight_smile: and it works perfect :smile:


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.

1 Like

Thanks so much.

I would like to see some patterns like

  • Decay system
  • Follow system (I use this a lot to let a camera follow main character or a lamp or what so ever)
  • Virtual link system (I have virtual id and a virtual link so I do not stick on pure entity id but can use names :smile: also for level design it is great to be able to give things names and beeing able to link to those names)
  • Visual system (yeah the one which add/remove/update models in graph)

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 blog and if you like the idea port it to your wiki.

1 Like

@ia97lies You mentioned about this book “Game Programming Patterns” in your blog which you finished reading it.
May I ask a question. :slight_smile:
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


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 :slight_smile: for example the command pattern to handle input action.

1 Like

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 :slight_smile: (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 :slight_smile: 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” :slight_smile:

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 :slight_smile: 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 :wink: 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…