Wednesday, December 03, 2003

Designers Without Rules?

Why do videogame design documents have rules?

A quick analogy-history: Did you know that the screenplay as it exists today did not in fact start life that way? In the early era of film, screenplays used to be inordinately technical documents, filled with notations for camera placements, technical requirements and so on. Over time, this sort of detail proved to be unsatisfactory, and the screenplay gradually whittled down step by step, with screenwriters themselves developing an ever-clearer idea of what a screenplay was.

Screenplays, nowadays, contain almost no technical notation at all. The only information that they contain are the things that the audience actually sees on screen. You do not put technical information in a screenplay. You do not put descriptions of character thoughts and emotions in a screenplay either. What a screenwriter does is to write a 90-page piece that portrays the story of the film and how the audience will see it. And it's a very successful format for doing that. The only technical notation permitted in the modern screenplay are directions that will explicitly affect what the audience sees. (Things like scene changes, text inserts, intercuts and so on).

The reason that the screenplay has evolved to such a point is simple: All that extra technical detail seemed so very important, but in actual fact turned out to cause more trouble that it was worth because it's very hard to visualise that level of technical detail, very hard to make it consistent, and is guaranteed to make the people actually doing the directing and shooting feel like they have no contribution at all. The modern screenplay is inclusive because it recognises the golden rule of group efforts: That the written word shows the direction, but the actual process of directing a production requires a whole other brand of creativity. Screenwriters show the path. The production walks the path.

Meanwhile, in the much younger field of videogame design, the document process is bizarre beyond belief. Game design documents are truly mammoth affairs, filled with all manner of arcane detail. They have business information, executive summaries, game mechanics and rules, control schemes, universal selling points, AI, characters, plot, progression, game structure, audience appeal, front end, dialogue, on and on and on.

Now, an honest question to all the coders, artists, animators, audio technicians, QA people, marketeers, producers and executive producers out there: How much of this design doc shit do you actually read? And how much of it do you remember? The answer is bugger all. The reason that game design documents are not read and barely understood is that they are boring, disorganised, replete with redundant detail, insulting, poorly written, badly edited, and so on.

What many game design documents fail to do is actually describe what a game is to play. Like the early screenplay, the current design documents are overrun with production concerns, because designers have not yet learned the golden rule. A screenplay contains no detail other than that which the audience sees and hears. A videogame design document should contain no detail other than that which the audience sees, hears, and with which they directly interact.

The whole point of a design document in any field of any kind is that it shows the way. It shows what the end product you are trying to design actually is. It is not a document that tells the people involved in the various professions of the industry how to do their jobs. They already know how to do their jobs, much as the cameramen already know how to place a camera, and don't need to have it spoonfed to them.

Fashion designers do not write long and complicated documents about how to stitch their designs together because their costumers already know how to do this. What the costumers don't have is the end goal, which the designer provides. Screenwriters (film designers, as it were) don't include directions to lighting and sound people in their scripts any more because the lighting and sound people know how to do this much better than they do, and can bring the intent of the screenplay out much better than the screenwriter can. Web designers usually design a look for a site in photoshop, and then put it together technically afterward, for similar reasons.

Good design of any kind is detailed, clear, consistent and non-technical. It is ideas as they will appear in the final form of the proposed product. Design can be visual, auditory, textual, even a combination of those three. Design and designers are all about communication. They have the ideas and they communicate the vision. With game design, there is rarely any sort of clear communication chiefly because the vision gets muddled between designing an end product and designing the way that it works. Why?

One possible answer is cultural. As I wrote previously, the ancestors of videogames are other games, especially boardgames and other formal games. In those elder game formats, the rules for the games can be quite technical. Some of the more convoluted 18XX train games, for example, have a whole variety of rules. Movement rules, combat rules and so on form the bulk of many roleplaying games as well, because they are necessary to know to play the games. Yet in many videogames, the rules of the game are invisible to the player, a part of code design and playtest tweaking instead of game design.

It is therefore naturally instinctive on the part of a videogame designer from these traditional game roots to follow the paths laid down by these older forms. But, as I talked about in my previous post, videogames are not boardgames. In boardgames and roleplaying games, those rules are all shown because that is part of the player's need to know. In videogames like Halo, there is no need for a player to know how fast in meters per second he can run. All he can see and feel is that he runs fast and slow. Therefore the design document should only include that information. How fast and how slow is irrelevant detail that no-one will follow during production.

Technician versus Artist
Perhaps part of the answer lies with how designers see themselves and how the rest of the production team sees the designers. Designers should occupy a role of ideas men, consistency police, directors and editors. (Actually this lumping of all these duties under one job is the subject of a future blog, but for the moment, we'll let it stand). This is basically a role for someone with artistic flair and sense, communicative English (or Japanese etc) and the ability to develop concepts.

Yet many designers seem to think of themselves as adjuncts of technical staff. Studios confuse "designers as idea architects" with "designers as gameplay implementers", which is a much more technical role. Many designers try to design code, AI, rules systems and so on, and think that is what a game design is. This couldn't be further from the truth. Firstly, most coders are much better at inventing AI systems and so forth by actually writing and compiling and testing code than someone in a room writing down a whole load of notions for how it should work on paper. Secondly, it ignores the basic function of design, which is the guiding vision above all else.

Communication Skills
Part of the problem is definitely a lack of training in basic language skills. Some designers can write well, many can write passably. Many have the problem of being overly-referential or technical when trying to describe something, however, and most do not really have strong layout or editing skills. This is because they do not receive the training to be good writers. Writing is among the most important skills that a designer can possess, and so is editing. It is very easy to over-egg a document so that it just drags down. Design documents should not be a chore to read. If they are, then how can we expect the people working on the project to be interested in it if the documentation makes it sound like the dullest thing ever?

Some designers can draw, others cannot. Visual aids are very important in any game design, because it is all on screen. In film, they use storyboards because many screenwriters cannot draw. In game design, if the designer can draw, then that is a valuable addition to communication. If he cannot, then he should work with a concept artist who can.

Either way, there are strong communication problems at most studios that stem from non-communicative designers.

Another equally valid reason is paranoia. With the usefulness of designers always being in question, they might naturally reach for the high ground (see Innovative Gameplay below) and in so doing try to impress everyone with their expertise. So a designer will pore over and produce a weighty tome of a design document that is intended to show everyone that they know what they are talking about. Publishers bow in fear, producers balk at reading it, artists assume that they must know their stuff and coders grumble in the corner. This sort of paranoia comes from not having any power.

Designers do not have the power in most development environments. Producers have management power. Coders have technical power. Artists have visual power. But designers have no power. This is because the production houses of today don't understand that they really need people in directorial positions, not just producers. As a result of not having the power, designers don't trust that anyone will really see through their vision unless they specify in excruciating detail exactly how everything works. In actual fact, the game will most likely go in wildly different directions than they intend anyway, perhaps more so as their document grows ever-more-lengthy.

Lastly, a strong reason, also related to powerlessness is fear. If you look at a design document, you will often see business information nestled in its pages. Often the front pages, in fact. This comes from believing that the design document is about giving everyone what they want. So, the theory goes, a producer can read his part of the design, and get what he wants. A marketing guy can read his part of the doc, and get what he wants. A coder can read his part of the doc and get what he wants. And so on. WRONG.

What actually happens is that everyone reads their part and assumes that the person who wrote it doesn't know what they're talking about. They know their field better than a designer does. They then don't understand how their part is supposed to relate to any other part, make up their own version of what they think the executive producers will like, and the result is a stinking mess. Design documents in any field are not supposed to be all things to all men. They are the DESIGN.

Studios have a habit of treating them like they are the Big Document of Everything. Do you see business information, technical descriptions, selling points, directorial notes and all the rest of it in a screenplay? No. But why? All those things are important to a film. They are, but they are not part of a film design document (a screenplay). The film design document details the DESIGN of the film. All that other information about business and technical details belongs elsewhere.

So what is needed is a serious rethink of the basis of a design document. Quoting screenplay analogies is useful, but we should not make the mistake of replicating the screenplay. There is a whole extra dimension involved in a game design stemming from the fact that the player can actually interact with the videogame, as well as just watching and listening to it. In rethinking the format, we should focus on trimming out the noise and allowing people from other parts of the industry the freedom to create in their own right while remaining consistent to the whole.

Next time: The New Game Design Format (suggestions)

Particleblog's comments have moved to The Play Room.