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
ANNOUNCEMENT BAR! I give you important event updates here, but this is usually invisible.

Coming Into Focus – A Postmortem/Autopsy

Posted by (twitter: @Gjarble)
August 28th, 2012 10:38 pm

Screenshot (no, really):

##################################################
#....................#...........................#
.....................#......#################....#
..O..................####....X..............#....#
##############XXXX...#...#..................#....#
#............#.......#....#.................#....#
#............#.......#.....##....X..........#....#
#.#####......#.......#.......#..............#....#
#..X..#......#.......#........#.............#....#
#...X.#.#....#.......#.........##....X......#....#
#....X#......#.......#...........#..........#.....
#.....#..#...#.......#............#.........#.....
#.....#......#.......#.............##.......######
#X....#...#..#..XXXXX#...............#...........#
#.X...#..............#................#..........#
#..X..#..............#####################.....#.#
#...X.################.......X.......X........#..#
#..........X....X................................#
#............#..........X........X......X........#
##################################################

Bluh. I submitted my game to the Jam, but I’m not sure I can say I “finished” it. It’s a very rudimentary packaging of what I was able to program within the time limit, but it’s not really a coherent “game” without a lot of explanation. Also, I accomplished absolutely none of the goals I outlined in my “I’m in!” post; as usual, I simply didn’t have time. This is my third completed and fifth attempted LD; I should be doing better than this by now!

So, what went wrong? I picked a terrible idea. I don’t think it’s a terrible idea for a game when actually executed to spec, but it IS a terrible idea for a Ludum Dare entry. The kicker is that the primary mistakes I made, I already knew were mistakes. I knew working with a language that was not my primary programming language would slow me down; I knew making a platforming engine from scratch would decimate my scope. The problem was that making an ASCII platformer was critical to my idea at the start – I wanted to impress people by having the link you click on transform into the game, using the Ludum Dare page itself as a play surface and playing off that fact as part of the story.  That required me to jump through all these hoops that slowed me down, and I had rejected all my other ideas because they were either unoriginal or had a very low chance of being fun.

Thankfully, even though I was well aware of many of my mistakes, I did learn some new things from it that’ll help me be more confident and, hopefully, get much more accomplished the next time around:

  • Technological experimentation in a time-constrained game jam is not a good idea.  I’ve read so many things about how the spirit of Ludum Dare is about going out of your comfort zone to create something unique; something you wouldn’t have made or perhaps even thought of otherwise.  That’s all well and good, and I love that aspect of LD, but I feel like that statement has some serious caveats.  Most of the experimentation I’ve done has involved structuring my games in uncommon ways that are not well-supported by existing engines.  The less you can rely on existing infrastructures and codebases to form the backbone of your game, the less you can get accomplished in all the other areas of game design, and the more potential there is for things going very wrong.  I spent about 50% of my time writing an ASCII platforming engine from scratch, and 50% of the remainder working on a Javascript exploit that was basically rejected by the submission form (in order for the game to be played on its own ratings page)- leaving very little time for art, level design, or anything approaching a coherent user experience.  Even though programming was the first game-related discipline I learned and one of my strengths, I think next time, I’m going to scrap any idea where the primary “wow” factor is supposed to be a technological aspect, in favor of experimental gameplay or storytelling methods that are easy to program.
  • Innovation doesn’t have to be in how you interpret the theme.  When brainstorming, I didn’t even stop to consider any ideas where the player character or enemies were the ones doing the evolving, or where the evolution was literal/biological in any way.  As per the aforementioned spirit of Ludum Dare, this was in order to ensure my game was unique- but I think it ended up working against me.  A lot of other people try to think like that, and in the case of this theme (or any theme based on a verb), there’s only so many other things that can evolve.  Sure enough, one of the eariler games submitted to the Compo stated in its description that, like in my own idea, the graphics were the thing that evolved.  In addition, I realized that I was sort of fighting against the theme rather than working with it.  I was categorically rejecting all the ideas that would’ve come naturally because they came naturally.  I still like that common “scrap your first idea because everyone’s going to do that” piece of advice, but in trying to innovate upon what aspect of the game evolves or how it evolves, I lost sight of the fact that there are other ways to innovate.  I have a feeling I would’ve done better had I just done a standard “characters get upgrades as you progress through the game” bit, but done so with unusual characters, in an unusual scenario or genre, or given it a unique stylization or sense of humor.
  • I should be doing FAR more detailed planning on paper.  I spent an embarassingly high amount of time looking at the top item on my to-do list (stuff as broad as, say, “enemies” or “collision detection”), wondering how to execute that particular aspect of the game, then getting distracted, forgetting the plan, and having to think it up all over again.  Here’s another thing I plan on doing next time: during the first 4 hours, I will do no programming, art, or anything else related to the production of the game.  I will simply figure out what idea I’ll be doing, then plan out the whole thing on paper, complete with time estimates and, where I’m not sure about execution, broad-level pseudocode.  I will budget for 13 hours of pure work-time.  In 48 hours, I usually sleep for 18, and since the planning would take 4, that’s about 26 hours of free time.  I cut those 26 hours in half because, having previous experience with self-estimates, I know that they tend to be pretty accurate (possibly even self-fulfilling, due to Parkinson’s law), but that I spend about half my time doing things “off the clock”- that is, real-life stuff that gets in the way: eating, bathroom breaks, distractions/breaks from work, phone calls, other unavoidable social situations, etc.  I say 4 hours for planning because settling on an idea usually takes me 1 hour (I was a bit intimidated when the keynote described it as “the first minute” of the LD experience- it took me a whole 3.5 hours to find an idea I liked this time, due to the flaw in my plan outlined by the previous bullet point), and the remaining 3 hours should be enough to make a very thorough plan that outlines the entire design (both on the user end and the programming end) in one fell swoop, so I can eliminate critical thinking almost entirely from the programming process (I work, like, 10x faster and more distraction-free when I don’t have to think all that much about it).
  • EDIT: I need to stop being such a perfectionist.  Reading Sos’s excellent post-mortem reminded me about this one.  I caught myself several times hacking away at bits of code because they didn’t work in some obscure edge case, or testing, altering the gravitational acceleration by miniscule amounts, and re-testing because the game might’ve been a bit too easy or a bit too hard without those adjustments.  I know from experience that I have a very hard time letting go of little nitpicks like that, but I need to learn to move on and come back to it if I have time (even though, deep down, I know I won’t).  In my most recent (non-LD) project with a deadline, on my to-do list, I kept a list labeled “nitpicks” of all the things that bugged me about the game that I thought would harm the user experience.  When I was done with the rest, I went back and fixed maybe two of them before I had to submit, but it was all the better because I didn’t focus on those right away.  I guess I should start doing that in LD too.  After all, why spend half an hour on fixing minor bugs in the controls when you could do it implementing something more important, like sound?

I guess I’ll end this very long-winded post by saying that, while this Ludum Dare was less pleasant to me than usual because of all my failures, I’m still glad to have done it because of how much it has galvanized me to do the next one so radically differently that I might actually accomplish some polish that time.

One Response to “Coming Into Focus – A Postmortem/Autopsy”

  1. rylgh says:

    Great postmortem, thanks for taking the time to write this up.

Leave a Reply

You must be logged in to post a comment.


[cache: storing page]