The Scratch Wiki will be transferred to its new domain: https://en.scratch-wiki.info on the 16th of February, 2018, at 14:00 (UTC). Point all links to the new domain now, and be warned that this current domain will be frozen starting from 13:00 and will never be unfrozen.
A platformer is a type of game distinguished by jumping across platforms and avoiding obstacles. In order to make the game realistic, more advanced scripting must be used.
|Note:||This tutorial is geared towards users who already have intermediate knowledge of Scratch. For those new to Scratch, How to Make a Basic Platformer can be used instead.|
- Main article: Simulating Gravity
The most basic gravity script works like this:if <touching [ground v]?> then change y by (10) else change y by (-10) end
However, this causes the player to:
- Move at a fixed speed
- Jitter when it touches the ground
This allows the sprite to fall faster and faster, like in real life.
- Main article: Jumping
Jumping is as easy as this:if <key [space v] pressed?> then if <not<touching [ground v]?>> then //this is so you can't fly up set [speed y v] to  //can be any value, test different numbers
Ceiling DetectionLet's add to our "check ground touch" block: define check ground touch if <(speed y) <  > then repeat until <not<touching [ground v]?>> change y by (1) end else set [speed y v] to  end
That way, if the player is going up and hit a platform, the scripts don't push it through the platform, and instead it stops going up and falls back down.
The "check ground touch" block causes the player to walk up walls. To get rid of this, make a new custom block called move:define move (distance) //this is also "run without screen refresh" change x by (distance) set [slope v] to  //new variable repeat until <<(slope) > > or <not <touching [ground v]>>> change y by (1) change [slope v] by  end if <(slope) > > then change x by ((0)-(distance) change y by ((0)-(slope) end Every time the player left or right, it checks if the slope is higher than 8 (basically, if it moves you more than 8 units), if it is, it moves you back. Replace the "change x by ()" blocks with two of these.
HitboxesIf your player, avatar, etc. has arms, they will catch on the platforms (if your player is a smooth rectangle you can skip this). The answer to that is a hitbox. Create a new costume for your sprite and make it a filled rectangle about the size of your normal costume (the one it's showing). Then update your scripts like this: when gf clicked forever switch costume to [hitbox v] ... //other scripts switch costume to [regular v] end
To simulate momentum, it needs a gliding effect - after you stop pressing the left/right key, it "glides" to a stop instead of stopping right away. First, update the "move" block - replace the "change x" block with a "change speed x" blockdefine move (distance) change [speed x v] by (distance) //replace with this ... //the other scripts
Then, after the "check ground touch" block, add:when gf clicked forever switch costume to [hitbox v] change [speed y v] by [-1] change y by (speed y) check ground touch::custom set [speed x v] to ((speed x)*(0.8)) //add this! change x by (speed x) //and this! ... end
What this does is slowly (but not too slowly) speed up when you are pressing the key, and slowly lose speed when you let go.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
Paradoxically, it’s often the same problem behind these 2 feelings: a lack of reactivity to the player’s inputs and a lack of precision.
My goal here is to help novice game designers (and maybe more experienced ones) to avoid this kind of control feelings if they don’t want it. But keep in mind having reactive and precise controls is not an obligation and won’t work for all the gameplays.
So, after this little clarification, let’s talk about the common reasons which could, in my mind, contribute to this feeling:
Priority to animations
What the first Prince of Persia, Another world and Dark souls have in common? Yes: the priority to player animations before the player’s inputs. If these 3 great games build their gameplay with this constraint, maybe it’s not what you want for a “reactive” game.
For more details, when animations have “priority”, it will be impossible for the player to do some actions while another animation is still running:
Hopefully, it’s very simple to avoid: give full priority to player’s input, even if it cut your character animations.
This issue may appears as obvious for experienced designers, but always good to remind it!
Low ground friction
What I call friction is a strength applied on the character speed, when the player releases the stick, on its opposite direction, until he’s stopped.
Yes, having a small ground friction is very cool, especially with a beautiful breaking animation! But when your player takes 0.5 seconds to stop at full speed, it’s most of the time too long!
Except for ice platforms or for a skateboarder character, be careful with too low friction on the ground and don’t hesitate to increase it.
No reactivity when changing direction
If you use a classic system to move your player on the ground, with run acceleration, maximum speed and friction to stop itself, maybe you noticed a result you didn’t expect when you suddenly change direction: the player is not reactive and needs some time to go the other way.
Let’s explain with a 2D platformer. The speed computation each time laps is:
(with a maximum speed limitation of course!)
If the player gives a “right input”, the acceleration is positive and speed increases in positive à the character moves right.
Now, if the player gives suddenly a “left input”, the acceleration is now negative and speed progressively decreases from positive to negative à the time the speed takes to move from positive to negative, the player slows down progressively to finally go left. With a little scheme :
So, now, what’s the solution? Actually it’s pretty simple: you just have to use a “reactivity percentage”.
What I call a “reactivity percentage” is an extra percent of acceleration when the player gives an input in a direction opposite to the actual speed:
And with a scheme :
This solution can be used in 3D environment too, with a little modification as a direction can be “more or less” opposite to one other. The idea is to apply a ratio to this acceleration percentage, relating to the “amount of opposition”:
(0 is the same direction and 1 the complete opposite)
Non-analog speed on analog stick
Some games use 2 values of speed, often a “walk” and a “run” one.
If this solution was evident on 8 and 16 bits consoles with a directional cross to control movements (by default, the player walks and, holding a button, the player runs), it seems not logical with analog stick on modern pads : as your thumb move on the stick is progressive, you expect a progressive speed too.
Having only these 2 values with an analog stick don’t always result with a “rigid” feeling but, if the values are too far from each other, the player will feel this “step” at stick midcourse.
Analog speed is quite simple to implement as most of commercial game engines have a -1 to 1 value for each axis. So, you can determinate your current maximum speed setting a “maximum” maximum speed (the maximum speed when your stick is all to the right/left):
And it’s always a good idea to think about modulate the acceleration the same way.
Having a little bit too low gravity value can definitively give you this feeling of limp controls, like if your character was a feather or was on the Moon.
It can be a choice but, sometimes, designers lower the gravity to make the platform challenges easier (or keep the Earth default one, 9.81m/s, not adapted to their objects dimensions). It’s a possibility but keep in mind you risk to lose the “weight feeling”, which is paradoxically important to succeed in platforming challenges.
Air control (acceleration in the air) not tweaked
Air control (ability to move player on the horizontal plan in the air) is something not realistic at all. But realistic behaviors are not always fun in video-games and, for a platformer with jump challenges, you’ll probably need some air control.
If acceleration parameter on the ground must be carefully tweaked, it’s all the more true for air acceleration (because the player is falling and don’t have all the time in the world to react):
- Too low air acceleration won’t give player a chance to correct his trajectory in the air and he’ll have a feeling of “heaviness”.
- Too fast air acceleration will be tricky to measure for the player
And, obviously, low air acceleration will multiply the “weight” feeling of a high gravity value and a fast one the “floating” feeling of a low gravity.
So, gravity and air acceleration should probably be considered and tweaked together.
However, be careful to not always “compensate” high gravity with a high air control and vice versa, sometimes it could be better to keep consistency between the 2 values. And don’t forget “extreme” values can lead to great games with strong identities:
A non-analog jump solution, namely only one jump height without any possibility of modulation, is frequent, even in modern and AAA games. First, let’s be clear on what is the difference between what I call an analog jump mechanic and a non-analog one:
In some games, like AC or GTA series, it's not a problem to have non-analog jumps, because they’re not focused on jump challenges and the game want to keep a “realistic” mood. However, in “jump-centric” games (like Super Meat Boy, Mario or Sonic series), being able to “cut” your jump in the air is essential to succeed in some challenges (like jumping under a spiked ceiling). In addition, it contributes to have a feeling of reactive controls.
Implementing an analog mechanic could be a little bit tricky. My solution as a designer is directly inspired by the one used in Sonic (thanks to the “Jump velocity” part of Sonic Physics guide): assuming you use an impulsion speed to jump (letting the character falling back step by step with the action of gravity), the idea is to define a “cut jump speed limit” and, if the vertical speed is superior to this limit when the player releases the input, set the vertical speed equal to the limit. If the speed is inferior to this value, it means the character is close enough to fall back and it’s not necessary to decrease “directly” the jump speed.
Of course, you’ll need some tries to find the good value for the “cut jump speed limit”. As the value is linked to your gravity, for me a value of “gravity / 10” worked well:
verticalSpeed = cutJumpSpeed
No tolerance for jump calls
Naturally, you want your character to be able to jump only when he is grounded. But if you strictly use this condition, you will probably encounter some lack of reactivity feelings. Indeed, if the player calls for a jump a few frames just before the character touches the ground (and it’s often true, because the human brain tends to anticipate too much the action), the call won’t be considerate. The same way, if the player wants to jump when the character reaches the end of a platform, he may reacts just a few frames too late while the character just start to fall. Clearer with a little scheme:
The perception of the player can make him think he was able to jump, even if technically it’s not true.
To avoid this perception, the solution is to add a “tolerance”, which means:
- A jump call is registered when the player gives the input AND the character is close enough to the ground. So, as the character touches the ground, he will jump again :
- When the character falls from a platform, there’s a time delay during which he can jump when in the air if the player gives the input :
No abilities when jumping
The sensation of "high reactivity" appears when having an immediate result of your inputs on the screen. Yes, it seems obvious but, playing Skylanders Swap Force, I was surprised to be unable to attack when I was jumping: no animation or sound feedback, just no response to the attack button when in the air.
In a platformer, jump is your main ability and way of moving and you will use it very often. So, forbid any other ability while jumping must really be carefully considered. Especially if this ability is needed in action phases (like the attack ability in a melee fight based game) !
If you really want to forbid the action in the air for any good reason, it's always a good idea to feedback this impossibility with some sound, FX or animation.
Round platform edges (slippery edges)
I some games, all the platform have round edges. There a lot of reasons to do that but a common one is to avoid the character “capsule” collider to get stuck on right-angled edges:
A lot of accessible game engines, like Unity 3D, use this kind of “capsule” collider to handle collisions with their physics engine. So, it’s very tempting to use this easy and quick solution to avoid the “stuck” issue instead of dealing with right-angled edges.
Actually, it’s not necessarily a bad solution: if your game is not based on jump challenges and don’t need high precision moves, it’s probably ok. However, if you want to make a Mario-like with critical jumps, you should probably avoid round edges: it could be very frustrating for the player to reach a platform on the edge, feeling he touched the platform ground, and finally slip into the void because of an almost invisible round edge!
If you are interested in coding, I wrote a previous article in my “hobbyist coder” series about a way to code a custom 2D platformer controller in Unity 3D, especially to avoid this kind of problems.
Visual and sound feedbacks
Yes, feedbacks are important. And yes, sometimes even during the prototype process.
I realized the importance of feedback in platformer working on a personal project: even with all the other “rules” above applied, I still found the game a little bit limp. I tried to tweak the variables, modify the move system, etc… Nothing changed. Finally I was tired to search and decided to start coding a sound manager to “relax” and the first sound I added to test it was the jump one. And how I was surprised to find my character much more reactive! I decided to continue on this way and implemented a run animation speed linked to the character speed: the games seemed to gain more reactivity again!
This little story was just to say that sometimes, even if you know animations, sounds or FX will come later in the development, the brain needs them to help it “materialize” some physics concepts like speed, move or gravity. And because platformer games are all about the understanding of specific physics, I think it’s important to implement placeholder feedbacks early before trying to tweak your move variables.
Of course, this list is non exhaustive and I’m really interested to hear about other observations about platformer controls.
This list is also subjective and it’s why I put a lot of “in my mind, “In my opinion” and “most of the time” expressions in this article: nothing is set in stone in game design. The game designer work is not really about “theory” and it’s why it’s very tricky to write about it. In my opinion (again!), the center of his work is above all to prototypes ideas, test them, prototype, test, etc. until he end up with something “fun”. So, if you want to design a kind of game which usually needs a lot of reactivity and precision, but going against these few tips, just don’t hesitate. But prototype your work!
Let’s finish with my game design golden rule: there are no golden rules!
And, finally, thanks to some really interesting articles which inspired me to write this one:
Telltale Games — San Rafael, California, United States
Telltale Games — San Rafael, California, United States
[View All Jobs]