Dytbaat Games · making good games greatCopenhagen, Denmark · game design, data and growth

Home › Services

Game audits: finding what holds your game back

Services · 18+ · Dytbaat studio
Game audits: finding what holds your game back

A game audit is a structured look at a game that is not performing as well as its makers hoped, with the goal of finding the few changes that matter most. It is not a review and not a score. It is a working document that names what is holding a game back and puts the fixes in an order worth following, starting with the ones a small team can actually ship.

What we look at first

We start where the player starts. The opening minutes decide whether anyone sees the rest of the game, so the tutorial, the first loop and the first reward are examined before anything deeper. A beautiful endgame is irrelevant if almost nobody reaches it, and most struggling games have their largest problem closer to the door than the team expects.

Game audits: finding what holds your game back

From there we work outward: the shape of a session, the reasons a player returns, the clarity of failure, and the way the game explains itself. Each of these is checked against how the game actually behaves rather than how the team believes it behaves.

What you give us

An audit works best when we can see the game as a player does and see the data as the team does. The more honestly both are shared, the sharper the findings, and we are comfortable working with messy or partial information as long as we know it is partial.

  • A playable build, on the platform the game targets.
  • Whatever event or retention data the team already collects.
  • The team's own view of where the problems lie.
  • The goals the game is being measured against.

We would rather see an ugly truth than a tidy summary. A build with known bugs and honest numbers tells us far more than a polished demo and a confident story, because the audit is only as useful as what it is allowed to see.

How the audit runs

We play the game ourselves, several times, in the way its real audience would play it. Then we read the data, then we play again with the data in mind. The two readings correct each other: data shows what happens, and play shows why. We avoid drawing conclusions from either alone, because a number without a cause is not yet a finding.

The table below sets out what an audit covers and what we deliver at each stage. It is the same shape whether the game is a small indie title or a live product with a back catalogue.

StageWhat we examineWhat you receive
First readOpening minutes and first loopAn honest early impression
PlaySessions, failure and returnNotes tied to moments in play
DataEvents and retention shapeWhere behaviour and belief differ
FindingsThe ranked list of issuesA prioritised, written report
Follow-upThe changes you chooseA second look at the results

What you get back

The deliverable is a written report, not a slide deck. It names each issue in plain language, explains the evidence behind it, and ranks the fixes by the effort they take against the difference they could make. We separate the changes we would make tomorrow from the ones worth considering later, so the document can guide a busy team rather than overwhelm it.

We also say clearly what is working. A studio under pressure tends to fix what is in front of it and leave the good parts alone, and naming those parts protects them from being redone out of fatigue. An honest audit is as much about what to keep as what to change.

The order we recommend changes in

Ranking matters more than the list itself. We sort fixes by how much they affect the player's experience against how much work they demand, and we put the early-session problems at the top almost every time. A change that lifts the first minute reaches every player, while a change buried late reaches only the few who stay.

This ordering is deliberately conservative. We would rather recommend three changes that will land than ten that will not, because a team that finishes a short list builds confidence and momentum for the next one. An audit that becomes a backlog served to nobody has failed, however accurate its findings.

When an audit is the right spend

An audit suits a game that has a real audience and a real problem, or a prototype the team believes in and cannot see clearly anymore. It is less useful when the game is still discovering its core loop, because the findings would change before they could be acted on. Knowing which stage a game is at is often the first useful judgement we can offer.

If a game is not yet ready for an audit, we say so and suggest a smaller piece of work instead. The point is never to sell the biggest engagement; it is to move the game forward, and sometimes that means waiting for the game to catch up to the question.

An honest second opinion

Most studios that hire us already suspect what is wrong. What they lack is the time, the distance or the permission to say it out loud. An audit gives a team an outside voice that can name the uncomfortable thing in writing and rank it against everything else. Often the value is not in the discovery but in the confirmation, and in the plan that turns a suspicion into a change someone can ship.

How we work. Every engagement starts with measurement: we look at how your game actually behaves before we suggest a change. We give honest, evidence-based advice, and we would rather tell you that a feature is working than push a rework you do not need.

Read next

Services

Monetisation strategy for free-to-play games

Designing offers and pricing that respect players and still pay for development.

Services

User acquisition: reaching the right players

Campaign structure, channel choices and how we keep spend honest.

Services

Live-ops: running a game after launch

Content cadence, events and the operational habits that keep a live game healthy.