Hey, thanks for the great advice guys!
In deed a useful guide line!
I’m trying to split my code up like that from now on. How far should one take this aproach though? I mean you could even go as far as having two seperate applications talking to each other through a messaging layer even when only playing locally.
And should both client and server side share the same ECS data?
I think I will go in this direction (already tested it with basic forces and torques) but I’m thinking about having it more higher level, like not having individual Force components but rather components that represent control “intents” (e.g. MoveForward, TurnLeft, Jump, etc.) and the Physics system would take care of applying the forces accordingly. These intent components would then be created by a Control system that reads local inputs and deleted on the same frame after the Physics has consumed them.
That sounds in deed like a nice benefit! If I go the more higher level control “intent” route I think that would have the same benefit as well.
Thanks for the links, will have a closer look at that!
If I understand this correctly a “control driver” is basically a marker for controllable entities right? The Physics system would then have a set of those and apply forces accordingly? And what do you mean with “translated” input? I’m guessing it’s about converting individual key presses into a “move” vector variable for example. Sorry for my misunderstanding.
That’s the case for my game too, because I need some “stabilizers” for certain things for example. And that is also the point at which my first attempt at Force components got pretty hairy
After having tried the more low level Force and Torque components approach, I feel so too. As mentioned above I’m trying to implement higher level concepts of “intent” components now.