# How to brief an endless runner
Source page: https://dfygames.com/guides/runner-brief (published 2026-10-19, updated 2026-10-19) · Topic: Endless runner games
Cite as: DFY Games, "How to brief an endless runner", updated 2026-10-19, https://dfygames.com/guides/runner-brief

**Quick answer:** Brief an endless runner by writing down the controls (each gesture and what it does), every obstacle with the move that beats it and how it is telegraphed, and how speed should rise over a run. Then judge the playable checkpoint on feel: whether a new player survives the first 30 seconds, whether deaths feel fair and whether near misses read as skill.

- Brief core: Controls, obstacles, speed curve
- Playable checkpoint: Core prototype, days 2-3
- Feedback: One owner, consolidated
- Package fit: Core for one environment

## A runner brief is about feel

Most runner briefs describe the theme and the characters at length and the controls in one line. Theme is easy to change at the art checkpoint; the way a swipe responds and the rhythm of obstacles is what players judge in the first ten seconds, and it is hard to describe after the fact. A good brief fixes three things in writing: controls, obstacles and the speed curve.

## The control blueprint

List every input, what it does and how forgiving it should be. Keep it to one thumb if you can: every extra gesture is something new players get wrong.

| Input | Action | Feel target | Annotation |
| --- | --- | --- | --- |
| Tap | Jump | Instant takeoff; fixed height | Holding for a higher jump is a second rule; leave it out unless the game needs it |
| Swipe down | Slide | Short slide, can cancel into a jump | Lets players fix a late decision |
| Swipe down in the air | Fast drop | Lands within a few frames | Makes jump-then-slide combinations possible |
| Input just before landing | Buffered jump | Accepted a moment early | Removes "I pressed it!" deaths |
| Tap on results screen | Retry | Back in a run within a couple of seconds | Restart speed matters as much as run speed |

> Write the forgiveness down: Our example concept makes hit boxes slightly smaller than the sprite, so a near miss reads as skill rather than luck. Rules like that, and input buffering, are invisible in screenshots and easy to lose unless the brief names them.

## The obstacle blueprint

For each obstacle, write the move that beats it, how the player is warned and when it first appears. The warning column is the one that decides whether deaths feel fair.

| Obstacle | Beaten by | Telegraph | First appears | Near-miss bonus |
| --- | --- | --- | --- | --- |
| Rooftop gap | Jump | Edge highlight, gap visible well ahead | First seconds, slow speed | Landing close to the edge |
| Hovering drone | Slide | Red scanning beam sweeps before it arrives | After the first gap | Sliding under the beam late |
| Laser fence | Jump | Fence flickers on with a sound cue | Once jump is learned | Clearing it at the last moment |
| Vent burst | Wait or jump | Steam puffs twice before firing | Mid-run | Passing just after it fires |
| Drone after a gap | Jump, then fast drop and slide | Both visible together | Late; never in the first minute | Chained near misses |

![The runner slides under a hovering drone's red scanning beam as a NEAR MISS times two label pops up](https://dfygames.com/media/games/rooftop-dash/near-miss.webp)

Add one line for combinations you never want, such as a drone placed directly after a gap at top speed. The spawner can be told to avoid them, but only if someone wrote them down.

## A reusable control and obstacle worksheet

Copy this worksheet into your own brief and fill in every line before checkout. If a line has no answer yet, that is the decision to make first.

Controls:
- [ ] Every input listed with the one action it triggers
- [ ] The whole game playable with one thumb, or a written reason why not
- [ ] A feel target for each input (instant, short, cancellable)
- [ ] Forgiveness rules named: input buffering, hit boxes smaller than the sprite
- [ ] Retry reachable with one tap from the results screen

Obstacles:
- [ ] Each obstacle has exactly one move that beats it
- [ ] Each obstacle has a warning cue the player can see or hear in time
- [ ] The order in which obstacles first appear, one new type at a time
- [ ] What counts as a near miss for each obstacle
- [ ] A list of combinations the spawner must never produce
- [ ] The total obstacle count kept small enough to describe in one table

## Describe the speed curve in plain words

You do not need numbers. Describe the run in phases and what the player should feel in each, and the developer turns that into values that get tuned in playtesting.

1. Opening: slow and readable; the first hazard is telegraphed early and the second rewards a near miss with a visible multiplier.
2. Build-up: speed rises steadily, new obstacles appear one at a time, gaps between them shrink.
3. Flow: combinations appear, near misses chain into a multiplier frenzy.
4. Ceiling: speed stops rising at a level that is hard but readable, so long runs end on mistakes rather than impossibility.

## Judge the playable checkpoint

In a Core build the playable loop arrives around days 2-3, before final art. It will look rough. That is the right moment to judge controls and obstacles, because changing them after art and effects are in costs time on both sides.

Playable checkpoint test (15 minutes, on a real phone):
- [ ] Hand it to someone who has not seen the brief: do they survive the first 30 seconds without being told anything?
- [ ] Play ten runs yourself: did every death feel like your mistake?
- [ ] Does a near miss feel different from a normal pass, with a visible reward?
- [ ] Is retry fast enough that you start another run without thinking?
- [ ] Do any two obstacles arrive together in a way you could not react to?
- [ ] Is the jump height right for the gaps, with no pixel-perfect jumps?
- [ ] Write one list of changes, ranked, from one feedback owner

> Feedback that slows a build down: Comments like "make it more fun" or five people sending separate notes are the usual cause of delay. Ranked, specific notes ("the second drone arrives too soon after the gap") get fixed the same day.

## Example: a one-page runner brief

Put together, a Core runner brief fits on one page. This is the version for our example endless runner concept, written the way a buyer could send it.

> One-page brief: neon rooftop runner: Audience: score chasers who play in short bursts. Hook: sprint across neon rooftops, slide under drones and chain near misses into a score multiplier. Controls: tap to jump, swipe down to slide or fast-drop, buffered input. Obstacles: gap, drone, laser fence, vent burst, introduced one at a time; never a drone straight after a gap in the first minute. Speed: slow opening, steady build, a ceiling that stays readable. Progression: local high score, daily best, skin unlocks that change the light trail. Monetization: one rewarded revive per run, cosmetic skins, interstitial only after the results screen. Look: neon skyline, high-contrast hazards, a rainy-night variant of the same city. Out of scope: other worlds, characters with powers, online leaderboards.

Notice what is missing: no story, no lore, no list of twenty characters. Those can come later if the runs feel good. The [launch checklist](https://dfygames.com/guides/mobile-launch-checklist) covers what happens after the build, from store assets to the first campaign.

![Results screen showing NEW BEST with the score, run stats and Retry and Continue buttons](https://dfygames.com/media/games/rooftop-dash/best.webp)

## What to leave out of a Core runner brief

Leave out anything that adds a system: extra worlds, characters with powers, missions, an upgrade tree, online leaderboards. If those are central to your idea, say so up front and scope Advanced; the [endless runner cost guide](https://dfygames.com/guides/endless-runner-cost) compares what each of them adds. If they are nice-to-haves, park them in a "later" list so the blueprint stays clean.

The [mobile game brief template](https://dfygames.com/guides/mobile-game-brief-template) covers the parts every genre shares (audience, references, monetization, store). When your control and obstacle tables are filled in, the [endless runner package](https://dfygames.com/games/endless-runner) is the next step.

## FAQ

**What should an endless runner brief include?**
The controls and what each does, every obstacle with its counter-move and warning cue, and a plain description of how speed rises over a run. Theme and art references come after that.

**Do I need to give exact speeds and timings?**
No. Describe each phase of a run and the feeling you want; the developer sets the values and tunes them in playtesting.

**When can I play the first build?**
In a Core build the playable loop is shared around days 2-3, before final art, so controls and obstacles can be adjusted early.

**How many obstacle types should a first runner have?**
A compact set that you can describe in one table, usually a handful. Every extra type multiplies the combinations that need testing.

**Who should give feedback on the playable?**
One person who collects everyone's notes and sends a single ranked list. Scattered feedback is the most common cause of delay.

## Related
- Service page: [Endless Runner Game development](https://dfygames.com/games/endless-runner)
- [Endless runner game development: cost and scope](https://dfygames.com/guides/endless-runner-cost)
- [Mobile game design document template: what to put in your brief](https://dfygames.com/guides/mobile-game-brief-template)

---
DFY Games (Done For You Games), https://dfygames.com. More guides: https://dfygames.com/guides · Index for AI assistants: https://dfygames.com/llms.txt