The Whole Picture

So as to make it easier to describe, I’ve partitioned the virtual world design process—however, it’s actually holistic. You can’t treat the individual aspects of design in isolation: They impact on one another in ways that may not be immediately obvious.

Example: Crafters complain that their towns are lifeless. You determine that this is because crafting (unlike combat) is a solo activity. You introduce manufacturing processes that entail several characters’ working together. Players build houses in close proximity to one another so they can get to and from the crafting centers quickly. Towns become more vibrant as a result. However, now that people spend more time in the towns than in the wilderness, adventurers complain that the wilderness is lifeless.

If you spot the problems in advance, you can tackle them as a whole. Taking them one at a time may merely push them about. It’s like trying to put out a burning hoop by dousing it a section at a time—as soon as you move from one bit to the next it catches fire again. You have to extinguish it all in one go: You can’t solve the problem by partitioning it. Unfortunately, you’ll always get some partitioning if the design team consists of more than one person; balancing the various issues in this situation is therefore even harder.

Problems due to the interaction of subsystems tend mainly to be of the consistency, compatibility, and depth varieties; these are, fortunately, tractable. Hard decisions have to be made, however, when a design calls for two elements that are in direct opposition to one another: You can have permanent death or some form of resurrection, but you can’t have both. Indirect contradictions can be almost as difficult to resolve while being less easy to spot. Players want to be able to sell the goods they manufacture at fixed prices to guarantee an income, but that will cause lots of people to manufacture those goods, which will raise the price of raw materials, which will reduce the income players get from their goods.

Solutions are hard to come by. The difficulties that arise by partitioning can be addressed by sound development practices—communication, regular design meetings, internal web sites, lead designer sign-off, and so on. For problems with the design itself, the team must strive for robustness: They can tackle whatever they notice beforehand, but once the virtual world goes live they have to rely on the checks and balances they build in to ensure that nothing goes horribly wrong ¹. Any new design for the economy in particular is almost certain not to work straight away, so damage-limitation code will have to be in place ready for the inevitable tribulations.

Under- and Over-Design

Under-design is a frequent problem with virtual worlds that have been written from scratch. Developers spend so long creating and building the world that they forget to add any gameplay. There’s not a lot for players to do, but lots of things for them not to do it to. Alternatively, there is a lot to do but only to the same things, over and over again. Either way, there simply isn’t enough. The virtual world may be immense, beautiful, and finely crafted, but just a shell. What players want, there’s no way they can have: It’s like going on a shopping expedition and finding that all the shops are closed ¹.

Over-design is also a problem. In this scenario, designers go into such detail that it overwhelms all activity. What players want to do is lost in the noise of what they have to do to facilitate doing it. There is a place in virtual worlds for a modicum of annoying detail, and some players will find particular details more irritating than do others; when they feel it’s irrelevant, though, they’ll rebel. I don’t want to have to specify the barb style, shaft length, and flight composition/configuration of the arrows that I buy, I just want something I can shoot in my bow!

Both over-design and under-design are the result of the same thing: misdirected focus. The designers look at something in too much detail: For under-design, it’s the infrastructure of the virtual world; for over-design it’s the structure built on this foundation.

They both illustrate another aspect of selective depth: Too much detail in one place gives an impression of shallowness elsewhere—even if looked at objectively the detail elsewhere is just right.

Participatory Design

When a bunch of musicians get together and start jamming, they’re engaging in a form of participatory design. Everyone has ideas, which they offer up for approval to everyone else. Some ideas work, some don’t work, and others suggest better ideas. Computer programmers hacking together work the same way: Someone types, other people make suggestions, changes are made in the light of these suggestions, new suggestions are made. It’s an editing process undertaken (ideally) by members of a spiritual community ¹.

Participatory design is good because everyone gets involved, everyone can contribute, and everyone’s contribution is acknowledged. It helps build a sense of community, and gives all participants an investment in the final product. It’s ideal for virtual worlds, then?

At the design team level, yes. Final approval must formally be made by one (lead) designer, but this is essentially a rubber-stamping of the consensus opinion ². Brainstorming works.

Extending participatory design beyond the design team, however, is another matter entirely. Designers have always been open to ideas from players once their virtual world has entered beta testing, but what about before then? It can be very difficult to manage; in particular, inviting prospective players of a virtual world to participate in design increases the number of contributors by several orders of magnitude. The design team itself can either act in concert as a single unit, or split along individual lines. It’ll usually be the former, because otherwise players will try to play off designers against one another. However, that’s not the only reason they may do it. I’ll explain….

Why would designers want to get players involved in design? There are several laudable grounds for doing so:

• It allows players to feel they have an investment in the virtual world.

• Ten thousand minds are better than ten.

• Designers can act as culture seeds.

• Players feel influential—they really can make a difference.

• If players understand the design process more, they won’t make knee-jerk objections to things that superficially annoy them.

• It draws players into a community. There also are some less laudable reasons:

• Players can be manipulated into accepting suggestions that they may otherwise have found unpalatable.

• Designers can accept “new” suggestions they had already thought of, tricking players into thinking they’re participating when they’re not.

• Designers get to pick the choicest fruits of players’ unpaid endeavors.

The cynical view (and players can be very cynical) is that the whole effort is primarily a public relations exercise. Nothing important is ever discussed, unless it’s to get players to suggest a preferred solution in order that criticism will be deflected when it proves unpopular once implemented. After all, although some players’ ideas will be excellent, most will be unusable (jaded, inconsistent, off-the-wall, dull, unimplementable, copyright someone else, and so on); it’s a simple matter when posting a question to wait for the “correct” response to appear and then seize on it as a great, original idea. Players participating in design are at best sounding boards and at worst betrayers of the players yet to come. In this context, it’s easier for designers to stage-manage participatory design if they work as a unit than if they don’t.

This scornful view of participatory design has, fortunately, yet to gain a strong hold of the player population. Participatory design does work, and can bring substantial benefits. It will be used extensively for Star Wars Galaxies, where it will probably work well. On one great test—players’ coming to understand that newbies can’t be allowed to start with a Jedi character—its advantages are particularly clear ³.

Its long-term future is cloudier, however. As with player content creation, there are legal issues concerning the “rights” to aspects of a design. If a scriptwriter pitched a movie concept to a director, they would be calling in the lawyers were that concept to appear as a movie five years later without even a credit (let alone payment) ⁴. Why should a player of a virtual world who pitches a design concept receive no recognition (professional or monetary) when it’s used?

The response that it’s “advice freely given” only goes so far. It may, for example, be material that already exists in some other virtual world to which the designers of that world hold copyright. Besides, even though the assumption that the inclusion of your idea in a design is reward enough holds sway at the moment, this will not necessarily always be the case. Were a new, high-profile virtual world to pay for any player-suggested ideas it used, the situation could well change. Under such circumstances, full participatory design could be hard to apply effectively.

Testing a Design

Large-scale virtual worlds are designed before they are implemented ¹. After implementation, play-testing can be used to pick up the many design bugs (as well as programming bugs) that will have crept in. However, fixing them at this stage is expensive as it involves code changes (potentially quite large ones). The more flaws in a design that can be fixed before implementation, the better.

How, though, do you test a design when there’s no world to test it in?

Some facets can be tested by writing quick-and-dirty programs or macros. An economy becomes a spreadsheet; combat becomes a few screens of C. This helps get the numbers right, but doesn’t say anything about the gameplay. You could end up with a well-balanced virtual world that is an absolute chore to play.

Surprising progress can be made by simulating the virtual world, tabletop style. You draw out a rough map of an area, put some tokens on it to represent PCs and monsters, then move them around and do things like you might expect the finished product to work. This does, however, require a discipline that is beyond most designers; although you should really take notes and discuss what happened after the session, most designers are unable to prevent themselves from launching into a debate the instant the first opportunity arises; the result is that such pencil-and-paper simulations are not usually as productive as they might be.

Two things I normally recommend to design teams on new virtual worlds address these problems: dummy logs and mock diaries. Both start from the premise of imagining that it’s some time in the future when the virtual world has been implemented and people are actually playing it. What will those players be doing?

Dummy logs work better for textual worlds than graphical ones. The idea is to write an imaginary transcript of a session as it might be recorded by a stereotypical player. It forces the designer to face up to concrete consequences of their decisions: the interface, room descriptions, movement, communication, the general atmosphere, and (crucially) what the player will be doing. This exercise will typically expose the greatest strengths and weaknesses of a design: The designers can then play up to the strengths and root out the weaknesses.

For graphical worlds, dummy logs are more like dummy storyboards, and they don’t work so well ². That said, there is still a lot of mileage in asking the enthusiastic, wannabe designers of new virtual worlds what they think their players will actually be doing once the doors are open.

Mock diaries ³ are like dummy logs, but they address longer-term issues. The idea is that you write a series of pretend diary entries for a player covering several imaginary sessions, outlining how the player’s character(s) got on and what they did. If the entries often lack excitement or fun, or they start to look the same, you may have discovered a potential problem.

Dummy logs and mock diaries can be constructed for a variety of player demographics at different stages in their career. Your first session will be different to your sessions after a week (or it should be!), which in turn will be different to your sessions after a month, six months, two years, and so on. By writing dummy logs or mock diaries for these periods, you can reassure yourself that there will be sufficient gameplay to sustain long-term play, and that this applies to all the main player groups you’re targeting.

Dummy logs and mock diaries have their variations. Jessica Mulligan recommends using mock letters rather than diaries, for example; these help the designer consider why things are fun, instead of merely assuming that they are fun.

Whatever, designs must be tested. In the same way that every time a programmer finishes a new section of code they test it, so a designer should consider the effects of every new addition to the virtual world. You don’t have to write out 20 new mock diary entries every time, I hasten to add, but you should at least consider whether it will work in the context of the rest of the design. Although occasionally you really do have to say, “Oh, let’s just put it in and see how it goes,” most of the time you don’t. Think what the players, good and bad, will make of it, and you’ll have your answer. If an idea is so original that you can’t do this, okay, then you can put it into the design document and hope—but be sure that if it does fail there’s nothing important relying on its working.