The Player class problem

• The model data. This is usually a position and a velocity, a collision rectangle, and perhaps also an "is touching floor" boolean or a "duration airborne" number. This is certainly not a player-only set of attributes, so you can move it out of the class.
  
• The model evolution rules. This is how the model evolves over time. This usually involves applying gravity, integrating acceleration into velocity and velocity into position, and perhaps increasing the "duration airborne" value. This doesn't have to be part of the player object.
  
• The model interaction rules. This is how the model reacts to world events, such as collisions. For instance, colliding with an object moves the player back and in some conditions resets the "touching floor" and "duration airborne" values. This can also be moved out.
  
• The model control rules. This how external considerations (player input, AI) affect the model. For instance, "move left" and "move right" change horizontal velocity, while "jump" sets vertical velocity and the "is touching floor" property. Keys may have different effects depending on the duration airborne.

• Data: No behavior, simply positional and velocity values, a collision shape and possibly some extra data.


• Evolution: Transformation of the movement over time based on the physical properties of the environment (you fall more slowly in water). Does not change the position, simply the velocity.


• Interaction: Changes the position based on the velocity and obstacles. Dispatches collision messages when they occur.


• Control: Changes the data based on external actions (user input or AI decisions). This is entity-dependant, and the player's movement controller still handles walking, running, jumping, shooting and swimming, although at a lesser degree. Or do you have different model control rules for the different actions?

Entity player = new Entity();player.AddComponent(new MovementData() { Position = ..., BoundingRect = ... });player.AddComponent(new MovementEvolution() { Gravity = ..., AirFriction = ... });player.AddComponent(new MovementInteraction());player.AddComponent(new PlayerControlRules());void MovementEvolution.Update(){    GetComponent<MovementData>().Velocity += Gravity;}void MovementInteraction.Update(){    MovementData data = GetComponent<MovementData>();    if(IntersectsOtherEntities(data.shape, data.velocity)        FireIntersectedEvent(intersectedEntities);    else        data.Position += data.Velocity;}void PlayerControlRules.Init(){    AttachToEvent(GetComponent<MovementInteraction>().IntersectionEvent);}void PlayerControlRules.Jump(){    MovementData data = GetComponent<MovementData>();    if(data.IsLanded)    {        data.IsLanded = false;        data.Velocity.Y = ...    }}

Quote:

Original post by Trillian Evolution: Transformation of the movement over time based on the physical properties of the environment (you fall more slowly in water). Does not change the position, simply the velocity.

Quote:

Interaction: Changes the position based on the velocity and obstacles. Dispatches collision messages when they occur.

Quote:

Control: Changes the data based on external actions (user input or AI decisions). This is entity-dependant, and the player's movement controller still handles walking, running, jumping, shooting and swimming, although at a lesser degree. Or do you have different model control rules for the different actions?

• Underwater, swim up.
  
• On the ground, jump up.
  
• Airborne, move up until airborne for a certain duration.

public Handle AddPlayerToWorld(PlayerControls controls){  PhysicalObject obj = new PhysicalObject(); // Stores pos/vel/acc  Handle removalHandle = new Handle(); // So we can remove the object  removalHandle += this.updater.Add(new PhysicalObjectUpdater(obj));   removalHandle += this.updater.Add(new PlayerController(obj, controls));  removalHandle += this.collisions.Add(new PhysicalObjectCollisionHandler(obj));  removalHandle += this.rendering.Add(new PlayerRenderer(obj));  return removalHandle;}

Quote:

Original post by Trillian The difference between evolution and interaction is still a little foggy to me. If friction has to be part of interaction, and maybe gravity as well (imagining a game where gravity could change), then what is its purpose? Now, in your last post, you said that evolution changes the velocity by the acceleration (which is in the data, I guess?) and the position by the velocity. But, as evolution has no knowledge of the environment, it could move the object into walls, which is unintended. In order for it not to move object into walls, interaction would have to always run first to ensure that the velocity will not be enough to allow evolution to move it into obstacles. That's why I don't see the benefit of splitting evolution and interaction, I can't understand how they could work in isolation. Maybe you could post a few samples of tasks best handled by evolution?

Quote:

As for your sample code, I don't see how you're splitting evolution and interaction. Does the PhysicalObjectUpdater handle both? And is the PhysicalObjectUpdater responsible for submitting intersection events to the collision manager?