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:
| Section | What to write | Why the studio needs it |
|---|---|---|
| Pitch | One or two sentences on the game and who it's for | Sets the frame for everything else |
| Genre and references | Two or three existing games, and what you take from each | The fastest way to share feel, scope and quality bar |
| Platforms | Where it launches first, and where it might go later | Each platform adds controls, UI, testing and store rules |
| Core loop | What the player does every minute, in one sentence | Decides most of the systems to build |
| Scope | Prototype, vertical slice or full game | Decides the size of the first contract |
| Art style | References, 2D or 3D, style versus realism | Art is often the largest cost line |
| Monetisation | Premium, ads, in-app purchases or a mix | Adds SDKs, store rules and economy design |
| Multiplayer | None, leaderboards, turn-based or real-time | Real-time multiplayer is close to a second product |
| Budget and timeline | A range, and any fixed dates | Lets the studio fit scope to what you can spend |
| Ownership and NDA | Who owns what, and confidentiality needs | Settled 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:
| Scope | What it is | What it answers |
|---|---|---|
| Prototype | The core mechanic playable with placeholder shapes and minimal UI | Is it fun? Does the main idea work? |
| Vertical slice | A small part of the game, such as one level or one area, at close to final quality: art, audio, UI, effects and performance | What will the game look and feel like, and what does each unit of content cost to make? |
| Full game | All content, platforms, monetisation, QA and store submission | Ready 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.
# 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
- App Review Guidelines — Apple Developer
- Payments policy — Google Play Console Help
- Google Play Families policies — Google Play Console Help
Need a hand?
Want this done for your project?
Explore our game development services, hire Unity developers, or see our software house in Lahore page.
Start a project