What I’ve Learned from not Finishing: A Postmortem

Posted by (twitter: @gamepopper)
December 18th, 2013 4:44 pm

Hey all! I’ve been enjoying a lot of games from this Ludum Dare, and I hope you all have to. I participated myself in the jam, collaborating with another indie game dev known as Code_Assassin. However, through details I’ll explain below, we didn’t finish. While we did submit an entry, it wasn’t a finished game like we hoped, and after a day of thought, we requested the entry to be taken down, and the game removed from Newgrounds.

The idea

Our game originally started off with a premise of finding a mob boss out of a group of people, the levels and the clues would be random each time, but you only had one chance at killing the boss. We agreed on using Flixel as our framework due to its ease of use, my experience from using it in last year’s Ludum Dare and CA’s experience with Actionscript3, and that we could upload it to the web. We got a Git repository set up and we were hyped up and ready to go!

What went wrong?

Time: Despite having 72 hours, plenty of time to work on a short game and with two people instead of one, time was not our friend in this collaborative jam. Along with having work or school or get together that were already planned before Ludum Dare, both CodeAssassin and I were living thousands of miles apart (USA and UK respectively) with a large timezone difference and our only means of communication was a Skype chat window and a Git repo. Finding a time forĀ  us both to work together wasn’t easy, and there was more than one occasion where only one of us could work on the game, and being in different timezones meant it was likely that one of us would be up really late or really early (basically, not at our best state of mind) to work on the game.

Planning: Our planning was that there really was an idea and a mockup, that was it. This was bad for us later into the development as ideas were changed around, and neither of us could agree on features or where the game should go. For example, when I was interesting in a more minimalist style to save on time with graphics, while CA wanted animated sprites to make the game stand out. There were also points where we were not sure of what to add, which slowed down development.

Tools Experience: Like I stated earlier when we decided to use Flixel, CA knew AS3, but I was the only one that knew the framework, and my experience in AS3 wasn’t as strong as CA’s. This meant that we struggled on understanding what we were using more than how the game should work. If we had about a week to prepare by getting to know the tools, with me showing how Flixel worked and CA giving me pointers on how to code in AS3, we would’ve used more time in making our game when the game jam began.

What went right? – Because it wasn’t all bad.

The idea: We spent less than four minutes brainstorming, suggesting and collectively agreeing on an idea, and despite our lack of planning, we stuck to that idea. We didn’t change from the basic concept, a randomly generated exploration game, which is never a smart move when you only have less than three days.

Source Control: Coming from someone who rarely uses some form of source control (despite having experience with Team Foundation Server and Rational Team Concert), I’ve found Git and GitHub to be very useful during our Team Project. Gone were the actions of having to send files over, as GitHub did that automatically! I’m gonna be using it in future gamejams and certain open source projects, so I’m glad to try it out in this game jam.

Effort and Enthusiasm: We may not have gotten a game we felt was mostly finish, but we didn’t give up or stop until we were in the last minute. We spent as much of the available time we had on this game and we were constantly adding to the repo.

Lessons Learned

Prepare for at least a week prior to the game jam starting, even if you are using tools you have good experience with.

Agree on an idea, and a plan (for what should be in the game) and stick to it. Experimenting should come after you’ve finished your initial goals.

Make sure you are free for most of the duration, and make sure you are free to talk for as much time as possible.

Use source control! It makes contributing as a team easier and it’s a good method of backup.

Finish a damn game!

Thank you for reading. :)

Tags: , , , , , , , , , , , ,

One Response to “What I’ve Learned from not Finishing: A Postmortem”

  1. Theintentnerds314 says:

    i also havent finished a game

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]