OK, let's talk about gameplay!
Knights and Ruffians – my new game – is about trying to bring to video gaming the kinds of experiences I used to enjoy from the skirmish scale adventure games I used to play as a kid. Possibly you're scratching your head at this point. Surely "skirmish scale" should be followed by "wargames" not "adventure games"? Well, therein lies an interesting quirk of the history of adventures…
I'm not quite old enough to have been around for the birth of pen and paper roleplaying games, but I found the hobby soon enough afterwards to experience old school roleplaying first hand. We taught ourselves roleplaying with those games as a framework, but really they were wargames. The interesting part was, they were cooperative wargames. In recent years cooperative gaming has really become a hot area, but back in the early 80s we spent all day doing exactly that without really being conscious of it. Later roleplaying systems dramatically reduced the wargaming aspects, although they never fully disappeared, as a consequence of which this style of gaming was almost lost.
I also played a great many Games Workshop games, from Warhammer and 40K to the excellent Space Hulk. However, Games Workshop were always more interested in selling miniatures than making great games. When they got rid of Richard Halliwell – who was full of incredible ideas that he was never allowed to develop – I started to lose interest. Still, games like Space Hulk and Advanced Heroquest remain important landmarks in my gaming history and are sources of inspiration for Knights and Ruffians.
Not all of the ideas behind Knights and Ruffians come from the tabletop world, though. The old C64 game Laser Squad was a pure wargame, but its mechanics set the standard for turn based play in video games. Also, whilst I don't really play RTS games, ever since Warcraft I've had my eye on the genre for its attempts to give players a high level of control without resorting to turn based play.
So what's wrong with turn based play?
The primary problem is that it encourages a glacially slow pace of play. Players will always find more things to think about. There's a reason why Chess needs clocks! Real time play also isn't right for the style of play I want. The trouble with real time is that either each player must be limited to controlling a single character or the behaviour and interactions of their characters must be simplified. Not that simplification is inherently a bad thing. But the kind of game I'm aiming for wants rich, interactive, moment-by-moment tactics. If a player is controlling multiple characters it must feel more like the way a good sports team interact than like a herd of sheep.
Knights and Ruffians is going to use a compromise between the two approaches. It will have turn-based play, but with a very short turn timer. Players will have enough time to do things with several characters each turn, but only if they issue orders fairly quickly. I'll write a whole entry sometime about my plans for the UI. It needs to be very good, because otherwise the fast turn cycle will be irritating rather than being a source of good gameplay.
In theme terms the game is going to be about looting rare and valuable treasures, many of which will also be useful items. It's going to be about fighting off enemies and rivals and monsters. It's going to be about characters and stories and mysteries and… Actually, I don't even know all the things it's going to be about because I'm going to have some assistance on the writing side. More about that another time.
Also, since this is a development blog I really ought to get around to talking about the technical side of things. Soon. Very soon.
My experience of game design as an activity has always been that it is easy to have fun with. This is a good thing, of course, but it also gives rise to a problem. If you spend your time having fun it makes it easy to avoid being critical of what you do. This is particularly true of video games, because most developers seem to enjoy the design work more than the implementation and both of those more than polishing or debugging. Therefore during the early stages of a project there is a temptation to make grand plans likely to take years to complete. During implementation, the huge size of the project becomes a burden and – as is well known – few reach completion. Experienced developers then tend to drift towards shorter and shorter projects for the simple reason that they come to value their ability to complete them. Very reasonable. But maybe still bad. Indie designers have become good at finding games they are able to make at the expense of making the games they want to make.
In this context, let me talk about my new project!
What I realised, just before starting it, was that I was about to make what I call a Three Bears mistake. You know the story of Goldilocks and the Three Bears, right? Well, my previous two projects were two of the bears. Vgypt was extremely large and ambitious. I was very excited about it and developed all kinds of clever tech for it and developed enough to submit a prototype to the IGF last year. The problem was, the project was too big. It got to the point where I was having performance problems and needed to rewrite the entire game engine and probably switch language too. I decided I couldn't justify the cost of doing so and reluctantly put the project on hold. The Unicyclist was my next project. It was much less ambitious and I completed it easily. It's good, if I say so myself, you should play it! The trouble is, it's too small to do well commercially. I got some good sponsorship (from teagames.com) but free games just can't pay enough to justify the kind of development time involved. So, time for a new project that was bigger than The Unicyclist but smaller than Vgypt. Time for Baby Bear's game, the size of which would be just right.
Or maybe not. Because that's the Three Bears mistake. Having identified two problems at opposite extremes, it does not follow that the best strategy is the average of the two bad ones.
The real problem with Vgypt was not that the game was too big, it was that the software required to implement it was too big. If I were to go ahead and write a medium sized game I might well complete it, but I'd leave myself with an awkward marketing problem. Like Terry Cavanagh's VVVVVV my game would be seen as too small for a commercial release whilst at the same time being too big to finance as a free release. (Incidentally, VVVVVV is very good and I personally found it well worth the price even at launch.) Also, who wants to start off a game design with a size constraint before you even have a concept? That can't be good.
The real lesson of these designs has to do with risk. At the start of a project the question to ask is: "What is most likely to go wrong here?". The trick is to make sure that the foreseeable problems are all things you can handle. Working as an indie designer has many positive points but one of the biggest negatives is that you're very vulnerable to risk. I'm lucky to be in a position where I can have an unprofitable year without needing to pack it all in and go and work in a bank.
My new game, as you may have guessed by now, is actually a bigger project than Vgypt. In fact it's easily the biggest game I've worked on. It's the reason this development blog has made it's appearance. I want to talk about the gameplay too, but I think that deserves its own entry.
