Just posted this over at LDJAM.com, it’s a post-mortem account of my creation of What We Hold In Our Hearts for Ludum Dare 43 back in December. This is my fourth Ludum Dare entry, and here’s how my numbers tallied up this time:
And using the nifty software over at ldstats.info, here’s how I’ve fared over my past four Ludum Dare entries.
I was happy to see my mood rating increase from previous contests, since that is where I spent most of my brainpower this time. Overall, I wish my ratings would have been higher. But, I learned a lot from the process and feedback by trying something new and different to me, which was my whole goal for submitting. Time for my development story and lessons learned.
Brainstorming
When the theme was announced, I brainstormed like everyone, trying to decide my particular angle on “sacrifice.” My go-to game style is a puzzle game, I’m very familiar with how to code them up, but I’m pushing myself out of this box this year. Whereas in previous contests, the theme was wrapped up in mechanical twists, this time I wanted to make a game dripping with theme and mood and worry less about innovation and mechanics.
I finally settled on making a game where the player was trying to save themselves and their possessions following some unnamed disaster. I wanted to make the player feel like they were making a sacrifice themselves, in the vein of the Companion Cube from Portal, and not just playing a game about sacrifice. It felt too easy to set up a situation where the easy and expected thing to do to win the game was for the character to sacrifice something (people, money, items, etc.) with no consequence to the player.
Luckily, I found a list of items people most regret leaving behind in emergencies, and built my game around these ideas. I sketched out the following images to be my valuable possessions:
- War Medals
- Personal Diaries
- Children’s Stuffed Animal
- Passport
- Jewelry
- Family Photographs
My thought was that somehow in the game, you would form a connection to these items, and then be forced to leave something behind, causing player devastation and inconsolable tears. Well, that was the plan, anyway.
Parallax
My game would involve running, lots of running. That in itself can be boring with just pressing a button to run, so I tried to add player interest in a few ways. First, the running would need to be rhythmic and need constant attention. I initially thought of having the player hit keys for the left and right foot of the character. I eventually simplified this to be repeated hitting of the “<” and “>” keys on the keyboard to go left and right.
Second, the scenery needed to be evocative of the theme. I’d taught my students about parallax backgrounds, using ideas from this excellent tutorial, but had never wrapped a game around the concept. This was the time!
I started out by copying an old demo project, which as we’ll see later, was not the best idea. It got me started with some initial code for the parallax, which I was able to swap out with some cold forest/swamp background images I made.
I was heavily inspired by the Forbidden Forest images in the first Harry Potter movie, as you can see here.
Anima2D
Now, to make some characters that run. I’d just learned about the Anima2D package in Unity in October, as I developed a puzzle game called Bunny Kiss.
Wanting to see if I could transfer what I learned, I set about making a simple flat character in Illustrator and give it a skeleton for movement in Anima2D.
To make it move, I decided to implement a walk cycle based on an image from Lynda.com.
And we have a running character! Hooray! Time to implement the actual game mechanics, or so I thought.
.gif)
Crash and Recovery
On Sunday afternoon, my bad decision earlier caught up with me. Because I’d copied a Unity 5 project to start, and was now using Unity 2018, weird things kept happening. In particular, the Invalid AABB errors (which no one really seems to know why they occur) were overwhelming my development process. My computer was losing battery power, and even when plugged in, there were huge lags in trying to get the game to run. And every so often, Unity would just close on me. Also, my hard drive was mysteriously filling up, I suspected with all of these errors being logged in cache somewhere. So, I followed the recommendations to wipe the Unity cache for the project.
TERRIBLE IDEA!
I got back some of my hard drive space, but somehow lost all of my prefabs, and animations, and skeletons, and AUGH! Nothing worked!
It was time to start over with a fresh Unity project. Sigh.
I still had all my graphic assets and code for the game, so by the evening, I was able to get back up to where I was before, with much cleaner setup, and no more mysterious AABB errors. My character animation was more like limping than running, but whatever, it needed to be finished.
Also, I haven’t learned how to substitute out the images in Anima2D once the skeleton has been constructed, so for the other characters in the game, I changed their brightness to make them distinguishable. I was running out of time, and needed to focus on making an actual game instead of just a running character.
Timing and Tuning
I settled on having three characters in the game, you, your friend, and the unnamed enemies who are after you. Your friend runs up and says you have to go, then starts running, and the enemies are not too far behind. You needed to run after your friend, not too fast or you would start to drop your precious items, but not too slow, or you would get caught by the enemies. I found using very small exponential growth in the speeds of the characters was the right way to go, starting out the friend and enemies slower than you can go, but by the time the minute is up, the friend is about your speed but the enemies are much faster, as the following graph shows.
As for timing, I was able place the enemies just far enough behind the friend that it would take them about 45 seconds to reach the friend. Also, if you did nothing when the game started, the enemies would catch you in about 4 seconds.
In my dialog manager script, the friend will signal that the next safehouse was found at 50 seconds, and the safehouse is entered about 5 seconds later. So if you just go slow and track your friends speed, you will both get caught too early! However, you get to slowly bump up your speed as you run, if you try to run again before the animation has finished. And in doing so, you can push a little on your friend in front of you and make their speed faster.
But if you bump up your speed too much, then you get clumsy and start dropping items. You stay clumsy until you pick up items you dropped. And your speed is reset each time you stop moving back to your default speed, so you need to be going faster at the end of the game or you are caught. I wanted to make it a very narrow balance for the player to walk, and with some good tweaking of the numbers, I think it works well. Ultimately, I wanted to make it even tighter, in that you would have to make at least one sacrifice of an item to make it to the end, but I let that go just to get the game working.
One other thing I thought was essential, was that I would never outright tell the player the right rhythm for tapping or the speeds of the characters, they would need to figure it all out through playing and losing the game. I did add one indicator, a repeated clip of labored breathing to let you know you were starting to go too fast and become clumsy. I did test it after the deadline of adding in a clumsy meter for you to know your exact level, but it made the game too easy to play, it was much better to have it all work by intuition.
Finally, I added in the GUI elements and dialog, set up the selection of the initial items, and it was time to submit!
Feedback
This was my first time making a platformer game with dialog and narrative, and I learned a lot. Most players felt the game was too short, and would be a great setup for a longer game with more variety in the missions to get from safehouse to safehouse. I agree. While I could usually churn out enough levels of a puzzle game to make a good demo prototype, this proved very hard to do in the limited jam window, especially with my reboot on Sunday, and the messy get-it-done code that resulted. I’ve since cleaned up the structure to allow for future extensions, making a class that specifically manages the dialog state and timing, hopefully I’ll have time to revisit this game soon. I now feel like I have enough experience to guide better platformer projects by my students and a nice working tutorial game to demonstrate the concepts in class next time I teach my game design course.
Watching ElysiaGriffin and YourBr0ther and a few others play my game on their Twitch streams was amazing! Their play followed the narrative arc I was hoping players would experience, (get trampled, go too fast, learn to pick things up, then try to work out the right speed) and I got to see first-hand how someone would navigate the system with my minimal explanations. You should definitely try to get your game playtested in this way, Twitch streamers for Ludum Dare games are awesome!
Here’s a link to the post jam version, and check out the Github repo to see more details of how it was made.
Thanks for reading, I’ll be back for at least one more Ludum Dare in April while on sabbatical, and hopefully continue participating when my teaching resumes in the fall.