Ludum Dare 35
The Theme is:

Judging ends in
Click here to start


Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created.
You NEED ratings to get a score at the end. Play and Rate games to help others find your game.
We’ll be announcing Ludum Dare 36’s August date alongside the results.

A Massive Postmortem

August 11th, 2012 7:04 pm

A wise man learns by the mistakes of others, a fool by his own.

-Latin Proverb

You’re all in for a treat, because I have been working on a HUGE post over the past few days just for you guys! It’s basically a postmortem of all my experiences in game jamming, as a relative amateur, and what I’ve learned from them. I wanted to make this post for two reasons: to focus on how to make my own jamming skills better (I’m the fool!), and, as a secondary goal, to help other people with their jamming (that makes you wise!).

Of course, I’ve done a lot of failing, so the post is a little long to put here! So, instead, I’ve put in on my blog to trick you into giving me more hits- I mean, keep my post from taking so much space. With my luck, this will be off the front page in a few days (CURSE YOU FOLIS), but oh well.

Here’s the link, and an excerpt from the summary near the end:

So, here’s a summary of all the lessons learned, or, as I like to call them, THE THIRTEEN COMMANDMENTS.

  1. Plan ahead.
  2. Do something you’re comfortable with.
  3. Let’s admit it, there are stupid questions, you just shouldn’t feel stupid about asking them.
  4. Make someone play through the game.
  5. Have all core features done by midnight on Saturday.
  6. Don’t use libraries if you find they need “minor modification” before doing what you want. Code it from scratch, or find a library that does exactly what you need.
  7. Don’t make a game without first knowing what you need to know to program it.
  8. If you’re sure you have absolutely no idea how to program it, don’t try.
  9. Don’t overestimate yourself. Make sure your design is small and well-polished and does what it can well.
  10. Have a very clear idea of how the game will turn out in the beginning. Especially when you’re working with a team.
  11. Know exactly what tools everyone is using. Seems obvious enough, but trust me, make sure you know them.
  12. Don’t immediately take someone else’s solution for your bugs. Try and solve it yourself until all else fails.
  13. Motivate yourself every second, before, during and long after the competition.


2 Responses to “A Massive Postmortem”

  1. ratboy2713 says:

    I disagree with number 6. In certain circumstances that is an acceptable thing to do, but more often than not when presented with something like that the better choice is to ask yourself “do I really need that minor modification?”. With the limited timeframe, you don’t want to spend unnecessary time coding from scratch when you can just use a library for most of it. Put that addition to the side, and if your code is modular enough, you can come back to it later if you have time.

    • Puzzlem00n says:

      Yeah, I’ve been thinking that one was a little specific. If you read the whole post (I’m not necessarily saying you didn’t), I explain that I used a camera library that I needed, mainly, for rotating, and it didn’t rotate. I suppose a better revision for the tip would be:

      “Don’t use libraries if you find they need “minor modification” before doing what you want. Code it from scratch, or find a library that does exactly what you need.”

      Yes, much better. I’ll fix that now.

      (For reference of future readers, the original was “Don’t use libraries if you find they need “minor modification” before doing what you want. Just code it from scratch. Only use libraries that do exactly what you need.)

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]