Ludum Dare 25 Post Mortem

December 29, 2012 | Posted in gamedev, Ludum Dare | No comments

My entry for Ludum Dare 25: “You are the Villain” is Muffin the Destroyer.

Development Timelapse Video (4:17)

Here’s my pearls of wisdom extracted from the clams of development.

What went right

  • The Setup & The Punchline

    Overall the game came out how I saw it in my head – the tutorial feels silly & crappy, Muffin feels tiny & slow, low expectations are set. Then the stage changes perspective and adds some juice (more on that below), and things are different.

    Muffin technically controls exactly the same in the tutorial & stage – jumps just as high, walks just as fast, etc. It’s just a difference of camera position for scale, and some extra effects added in.

  • Show Controls are shown

    I’d mentioned in my previous LudumDare post-mortem:

    This is a common failing of Ludum Dare games, where the authors spend so much time neck-deep in the game, things that appear obvious to them isn’t actually obvious. “Of course you aim with the mouse!” The fact that I fell into the same pitfall as last time bothers me more. You can be sure I’ll be watching out for this next Ludum Dare.

    This led me to create Show Controls, a unity package for showing controls to users that’s designed to require minimal configuration, so it can be used quickly in Ludum Dare.

    I think I’m the only one who’s ever used it, but it fulfilled its purpose well here; I set up a few ShowControl instances with the various dialogs I wanted, added some trigger colliders to change from one to the next, and that’s that! I’ll be using it again in the future, and suggesting it to others whenever the topic comes up.

  • Physics is Phun!


    Muffin with the “stomp effect” radius visible

    My previous entry had a lot of problems with Unity’s physics engine, which in hindsight I can attribute to the much-maligned Character Controller and its interaction with rigid bodies.

    This time I ditched the Character Controller after about 30 seconds, set up a kinematic rigidbody for the player, non-kinematic rigidbodies for people & houses, and static colliders for the road, and poof! everything’s happy as can be.

    This is one of the positive feedback loops I look for in these contests – here’s something that I wasted a good few hours on in a previous competition, but now solved in a matter of minutes. This left me hours to waste on OTHER annoying problems, which would be again future-solvable faster.

  • Juicy!

    I knew I needed the stomping & swiping to feel much more “satisfying” after the tutorial, and the concept of “Juice“, or extraneous effects that provide better feedback to users, came in to play heavily. The sound effects, the camera shake, and the “waves” that appear when stomping & swiping made them feel much more powerful than in the tutorial stage.

  • Gitified

    This was the first time I’d used any revision control during a LudumDare, as I’d been previously unaware that Unity enabled the “external metadata” feature in their free version, which is required for external SCM. Had no problems with it, and kept the public GitHub repository up to date as I went along. Not that I’m presumptuous enough to think that anyone wanted to follow my every action during the weekend, but it provides a nice log of events of what happened during the 48 hour jam.

What went wrong

  • “Game”?

    My Ludum Dare games tend to be rather short and not have a lot of content, but this was by far the shortest. I’d argue it barely meets the criteria of a “game”; there is no challenge whatsoever as there’s no way to lose – Muffin can’t get hurt in any way. You simply advance, and that’s the end of it. It’s more of a humor/performance piece than a game. Not that there’s anything wrong with those things, but it’s not what the competition is about, and it’s not what I set out to create.

  • Churning out Content

    The limiting factor during this LD seemed to be how long it takes me to make all the assets for the game – modelling, texturing, rigging, & animating Muffin, modelling & texturing the building/road/people/ground/background/effects, creating the sounds, creating the music, etc. I feel like I didn’t have time to make a game with all the time I spent making STUFF for it.

    I’m approaching the point where I’m satisfied with the assets (but not quite there), but I’m already spending too much time on them. I hope to work with some 2D frameworks before the next Ludum Dare, either C++/OpenGL/SDL or Pygame, as it seems 2D sprite work would be much faster than messing with the 3D stuff and allow me to focus on where I feel my games are lacking – the “game” itself.