“So, how many people will we need to build this game?” is a question that we hear often from the clients. If this question is asked too early in the conversation, even the best professionals won’t be able to answer.
There are so many details that affect the team size and structure: the scope, the style, the genre, the amount of content, the platforms it needs to run on, and whether the game is meant to end at release or keep evolving over time. A small mobile game can be built by a handful of people. A large open-world title can involve hundreds, sometimes more. The difference isn’t just budget or ambition. It’s how much content the game requires and how long it needs to be supported after release.
That’s why we can only answer that client’s question when we know enough details about their idea. If you want to understand more about what shapes game development team, read on.
Average Game Development Team Size
There’s no universal standard, but if you look across real projects, the ranges are fairly consistent.
| Game type | Typical team size |
| Hyper-casual / simple mobile | 2–10 |
| Indie | 5–20 |
| Mid-core / AA | 20–80 |
| AAA | 100–500+ |
These numbers come from a mix of developer interviews, postmortems, and production data. There have been successful games created by a one man team, and there have been others that involved over 1000 people (we’ll see the examples later).
The important part is not the exact number. It’s the pattern. As soon as the scope grows – more assets, more systems, more platforms – the team expands to support it.
And in most modern projects, that expansion doesn’t happen only inside one studio. It usually includes external teams as well.
How Team Size Actually Breaks Down
aying “a team has 50 people” doesn’t tell you much on its own. What matters more is how those people are distributed. The most common pattern has the largest share of the art department, followed by engineering, then QA and design. Production and support roles usually stay smaller but still critical.
Here is an average team breakdown in percentages
| Role | Share of team |
| Art (2D, 3D, animation, VFX) | 30–50% |
| Engineering | 20–35% |
| QA | 10–20% |
| Design | 5–15% |
| Production / management | 5–10% |
This isn’t a strict rule, but it shows how production is usually weighted. The exact structure shifts depending on the project. A multiplayer game will have more backend engineers. A narrative-heavy title may rely more on design and writing. But the general pattern tends to stay the same.
Once you look at teams this way, the size starts to make more sense. It’s not just a number – it’s a reflection of how much content and complexity the game requires.
Why Art Teams Are Usually the Largest
If you look at most game teams, one pattern shows up pretty quickly – art takes the biggest share. It’s not because art is “more important” than other parts. It’s because of how the work scales.
A lot of systems in a game are built once and then reused. Gameplay logic, tools, core mechanics – they take time to build, but they don’t multiply in the same way. Content does.
Every character, environment, prop, animation, UI element – each one has to be created separately. And as soon as the scope grows, that number increases fast. An open-world game doesn’t just need one environment. It needs dozens of locations, each filled with unique or semi-unique assets.
That’s where the difference comes from. If a feature is reused, it doesn’t require more people. If content grows, it does.
That’s also why art production tends to take a large share of the budget. Industry estimates often place art and content creation at around 30–40% of total development cost, which reflects both the amount of work and the number of people involved.
There are ways to manage that – modular assets, reuse, outsourcing – but they don’t remove the core problem. They just make it manageable. At a certain point, if a game needs more content, it needs more artists.
How Team Structure Changes by Game Type
The same team breakdown doesn’t apply equally to every project. The structure shifts depending on what the game actually needs.
In smaller projects, especially indie or mobile, roles tend to overlap. One person might handle multiple responsibilities – design, implementation, even parts of art or QA. That’s not just a budget decision. It’s often the only practical way to move quickly with a small team.
Let’s take Undertale as an example. It’s a small story-driven RPG about a child who falls into an underground world of monsters. Its author, Toby Fox, went on Kickstarter with his idea and raised about $50,000. That was a good support for the start, but not enough to hire a traditional team. Toby wasn’t a professional developer or game designer, but he decided to do what he could by himself – design, writing, programming, and a large part of the music.
He invited people for some parts of work like character art, testing, and polishing. But most of it was done by him. For an indie game, it has an additional benefit – that unique wholeness that is so easy to lose with big teams and maintains naturally when the author works (almost) alone.
In larger productions, the opposite happens. Roles become more specialized. Instead of “an artist,” you get environment artists, character artists, technical artists, lighting artists. The same goes for engineering and design. The team grows not just in size, but in structure.
In Hades, a roguelike action game, the team was still small enough that people stayed close to the work, but roles were already more defined. You’re not doing everything anymore, but you’re also not isolated into one narrow task.
Hades – Official Animated Trailer
Then at the top end, it’s a different setup entirely. A big and cinema-like game (for instance, The Last of Us Part II) is built in layers. Environment art, character animation, lighting, gameplay systems – each handled by separate teams, often working in parallel.
The Last of Us Part 2 – Official Cinematic Trailer
By the time something reaches the final build, it’s already passed through multiple hands. A scene might start with level design, then get dressed by environment artists, adjusted by lighting, tested for gameplay, and refined again after that.
At that point, the work isn’t just about making something good. It’s about making sure nothing breaks when all those pieces come together.
So the shift isn’t only about size. It’s about how much coordination the project can handle before it slows itself down.
How Teams Start to Expand
There’s a point where doing everything yourself just stops working. Not because of skill, but because there’s too much to build.
That’s where projects like Hades sit. It’s not a massive production, but it’s already beyond what one person could reasonably manage. There are too many moving parts – weapons, abilities, enemies, dialogue – all tied together. At that point, the only way forward is to start splitting the work.
At that stage, roles start to separate almost naturally. Someone focuses on combat feel, someone else on character art, someone else on code. But it’s still close enough that changes happen quickly. If something doesn’t work, it gets adjusted without going through layers of approval.
The difference is noticeable. It’s no longer one person deciding everything, but it’s also not a full production machine yet. Things are still flexible, just not entirely centralized.
How Team Structure Changes as Projects Grow
There’s another shift that happens when teams get bigger, and it’s not about skills or roles. It’s about time.
With a small team, changes happen quickly. If something feels off, you fix it and move on. There’s very little overhead.
As soon as more people get involved, that changes. Work has to be aligned. Decisions need to be shared. Even simple adjustments can take longer, because they affect more parts of the project.
That’s why larger productions feel so much different from small ones in so many ways. On some AAA-style open-world RPG with hundreds of quests and a huge world, you don’t have one team building everything in sequence. Work happens in parallel. While one group is building locations, another is writing quests, and another is working on gameplay systems.
The difficulty isn’t making those parts. It’s making them meet in the same place without breaking each other. At that scale, you don’t just fix things directly. You make sure the fix doesn’t break something else.
That’s usually the trade-off:
👉 Smaller teams move faster but have limits on scope.
👉 Larger teams can build more, but they spend more time making sure everything fits together.
Why Adding More People Doesn’t Always Speed Up Development
It sounds obvious – if something is taking too long, add more people. In practice, that only works up to a point.
With small teams, most of the time is spent building things. There’s very little overhead. Decisions are quick, changes happen immediately, and everyone knows what’s going on.
As soon as the team grows, that balance shifts.
More people means more coordination. Once work is split across people, things stop being straightforward. Work stops being isolated pretty quickly. Things start depending on each other. A small change stops being small once it touches something else. You fix one thing, then check what it affects, then check that again. It adds steps you didn’t have before.
At some point, adding more people doesn’t really move things forward. New people need context first. Until they have it, someone else has to spend time bringing them in. The work shifts around to make space, and instead of going faster, it just gets more fragmented.
You see it most when several teams are working on pieces that connect. Nothing is fully isolated anymore, so everything has to be kept in sync. The problem isn’t just making those parts – it’s making sure they still fit once they come together.
That’s why teams don’t scale in a straight line. More people doesn’t mean the work finishes proportionally faster. It just shifts the effort into coordination.
How Teams Are Changing Today
If you look at how teams are built now compared to even five years ago, the structure is less fixed.
More work is being distributed. Teams are often spread across locations, sometimes across time zones, and not everything is handled internally anymore. Outsourcing has become a regular part of production, especially for art and content-heavy areas.
There’s a simple reason for that. Content demand keeps growing, but keeping a large team in-house all the time isn’t always practical. So instead of scaling permanently, studios scale when they need to.
At the same time, tools are changing how work is done. AI is starting to reduce time spent on repetitive tasks – things like iteration, cleanup, or early variations. It doesn’t replace roles, but it shifts where time is spent.
Another noticeable change is the growth of LiveOps. Games are updated after release much more frequently, which means teams don’t shrink once the game ships. They keep working on the game after release – adding content, adjusting balance, running events. That part has become normal.
GDC reports have been pointing in that direction for a while. More time is now spent after launch, not just before it. Games don’t really “finish” the same way they used to.
So instead of a fixed team that builds something and moves on, the setup becomes more flexible. Teams expand when there’s more work, scale back when things slow down, and shift depending on what the project needs at that moment.
Modern Team Structure = Hybrid Teams
Most teams aren’t fully in-house anymore. What you usually have now is a core group – design, engineering, key art direction – and then a wider circle around it. External artists, QA teams, porting specialists, sometimes entire feature teams working from the outside.
It’s not a temporary setup. It’s how projects are built. Part of it is practical. Keeping a large team permanently in-house doesn’t make sense if the workload changes over time. Art needs spike, then drop. QA ramps up closer to release. Some tasks are only needed for a short period. Instead of trying to keep all of that internally, studios keep a smaller core and scale around it.
That’s where the hybrid structure comes from. Internal team handles the direction and key systems. External teams handle volume, specialized work, or specific phases. The boundaries aren’t always visible, but the split is there.
Most larger projects today follow this model in one form or another. The “team size” you see from the outside is usually just part of it.
Where Outsourcing Fits
Nowadays, outsourcing is not something that’s added on top when the work gets too ugly for the core team. It becomes part of how the team is built. Studios keep a smaller core group and bring in external teams when they need to scale or cover specific areas. That allows them to stay focused on key systems while scaling production in areas that require volume.
Art is the most obvious example. It’s one of the most resource-heavy parts of development, and also one of the easiest to scale externally. Rather than building a large internal team for a limited period, studios can work with external partners to handle asset production.
Outsourcing also helps with specialization. Some tasks require very specific skills – certain types of animation, technical art, or platform-specific work. It’s not always efficient to keep those roles in-house full time.
In that sense, outsourcing doesn’t replace the team. It extends it and brings various opportunities to the production, such as:
- scale production without permanently increasing team size
- handle large volumes of content more efficiently
- bring in specialized expertise when needed
And in larger projects, it’s often the difference between keeping production manageable and letting it slow down under its own weight.
Conclusion
If you step back, team size is only part of the picture. What matters more is how the work is structured.
Small teams move fast because everything happens in one place. Larger teams can build more, but they spend more time keeping things aligned. And most modern projects sit somewhere in between, adjusting their structure as production moves forward. What keeps coming up in game production is that headcount on its own doesn’t say much.
A team of ten might be enough for one kind of project and completely unrealistic for another. It’s not really about the number itself – it’s about what the project ends up requiring. Some games are mostly systems, others are mostly content. Some are built to ship and be done, others are expected to keep changing after release.
Because of that, teams don’t stay the same for long. Early on, it’s usually about getting the core working. Later, the weight shifts toward content, testing, and making sure everything holds together as more pieces are added. Closer to release, QA and polish take over. After launch, the focus can shift again if the game is being supported further.
So the team you start with is rarely the one you finish with. Early on, you might need more design and engineering. Later, art, QA, or LiveOps starts taking more space. Some roles fade out, others appear, and outside support gets pulled in when the workload spikes.So the real question is usually not “how big should the team be?” It’s “what kind of work is this game going to create, and when?” And that’s usually what determines whether production stays manageable or starts to slow down.
