Hey everyone!  I’m back for my 6th attempted (and hopefully 4th completed) Ludum Dare!  Although I’ve completed a few games in the past, I still really have to work on my polish and work ethic- I haven’t been too good at either of those things in past LDs, and it shows.  After the disaster that was last time, I am now committed to learning from my mistakes and Doing Things Completely Differently.  Here’s how I’m changing up my process from last time:

• Having my tools set in stone before the compo.  In the past, I’ve been tempted to use an engine I was less familiar with or write more code from scratch because it better suits the idea- this time, I established what I’m going to be using well in advance of the theme announcement – all tools that I’m familiar with and will allow me to prototype quickly.  I’ll be working in Flixel, with Photoshop CS3 for art, Bfxr and Audacity for sound, and GarageBand for music.  These will restrict the kinds of games I can make, but the assurance that I won’t overscope on the core mechanic alone is worth it.
• Focusing less on an innovative high concept and more on polish.  Of course, I always want my gameplay to be innovative, but my ideas are usually a bit too “let’s put a big ol’ gigantic TWIST on the theme”, forcing me into oddball gameplay structures that don’t lend themselves well to the tools I use.  This time, I’m focusing on wowing people less with the elevator pitch (I’m doing a game about alien abduction- not too unusual) and more with the actual experience.
• Not making a platformer.  I tend to think too much within preexisting genre conventions.  This time, I wrote at the top of my brainstorming sheet “NO GAME GENRE REFERENCES ALLOWED”.  I thought purely in terms of what kind of villain the player might play, and what primary “verb” the villain will be doing.  I think that it’s paid off – the idea I’ve settled on would probably be best described as an “action game”, which is pretty damn nonspecific (at least compared to things like “shooter”, “beat’em up”, or “platformer”).  This allows me to branch out a bit in terms of game design, and think less inside the box.
• Planning, planning, planning. I’ll be writing out every little thing I plan to implement, how I plan on implementing it, and how long I plan on taking to implement it (within a fixed time budget of 13 “on-the-clock” hours, not counting meals, sleeping, and such), so I don’t get carried away with designing while I code.  It’s a distraction, and keeping all the info I need in my head has severely slowed me down by forcing me to constantly remind myself what I’m doing.  Of course, if playtesting reveals something interesting (or uninteresting), I’ll change the design accordingly, but I’m not going to improvise while I’m typing out the code.
• Tossing away my nitpicks and worrying about them later.  So the collision’s a little off.  So the spawn rate of enemy X is a little high.  Who cares?  I’ve got an entire game to finish!  Instead of trying to fix these little things, I’ll put them in a list to fix if I have more time, and move on to more important things, like interesting mechanics, art, and sound.
• Reserving time to make music.  I don’t care if all I’ve got in the game after Day 1 is Hello World, I will put some music in this game if it kills me.  I have yet to have a game with polished gameplay, art, sound effects, AND music – something that really feels complete instead of just thrown together.  I plan on changing that this weekend.
• Stretch goal – Progress shots!  I have yet to supply in-progress shots of my game, because I’m too busy rushing to make something barely playable.  I want to participate more in the community, and I want to feel less pressured about the amount of time I have.

Well, I’ve spent long enough writing this (that’s another thing I need to learn not to be so perfectionistic about)- time to get to work!