Roles in a game studio: who does what

A game studio is a small set of very different jobs held together by one shared goal, and the boundaries between them are looser than the job titles suggest. Understanding who does what, and where the overlaps fall, is useful whether you are applying for a role or trying to work better with the people already around you.

Design

Designers decide what the player is trying to do and how the game tells them whether it is working. Their craft is not in ideas but in structure: the shape of a loop, the pacing of a session, the clarity of a failure. A good designer can describe the game's core in a sentence and knows exactly which of the player's expectations each screen is answering.

Design overlaps with almost everything. A designer who ignores data will tune the wrong thing, and one who ignores engineering will ask for the impossible. The best design work we have seen comes from people who understand both and still argue for the player's experience above either.

Engineering

Engineers build the thing and keep it standing. Their work is invisible when it is right and obvious when it is wrong, which makes it easy to underestimate until something breaks. Beyond writing code, they decide how the game behaves under real conditions, how it loads, how it recovers from a lost connection, and how a change today will sit six months from now.

Engineering is where a game's honesty is enforced. A designer can imagine a fair loop, and it takes an engineer to make sure the code actually delivers it at the moment of play. When the two disagree, the disagreement is usually worth having, and the player is the one who benefits from it.

Art and audio

Artists and sound designers make the game legible and give it a feel that no description captures. In a casual game, clarity outranks beauty: an icon that reads at thumbnail size, a sound that tells the player they succeeded without looking. Style is a decision that has to serve the moment of play first.

The strongest art in casual games tends to be restrained rather than elaborate. A scene that pulls the eye away from the interaction is working against the design, however lovely it is on its own. Judging art by how it helps the loop, not by how it looks in isolation, is a habit that improves every project.

Data and analytics

The data role is to turn behaviour into something a team can act on. That means designing events carefully, asking a small number of good questions, and reading the numbers alongside what players actually do. It is a role that only works when the analyst is close enough to the game to see what the figures cannot.

• Write events that map to real decisions.
• Answer questions the team is about to act on.
• Pair every number with the behaviour it describes.
• Say when the data cannot answer something.
• Keep the game, not the dashboard, in the conversation.

Analysts who can say I do not know, here is what would tell us are worth more than analysts who always produce a figure, because confidence is cheap and trust is not.

Marketing and community

Marketing brings the right players to a game and represents it honestly to them. Community work keeps the relationship alive afterwards. Both roles live or die on their candour: an ad that overpromises buys a disappointed player, and a community that is answered dishonestly loses the trust it took years to build.

These roles overlap most with design, because the promise an ad makes is a design promise and the questions a community asks are design questions. Studios that keep them separated end up with a game and a message that disagree, which players notice long before anyone adds it to a chart.

Where the roles overlap

The table below shows how the main roles sit next to each other in a small studio, and which neighbouring discipline each one tends to lean on most. The overlaps are not boundaries to defend; they are the places where good work actually happens.

Choosing a role, and outgrowing one

Most people who last in games start in one discipline and slowly grow across two. That is normal in a studio like ours, where a role is a starting point rather than a cage. What matters is that you know the discipline you are strongest in and can still hold a conversation with the ones next to it.

If you are choosing a path, pick the discipline whose daily problems you find interesting, not the one with the clearest titles. The people who thrive here are the ones who enjoy the ordinary work of the role, not just the idea of having it, and that enjoyment is what carries someone through the long middle of a difficult project.

One team, many crafts

A studio is at its best when each craft respects what the others know. Designers who trust engineers, engineers who trust data, and everyone who trusts the player's experience over their own preference: that is the whole thing, and it is harder to build than any feature. Roles divide the work; the shared goal is what makes the divided work into a game.