Now:
October Challenge 2014
Ends in:

Coming Soon:
Ludum Dare 31
December 5th-8th, 2014

PST: 6 PM
*EST: 9 PM
UTC: 02:00

ConstructionPlease excuse the site weirdness. Mike is making and fixing things. Clocks are probably wrong. Colors are place-holder.

Ludum Dare 31:
Ludum Deals
???
 
Recent:
MiniLD #XX

A Massive Postmortem

Posted by (twitter: @theBumpus)
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.

Tags:

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]