# Testing a Design

LLMS index: [llms.txt](/dvw/en/llms.txt)

---

Large-scale virtual worlds are designed before they are implemented [^134]. 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 [^135]. 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 [^136] 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.


[^134]: Small-scale ones are usually designed while they’re being implemented, which is a much more organic way of doing it. This can mean the overall systems are better balanced and more stable, but it also can cause numerous rewrites as the consequences of early bad decisions finally make their appearance.
[^135]: They can look better in a design document, though, if your aim is to impress publishers into giving you their money.
[^136]: These are also known as user stories.