I’ve always thought the term “postmortem” to be an odd one.  A game doesn’t die when it’s released; it’s more like a birth!  So, I’m calling this a “postpartum”.  Not that this is necessarily the best time to start using that term- my “finished” game isn’t really a complete product, and I’m not too proud of its current state.  But anyway…

Instead of trying to create the most polished game I could in 72 hours, I focused on using the jam as an excuse to force myself to learn something I’d otherwise put off- in this case, developing a mobile game (which I’d never done before).  As it’s an uncommon approach to a game jam, this postpartum is as much a referendum on that approach as it is on the game itself.

The Concept:

The Result:

What Went Right:

• I learned a new skill!  As many drawbacks as my approach has, there’s the one big benefit: I actually accomplished my goal.  Before this Ludum Dare, it seemed like it would be a nightmare to start developing for mobile devices- learning all the considerations that don’t apply to desktop and web development and getting all the necessary components to cooperate with each other.  Now, making my first real Android game seems like it will be a lot simpler of a task, though much of that is thanks to…
• The tools.  I’ve been wanting to use OpenFL (a library for developing multiplatform applications using just one codebase in Haxe) for quite some time, but I had problems setting it up before.  Those problems have been mostly resolved, and it worked like a charm.  Installing the Android tools took way longer than I anticipated, but thanks to OpenFL’s capabilities, I was able to develop and test the game in Flash while I waited for the tools to download without having to change huge chunks of the codebase for the Android version. There seemed to be a few things that worked in one platform but not the other, but resolving those issues didn’t take too much time.  I also tried a new IDE, IntelliJ IDEA, because I was tired of Haxe code completion not working in Eclipse’s Eclihx plugin.  Code completion worked much better in IntelliJ, though it appears not to detect files in the same directory as the file in which you’re working (importing classes from those files compiles fine).
• The control scheme.  I’ve heard horror stories about virtual joysticks on mobile games being the Worst Interface Ever, but the constraints of my idea (a limited camera view that may not necessarily be looking at the player character) prevented me from having the player directly touch objects to move them.  As such, I worked out a two-“joystick” setup that avoids the usual virtual-joystick problem: having to constantly make sure your finger is on the spot of the screen that represents the joystick.  Instead of having a joystick at a fixed point on the screen, my game uses wherever your thumb lands as the center point (that’s what the thumbprints represent in the concept screenshot above; the circles represent where the thumbs have been dragged to), re-centering it every time you touch your thumb to the screen anew.  As a consequence, you don’t have to look at the interface to re-center yourself.  It also has the added benefit of allowing people with different hand shapes to play the game comfortably without having to adjust the UI.

What Went Wrong:

• The phone’s accelerometer.  See my previous post for details on my problems with that.  It set me back about 24 hours, but I still had a whole compo’s worth of time left to go.
• Distraction.  I spent Saturday and Sunday working very efficiently and brimming with confidence.  Come Monday, boom- my resolve suddenly disappeared as I debated whether or not I could finish something workbale in time, and figuring out how to implement some important bits.  I ended up spending many hours just trying to de-stress myself by doing things unrelated to Ludum Dare.
• Collision detection.  Ironically, the big time-sink that became the reason why my game has absolutely zero polish (and no levels of substance) was not one of the many technological experiments I underwent in the making of this game, but rather the inherent limitations of the one tool I was familiar with: the Flixel engine.  I knew going in that I would have to implement circle-to-square and circle-to-circle collision because Flixel does not support those, and I didn’t want to spend valuable time importing and figuring out a full-blown physics engine like Nape.  I implemented those types of collision easily enough.  The problem was that I assumed that circle-to-circular-sector collision, which I also needed, was just a subset of circle-to-circle collision and would also be easy to implement.  I realized too late that the problem was not so trivial, and spent about half of my final day attempting (and failing) to work it out.
• The aftermath of the jam.  This is the major problem with the approach I tried this LD:

I knew that I was probably going to turn in a less polished product than I usually do, because this time, I wasn’t focused on making the best game possible so much as one that worked under the constraints I set for myself.  As I said previously, I was willing to accept that risk this time around, because my goals were different from what they’ve normally been since I started LD two years ago.  However, now that I have taken that risk, and I have put out an unpolished tech demo, I’m not so sure I want to do it again.  While my idea worked in principle (using the time pressure of the jam as a tool to learn a skill), I made a mistake in choosing Ludum Dare as the venue to do it.

A major purpose of Ludum Dare is to make something you can share with others- both for the joy of being involved in a community, and so others can evaluate your work to help improve your skills.  This game is not something I really feel is shareable- not in its current state, anyway (I felt a little dirty submitting it).  I’m well aware of the maxim “it’s never too early to playtest”, but I feel there are limits to that idea.  This game isn’t just “I didn’t get to include all the features I wanted” unfinished; it’s “I haven’t even completed the core mechanic” unfinished.  Because of this, I actively didn’t want to play and rate anyone else’s games– not only because it would draw unwanted attention to my own game (through the Coolness system), but I feel like if this is what people see of my work, than I have no grounds on which to evaluate others’ work (even though I’m a student of game design who’s been doing game jams for years).

So, will I use this approach to LD again?

Probably not.  I underestimated the level of gratification that comes with trying my best to make the most polished game I can, and I didn’t realize that redefining “success” as something irrelevant to the final product (in this case, the learning experience) takes away all the joy of the 3 weeks after LD.  That said, am I glad to have done it?  Yeah, I can’t really complain about having opened the door to mobile development for myself.  My technique worked as intended, not for gaining a complete understanding of mobile development, but as a way to prove to myself that I can do it without agonizing over it forever.  I’d just rather do this again in a context that has much less of a focus on other people evaluating my work.  Maybe I’ll do it again in a MiniLD- no ratings/rankings, no pressure.

See everyone next LD!