About testing, part I
Suddenly doors in my office opens and Ryu runs into. 'Did you see?’
’What?’ I ask.
’New game from Rosenberg is broken!’
’Bullshit.’ I say. Everybody knows Uve has an army of trusted testers and his games are always perfectly balanced.
’No, really! You check BGG!’ he says and goes back to his office.
Uve’s game has a small problem, as players pointed. Other Essen release, Cornish Smuggled has a bigger problem, as players pointed right after few plays. In next few weeks probably more games will have a smaller or bigger problem.
Every year I publish a game, I ask myself that questions. 'Did I tested it enough? Is there a winning strategy I haven’t found? Is there a smart ass somewhere out there who will play my game and find a hole in the rules, exploit it and create winning combo?’
I fear it every single year…
If you listen to interviews with designers who give advices for young authors, most of them, really, most of them say: Test your games. Test them and test them and then test them again.
But not too many of designers tell you how exactly you should test your games. Because, you know, testing is not just playing. It is something much more difficult. If you play your prototype and you think you are actually testing it, you are wrong.
In few short articles I’d like to share my experience about this process. I hope you find it useful.
First of all, I have my testers divided into few very important groups. Depending on the stage of prototype I need different feedback. Some testers are better in one type of feedback, other are better in different feedback.
It took me a while to get to know all those players I have, fellow gamers who wants to spend time playing my prototypes and help me here. I categorized them, I have them in different baskets and I invite people from particular basket depending on what I need at this particular moment.
So my first message – you don’t test with random people. You don’t test with just a bunch of gamers. You pick right people.
Because testing is work.
Because testing is not just playing.
Because you don’t need just players.
You need people to do a work for you.
You need to choose right people to do this work.
My Merry is a silent tester. I’d say it is most important type of tester, but let’s face it – each of those types is as much important, right?
Silent tester just plays. He is like living flower, he just sits, plays, and say nothing.
He doesn’t share his brilliant ideas.
He doesn’t suggest you anything.
He doesn’t comment the gameplay.
He doesn’t ask questions.
And he patiently accepts all changes in the gameplay you introduce in the middle of the game.
You began the game with 1 coin worth 1 VP, in the middle you change it into 2 VP, and later on you decide that coins doesn’t give any VP.
That’s fine. No problem for him. Silent tester just plays. He is fine with everything you came up. He sits and plays.
You need silent player at the beginning. Prototype doesn’t work, and you know that. Everything is a mess, and you know that. Game doesn’t make a sense yet, and you know that.
You don’t need tester to tell you all of that.
You need tester to shut his bloody mouth and just play with you.
It is hard to find silent tester. It is hard to find flexible player who accepts that game changes three times during 30 minutes, and yet he just shut up and plays. Flexible player who can improvise and follow you like a shadow, with patience. With lots of patience.
Yes, I have such a treasure at home.
Lucky bastard, I am.
Being a software tester I can appreciate the silent-tester importance. Sometimes changes occur so quickly that it is best to digest all of them before providing the analysis of what is „broke”.