How much does game development cost in the UK?

The core loop, logging a workout and getting XP for it, was quick. That part is a form and a calculation, and it worked within days. If we had stopped there we would have had a prototype in under two weeks, which is exactly the argument for building the prototype first.

The XP economy took far longer than the feature list implied. Deciding how much a workout is worth, how fast levels should arrive, and what stops someone logging nonsense to farm points, is balancing work that only playtesting answers. Every economy number is a guess until real people use it, and the tuning continued long after the code stopped changing.

Leaderboards were the biggest single underestimate. A leaderboard looks like a sorted list. A leaderboard that cannot be cheated means every score is verified on the server, which means the server has to understand the rules of the game, which means the game logic exists in two places and has to agree. That is a different project from displaying a list.

Seasons and collectible cards were content problems, not engineering ones. Building the system took a fortnight; filling it takes forever, because content is the cost that never stops. That is the single most useful thing we learned, and it is why the content-volume line sits at the top of the drivers above.

There is a right and a wrong way to make a game cheaper. The wrong way is keeping every feature and doing all of them badly, which produces something nobody enjoys for the same money.

Cut content before you cut quality. Five polished levels beat twenty rushed ones, and players will ask for more of something good long before they forgive something shallow.

Cut multiplayer first if it is not the point of the game. Asynchronous competition, meaning leaderboards and shared challenges, gives you most of the social feeling for a fraction of real-time multiplayer's cost.

Cut platforms. Launching on one, learning, then porting is cheaper and less risky than launching everywhere at once, and it lets you fix what the first audience finds before the second one arrives.

Do not cut the feel. The responsiveness, the animation timing, the sound on a successful action: this is what separates a game people play from a game people uninstall, and it is the last thing to economise on.

Games carry more uncertainty than other software, so the payment structure should reflect that. We quote each stage separately and you can stop between any two: prototype, then a vertical slice showing what the finished game looks and feels like, then content build-out, then release.

A project that stops after a prototype nobody enjoyed has cost you a prototype. That is a far better outcome than a finished game nobody plays, and it is the arrangement we would want if we were paying.

The game development page sets out what each stage includes, which project sizes we are right for, and where we use AI tooling and where we deliberately do not.