Skip to content
Game Dev· 8 min read

How to Brief a Game Studio (Free Template)

What to put in a game development brief: genre, platforms, core loop, scope tiers, art, monetisation, multiplayer, budget and NDA, plus a free template.

Short answer

A good game brief fits on two pages: the genre and two or three reference games, target platforms, the core loop in one sentence, the scope you want first (prototype, vertical slice or full game), art style, monetisation, multiplayer needs, an honest budget range and timeline, and whether you need an NDA.

DSDevSnippetWeb, game, SEO & Google Ads studio

Why does a good brief matter?

A studio can only price what it understands. Send "a racing game like Forza but for mobile" and you'll get either a very wide estimate or a narrow one padded for everything nobody asked about. Send two pages that answer the questions below and you'll get a quote you can compare, plus better questions back.

Most of a game's budget is team size multiplied by time, as our guide to how much it costs to make a game explains. The brief tells a studio how big the team needs to be and for how long.

What should a game brief include?

You don't need a full game design document. You need enough to define the game and its limits:

SectionWhat to writeWhy the studio needs it
PitchOne or two sentences on the game and who it's forSets the frame for everything else
Genre and referencesTwo or three existing games, and what you take from eachThe fastest way to share feel, scope and quality bar
PlatformsWhere it launches first, and where it might go laterEach platform adds controls, UI, testing and store rules
Core loopWhat the player does every minute, in one sentenceDecides most of the systems to build
ScopePrototype, vertical slice or full gameDecides the size of the first contract
Art styleReferences, 2D or 3D, style versus realismArt is often the largest cost line
MonetisationPremium, ads, in-app purchases or a mixAdds SDKs, store rules and economy design
MultiplayerNone, leaderboards, turn-based or real-timeReal-time multiplayer is close to a second product
Budget and timelineA range, and any fixed datesLets the studio fit scope to what you can spend
Ownership and NDAWho owns what, and confidentiality needsSettled before you share details

How should you describe genre and reference games?

Name real games and say exactly what you're borrowing from each: "the driving feel of game A, the upgrade screen of game B, the session length of game C." Without that detail, one person's reference means the controls and another's means the art.

Also say what you don't want. "No open world, no story mode" removes more uncertainty from an estimate than another paragraph of features.

Which platforms should you target first?

Pick one launch platform if you can. Every extra platform brings its own input, UI layout, performance budget, store review and testing, and porting a game that already has players is lower risk.

If you have an engine preference, say why; if you don't, say so and let the studio recommend one. Our Godot vs Unity comparison explains how platforms, monetisation and the type of game usually decide the engine.

How do you describe the core loop?

The core loop is what the player repeats: the action, the reward and what the reward lets them do next. Write it as one sentence. For a mobile driving game, that might be "pick a delivery, drive it across the city against the clock, earn coins, upgrade the truck." For a puzzle game, "clear a board, earn stars, open the next set of levels."

We've shipped Unity driving, simulation and puzzle games on Google Play and the App Store, and in our experience the loop sentence is the most useful line in a brief. If you can't write it yet, start with a prototype.

Prototype, vertical slice or full game: what's the difference?

These three words get used loosely, so define which one you're asking for. This is how we use them:

ScopeWhat it isWhat it answers
PrototypeThe core mechanic playable with placeholder shapes and minimal UIIs it fun? Does the main idea work?
Vertical sliceA small part of the game, such as one level or one area, at close to final quality: art, audio, UI, effects and performanceWhat will the game look and feel like, and what does each unit of content cost to make?
Full gameAll content, platforms, monetisation, QA and store submissionReady to launch

Why do studios propose a vertical slice first for big ideas?

Because big ideas hide expensive unknowns. In an open-world driving game, nobody knows up front what a square kilometre of finished city costs, whether traffic and streaming hold a steady frame rate on a mid-range phone, or how long a mission takes to build. A full-game quote without those answers is a guess, and guesses get padded.

A vertical slice builds one district at final quality, with real traffic, real vehicles and one or two missions. That turns the unknowns into measurements. The studio can then quote the full game from what one district actually took, and you have something playable to show players, investors or a publisher. If the slice shows the idea is too expensive, you've learned it for a fraction of the budget.

What should you say about art style?

Send pictures, not adjectives: "stylised" covers everything from flat 2D to hand-painted 3D. Collect five to ten reference images, note what you like in each, and say whether you already have art or brand assets the game must match.

How should you describe monetisation?

Say how the game earns: a one-off price, ads, in-app purchases, a subscription or a mix. On the Unity mobile games we've shipped, ad mediation, the IAP catalogue, analytics events and the economy all had to be designed in from the start, not added at the end. Store rules shape the design too:

  • Digital items and currencies sold inside iOS apps must use Apple's in-app purchase (App Review Guidelines, 3.1.1), and Google Play requires its billing system for in-game digital goods, apart from specific regional programmes (Play Console Help).
  • Both stores require loot boxes and other paid random items to show the odds before purchase.
  • If children are in your audience, Google Play's Families policy limits you to self-certified ad SDKs and rules out personalised ads for them (Play Console Help). Say your target age in the brief.

Does your game need multiplayer?

Be specific, because "multiplayer" ranges from a leaderboard to a live competitive game. Leaderboards and cloud saves are modest work; turn-based play needs a backend but tolerates delay. Real-time multiplayer needs networking, servers, matchmaking and anti-cheat, plus hosting costs every month it's live. If multiplayer is a later idea, say so, and the studio can keep the architecture open for it.

How honest should you be about budget and timeline?

Completely. A budget range isn't a number for the studio to spend; it tells them which version of your idea to propose. The same brief can become a two-month prototype or an eighteen-month production.

The same goes for dates. If you need a build for a trade show, an investor meeting or a seasonal launch, put the date in the brief.

Should you ask a studio to sign an NDA?

It's a reasonable request, and a professional studio will sign one before you share the detailed brief. Send a short, non-confidential summary first. More important than the NDA is the contract: it should assign the code, art and other IP to you on payment, and keep the project's repositories and store accounts in your name.

Free game brief template

Copy this into a document, fill in what you know and mark the rest "not sure". An honest gap beats a guess.

markdown
# Game brief: [working title]

## Pitch
One or two sentences: what the game is and who it's for.

## Genre and references
- Genre:
- Reference 1: [game] - what we take from it:
- Reference 2: [game] - what we take from it:
- Reference 3: [game] - what we take from it:
- What we don't want:

## Platforms
- Launch platform(s):
- Later platform(s), if any:
- Engine preference (or "no preference"):

## Core loop
One sentence: action, reward, what the reward lets the player do next.

## Scope for this contract
[ ] Prototype   [ ] Vertical slice   [ ] Full game   [ ] Not sure
- Content at launch (levels, areas, characters, modes):

## Art style
- 2D or 3D:
- Reference images (links):
- Existing art or brand assets:

## Monetisation
[ ] Premium   [ ] Ads   [ ] In-app purchases   [ ] Subscription   [ ] Not decided
- Target age of players:

## Multiplayer
[ ] None   [ ] Leaderboards / cloud saves   [ ] Turn-based   [ ] Real-time

## Budget and timeline
- Budget range:
- Fixed dates (events, launches, investor meetings):

## Team and ownership
- Who on our side approves work:
- What we provide (design, art, audio, backend):
- NDA needed before full details: [ ] Yes   [ ] No

## Questions for the studio
-

What happens after you send a brief?

A good studio comes back with questions before a number. When we receive a brief, we ask about the parts that move the estimate most, recommend an engine and a first milestone, and usually propose a prototype or vertical slice before a full production contract.

If you have a brief ready, or half a brief and a lot of questions, our game development team works in Unity, Unreal Engine, Godot and HTML5. Send it to us and we'll tell you honestly what we'd build first.

Frequently asked questions

  • No. A full game design document is usually written during pre-production, often with the studio. A short brief is enough to get a realistic estimate and a proposed first milestone.

  • A small part of the game, such as one level or area, built to close to final quality in art, audio, UI and performance. It shows how the finished game will look and feel, and what each unit of content costs to make.

  • It's very unlikely; studios earn from building games, and ideas are worth little without execution. Still, ask for an NDA before sharing details, and make sure your contract assigns all IP to you on payment.

  • Yes, and it often works better. Share an honest range and the studio can propose the strongest version of the game that fits it, usually starting with a prototype or vertical slice.

  • Not necessarily. If you have a reason, such as an existing codebase or a team that knows one engine, say so. Otherwise describe the game and platforms and let the studio recommend an engine with its reasons.

Sources

  1. App Review Guidelines — Apple Developer
  2. Payments policy — Google Play Console Help
  3. Google Play Families policies — Google Play Console Help
Start a projectWhatsAppChat on WhatsApp