Champions Online: Beyond the Wall

The Champions Online site has been updated with Part Two of a series of articles about getting in on the development business. Part One dealt with getting into the business and Part Two deals with what to do once one arrives:

Standing outside the industry, awareness of what designers actually do can be spotty. The reality is that the role, authority, process and areas of responsibility may vary drastically depending on the company and the design department under consideration, and even within the same department.

Titles do not consistently match up with any of these between different companies; so instead, let's look at this from the point of view of the design process.

The Vision

It all starts with the vision. What kind of game is this? MMORPG? Action? RTS? FPS? What makes the game different? Customization? Speed? Some new twist on gameplay? Why will anyone want to buy this game instead of any other game in the same genre?

Once the kind of game is determined, the next step is identifying the principles. Let's say we've decided to make an MMORPG. We might then decide that one of our principles includes, for example, that we want crafting to be fundamental to gameplay.

What the vision does not include is how these things will work. The principles are about what is the focus of the game, what are the priorities, what is the expected normative gameplay going to look like. Every priority and every principle will heavily inform the final game design. While it is easy to say, "We'll do everything!" the reality is that no game can, and games that try to please everyone will wind up pleasing no one.

Possible principles for an MMORPG might include:
1. It should be possible to get from level 1 to maximum level without having to group.
2. Loot and items should be very important to characters.
3. It should not be possible for a player to make irreversible choices that prevent their character from soloing normal content.

Here is where understanding the difference between principles and the actual design is critical. Principles are an issue of preference. Design is an issue of plan of execution. If I favor a principle that says, "Loot should be important to characters," and my co-worker wants a principle that says, "Loot should not be necessary for normative gameplay for characters," neither one is "right"; rather they are an issue of preference.

Clearly, the principles that are determined for a game will have enormous repercussions on the design, the potential market, the demographics of the playerbase and the technology. The principles chosen for a project can literally reshape the nature of an entire project, and are as much business decisions as creative decisions.

Not surprisingly, given this, a project's foundational principles are almost always decided either - implicitly or explicitly - at a very high level. If the company has a chief creative officer or similar position, this is that individual's primary obsession. Company directors will frequently be brought into such determinations, as will Executive Producers.

The Design

Depending on the company, the core design may start with brainstorming, or with a design proposal written by one or more individual designers. The design will usually be subjected to review, critique and yet more brainstorming. Whiteboards will be abused, printers will be exhausted of their ink, and designers will talk themselves hoarse.

Some companies make an effort to bring people outside of a design department into this part of the process, especially in regards to brainstorming, but not all include people from outside - even within the design department, not everyone may be involved. Focus groups or strike teams to brainstorm particular features are not uncommon.

The design documentation that emerges out of this process will undergo strict scrutiny from not just design, but also software/engineering for technical issues, art for technical art issues or user interface concerns and production for scheduling implications.

So who writes the design documentation, anyways?

Depending on the size of the project, the lead designer may write some - or even all - of these design documents. There may also be one or more senior designers with a proven track record and titles under their belt who are responsible for putting documents together.

Some of the more peripheral design documents may be the first big chance for an up-and-coming designer to show what they are capable of. Speed at writing a good design document is important, but so is accuracy and creativity. Usually even more important, however, is practicality - does the design work within the current engine, if there is one? Does it leverage existing tech that is already planned? Is the time investment to execute on the proposed system reasonable and in line with the importance of the feature or system? Such opportunities are by no means assured, however, and rarely are offered twice if the first opportunity is squandered.

The Implementation

Thomas Edison pronounced genius to be "ten percent inspiration and ninety percent perspiration," and nowhere is this as true as it is in the discipline of game design.

Once the vision and design documents are hammered out and ready, next comes the implementation phase. Depending on the company, there will sometimes be a second set of documentation for each feature separate from the design documents specific to the implementation. Where the design docs will usually describe, for example, what things go into a level or mob, the implementation docs will describe and detail every level and every mob, following the design documentation as a template.

Most project design groups are split up into individual teams led by functional leads. The names and divisions here can vary dramatically from company to company, but generally things are broken up broadly into content (level design, mission design) and systems (mobs, abilities, player skills, reward systems, other systems). Within the broad categories of content and systems, there frequently are additional sub-divisions depending on the size and scope of the project as much as anything.

Individual designers are then usually tasked with the implementation of specific elements of the game - this level, that instance, this mob, that class, and so on. As issues come up in implementation (and they always do) the designer then works with art, software, QA or whomever else to figure out appropriate solutions.

The Iteration

Once initial implementation is done, and then comes review, playtesting, iteration - then rinse and repeat. At some companies, iteration can take up a huge amount of time, at others the emphasis is on putting in more time upfront. Both approaches have their benefits and disadvantages.

The main thing here is polish. Does it match the principles and design? Is it fun? If we tweak this, what happens? Is this better? Is there any way we can improve the way that mob reacts or its preferred ordering of abilities? What about the level flow? Is that intuitive for new players? How difficult is it?

This really is the final component of design - asking questions, figuring out creative solutions within constraints, polish, polish, polish, and then, hopefully, you ship!

Really, for those looking to get into the "biz", this series of articles is a terrific jump start.