You commission twelve enemy sprites from a freelancer. Three weeks later the art arrives: beautiful, consistent, and unusable. The characters are 30% taller than your player, the pivot is centred instead of at the feet, there is a soft drop shadow baked into every frame, and the files are layered PSDs named enemy_final_v3_NEW.psd. Nobody did anything wrong. You just never wrote down what "done" meant.
A brief is not paperwork you produce to look professional. It is the document that decides whether a commission costs you one round of revisions or four, and whether the art you paid for can be dropped into the build the day it arrives. For a small team, that difference is often a month.
What a brief actually has to do
An asset brief has one job: make the deliverable verifiable by someone who is not an artist. If you cannot look at the returned file and answer "does this meet the brief, yes or no" without a conversation, the brief is incomplete.
That means it contains more than taste. A mood board tells the artist what the thing should feel like. A brief tells them what the file has to be. You need both, and they fail in different ways — a beautiful reference board with no technical section produces art you have to repaint, and a precise spec with no reference produces art that matches the engine and nothing else in your game.
The six blocks
Keep every commission brief to the same six sections. Consistency matters more than length; an artist working on their fourth batch for you should know exactly where to look for the canvas size.
1. Context. Two or three sentences on the game and where this asset appears. "Top-down pixel-art dungeon crawler. These are the tier-2 enemies for the sewer biome, seen from a fixed 3/4 angle, usually 2–4 on screen at once." The last clause matters: an artist who knows four of these will be on screen together will not give each one a unique silhouette-breaking hat.
2. Technical spec. Numbers only, pulled from the build rather than from preference.
| Field | Value |
|---|---|
| Canvas | 48 × 48 px, transparent |
| Character height in frame | 32 px (matches player) |
| Pivot / origin | bottom-centre |
| Palette | project palette, 24 colours, no new hues |
| Outline | 1 px, #1b1b26, no anti-aliasing |
| Shadow | none baked in — engine draws it |
| Animations | idle 4f, walk 6f, attack 5f, hurt 2f |
| Frame rate | 12 fps |
| Delivery | PNG sprite sheet, one row per animation, plus source file |
| Naming | enemy_sewerrat_walk.png |
3. Reference. Use the three-image rule: one image for silhouette and proportion, one for palette and lighting, one for rendering finish — the level of detail and line quality you expect. Then add the section most briefs skip: anti-reference. One or two images with a sentence on why they are wrong. "Not this: too much texture detail, reads as noise at our zoom level." Negative examples cut more revision rounds than positive ones, because they rule out whole directions the artist might otherwise explore for a week.
4. Deliverables. A literal list of files you expect to receive, with counts. "6 sprite sheets (one per enemy), 6 source files, 1 contact sheet PNG showing all idle frames side by side." If you want the source files, say so in the brief, not after delivery.
5. Revision policy. Say how many rounds are included and what a round is. A workable default: two rounds included, where a round is one consolidated set of notes from you, delivered within three working days of receiving the asset. Changes that contradict the approved brief — "actually make them side-view" — are a new commission, not a revision. Write that sentence down before you need it.
6. Acceptance criteria. Three to six checkable statements. "Imports into the engine with no resize. Reads at 100% zoom on a 1080p screen. Uses only project palette colours. Idle loops seamlessly." This is the section that lets you approve work in ten minutes instead of a meeting.
Buy one before you buy forty
The single highest-value change you can make to how you commission art is to pay for one complete asset first, pushed all the way through your pipeline, before approving the batch.
One asset, in the engine, animating, next to the player character, on the real background. Not a flat image in a chat window. You will discover in that one pass whether the outline weight survives your camera zoom, whether the palette holds up against your tileset, whether the walk cycle matches your movement speed, and whether your importer chokes on the sheet layout. Every one of those is cheap to fix once and expensive to fix across forty files.
The same logic applies to audio and to music: commission one footstep set or one 30-second loop, get it into the build with your mixer settings applied, and only then order the rest.
Money, milestones and the boring lines
You do not need a legal department, but you do need four things in writing, in the same place as the brief:
- Scope and price. Per-asset or per-batch, stated as a number.
- Payment schedule. A common structure for a batch: 30% on signing, 40% on approval of the test asset, 30% on final delivery. Milestones tied to approvals, not to dates, keep both sides honest.
- Rights. State plainly that you receive the right to use the work in the game and its marketing, commercially, in perpetuity — and whether the artist may show it in their portfolio. The answer to the portfolio question should almost always be yes, and saying so in the brief costs you nothing.
- Credit. How their name appears in the credits, and the spelling they want.
Agree these before the first asset, because the moment to negotiate rights is not the week you are building your store page.
Keep the brief where the design lives
The reason briefs go stale is that they live in a chat thread. The technical spec is a copy of your real metrics, the reference board is a folder someone shared once, and the revision notes are scattered across three messages and a voice note.
If you already keep your characters, items and locations as structured entries, brief from those entries rather than from memory — the canvas size and palette belong next to the asset they describe, and a mood board attached to the same entry is the reference block, not a separate artefact. In GameDesignerX this is why mood boards sit alongside character and item entries, and why a commission tends to work best as a milestone with one task per asset: each task holds its own brief, revision count and approval state, so "which of the twelve are actually signed off" is a glance rather than an archaeology project.
Pre-send checklist
Run this before the brief leaves your hands:
- Canvas size, pivot and character height stated in pixels (or units)
- Palette attached as a file, not described in words
- Frame counts and target frame rate for every animation
- Exactly what files you expect, with counts
- At least one anti-reference with a reason
- Number of revision rounds and what a round means
- Three to six acceptance criteria you could check yourself
- Test-asset milestone before the batch
- Price, payment schedule, rights, credit
- A named person who answers the artist's questions, and how fast
Failure modes worth recognising
| Symptom | Usual cause | Fix in the brief |
|---|---|---|
| Art needs resizing on import | No canvas or height spec | Technical spec table |
| Style drifts across a batch | Reference given per asset, not per set | One reference block for the whole set |
| Endless revision rounds | No acceptance criteria | Checkable criteria + round limit |
| Artist waits on you for days | No named contact or response window | Response SLA in the brief |
| Can't tell what's approved | Approvals in chat | One task per asset with a state |
None of this makes the art better. It makes the art arrive — correct, once, in a state your build can use. On a three-person team that is the same thing as making the game better, because the weeks you save repainting sprites are weeks you spend on the game nobody else can make for you.