I had an interesting design challenge thrown at me a few weeks ago.

My boss came to me and said “We’re releasing a magazine soon. We’re interested in having a free game to go with it. Since it’s a freebie alongside the magazine it’s not got a lot of budget behind it and since it’s being published soon there’s not a lot of time either. On the plus side we can use art assets from the magazine. Here are 31 images of monsters. You have three weeks to design, prototype, playtest, improve and write the rules – whatever comes out of that process is getting published ready or not. Go!”

Obviously this was something of a challenge. Now 3DTotal is a very good place to work and I’ve never been subject to an unreasonable expectation. Everyone’s aware that the game will be quick and that it’s going out free with something – nobody really minds if it isn’t very good. Certainly nobody was planning to blame me if the game coming out of a process like this was a bit of a flop.

Except me.

I mind.

Not all of my games are amazing smash hits, but all of them have delighted some number of players. I’m typically more interested in making something that sings to someone than something that’s broadly inoffensive to everyone. I didn’t want this to be the exception, I wanted it to be someone’s favourite game.

This weeks post is going to be about doing all of the things designers usually do, but at speed. I’ll let you know the shortcuts I took, the compromises that entailed and what it was oriented around to make a game that was still worth something.

My usual process for writing games to spec is to create three games that fit the bill, test them all, pick the one getting the best results and take that further. The testing and improvement cycle then takes months and months of playing the game and getting it to a stage that it does the job. The codification of the rules tends to be my weak spot, but I still make an effort to get a bunch of blind testing done to see just how much people struggle with the nonsense I write.

So the first step was to steal. The more material I could steal the better – if something’s already had a lot of design, playtest and improvement work then that’s less to do in the very limited time available, without a sacrifice in quality.

But who is there that I can steal from ethically? I don’t want to take credit for someone else’s work, especially not to their detriment or if it makes their game look worse because some players first encounter a cheap, quickly made knock off floating about.

There are two answers. The first is to steal from someone who’s long dead and far past caring. If I want to make something that’s a loose kludge on the rules for Mancala I suspect that its creator (whoever it was) is way past caring. The second is to steal from the person I know who most tolerates my nonsense: Myself!

Remember the early days of the SatW design where I followed my usual approach to the extreme and wound up making eleven versions of the game before choosing just one to ultimately be published? Those other ten versions are just gathering dust, but they weren’t all bad, particularly ones that were rejected more for not suiting the target audience than for their intrinsic flaws.

The relationship game was pretty neat, laying cards to try to match up the icons in ways that suited you was compelling gameplay. It’s pretty easy to edit that for a game about thirty monsters, trying to get people to line up their monsters so that they win. The resolution needed to change – so that monsters were harming each other and could in some way be defeated – but the mechanics of how to add cards to the grid and the set of special abilities that allowed the grid to be manipulated had now already been designed and subjected to at least some testing.

Which is pretty good for the first ten minutes of a three week crunch.

The next step was to make sure that my prototyping and improvement was rapid. There weren’t going to be a lot of playtests and testing and improvement is the heart of game design. That meant getting to a testing stage needed to be faster and iterations had to be quick.

Fortunately these are pretty natural corners to cut. Simply making a decision of “physical playtest vs TTS playtest” and only creating a prototype for one halved iteration time. Then not taking the time to do things properly ™ became worth the trouble. I usually like tools like NaNDeck that let you make changes quickly. The idea is that if you want to – say – move an icon from the top right to the top left you can make that change quickly and see it propagate through the entire deck. It saves a lot of time in the long run.

We didn’t have a long run – the time spend setting up the cards on the software would be greater than the time it saved. Plan B!

Openoffice it is! It turns out that setting a spreadsheet to the right size for a card, creating one card and copy-pasting it a bunch of times before changing the details is really fast. It’s a horrible kludge and if later you decide you want to make a consistent change on every card it’s a lot of work – but it’s fast. I had my first playable prototype within a couple of hours of being handed the job.

So with a prototype in hand and rules as intended in my head (with nothing on paper) what was left was to playtest, improve, codify and blind test. So what corners got cut on this process?

The answer is as few as possible. I can filch design ideas to make the initial design step quicker. I can decide I don’t care about having an easily managed project in the long term to make prototyping fast. There is simply no substitute for playtesting. That’s where the majority of the time went.

I only found two viable short cuts for playtesting:

The first was to engage in mathematical analysis at times that playtesters weren’t available. Knowing that one set of monsters had a higher average health or lower average attack allowed some attempts at balancing in the absence of feedback. Maths balancing will never make a good game on its own (A fair game and a good game are not synonymous).

The second was to overlap the RAI testing and RAW testing. Usually I prefer to play games explaining the rules until the rules as intended are working exactly as I’d like, before codifing them and doing blind testing until the rules lead to people playing the game in the intended fashion. There was no time for it this time around so those stages were overlapped to the point that “rules testing” playtests were also leading to balance and ability adjustments.

This is a little dangerous because it’s possible that a new or changed ability wording will cause someone to interpret the rules differently but it seemed like the extra round of balance testing was going to offer more of an improvement to the game than this limitation would hold it back.

From a game design point of view, the game turned out pretty reasonably. The last group of testers to touch it seemed to have a lot of fun. It’s not my best work – nothing created so quickly could be – but I feel like it could be someone’s favourite game. If you’re curious you can have a peek at the rules here.

Obviously the rules and the cards will be attacked by a graphic designer who’s got a similarly short space of time to make them beautiful. Usually I would be involved in that process, actively running playtests with the newly designed cards to make sure that players can follow what’s going on with the new card designs – but I gather he’s been giving a similarly short window for that stage of the project so there’s probably not enough time between the design being finished and going to print to get in a round of testing and improvement on the final designs. I’ll sneak one in if I think I can though 😉

Despite everything I’m looking forward to seeing the end result. I’m definitely snaffling a copy from the run. I think that it turned out well enough that I’ll get some fun out of it. I hope that the post was some use to you in seeing how to speed up the process when needs must, though it’s always better to take your time. Think fast and happy gaming 🙂