Handling movement using an Entity Component-based System Architecture

Question

I have seen various descriptions of how to handle movement in a component-based entity framework. The most common I've stumbled across is the idea of using components called Controller, Physics, Transform, Velocity, and Collider.

The idea here is that the Controller influences the Velocity component when movement keystrokes are detected. The Velocity component in turn influences Physics. Once the simulation has been stepped, the Collider is either affected if a collision occured or is not if no collision happened. In the end, the Transform is updated with the new position from the physics simulation step and thusly the Renderable needs to be adjusted so it is drawn in the proper location.

I have often read that one needs to consider both physics-driven and non-physics-driven entities. As outlined in the above paragraph, manipulating physics-driven entities seems like a piece of cake. The difference with non-physics-driven entities is that the Velocity component values need to simply be applied to the the Transform based on delta-time. This would allow moving the entity without being concerned with physics nor collision detection.

For physics-driven entities, one simply iterates entities with both Velocity and Physics components. But for non-physics-driven entities, simply iterating over entities with a Velocity component isn't sufficient as it would include the above subset as well.

So there must be some factor that clearly separates these two cases. So with these two cases in mind, how would movement actions that influence the values of Velocity be carried out in such a system to manipulate both types of entities whether physics plays a roll in their movement or not??

And lastly, considering that there may be times where the transform for an entity needs to be manipulated directly, such as player clicking on a portal to be teleported to another x/y/z position, how would one properly propagate this change to adjust both the physics step simultation and the renderable's draw location?

EDIT: @bobenko Your explanations provide insight to the most common case where objects are simulated via physics but I'm somewhat lost on the Kinematic aspect regarding updating an entities position via a velocity value? Are you simply implying that some code of my own will apply movement to the entity via velocity, thus being Kinematic? I still am interested in your explanation on how to avoid cyclic notifications effectively when aspects of these components involved change.

For all who answered, I'm still not clear how would you handle teleporting an entity from one position to another? Would this involve turning off physics, teleporting the player, then turning physics on after teleport finished? Turning physics on/off can be as simply as setting the entity as Kinematic YES/NO, right?

Answer 1

With your Physics you subscribe to changes of your Transform component. So when transform position changed directly you Physical part also moves. And after physics simulation you can directly change Transform->position from Physics, because entities which have Physics will always have Transform.

What about direct moving of objects without physical simulation, you can use Kinematic bodies most of engines provides their support. Or you can directly write your position+=velocity in any your script. Or create some BasicPhysics component and then just adjust properties.

Answer 2

The basic setup for interaction with physical simulation has already been covered by user bobenko. I've implemented it more or less like this myself and it works fine.

However, a problem that occurs when multiple Components each add their own movement to the same object during the frame is that velocity is no longer a value you can simply store somewhere and set from the outside, as suggested by your Velocity Component. My solution was, in short:

• The Transform Component stores a velocity value, but doesn't apply it. This is just a "for your information" stat.
• If some Component wants to move the object (not teleport it), it wouldn't just set the position (obj.Pos += vel) but call one of several specific Move methods exposed by Transform. They remember the applied velocity in a local variable and accumulate it throughout the frame.
• Actually, the Transform Component stores two velocity values: One that is accumulated and one that is exposed for read access - the actual velocity value that has been determined last frame. When the Transform Component updates, the accumulator is written to the readout value and then set to zero.

That way, Transform isn't only a central place to store the current position and rotation values, but also a place where all the modifications done to them in one frame are gathered for public usage. I read those values out for velocity-specific effects such as the doppler effect for the sound system.