Author Archives: David Mullich
Roles On A Game Development Team
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:
- What did you do yesterday?
- What will you do today?
- 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.
What Makes A Video Game Good?
We’ve all played games that we thought were really, really good, and some that were not so good. What is it that separates the two? Of course the “good” ones are fun to play, but what makes them fun? Let’s take a look at the principles that a game must adhere to for it to be a good experience for the player.
The game must successfully deliver the player experience expected and desired by the player based upon the game’s premise, genre, competition, and marketing. Jason Vanderberghe, in a talk he gave at the 2012 Game Developers Conference, cited 5 parameters that can be used to define the player experience.
- Novelty: The degree to which the game provides new or unexpected experiences versus familiar ones. I will also add to this, the immersive experience of the player feeling that he or shed is another person or another place, and what that person/place is.
- Challenge: The degree to which the “work” the player needs to reach the game’s goals is difficult. I will also add that the challenge is also the balance of mental, physical and chance-based skills required to overcome the conflicts or obstacles that stand in the way of achieving the game’s goals.
- Stimulation: The degree to which the game provides emotional stimulation (suspense, fear, humor) versus a calming experience.
- Harmony: The degree to with the player must interact with other players (real or game-controlled) in either competitive or cooperative scenarios.
- Threat: The degree to which the player is exposed to (imaginary) danger or potential humiliation versus having no risk of losing progress or self-esteem.
In additional, all of the game’s elements must be designed to create that player experience.
The game’s core mechanic — that is, the action that the player most often performs in a game — is evergreen. It is as fun to do the 1,000th time as it is to do the first time.
The game’s rules must be easy to understand. If that game is complex — that is, it has many rules — the game only requires the player to learn the basic rules at the beginning of the game and then introduces additional rules as the player progresses.
The game should ideally be deep; that is, the game provides with interesting choices to make regardless of their skill level. In other words, the game is difficult to master.
The difficulty of overcoming the game’s conflicts should increase as the player’s skill level improves throughout the game, depending on what level of challenge is required by the player experience. If the game is designed for casual players, then the conflicts should be relatively easy to overcome. If the game is for hardcore players, the challenges should be relatively difficult to overcome.
The game’s goals have the following qualities:
- They are clear to the player.
- They are obtainable; that is, the skill required to meet them is not hopelessly beyond the player’s skill level and the player is provided with sufficient information and resources for achieving them. Ideally, players have multiple ways for achieving their goals.
- They are worthy of obtaining; that is, achieving them rewards the player by progressing the player to the game’s conclusion, providing the player with a valuable resource necessary for meeting other goals, and/or advances the game’s story.
- They relate to the game’s premise and to each other in a meaningful way.
- Once a players achieve goals, the player is presented with new goals. Ideally, the player also has multiple choices of goals to pursue at any point in the game.
The game’s outcome (such as whether a player will win or lose) must be uncertain to the players throughout the game. The game should be balanced so that there is no dominant winning strategy or resource.
There should be no missing elements in the game through any of the game paths that might lead to dead-ends or loopholes that the players can exploit.
Finally, and obviously, the game must not have anything that gets in the way of making it fun to play. The game should not require players to do the same tasks over and over without any visible signs of progress, require the player to either micromanage resources or not have sufficient resources, present the player with arbitrary events that can adversely effect game progress or choices that have no positive effect on progress, or have predictable paths or insurmountable obstacles. However, the only way to determine whether the game is fun is to playtest it over and over again with play testers who are representative to the target player, as it all comes back to meeting the expected play experience.
David Mullich 