The process of putting the basic code structure of Knight & Ruffians into place is, as usual, proceeding well but not quite as fast as I'd like it to. Some of the design decisions I will eventually get around to talking about in detail, but for now I want to talk about a side project I've been distracting myself with!
Last January was TIGJam UK2, a get-together of people from the TIGSource development community. This was held in Cambridge, which was very convenient for me since I grew up there and still have family there. So off I went to write games for a few days as a break from writing games. Lots of big names from the indie community turned up. So much so that I didn't even get around to saying hello to everyone. It was a huge amount of fun.
Whilst there I met Luke Davies of Manatee Games – better known to the online world as LeFishy. He was doing shiny things with Unity, so I looked over his shoulder for a while since I'm interested in learning how to use it. Then he started chatting about this rough idea he had for a game and it sounded fantastic. We decided to develop two versions of it in parallel – I'd write a Flash one whilst he was working on the Unity version. We'd barely started when Craig Forrester (Ishi of Ishisoft) offered to get involved and make art for us.
Flash being what it is I had the game working complete with demo level after not very long. In keeping with my usual style I'd made the demo much too hard. This wasn't entirely accidental. I wanted to see if the game had sufficiently deep gameplay to be worth pursuing and I wasn't going to find that out by designing tutorial levels. Of course, TIGJam was full of very skilled gamers who were delighted at the opportunity to learn a new game on a tricky level. A team of solvers gathered round and inside ten minutes had completed the level. The verdict was very positive. Luke's design was a winner!
Shortly thereafter, Craig proposed making an XBox 360 version for distribution via XBLIG. This seemed like a great idea – the more platforms the better, really. And then Neil Thapen (Pishtaco) took the project to the next level by proposing we call the game "UpBot Goes Up" in preference to its working title of "Cardinals". Presumably on the basis that this was consistently the first line of the gameplay explanation offered to new players!
Of course, the journey from prototype to finished product is pretty long, but the Flash version is now complete and beginning the process of looking for sponsorship. So I want to talk a bit about the design process…
The Design of UpBot Goes Up
The core concept of UpBot goes up remains unchanged from Luke's initial idea. It's an idea that came from a remarkably silly place, actually. Stephen Lavelle (increpare) is so ridiculously hardcore that he wrote several games on the train on the way to the Jam. One of these was Modernauts, a game I'll leave you to try out for yourself because it's too hard to describe! But anyway, Luke was telling me about this, but couldn't remember what it was called. He thought it was maybe "something like 'monobots'". Which gave him the idea for a game involving robots which could only move in one direction. He said this almost as though he was joking, but the section of my brain that likes classic puzzles and NP-hard things immediately saw the potential.
Once we started to develop the game it quickly became clear that quite a lot of good puzzles could be made with no other game elements at all! If you've played a lot of very pure puzzle games you'll know that this is pretty much the holy grail of puzzle design. You want something simple, yet very deep.
In the end we did add one more element, in the form of teleporters which can move the Bots around the level. These were worth adding since they're easy and intuitive for the player to pick up, but mean you can make complex levels in a far smaller space. Huge, sprawling levels can detract from the appeal in a puzzle game, because players often feel happier if they can ponder the entire puzzle at once. Also, reasonably small puzzles are more elegant.
I was lucky with the level design work in that Luke and Craig took one look at the mad glint in my eye and basically told me I could make as many levels as I wanted to. Experience of level design from Dozer (a puzzle game I published way back in 1993) helped a lot here. Marcus Dyson, the then editor of Amiga Format, gave me a controversial-sounding but extremely good tip for puzzle design: there should be no clutter on the level. That is, every aspect of the level must be there for a reason. This advice isn't at all obvious, because it seems as though sorting out the relevant parts of the level could be part of a puzzle too. However, brute force searching of possibilities is not fun for most people. Flashes of insight are fun. It turns out that levels which don't contain clutter are much more likely to be solved by sudden inspiration than tedious grind.
I didn't design all the levels, though. Craig came up with some brilliant designs, one of which would probably be my pick for the best level in the game. And as with many games, cooperative playtesting led to many improvements to level designs which might otherwise have been overlooked.
One question I'm still not completely sure of is: how hard should the hardest level in a puzzle game be? There is an argument that perhaps the Flash version should be quite casual, saving the really tough stuff for XBLIG and maybe iPhone (which is where the Unity version is probably heading). However, we eventually concluded that so long as the early levels provide a friendly learning curve there's no reason why the Flash version can't contain a few really fierce puzzles right at the end.
So it does.
As you can probably tell, I'm very happy with how the game's turned out. I rather doubt it's going to be massively profitable, because it's not that sort of game, but it's a more-or-less perfect example of a retro puzzle game. I'll post a link once it's finally published.