2D Platformer Controls
This is Super Meat Boy. Super Meat Boy has good controls. When you die in Super Meat Boy, you know that it is your fault.
Be like Super Meat Boy.
Easy, right? I mean, the video game industry has been alive and well for 40+ years. There’s gotta be an easy-peasy lemon-squeezy magic formula for controls, particularly for such a fundamentally simple and long standing genre like platformers.
Well, not so fast. While jumping into making your first game, oftentimes the first major task at hand is figuring out the controls for a game. In my current project (a spiritual successor to Spelunky) I’ve spent the past week in my free time scouring the internet for the perfect code for platformer character movement. Turns out, while most games of those sorts out there have solid controls, they actually feel different and have nuances that set them apart.
What I’m trying to say is, there are multiple ways of tackling platformer movement, and each method ends up with a subtle and unique final result. I’ve found that there’s two easy methods for simulating movement in Unity and getting a desireable result.
Old School Movement
What sets this sort of movement apart is the instant velocity change. There’s no concept of acceleration — stop and go is immediate, which means that game will feel responsive, but also a little unrealistic. Aerial manipulation of the character is really easy with this sort of code. I’d argue these controls have learning curve, which may or may not fit your style game.
Realistic Movement
Acceleration is the name of the game in these sorts of controls. You can control how fast or slow the start and stop is, but what’s important to realize is that you cannot make this sort of movement instantaneous. Personally I think that this is the way to go, as it ultimately feels more organic and adds a nice learning curve and unique flair for games that hinge on platforming elements.
So why are they different?
Ultimately it comes down to using AddForce vs altering the velocity attribute manually. Luckily, both options support collision checks. The old school esque movement code alters the velocity attribute in order to immediately start moving in a given direction, but still uses force to cause the player to jump. Play around with it — either one could work for your game!
