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...