Testing #1: Game Mechanics
One of the questions I get asked most frequently when I mention that I’ve designed a game is: “Have you tested it?”. Actually, it’s probably the second most popular question, the most popular being: “You what?” But the testing question is a good one, and I want to spend today’s post, and probably a couple of subsequent posts too, talking about it.
Here’s what I wanted to test:
- Is there enough FUN!! in the game?
- Do the game mechanics work?
- Do the puzzles work?
Today I’m thinking about the game mechanics, and whether the game mechanics do the best job they can of meeting Army Of Zero’s design criteria?
We spent a lot of time round the kitchen table, playing various versions of the game with our kids but also with any of their friends and cousins who wandered through our front door.
These playtesting sessions also helped is to streamline the gameplay a lot - a good thing, because we wanted the game to play as quickly as possible.
For example, early versions of the game had a “wound” system. If your character got hit, you’d put a little counter on his card to indicate he was wounded, but he wouldn’t die until/unless he got hit again. I guess the idea was that if you got hit, you had a second chance.
What actually happened in practice was that the player tended to start playing defensively, and consequently the second wound took a while to come. Eventually we realised that if we got rid of the wound system then (a) the game played more than twice as quickly, and (b) we didn’t need to supply the counters.
That idea about having a second chance was bogus anyway: your character could avoid being hit in the first place by being faster than the other character, being better in combat, or by having good armour.
We also quickly realised that we didn’t need as many character stats as we started off with. We began with 5: SPEED, ATTACK, DEFEND, WEAPON and ARMOUR. ATTACK and DEFEND were supposed to indicate how skillful the character was at, well, attacking and defending, but things improved a lot when we replaced the two of them with a single stat called COMBAT.
That change, incidentally, also had a big impact on the puzzles - I’d go so far as to say it made them work - but I can’t say much more about that without giving stuff away!
The only real issue that we had with the balance of the early versions of the game was that we discovered that it was really, really hard for a character with WEAPON -2 to beat a character with ARMOUR 2. In the original rules, the attacker had to beat the defender’s score, so the only way for the attacker to win was to throw a six (total score 6-2 = 4) and hope that the defender threw a 1 (total score 1+2 = 3). The odds of this happening are 1 in 36, and to even earn that 1 in 36 chance you have to beat the other character for speed or combat first.
We tried replacing the six-sided dice with eight-sided and ten-sided, and even tried using different dice for different tests, but we decided it was getting too complicated. In the end we just tweaked the rule to say “if it’s a draw, the attacker wins”: sort of like the offside rule in football, we liked rewarding attacking play.
Now the attacker wins with rolls of 6/1, 6/2 or 5/3, giving odds of 1 in 12, which feels about right for the worst weapon in the game against the best armour.
I’m pleased that we found these problems, because that was the entire purpose of the playtesting. If we’d done the playtesting and decided that the first design was optimal, I think it more likely that there would have been a flaw in the testing process.
I was going to entitle this post “Playtesting #1″, but then I changed it to “Testing #1″, having realised that not all our testing was done through play. Because Army Of Zero is relatively simple, we could actually computerise the gameplay, so that we could simulate many, many thousands of rounds of combat and make sure that there weren’t any nasty hidden circumstances where the rules came unstuck. We could also check the balance of the game and make sure that particular characters weren’t dominating.
Here’s one example of a chart that we produced. This particular chart was used to check whether characters with high SPEED had any innate advantage:
If there had been obvious clusterings (horizontally), it would have meant that some characters were winning too easily. Fortunately, it looks pretty much randomly spread out. We had similar results when we looked at the other characteristics.
So anyway, long post today, phew. In the next couple of posts, I’m going to talk about testing the puzzles, and testing the FUN!!
