Run And Jump Games

Building a Run And Jump Game From Scratch

The first thing people get wrong about platformer development is thinking it's simple. It looks simple because Mario made it look simple. Getting a character to run and jump without it feeling like garbage takes attention to details most beginners skip entirely. I spent three months on my first attempt because I didn't understand input buffering, and I'm not proud of that time loss. You need a game loop first. Not a fancy one. Just a basic frame update cycle that handles input, updates physics, checks collisions, and renders. That's it. If you're using Unity, Godot, or even plain JavaScript with Canvas, the structure is identical. The loop runs at your target frame rate—ideally 60fps for a responsive feel—and each iteration processes everything in a fixed order. Input before physics, physics before collision, collision before rendering. Mess that order up and your game will feel inconsistent across different hardware. Run And Jump Games rely on a state machine for your character. You have an idle state, a running state, and a jumping state. Each state has different movement values. The trick isn't the states themselves—it's how you transition between them. Here's where I made my mistake initially: I was checking if the player was touching the ground inside the update loop, and my jump would sometimes register while airborne because of frame timing issues. The fix was creating a boolean flag called isGrounded that only gets set to true during a collision check with a floor object, and only set to false after a defined upward velocity threshold is crossed. This prevents double-jumps from accidentally triggering.

The Physics You Actually Need

You don't need a full physics engine. A simple gravity system works fine. Give your player a vertical velocity variable. Each frame, subtract gravity from that velocity—typically something around 20 to 30 pixels per second squared in 2D space. When the player presses jump and is grounded, set the vertical velocity to a negative value like -10 to -15 depending on your screen scale. That's it. That's the entire jump mechanic. Horizontal movement is equally basic but more sensitive to tuning. Set a max run speed and an acceleration value. When the player holds right, add acceleration to horizontal velocity up to the max. When they release, apply friction to slow them down. Friction values between 0.8 and 0.95 work well—higher values make the character slide more, which feels floaty and imprecise. For tight platformers where jump timing matters, lean toward 0.9 or below. The counter-intuitive part: variable jump height. If you let players hold the jump button longer to go higher, you need to cut gravity's effect mid-air when they release. Check for button release during ascent, then multiply gravity by 2 or 3. This is how classic Super Mario Bros. works and it's what separates good platformers from mediocre ones. Without it, every jump feels the same and precision becomes impossible.

Collision Detection That Doesn't Suck

AABB collision detection is the standard. Axis-aligned bounding boxes. Your player is a rectangle, your platforms are rectangles. Check overlap on each axis separately. Resolve X collisions before Y collisions to prevent getting stuck in walls. I learned this the hard way when my player would occasionally phase through a ceiling by a few pixels on certain frames, which looked like a bug to testers until I traced it to simultaneous axis resolution. Use a tilemap for your level geometry. Each tile is a fixed size—16x16 or 32x32 pixels is standard. Store solid tiles in a 2D array. On each frame, calculate which tiles the player's bounding box overlaps and resolve accordingly. This is faster than checking every individual platform object and makes level design trivial since you can edit the array directly or use a visual editor.

Common Pitfalls and Where Things Break

The biggest issue I ran into was corner clipping. When a player runs into the side of a platform and is also jumping upward, they can sometimes squeeze through the corner gap between two tiles. The workaround is to add a small horizontal margin to your collision boxes—essentially making the player's hitbox slightly narrower than their visual sprite. A 2-pixel margin on each side for a 16-pixel wide character goes a long way. Test this extensively with tight corridors and sudden drops. Another problem: high-speed tunneling. If your player moves fast enough, they can pass completely through a thin platform in a single frame because the collision check only looks at the start and end positions, not the path between them. The fix is continuous collision detection or simply reducing max speed. For a run and jump game, you probably don't need super high speeds anyway. Keeping max horizontal velocity under 8 pixels per frame at 60fps prevents most tunneling issues without complex math. Limits of this approach: AABB collision won't handle angled surfaces or rotating platforms. If you need those, you'll have to move into swept sphere tests or use a proper physics library like Box2D. For pure flat-surface platformers though, this method is sufficient and lightweight enough to run on anything from a modern PC to a low-end browser canvas element.

The download and source code for a working minimal implementation is available on GitHub under the repository name simple-platformer-prototype. It's written in vanilla JavaScript with no dependencies, around 400 lines total. The README has setup instructions for running it in any browser. I've included comments on the gravity tuning section and the input buffering logic since those are the parts people ask about most.