Many computer games are adaptations of a real-world gaming experience. Role-playing games, board games, card games, war games: all of these have made the leap from paper to computer, often many times over. But just as a good translation of a work of fiction or poetry is no small task, a good adaptation of the real-world game ain’t trivial. Far from it.
A sneaky problem is one we can call the “Black Box Problem”. Here’s the gist of it: Sometimes, when you take a game mechanic from a real-world game, and move it to the computer, the computer handles the mechanic for you. This turns up a lot in role-playing games, where the computer typically takes on the role of game master – but it’s far from restricted to the RPG world. And once you start hiding those mechanics, players run into problems.
To take a non-RPG example: The hit Magic trading card game came out in an online version many years after the original game was produced. Despite a frustrating interface and problems with outages, the service flourished. So what’s the most common complaint you hear in the Magic chat rooms? ”The shuffler cheats!” Here’s the problem: in Magic, you get a random hand of cards each time you sit down to play a game. Sometimes, that hand lacks a critical resource (“land” cards), or contains too many of them. You are at a major disadvantage with a hand like this. Get too many such hands in a row, and you get frustrated. In real life, there’s nobody to blame: you shuffled your own cards, you felt and saw it happen, and know that a bad hand was just unfortunate luck (or possibly not enough shuffling on your part). But online, the shuffling happens for you. And so if you see that streak of bad hands, your human pattern-matching mind can quickly go that place of deciding that Something Is Wrong… what is it? That black box shuffler!
RPGs are much more prone to this problem because the computer has more responsibility for managing the game experience and mechanics. This is particularly true if the RPG uses virtual “die-rolling” to decide whether players and their foes are succeeding or failing at their actions, from attacking to dealing damage to using skills. If the interface hides the die-rolling, and a player sees too many failures or successes in a row, he or she can easily end up drawing the wrong conclusions about why those failures or successes are happening.
Another common – and related – Black Box Problem in RPGs is hiding what factors are influencing conflict resolution. Does flanking my foe help with my attacks on him? What about being hidden? Am I a worse shot when firing at range? In melee? Does the rain help my stealth? Hurt my climbing? Which of my foes is better protected against my attacks? How do I know and learn this stuff? Paper RPGs have lots of ways to convey the answers: a rulebook (and one which players actually read), verbal descriptions of monsters and situations, being able to count on a good gamemaster to take the situation into account in the same way you do… and the chance to ask the gamemaster what will happen. All of these things are harder with a computer, and some impossible.
How you solve this problem in your computer RPG is up to you. Some games get very “open kimono”, showing % chances to hit, specific die rolls, and so on. That’s a fine approach, if your game is more about tactics than roleplaying, and if you are okay with not having the ability to hide much from players. But numbers tend to detract from the roleplaying experience for players, so consider using them with discretion. A description, like “excellent” or “difficult” can convey critical information without damaging verisimilitude. And sometimes you do want to hide information; sometimes, you have good reason to do so. The important thing is to be aware of the tradeoffs you are making between giving players the feedback they need to learn and play your game well – meaning that they feel mastery of their experience – and using hidden information to create dramatic surprises and suspense.
Even the “open kimono” strategy (where’d that metaphor come from, anyway?) falls prey to the black box problem. This is because we pattern-finding humans are really bad at judging the actual probability of sequences of random numbers. For example, flipping a coin and getting HTTTHTHHTT is just as improbable as getting HHTTTTTTHH (or HHHHHHHHHH, for that matter), but the latter *seems* more improbable.
When game designers make visible the results of their random number generators, players usually consider the more mixed streams of results to be “random”, while the (just as probable) runs of extremes will seem “unfair”. When these results disadvantage the player, they may blame the game itself, much in the same way that they would blame a run of bad luck on a particular die in a tabletop RPG. Unfortunately for the designers, blaming the game can take the form of resentment against it and an unwillingness to play it. Most gamers are aware of the preposterousness of blaming the die, which usually takes the form of just chucking it across the room and picking a new one. 🙂
I’ve read somewhere — sadly, I can’t track down exactly where — that for this reason, some game designers sing the praises of quasi-random number generators, which are less likely to produce these strings of extremes. An alternative is to use larger and atypical ranges, since the “low bits” don’t impact the results much but make us less likely to notice patterns. For example, for an event with a probability of 0.5 using a range of 1 to 84, the sequence 64, 71, 38, 19, 27, 32, 9, 41, 75, 52 is equivalent to HHTTTTTTHH, but it’s harder to notice the pattern.
Another strategy is the one employed by a Settlers of Catan expansion, where they reacted to player frustration with uneven die roll distribution by coming out with a deck of 36 cards, containing all the possible die rolls in the game – thus guaranteeing a perfect distribution of production roll results over 36 turns. After seeing your post, I did a quick search on “quasi-random game”, and found mention of a similar option for GNU Backgammon. It seems fair to say that not only is quasi-randomness an option for computer RPGs, but that there are options to consider for quasi-randomness!