PRJ-Motion:MechanicsAndFlow

Motion: Mechanics and Flow

This is a poorly written up page on the mechanics and flow of Motion. This is written for later use when C is in a better position to properly exercise his theories. All of this applies to the player objects in the game.

This does not address VIP things like the player state or frame rate.

Various Variables

• bool run
• bool lockJump
• bool inAir
• bool wallJumpAble

• float walkVel = 2.0
• float runVel = 2.75
• float jumpVel = 4.5
• float runJumpVel = 5.1

• float gravity = 0.20

Collision

Collision in Motion is detected on a tile by tile basis. The game flow checks the tiles, not the pixels, that the player's hitbox has collided with. Typical collision with a tile from the sides- that is, the tiles left and right sides- reduces player's horizontal velocity to zero so that the player doesn't go through the tile on either side.

Similarly, the tile's collision is checked from the top and bottoms and sets the player's vertical velocity to zero so that gravity doesn't push them through the ground, or so that the player doesn't jump up through the ceiling. When the bottom of the player's hitbox is touching the top of a tile, the player is not considered in air. So, inAir bool would be set false.

Walking and Running

Self explanatory, for the most part. A global variable determines the player's movement speed for when they press the left and right buttons.

Running, however, can actually be implemented two ways:

Double Tap Run

"Double Tap" Run is the sort of run mechanic seen in the Kirby series or in Super Smash Brothers. Basically, you double tap a direction to run.

A bool for running is set up. When the bool for running is set false, the player moves with their globally defined walking speed variable. When true, the player moves with the defined running speed variable.

A timer is set up during the initial movement button press. If the button is pressed again during that timer and held, a bool for running is set true, then the player moves with the run velocity instead of the walk velocity. The running bool remains true as long as the button is pressed and held.

Hold Button Run

"Hold Button" Run is seen in most 2d platformers, like Donkey Kong Country and Super Mario Brothers. Of the two, it is easier to implement because it simply adds a check for a button being pressed before deciding which movement speed variable to apply to the movement calculation.

A bool for running is not necessary, but recommended anyway for later mechanics checking movement speed.

Acceleration

To create acceleration, instead of having a base movement velocity, you have a smaller velocity that that gets incremented into the movement speed by a check. Movement speed is checked against a defined max speed. If movement speed is less than the max speed, the movement speed is incremented. Otherwise, the calculation stops incrementing and defaults the movement speed to max speed.

Jumping

In the case of having a run mechanic, a second global variable for jump velocity should be set. So you have jumpVel and then runJumpVel.

Button is pressed and jumpVel is applied to player object as long as button is held down, allowing for variable jump height- short hops and high jumps. With a run mechanic, there is an if/else or switch check to check whether or not run bool is set true. When run bool is set true, you'd instead apply the runJumpVel.

Once the player has jumped, a inAir bool is set true, and lockJump is set true. If lockJump is not set, the player gets infinite jumps in the air.

Wall Jumps

The player's inAir bool is true and lockJump is true. The player has also collided with a wall and a timer is set. A bool, wallJumpAble is set true and checked with inAir.

If both are true, then the player gets a Wall Jump with the velocity they had hit the wall with, but only during the timer.

Wall Stick/Slide

To make this appear more fluid (because the wall catching sprite is wider on either side than the usual sprite) apply a second hitbox when the player has reached appropriate velocity. Instead of checking the player's collision against the wall, it checks the slight extension of the box.

When this hitbox touches the wall, the player's horizontal velocity is set zero, but their vertical velocity doesn't change, meaning they will slide up and down the wall on that extended hitbox. During this time, wallJumpAble is set true, and lockJump is false, meaning the player can jump again off the wall.

To make the wall jump seem a bit more realistic, do a check on the player's vertical velocity. If the player's vertical velocity is still increasing, the player's wall jump has more velocity away and up from the wall from the wall than if they were sliding down it.