Why insist on a vertical slice before full production?

Because it is the only honest answer to whether the game is any good. A slice is one level built to final quality — art, audio, controls and feel — while the rest of the game does not exist yet. It is what a publisher or an internal sponsor looks at before committing the rest of the money, and it is what stops a year of art being produced for mechanics that turn out not to be fun.

It depends on the target and the team who will maintain it, and we will make a recommendation rather than a declaration. Unity tends to suit mobile and lighter builds and has a shorter path to a working prototype. Unreal tends to suit high-fidelity visuals and console work. The wrong reason to choose either is that it is the one somebody already has installed.

What drives the cost more than anything else?

Content quantity. Not engine, not platform, not how clever the mechanics are — how many levels, how many characters, how many minutes of audio and how many distinct assets. A single mechanic can be built once and reused across forty levels, and it is those forty levels that consume the budget. This is why the estimate is written against a content list.

Can AI write most of the game?

It can write a lot of the code, help with shaders, and take real time out of tooling and boilerplate. It cannot decide whether the game is fun. That judgement comes from watching people play, and there is no shortcut around playtesting — which is exactly why the schedule includes it as its own recurring activity rather than as a phase near the end.

What about console certification?

It is planned for from the start rather than met at the end. Each platform has its own technical requirements covering saves, suspend and resume, input handling, storefront behaviour and messaging, and a build that ignores them fails submission and returns weeks later. Certification time and at least one resubmission are in the schedule when console is in scope.

We are a brand, not a studio. Is a game the right thing to buy?

Sometimes. A small, well-scoped game around a campaign or a training objective can be genuinely effective. A large one, bought because it sounded good in a strategy deck, usually is not. The first conversation is about what the game is supposed to change, and if the answer is thin we will say so before anyone commits.

Immersive, 3D & Emerging Tech

Game development in Unity and Unreal, starting with a vertical slice

Playable first, pretty second — a proven prototype and a finished slice of the real thing before anyone commits a year of art production to a design nobody has tested.

From: $8,000–$200,000
Typical time: 4–18 months
Usually bought by: Studios, brands

What this actually solves

Three quite different buyers arrive at this service, and it is worth knowing which one you are, because they are buying different things.

A studio needs capacity. There is a project underway and a gap in it — levels to build, a port to another platform, an optimisation pass that keeps being deferred, a system nobody internally has time to write. The requirement is well defined, the technical direction already exists, and what is needed is someone who works inside an existing pipeline without disturbing it.

A brand needs attention, and has noticed that a game is something people choose to play while an advert is something they sit through. The mistake here is scale rather than concept — a small, tight, genuinely playable thing tied to one clear idea outperforms an ambitious one that ships late and unfinished.

An education or training organisation needs someone to actually complete a course, and knows that engagement is where their programme leaks. Turning a curriculum into something with progression, feedback and consequence is a real design problem, and it is the most reliably worthwhile of the three, because success is measurable in completion rather than in sentiment.

What all three share is the hardest requirement in this field, and it is not technical. It is fun, or in the training case, engagement. Nobody can specify it in a document in advance. It is discovered by putting a build in front of people who did not make it and watching what they do, which is why the process below is organised to find that out early and cheaply rather than late and expensively.

How the work runs

Design document and content list. What the game is, the core loop, what the player does the moment it starts, and then the itemised content — levels, characters, environments, audio. That second list is the budget in disguise, and writing it explicitly at the start is what makes the estimate mean something. Two to four weeks.
Grey-box prototype with no art at all. The core mechanics, playable, in untextured blocks. It looks like nothing and it answers the only question that matters at this stage — does the loop hold someone's attention. Cheap to change, cheap to throw away, and the single most valuable phase in the entire project. Three weeks to two months.
Vertical slice. One level built to shipping quality end to end — art, audio, controls, interface, feel. This is the milestone that internal sponsors and publishers make decisions against, and it is often contracted separately from the production that follows. It also calibrates everything downstream, because once one level has been finished properly, the cost of the remaining levels stops being a guess. One to three months.
Production. The content list from step one, built out against the pipeline the slice proved. Version control here uses tooling built for large binary assets rather than a standard code repository, because source art and audio files are enormous and a normal repository degrades into something artists route around. Playtesting continues throughout rather than waiting for a phase. Two to nine months.
Polish, optimisation and quality assurance. Frame rate on the actual target hardware, load times, control feel, the hundred small corrections that separate a finished game from a working one, and structured testing across the device range. Where console is in scope, this is also where the platform's technical requirements are met deliberately. One to three months.
Submission, launch and immediate support. Store assets, build submission, certification and the near-certain second submission, then the first weeks after launch when real players find what testing did not. Three weeks to two months.

What moves the price

The range is $8,000–$200,000 over 4–18 months, and it is that wide because a small mobile puzzle and a console title live under the same two words.

Content quantity. The dominant factor, by a distance. A mechanic is built once; the levels, characters, environments and audio that use it are built many times, and that repetition is where the money goes.

Target platform. Mobile-only is the cheapest path. PC adds a hardware range to support. Console adds certification, platform-specific requirements and dedicated testing, and it is the difference between one build and several.

Art direction. A committed stylised look can be produced consistently and efficiently. Photorealism multiplies the cost of every asset, every material and every lighting decision, and it also raises the performance floor. This decision is made early, and it is a budget decision as much as an aesthetic one.

What usually goes wrong

Full production starts before a slice exists. Levels are designed and art commissioned for a loop nobody has verified. When the loop turns out to need changing — and on a first project it nearly always does — the change invalidates months of finished work. The slice exists precisely so that discovery costs one level instead of a production's worth of them.

The content list is written once and never re-costed. A line in the design document reading twenty levels is the largest number in the budget, and it is usually the least examined. Every scope change should be quoted against that list, so that adding a character is a visible decision rather than a quiet one absorbed into the schedule.

Version control is set up as though this were a web project. A standard repository with no large-file handling meets its first serious batch of source art and becomes unusable, at which point artists start passing files around by other means and the project loses the ability to say what the current build contains. Choosing the right tooling on day one costs an afternoon; retrofitting it mid-production means migrating every asset across and losing part of the history.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Why insist on a vertical slice before full production?: Because it is the only honest answer to whether the game is any good. A slice is one level built to final quality — art, audio, controls and feel — while the rest of the game does not exist yet. It is what a publisher or an internal sponsor looks at before committing the rest of the money, and it is what stops a year of art being produced for mechanics that turn out not to be fun.
Unity or Unreal?: It depends on the target and the team who will maintain it, and we will make a recommendation rather than a declaration. Unity tends to suit mobile and lighter builds and has a shorter path to a working prototype. Unreal tends to suit high-fidelity visuals and console work. The wrong reason to choose either is that it is the one somebody already has installed.
What drives the cost more than anything else?: Content quantity. Not engine, not platform, not how clever the mechanics are — how many levels, how many characters, how many minutes of audio and how many distinct assets. A single mechanic can be built once and reused across forty levels, and it is those forty levels that consume the budget. This is why the estimate is written against a content list.
Can AI write most of the game?: It can write a lot of the code, help with shaders, and take real time out of tooling and boilerplate. It cannot decide whether the game is fun. That judgement comes from watching people play, and there is no shortcut around playtesting — which is exactly why the schedule includes it as its own recurring activity rather than as a phase near the end.
What about console certification?: It is planned for from the start rather than met at the end. Each platform has its own technical requirements covering saves, suspend and resume, input handling, storefront behaviour and messaging, and a build that ignores them fails submission and returns weeks later. Certification time and at least one resubmission are in the schedule when console is in scope.
We are a brand, not a studio. Is a game the right thing to buy?: Sometimes. A small, well-scoped game around a campaign or a training objective can be genuinely effective. A large one, bought because it sounded good in a strategy deck, usually is not. The first conversation is about what the game is supposed to change, and if the answer is thin we will say so before anyone commits.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Game development (Unity / Unreal) All Immersive, 3D & Emerging Tech services