It’s weird to go back to writing about smaller games, but refreshing.  As small as about-face was, it is a “finished” game (in quotations because I still have a patch that isn’t live yet).  Finishing things is pretty important – I don’t think it’s actually the most important thing, but it’s really high up there.  And every time you finish something, you usually learn some stuff, because it is one of the primary ways of getting feedback.  So, what have I learned this time around?

---

What went right

It’s always nice to start with the positive.  I think some things went well with about-face that are worth mentioning.

1. Scope was controlled

about-face never expanded in scope – there were some things that weren’t part of the original idea that made it in, but they didn’t lengthen the game’s development significantly.  There were huge delays in the game’s development, but more due to personal interruptions, losing focus and switching to different projects.

2. The mechanic worked

General feedback has been that people have had fun with the game and often play it to completion.  It isn’t a long game, but the mechanic was interesting enough to hold peoples’ attention and was a strong motivator for people to finish it.

The idea was to take a very simple mechanic that still had a lot of space to explore, and that didn’t require lots of other sub-mechanics to make it interesting.  This made the game very fun to design as well, because I was able to be laser-focused on that one concept and make everything around it.

3. The art/sound/motif worked

I wasn’t sure how people would receive the style of the game.  From a production standpoint, this game definitely isn’t my most ambitious work.  The game mechanics, art, and sound are all very minimal, and I wouldn’t have been surprised if that was counted against it.  Luckily though, people have appreciated it for what it is.

What went not right

1. The ending

I think this is a weakness of mine, because for pretty much every game I’ve made the ending has not been received as anticipated, for better or for worse.  In this case, some people were not even sure if the ending of about-face was actually the ending or not.  Granted some people liked what I did, but when something creates unintentional confusion that’s always a failure in design.  There are parts of the game that I had envisioned as cues for the game’s ending – the final areas of the game take a step back from the mechanics earlier in the game, and serve more as spectacles than anything else – to me, this was the game gearing up for an ending, but none of this was backed up by any other cues in the game.

I think ultimately, I made a lot of assumptions regarding what people would be thinking as they were completing the game, which turned out to be wrong!  I need to spend as much time with narrative cues as I do with the rest of the game’s design.

2. The resolution

This is a weird one.  The game was meant to be a pretty small resolution to complement the simple visuals, but what I ended up with was uncomfortably small and kind of a pain to look at.  The weird thing is that part of this is because my IDE was actually displaying the game at a larger resolution than I had configured and applying AA (despite my attempts to hard-code no-AA settings), so 99% of the time I spent playing/testing the game was with a larger resolution than it would be in reality.  This is particularly annoying, because without using AA, the only way to make the game larger is to just scale everything up 2X, which is unfortunately a bit too large.  So, the only real fix is to change the game’s aspect ratio, without messing up the gameplay by making the player’s vision too small.

I guess the take-away here would be to try the game out more on the actual platform it’s being played on, and not just in the dev environment.

3. The controls

Some of the feedback was on the game being too slippery, and the gravity being way too high.  The former was easy to fix, but the latter is tricky because all of the levels are designed around the player having a specific jump height/speed.  So obviously, changing the player’s physics can have consequences on level design.

These are pretty big deals, because moving left/right/jumping encompass all of the player’s controls.  If those aren’t on point, there’s a problem with the core of the game.  Ideally, I would identify any dependencies the game has – in this case, how the level design is very closely tied to the way the player controls – and get early feedback on those elements before they’ve become fleshed out.  In this case, the problem wouldn’t have been a problem at all if I had identified that gravity was too high before I designed and iterated through all of the levels.