This was my first Ludum Dare. I've been aware of the event for a long time and had planned to participate before, but this is the first time I followed through. I've been at kind of a personal and creative lull so far this year, so I was looking for something to awaken my passions and thought this might be it.
If you're not familiar with Ludum Dare it's a weekend game jam and competition that happens every 4 months on the internet. You are tasked with creating a game in either 48 (hard mode) or 72 hours that fits in (optionally) with a community selected theme. You can read the rules for more details.
This time the theme was 'A Small World'. I had a few general ideas including creating a game that took place on the Small World Disneyland ride, but eventually settled on the idea of becoming a giant that tries not to step on people in a small world. I thought that it would be simple enough to do in a couple of days, kinda funny, and that it could have an interesting control mechanic with draggable feet.
Here is a link to the game:
No Step On Hyoomins @ Itch.io
I also recorded a time lapse video of the creation process. Doing that or something like a live stream is pretty common for these game jams:
https://www.youtube.com/watch?v=ZYQxab8NXqo
Another thing that is pretty common is writing post mortem that talks about what went right and what went wrong, and that's what you're reading now! One of the great things about the videos and post mortems is that they're educational to newcomers. I looked over a few of them myself before signing up for this now, and now I'm happy to add my experiences to the available pool.
# What Went Right:
1. Using PhaserJS
I am a web developer who uses JavaScript every day for work stuff, so I thought I'd be better using a language I know well. Last year I saw a fun talk by Rachel White about PhaserJS and really wanted to use it for something.
Phaser made a lot of things a breeze. The built in support for various file formats for things like sprite sheets, bitmapped fonts, tilemaps and more made it super easy to cobble things together quickly. The community support and docs were top notch. The drag and drop and interactions work on both mobile and desktop flawlessly. The scale manager and game states are amazing.
Maybe some of these things are pretty standard in modern game frameworks, but I really appreciate them! I've only written games years and years ago (Basic, Pascal, C) when things seemed much harder and any frameworks that existed were much more limited in scope. Even if these features are standard, I think they are executed very well and in an easy to understand manner in Phaser.
2. Using phaser-node-kit
One of the most painful aspects of JavaScript web development is setting up toolchains. You can develop a Phaser app just using a text editor and phaser.min.js, but you'll have to include each file in your HTML individually and worry about things like namespacing and order of dependencies if you're writing client side JS code.
We tend to use collections of tools to get rid of some of these limitations by using things webpack that allow us to require files and modules and pack them into a couple of optimized script files, but they are a pain to set up. I found a package on NPM called phaser-node-kit that did a great job setting up a boilerplate project and coupled it with browserify and a local web server to make local development a breeze with no dependency issues. Note: a local web server is required for running phaser games because of cross origin security policies.
3. Cramming before the jam
I felt a little unprepared going into the jam since I haven't done much game development, so I spent a few evenings of the week leading up to the jam studying various topics.
I started by reading Game Jam Survival Guide, which I got a free copy of years ago as part of some promotion. It was still sitting in my Packt account waiting for me. This gave me a few good pointers and a better idea of what to expect. A few things I took to heart:
- Reducing scope to fit available time and keeping things simple
- Thinking out of the box with the theme / using a thesaurus etc. for various interpretations of the words
- Not worrying about elegant code and using hacks to get things working
- Optimizing for fun in the first 15 seconds of game play since that's how much most people spend
- Funny or "Joke" games tend to do well
I also went through the HTML5 Game Development with Phaser tutorial on Lynda to get up to speed on the framework. It was pretty helpful beyond the documentation to see how a full game goes together. I didn't write much code before the actual jam, but after watching this tutorial I had a mental palette what was available and how to accomplish certain things.
I also spent some time downloading and familiarizing myself with various asset creation tools. I looked at Tiled, Texture Packer, ASEprite, Pyxel and Spriter. I mostly watched video tutorials and made sure I understood the basics of how each tool worked just in case I needed them for the jam. I ended up using Tiled, Texture Packer, and ASESprite to set up a map, create a sprite sheet, and create animations.
I was really inspired by the tutorials for Spriter and totally into the way the animation tools work! I didn't get to use it this time, but I'll be looking for an excuse. I used to do a little bit of Flash development, so the process was pretty familiar to me and it looks like it makes animating a lot more fun by moving limbs around rather than redrawing entire sprites as one would with ASEprite.
4. Not working 24/7 on this
In total I spent about 12 hours working on this game out of the 72 or so available for the jam. I didn't stay up too late at night, though I had a small cache of sugar free red bull just in case it came to that. I got off to a good start on Friday night. On Saturday I had pretty much the whole day free with zero distractions, but I wasn't really feeling up to the task in the morning. I visited my parents for a bit instead. When I got back home, I had another fairly productive few hours in the evening. On Sunday, I went for a long hike with the family, then worked on the game for an hour or so before a weekly dinner with have with our whole family (my family, my sister's and my parents). After dinner when we got home and put the kids to bed, I was able to get most of the basic game mechanics completed.
I took part of my normal work day on Monday to put some finishing touches on the game including titles, sound, music and packaging.
When it was done, I felt pretty good about what I had accomplished. I wasn't feeling burned out or exhausted and I didn't feel guilty about shutting out my family during the family because I hadn't (too much). I could have probably come up with a much more impressive game if I had put more time into it, but this was a good compromise for me.
..continued in Part 2