Last weekend I took part in the inaugural IAmAGamer game jam. It seems that game jams are all the rage at the moment, with sites such as OneGameAMonth, Ludum Dare, 7dFPS, and the Global Game Jam all encouraging would-be game devs to stop talking about making games, and actually start doing it.
The theme for the iamagamer.ca jam was particularly interesting – with no restrictions on game genre, style, or technical aspects, but requiring only that you create a playable game in 48hrs in which the main player character is female. You can read more on the background by the jam organiser in this article on the CoronaLabs blog. But it was a sufficiently interesting hook and worthwhile cause for me to want to get involved. And, it also gave me a good opportunity to exercise the fledgling Unity3d skills that I’ve been teaching myself over the last few months.
I decided that, in order to stand any chance of creating a playable game in a weekend, I needed to keep the basic game mechanic simple, and I chose to create an “into-the-screen infinite runner”. I’ve recently discovered the motion capture library at Carnegie Mellon University and my intention was to use some of the gymnastic/acrobatic/ballet motions there to animate the lead character in a graceful, feminine way, navigating obstacles in a free-running race across building rooftops (in my head, I had a simplified “Mirror’s Edge”, but from 3rd person perspective).
In practice, the game fell rather short of my original intentions, mainly due to my inexperience in 3d animation and underestimation of how much work would be involved in importing and cleaning up the motion capture data. Here’s my state transition diagram for the player animations, for example:
The player would have to perform the correct action (swipe up/down, keypress etc.) to switch animation state to “Vaulting Over”, “Sliding Under”, “Cartwheeling Over” etc. as appropriate for the obstacle in front of them. However, having never really worked with mocap data before (and from subsequently reading others’ experiences of working with the CMU mocap data), I found a lot of issues with basic things like joints being rotated, incorrect offsets, framerates etc. which led to my character model collapsing on the floor, limbs flailing, falling through obstacles etc. I spent too much development time during the jam re-running the game over and over with tiny adjustments to animation offsets etc. trying to make it look right, which means the gameplay and other aspects of the game suffered (as it turns out, a weekend goes really quickly when you’re trying to make a game from scratch!) and I never even got time to implement the game mechanics for some of the animations shown above.
Then, quite near the end, I foolishly changed the game’s physics (switching from Unity’s inbuilt PhysX engine to my own custom kinematics) which, had I made such a design decision right at the beginning would have simplified development. As it happened, it ended up messing up the animations again. Whoops.
I was probably naive and overambitious to think that I would just be able to drop some free mocap data onto my 3d model and expect it to work. However, I enjoyed the experience and I learned loads – details of the BVH file format, Mecanim’s ability to retarget animations to different humanoid models, 1D and 2D blending, Unity’s multi-layer animation state machines… and I plan to write some more blog articles on these subjects shortly.
Here’s a timelapse video (made with the excellent Chronolapse) showing the game’s development:
And, if you have any interest in creating games whatsoever, I strongly recommend you consider participating in a game jam – although, like me, you probably won’t be able to implement everything you intended, the motivation of working in a constrained time limit really helps you focus and get on with it, and it’s a lot of fun. Although my game is not very good, I’m certain the experience of attempting to create it will make me better for next time…