Nineties Holywood Hacker post-mortem

Posted by (twitter: @jayrob_in)
May 1st, 2012 12:06 pm

(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!)


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.


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.
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.
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.


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]