topnav

Series Info...Building Stories, Telling Games #41:

Don't Look Too Closely, Part 2

by Travis S. Casey
August 31, 2002

In the last column, I started talking about how games are built on illusion, and about things that can break that illusion and ways you can use the fact that it's all an illusion to help you. This time, I'm continuing with that.

Castles vs. Pegasi

The vast majority of RPGs, whether they're online or not, aren't set in the "real world". That is, they involve elements that simply don't exist in the real world — dragons, elves, fireball-throwing magic, starships, powered armor, etc. Since these things don't exist in the real world, we can't know for sure how things would change if we introduced them.

Things that don't work in the real world do work in our fantasy worlds (using "fantasy" in the broad sense here — i.e., worlds of our imagining); and conversely, things that do work in the real world may not work in our fantasy worlds. The classical example is castles in a D&D-style setting — the medieval European-style castle isn't nearly the effective defense it was in the real world in a world which has flight spells, pegasi, dragons, and so on.

The "realistic" thing to do would be to either make castle-breaking things very hard to find, or to replace the castles with something that can resist those sorts of intrusions — e.g., underground bunkers. The first option makes the game world more like the real world (or at least, the real world at some point in history). That's generally not desired. The second option makes the game world less like the real world, but it also often makes the game world less like the literary worlds that players are familiar with (and that many of those players may want the game world to resemble).

This doesn't just turn up in fantasy worlds either; science fiction games have similar problems. Take Star Trek , for example. Humans in Star Trek are surrounded by races that have large physical and/or mental advantages — klingons, vulcans, romulans, etc. Why haven't humans genetically engineered themselves to overcome the disadvantage they're operating under?

Well, the real reasons are that having a disadvantage helps make for better stories (the more of an advantage the opposition has, the harder it is to overcome), makes the characters more sympathetic (most people like to root for the underdog, and it's easier to identify with "normal people" than with a bunch of genetically-engineered superbeings), and that we don't have genetically enhanced humans around to play parts on the show (that old budget problem).

So what can be done? Well, the general solution is to pay lip service to solving the problem in some way and then... well, "don't look too closely", as the title of the column says. There's several ways to do that:

Cultural restriction . This is the solution Star Trek uses for why humans aren't genetically enhanced. In Star Trek history, genetic engineering in the late 20th century led to the creation of genetically-enhanced humans — who proceeded to try to take over the world, triggering a series of wars. Since then, genetic enhancement of humans has been banned on Earth, a ban which was carried over into the Federation.

This method has a weakness — cultural restrictions aren't natural laws. The fact that genetic engineering is banned doesn't mean that no one will do it. This weakness, however, can be turned into a strength by making it a plot point — in the Star Trek: Deep Space Nine series, it was revealed that the character of Dr. Bashir had been genetically enhanced. In a game, player characters could be assigned the task of seeking out people violating such restrictions... or there could be an NPC group doing so.

Partial fixing . Here, one fixes the problem part-way, then relies on people not looking too closely to fix it the rest of the way. For example, going back to the idea of castles and pegasi, stating that pegasi do not breed in captivity would be a partial fix, preventing someone from starting their own herd of tame pegasi to mount troops on. In some cases, multiple partial fixes might be necessary.

Use control over non-player characters . Non-player characters are completely under the control of the people running the game. Because of this, one can easily say, "X is possible, but no one's ever done it before." The drawback here is that it's easy to strain suspension of disbelief this way — especially is what it takes to do X is easily available. It's much easier to believe is X is difficult and/or expensive to accomplish.

It should be noted as well that the old adage, "what's good for the goose is good for the gander" applies here. If something gives a sizeable advantage and is easy and cheap, not allowing NPCs to ever do it can give players a strong advantage in dealing with NPCs. Further, even if no one's done it before, once someone else (i.e., one of the player characters) starts doing it, if others don't start as well, that can severely strain suspension of disbelief.

Let's have an example. Long, long ago, I helped set up SWmud — a Star Wars-themed text mud. One of the things that we strongly wanted to have was ranged weapons. It just didn't feel right to us for blasters and similar weapons to not be able to attack someone unless they were in the same "room" with you.

The system that was worked out was one where the player indicated in their firing command both the direction to fire in and the name of the target — e.g., "fire north at guard". That was easy to add. The problem, however, was making NPCs react to being fired upon from a distance. The first fix was to make NPCs who had ranged weapons shoot back when fired upon. This was done by creating a table of directions and their opposites, so that when a player did "fire north at guard", the guard could be commanded to "fire south at <player>". There were a couple of problems in this — first, NPCs didn't check range, so that if the player had a longer-range weapon, the guard would shoot back, but would never hit. Second, if a builder created a room with non-standard exits, the "reverse the direction" code wouldn't work — what's the reverse of "door" or "hatchway"?

The second fix was to create code that made it possible for area builders to create snipers. An NPC with a ranged weapon could be set up to fire at anyone who entered a particular area, and criteria could be applied — e.g., an Imperial soldier could be set not to fire on those with Imperial affiliation. This lacked flexibility, though — there was no easy way, for example, to make a guard "see" and fire when appropriate in all directions, and the system didn't work for moving NPCs.

Even with those problems, though, it still felt better to us than not having ranged weapons at all, or than not having NPCs use ranged weapons. This, then, was a case of having two partial fixes and relying on people not looking too closely.

To Be Continued

Well... those of you who read the last column know that I intended to have the topics "But It's Magic!" and "Getting There Isn't Half the Fun" in this article, but I'm afraid that "Castles vs. Pegasi" stretched to be much longer than I anticipated. So join me next time for the third and final part of the "Don't Look Too Closely" mini-series!

Recent Discussions on Building Stories, Telling Games:

jump new