The Team
Design might be the most important cog in the machine that creates virtual worlds, but that isn’t to say the other components are unimportant. Some are absolutely critical: If a server crashes, for example, every minute it stays down will be paid for in cancelled accounts. Designers have to know about these things, so they can account for them in their virtual world design.
Designers should have not only a realistic idea of their own place in the system, but also a sound knowledge of the roles of the other people involved in the creation process. Composers don’t have to know how to play every instrument in an orchestra, but it’s essential that they know how all the instruments sound; designers can’t be expected to know how programmers or artists do what they do, but they must be aware of any limitations. If you want every wall of your virtual palace to have a stunning, original fresco on it, you can think again.
To create a virtual world is creating a piece of software. That’s not all it is, of course—it’s creating a community, a service, a place—but these count for little if there isn’t an engine to run the world.
A typical software engineering company is organized along functional lines that cover the following areas:
Company leadership
Sales and marketing
Finance and accounting
Software development, support, and quality assurance (QA)
Operations and information technology (IT)
Human resources (HR)
Some of these may be split into separate sections, for example sales might be distinct from marketing; on the whole, though, the preceding list is fairly uncontentious. Note that normally there is no specific group responsible solely for product specification; the task falls to whoever sources the software, which in many cases could well be the customer.
A typical computer games development company is organized in much the same way, but with some games-specific differences:
An art and animation section is added.
An audio (music, sound effects) section is added (unless outsourced).
QA is expanded, and is formally separated from actual software development.
A (usually small) design group is added; its members will be paid less, but get more fan kudos, than their coworkers.
For developers of massively multiplayer, graphical virtual worlds, the games development model is used except:
The design group is expanded.
The operations group (which maintains and supports the hardware on which the system will run) is expanded.
The support group (which deals with players, both inside and outside the virtual world) is greatly expanded, and is formally separated from actual software development. It will usually reabsorb the QA section.
The company leadership, HR, IT, and finance/accounting people only occasionally bother designers. Designers have a dialogue with sales/marketing that may be in balance or lopsided (“This is the kind of world we want you to design” versus “This is the kind of world we want you to sell” 1).
Designers tell the operations, artwork, and audio experts what needs to be done, but generally leave them to it. Designers interact mostly with:
The programmers (because designers are never specific enough about what they want, except when they’re so enthusiastic that they try to tell the programmers how to program 2).
QA (because testers spot more design flaws than they do programming bugs and operations problems).
Support (because players spot more design flaws than QA people).
Each other (because although this book keeps referring to “the designer” of a virtual world, there’s usually a design team, led by a lead designer).
When work on a new virtual world begins, a core team is assembled. For a small world, this could be a single individual performing multiple tasks; indeed, it might never get any bigger. For a large-scale world, though, it is merely the nucleus about which a full-blown development effort will form. A core team consists of the:
Producer
Lead designer
Lead programmer(s) (server, client)
Lead artist(s) (environment, inhabitants/characters)
There may be two lead programmers because client programming is something best done by people with a background in computer games development, and server programming is best done by people with a background in software engineering. Programming is becoming a progressively more specialized field, and programmers expert in one area may need training to work in another.
There may be two lead artists because of the sheer quantity of artwork involved in a graphical virtual world (albeit not when development first starts). Strictly speaking, the “environment artist” is in charge of the concept art—defining the look of the virtual world. The “characters artist” is in charge of the technical side—interfacing with the programmers. Because this usually comes down to issues of animation, character artists wind up being responsible for characters.
Increasingly, operations and customer service leads are being brought in to the core team, but because their work cannot begin until some time into the development process it’s unusual if this occurs in a start-up company.
Marketing people consider themselves to have expert knowledge of what players like and dislike. They may indeed have this knowledge. The friction comes from when they try to tell designers what features should be added/removed/changed to exploit the virtual world. ↩︎
It’s particularly important that programmers don’t feel that they can ad lib features of their own. ↩︎