This morning I conducted my second virtual classroom lecture hosted by Nepris. A teacher from a school in Austin, Texas requested that I speak to his class about working as a game development team. It wasn’t until the question-and-answer session that I did with the class after my talk that I learned that they were developing a game about pharmaceuticals for a university to demonstrated that high school kids could develop serious games. How cool is that?

However, it seemed they needed some pointers on how a game development team works, and here is a synopsis of what I told them.

Most games are not developed by an individual person but rather by a group of individuals working together as a team. The smallest team I’ve ever worked on consisted of three people (myself, serving as project manager and designers, plus a programmer and artist), while the largest team I’ve managed consisted of about 40 game developers. For the biggest AAA games, development teams can number in the hundreds.

The typical game development team is comprised of a project manager (also called a development director or producer) and the designers, programmers, and artists working under him or her. The game designer’s role is to take the game idea (which may actually come from someone else, especially if the game is a sequel or an adaptation of a licensed property) and expand it into a detailed description of how the game should work, including the game’s goals, conflicts that make achieving the goals challenging, resources that aid the player in achieving the goals, rules that define and limit the player’s actions, possible outcomes depending upon whether or not the player achieves the goals, as well as the premise and story that gives the game an immersive context. While the game design defines what tasks the other team members need to do, the game designer is not the team’s boss. It is the project manager’s responsibility to provide the team with direction and support, balancing the scope of the game design against the project’s time and budget constraints.

Obviously, the teams’ artists are responsible for creating the game’s art assets, which may have to go through a pipeline, or series of steps, to go from concept art to final asset. For example, a game character will need to be modeled, textured, rigged, animated and then perhaps compressed down to a size to fit within the game platform’s memory or download limits. The programming team is responsible for coding the game design in a computer language so that the game platform can present the game as well as all the game art and audio assets.

The team may also be supplemented by other individuals or groups to assist at different stages of development. For example, there may be middleware programmers responsible for programming development tools at the start of the project, art studios responsible for creating additional or specialty art assets (such as cut scenes involving motion capture), audio specialists responsible for creating the game’s music and sound effects, and quality assurance teams who test beta versions of the game to ensure that it is complete and working properly.

With so many people needing to do so many tasks, the project manager needs to run the team in a very efficient manner. One project development methodology that is very popular in the game development community is called Scrum, which is a Rugby term for restarting a game after a minor infraction.

A Scrum project in game development starts with the Product Owner (the person responsible for representing the customer) creating a prioritized list of features that must be created for the game. This list is called a Product Backlog, and once it is created, development begins as a series of Sprints. Each Sprint lasts for a specified time period (typically, anywhere from one to four weeks), during which the development team produces a demonstrable version of the game. Sprints are comprised of the following components:

• Sprint Planning Meeting: The entire team meets to decide what features from the Product Backlog they can implement during the upcoming Sprint. The team breaks each feature into tasks and determines who should do that task and how long it will take. It is vital that the person who is doing the task determines how long it will take him or her to do it. All of the features that the team agrees they can implement during the Sprint goes into a list called a Sprint Backlog.

• Daily Scrum: Each day of the Sprint, the team meets at the same time and the same place for a short meeting (usually 15 minutes). The person managing the Sprint, called the Scrum Master, asks the team members these three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any obstacles in your way?

  It is the Scrum Master’s responsibility to remove any obstacles that is standing in the way of a team member’s productivity.

• Sprint Review Meeting: The Scrum Master (and team) demonstrates the game to the Product Owner. The Product Owner then decides whether the game is ready to ship or whether another the development team should do another Sprint. If the ladder, the Product Owner may remove or reorder items on the Product Backlog.
• Sprint Retrospective Meeting: The team meets to discuss the past Sprint and determine any changes that need to be made to work together better for the next Sprint.

Of course, there are many other meetings that may take place during a game’s development (it seems half my time developing games is spent on meetings). There are meetings to make plans, solve problems, make decisions, reach consensus, receive feedback, report progress, or some combination. Having effective meetings require good meeting management skills:

• Before the meeting: Decide on the meeting’s purpose, format, length, and participants, and then circulate an agenda.
• During the meeting: Start the purpose of the meeting, allow everyone to express their opinions, keep off-topic conversation to a minimum, and end the meeting informing everyone of the next steps.
• After the meeting: Write up meeting notes, reach out to any participants who didn’t get heard or weren’t happy with the meeting results, send out any promised resources, and follow up on how the next steps are progression.

Managing the team as a whole throughout the length of the project also takes good people management skills as well as some flexibility. Here is how to handle a team during the phases of their work together:

• Forming: When the team first gets together, everyone may be unsure of their individual responsibilities and where they fit into the group as a whole. Therefore, at this initial stage, the team leader is in charge of making decisions. It is import that the team leader to demonstrate clear and strong, especially at this stage, to earn the team’s confidence and respect.
• Storming: Once the team has developed a sense of what is expected of them, they typically charge ahead enthusiastically. At this time, the team leader shifts to a coaching role, asking team members for their opinions but still making the decisions.
• Norming: As the team settles into their roles, the team leader may adopt a more supportive role, discussing issues with team members but allowing them to make decisions.
• Performing: By now the team is a well-oiled machine, and now the team leader can begin to delegate, allowing team members to make decisions without consulting the team leader.

The main point I stressed to the students that a good game development team is not run by a dictator. Teamwork, communication, consensus, and trust are as essential components of a good game, as are design, art, audio and programming.