Summary
Game development is a team activity: even small indie games typically require skills across programming, art, design, audio, and production. Sellers (Advanced Game Design, Ch. 11) treats teams as hierarchical systems governed by the same principles as game systems — parts (individuals), loops (communication), and emergent wholes (team culture and output). Understanding how teams are structured, what makes them succeed, and how they fail is as much a design skill as understanding mechanics.
(Sellers, Advanced Game Design, see source-advanced-game-design)
The Game Outcomes Project
The Game Outcomes Project (Tozour, 2014) is the most rigorous empirical study of game development success factors available. Tozour surveyed approximately 300 completed commercial game projects, measuring both outcomes (critical reception, financial performance, team satisfaction) and development practices, then analysed which practices correlated with better outcomes.
The top success factors, in approximate order of impact:
| Rank | Factor |
|---|---|
| 1 | Clear, compelling, consistent, and shared vision |
| 2 | Focused development — limited feature scope |
| 3 | Cohesive, collaborative team |
| 4 | Limited crunch |
| 5 | Swift and effective conflict resolution |
| 6 | Strong and experienced leadership |
| 7 | Effective use of iterative development |
| 8 | Adequate resources and time |
Shared vision as the #1 factor: the project that everyone agrees on — what the game is trying to be, who it is for, what experience it delivers — is a stronger predictor of success than budget, team size, or prior studio success. Vision failure manifests as scope creep, design by committee, and inconsistent player experiences.
Limited crunch as the #4 factor: projects with limited crunch produced both better-received games and happier teams. This directly contradicts the industry assumption that crunch is a necessary driver of quality. The data suggests the opposite: sustained crunch degrades decision-making quality, introduces bugs, and reduces the team’s capacity for the creative problem-solving that quality games require. See also game-industry-realities for the full crunch data.
Conflict resolution: unresolved conflict is a systemic failure — it creates feedback loops where disagreement spreads, trust degrades, and communication breaks down. Teams that resolve conflict quickly (not by suppressing it, but by actually resolving it) outperform teams that let conflict fester.
“An idea is not a design. A design is not a prototype. A prototype is not a game. A game is not a shipped game. A shipped game is not a successful game.” — Sellers, Advanced Game Design, Ch. 11 (on maintaining clear vision through each stage)
Sellers’ three team principles
Sellers proposes three foundational principles that must characterise team members and team culture for the team to function as a healthy system:
Integrity
Acting in accordance with your stated values; doing what you say you will do; being honest about the state of your work. For a game team, integrity means:
- Honest progress reporting (not hiding red status to avoid difficult conversations)
- Following through on commitments without being chased
- Raising problems early rather than hoping they resolve themselves
- Crediting others’ contributions accurately
Integrity failures compound quickly in creative teams because trust, once broken, is slow to repair. A single pattern of overpromising can poison a team’s ability to rely on estimates, cascade into late deliveries, and damage the shared vision.
Flexibility
The ability to adapt to new information, changing requirements, and unexpected obstacles without losing coherence. Sellers explicitly frames flexibility as the team-level analogue of second-order-design: just as a good game adapts to the player, a good team adapts to the game’s evolving needs.
Flexibility does not mean changing direction arbitrarily — it means:
- Being willing to cut features that are not working rather than defending them because of sunk cost
- Bringing skills outside your core role when the team needs it
- Treating the original plan as a hypothesis, not a contract
Rigidity vs. flexibility: the most common team rigidity pattern is discipline silos — programmers who refuse to weigh in on design, artists who treat performance as someone else’s problem. High-functioning teams have blurry boundaries between roles at the margins.
Communication
Information flowing freely, accurately, and appropriately to everyone who needs it. Communication in a game team includes:
- Regular, honest status updates (stand-ups, sprint reviews — see sprints)
- Clear articulation of the shared vision in terms every discipline can use
- Constructive critique: specific, actionable feedback rather than vague approval or rejection
- Escalating blockers early rather than solving them alone in ways that create downstream problems
Communication as a system property: Sellers notes that communication failures are not individual failures — they are structural failures. If important information is not reaching the people who need it, the team structure is wrong, not the individuals.
Studio hierarchy
A commercial game studio of moderate size (50–200 people) is typically organised as follows. This is the structural context in which the principles above operate.
C-suite and leadership
| Role | Responsibility |
|---|---|
| CEO (Chief Executive Officer) | Overall studio direction; external relationships; final authority on major decisions |
| COO (Chief Operating Officer) | Day-to-day operations; resource allocation; hiring |
| CFO (Chief Financial Officer) | Financial health; budget approval; P&L (see game-industry-realities) |
| CTO (Chief Technology Officer) | Technology direction; engine choices; technical standards |
| CCO (Chief Creative Officer) | Creative vision across all projects; consistency of aesthetic and design identity |
In small studios, one or two founders carry multiple C-suite functions informally.
Vice Presidents and General Managers
VPs and GMs own a product line, a major department, or a studio within a larger publisher. They translate C-suite strategy into execution targets and manage Executive Producers.
Executive Producers and Producers
Producers are the project management and team welfare layer. They own schedules, budgets, and team health.
Span of control: Sellers (following industry convention) cites a 1:10 producer-to-team ratio — one producer for approximately ten team members. Beyond this ratio, individual attention degrades and blockers go unresolved for too long.
| Role | Responsibility |
|---|---|
| Executive Producer (EP) | Owns the project from concept to ship; accountable to C-suite; manages Lead Producers |
| Lead Producer | Day-to-day schedule management; runs sprints; removes blockers for their sub-team |
| Associate Producer | Task tracking, meeting facilitation, asset tracking; often a junior role |
The producer role is frequently misunderstood as purely administrative. In practice, producers who understand the creative and technical challenges of their team are more effective at removing blockers, forecasting risk, and maintaining morale.
Design
| Role | Responsibility |
|---|---|
| Creative Director / Lead Designer | Owns the game’s creative vision; makes final design calls |
| Game Designer | Designs mechanics, content, levels; writes design documents |
| Level Designer | Designs individual levels, encounters, and spaces |
| Narrative Designer / Writer | Story, dialogue, world-building |
| UI/UX Designer | Interface design, user flow, accessibility (see ui-design) |
Programming
Programmers specialise by domain. Sellers’ categories:
| Specialisation | Domain |
|---|---|
| Gameplay programmer | Core mechanics, player input, game logic |
| Engine / systems programmer | Rendering, physics, audio, asset pipeline |
| AI programmer | Enemy behaviour, pathfinding, decision-making |
| Tools programmer | Internal editor tools, pipeline automation |
| Network programmer | Multiplayer, live-service backend |
| Graphics / shader programmer | Visual effects, rendering pipeline, performance |
Smaller studios collapse multiple specialisations into one role (“generalist programmer”). Unity-based indie and student teams typically have one to three programmers covering all domains.
QA (Quality Assurance)
| Role | Responsibility |
|---|---|
| QA Lead | Test planning; prioritising and communicating issues to production |
| QA Tester | Executing test plans; bug reporting; regression testing |
QA is often the most junior role but also one of the most knowledge-intensive: experienced QA testers understand the entire game system deeply enough to reproduce edge cases and to recognise regression patterns. See qa-and-bug-triage for the testing process.
Art and Audio
| Role | Responsibility |
|---|---|
| Art Director | Visual style; consistency across all art assets |
| Concept Artist | Early visual development; character and environment concepts |
| Environment Artist | 3D and 2D world-building assets |
| Character Artist | Character models, rigs, and textures |
| Animator | Character and environment animation |
| VFX Artist | Visual effects (particles, shaders, post-processing) |
| UI Artist | Visual implementation of interface designs |
| Audio Director / Composer | Music direction and composition |
| Sound Designer | Sound effects, audio implementation |
In Unity indie teams, art and audio roles are often handled by one generalist or outsourced. The most common gap in student projects is audio — it is the discipline most frequently treated as optional and most impactful when absent.
Team as a system
Sellers frames the team as a hierarchical system with the same structural properties as the games it builds:
- Parts: individuals with distinct skills, personalities, and goals
- Loops: communication channels, stand-ups, sprint reviews, design critiques
- Emergent whole: team culture, velocity, and creative output — properties not present in any individual
A team with clear vision, honest communication, and fast conflict resolution produces emergent capability that exceeds the sum of its individuals. A team with hidden agendas, unclear direction, and unresolved interpersonal conflict produces emergent dysfunction that no individual may be responsible for.
Practical implication: dysfunctional team behaviour should be diagnosed at the system level, not the individual level. If stand-ups are consistently unproductive, the problem is usually the meeting structure, not the people. If features are consistently over-scoped, the problem is usually the vision-clarity process, not individual designers.
Open questions
- The Game Outcomes Project data (2014) predates several major industry shifts: the rise of remote development, the post-2020 unionisation movement, and the widespread adoption of crunch-reduction policies. Do the top success factors still hold in this context?
- The 1:10 producer ratio assumes co-located teams with daily communication. How does the ratio change for remote or hybrid teams?
- Vision alignment is the #1 success factor, but vision is inherently subjective. What practical tools (design pillars, mood boards, playable references) most effectively translate shared vision into concrete decisions?
Related
- scrum-in-game-development — The operational method for team communication and iteration
- sprints — Sprint review as a shared vision checkpoint and communication mechanism
- game-industry-realities — P&L, crunch data, career tracks; the industry context for team decisions
- game-design-documentation — Documentation as a vision-communication tool
- vertical-slice — The vertical slice as a shared reference point for team vision alignment
- playtesting — Sprint Review as structured playtesting
- qa-and-bug-triage — QA role in the production pipeline
- source-advanced-game-design