See also: collision<\/p>\n\n\n\n
System: input<\/p>\n\n\n\n
The basics:<\/p>\n\n\n\n
Moving left – then flipping the direction<\/p>\n\n\n\n
Movement is context based – for example, the background moves when in an ‘over world’ type map (such as map in LTTP), but not necessarily if you are in a small room which will totally fit with the game screen (like links house in the opening scene from LTTP)<\/p>\n\n\n\n
always respond to current key that is being pressed (the ‘last key’ pressed<\/p>\n\n\n\n
if (keys.w.pressed && lastKey === ‘w’) background.position.y += 3<\/p>\n\n\n\n
keys.w.pressed = true<\/p>\n\n\n\n
lastKey = ‘w’<\/p>\n\n\n\n
determine if you can move there – then animate the char there – see porklike movement for an example<\/p>\n\n\n\n
Examples<\/p>\n\n\n\n
easing?<\/p>\n\n\n\n
calculate vector<\/p>\n\n\n\n
apply vector<\/p>\n\n\n\n
no gravity<\/p>\n\n\n\n
moving in 8 directions<\/p>\n\n\n\n
<\/p>\n\n\n\n
Platformer<\/p>\n\n\n\n
Hang time<\/p>\n\n\n\n
<\/p>\n\n\n\n
GODOT<\/p>\n\n\n\n
var input_vector = Vector2.ZERO<\/p>\n\n\n\n
input_vector.x = Input.get_action_strength(“ui_right”) – Input.get_action_strength(“ui_left”)<\/p>\n\n\n\n
input_vector.y = Input.get_action_strength(“ui_down”) – Input.get_action_strength(“ui_up”)<\/p>\n\n\n\n
JS<\/p>\n\n\n\n
– is there a clean and simple solution for this?<\/p>\n\n\n\n
\/\/Move the cat and keep it inside the boundaries<\/p>\n\n\n\n
cat.x = Math.max(0, Math.min(cat.x + cat.vx, canvas.width – cat.width));<\/p>\n\n\n\n
cat.y = Math.max(0, Math.min(cat.y + cat.vy, canvas.height – cat.height));<\/p>\n\n\n\n
velocity\/easing in\/out<\/p>\n\n\n\n
usually applied to movement, but could be for anything really<\/p>\n\n\n\n
snap to pixel<\/p>\n\n\n\n
\u201cWhile Link can move a single pixel at a time, in any direction, the longer he continously moves in any direction the more he gravitates toward aligning himself with the underlying grid of the screen. The tile grid for LoZ is 16 tiles wide by 14 tiles high (including 3 tiles for the status display at the top of the screen). Each tile is 16\u00d716 pixels. Link operates on a half-tile grid, though (32\u00d728 tiles, 8\u00d78 pixels each). As Link moves, if he\u2019s not currently aligned with the half-tile grid, he is adjusted, one pixel at a time, toward the closest correction. As a result, if Link is 4 pixels off alignment he\u2019ll line back up with the grid after moving 4 pixels.\u201d – from https:\/\/troygilbert.com\/deconstructing-zelda\/movement-mechanics\/#:~:text=The%20tile%20grid%20for%20LoZ,8%C3%978%20pixels%20each<\/a>).<\/p>\n\n\n\n This is somewhat the case in Earthbound too\u2026<\/p>\n\n\n\n has gravity<\/p>\n\n\n\n fixed ‘x’ position or not fixed (a range)<\/p>\n\n\n\n jump in ‘y’ position<\/p>\n\n\n\nFor SIDE ON ‘mario’ style games<\/h2>\n\n\n\n
Sub-pixel (fixed-point number) movement – ala mario 3<\/h2>\n\n\n\n