3 weeks ago, Udell Games entered The Indie Speedrun with Mike “Frosty” Frost, an old friend from University. It was an intense 48 hours of programming, art and sound design and in the end we created a game that, I think, is good. We learned a lot during the time, and thought I’d share my experience with you.
An Out-Of-Sorts Sort Of Morning
I crawled out of bed at 11AM and was on Skype within ten minutes. Frosty was already there, but he wasn’t awake either. We both sat in silence as each of us adjusted to the harsh climate of morning. Frosty watched an episode of Dexter and continued work on the power ups while I browsed the morning funnies and tried my best to further the UI effort.
An hour later, with Frosty’s episode of Dexter finished and a full mug of coffee warming me from the inside, we were ready to be social. Skype conversation re-enabled, we discussed our progress and worked out a list of remaining features. The list seemed long, but we prioritized. Frosty would continue efforts on the core code - the power ups, and I would finish importing the art and setting up birds - an idea we’d had but not fully fleshed out the night before. Birds would swoop in from the sides. We didn’t have anything else at that point - not even any idea what they would do if they hit you.
It’s Like Electronics Hate Us By 2PM we took stock of the situation and broke for lunch. As well as the moving birds, I’d also added oscillating lava sprites to give them the appearance of bobbing and waving under you and had made further tweaks to the bungee. The bungee would now follow you down, so the cord only stretched when you hit the end of the course. This made the rope behaviour a lot less random (even if it is technically less realistic) and meant we could vary the length of each level depending on difficulty. Meanwhile Frosty had added collisions to all the power ups and implemented a basic speed up / slow down system for the character. Additionally the player could now move left and right and everything started to feel like a game, if only a prototype for the moment.
After lunch we hit another technical setback. My microphone had completely failed, the suspected cause a loose connection. While I hunted around the house like a truffling pig looking for anything with an audio jack, Frosty continued polishing the bird mechanic. We decided during lunch that the bird should steal some cheese, which we were using as a primitive score multiplier. He added an arcing flight path to make it look more natural and polished the collision zones. When I returned with nothing better than a Microsoft-branded webcam with built-in microphone and a constant, loud low-frequency hum I got to work adding the effect of cheese-stealing to the bird. After that, I also added a GUI to the main game - a countdown timer until poor Walter splashed into the lava and a cheese counter. I did my best to try to put as little on the screen as I could to avoid distracting the player.
We decided that a cube wasn’t the best art style for the bridge Walter jumps off, so I set about making one in Inkscape. At the time, Frosty was close to finishing the implementation for all the power ups (including some annoying power downs too) and was working his way through the remaining bugs with over-Skype diagnostics from me.
B E H I N D
Evening crept up on us and, with only a few hours to go before we needed sleep, we were nowhere near having a finished core game. Neither of us had given the win/loss mechanism any thought. I dreaded even touching it, and Frosty had a social engagement for the next couple of hours. I twiddled with some of the imported art assets, making sure that they all looked good and scaled correctly, knowing that I should definitely be cracking on with the win mechanic.
Eventually I took a shot at it around 10PM, and found it was nowhere near as hard as I’d expected. I realized I could make the cloth renderer act only as a visual representation of the bungee and instead use a physics spring joint. If I wanted the bungee to snap, I simply had to remove the spring joint and let Walter fall - causing the cloth to eventually tear and spring back of its own accord. All I had to do was work out when to disable the spring to give maximal effect and how exactly to decide when the player has won or failed. The latter turned out to be the most difficult part, having me stumped for a good few hours until Frosty returned. We decided to keep the physics and the result separate, to make the game easier to understand. We kept a count of the clouds the player had burst through, and if you’d hit a certain number the rope would not snap. This made it easier to convey to the player, as we could now make an easy speed bar.
Once again Frosty departed around midnight, and I kept working until 3AM, tweaking the snapping mechanic and making the level restart after the game ended. by the time I went to sleep, we finally had a playable game. I’d also, in a flash of inspiration, added a procedural component to level generation. As the game got more difficult, the jump height would reduce, giving the player less time to hit the clouds. While only a simple change, it added increased depth to an otherwise shallow game, and paved the way for more procedural systems.
Lessons Learned - If you’re still awake, keep working, you’ll feel much worse in the morning regardless. I lost close to two hours because I went to bed at 2AM feeling awake enough to keep working, but woke up late anyway and still needed an hour to focus.
Prioritize working versions over art and sound. We did art and sound far too early. I spent a good couple of hours on the first day creating art assets we wouldn’t even use until the end of this day, and by then the game design had changed sufficiently that some of the art just wasn’t useful any more. Create art on demand, make sure you have a game first. The earlier you have something playable, the sooner you can get it out to testers and tweak it to make it fun.
Best Commit HIIIIIIIIIIGHWAY TOOOO THUH… (only committed asset is “DangerZone.cs”)
15/09/2013 - 2:37AM
0 comments