I made a game in 48 hours! And I even like it!
I started preparing for this LD with the release of @mcfunkypant’s book “The Game Jam Survival Guide.” I had been wanting to enter the LD48 contest ever since I first heard about it 2 years ago, but the survival guide is what finally gave me the confidence to try.
Code preparations began a week before with the warmup contest. The 1 week deadline helped keep me motivated as I put together the library of important basic functions that I knew I would need. I had decided by this point to do a pixelated platformer because I felt like that was comfortably within my skill level to accomplish in the time. I used the warmup time to hash out rect-vs-rect collisions, some really basic spring/damper physics, and a set of map loading and rendering utilities. This brings us to the first major thing that went right…
What went right
Using Bitmaps as Levels
In previous projects I’ve lost many hours of game coding because I attempted to create “the perfect level editor.” Inevitably the process takes longer than I had expected, and my final product does far less than I had hoped. This time, I was inspired by a friend of mine (who was inspired by Notch) to just use the pixel data in an image as the map. Brilliant! This means that I can take full advantage of my graphics software to make rectangles and circles and rotations and flood fills… all those things that I’d never have time to implement in a homebrew map editor. Then my game loads this image and translates each pixel of the image into a tile in the world. It recognizes certain colors as being tiles with certain properties (non-destructable, collidable, non-collidable) and, if it reads a pixel it doesn’t recognize as a particular kind of block, it generates a slightly noised-up tile of the same color and gives it some default properties. This technique slayed the level-editing-dragon that has conquered me many times before.
Choosing an Art and Game Style in Advance
Two weeks in advance of the theme being announced I knew that I would be creating a pixelated platformer. Having those additional constraints in place really helped focus my thinking once the theme “Tiny World” was announced. Making the decision to make a platformer style game early also let me write the necessary collision, spriting, and map loading/drawing code before the contest began.
Being Ready with my Tools
I devoted some pre-compo time to setting up a reasonably efficient Clojurescript development workflow. I used cljs-build to monitor and continuously re-compile my source as I changed it so I could very quickly hop back and forth between emacs and the browser to see the effects of my changes. I hacked my resource fetching code so that it would keep the browser from caching anything while I was coding. I even decided in advance that my nominal sprite/tile size would be 16×16 pixels, and I figured out an appropriate scale to apply so that the game would have the retro-pixelated look I was going for.
Throwing Away My Early Ideas
To quote Chevy Ray Johnston in “The Game Jam Survival Guide”: “A great way to come up with an idea to fit the theme is to write down the first five things that come to mind, then toss ‘em. Those are the ideas everybody else is already thinking of and/or making.”
When the theme was announced I immediately starting doodling gameplay ideas on my handy pile of scratch-paper. My first idea was a game centered around some kind of proto-plasmic hero that collects nutrients and waste and transports them around a human body. I’ve now seen a few game entries that are similar to this idea, and I would have been pretty disappointed to write a duplicate game.
My next idea was some kind of RTS / resource management game where you lay out the major components and the transport systems within a cell. I wasn’t able to find the spark in that idea that would make me confident that the game would be fun. After this idea, I also rejected another idea due to its potential art scope.
After looking up “tiny” in a thesaurus, I came across the word “elfin” and its synonyms: “sprightly, playful, rascally.” Thus was born the idea for a game about the little people who are always stealing my keys. As I was telling my wife about the idea, she suggested the collecting-and-stacking mechanic that ended up being central to the game.
What went wrong
Insisting on “realistic” physics
The number one complaint I’ve received from players is the sluggishness of the controls. You see, I fell for the classic blunder of having the keyboard apply forces instead of velocities to the character. It’s my own fault. I even got that feedback from friends that I asked to play the game after the first day of the contest. I responded to their feedback by increasing gravity, increasing drag, and applying stronger forces due to keypresses. This improved the feel, but it seems that any perceptible acceleration time translates to the player’s mind as “sloshy, unresponsive controls.” Never-mind that that is the way it works in real life… sometimes reality just isn’t real enough for video games.
Not fully rewarding the player
In my game, you race a timer and collect keys (while doing general damage to some poor sap’s house). I scored the player both on keys collected and damage done but emphasized the importance of keys by giving the player an implicit goal (e.g., “You found 8 of 12!”) However, I failed to reward the player for achieving my implicit goal! Sadly, it never crossed my mind that players would want some gratification for getting all 12 keys. It’s obvious now. It should be one of the commandments of game-creation–look for ways to reward the player. You can never reward them too much.
I had to watch new testers play my game in person before I realized how unintuitive my animated instruction screen was. The problems are clear to me now: I have arrows representing arrow keys, but they don’t really look like keys; I have “SPACE” written on a horizontal blob with the player’s character sitting next to a tool, but that doesn’t really communicate “hit space to use your active tool” like I had hoped. The instruction screen came late in my development process and after I had already used up my available fresh-to-the-game testers. I should have opted for simple text to explain the controls instead.
My final tool stack was:
- Clojurescript: [https://github.com/clojure/clojurescript]
- cljs-build: [https://github.com/emezeske/lein-cljsbuild]
- zynga/jukebox: [https://github.com/zynga/jukebox]
- Garage Band (iPad)
- Paper and a blue ball point pen
- Trello (to organize my thoughts): [http://www.trello.com]
- A very reasonable amount of sleep
Things I produced:
Ludum Dare 23 was a fantastic experience. I’m proud to say that I succeeded in my ultimate goal of making a game that I actually enjoy playing. Now I’m continuing to learn as the very talented LD community members evaluate my game and offer suggestions.
It's a truck full of keys! Really!