Just remember that it's not easy for a fat man in a red suit to climb down chimneys and bestow gifts on children in these so-called modern times without getting attacked by the dog, arrested by the cops, prosecuted to fullest extent of the law, and left with his beard shaved in a stripey suit doing 8-to-25 in San Quentin. Especially not 50 million times all in one night.
Christmas = Hard work
So you better enjoy it. Or else.
Particleblog's comments have moved to The Play Room.
Following on from Designers Without Rules, it occurred to me that any sort of game design that was based on actually conveying the playing experience (as opposed to the production aspects) would need to be direct and involving. A friend of mine suggested that he thought some of the best models for design formats would be things like Prima Strategy Guides.
A Prima guide is essentially a bare-as-bones description of an actual game, and no messing about with long-windedness. They contain full maps, locations of secrets, cheats, strategies for play, and so on. As such, they contain all the relevant detail that a game is from the player's point of view. Wouldn't this be the kind of thing that a game design could be?
I think that there's one big thing missing from the Prima suggestion, and that's the lack of personal involvement. Strategy guides are entirely neutral in their perspective, focusing more objectively on the game and not so much interested in conveying why you want to play. In the Strategy guide view, much like a well-written FAQ, the game is an object to be decoded, and so it rarely (if ever) would get into the possible flavour or fantasy of the game.
Current game designs are also very neutral, mostly because they are essentially based on business plans. In the current design model, everything is theory and statements of intent, essentially. They address the production of the game rather than the game itself, and so are much worse than a strategy guide for design purposes. The current 'design' documents are in fact the same thing as what the film industry calls 'production notes'. I.e. not a design. Let's call that the X-model, because they treat the design of the game almost like a set of equations than a creation. Also, the letter X is linguistically associated with masculinity, which is appropriate.
X-model designs usually refer to player and game in terms such as "Once the player gets to point X, he or she might do this" or "The player is capable of motion in several dimensions through the thumbstick controls and with toggling L and R shoulder buttons" or "Combat between each of the seven available units is worked out as a function of Attack score, Shield score, Cover, Protection, Range and Damage, using a formula as follows:". This is called indirect writing, and it is highly useful for the disciplines of science and engineering, and probably even programming, but it is very dry.
This kind of writing does not involve your audience, and in the case of the game designer, that is a critical failing. The audience for a game design consists of many people, most of them artists, animators, producers, marketeers and coders. If you write in the X-model style, none of the above people will be interested. The only people that are likely to be interested are other game designers. In which case you have failed at your primary task (i.e. design) and wasted a lot of your (and their) time.
In a screenplay, the writing talks directly to the viewer. There is no time that a screenwriter writes "The audience sees..." (unless there is an audience on-screen of course). In a sense, the screenwriter conveys the essential experience of the film to the reader, and he understands it as though he was seeing it. Notation is kept to the absolutely essential. The text describes the essence of each scene without going into windy camera placement descriptions, or marketing explanations. The best screenplays are great READS.
Similar lessons can be drawn from all the forms of writing. It is why a play has stage exits and entrance notations. It's why novels are written the way that they are, spending much time conveying thought as well as action. Poems are nothing if not big bags of literary tricks design to trick the mind into the irrational.
The point is, in each form, writing is used as a means of drawing the reader in and making him live in a writer's imagination. That is its essential focus. Part of that can be perspective, part of it is narrative tricks. But in all cases, it is essential that the writing is focussed on the direct, as opposed to the indirect. Game designs should also be great READS.
With a game design, the focus should not be about we, it, the player, he or she. It should be about You. We should not write "the player can choose to pick up the BFG". We should write "Do you want to pick up the BFG?". The You-perspective (or second person perspective, to get technical) is what gives me my starting point for a new model of game design. I've called it the Y-model, for many loaded reasons, not the least being it sounds good.
So what is the Y-model?
The first part of it is the writing of choice, or the Play-Through. The designer works using the idea of writing a design that actually models choice. Sid Meier once called gameplay "a series of interesting choices", and the Y-model is exactly that. Rather than writing a dry business document, or an informative but neutral strategy guide, the game designer writes a Y-model document as a piece of present-tense second-perspective fiction that offers many choices. The bulk of the document is essentially a tree structure that your reader then uses to actually "play" the game directly.
Or, to put it another way, have you ever heard of Choose Your Own Adventure books?
Or Fighting Fantasy, Lone Wolf, Way of the Tiger and so on?
Choose Your Own Adventure (or gamebooks, as they're called) are models of interactive writing. They talk directly to a reader in the second person, and they involve him in sweeping interactive narratives. Some of them also involve combat in the form of simple dice mechanics, and even some entirely interesting challenges like puzzle solving, item collection, acquiring skills and so on. They even got into the area of wargaming, for example Warbringer.
The way that these books work is that a player reads a numbered paragraph, and then is given a choice "Do you want to use this? Turn to 45" They would then move on to paragraph 45. Every choice becomes part of a series of choices, essentially, sometimes looping back in on itself, sometimes leading on to another branch on the tree. With the addition of basic game mechanics like collection, there is a whole other order of emergent complexity attached. One classic example, from the Way of the Tiger books, was the way that your ninja character could specialise in three of the ten Ninja arts. At certain points in the adventure, you would be offered choices only if you had that skill. "If you have learned Kwon's Flail and want to use it, turn to 182". Otherwise, you would be left with the other choices.
Leaving aside all the roleplaying convention histrionics that the books themselves contain, the actual raw model of the gamebook is a powerful tool because what they do is involve the reader as a character and completely leave the direction of the story in her hands, from the ground up. Just like a good videogame. The story often moves toward one conclusion. Just like many videogames. It contains plenty of game challenges and narrative intertwined. Just like a good videogame.
Some of you are now saying to yourselves, "But it can't possibly cover all the choices that the player makes in a game!". Of course not. But as Sid Meier said, gameplay is all about interesting choices, not all choices. A gamebook format is also about interesting choices. When a screenwriter writes a script, an actor and director (and crew) can choose to shoot the film a hundred different ways, of course, so the screenplay represents a yardstick goal, an inspiration source and a guide. That's what a Play-Throughshould do. It should convey the gameplay, depict the world, and interest the readers by making them players. And they are the people who will be the people actually making it, so you'd better make them interested.
Aside from the gamebook structure, there are probably a few extra items in the Play-Through that would be necessary. Location tags, for example, at the top of each numbered paragraph, so that the artists and animators can evaluate at a glance what locations there are and what changes they'll need. Capitalisation or bolding of names, NPC types, and so on will be tremendously useful as well. Perhaps it would even work best to write a Play-Through as a series of HTML pages, and use standard colours for such significant text, or even links.
The Play-Through would also work better with a strong visual component, to show what the game will look like and what the player will look like in the game. In my earlier piece (Designers Without Rules?), I talked about the need for game design documents to show what the player will see, hear and directly interact with (or 'do', in otherwords), and visual components really help in that regard. Get an artist involved.
Realistically, the Play-Through works better for some types of games than others. It is best suited to any adventure game model, which could mean anything from Splinter Cell to Halo, Zelda to Broken Sword. In otherwords, games that don't require the player to understand rules before proceeding. For more formal roleplaying games, especially of the party-variety, the Play-Through would also be perfectly useful, though more complex. For MMORPGs, Play-Throughs could be used for quest designs and sample playthroughs.
With strategy games, the Play-Through document still works, in a sense, but the designer would have to think in terms of some formal rules that would be included at the end. As for puzzle games, it very much depends on the scope of your interesting choices.
This leads us into the second part of the Y-model: The Gameworld.
With a strategy, puzzle or arcade style game, the Play-Through is going to be less important, for obvious reasons, although still seriously useful for capturing the aesthetics of your game. The second, and highly essential part is The Gameworld. The Gameworld is a very flexible term, used to describe any sort of playing area. A strategy Gameworld might consist of a physical board and pieces for example, which roughly approximate the physical game. A roleplaying Gameworld, on the other hand, would be a series of maps, with a rudimentary rule system that allows players to analog-play the game and figure out what your intentions are.
With a dancing game, you might even take the unusual step of having the Gameworld as a music CD and a timer, a series of mock controls, and so on.
The whole reason for Gameworlds is that they cover "visible" rules, again as part of what players see, hear and do. The guiding light in this regard is whether the player has to learn the rule or not to play. If designing Shogun: Total War, for example, there need to be rules that explain formations, troop advantages and disadvantages, and rules that explain the boardgame section. But there don't need to be detailed rules of ranges and movement speeds for all units, nor the mechanics of how the combat actually works. A statement of intent and possible factors would be enough.
The number crunching part comes later in technical production, and will be done by developers rather than designers.
Between the Play-Through and the Gameworld, the Y-model is essentially an experience-driven design, and this is what professionals in the industry need in order to make the games you have envisioned. There's no point in writing a big theory document that leaves you constantly explaining yourself to fifty different people (all gathering different messages from your explanation). By explaining the design in a detailed way that involves them as players, through a combination of document and world, readers come to understand and appreciate what the game is, and what it is not. Which is far more than with a stuffy-old X-model set of production notes and technical data could. This applies to technical readers, artistic readers, producers, executive producers, and all sorts of business people.
The Y-model also opens the game up to proper analysis and evaluation, as people can give proper feedback and tell you where they think your design is going wrong, which bits are boring, which are too fast, and a sort of editorial feedback that is all-too-often missing from today's games.
Speaking of which, feel free to comment.
Particleblog's comments have moved to The Play Room.
I am currently reading two books, both called 'On Game Design', one by Chris Crawford and the other by Ernest Adams and Andrew Rollings. Both of them are Very Big Books.
They're subjects are ostensibly all about the mighty and arcane art of game design, but I have to say, I'm finding both quite ennervating. All three authors seem to take a long time getting around to actually saying what they want to say. Crawford's writing style is currently clearer, whereas Adams and Rolling are less so. One very interesting quote from A+R, right at the very start, sums the two books up: "One area that we have not addressed is level design."
They are both huge theory books, in otherwords. At least, as far as I've read them. Both of them are also concerned with very long and boring issues that aren't really all that important. A+R go into very long detail about their definition of gameplay, for example. While Crawford does a much larger job of talking about the roles of Conflict and Interactivity.
What amazes me about these two books is that they both have 'codex' ambitions, to create some sort of "bible" of games and game design lore, starting from the basic foundations of play and then, it seems, moving on into videogames. Yet they both make for intensely depressing reads. To read them and take them at their word, one would think that to be a game designer requires an intense level of academia and a sort of hermit-like disposition. Not to mention a capacity for intellectual spoonfeeding.
I am of the view that game design is both interesting and in need of study, but not like this. For one thing, play is really not that complex a process to understand. What amazes me is why some people seem to feel the need to make play out to be something that it isn't. There are a few basic ground rules to be learned, much like in writing, but it really doesn't need this level of tedium, frankly.
Game design should be anything but tedious, and I'm sorry, but endless windy examples do not really make the case for it. The books are also full of really serious attempts to politicise games and gaming philosophy, for reasons that I haven't fully understood yet. Crawford talks long and loud about how more interactivity must always be better (to which I am forced to point at Steel Battallion and say 'Oh really?') by saying that more 'cinematic' films are nearly always better. Rubbish. Adams and Rollings, meanwhile, are determined to forgo all mention of the actual practical end of design (the levels, see above) and instead take a noble/humble view of game design as a craft, not an art, and advance a model of design documents that clearly are not about the game design, but the game production design. (see Designers Without Rules on this site).
What the hell is going on here?
In a form that is in danger of obliviating itself, shouldn't would-be authors be attempting to inspire new new talent instead of stultifying it? Shouldn't they be encouraging people to actually have opinions and artistic intent, instead of saying "Designing games is a craft, like cinematography or costume design". That's right folks, the last thing that games would ever want to be is controversial or, you know, artistic. Crawford adds to this sentiment by adding that play should always be safe, feel safe, and so on.
I believe that this is the result of the 'videogames are boardgames extended' school of thought: A one-way ticket to oblivion. It is a message to would be designers that they should have no ambitions or controversial opinions. It is Old School. It's time for the New School. The one that says it's OK for a designer to actually challenge players intellectually, morally, even ethically. The tools are right there, but these two books tell you that you are wrong to use them that way.
WHY?
From the outside looking in, this sort of thing is simply going to scare off many talented individuals. And then authors wonder why there are many games professionals who hold gaming academia in such low esteem. Rightly so, if this sort of thing is anything to go by.
A much better model for a game design book would be something like Screenplay, not because it is about screenwriting, but because it is short and sweet and practical. Syd Field dares to cut to the chase and use examples, lay out a simple premise that works well, and then he proceeds to develop it. He doesn't spend a hundred and more odd pages preaching the pseudo-academic patchy theory of unfulfilled childhoods, 'all games are one' and 'the noble craftsman' to the unwashed.
When will someone write a game design book that starts out with 'You have a right to create!'
You might be able to tell that I'm annoyed.
I'll have more on this when I finish the books in question, and the piece all about game design formats is also on the way.
Particleblog's comments have moved to The Play Room.
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?
Culture
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.
Trust
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.
Fear
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.
Posts
All Comments
