Finikey Postmortem
During March of 2018, I was in my third year of game design and around that time things were very slow. Compared to my first two years of game design, there was a lot less focus on actually making games and more focus on everything else: proper testing procedures and documentation, source control and task management tools, etc. The past couple of months had everyone scrambling to find co-op placements over the summer, but now that those were mostly taken care of it felt like nothing was really happening. So I figured that if the course work wasn't going to involve making games, that I would just have to make them on my own.
I knew I wanted to make a 2D platformer, and I had made a few before, but I had found that the platformers I had made previously never really felt right. There was always something a little off about them and it annoyed me to no end. So instead of making anything in particular, I decided to focus on making the core platformer mechanics feel as great as they possibly could. I figured that once I had a solid base I could add whatever on top of it, and I would always have that base to work from in the future. Finikey evolved from the tests and experiments I did while developing this platformer tool set.
Finikey is a finicky puzzle platformer where your goal is to get the key to the keyhole in each level. You do this by jumping. Whenever you land on the ground, objects around will be pushed away from you. It's pretty simple, but the focus was more on making the platforming feel good than doing anything crazy with the mechanics.
The first thing I focused on was the camera. Even though it isn't related to the platforming itself, it doesn't matter how good the jump feels if you can't see where you're jumping. My first attempts at a 2D platformer simply had the camera track the player's position at all times, keeping them in the center of the screen, and while that technically works, it didn't have anywhere near the level of finesse that I felt it should.
I knew I wanted to make a 2D platformer, and I had made a few before, but I had found that the platformers I had made previously never really felt right. There was always something a little off about them and it annoyed me to no end. So instead of making anything in particular, I decided to focus on making the core platformer mechanics feel as great as they possibly could. I figured that once I had a solid base I could add whatever on top of it, and I would always have that base to work from in the future. Finikey evolved from the tests and experiments I did while developing this platformer tool set.
 |
| Finikey with all its blocks n' doodads |
Finikey is a finicky puzzle platformer where your goal is to get the key to the keyhole in each level. You do this by jumping. Whenever you land on the ground, objects around will be pushed away from you. It's pretty simple, but the focus was more on making the platforming feel good than doing anything crazy with the mechanics.
The first thing I focused on was the camera. Even though it isn't related to the platforming itself, it doesn't matter how good the jump feels if you can't see where you're jumping. My first attempts at a 2D platformer simply had the camera track the player's position at all times, keeping them in the center of the screen, and while that technically works, it didn't have anywhere near the level of finesse that I felt it should.
 |
| An early version of the first platformer I made using Java. I couldn't find the final version ;_; |
I might not have had any specific idea in mind while making Finikey, but at first I wanted to make an action game of some kind. Around this time I was playing Momodora: Reverie Under the Moonlight, and based a lot of my camera and platforming feel off of theirs. Because of this, the camera in Finikey doesn't actually follow the player, but rather follows a position just in front of the player. This allows the player to see more of what's ahead of them, which would help players see upcoming enemies as they run and gun through levels.
At first it was a bit disorienting having the camera swing back and forth as you looked left and right, but by adjusting and smoothing out the camera's movement speed I got it to a level where it worked. I imagine that this would have been a bit trickier if I had objects in the background or parallax scrolling as the additional details, and movement would probably enhance how disorienting the camera movement was, but seeing how Momodora has both of those things, it should still be possible with the right camera speed.
Similar to Momodora, I also wanted my camera to be constrained to rooms, or, at the very least, stop when it hit a wall. Before I did this, if the player ran up to a wall, the camera would drift outside the bounds of the level, and didn't look very nice. To prevent this, I used an invisible cube to block out an area where the "room" would be, and used the bounds of the cube to define how far the camera could go. This way I could easily tweak the size of a room by just scaling the invisible cube instead of fiddling with precise numbers.
Getting the jumping right was a bit more work, but, in the end, there were three main things I did to improve it. I didn't invent these techniques, and they've been used in plenty of other games, but when it comes to a genre as old as the platformer, there's really no reason to reinvent the wheel when you could be spending that time building the rest of the car.
The first was adding a bit of an input buffer to your jump. Normally, in order to jump, you have to be on the ground (unless you're doing some double-jump shenanigans or something) and if you try to jump while in the air, nothing happens. However, this can lead to times when players feel like they pressed the jump button, but didn't jump. This is usually because they push the button just before they land, and it doesn't register as a jump because they're still in the air. Buffering jumps fixes this. We check if the player presses the button before they land, and if they do, then we make them jump again right away once they land.
The second is a technique called coyote time, and it's similar in use to jump buffering to help with misinputs. If a player walks off a ledge, and then tries to jump, the input won't register, because they will be in midair by that point, so we simply give them a small window of opportunity where, after a player has walked off a ledge, they can still jump. To my understanding, coyote time gets its name from Looney Tunes where Wile E. Coyote would run off a cliff then hang there in midair for a second before falling, the time he hangs midair being the time players have to jump.
The last thing I did was adjust the player's jump height and gravity. It's a minor detail, but if you've ever played Super Mario Bros. you may have noticed that when Mario jumps to his full jump height, it takes him longer to rise to the peak of his jump than it does for him to fall down. Because the rise of Mario's jump takes longer than the fall, players have more control over Mario while he's in the air, but because he falls faster than he rises, his jump doesn't feel "floaty".
Having a sense of weight to the jump would be super important for Finikey because of how it plays with physics. If the character felt like they were floaty and weighed nothing, then the impact of knocking objects around when you land would be less... well, impactful. I had intended on adding a bit of a screenshake to better sell this impact, but I didn't want it to happen every time you landed, only when you landed from a really high height. I first tried it with some particles, using the same idea, but I had issues where it would go off without the player jumping when you were just standing around. Particles are one thing but random screenshake, when you're just standing around, wasn't going to fly, so I had to cut it.
The idea for knocking objects up in the air came from what I thought would be a cool fighting style for my then action platformer. The idea was that you would stomp the ground to knock up small objects, then punch them at your enemies to use them as projectiles. I only ever got as far as the knocking objects up in the air part. Once I had the basic physics knockback working, it was too much fun just spawning a bunch of objects and sending them all flying.
I wasn't super keen on using the physics idea at first, as I was worried that there would be some wonky side effects of just having physics objects everywhere and figured that it would be better to go with something I would have more control over. But everyone who saw the physics stuff liked it, so I bit the bullet and went with it.
After a new coat of paint (I was getting sick of looking at blue placeholder square with red triangle nose), I started sketching out levels. I already had the blocks but I wanted some other things I could use to build levels with. I designed some levels based on one-way platforms, but they weren't working out in the game, so I scrapped them. Another idea I had was platforms made out of glass or something that would break after you stomped X number of times, but I never actually got around to prototyping it. I still think that could work, so maybe for the sequel, if that ever happens.
One of the ideas I got decently far with was spikes. Spikes are pointy, you step on them and they kill you. Simple stuff. But I had planned to have them work in tandem with the boxes. You couldn't stand on spikes, but you could stand on boxes so if there was a large pit of spikes you could knock some boxes into them to cover them up and make a bridge. I actually had spikes working in the game and had a couple of levels designed around them, but around this time school was coming to an end and I had to focus on final projects after which was the move back home and starting work at my co-op.
At this point I had been working on the game for 2 months and I wanted to finish it. The only real thing that was missing was a title screen and sound. So after things had settled down I got to work on a title screen. I found out that the name I had originally been calling it, Physic, was actually old English for laxative or something like that. Google your made up words kids, they might actually be real words. I eventually settled on Finikey and made the title sequence that the game has now.
At this point I realized that I had a bit of a problem. Earlier, when I was making levels and coming up with new mechanics, I had made a level select. It was pretty cool, when you moused over a button, the player character would appear over top of it and once you selected a level, all the other level buttons would go flying. So when I made my title, it had two options: Start and Level Select. The problem was that the level select didn't fit into the design of the game.
Once you completed a level, there was no reason to go back and play it again. I didn't want to remove the level select because then the title screen would have Start as the only option. Yes I know that's a stupid reason and it would be perfectly OK to just have a title screen that said "Press Enter to Start" but I really liked that level select and I swear keeping it made sense at the time. I figured I could add collectibles to each level so that there was a reason to go back and play older levels, but then what would the point of the collectibles be? I wouldn't be happy with collecting collectibles for the sake of collecting them, they would have to do something. But what?
At this point the game that was so close to being done had just doubled in scope. After that my motivation was shot. It didn't help that I also had to implement my spike level ideas while, at the same time, making sure that I had enough levels so that my level count was a multiple of 5 and damn that last sentence made me realize I'm more of a perfectionist than I thought.
And now it's out. The level select still bothers me, probably even more than it did almost a year ago, but that doesn't matter because the game is done. People can go play it, with all of it's charming flaws, and I can finally move on. I feel like I've heard multiple people say something along the lines of "finishing something is far better than working on something forever until its perfect" and I believe that that's very true. The important part of Finikey, the scripts and tools for good feeling platforming, was done after only a few months. It was only my perfectionism that caused the game to take so long.
Like I mentioned earlier, I didn't invent any of the tricks I used for making a good feeling platformer, and if you're interested in knowing more about them I've linked some of the resources I used below. I would also recommend checking out Momodora: Reverie Under the Moonlight, it just got a Switch port so go check it out there if you're not a fan of playing games on PC. Also maybe check out Finikey since you made it all the way through this.
https://gdcvault.com/play/1022243/Scroll-Back-The-Theory-and
https://www.youtube.com/watch?v=hG9SzQxaCm8
https://www.gamasutra.com/blogs/LisaBrown/20171005/307063/GameMaker_Platformer_Jumping_Tips.php
https://arcadim.itch.io/finikey
At first it was a bit disorienting having the camera swing back and forth as you looked left and right, but by adjusting and smoothing out the camera's movement speed I got it to a level where it worked. I imagine that this would have been a bit trickier if I had objects in the background or parallax scrolling as the additional details, and movement would probably enhance how disorienting the camera movement was, but seeing how Momodora has both of those things, it should still be possible with the right camera speed.
Similar to Momodora, I also wanted my camera to be constrained to rooms, or, at the very least, stop when it hit a wall. Before I did this, if the player ran up to a wall, the camera would drift outside the bounds of the level, and didn't look very nice. To prevent this, I used an invisible cube to block out an area where the "room" would be, and used the bounds of the cube to define how far the camera could go. This way I could easily tweak the size of a room by just scaling the invisible cube instead of fiddling with precise numbers.
 |
| An early gif from what would become Finikey. You can see the camera bounds in action. |
Getting the jumping right was a bit more work, but, in the end, there were three main things I did to improve it. I didn't invent these techniques, and they've been used in plenty of other games, but when it comes to a genre as old as the platformer, there's really no reason to reinvent the wheel when you could be spending that time building the rest of the car.
The first was adding a bit of an input buffer to your jump. Normally, in order to jump, you have to be on the ground (unless you're doing some double-jump shenanigans or something) and if you try to jump while in the air, nothing happens. However, this can lead to times when players feel like they pressed the jump button, but didn't jump. This is usually because they push the button just before they land, and it doesn't register as a jump because they're still in the air. Buffering jumps fixes this. We check if the player presses the button before they land, and if they do, then we make them jump again right away once they land.
The second is a technique called coyote time, and it's similar in use to jump buffering to help with misinputs. If a player walks off a ledge, and then tries to jump, the input won't register, because they will be in midair by that point, so we simply give them a small window of opportunity where, after a player has walked off a ledge, they can still jump. To my understanding, coyote time gets its name from Looney Tunes where Wile E. Coyote would run off a cliff then hang there in midair for a second before falling, the time he hangs midair being the time players have to jump.
The last thing I did was adjust the player's jump height and gravity. It's a minor detail, but if you've ever played Super Mario Bros. you may have noticed that when Mario jumps to his full jump height, it takes him longer to rise to the peak of his jump than it does for him to fall down. Because the rise of Mario's jump takes longer than the fall, players have more control over Mario while he's in the air, but because he falls faster than he rises, his jump doesn't feel "floaty".
 |
| An early prototype of the physics knockback. |
Having a sense of weight to the jump would be super important for Finikey because of how it plays with physics. If the character felt like they were floaty and weighed nothing, then the impact of knocking objects around when you land would be less... well, impactful. I had intended on adding a bit of a screenshake to better sell this impact, but I didn't want it to happen every time you landed, only when you landed from a really high height. I first tried it with some particles, using the same idea, but I had issues where it would go off without the player jumping when you were just standing around. Particles are one thing but random screenshake, when you're just standing around, wasn't going to fly, so I had to cut it.
The idea for knocking objects up in the air came from what I thought would be a cool fighting style for my then action platformer. The idea was that you would stomp the ground to knock up small objects, then punch them at your enemies to use them as projectiles. I only ever got as far as the knocking objects up in the air part. Once I had the basic physics knockback working, it was too much fun just spawning a bunch of objects and sending them all flying.
I wasn't super keen on using the physics idea at first, as I was worried that there would be some wonky side effects of just having physics objects everywhere and figured that it would be better to go with something I would have more control over. But everyone who saw the physics stuff liked it, so I bit the bullet and went with it.
 |
| Some sketches of levels for Finikey |
After a new coat of paint (I was getting sick of looking at blue placeholder square with red triangle nose), I started sketching out levels. I already had the blocks but I wanted some other things I could use to build levels with. I designed some levels based on one-way platforms, but they weren't working out in the game, so I scrapped them. Another idea I had was platforms made out of glass or something that would break after you stomped X number of times, but I never actually got around to prototyping it. I still think that could work, so maybe for the sequel, if that ever happens.
One of the ideas I got decently far with was spikes. Spikes are pointy, you step on them and they kill you. Simple stuff. But I had planned to have them work in tandem with the boxes. You couldn't stand on spikes, but you could stand on boxes so if there was a large pit of spikes you could knock some boxes into them to cover them up and make a bridge. I actually had spikes working in the game and had a couple of levels designed around them, but around this time school was coming to an end and I had to focus on final projects after which was the move back home and starting work at my co-op.
 |
| An unused spike from the game |
At this point I had been working on the game for 2 months and I wanted to finish it. The only real thing that was missing was a title screen and sound. So after things had settled down I got to work on a title screen. I found out that the name I had originally been calling it, Physic, was actually old English for laxative or something like that. Google your made up words kids, they might actually be real words. I eventually settled on Finikey and made the title sequence that the game has now.
At this point I realized that I had a bit of a problem. Earlier, when I was making levels and coming up with new mechanics, I had made a level select. It was pretty cool, when you moused over a button, the player character would appear over top of it and once you selected a level, all the other level buttons would go flying. So when I made my title, it had two options: Start and Level Select. The problem was that the level select didn't fit into the design of the game.
Once you completed a level, there was no reason to go back and play it again. I didn't want to remove the level select because then the title screen would have Start as the only option. Yes I know that's a stupid reason and it would be perfectly OK to just have a title screen that said "Press Enter to Start" but I really liked that level select and I swear keeping it made sense at the time. I figured I could add collectibles to each level so that there was a reason to go back and play older levels, but then what would the point of the collectibles be? I wouldn't be happy with collecting collectibles for the sake of collecting them, they would have to do something. But what?
 |
| The level select. This is why the game took me so long to finish, and not for the right reasons. |
At this point the game that was so close to being done had just doubled in scope. After that my motivation was shot. It didn't help that I also had to implement my spike level ideas while, at the same time, making sure that I had enough levels so that my level count was a multiple of 5 and damn that last sentence made me realize I'm more of a perfectionist than I thought.
Finikey had become a gargantuan task in my mind, and whenever I had free time, I didn't really want to work on it anymore. Instead, I would doodle on my 3DS using Flipnote Studio or watch anime or respond to all the let's plays that my banana-dating sim was getting. Eventually, the summer was over and going into my last year of school didn't leave me with the free time that the previous years had.
It's not like I forgot about it. I still wanted to finish it but I was just struggling with how. Do I add more stuff to the game to justify having a level select, or do I just say screw it and actually finish it? As time went on I was leaning more and more towards just finishing what I had and throwing it out there. By this point the project had drifted away from the simple little game that was supposed to be an exercise in good platformer feel to something completely different.
Then one day a friend of mine asked me "What happened to that key game you were making? It was really cool", and that was the tipping point. I was going to finish this game already. None of this collectible stuff, none of this worrying about how having a level select impacts the design of the game. I had 10 levels (conveniently a multiple of 5), and only needed some sounds, music, and some sort of ending. I had been busy during my previous breaks from school with the Enthusiast Gaming Live Expo and Christmas, so as soon as we started approaching our final break of the school year, I got to work.
 |
| It's out! |
And now it's out. The level select still bothers me, probably even more than it did almost a year ago, but that doesn't matter because the game is done. People can go play it, with all of it's charming flaws, and I can finally move on. I feel like I've heard multiple people say something along the lines of "finishing something is far better than working on something forever until its perfect" and I believe that that's very true. The important part of Finikey, the scripts and tools for good feeling platforming, was done after only a few months. It was only my perfectionism that caused the game to take so long.
Like I mentioned earlier, I didn't invent any of the tricks I used for making a good feeling platformer, and if you're interested in knowing more about them I've linked some of the resources I used below. I would also recommend checking out Momodora: Reverie Under the Moonlight, it just got a Switch port so go check it out there if you're not a fan of playing games on PC. Also maybe check out Finikey since you made it all the way through this.
https://www.youtube.com/watch?v=hG9SzQxaCm8
https://www.gamasutra.com/blogs/LisaBrown/20171005/307063/GameMaker_Platformer_Jumping_Tips.php
https://arcadim.itch.io/finikey
