“Stay the course, captain!” A lone voice rose above the howling winds. The captain gripped the helm, icy fingers numb and skin lashed by the wind. “Just a few more days.”

sea_captain And so it is, that’s where I’m at with A Fishmonger’s Dream ( yet another new title for the game!) Just a few more days before I deliver a full, working game to Google Play, Apple’s App Store and to the thousands of web game portals out there. The other day I wrote a blog post on the Perils of Feature Creep and I wanted to reflect on what I’d been able to achieve and what I had to cut out, and in the process give a few tips from my own experience as a game developer on finishing a project. I’ve been really hard at work the last few days ( 9 and 10 were flat out development, no time to even write the blog ) and the game is now 90% complete. All that remains is to finish the levels and create a ‘rest/reward’ screen every time the player earns a certain amount of stars. Even though I have been working with Flash, Actionscript and AIR for many years now, I remain so impressed at how easy it is to build a complete product in a very short time frame. You merely need to check out this comparison list by Code and Visual’s James McNess just to see how favourably it stacks up against HTML5 for rapid development. So, looking back at what I wanted to achieve a few days ago – I realised I had to cut out a few features that weren’t integral to the core of the game. This is a little checklist I use to determine whether I keep a feature in a game  or scrap it.

  1. Have I built this before?
  2. Do I have the experience to know how long it will take to build?
  3. Is this something I think the end user would like, or just something that might amuse me?
  4. If I took this feature out, would the game suffer much for its absence?
  5. Is it something I can add later if the game is successful?

If the feature doesn’t meet 4 of those five requirements, it gets scrapped. Even if you’ve written some of the code for it, sometimes you need to be able to know when to abandon it. I’ve so far scrapped:

  • A community leaderboard for the game ( for now, points in the game are a little meaningless as each level has a ‘star rating’ system instead )
  • An upgrade shop for the boat ( again, way too hard to balance the game if the boat has upgradable sections and the art list was ballooning)
  • The game’s total levels were reduced from 100 to 50 – it’s just too hard to come up with 100 interesting levels in a short time without adding extra game mechanics
  • A rolling narrative ( originally, after each level, I had the captain telling tales of his adventure for the player to read)

This last feature, I’m a little sad about as a hallmark of my games is a sense of narrative – whether through character comments, chapter text paragraphs and so on. Sometimes – however, you can re-imagine the original feature. In this case, I combined it with the ‘instructions’ screen before each level starts. Some levels, the captain is able to add some flavour text to the game via just a few lines, as you can see below. fishmonger_6     One of the problems I find when you’re in the late stages of developing a game is fatigue setting in. Even in short projects like this, you might have tested, played, replayed, and tested your game hundreds if not thousands of times. All the fun stuff is done – all the sound is in, most of the art, the interesting prototype you wrote is now a fully fledged product ready to be unveiled. The problem, so often, is you’ve left the admin side of things until the end. There are icons to build, screenshots to grab, promotional copy to write. There are credits screens to design, help pages to write. Things you’ve been avoiding until now rear their ugly head and won’t be silenced. Here’s a few little tips for dealing with this fatigue. They’ve certainly helped me over the years.

  • Save something fun for the end. Don’t add the title screen art until the game is almost ready. It’ll look fresh and exciting.
  • Save the sound effects for late in the development. You’ll otherwise be so sick of them by the end, you might want to change them needlessly. You will be amazed at how your game takes on a new life when the sound effects and music are in the game
  • Do the grunt work early. Build your credits screen. Set up the template for your help and settings screens near the beginning. They’ll be easy to tweak and edit, and you won’t have to spend your energy on implementing them later when you’re not so enthused about things
  • Show the game to your friends. Their enthusiasm will get you over the line – you’re nearly there, the world deserves to see this!

This last point, of course, in larger projects is a given. In fact, in larger games, you will have testing groups providing feedback from the moment your game is in beta. Of course, if you are an indie developer you don’t often have this luxury ( nor the time ). My testing group has consisted of my very clever, puzzle-genius girlfriend, and the other two guys working on the project with me – the artist and the musician. Since they have different skill sets and interests to mine, I find their feedback invaluable.  They see things I don’t and hold me accountable for problems in the game I’ve been ignoring.

Anyway, it’s time to return to the game. I’m really excited about this one, it’s turned out better than I thought and I really look forward to seeing people enjoy it.

Cheers, Oliver