Good storytelling from a production point of view

A few weeks ago, I participated in a workshop on game design and storytelling in LA. I’m sure ‘Spend two days sitting in a hotel conference room talking’ is not on the top of everyone’s list of Things To Do In LA, but it was for me (the other thing was ‘Drive out of LA’ – more on that in some other post). One of the parts I like the most about my profession are the discussions with other game developers, so being invited to do just that with 29 veteran game designers is difficult to refuse, even if it requires flying to the other side of the world.

Every participant gets to pick a topic of their choice and then basically moderates a round table for 40 minutes. This blog entry is the report of my session. Before I start, a big disclaimer: I have rewritten the notes that were taken by myself and others. Most significantly, I have removed the names of the participants. I dislike making someone else’s point for them. After writing down what people said during the session and then rewriting it here, I will inevitably have introduced some personal bias. I prefer writing down my interpretation of (and elaboration on) what was said, much as I do when I blog about some news item. Also, for a variety of pragmatic reasons, the workshop likes to keep a low profile.

The downside is, of course, that I may appear to be ungrateful, or to take credit for what someone else has said. Au contraire, dear reader. Let me assure that you that, if something appears wrong or bone-headed, it was caused by my inept editing or poor mental facilities. If you find something edifying, it was the shining thought of the involuntarily anonymous workshop participant.

Onwards to the topic! My question for the group was more related to production than to game design or storytelling per se:

What does one need to do, in terms of organization and producing, to ensure good storytelling and good gameplay in a medium-sized game team of, say, 30 to 60 people?

Making a playable game is already quite hard, making a playable game with a decent story even more so. What I was interested in was how team structure, schedule structure, production processes, team goals and other production issues could help or hinder storytelling.

Management philosophy

One of the big topics that came back again and again is that of a game team’s management philosophy. Who decides what? What are the rights, duties and responsibilities of each individual team member?

On the one hand, teams have a hierarchy, and not everyone needs to understand the design. Game development teams are not democracies. One participant said that, compared to Hollywood, teams in the games business are over-coddled. (Another mentioned, offhandedly and much later, that Valve’s cabal process was one the most poisonous ideas to be introduced into the games industry in the last ten years. I agree, even if the article that explained it also contained one of the most powerful ideas about game development I’ve read in the last ten years. But I digress.)

On the other hand, you want to make the best possible use of your team. No one has ever known everything there is to know about a project, but that doesn’t mean that isn’t a good target to shoot for. The people on your team will be relentlessly creative, and you want to funnel that creativity productively, rather than having them going down blind alleys and then shoot them down because it doesn’t fit. (There’s more on managing ideas further down.)

No-one can or has to know all, but being able to know all is good for morale. Being selective in publishing information is counter-productive: why worry about deciding who needs to know what? Why not give everyone the opportunity to read all? Do you know the strengths and interests of every single team member? (Making sure everyone knows what they MUST know, and that they can easily find that information, is a separate issue.)

You will have the occasional team member who suggests dumb ideas, and shooting these down is tough, but when you make sure everyone knows what the team is shooting for, you will automatically reduce the number of ideas that don’t fit, and increase the number of ideas that do. If in the end you still have someone who keeps proposing ideas that don’t work and can’t be made to understand why, this person may need to be replaced.

People want a vision for the game, and want clear rules defining what their place is in defining and implementing that vision. I know it works for me. It’s all about giving people a framework in which they can direct their energies. Being unsure of what that framework is, how it could change, how I could change it, and being micromanaged: these all lower morale. The French may not have a proper word for ‘schedule’ (‘le planning’ – I’m sure the Académie frowns on it) but they do have the wonderful verb ‘encadrer’ (‘framing’ comes close) which comes up a lot in discussions on management there.

It’s a big subject, and one that gets discussed quite often. I suspect that it keeps coming up because it pushes some basic buttons of the typical game developer, because it is so hard to strike a balance between telling people what to do and letting everyone contribute as much as they can, and because this balance changes from team to team, as well as the games industry evolves and the average team size grows.

The games business is still quite multi-disciplinary: it is not as centered on separate crafts as Hollywood. This may change as team sizes grow to 100-300 people, and game development becomes more decentralized. I’ve always thought that the big budget movie approach to filmmaking is possible because the process of filmmaking is relatively well-known and stable. It evolves, and varies from film to film, but in many ways it hasn’t changed much for 75 years or more. Just like, in fact, the form of film as a medium hasn’t changed much in that same period. Yes, today’s films are different from the ones made  back then, but the difference is less significant than the one between the games of today and the games of just twenty years ago. When one or more interactive forms have settled down (and this is a highly interesting topic in itself), the process of making these forms will settle down as well, and perhaps our industry will become, in this aspect at least, more like Hollywood, for better or for worse. But perhaps it’s good that we’re still dynamic.

(Note how this part of the discussion reflects, to some degree, what has been happening in the software methodology space, with the rise of agile development: Extreme Programming, SCRUM, etc. In fact, agile development was mentioned several times.)

Communication

A closely related discussion topic was communication. If you want the whole team to integrate the story into their work, communication is key. In a way, in discussing management philosophy we talked about the environment in which communication can happen, after which we discussed the practical mechanisms and methods, such as wikis, daily standup meetings, physical setup, etc.

Presenting story

We also talked more in-depth about how the story can be presented to the team. At one company, designers do a dog-and-pony show of the story. This lead to increasingly entertaining presentations. Having the designers present the story to the rest of the team makes them focus on the task of communication.  It’s also good for finding out the attitude to story in the team, and the people in the team learn how their efforts tie in with the story.

At another company, the story was presented during meetings of other disciplines, which I thought was a great idea. Other tips that were mentioned for the presentation of story is to distill it down to key points, to keep it verbal and visual, and to use concept art. Someone else put all 180 plot points of the game he was working on on a 20 foot chart, and had a separate chart showing the current level (because the team was fairly small, they only worked on one level at the same time).

Managing ideas

Several people mentioned that you need a process for making sure ideas aren’t lost. Put ideas from team members on a list, and use a specific time to evaluate them. Often people will remove bad ideas by themselves. Larry Constantine once described a somewhat similar process, which I absolutely have to mention sometime in this blog. I mean, in more depth than this brief teaser.

One participant mentioned that Walt Disney used to pay a bonus whenever an employee came up with a gag (this was back on Snow White – I don’t know how long this persisted). I once read that every member of the Metal Gear Solid 2 team had to write down one idea in a notebook every day, although the article didn’t say what happened to those ideas.

Company culture and education

Several people mentioned raising the level of storytelling sensitivity in a team or studio by organizing acting classes, shared movie watching or training sessions with a pro writer. One participant mentioned that his studio had switched to story, i.e. had committed, as a company, to take story seriously from now on. In my experience, this kind of top-down commitment is essential for making changes in the way a company does things. There’s only so much you can do without support from management.

Team structure

In one studio, the team was divided into groups that were not all equally familiar with the story, so as to be able to keep getting fresh input. Another participant mentioned that it’s a good idea for team directors to have people around them to cross-pollinate and give good feedback. And of course outsiders can always give a fresh perspective.

Working with, or as, an off-site writer

Since several independent writers were present, I got quite a bit of good input on this. It was stressed that the remote writer has to be part of the team. Methods to insure this includes traveling to meet the rest of the team, going out and drinking beer (I personally – and seriously – endorse the last two methods: I have seen this work wonders many times), daily IM or Skype sessions and VPN access.

The writer must be institutionalized as being part of team. And the writer and the writing (!) must be involved early. That short sentence does not do justice to how important that is, so let me say it again: the writer and the writing must be involved early.

And one final thing that was said was: if you’re serious about storytelling, you need to get a pro writer. Just as games are no longer designed by the lead programmer* and the lead artist, games can no longer be written by your cousin Joe. This should be fairly obvious by now, but sometimes it can become less obvious when the time comes to cough up money.

*) Unless it’s the early 90s and I’m that lead programmer :P Oh, I also wrote some of the stories back then. But they sucked!

Scheduling

We didn’t talk about scheduling much, although I think there are some interesting task dependencies around storytelling. The one thing that was mentioned was that if you’re going to release your game in multiple languages simultaneously, you better make sure you have all your changes locked down before localization starts. Of course, this also applies to voice recording, and, in fact, to the majority of production tasks in one way or another. It’s generally not a good idea to decide to set your game in a forest after you’ve been producing desert content for 6 months…

Technology

Technology also came up as a subject. Various people suggested looking at the specifications for the tools and engine, so as to understand at the beginning what is possible and what isn’t, and to make sure that the technology can support what you want to do story-wise (actually it would probably be better to do this the other way around). Having the writer talk to a programmer early on helps. On the other hand, locking down features early gives people constraints to work in – clear rules again.

Documentation formats

Several participants mentioned wikis as a good format for keeping design documents in. (Although wikis have pros, they also have cons, and I feel some parts may be better represented using other means. But once again, that’s another topic.) Someone suggested making the test lead the maintainer and nit-picker of the wiki, since the test lead often has little to do in the beginning of the project when a lot of documentation is being written. I think that’s a great idea.

Sometimes you need the documentation in another format, such as a nice printable document. This can be problematic, when information can not be easily converted, exists in multiple places, and must be kept in sync. But these problems are all solvable.

The problem of team members not reading documents was raised. It was countered by the radical suggestion of firing people who don’t read the documents they need to read. Although this is perhaps over-enthusiastic, I think this is another case where top-down pressure can help. (I particularly like an idea from formal reviews, a code quality method: if someone hasn’t prepared for the review, call it off immediately, write down in the minutes that the review was cancelled because not everybody was prepared, and schedule a new one.)

One person mentioned that agile development argues against the massive up-front design doc, but we didn’t go much further into general development methodology issues.

Conclusion

And there you go: 40 minutes jam-packed with fun and adventure. There were a lot of good ideas, and even with established ideas it was great to hear them confirmed by so many experienced people.

Now to put it all into practice some day…

Comments 9

  1. Stephane Bura wrote:

    Very interesting. I wish I could have come.

    I’m going to lift the “talking about story in stand-up meetings” idea from your post (and probably the chart one too). We do have daily stand-up meetings for planning and I hadn’t realize how great an opportunity they were.

    Thanks.

    Posted 04 Nov 2005 at 23:02
  2. Jurie Horneman wrote:

    Well, you just saved yourself about a thousand dollars and some nasty jet-lag.

    (A bit of an obvious set up for trying to get a free dinner, I know.)

    Posted 08 Nov 2005 at 2:09
  3. Stephane Bura wrote:

    If you’re willing to come to Belgium for it, you’re welcome :)

    Posted 08 Nov 2005 at 23:18
  4. Jay Woodward wrote:

    “Another mentioned, offhandedly and much later, that Valve’s cabal process was one the most poisonous ideas to be introduced into the games industry in the last ten years. I agree, even if the article that explained it also contained one of the most powerful ideas about game development I’ve read in the last ten years. But I digress.”

    Well finish the digression, dammit! :) What do you find powerful and poisonous about the cabal concept?

    I say it’s powerful when it’s implemented, and it’s poisonous when it’s not. ;)

    To elaborate: when design-competent artists and programmers learn about the idea of a “cabal,” and can point to how successful it was for Valve, it causes them to feel extremely justified in wanting input into their project’s design — and even more disgruntled than they otherwise would have been, when management and the design team refuse to try it.

    Yep. “Like my hat? It’s made of poison!” ;)

    Posted 13 Nov 2005 at 4:30
  5. Jurie Horneman wrote:

    I am all for having everyone think, instead of having just a few people think and telling everyone else what to do. Developing games is pure knowledge work, so the more knowledge you have (through recruiting, developing, and retaining the right people), and the more of it flows into the game, the better. (The knowledge ‘pipeline’ is a bad metaphor because it misses the interdisciplinary, alchemical part, but oh well.)

    However, the cabal process, as described in that GD article, can easily be interpreted as being a creative democracy, and that’s something I am convinced can’t work, as a repeatable approach or process. Simply put, you need to have one person who keeps the vision.

    A friend of mine once interviewed Ken Birdwell, the author of that article, and it turned out their implementation is not a creative democracy, and they do have vision keepers.

    The problem with success, as I’m sure you’re aware of, is that it is hard to pin-point why someone has been successful. It is often a combination of many things, plus some ineffable qualities and some luck. But it is very easy to pick one obvious trait, such as the cabal process, and emulate it. But even if this process was the reason for someone else’s success, you may emulate it badly, and – more importantly – it may not fit your organization at all.

    Having worked for several companies, I’ve grown to appreciate the influence of company culture and how it influences what an organization can and cannot do. I am entirely hypothesizing here, but likely cabal works for Valve because they were founded by certain people who hired the right people and who shaped the company so that that works. And probably the cabal idea came completely naturally to them.

    (Yes, I can and do argue with success.)

    For an impressive and apparently successful approach to consciously shaping a company’s culture, try to find out how Ensemble and their offspring studios work. I don’t think I can quote it here, and anyway I’m not the right person to write about it.

    I will write about the powerful idea from that GD article in a separate post.

    Posted 13 Nov 2005 at 13:21
  6. Jay Woodward wrote:

    Without looking back to check either the old gama article or the new GD “scaling the cabal for HL2” article, here’s how I would describe the requirements for the functioning of a cabal:

    * Ideas and suggestions can and should come from any member of a cabal, at any time. This is necessary because it ensures that the project is open to the best ideas.

    * There is a single individual who is the cabal’s “ultimate authority.” This is necessary in order to filter out the best ideas and assemble them into a coherent vision & plan of action.

    * The “ultimate authority” is someone within the cabal, obviously. This person don’t have to go outside the cabal for approval — of anything. This is necessary in order to ensure that the cabal is self-sufficient. (It does not preclude a cabal of cabals.)

    * The “ultimate authority” is supremely reasonable. Which means: this person will select the ideas that are the most compelling, taking all factors into account, especially including scheduling. Furthermore, this person can then justify their decisions, in a way that’s compelling even to those who initially disagreed. (The goal is not that this person’s authority should be challenged constantly, but rather that this person’s capacity for reason eventually becomes so self-evident that the cabal gains complete confidence in this person’s ability to make the right decisions.)

    So, rather than a “creative democracy,” what I’m really looking for is a “creative President-and-cabinet”. Except that the president isn’t necessarily elected. The whole cabal has to be pretty level-headed, in order to pick the most reasonable of their number to be the vision-keeper.

    Given how I’ve just described my own wacky vision of “cabals,” I must agree with you: I’m quite willing to believe that there are companies that could not possibly work effectively using such a system.

    Posted 22 Nov 2005 at 1:36
  7. Jurie Horneman wrote:

    Jay, I like that system, in fact I like it better than Birdwell’s description :) I think we’re basically talking about the same thing, just calling it differently.

    The original article can be found at: http://www.gamasutra.com/features/19991210/birdwell_01.htm

    There is no explicit mention of any ultimate authority, either intra- or inter-cabal, just recorders. I quote:

    “The first few months of the Cabal process were somewhat nerve wracking for those outside the process. It wasn’t clear that egos could be suppressed enough to get anything done, or that a vision of the game filtered through a large number of people would be anything other than bland.”

    Which implies to me that they did not have an explicit mechanism, but were, basically, just lucky because they picked the right people with the right level of maturity. (I think the lack of an explicit mechanism is scary and makes people attend more meetings than they strictly have to, but hey.)

    The article also mentions the value of having a professional writer (Marc Laidlaw, presumably) on staff: “his ability to keep track of thematic structures, plot twists, pacing, and consistency was invaluable.”

    I think he did more than just keep track of things. It is Half-Life’s consistency that is one of its strongest (and least appreciated) traits, and one of the things that’s pretty hard to make happen without squashing everyone else’s creativity.

    Posted 22 Nov 2005 at 8:42
  8. Jay Woodward wrote:

    Yeah, Ivan the Space Biker is an old friend of mine. :) I’ve read that original cabal article several times, though obviously I don’t have it memorized.

    Maybe my thoughts regarding an ultimate authority are just a reflection of what I think it would take to try to patch the cabal system into the team culture that I’m familiar with. If everyone on the project was inherently sold on the effectiveness of collaboration, perhaps you wouldn’t need an enforcer of authority. That seems to have been the case for Valve.

    (Then again, if people aren’t sold on the effectiveness of collaboration, perhaps they wouldn’t accept the authority anyway. Whee.)

    Posted 23 Nov 2005 at 3:26
  9. Jurie Horneman wrote:

    Jay, this is exactly why it is so hard to adopt someone else’s working methods. What works or not depends on the values (or culture if you like) of the organization, be it a small team or a huge company. Those values are usually implicit – it takes insight to be aware of them and courage to maintain, let alone change them. Usually they are implicitly set by studio founders and other early employees, they’re the ‘unwritten rules’. One of the things I regret not having done as a producer is to try to articulate the values of the team (especially between the leads), to try and push those values in a certain direction, and to sell them to / defend them against upper management.

    In other words, if people aren’t sold on the effectiveness of collaboration, you probably shouldn’t have hired them if you want to have a team culture that relies on collaboration. By the time you realize that, it’s usually too late :) Of course, whether you agree or not depends on how much you think people can change.

    Posted 23 Nov 2005 at 8:52