Today, As I Was Crawling Across the Floor…

As I believe I’ve already mentioned, I play a number of board games but, before you think “Oh no, not Monopoly!”, these are along the lines of the German-style board games, games that place some emphasis on strategy, don’t depend too heavily on luck, may have collaborative elements (or an entirely collaborative theme), tend not to be straight war games and manage to keep all the players in the game until the end. Notably, German-style board games don’t have to be German! While some of the ones that I enjoy (Settlers of Cataan, Ticket to Ride and Shadows Over Camelot) are European, a number are not (Arkham Horror, Battlestar Galactica and Lords of Waterdeep). A number of these require cooperative and collaborative play to succeed – some have a traitor within.

I have discussed these games with students on a number of occasions as many students have no idea that such games exist. The idea of players working together against a common enemy (Arkham Horror) appeals to a lot of people, especially as it allows you to share success. One of the best things about games that are well-designed to reward player action and keep everyone in the game is that the tension builds to a point a final victory gives everyone fiero – that powerful surge of joy.

Now, while there are many games out there, I decided to go through the full game design process to get my head around the components required to achieve a playable game. I’ve designed some games before and, after a brief time spent playing them, I’ve left most of them back on the shelf. Why? Poor game design, generally. As a writer, I have a tendency to think of stories and to run narrative in my head – in game terms, this is only one possible passage through the game. One of the strengths of computer games such as Deus Ex is the ability to play multiple times and get something new out: to shake up the events and run it in your order, forming a new narrative. (In DE, technically, you were on rails the whole time, the strength of the game is in the illusion of free will.)

Why is it important for me to try and design a good game? Because it requires a sound assessment of what is required, reflection upon how I can model a situation in a game, good design, solid prototyping, testing, feedback, revision, modification, re-testing, thought, evaluation and then more and more refinement. From a methodological point of view, my question to myself is “Can I build a game that is worth playing based on a general sketch of the problem, a few good ideas and then a solid process to allow me to build game features in the way that I would build code features?”

Right now I’m in the requirements gathering phase and this is proving to be very interesting. I’m working on a Zombie game (oh no, not another one) but I want to have a three-stage game where the options available to players, resources and freedom of action, change dramatically during each stage. I want it to be based in London. I want to allow for players to develop their characters as they play through a given game. I want player actions to have a lasting impact in the game, for decisions to matter. I want the game to generate a different board and base scenario set every time, to prevent players learning a default strategy. I want the whole thing to run, as a board game, in the German style. I want the instructions to fit onto 8 A4 pages – with pictures.

(I should note that I’ve been playing games for a long time and made a lot of notes about rules and mechanics that I like, so this has all formed part of my requirements gathering, but I’m not trying to put a new skin on an old game – I’m trying to create something interesting that is also not a blatant rip-off. Also, yes, I know that there are already a lot of zombie games out there. That isn’t the point.)

I’ve been crawling the web for pictures of London, layouts, property values, building types and other things to get London into my head. Because the board has to change every time, and I can’t use computer generation, I need a modular board structure. That, of course, requires that the modules make sense and feel like London, and that the composition of these modules also makes sense. I need the size of the board to make the players work for their victories and not make victory too easy or too hard to attain. (So, I’m building bounds into the modularity and composition that I can tune based on what happens in play testing.)

I knew this but my research nailed it as a requirement: London is about as far away from being a grid layout as you can get, with a river snaking through it. Because of this, and my randomisation and modularity requirements, I had to think about a system that allowed me to put the elements together but that didn’t make London look like New York.  Instead, I’ve opted for a tiled layout based on hexagons. They tesselate nicely, you can’t run in straight lines, and you can’t see further than the side of one hex, which reflects the problems of working in London without having to force someone to copy out a section of the London map with all of its terrible twists and turns.

The other thing I really wanted to know was “How fast do zombies move?” and, rather than just look it up, I’ve spent a bit of this afternoon shambling around the house and timing myself to see what the traditional “slow” zombie does. Standard walking and running are easy (I have a good feel for those figures) but then I thought about that stalwart of zombie movies – the legless crawler. So, in the interests of research, I measured off a 10m course and dragged myself across the floor only using my arms. Then I added a fudge factor to account for the smoothness of the floor and, voila, a range of speeds that tell me how long zombies will take to move across my maps.

Why do I need to do this? Because I’ve never done it before. From now on, if someone asks me what the estimated speed of a legless zombie is on a level surface, I can say “Oh, about 0.25m/s” and really stop the conversation at the Vice Chancellor’s cocktail party.

Requirements gathering, around a problem specification, is a vital activity because if it’s done properly then you gain more and more understanding of the problem and, even though initially the questions seem to explode, you can move to a point that you have answered most of the important questions. By the time I’ve finished this stage, I should have refined my problem statement into a form that allows me to write the proper design and then build the first prototype without too many further questions. I should have the base rules down in a form that I can give to somebody and see what they do.

By doing this, I’m practising my own Software Engineering skills in a very different way, which makes me think about them outside of the comfortable framework of a programming language. Students often head off to start writing code because it’s easier to sit and write code that might work, instead of spending the time doing the far more difficulty activities of problem specification, requirements gathering, specification refinement and full design. I don’t get much of a chance to work on commercial software these days, so a zombie game on the weekends is an unusual, if rewarding, way to practice these skills.

Sliding across the floor is murder on the knees, though…