Extensibility
Virtual worlds are designed such that they can be extended over time.
Why? To add content, to correct imbalances, to allow for more simultaneous players—there are lots of reasons.
Who extends the world? The live team.
Who created the world? The dev team.
Is the dev team a subset of the live team? At some point, the answer has to be “no.”
For large-scale, graphical virtual worlds, the answer is usually “no” immediately, because the live team is a separate entity from the dev team. Even for small-scale worlds, or those for which the live team is built from the dev team, the original designers aren’t going to be around indefinitely. Students who create virtual worlds eventually leave college; professional designers who create successful worlds are offered new opportunities 1; people move, their circumstances change: Ultimately, no one lives forever.
The live team may therefore differ in attitude to the dev team 2 when it comes to assessing how the virtual world “should” work. There are many opportunities for divergence:
The live team may fail to understand aspects of the design, seeing flaws where there are none.
The live team may misunderstand the dev team’s intentions, believing they’re doing the right thing when they’re not.
The live team may have a different overall philosophy, and “correct” the design where it runs counter to this.
The dev team’s design might fail when exposed to real players.
The dev team may have higher quality staff than the live team (or vice versa), with a consequently better handle on things.
Because the live team is in control, there is great scope for a virtual world to shift away from the designers’ original vision over time. This isn’t necessarily a bad thing—adapting to circumstances is how systems evolve, after all. Neither, though, is it necessarily a good thing—survival of the fittest is great when you’re one of the fittest, but not so great otherwise.
At this level, it’s a classic conflict between theory (what the dev team wants) and practice (what the live team gets). It’s a little more complicated than that, though. The live team has to deal with players, every single one of whom believes they know just as much about virtual world design (if not more) than anyone in the live team—and are prepared to argue the point.
The bad news is that players know nothing about virtual world design. Nothing whatsoever.
Well, that’s not strictly true. A very small fraction of them do 3, but these are generally indistinguishable from normal players except in the benighted eyes of people who actually do know about virtual world design. Message boards are full of erudite arguments by players able to put their opinions cogently, politely, and convincingly. That doesn’t mean they’re right, though. It’s like listening to a religious discussion between people of a religion different to your own: They obviously know exactly what they’re talking about, in great and profound detail, but from your point of view they’re at least misinformed and at most completely misguided. Player discussions are frequently like that: Designers can recognize some truths in what is being said, but these are so mixed with dogma, rhetoric, and downright falsehoods that the conclusions they reach are often bizarre and irrelevant (whenever they reach conclusions at all, that is).
Yes, I realize I’ve just insulted about three million people, here.
It’s not that most players don’t know about virtual world design, but that their knowledge is too personal. As mentioned in Chapter 1, players tend to view all virtual worlds in the context of the one they “grew up” playing. If a new idea is suggested, many players will immediately consider how it would fit into their preferred virtual world, whether or not the virtual world for which it is intended is remotely similar. If the debate actually concerns “their” virtual world, they’ll figure out the short-term repercussions of their own playing style and use that as a basis to decide whether they’re for or against. They’ll only refer to long-term effects or other playing styles when they’re trying to win allies or to convince the live team that they are responsible people whose opinions should carry weight.
This is because actually playing a virtual world adds a subjective element to all discussion. Designers have to be objective. If you can play a virtual world for fun, it’s very hard to be a designer; every decision you make is related to your own experiences as a player. Designers can’t play virtual worlds for fun. When I enter a virtual world, all I see is the machinery, the forces at work, the interactions—it’s intellectually interesting and can be artistically exciting, but it isn’t fun. Other designers are the same: The price you pay for being able to deconstruct a virtual world is that of being unable not to deconstruct it. Magic isn’t magic when you know how the trick is done.
That’s why most players aren’t good at design. They still sense the magic.
Unfortunately for the live team, that’s not quite how the players themselves see it. Players want improvements made to their virtual world, and most of the time they are appreciative—even fanatical—of the live team’s efforts. When they aren’t, though, oh boy, do they ever let the live team know! The pressure can be phenomenal. It can reach the stage where it’s more gainful to implement the change that everyone is screaming for than it is to answer all the emails they’d send if you continued to hold out.
At this point, the live team often surrenders. Top-down design gives way to bottom-up experiment.
Whether this fills the original dev team with pride or despair depends on the extent to which they’d planned for its occurrence.
It’s quite a different story for professional designers who create unsuccessful worlds, but the effect is the same: They end up not working on the project. ↩︎
Indeed, they may differ in attitude to the live team of a few months earlier. ↩︎
Hopefully, a fraction that will increase as more and more players read this book. ↩︎