I know, my last blog was supposed to be my final blog, but now I’m just going to post every time I come up with something interesting to write. I have no idea when the next one will be. Maybe tomorrow. Maybe never. I don’t know.
Most of this blog is about fixing the implementation of a game, but these methods can break down when the game has premise issues. Understanding the nature of the game’s problem can save you many hours of ineffective play testing.
What is the difference? Not everything fits easily into “premise” and “implementation” categories, but once you can see the difference between the extremes, you should at least be able to spot which shade of grey everything is. A loose and vague definition I’ll start you off with before I dive deeper is, “The premise is everything your game wants to be, and the implementation is everything it is.”
Suppose I’m working on a party game that requires 30 to 45 people to play, takes 5 hours to play in which everyone gets to pretend to be a veterinarian that specialises in fish. So there are three features of the game so far. Play time: 5 hours. People required: 30 to 45. Theme: Fish veterinarians.
Each of those features could either be part of the premise or the implementation.
I may have woken up one morning and thought “There is not enough 5 hour fish veterinarian games for 30 to 45 players.” If so, then they are all part of the premise.
I may have spent years working on designing the game and thought “The only way I can get this game to work, is if I require 30 players, let it go for 5 hours, and make all the players be fish veterinarians.” If so, then they are all part of the implementation.
Even though both could result in the exact same game, the difference between the two radically changes the approach to developing it.
If the premise is bad, the game should be destroyed, not fixed. A game built on a bad premise is much like a house built on bad foundation. It can be tempting to build a new foundation and try to lift the house onto it, but it will probably destroy the house in the process. Likewise, a game built on a bad premise was built for that premise. Reworking a game to fit a new premise will be no more successful than reworking a sledge hammer to turn a screw.
Good ideas can still be salvaged. There is a difference between salvaging and fixing. Your destroyed game may have a clever way of interpreting dice, or a new purpose for a classic game piece. Fixing is when you replace a bad feature in a good game. Salvaging is when you keep a good feature, but destroy the bad game it came from.
Testing a premise. If you’ve read the rest of my blog, you should know plenty about testing implementation. I want you to forget all that. None of it works for testing a premise.
To test a premise, simply describe it to someone. If they say something to the effect of, “That sounds like a horrible game,” you have just saved yourself many hours of play testing. That’s probably all the useful advice they could’ve given you. If they say, “I don’t know how you’d get it to work, but I think it could be a lot of fun,” your premise is excellent, for that person. That is, if your game was finished and printed, that one person is a potential customer.
The test of a premise is how many potential customers there are out there. If there aren’t enough, your game will never be a commercial success. If there aren’t anyone beside yourself, you’d better make sure it has a solitaire version, because that’s all you’ll ever see of it.
It’s a matter of fit. In my example earlier, I deliberately invented the worst premise I could think of. Still, you may have 29 friends who regularly meet up with you for five hours and have nothing to do with them. Perhaps they are all members of your weekly fish veterinarian enthusiast club, where they hang pictures on the wall of the world’s greatest fish veterinarians, and they all stare at them longingly, wishing they could be one. If so, they would be ideal play testers for this game.
On the other side, I know I would be a horrible play tester for complex miniatures war games. I know this because I have played and disliked some of the greatest complex miniatures war games in the world. So if the premise of your game is “complex miniatures war game”, you should probably make sure your play testers love the premise before continuing further.
Testing games you don’t fit. As a designer, you should play test other people’s games as often as you can. This helps you a lot in understanding the play testing process, but it also means you’ll have people who are knowledgeable about game design who owe you a favour.
For non-designers, I’d say “never test games you don’t fit”, or you might find yourself doing something silly like complaining that the murder mystery contained a murder, and was too mysterious.
For designers, test games you don’t fit, but be honest and up front. If you asked me to test your complex miniatures war game, I would start by letting you know I’m not personally a fan. They’d need to know that I like my complex games without randomness and my random games without complexity.
Once I began playing the game, I need to pretend I’m a war gamer. War gamers don’t say “this is too random” or “these rules are too detailed”. They say things like, “that’s not what would happen in real life” or “how does this choice reflect the real choices a soldier or commander face?”
Personally, I’m not bothered by these things. I don’t mind playing a game that’s a little divorced from reality so long as the rules are easy to remember. However, playing a war game, I need to pretend I’m a war gamer and pretend those things upset me.
I would still give my true opinions also. I’d say it felt too random for my taste, and the rules were too complex for my taste, but I’d say it knowing it’s my personal taste. I wouldn’t let the designer feel discouraged by such things. I’d recommend they get more opinions on those things before making the game simpler and less random.