Creating a game is a passionate experience. Doing it in 48 hours is equal parts divinity and torture. As such, a lot goes down during the development process, laughs are had, tears are shed, and ultimately you arrive at the end product – your game.
Well, maybe I’m being overdramatic. But you definitely learn a lot upon completing a development cycle, even one as short as two days. The post-mortem is a great way to share that knowledge, imparting wisdom upon those who seek it. In this I’m going to examine what was successful, what were failures, and what just plain drove me nuts during my development of The Man Who Sold The World.
Play The Game Here
The Good
Level Design Workflow (or “Levels are the meat of the meal“)
I had an excellent workflow for creating levels in TMWSTW. One of my favorite aspect of game design is creating levels, so I made sure that process would be as smooth as possible. This meant creating a method of designing, developing, testing and finaling levels in a minimum of time.
The first thing I did was create the character and camera systems, including physics and collision detection. This allowed me to get right into levels, as I knew how my player acted and moved within the first wee hours of development. The result was over a dozen enormous, hand-crafted levels that made it in-game; not only created, but tweaked and tuned for an ideal gameplay experience.
I had the time to fully explore what I wanted to with my level designs, creating many worlds in different environments, and even get experimental with more abstract locations. The process was effective, informative, mentally invigorating and, most importantly, fun.
Source of Inspiration (or “Why the Repeat Button is Your Friend“)
You’ll notice upon launching TMWSTW that a splash screen reads, “Inspired by David Bowie’s conceptual album and story, ‘The Rise and Fall of Ziggy Stardust and the Spiders From Mars'”. That’s there for a reason – it may sound silly, but I listened to David Bowie’s “Greatest Hits” album on repeat for nearly the entire Ludum Dare – having it on repeat allowed those songs to be constantly in my consciousness, influencing my design choices. Having that aural feedback not only encouraged me to keep working, but did wonders for keeping me focused and following a coherent vision for the game.
I did the same thing when I developed Nyan Cat FLY!, listening to the Nyan Cat song during development – I’ve spent over 100 hours of my life listening to that atrocious tune, but it helped the game reach its final state. Nyan Cat FLY!, like the meme itself, is cute. TMWSTW is, like the story it’s inspired by, an epic tale about the decline of humanity.
Plus, Bowie is pretty rocking, and helped me get through the long hours of the night.
Audio Design & Implementation (or “If it’s there, use it!“)
I’m proud of the audio in TMWSTW. I spend a liberal amount of time creating game audio tracks, and like to think I’m getting better at it. I primarily use Sony ACID Music Studio 8, of which I’m lucky enough to have amassed a liberal amount of assets I can use to develop custom music. However, that’s just so much bandwidth-drinking data unless you can get it to actually sound off in-game. Flash is notoriously awful at handling audio effects, and I didn’t want to struggle through creating my own audio manager in AS3.
This is where external classes and APIs come in. Guess what – you’re not the only programmer in the world, and other people have come across the same problems. I wish I’d realized this sooner, especially for audio. Matt Przybylski has creating an amazing tool in the AS3 Sound Manager v1.4, which controls the sound in TMWSTW (and all future AS3 krangGAMES projects). Unfortunately I implemented this system fairly late into development of TMWSTW, and had already lost time trying to foolishly use my own code. Had I gone straight for Sound Manager, I could’ve saved plenty of time and effort. I won’t make that mistake again, and if you ever use audio in AS3, I highly recommend looking into it.
The Bad
Unclear Art Direction (or “Know Your Limit, Play Within It“)
By no means am I an artist. I have a confession to make: while my LD19 entry PRIOR won 8th in graphics and was lauded in being beautifully stylized, the art is only the way it is because at hour 47/48, I realized, “Oh, this game needs some better art than the debug stuff.” I then proceeded to slap a gradient texture on every background I could find.
However, that was not the case in TMWSTW. Forgetting that I’m not an artist, I -wanted- to make custom retro/pixel art for every environment in the game. Ultimately, I lost several hours of work to something I ended up simply not using. The pixel environment art I made was ugly, low-quality, and took far too much time to develop (especially including the process of moving from Photoshop to Flash, then implementing it into the game). I finally abandoned that vain attempt, and moved to Flash-generated stylized art, similar to PRIOR (though, thankfully, with a bit more color. I’m kinda getting sick of black-and-white, and actually spent a few hours on the art this time.)
The moral of the story: Don’t be something your not. If you have to, do it in the easiest way possible.
Misallocation of Time (or “Why Your Brain and Time are NOT Friends“)
In Ludum Dare, time is not just a commodity, but a deceptive bastard of a resource. What I mean is, your psychological interpretation of time is never representative of true amount of time left. Even when you KNOW that you’re running out of time, you can still very easily lose track of it and waste it on badly prioritized endeavours.
If you’ve been reading this post-mortem through, you know how much time I lost working with audio and Photoshop (more on Photoshop in a moment). This happened primarily because I misjudged both the amount of time required on these tasks, and the amount of time remaining. Admittedly I’m vastly unfamiliar with Photoshop and couldn’t make a proper work-time estimate there to save my life, but that’s a poor excuse for losing the number of hours that I did. Estimating time and collecting those estimations into a proper timeline is incredibly difficult, and it’s all too easy to misjudge that and stray too far from the path of your development.
I suppose the best method to avoid this tragedy is to quantify everything you have to do objectively, at the beginning of development. What I’m going to do for the next Dare: create a task list of everything I need to do and estimate the time it’ll take to do it. Then add 15% to those tasks. Then reserve at least six hours for polish and miscellanea, and strip away everything of low-priority that pushes me over the 48-hour timeline. Hopefully, that’ll keep me on time.
Lack of Sleep (or “Quality Is Better Than Quantity“)
Here’s an unsurprising truth: you lose sleep in Ludum Dare. There’s no way around it, making a decent game in 48 hours will suck away time like nobody’s business. Spare time doesn’t come from nowhere, so if you want to make a decent product, you’ve gotta cut something away, and sleep is the most obvious victim.
Don’t get me wrong – there’s nothing wrong with that, at least from the Dare’s perspective. Staying up late can be fun, as any eleven-year-old would attest, and the constant flow of energy and creativity that arises from game development is exceptionally invigorating.
But there’s an fine-yet-extremely-important line between sacrificing sleep and neglecting your needs. Time limit or not, your brain needs sleep, even if only for a few hours. Staying up too late under a naive notion of “If I sleep, I won’t have time finish” is one of the most dangerous things you can possibly do.
Lack of sleep will take its toll, a far worse toll than spending three-hundred minutes unconscious will. Your focus will drift, your quality of work will decline, and your overall product will suffer for your self-negligence. Taking a four-hour powernap and a shower upon waking up will do far more for your product than an extra five hours of half-baked development, followed by more hours of ever-increasing tiredness. At one point I was falling asleep at my computer – it sucked, and my game knew it. So learn from my mistakes. Go take a nap.
Either that, or adopt the Uberman Sleep Schedule.
The Ugly… Sotra
Theme Interpretation (or “Livin’ By Your Own Rules In Someone Else’s House“)
The theme for Ludum Dare 21 was “Escape”. I’ve noticed that people tend to treat the theme differently. Most people take it literally, which is fine, and often produces some pretty excellent gameplay experiences (such as NMcCoy’s excellent “Planetary Mission“, which I recommend trying out). Others view the theme in a different light, more like a guiding star than a criteria point.
This is how I viewed it in TMWSTW. Make no mistake – “Escape” is the dominant theme in my game, and it’s represented metaphorically through the player’s final actions in the game. This is not some kind of excuse for my game design, nor is it an attempt at being a pretentious douche. It is simply my interpretation of the theme, and how I chose to represent it through a video game.
Ludum Dare Compo Rule #3 states “Games must be based on the theme.” Ludum Dare is all about rapid development, and creating a product out of unfiltered passion. Basing the entire development cycle on a theme, like what the Dare has done, is ingenious, and manipulating that theme in your own fashion is an exciting thing. No matter how you interpret the theme, you’re taking a universally acknowledged concept, and making it your own. So do so however you see fit.
F**k Photoshop (or “No, seriously.“)
Please, bear with me for a moment while I depart from a more eloquent dialog and instead relinquish to the world a personal opinion that I hold, in the most base and understandable form possible:
F**k Photoshop.
For real. I love Adobe, I’m a huge fan of Flash (as anyone who knows me can attest), and the entire Creative Suite is a great product. But Photoshop and I have a beef, and I’ve gotta address it. I’ve stated on several occasions that I am NOT an artist, and as such I don’t pretend to have any level of skill in Photoshop, or Illustrator or even creating advanced artistic elements in Flash. But I do know a thing or two about product design, and creating features for users of all skill levels.
In this case, the chip on my shoulder comes from Photoshop’s inability to mass-modify colors on different layers, and then export them. You simply cannot find-and-replace colors on multiple layers (or at least, after a few hours of forum-sifting, I couldn’t find a way). As my player character had many different layers for animation, this was a huge issue. I could simply place a layer mask that changes all layers beneath it, sure, but then you can’t mass export those assets – the layer mask is not included in the export, and only default images get created. Ultimately I made a keyboard macro to duplicate the layer mask, combine it with the layer below, export that layer only, delete the layer, and move the original mask down to the next layer. Lather, rinse, repeat – a major pain.
I lost over four hours to trying to change BLACK and WHITE to ORANGE and BLUE. Four hours. Now, feel free to go off and rant, “You were using a poor method/That’s easy to do if you know how/there’s technical reasons it can’t be done/You’re a PS noob!” or whatever other retorts you may have. My point is, usability design has to take novices into account – a program SHOULD be intuitive enough that users can perform simple tasks. And replacing one color with another should be a simple task, and it is, if you’re only working on a single layer. I’m no slouch when it comes to finding solutions on online forums or hunting for methods of completing tasks, but when it takes you over four hours to jury-rig an impromptu solution to a presumably simple issue, I’m left at the conclusion that Adobe dropped the ball. Photoshop is a great program, but it’s far from perfect.
</rant>
Scope, and Knowing Yourself (or “The Uplifting Conclusion“)
I think I’m masochistic. Maybe that’s more than you wanted to know, but that’s the only explanation for the decisions I make during Ludum Dare. I’m constantly pushing myself beyond my self-determined reach in terms of development. In Ludum Dare 19, I crafted a facility larger than a standard city block and populated it with a complete, twisted back story. In LD20, I created a fully-functional level editor and allowed players to not only take the game into their own hands, but record the fruits of their labor and share them around. And in LD21, I wove a Universe. With David Bowie at my side, I explored love, spirit, daring, and the fate and frailty of humanity.
Those lofty reviews aside, the point is I established the scope of my development as HUGE. I did this intentionally, for a few reasons. One reason is, I simply love creating stuff. “Stuff” is the correct word there: I love creating levels, NPCs, obstacles, stories, music, everything that goes into a game experience. So I set ludicrous goals for myself, and push myself beyond my reach. It’s risky, and it isn’t for everyone, but it’s how I generate the best personal results (usually).
The point I’m trying to make here, is be true to yourself and your habits. Take every bit of advice with a grain of salt, and find your own best practices. Biting off more than I can chew works for me, but it can be catastrophic for others (just as trying to do pixel art nearly did me in, while some people are savants with retro graphics). We’re game designers. Only through creating games can we get better at our craft, and only by being true to ourselves can we really create a game. Anyone can build a game, but to really create an interactive experience, you have to play to your skills, nurture your muse, and be true to yourself. That’s where games come from.
In summary: David Bowie rules. F**k Photoshop. Thanks for reading. <3
<3 Nick Yonge
Founder, Director, MCS-EOOEJ, krangGAMES
www.kranggames.com
nick@kranggames.com
Facebook ~ Twitter
Tags: as3, final, flash, LD #21, motivation, post-mortem, postmortem
I might be able to do it at a friends pc the next couple of days though, so look forward to it 
