Blog

Game Development Team Roles: Who Owns What on Small Crews

By Lauren "Celeste" Rousell · November 6, 2026 · 10 min read

Game development team roles fall into four disciplines: design, programming, art, and production, plus supporting roles like QA, audio, and marketing. This guide maps what each role owns, then shows how the same role contracts, merges, or disappears as you scale from AAA down to a 2-8 person indie crew.

What are the core game development team roles?

Every studio, from AAA to a tiny crew, draws from the same set of discipline families. The IGDA's developer satisfaction surveys describe standard studio structures built around these functions, and the titles vary but the ownership lines stay consistent.

The seven discipline families

Design, programming, art, audio, production, QA, and business/marketing cover nearly every task on a game project. A 200-person studio splits these into specializations; a 4-person crew merges them into hats. Knowing the family a task belongs to tells you who owns it, even when nobody holds the title.

One-line ownership map

On a tiny crew, the producer hat usually lands on the studio lead, which is where a shared board like Inferno earns its keep. The sections below break down each family and how roles contract as headcount drops.

What does a game designer actually own versus a producer?

The designer owns what the game is: systems, mechanics, level flow, and the feel of play. The producer owns whether it ships: scope, milestones, and keeping people unblocked. Confusing the two is why a 5-person studio ends up with three designers and no schedule.

Designer ownership: systems, levels, and the paper design

The designer writes the paper design: the vertical slice spec, the economy numbers, the level layouts, and the rules that make the loop fun. Their deliverable is a decision, not a document. If a designer is only writing docs nobody reads, they are not owning the design; they are archiving it.

Producer ownership: scope, milestones, and unblocking

The producer owns the backlog, the milestone plan, and the daily reality of scope creep. Their job is cutting features before the build breaks, not after. On a tiny crew this is usually a hat worn by the studio lead, which is exactly the role a tool like Inferno is built to support: one board where scope decisions live next to the work they affect.

How do programming roles differ between engine, gameplay, and tools?

Engine and graphics programmers

Engine programmers work on the layer under the game: rendering, memory management, physics, and platform ports. Graphics specialists dig into shaders, draw-call budgets, and frame-time profiling. On Unreal or Unity projects, this role shrinks to configuring and extending the engine rather than writing one, which is why most small studios never hire for it separately.

Gameplay programmers

Gameplay programmers own the code the player actually feels: character controllers, combat systems, AI behavior, and UI logic. Studio job listings treat this as the most common specialization; Rockstar's careers page, for example, lists gameplay programming as a distinct discipline from engine work (Rockstar Games careers). On a 2-8 person crew, this is usually the lead programmer's hat.

Tools and pipeline programmers

Tools programmers build the editors, importers, and build scripts that keep everyone else shipping, while pipeline work connects DCC exports to the engine. Many studios fold this into a tech-lead role who also owns code review and architecture. Whoever holds it should log every change against a named task, not a "fixed stuff" commit; see how we compare options in Inferno vs Codecks.

What does the art pipeline hierarchy look like from concept to final asset?

Concept to production art

A concept artist sketches characters, environments, and props to lock the visual direction before production ramps up. Once approved, 2D or 3D artists translate those sketches into final assets: sprites, models, textures, and materials. On a 2-8 person crew, one artist often does both, which works until the backlog of unpolished concepts collides with the milestone build. That collision is a pipeline problem, not a talent problem, and it is the same handoff tracking that pushes teams off Trello (see Inferno vs Trello).

The technical artist bridge

The technical artist sits between art and code, writing shaders, rigging models, and optimizing draw calls so assets survive the jump from DCC tool to engine. Small crews usually fold this hat into a programmer's workload. The risk is silent: nobody notices until a shipped asset tanks the frame rate.

Animation and VFX

Animators bring rigs to life with movement and cutscenes; VFX artists handle particles, explosions, and feedback effects. Both arrive late in the pipeline, so scope creep here hits the ship date first.

What non-development roles (QA, audio, marketing, community) does a team need and when?

QA and playtesting

On a AAA team, QA is a dedicated discipline with leads and testers at several seniority tiers, tracked in industry salary surveys like Game Developer's annual salary report. On a 2-8 person crew, nobody is a QA specialist: everyone plays every build, and playtesting shifts to friends, Discord volunteers, and festivals around each milestone. The discipline still exists, it just lives inside everyone's week.

Audio, marketing, and community

Audio is the non-development role most likely to be a real hire or contractor, because it demands a skill none of your artists or coders have. Marketing and community start as the studio lead's Twitter account and grow into a part-time hire once you have a demo or vertical slice worth showing.

When to add each

Add audio help before your first public build, community around a Steam page, and QA effort at every milestone crunch. If tracking these hats is getting messy across tools, see how Inferno compares to HacknPlan for keeping roles visible on one board.

How do job titles map differently at AAA versus indie studios?

AAA: deep specialization

A AAA studio splits every discipline into narrow titles: a technical designer, a VFX artist, a sound designer, a tools programmer, a producer per department. Each role owns a slice of the pipeline and hands off to the next. The tradeoff is coordination overhead, which is why AAA teams need dedicated producers just to keep handoffs moving.

AA: partial merging

AA studios merge adjacent roles first. A technical artist covers shader work and pipeline glue. A senior designer absorbs some production duties. One producer serves multiple disciplines instead of one per department. Specialization survives where the pipeline demands it, mostly in art and code, while planning and communication roles consolidate.

Indie 2-8: the hat-merge map

At a tiny crew, the same game development team roles still exist as work, but almost none exist as titles. Here is the honest way to think about it: the role isn't a person, it's a hat, and one person wears four or five. Your gameplay programmer is also your tools programmer, your QA department, and the person who fixes the build at 11 PM before a milestone. Your artist owns concept, production art, VFX, and probably UI.

Your designer is the producer, the writer, and half your marketing. The failure mode isn't wearing too many hats, it's not naming which hat you're wearing when you do the work. If a task says "fixed stuff" with no role attached, nobody can tell whether it was code, design, or art, and Monday becomes archaeology. Name the discipline on every card, merge the hats deliberately, and a two-person crew covers the same ground a AAA org chart does, just with fewer handoffs and no one to blame but each other.

Which roles can be merged or dropped on a small indie team?

Safe merges for a tiny crew

Design and code merge cleanly when one person owns both a feature and its implementation. Art and audio can sit with one person if your pipeline is mostly bought assets or simple shaders. QA belongs to everyone: every discipline tests the build before a milestone, so it needs no dedicated hat until you near ship.

Merges that go wrong

Producer and programmer is the merge that breaks. When the person fixing the build also decides what ships, "fixed stuff" happens: no one wrote down which backlog item the commit served, and Monday morning turns into archaeology through Discord and half-remembered standups. The 11 PM broken-build problem is usually a missing producer hat, not a missing engineer. Keep someone accountable for scope and milestone tracking even if it's a part-time role.

Solo and game-jam versions

Solo, you merge everything but must externalize the producer: a public backlog with dates. Tools built for this exist, including Codecks, which positions itself around game teams and combining task management with design documentation. Write the merge map down before the vertical slice, not after.

How should a tiny crew assign and track roles without scattered tools?

One owner per discipline, one board per milestone

Map each role from this article to a name, even when one person holds three hats: "Alex owns Code, Audio, and QA." Then give every milestone its own board with columns that match your pipeline, not a generic kanban template. A vertical slice board might run Design, Blockout, Implementation, Polish, and Ship. When the build breaks at 11 PM before a milestone, the owner column answers "whose system is this?" without digging through Discord threads.

The failure mode to avoid is splitting: tasks in Trello, decisions in Discord, design docs in Google Docs. That's how scope creep hides and "fixed stuff" commits happen.

Where Inferno fits, and where it doesn't

Inferno is built for exactly this: one workspace where planning, build tracking, and design notes live together for a 2-8 person crew. It shines when your problem is scattered tools, not process complexity. It falls short if you need deep discipline-specific pipelines like HacknPlan's art task breakdowns, or Codecks' card-deck model your team already loves. If Trello plus Discord already works, don't migrate for its own sake.

FAQ

Is a game producer the same as a project manager?

Not exactly. A producer owns scope, milestones, and the backlog, including creative tradeoff calls like cutting features before the build breaks. A project manager tracks schedule and process without deciding what the game contains. On a tiny crew, the producer hat usually lands on the studio lead, which is why a shared board earns its keep.

What role should I hire first when expanding my indie team?

Usually a second programmer or an artist, depending on your bottleneck. Audio is often the first contractor hire because it demands a skill none of your artists or coders have. Marketing and community only become a part-time hire once you have a demo or vertical slice worth showing publicly.

Do solo game developers need to learn every discipline?

You wear every hat, but you don't need mastery of each. Learn enough design, code, art, and audio to ship, then lean on bought assets and contractors for the gaps. The one role to externalize is the producer: a public backlog with dates keeps scope honest.

What is the difference between a technical artist and a tools programmer?

A technical artist sits between art and code, writing shaders and optimizing draw calls so assets survive the jump from DCC tool to engine. A tools programmer builds the editors, importers, and build scripts that keep everyone else shipping. Small crews usually fold both hats into a programmer's workload.

How many people do you need to make an indie game?

Two to eight covers most small crews, and solo developers ship games too. The seven role families still exist as work even when nobody holds the title; one person just wears four or five hats. What matters is naming which hat you're wearing per task and keeping someone accountable for scope.