Sponsored By

The Beatles: Rock Band lead designer Chris Foster believes in design by collaboration (not by consensus), a process he described in a Gamasutra-attended keynote at the GameX event in Philadelphia.

Jason Della Rocca, Contributor

October 26, 2009

4 Min Read

In a keynote at the inaugural GameX Industry Summit in Philadelphia, The Beatles: Rock Band lead designer Chris Foster discussed the value of design collaboration. Having done design work over the past 15 years -- with credits including Caesar 2, Asheron’s Call, Lord of the Rings Online, and Phase), Foster was keen to share his lessons learned from the trenches. He described the designer role as being in a constant state of tension. On the one hand, the designer is defining the shape of the game, but on the other hand, the designer often doesn’t do any "real" production work. Given that, it's easy to think that the job comes down to an attempt to manipulate the rest of the team to implement your ideas. But that's generally a bad idea, since the designer is often wrong. Doing wrong is how you get to the right – and you can get there faster if you work with others. As an example of collaboration gone bad, Foster recalled an early design spec he simply dumped on the development team. They implemented the game to spec, but the end result sucked. There had been no back and forth. There was no opportunity for the developers to clarify ambiguities or improve a weak initial design. There was no collaboration. During his design efforts on Asheron’s Call, Foster had his first collaboration "aha" moment. Early on at developer Turbine, producers were a schedule bottleneck between the designers and the engineering team, who had no direct interaction with each other. The solution to clearing the bottleneck was for the designers and coders to sit down face-to-face to discuss disagreements over design specs: argue positions, make compromises, and then rewrite the spec. Eventually, that process led to starting without specs. Instead, the designers and programmers would sit down and ask each other, How the hell do we do this? Someone would invariably have an initial “bad” idea, and the process was kicked off as everyone reworked the original idea, adding their own input, and taking things in new directions. Foster used the Stone Soup fairy tale as an analogy for this collaborative process. That is, you start with the core of the idea and then let everyone contribute their ideas to make it better. Drilling down into the specifics of process, Foster stressed the need for a moderator. This role is usually filled by the designer, who sets the agenda and keeps the discussion organized. Clear goals and specific questions to be answered are critical. And while collaboration is an exploration, and diversions can be fun, you do need to stay on target for your final destination -– and the moderator holds the map. But collaboration can also be improv, Foster added. One of the golden rules of improv is never to say no. Always say “Yes, and...” As with any good brainstorming process, the key is to not shut down ideas but to talk them through. Foster encouraged everyone to see if each idea goes somewhere or if it just goes away. As a caveat, Foster warned, there is still a need for an active filter. The most popular idea is not necessarily the best. The designer must be active, must think around corners to identify why ideas don’t integrate, and must be willing to say so. Collaboration does not meant to be design by consensus. Instead, let the ideas linger for a bit to see if other ideas emerge -- or reemerge. The designer must also actively seek participation and interaction from team members. This is your chance to ask questions of people and get them engaged, especially the introverts on the team. Be welcoming and, most importantly, be aware if and when you are inadvertently shutting people down. As Foster put it, watch out for that "look." Above all, be humble as you work with others. Within Harmonix, QA team members are assigned ownership over specific systems and embedded in the development strike team for those systems. This allowed for constant real-time collaboration as systems were designed, implemented, tested and iterated. On the broader level, Foster discussed the need to also collaborate with your audience during the development process, by way of playtesting. Listening to your players will help ensure you are making the right game. Even though they won’t give you the solutions right out, you can verify that you’re working on the right problems. Rounding out his talk, Foster argued that a truly collaborative designer takes less pride in personally-created ideas than in the ones he or she collected and refined and shepherded along. Designers need to focus more on owning the process than on owning the product itself. Few people can make consistently good decisions in a vacuum, and better ideas come from everyone’s insights -– ultimately leading to better games. [Jason Della Rocca spent nine years leading the International Game Developers Association. Recently, he left IGDA to found Perimeter Partners, a consultancy focused on building the game industry via consulting on economic and cluster development efforts around the globe.]

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like