Forgiveness Mechanics: Reading Minds for Responsive Gameplay

[Music] the controls are unresponsive these four words can be a death sentence for any video game if you have unresponsive controls it means unfair losses frustration players quitting and of course lots of bad reviews but what are responsive controls if it just means the game does what the player tells it to do how hard could that be to implement and how could so many games get it wrong I mean surely it's a simple thing all you have to do is tell the game hey when the player presses right have the character go right right wrong there's a lot more to it than that making a responsive game requires an additional touch it requires you the designer to understand your players better than they understand themselves it requires you to understand their inconsistencies and then forgive

them and I don't mean that in a philosophical way I mean literally building forgiveness into the design of your game so that even if your players aren't perfect even if they make mistakes they could still have a great time my name is Seth Koster and I'm a co-founder designer and game programmer at butterscotch shenanigans today I'm going to talk about our studios journey through developing our upcoming platformer level head and the ways that we incorporated forgiveness mechanics into the game's design to make it a truly enjoyable experience now we have a lot to cover so let's just jump right in then now about a month into level heads development Sam our artist was playing the game and I noticed that he was having a hard time trying to bounce off of enemies heads and level head as in many platformers you can jump on an enemy to defeat it and if you're holding the jump button when you land on its head then you get a big aerial boost but when Sam was playing I saw that he

wasn't always getting the boost I asked him what was going on with that because I'd never seen that before and he just said yeah there's something inconsistent about bouncing off of enemy's heads and it only seems to work half the time so as the programmer I got defensive because I knew that the underlying code was so simple that there was absolutely no way that it could be inconsistent either you hold the jump button and you get the boost or you don't hold the jump button and you don't get the boost I mean that's textbook consistency so I watched Sam play to figure out what was going on and sure enough he was not holding the jump button instead he was trying to time it so that he was pressing jump in the exact moment that he hit the enemy and about half the time he would hit it too early but he'd get the boost anyway because he was holding the button right as he touched the

enemy's head but the other half of the time he would press the button after bouncing off the enemy's head and then that wouldn't count so as a designer this kind of situation puts you at a crossroads you know that your controls are consistent so you could just blame the player you know hold jump to bounce if you don't hold jump you don't bounce the end or you can recognize the truth which is that people are inconsistent so if your game demands consistent inputs your players will not get consistent results the philosophy of forgiveness mechanics tells us that we need to anticipate these inconsistent inputs and build them into the games mechanics people sometimes hit buttons too late so let's just see if we can accommodate that by using a forgiveness mechanic called the coyote jump under the original setup we just had a true/false

variable called can jump inside the player and if it was true you could jump and if it was false you couldn't and we would set that variable to true only if there was a valid jump right in this exact moment meaning your feet are touching the ground or you you're bouncing off an enemy so the simple change we made was to turn this variable from a true false variable into a timer so now anytime it becomes possible for you to jump instead of being true the variable becomes 0.1 and so that means that you're always gonna be given a tenth of a second to jump even after it should no longer be possible to jump and suddenly all those missed inputs from pressing the button too late go away this technique is called the coyote jump after a while a coyote the Looney Tunes character it would run off of cliffs and then only fall when he realized that he no longer had anything to stand on and if you're

really watching somebody play with this mechanic then you'll notice those times when they run off a cliff and they seem to jump off of thin air so if you're finding that a little tricky to catch here's this same clip at 25% speed as you can clearly see gr-18 our protagonists delivering robot is fully floating in mid-air here by the time the jump button is pressed and that gets caught by our little can jump timer so this is what a player would call responsive controls because the player attempted to jump across a gap and as far as they could tell they pushed the button at the right time so they would expect to jump that gap and they did and that's all there is to it so once we opened up our minds to the possibility of letting the player hit buttons too late we started to see how this could be applied to other areas as well and level head the the player has

the ability to grab objects using a grappler and this grappler extends up to three full grid spaces away from the player and it attaches to whatever it hits and then it quickly pulls that back and puts it on the players back so when we first implemented this grappler we didn't think too much of it because it's a it's a common concept in platformers to be able to grab objects and carry them but because our grappler had a range and a directionality it suddenly opened up a lot of really interesting mechanics and the coolest of these mechanics was what our players came to package jump which came to be the signature move of Jerry teen a package jump is when the player jumps off the package while grappling downward to pick it up again mid jump so this move allows you to use a box as a mobile platform to traverse hazardous terrain and although

the package jump was really fun an interesting mechanic we had a little bit of a math problem the player can jump more than four spaces high but the grappler only extends three spaces so if the player hit the grappler too late then they wouldn't quite be able to reach the package so we created a system called cable stretching where we would lock in the destination of the cable the moment you press the button and if you happened to move farther away the end of the cable would stretch to reach that original intended spot so in this gif you can see the cable stretching in action and even though gr-18 here when standing at the top normally can't reach down far enough to grab the package we can see that while jumping upward the cable stretches that entire distance giving plenty of wiggle room to perform that package jump so cable stretching and coyote jumps are both forgiveness mechanics that work toward the same goal and they both fall

under the category of late input forgiveness that is they allow the player to press inputs too late while still giving the player the results that they expect but even with our delayed input forgiveness at mechanics added to level head we still felt like the controls had some problems because there's a flipside people don't just hit buttons too late they also hit buttons too early so to solve this problem we need some kind of early input forgiveness we need to let players hit buttons too early and still make it count so for example if you hit the jump button before your feet touch the ground you should still jump we can easily solve this problem with a technique called input buffering which is when you store an input for a short time after it's pressed and then engage the input when it becomes valid a simple example from level head is the input buffering that we have on jumps which gives you a point to second window after pressing

the jump button and it still counts so in this gif we spawn a red marker at the player's feet the moment the jump button is pressed as you can see here there's no way that the player would ordinarily be able to jump at these locations because their feet or just wing above the ground and even more importantly here 0.2 seconds doesn't sound like much but this gif shows that even even that short amount of time gives you a huge amount of leeway making it almost impossible to miss time those jumps so once we got this system working we found it useful to use input buffering in just about everything yeahthere's input buffering for the jumping but also the grappler the power-ups everything that the player does is just becomes a much more responsive it feels better with input buffer but this point we've now covered all the input timing problems in our first design the player had to exactly

press an input when that input was valid or it wouldn't count and this felt unresponsive and demanded too much perfection of the player but when we combined our early and late input forgiveness mechanics we create the input forgiveness sandwich where the player has a nice wide window of opportunity where when they press a key they get the result they expect this is what a player would call responsive controls so we've done all we can to handle mistimed inputs where the player presses the right button at the wrong time but what about situations where a player is just pressing the wrong button entirely one of the biggest things we struggled with in making level head feel responsive is that when moments of tension arise players minds can become somewhat disconnected from the controls so they might think that they're hitting a certain button but really they're doing something else maybe they're

holding the button instead of repeatedly pressing it or maybe they're pushing a different button entirely for us this problem was most pronounced when it came to level heads fall through mode in level head after holding the down key for 0.2 seconds you enter fall through mode which allows you to continue to fall through certain kinds of platforms or certain kinds of terrain as long as you continue to hold down so here this gift you can see a red bar appear at gr-18 s feet when the timer starts so that's when down is first pressed and when gr-18 enters fall through mode the bar turns green and he begins passing down through the thin ledges so this system worked pretty well except when it came to performing package jumps to do a package jump you need to grapple downward which requires holding down while grappling but some

players would forget that they were holding down and they would keep holding down and they would try to land back on the package and just fall right through it as you can see here in this gif so we added some hidden rules to make it so that if the player continued holding down they would still get the expected results so first we made it so that every time you jump fall through mode just turns off we assume that if you're jumping you want to go up and fall through mode is about going down so in other words we use one input to completely invalidate and reset another input and second we add a rule that fall through mode only begins when your feet are on the ground so that means if you're holding down before you land then you'll get a brief window of standing on the ground before you begin falling so when we combine these rules you can see that the player can now just continue to hold down forever whether they know that

they're doing it or not and still be able to perform a series of package jumps without falling through so in this gift the down button is never released you might think that these extra rules would add some kind of clunkiness to the controls but since they line up with players expected outcomes they actually just make the controls feel correct instead of weird so this whole concept that we used to solve our down button problem is just called an input reset where even though the player is holding a button we add rules that reset the input to make it seem like the player isn't holding the button and if they've pressed it fresh as designers we just have to acknowledge that players will sometimes forget to let go of a button and it's our job to make sure that the game handles that gracefully wherever possible so when it comes to accidental input forgiveness you can go even deeper than input resets because sometimes

you'll find that players will press a button that they really really don't want to use at all in level head we got hit by this problem in a big way we had the controller's left bumper tied to the retry button so if you pressed that bumper it would start the level over or set you back to the previous checkpoint we wanted to make sure that it was super easy for speedrunners and and more serious players to restart levels to work on their strategies or if somebody got soft locked in a puzzle that they could just hit a button and just start over so we discovered though that a sizable portion of our players probably about a third kept hitting that that left bumper on accident so they'd be in the middle of doing something and then all of a sudden they would just accidentally reset the level this seemed weird to us because the left bumper is like it's way over there on the controller so how could you possibly hit it on accident we sat down and we just watched some people play the game and we quickly discovered

the problem which is that some players just naturally hold the controller with their index fingers resting on the bumpers and when something intense was happening these players would clutch the controller super hard and squeeze it and impressed both of the bumpers at the same time and because it happened when the player was in the middle of panic moment then the player would actually have no idea that they had squeezed the bumpers they didn't know they had pressed any buttons and so as far as they were concerned the level just randomly restarted so fortunately there's a simple fix for this we just added a count up timer to the reset button so that the button would only be valid if you held it for more than 0.3 seconds though this is enough time that it allows the panic to pass and if a player clutch the controller the unit would only do it just for an instant and so by the time the panic subsides they've released the button and they've stopped accidentally resetting so once

sure enough once we implemented this all those complaints about accidental restarts vanished so we call this kind of forgiveness mechanic an input speed bump so rather than just instantly taking the players input and engaging the action for some inputs we can say slow down a second so you don't hurt yourself and when it comes to buttons of higher consequence where an accidental input would be really bad you might want to consider putting some speed bumps in there so there's many ways that you can forgive their players for giving weird bad or just plain wrong inputs but forgiveness mechanics are not just about inputs there are lots of other little things you can do to make your game feel more responsive to the players intentions for example when we first started working on level head we kept running into scenarios where it was unusually difficult to navigate tight spaces like if you ran over a little gap

in the floor you just fall right into it or if you wanted to jump through a one grid space hole in the ceiling it would take a couple tries and you kept bumping your head this was all because of how we were thinking about our hit boxes under the hood everything in level head has a width and a height which determines the hitbox of whatever that thing might be so here you can see some of the items in level head shown with their baseline square-shaped hit boxes when we first started building the game we treated these hitboxes as sacred any collision between hit boxes should be respected we thought so let's say we had a situation like this where you have some terrain and then there's a tiny ledge sticking up and if we have a character walking along here and we take a rigid view of these hitboxes then we would say that unless the character jumps this tiny ledge is going to stop them but it turns out that is a terrible

gameplay experience because being stopped by every tiny ledge lip and corner just makes everything frustrating so to solve this we use hitbox pinching which is when the characters movement collisions are based on some smaller pinched version of the hitbox and this is going to allow the character to squeeze through areas that they otherwise would have had a harder time squeezing into and then they can pop up over obstacles so in our previous example it would look like this when you're calculating horizontal movement collisions we would pinch the hitbox vertically which allows us to pretend like the character's feet are higher up off the ground and its head is lower as the character moves forward this tiny ledge is no longer a problem and in that same movement frame we can resolve the fact that the characters inside the floor by just popping them up out of the ground so the player can now move unimpeded

over small obstacles and this hitbox pinching technique also allows the player to run over small holes in the ground so without head box pinching you would often find yourself in this kind of a situation where you go to run across this little gap but in one frame you can fall down a single pixel and because you fell down one pixel the next ledge becomes an impassable wall and now you just fall right in in level head when gr-18 is moving to the side we pinched the hitbox by 20 pixels top and bottom so that means that while running to the right the player would have to drop more than 20 pixels before they can no longer pop up over the next ledge and when we put this into practice we can see that now gr-18 can run across one tile wide gaps then and actually if you move horizontally fast enough you

can even clear double wide gaps and this visualization really illustrates that pop up effect from the hitbox pinching in a much more pronounced way so as you can see here we guarantee no runs across Falls for a moment and pops up over the next tile and that little bit of falling is forgiving hitbox pinching can also be used to let the player easily jump up and out of tight spaces so here and this gif were representing collision checks with these little green dots and as you can see that when the players jumping upward we pinch the hitbox down to almost nothing I think maybe the players about two pixels wide while jumping upward but that squeeze generally allows the player to sometimes partially go inside of walls and so we have to make sure that we adjust for that and that adjustment is shown by those little yellow dots in the center of the players body when they jump around corners just like that and you may also notice that

when the players falling we don't pinch the hitbox at all so the player has a wide base on which they can much more easily land on narrow ledges the hitbox pinching is a super useful tool that allows you to demand a lot less precision of the player and allows them to very easily squeeze through areas of the game that would otherwise require a frustrating amount of fine motor skill so when it comes to hitboxes there are a couple of other much simpler things you can do to get a lot of mileage for example we can play around with hitbox sizes and shapes as a simple but effective tool to make the game more forgiving for starters when it comes to things that are bad for the play to touch we can tuck the hitbox in at the edges making the hitbox smaller than the visual area of the object so it's harder for the player to hurt themselves and you can see in this gift how these spike

jonze in level head have very forgiving hit boxes which allows the player to easily squeeze through a gap like this so I like to think of this as those times in movies where someone's flying a spaceship and there's always a scene where two big doors are closing and they have to squeeze the ship through the gap so basically you want to create that feeling and that's easy to do just by tucking in those hit boxes so you may also notice that these spikes despite obviously being square have circular hit boxes by shaving off the corners we make it so that the player can kind of pass their toe through the corner of the spike and that's still fine it's a close call which feels cool and makes the player feel like they're better at the game and it's just a lot more exciting that way on the flip side for anything positive we want the hitbox to be as easy to hit as possible so for starters we make it a square so that it

has those corners to catch and we also extend the hitbox beyond the visual signs of the item so in this gif we can see how these hitboxes of gems and level head extend far beyond their actual visual size and when the game has slowed down at half speed like this and when the hitboxes are visible the forgiveness mechanics are pretty obvious but at full speed without the hitbox is visible it feels totally natural and the player is not going to notice or be upset that these good things are being handed to them with ease but sometimes having a big hitbox isn't enough if you want the player to really get that good stuff you can add magnetism to positive items level head we only apply this to the gems but in your game you could technically do this to whatever you want the rule we use is once the player has gotten pretty close to the gym we have

the gem enter magnet mode and it's then just gonna chase the player until it gets picked up this effect is especially pronounced when the player is moving faster like this gift when they're falling or maybe if they're being shot out of a cannon so we use this kind of magnetism to make it so that the player doesn't have to backtrack and physically touch every gem just to collect it if they just kind of like graze past one just it got close enough then we just call it good enough and we let the player have the win and plus I think it just feels really cool to go really fast and just be chased by a bunch of gems that are trying to catch the last forgiveness mechanic I want to go over is the concept of a benefit of the doubt decision tree this is what we use when a player could have multiple possible outcomes when interacting with something with varying degrees of goodness or badness when one of these

events occurs we walk through a series of questions that always leads to the most favorable outcome to the player in level head enemies are the best example of this so when you hit an enemy there are some scenarios where you defeat the enemy and there are some scenarios where the enemy defeats you and the outcome totally depends on how you hit the enemy so we can use this scrub enemy from level head as an example when you collide with this scrub we first check the green rectangular area this is the area that is favorable to you to determine whether you're gonna deal damage to the scrub by jumping on its head so notice that this area is larger than the visual size of the scrub and it also has corners making it easier to hit and as you can see in this gift the player doesn't have to directly land on

the visual area of the scrub for this to count as a successful hit you just need to hit somewhere in that green rectangle and just like with the gems the positive hitbox extends far beyond the visible area as before this effect is more pronounced when the game has slowed down like this but at full speed this happens fast enough that you don't really you don't really notice it that much when you've collided with the enemy and failed to meet that first decision criteria for dealing damage to it in the green rectangle only then do we evaluate if you're going to be harmed and in that case we use a second smaller circular collision mask represented by this red circle to determine whether you're harmed so it's possible that you would collide with the green rectangle fail to damage the enemy because maybe I don't know maybe you were traveling up or so thing but maybe you're still not inside the circle so you don't take any you

know you're not harmed and you live to see another day and by using this tucked in circle we allow you to kind of graze past and and avoid anything bad happening to you so in all cases our goal here is to give the player as many opportunities to win and feel like they're really good at the game and only when they totally run out of possible ways out that's when the player loses all right so that's about all the time that I have I hope you've all found this useful and interesting some of these concepts are a lot more complicated to implement than others and not all of them will apply to all games so how you bring these forgiveness mechanics into your game may end up looking a lot different than what I've shown here today but that's okay because the most important thing here is not in the specifics it's in the broader philosophy that your players are people and people

do all kinds of wacky things they push the wrong buttons they squeeze the controller they panic they do a lot of things that they don't even know about or that they can't even explain in other words they're not perfect but we shouldn't expect them to be perfect as designers it's our job to meet our players where they are and give them the best possible experience and to do that we have to forgive their inconsistencies and build rules into our games that accommodate them and only then will you have a truly responsive game thank you for listening if you have any questions or comments about this talk feel free to shoot me an email at seth at b scotch net good luck out there