To The Core — A post mortem
Back in February of this year I participated in the One Mechanic Gamejam. It’s been a few months since then, and I’ve had some time to look back on the game I created and gather my thoughts.
One mechanic? Which should I choose?
When I first saw the gamejam posted and what it was about I recalled a wonderful 4-way race of Ori and The Blind Forest at AGDQ 2018.
After watching it I was inspired and had some ideas whizzing around in my head but lacked motivation to actually convert those ideas into a functioning prototype.
When I saw that One Mechanic Gamejam was coming up I immediately knew I had to try my hand at making an Ori inspired movement system. The only constraint I put on myself was that whatever it was I created, regardless if the game was finished or not, it had to be incredibly fun to play with.
Now that I knew the general idea of the mechanic I wanted, I had to try my hand at actually prototyping it. I’ve been using UE4 off and on for a few years but recently, in August or so of last year, I started seriously committing to learning about UE4 and all of its different features. I felt I had a pretty good idea on where to start. Lets see how the first stages of my prototype compares to my goal…
In retrospect this is actually cooler than I thought it was gonna be. I haven’t looked back at this project visually for a long time. It’s been in the back of my mind and I spent what must have been 30 hours straight staring at it during that weekend so I definitely had no intentions of looking back until I thought about writing this blog post.
One Mechanic To Rule Them All
At this point I had an idea, a prototype, and no idea what I was doing. I recall that around this time I had made a decision to put my time into further improving the player experience instead of like… you know… on planning how many levels there needed to be, how much time each level needed to be worked on, additional mechanics to make the game interesting, and so on.
I fell into a trap that I designed myself. I knew that my game would be fairly memorable if it was short and fun, rather than long and boring, but managed to make it just as forgettable by not giving the player space to breathe and play with this interesting mechanic.
I continued to work on it for a few hours and it slowly became better and better.
I added an arrow that would kind of grow outward and indicate where you were gonna be pushed towards when you let go of the mouse.
I also managed to give the player more control by resetting the velocity every time a new impulse was made. This stopped the player from having to repeatedly dash in the same direction to build up speed when making sharp turns and allowed for some very tight movements.
During this time I also added something called Asymptotic Averaging to the slow motion which made it much smoother to play with. There’s also some remnants of features that I planned on having but cut for one reason or another, but we’ll get to that part later.
Lets juice It!
Over the years I have watched a bunch of different game design videos and one of the things that seems to be a recurring theme on making your games fun to play is adding something called “Juice”.
It’s not exactly a single thing you can point to but if I were to put it on a graph the graph would look something like this:
All joking aside juice is when you take player interaction and make it INCREDIBLY responsive, for example:
- Hitting a wall or floor after moving fast should shake the camera.
- Punching / hitting someone or something, or being hit, should pause the game momentarily in what’s known as an “Impact Frame”.
- Using asymptotic averaging to shift between values naturally.
- Context sensitive audio cues that are satisfying to hear e.g. gunshots.
For example, I made death especially rewarding because when you’d die you would break into a bunch of little physics assets that interacted with the environment!
One of the best pieces of information I found that seriously impacted how I design my interpolations is the following snippet of code:
- x += (target — x) * .1
Now it might not seem like much, but this formula is incredibly powerful. It’s the formula for Asymptotic Averaging and is what lets you ease any two values into each other, generally but not necessarily, each tick.
In my game, it ended up looking somewhat like this:
- Current Timerate += (Target Timerate — Current Timerate) * SomeFraction
Without going too much into it, it essentially allows you to transition towards a value but never actually reach it. If you have ever heard of the Arrow Paradox it basically works like that. You can learn more about it in this incredibly insightful Youtube video here which goes into Juicing your games much more than this blog post could without just parroting what they talk about in their video.
Not visible in the snippets of game-play are the sounds which work just good enough to convey motion and impact.
The Rest of The Damn Game
So at this point I had an awesome little character that the player could control but there wasn’t much to do with them because the rest of the game didn’t exactly “Exist”.
I was running low on time, and only had about 12–16 hours left when I realized I had to seriously kick it into high gear and get some of the last minute stuff out. I started worrying about how to tie into the themes of the GDQ and ended up trying the Man vs. Machine choice.
I decided to go with the Megaman style story where you get jacked into the network and have to fight the machines from inside. So I began working on a few of the assets that would at least fill the world with more than white blocks and I could hopefully use for mechanics.
I created these spikes and animated them using UE4’s timeline tools. Made it really easy to line up collision hitbox with a specific point in the animation. I use shape keys to transition between the two states the spikes can be in. That’s why they appear to be stretching rather than expanding out.
There’s also these fabric blocks that give the player a bit of a break. When they touch them they just stick to the block like glue until they’re ready to jump again.
These core things were the “objective” of the game, albeit fairly shoehorned in. I wouldn’t encourage you to write your games lore on no sleep! The general rule is to just touch them and then it counts as a score for the level to transition you into the next.
I created the assets myself using Substance Designer / Painter and Blender.
One of the things that was really neat was the dialogue system. I was running low on time and found this awesome little UE4 post about how to implement a simple text buffer that had some really neat animations tied into it and used that for my dialogue system. There were probably 10 hours left around this point.
I quickly scripted out the story and there were suddenly 4 hours left until the gamejam was over. Oh, did I say quickly?
So I had this dialogue system setup, but I had no user saves, no way to toggle controls, no main menu, nothing.
But hey, at least I could display poorly written dialogue to the screen all fancy-and such!
I managed to squeeze out a decent looking main menu in about an hour since UE4 widgets are actually pretty strong and easy to work with.
I also managed to add an entire save system that kept track where-at in the story you were so dialogue wouldn’t repeat if you were to, for some reason, ever launch this game a second time.
Letting Things Go
There was so much stuff I had designed to completion that just didn’t make the game any fun. I’ve never actually aimed to make an “entire” game before and I honestly was surprised at how many ideas I could quickly just add to the game and how awful those ideas actually were.
I remember trying to implement some form of Stamina system that determined if you were able to jump. It was just awful and made the game way less fun. I tried balancing it to make it more forgiving and generous but its sheer existence was counter to my goal and I scrapped the stamina system entirely.
I also had a feature that would let you stick to walls by holding down the mouse button but that kinda nullified a lot of the tight movement required to pass through tighter areas.
One of the best things I removed was probably the “Charge” mechanic. You could charge up your jump and it would become more powerful but when I paired that with the games tick rate slowing down when you’re about to dash it just made it so that building a powerful jump was extremely time consuming. This is more of a limitation imposed because of how slowing game time down works within the engine but in testing, even without time slowing down, I found that a set amount of force each jump was much more responsive and fun to play with.
Conclusion
I made my first real game in 2 days! It was a very fulfilling experience and showed me a lot about my skills, where I’m at, and where I want to be.
I learned that not all code is sacred, and ideas even more-so. I also learned that I’m not necessarily that great with time management, and while I achieved my initial goal of a fun and interesting movement mechanic I feel I fell short on the rest of the goals people generally have in a gamejam.
These days I do a lot of artwork related stuff, more than game development, but I plan on changing that up very soon as I start implementing more of these assets I’m creating into a tech piece of my own and see what I can come up with.
I hope that you enjoyed this post-mortem. I’m new to blogging and I hope that, if you enjoyed this post, you will follow me to learn more about my journey into game development.
You can Download To The Core on itch.io here: https://skullfurious.itch.io/to-the-core
Thank you for reading.
