This was my first Ludum Dare and I thoroughly enjoyed it. Not only because I learned a lot in a short time, but also because I made (what I believe is) a pretty good first iteration of a game in just 48 hours. I have plenty of ideas for what I could do with the game, but I’d much rather find out what the players want and build that into my backlog. That is one of the great charms of Ludum Dare – building a prototype and getting guaranteed feedback from real players.

As of writing, my game has 34 comments. I could go through them one at a time and tick off each feature request, bug report, etc, but that would be long and stupid. So, here’s what I did instead:

1. Gather all feedback
I copied and pasted each comment from my entry page into Excel and cut out any that very clearly didn’t provide any useful feedback (e.g. “Awesome game!!!1″ or “I didn’t like it”)

2. Split feedback into negative and positive key points
The point of this step is to understand what each piece of feedback is actually telling you. I found it helped to make a list of negative and positive bullet points for each comment. Take this example:

“I like this, it has a lot of potential. Here are some of my random thoughts…

It’s rather slow paced. It feels less like action than “Line up with an enemy, start shooting, wait, dodge it, wait, wait, dodge it, aim at next enemy”. Also, because there are so few enemies in each stage, it feels empty.

It’s hard to keep track of where you are. It would be awesome if there were a minimap during the shooting bits.

I got frustrated with placing pieces, but then I figured out, you can’t place a piece if it doesn’t match up? That does make sense, but with a little work it could be better. How about if the game checks if there’s a valid path, and it won’t let you place a piece that makes the path invalid? Also, what happens if you run out of room? Perhaps you could place pieces over previously placed pieces to delete them.

I’ll be looking forward to later versions! ”

If we extract the key positives and negatives we get:

Positives:

• Good concept

Negatives:

• Slow-paced ship section
• Too few enemies in a room
• No in-game map
• Difficult to figure out level building (tile placement)
• Unintuitive level building (e.g. just place junk pieces elsewhere until right piece appears, potential to run out of room)
• Build stage lets you proceed to ship stage even if a path doesn’t exist from start to goal

3. Group feedback points and sum totals to rank them
At this stage, you’re still left with a long ‘to do’ list of overlapping or contradicting items. You should group similar points together and rank them according to the totals

You can see below the tally of my groupings:

My interpretation is that people really enjoyed being able to create the levels before flying through them, but the level building could be better implemented, explained and introduced. The other major feedback points were around the ship sections being slow-paced but occasionally too difficult (green rooms are too easy and red rooms are too hard), and enemy ships starting too close to the door when entering a room.

4. Take the top negative items and determine how you can resolve/improve them
You should now have a list of items, ranked by the number of people who commented on that aspect of your game (I took anything that 2 or more people commented on). The idea is to remove the pain points by taking the most commented negatives and working out how you can turn them into positives. So, another example:

“I don’t fully understand the level building section”

Improvements:

• First level goes straight into ship section, second introduces level building with short tutorial
• Prevent level start until route exists between start and finish
• Remove restriction on tile placement (can place anywhere)
• Replace random tile selection with ability to choose which tile to place next

Note that you may occasionally need to refer back to some of the comments if your items are too general.

You should now have a pretty full to do list of changes that will make the biggest positive impact to players, which you could merge with your previous list of new features/fixes to cater for the few things that players may not have thought of.

(Yes, I realise I spelled Hollywood wrong, but I didn’t want to cheat and fix it after the deadline)

Link to my game (ratings and feedback appreciated!)

Background

I have a bit of experience in Flash and have released a few small games over the past few years. I took a hiatus for a while and picked it up again about six months ago very part-time. I’ve wanted to give Ludum Dare a try for ages, but honestly didn’t think I could actually finish anything in <48 hours. Since this was the 10th anniversary, I figured I’d block out this weekend and force myself to at least try.

I read a lot of post-mortems to try and learn from others, and made a few very very simple games in Flixel last weekend to familiarise myself with the library.

Tools

• IDE: FlashDevelop
• Library: Flixel
• Graphics: Paint.NET
• Sound: as3fxr

The finished product

Nineties Holywood Hacker has you hacking like in a cliched nineties Hollywood movie, i.e. with no resemblance to actual hacking in the real world. First, in the Pipeline-esque intro game you need to build a link between your computer and the target node. Then, you have to fly through the link cell-by-cell from the start to the exit in a top-down Smash TV style. Watch out for rogue security programs and collect coins to buy upgrades.

What went well

• Editing levels visually

I started off trying to make levels in a text editor and hard-coding them. This was fine for the very early testing, but as soon as I started on the actual game I gave FlxTilemap.imageToCSV a try and drew monochromatic tilemaps in Paint.NET. Making changes to a level became as simple as ALT-Tabbing to Paint, drawing a couple of black/white pixels and recompiling.

• Planning

At the start and whenever I came to a good stopping point, I spent 10-15 minutes updating a features, tasks and bugs list, estimating how long each might take and prioritising accordingly. Because of this, I implemented *nearly* all of my originally planned features and fixed all the major bugs with time to spare.

• Taking regular breaks

Sometimes I’m in the zone coding for hours and everything compiles first try. Other times I’m stuck for ages trying to fix a bug and it turns out to be something stupid like for(i = 0; i < numEnemies; j++). For the most part, I was pretty good at stepping away from my PC for five minutes every so often to reset my brain.

• Build an MVP and iterate

A ‘minimum viable product’ is the minimum feature set for your product to be in a releasable state. Since I was worried about not being able to finish in 48 hours, one of the first things I did was figuring out the absolute minimum requirements for the game I *knew* I could implement in a few hours (e.g. basic main menu, player controlled entity, basic enemies that move towards and destroy the player), and built a working bug-free version. Then, I did this again with another logical grouping of features (tilemap+collision detection, different screen-sized rooms, ability to move between rooms). I repeated this process until the 48 hours was up.

• Made use of available libraries

Little to say on this except I now love Flixel. Even being fairly unfamiliar with it, things like animations, pathfinding and collision detection were ridiculously easy to implement. I guess my point is: don’t try to reinvent the wheel in a weekend (unless that’s the theme).

What went poorly

• Tried to implement two mechanics

While I really do like the Pipeline/level editor subgame, I essentially had to split my effort 50:50 between that and the main game. The entirety of day one was spent on the main game and day two on the subgame.

• Doing the graphics

I’ll be honest: I’m really bad at art. I should have accepted this early on and gone for a minimalistic style from the beginning, but instead I kept coming back and adding a little extra colour here and a half-finished animation there. The end result is a complete lack of consistency.

• Chasing annoying bugs

The example earlier wasn’t the worst bug I came across – I spent over an hour trying to figure out why my sounds weren’t importing and it turned out that when exporting from as3fxr to Audacity and converting to mp3, I should have saved them with IDV1 tags rather than IDV2. One simple click and I could have had an extra hour to add another cool feature. But is there really a way to avoid this entirely?

• No time for balancing

This was one of those “I’ll do it last” tasks. Unfortunately, given how close I was developing up to the finish, I ended spending less than 15 minutes playing through a couple of times to mess with the variables.

What I’ll do differently next time

• Focus on a single mechanic

This really should be an obvious one, as it’s pretty much Game Jam 101: come up with a single innovative gameplay mechanic and get it working really really well.

• Balance the gameplay as I go

While I was constantly playing it, I could have easily spent a bit more time playtesting as I went and tweaking the variables to make it a bit more playable, rather than planning to set aside a few hours at the very end but running out of time.

• Use the theme to guide the project, not just the initial brainstorming

My use of the theme was simply writing ‘Tiny World’ on a piece of A4 paper and brainstorming mechanics around it. Once I’d come up with something I liked and thought I could achieve, I completely forgot about the theme until a few hours before the end. Ideally, the theme would guide every one of the metrics you’re scored on.

• Implement basic tracking

Playtomic takes <10 minutes to set up and implement, and it would be really nice to actually see how many people are playing it and for how long.

• Get a good night’s sleep ahead of the compo

After a long work week and a heavy Thursday night, I was already knackered on Thursday but decided to stay up until 2am GMT to see what the theme was, in the hope that I’d have a spark of genius in my sleep and wake up with a pre-designed game in my head. Instead, I slept until about mid-day and dreamt about ducks.