Ludum Dare 32 Post-Mortem

In preparation of another Ludum Dare, I am reposting my post-mortem from the last Ludum Dare.  To those who are joining for the jam or compo, good luck!

--------------------------------------------------------------------------------

Well, It's been a week since we submitted our game, Break A Leg, and it's given us time to think about what we have done.  It was a blast to make and I personally am proud of what we had made.  That being said, I feel like a proper post-mortem is in order.  Let's do this!


The Good:
Playtest the game mechanics the first night.  Most of the Ludum Dares I get lost in the details of making the game that I don't stop to think of whether my game will actually be *fun* or not.  So, playtesting the game mechanics night one made me much more confident about the direction of the game.
I had backup for programming! This one was personally huge for me, since it gave me more time to think about the structure of the code and, consequently, make better code.  A larger group also let us have some backup on each area of work.  The extra help on art and code made a much better project.
The Bad:
Time.  I know this is a common item on the bad list, but having some extra time would have been immense. Everyone had work on Monday, so the last day of the jam really wasn't an option.  We worked as late as possible and got a lot done in the final few hours, but we didn't have time to get the audio that we recorded into the game.
Split work areas.  Since we had a larger group than expected join us at the TinkerMill, we had to move into the main area for the Dare.  We had the people doing art and sound working in one area and the programming group working in another.  That led to a few issues with user interfaces and misunderstandings about what the vision of the game would be.  Although we mitigated confusion by planning thoroughly the first night, some details fell through the cracks.
The Ugly:
Having to move into the central area.  The main area was quite a bit louder than the conference room we were initially going to use, so it affected how focused we were on the game.  It wasn't a huge deal, it just made it take longer to get done.
Not participating in the warmup weekend.  I was a bit rusty on the coding side, so it took me longer to get moving on the code than it should have been.
Next Time:
Reserve the classroom.  I think that this would solve the split work area issues, along with the noisier work area.  This is easy enough to solve, though.
Practice!  Working on games is not a short term endeavor, so not practicing the art really takes it's toll between the Dares.
As always, it was a blast to make this game and we look forward to jamming again next time.

The Motivation Problem

Motivation.  Man, is this an issue!

I have done a few game jams and have only once been thoroughly uninspired by the theme. Even then, I haven't had an issue working my way through the initial, "What AM I making?" most (longer) projects I've worked on are plagued with.  It's not that I'm uninspired by the project (well, mostly, anyway), it's more of the long burn the long project presents me versus the, "Gotta go, gotta go, GOTTA GO!" mentality that pushes me through a short, succinct project that I embark on in any game jam.  Why would doing a game jam seem relatively easy compared to a solo project, where I have as much time as I need?  I have had to think about this exact problem as I work on my latest project and I think I have come up with a few reasons.

3. The rush.

I'm not sure what it is about doing a jam, but I always get a rush when I'm in them.  It's like a gaming Mardi Gras filled with fellow masochists. We're all in a fellowship of suffering for our favorite pastime, designing games.  There's some comfort knowing that I'm not the only one who is doing it, all competing for attention and glory.  That's a huge rush.

2. Long burn versus short burst. 

A solo project long-term is not the same thing as a quick weekend of design.  Sure, you can continue to develop the game you come up with in the jam, but at the end of the day, you're still facing the prospect of a long, sometimes soul-crushing, development time. A jam is nice because it has a clear, short time frame in which to work. Polishing any game takes a looong time. And from my experience, once you have that proof of concept from the jam, guess what most of it ends up being?  That's right, the polish.  I haven't quite mastered the polishing stage, since all of my games have come from quick burst of inspiration.  Once the inspiration expired, I moved onto another project that caught my fancy. The long burn of the polishing stage is the next stage I need to master.

1. It's a solo project.

I really want to discount this as my number one reason, but I must come to terms about my own behavior.  I suck working alone.  Sure, I can work my day job a whole day alone, with me being the only one in the office that day, but I feel as those days fall into the short burst category.  When it comes to the long burn type projects, having someone there to bounce ideas off of or prod me into doing that part I don't care for really helps me advance.  Not having someone relying on my work to get something done makes me want to put that project on the "I'll do it at some point" list.  This destroys most immediate motivation I have.  Honestly, I'm not sure how to remedy this.


Thank you for reading this rant!