Games, Design and Play: A detailed approach to iterative game design (2016)
Part II: Process
Chapter 8. Collaboration and Teamwork
This chapter explores one of the more important aspects of iterative game design: collaboration. Topics such as setting up team rules, running meetings, and establishing roles are discussed. And perhaps most important, techniques for resolving differences and conflicts among team members are introduced.
Before diving further into the game design process, let’s step back and think about the collaborative nature of making games. Both of us have been part of many collaborative projects throughout our careers, with teams ranging from 2 to 20 people. We’ve also overseen hundreds of student teams as they worked on collaborative projects. Through all of this, we’ve experienced many, if not all, the pitfalls and challenges of collaboration. That’s what this chapter is about: the things you need to pay attention to when working in a group. It’s about knowing who is doing what, how you’ll work together, how to run meetings, how to identify and work through differences, learning to embrace failure as part of the iterative process, and the creation of team agreements to help structure how it all unfolds.
More often than not, games are made by teams. This isn’t always the case, of course, particularly around smaller, or more personal games like anna anthropy’s Queers in Love at the End of the World or Captain Game’s Desert Golfing. Still, in the vast majority of cases, games are collaborative productions. So developing skills to work well with others is just as important as honing game design, programming, sound design, and art direction skills.
Roles and Responsibilities
One of the most important areas to consider is who is doing what. Traditional roles in game development revolve around game design, programming, interface design, visual art, sound design, project management, and testing. On larger teams, these break down even further—within game design, there might be a lead game designer, level designer, vehicle designer, and so on. But on small teams, the roles and responsibilities tend to mix: a designer who also programs; an artist who handles project management; a sound designer who works on level design. Even with overlapping roles, it is important to know who is doing what to avoid potential confusion and frustration.
Here is a simple explanation of the roles and responsibilities to take into account as you and your team design your game. Depending on the game, not all roles may be needed, but these are the basics.
Game design: Most simply stated, game design is the determination of the game’s goals, the play experience, and the objects used and actions performed by players to achieve those goals.
Programming: The programmers implement the code that allows the game to be played. This includes the gameplay but also other things like communication with servers, hooking into controller protocols, and other processes that make the gameplay happen.
Art direction: The artist creates what the player sees while playing the game. This can include the character design, animation, world design, splash and credit screens, and interface elements.
Narrative design: The creation of the game’s storyworld, should it have one. This can include a range of activities like writing backstory, developing characters, writing dialogue, creating scenarios to connect levels or scenes, and so on.
Sound design: The musical score, environmental or ambient sounds, and event sounds that play during the game. On smaller teams, this role will include both the early-stage concepting and style development and the later-stage production of implementing sound.
Art implementation: Separate from the creation of the visual and aural style is the implementation of these. This breaks down into a wide range of production tasks—animation, modeling, rigging, and sprite creation, for example.
Testing: The process of planning, organizing, running, and documenting playtests of the game’s prototypes.
Project management: The day-to-day management of the schedule and budget, ongoing and upcoming tasks in the iterative design process.
Marketing/public relations: Even on student and indie projects, it’s important to keep in mind that talking about your game and helping it find an audience is a part of the process.
While these are the primary tasks of game development, they do not have to be isolated roles. Many developers, particularly on the small team projects this book focuses on, find it better to have shared responsibility for tasks. Local No. 12, our company with Eric Zimmerman, shares game design and project management tasks, and everyone provides feedback on all aspects of the game. From there, we have specific roles. Colleen leads the narrative, content, and marketing aspects of our projects, John the visual design, and Eric the game design documentation and playtesting process. On some projects, Colleen codes, while on others we bring in collaborators to handle this part of our games. On another project outside Local No. 12, Colleen and John share game design, while another collaborator develops custom controllers, and two others code. John does art direction, too, while Colleen does interaction design.
Alignment Versus Autonomy
On most teams, there isn’t a “boss,” and no single team member has final say over any aspect of the game. In some fields, project manager or producer roles are thought of as “the boss,” while in many creative fields, the creative lead is considered to be in charge. But in small team game projects, that isn’t always the case. Many small game teams prefer to strike a balance between autonomy in roles and alignment of team vision. For example, the art director will likely create style frames (a single image of what the game will look like) or screen mockups, but they won’t necessarily have final say. In fact, given the way game design, art direction, coding, sound design, narrative design, and all other facets of making games overlap, it is important that the team gives feedback on important decisions in the process.
The more autonomy someone has in their role (or roles) on the team, the more likely they are to feel empowered and thus engaged and committed to the game project. The more aligned everyone is, the more in sync the team will be, but the less autonomy any one person has. This is the fundamental balance teams must find to keep the process healthy and productive for everyone. Henrik Kniberg talks about balancing these at the streaming music service Spotify.1At Spotify, they think about this as a pair of intersecting continua where they want to have clear goals for each project that everyone agrees on. Team members are then given autonomy to find ways to achieve the goals.
1 Spotify Engineering Culture (Part 1)” by Henrik Kniberg. https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/.
We have found consensus-based decision-making2 to be the best approach for balancing autonomy and alignment. Individuals have areas in which they focus their energies, but important decisions are discussed and agreed upon by the entire team. An important distinction to draw here is between agreement and consent. While everyone may be okay with a decision, that doesn’t necessarily mean everyone is in agreement. Being able to tell the difference is important to avoid latent tension in the group. It takes time and energy, but establishing consensus in which everyone buys into a decision is well worth the effort. This may seem like it would take an inordinate amount of time, but that is not necessarily the case.
2 A great resource for how to make decisions through consensus is found here: www.consensusdecisionmaking.org/.
The more clearly a team can establish its goals for the game, the more members can trust one another to autonomously work toward their success. Design values (discussed in Chapter 6, “Design Values”) play a big role in this. If everyone knows what the team values about the game’s play experience, then team members can feel open to explore the best solutions, processes, and implementations to meet the design values. This also requires frequent check-ins to see how everyone is proceeding on their portion and how the decisions team members are making impact the work of others.
Time and Resources
In the same way that many of these roles will be split among team members in different ways, the amount of time and energy required by each will vary over the design process. For example, the art direction and programming may not really begin to happen until the concept is gelled on some projects, while on others, things begin with art or code. It is also likely that roles will shift over the course of the project. At first, the project management may be handled by the art team, but later, once the game design is understood, project management may shift to the game designer when the project gets to core game prototyping. (The types of prototyping are introduced in Chapter 11, “Playtesting Your Game.”) Being aware of the shifting demands on different aspects of the design process is an important part of keeping a team productive. At times, this can mean the team needs to make changes to the overall schedule to accommodate other responsibilities and needs.
Time is a precious resource, as are labor and money. While many games can be made by “sweat equity” (labor invested in the project in hopes of future returns), there are inevitable expenses the team will encounter—software licenses, game controllers, travel to events to showcase the game, snacks for playtesters. It is important to recognize and respect the time, financial, and material resources team members can afford to give the project.
Team Agreements
Once team roles are established and time commitments are understood by everyone, the next step is putting together a team agreement. Team agreements spell out how the team is going to interact, how decisions are made, how ownership of the game is handled, and many other important elements of collaborations between individuals. This may seem overly formal for a small-team game project, but the fact is, team agreements really can help a lot when things go incredibly bad, or, even more, when they go incredibly well. While this aspect of the process is perhaps outside the game design and development scope of this book, it is nevertheless important as you identify team roles and responsibilities and will prove invaluable as you all embark on the process of making your game.
Goal: What is the purpose of the team? Knowing why you have come together is one of the most important things to capture in the agreement. Is it to bring the game to market? To be the first product of a new game studio? To create a proof of concept to enter in contests or shop to publishers? To give away? To display at game events or in a gallery? To successfully complete a school assignment?
Team member status: Defining what it means to be a member of the team is important. Does it mean you have voting rights? Does it require a certain amount of time? What happens when a team member decides to leave the project or put their participation on hold?
Ownership: If things go really well (your game ends up on a featured carousel on Steam or as a featured game on the Apple App Store, as a favored game at festivals and conferences, in the Museum of Modern Art) or really poorly (team members invest time, energy, and resources into a game that is never finished or doesn’t find an audience), the team will want to establish how ownership of the game is calculated. Is it an even split among team members? Is it based on time put into the project? What happens to an ownership stake if a team member leaves the project before, during, or after its completion?
Participation expectations: Making clear the team’s expectations of its members is important to avoid conflicts around everyone’s participation. Sometimes this is measured by time estimates, sometimes it is based on simply carrying out the assigned tasks, and sometimes it is not measured at all. The important thing here is everyone understanding how they and their team members are expected to participate in the project.
Roles: Depending on how a team operates, they may want to establish the roles the team needs and who will fill each. It is also important here to acknowledge the shifting needs of the project and roles that may shift as you move from iteration to production to game release.
Decision-making: There are many kinds of decisions to be made when designing a game—the design values, what to prototype and test next, but also decisions about whether or not to bring in a new team member, to spend money on tools or assets, and so on. Having protocols for how the different classes of decisions are made is crucial. Break down decisions into creative, process, and business. For each, identify what agreement means—majority rules, two-thirds agreement, consensus, and more.
Term of agreement: Understanding the timeframe under which the team operates is the last important detail. Is it within the confines of a course or school program? Is it something everyone agrees they will work on for three months? A year? Knowing how long the team agrees to work on the project helps everyone measure time and create milestones for the project. Equally important is having a plan for extending the agreement, and in some cases, bringing it to an early conclusion.
Collaboration Tools
One of the seemingly mundane but critical aspects of collaboration is creating and refining the way your team works together. There are times you need everyone’s attention and times when everyone needs to focus on their work. Sometimes a decision requires a meeting, and sometimes it requires just a short chat between a couple of team members.
Related is knowing when and how the team will meet. It might seem obvious, but having a handle on this is critical to a game’s successful design and development. Will the team meet in person? Online? A mix of the two? For us, we tend toward a blend, with most work done remotely, and meetings held in person or over videoconference software.
Having a solid set of tools to track collaboration is essential. There are a lot of really useful tools out there, each perfect for different teams. We use a variety in our work, and often what we use will depend on the project. These broadly break down into three categories: file sharing, task management, and communication.
File sharing: One of the more important kinds of tools is file sharing—without this, teams will have a hard time keeping track of the game design documents, schematics, playtest plans (covered in Chapter 11), and other important materials. Tools like Google Drive and Dropbox allow for cloud-based document sharing and work well as a place to keep important files everyone on the team needs to access. A more robust class of file sharing for actual project codebases is found in version control software such as Apache Subversion (SVN) and Concurrent Version Systems (CVS). These are the tools that allow teams to have a shared repository for the living documents of a project—code bases, 3D models, art files, and more. They allow team members to “check out” a file so that they can work on it without others writing over their work.
Task management: Equally important are tools that manage workflow. There are a lot of options, from the task spreadsheets described in Chapter 7, “Game Design Documentation,” to the shared tools like Trello and Basecamp. All these are excellent ways to create and stay on top of the team’s schedule.
Communication: The final category of collaboration tool is around remote and asynchronous communication. While some teams will work in a shared physical space, many will not, so having channels for communication is important. Here as well there are many options—Slack, Skype, even Google Plus or Apple’s Messages.
We suggest trying the simplest, most familiar, most popular, and least expensive tools you can find, and if they don’t work for the team or you need other functionalities, going from there. Ultimately, choosing the right tools for your collaboration is all about what everyone feels most comfortable using and what people will actually use. For example, we have tried more specialized task management software several times, but we always return to simply sharing a spreadsheet. The key here is that using the tools is seamless and easy—and doesn’t get in the way of spending most of your time working on your game.
Running a Meeting
It may seem like there isn’t anything to say about running meetings, but the fact is that keeping them productive, focused, and conflict-free is no small task. Poorly run meetings can sidetrack the best-laid plans, or even worse, hurt team morale and the progress on a game’s design. On one hand, meetings are time not spent working on the game. On the other hand, they are an opportunity to share ideas and progress and to ensure everyone is working toward the same goal. There are a lot of theories about running meetings—from informal standing meetings to Robert’s Rules of Order3 to consensus decision-making. They all work—or don’t—depending on the team, the project, and the context in which the work is being done. If you would rather not focus on a particular methodology, plan for the basics of a productive meeting: goals, agenda, talking rights, decision-making, action items, and note-taking.
3 Robert’s Rules of Order was created in 1876 by Henry Martyn Robert and continues to be used and revised to this day.
Goals: What is the meeting about? What does the team hope to achieve? Having a set of conversation topics will make the meeting more focused and productive for everyone. Using the “for discussion” sheet list in your project management spreadsheet (from Chapter 7) is great for keeping track of your team’s goals. These goals should be steered by the increasingly granular breakdown of long-range, mid-range, short-range, and immediate tasks. For full team meetings, staying at a level of abstraction above immediate tasks is smart because it keeps the meetings from bogging down in details that don’t pertain to everyone. For smaller meetings around specific short-range tasks, getting into detailed immediate tasks makes more sense.
Agenda: With the goals in mind, the team should create an agenda for the conversation. This involves which topics will be discussed, in what order, and for how long. An agenda keeps the team on track and helps keep focus on the topic at hand.
Talking rights: When a group of people with passionate opinions on a subject get together, it is often hard to get a word in edgewise. To help manage the well-intentioned enthusiasm of your team, establish a protocol for who can talk when and how that person communicates when they are done. Of course, there is a fine art to discussion and dialogue, but it is also important that everyone be heard and that the loud and forceful don’t win out over the quiet and polite.
Decision-making: How will the team make decisions? There are so many things to make decisions about when designing a game, but the most important are those around what to prototype, how to test it, and what to do next based on the outcome of the playtest. So establishing a process for how decisions will be made is essential. Here again, consensus decision-making can provide some guidance.
Action items: A meeting without action items is just a conversation. Make sure everyone has a list of action items based on the discussion and decisions made during the meeting. These should be transcribed into the “task list” sheet discussed in Chapter 7.
Note-taking: To help capture the discussion and decisions, someone should take notes. Using the agenda as an outline is a helpful way to do this. Moreover, rotating who takes notes is a smart way to share the responsibility from meeting to meeting. These notes should be kept in a place accessible to the whole team. Using a Google Doc that contains a running set of notes for all team meetings is a good idea since it allows the team to revisit previous meetings as necessary, as well as translating the notes to action items in the tracking spreadsheet, including any updates necessary in the design document.
The Soft Skills of Collaboration
Equally important to the successful design process are the “soft skills” of being a good team member. It is important for the team to recognize the shared and divergent values and goals of all team members. Some will value the freedom to manage their own time, while others are fine with a detailed schedule but prefer to work at night or only during the workweek. Some will have strong personalities, while others will be shy and quiet. Some will be on the project for the experience, while others might be because they really love the game’s concept. One team member may prefer coworking, while others prefer asynchronous work. This team member may prefer daily meetings, while that team member may prefer no meetings but having a constant open chat session among the team for questions and discussion.
There is no single right way to run a team, and finding the right way for a team will take time, patience, and mutual respect. Listening to each other, being open to ideas radically different from your own, and giving credit to teammates are just a few of the most important skills to develop to work effectively in teams. And even if everyone works well together, learning how to resolve conflict is something that can test anyone’s patience. This is where structures like meeting agendas, agreements, and even the iterative process come in handy. During some of the biggest conflicts on design questions, it’s often the prototyping and playtesting process that we can fall back on to help resolve things and show the way.
Special attention should be paid to make sure everyone’s opinions are heard. Since not everyone is comfortable speaking up on their own, it is helpful to pose questions to the group, give prompts to those who are more soft-spoken, and give opportunity for written feedback before or after meetings. Strategies like these can go a long way to make sure everyone’s thoughts are taken into account.
Resolving Differences
Put talented, passionate people together, and you are bound to encounter differences of opinion, personality, methodology, and so on. This is inevitable. The trick is to find ways as a team to work through your differences and turn them into strengths, not weaknesses.
In their book, WOVENText,4 Rebecca Burnett and her collaborators identify three core kinds of conflict in teams: procedural, affective, and substantive.
4 Rebecca Burnett, Andy Frazee, and Robin Wharton with Katy Crowther, Kathleen Hanggi, Jennifer Orth-Veillon, Sarah Schiff, and Malavika Shetty, Georgia Tech WOVENText version 2.1. New York: Bedford St. Martin’s, 2012.
Procedural conflicts: Procedural conflicts relate to the processes through which a team collaborates. Does someone feel unheard based on how meetings are conducted? Is the schedule too loose or tight? Do team members feel constrained by or uncertain of their responsibilities? Procedural conflicts are systemic in nature and can be worked on iteratively. Seek out solutions to the problems causing the conflicts, and implement changes to see if things get better for everyone.
Affective conflicts: Affective conflicts are those relating to team members’ feelings, which in turn relate to their goals, needs, and wishes for the project. As Burnett notes, affective conflicts often emerge from differences in values, which often derive from factors like gender, creed, culture, class, age, and sexual orientation. Dealing with this sort of conflict can be a real challenge, as it is often borne from deeply instilled ways of thinking and belief. The best way to avoid affective conflict? Be open to other points of view, develop active listening skills, and most important, be willing to reflect on the ways your own identity, beliefs, and behaviors impact those around you.
Substantive conflicts: Finally, substantive conflicts are those relating to the game itself—things like what kind of game it is and what kind of experience the team wants to provide players. These are the “good” kind of conflicts, within reason. Best case, substantive conflicts come from team members’ commitment to the game and wanting it to be the best it can be. Worst case, substantive conflicts come from team members’ wanting to overly assert their own vision of the game. The best way to handle this sort of conflict is to return to the design values the team has established and to make sure everyone is still on the same page.
One of the benefits of the iterative design process is that it provides insight into the game’s design in ways other methodologies do not. Instead of relying solely on the opinions of team members, well-done playtesting will illuminate the strengths and weaknesses of your game. This can help push through the substantive conflicts, so long as the team is willing to objectively learn from what playtesters show and tell.
Understanding Failure
One thing is certain about the iterative game design process: failure is going to happen. This is a good thing, particularly early in the process, as it helps strengthen a game’s design. But there are also challenges that come with failure, as failures are often the cause for some of the conflicts that emerge during collaborations. Spotify’s Henrik Kniberg talks about not worrying about whose fault a particular problem is but rather what was learned from the failure and how the issue will be addressed.5 Keeping things constructive is always important. The iterative cycle is an excellent tool for constructively handling moments of failure. Looking back at the prototype and its playtest will often hold answers to these questions of what was learned and how it will be fixed.
5 “Spotify Engineering Culture (Part 2)” by Henrik Kniberg. https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/.
Of course, not all failures are alike. Design researcher Jamer Hunt describes the kinds of failure we might encounter and which ones are most productive in the design process:6
6 From Jamer Hunt’s Fast Company article “Among Six Types of Failure, Only a Few Help You Innovate.” www.fastcodesign.com/1664360/among-six-types-of-failure-only-a-few-help-you-innovate.
Abject failure: This is failure at its most final and devastating. For a game, this might be failure to meet your final goals or the team dissolving due to irreconcilable differences.
Structural failure: A failure, often technological. For a game, this might be bugs that make the game unplayable or a platform change that renders the game broken.
Glorious failure: A grand failure, or “glorious trainwreck”—a game that aims high and fails big, but in a way that provides valuable lessons or an exciting cultural moment.
Common failure: Everyday moments of messing up, such as the team not meeting deadlines or someone sleeping through a meeting.
Version failure: Bugs and glitches that lead to incremental improvement. This is often why we see so many updates on the App Store.
Predicted failure: This is the kind of failure we’re talking about when we talk about iterative design. We all know there will be failures in our prototype that our playtesting will reveal. This is the “good” kind of failure we need to happen to improve our game.
Early in the game design process, structural, common, and version failures are expected and welcomed. Throughout the process, predicted failures are desired, as they create safe places within which the team can experiment with limited risk. Glorious failures are sometimes needed to learn important lessons from taking large risks. Sometimes they are formative for the next project. Abject failure? It’s certainly the most foreboding of the kinds of failure. It’s also important to know that all of the best designers have, in some way or another, been through this kind of failure. However, it can certainly be mitigated if the team is open to failing early on in the process and addressing those failures.
Summary
Making games is often a collaborative effort—and collaboration is an art in and of itself. Creating an environment and set of practices that ensure everyone is engaged, has a say, and is contributing their best ideas and work to the project involves planning and thought. Strategies to manage disagreements like consensus decision-making, writing team agreements, and using tools to help everyone track meeting results and action items will go a long way to ensuring that your game is the best it can be.