Finishing a Design

Once you've finished the experimental middle stage of design, and you're happy with the game's fundamental systems, it's time to move to late design.

Narrowing down

During this phase, you must make a conscious effort to end the project. Do this not by neglecting to polish your game. Instead, do it by being less and less open to changes.

As time goes on, through middle and late design, reduce the scope of changes.

Your game is what it is. Don't chase what it could have been.

There are many ways to make a game. You need to pick one, and stick with it. It's not going to be perfect, but no game is perfect anyway.

During the development of my gangster game, I'd often feel like something wasn't quite right, so I'd make a mid-level change to the game. However, this never really stopped, and after about 270 revisions, the game still wasn't done. I'd been working on the game on and off for about ten years. During this time, I was proposing the game too. It was eventually accepted for publication, but it's not quite finished, so the publisher is doing significant design work on it.

You can go backwards, and change things, but only do it to fix things, not to improve the game, or add something cool.

Late in the development of my pirate game, I realised there was a problem. You could attack someone, and steal their stuff. However, they'd just attack you back, on their turn, and steal their stuff back. This could go back and forth for a while. I thought of complex answers that required new concepts, like "damage" cubes, that would wear off, over time, to stop the attacked ship retaliating. There could be a special token that specifically stopped attacked players from attacking on their turn. In the end, rather than adding a disruptive new rule, I just added an ability to the already-long list of abilities. It's called Banish, and it just lets you send an adjacent ship away from you. This breaks up these repetitive fights very easily, and does so without adding any rules.

If you can fix a problem by just changing game objects, not the rules, then do it that way.

My farm game has gone through 178 revisions. (People were telling me it was publishable at revision 40.) It's possible that the two-player game is too tight. If that's the case, I'll probably just give each player a gold to start with. This allows the player to use an occupied space.

Very late in design, just remove things, rather than fixing them. If it's an action space, just have one less action space. If it's a card, just have one more of another card. You didn't need that exact amount of game content anyway.

Sometimes, you will need to add little caveats or complexities to rules or objects. This is fine too.

Ending a design is a compromise. It has to be that way.

When is the game done?

Very late in design, you'll start doing playtests, and not want to change anything afterwards. Look out for this starting to happen. Most of your playtesters will feel the same way, and be unable to find fault with the game. Eventually, you'll play the game several times, without wanting to change anything. That's when the game is done.

Your playtesters will also feel very positive about the game, and start telling you when they can buy it. They'll ask if they can have their own copy to play (no they can't). You'll feel the same way about the game.

Democracy

Playtesters can't always understand the reasons why things need to be some way, to make the game work. However, there are many things that are non-structural, and just a matter of preference. Late in design, just start asking playtesters what they like, and go with the majority.

You need to make it clear that, on many of these things, you are not the expert. The playtester's opinion is as valid as yours.

There was a space in my farming game that gave you a bonus, and everyone (including you) got a cabbage. Is it fun or not, for players to get resources from other players' actions? I wasn't sure, but the playtesters liked it, so it stayed.

In my farm game, there is no spatial element. However, I made some buildings that occupy more than one space. This makes the arrangement of things occasionally matter. This contravenes my rule that says that there should be lots of something, or none. However, what actually matters is what the players think. And, my playtesters are similar to the people who will actually play the game. They told me that multi-space buildings were okay, so I went with them.

Also, get a feel for the big picture of your game. All these things are simply a matter of opinion, and you should generally go with the majority.

In my pirate game, there was an ability called Capsize. Your ship lost one of its goods cubes. A playtester said the cube should sit on the sea, so a player could pick it up. I thought that was a bit pointless, but I tried it, and the playtesters loved it, so I kept it.

Game length is the clearest of these questions. Adjust it until the players feel it's right.

The "Theme Pass" is one of the final phases my games go through. It's almost entirely democratic. With as many playtesters, one at a time, we go through everything.  We go through the name and design of every card, action, and resource. We go through all the icons, colours, and wordings.

And, when absolutely everything is done, THEN you write the proper rulebook. :) That way, you don't have to update it every time you make a change.

What don't you need to do?

You don't even know if any publisher will ever be interested in your game, so only develop it to the point of publication.

Your game needs to be great, at the rules level, but you don't need to fine-tune all the content.

The publisher will play your game once, and if they like it, they'll take it in-house for evaluation. If they run into problems with some piece of content later, that's not a huge problem. They know the game is great.

If they do publish your game, they'll often just do a whole lot of development, that makes all your detailed work obsolete.

Leave the following to the publisher:

• Player counts higher than 2. Just make sure it works.
• Unique player powers / characters / special buildings etc. Just balance these as best you can, while you play, and let the publisher fine-tune them.
• Edge cases, FAQ, and complex interactions.
• Checking for exploits and broken combos.