# Game developers

Plan playable milestones and turn playtest observations into work.

## Who it's for

Solo developers and small studios making a game. You plan around builds people can play, and most of your best input comes from watching playtesters.

## Recommended setup

Example: **Lanternfall**, a fictional 2D roguelike about climbing a changing tower.

| Piece | Example |
|---|---|
| Product context | Fifteen-minute runs, controls that feel immediate, deaths that feel fair |
| Areas | Combat, Movement, Level generation, UI, Audio |
| Releases | 0.1 Vertical slice → **0.2 Steam demo** (active) → 0.9 Early Access → 1.0 |
| First tasks for 0.2 | Add the second floor, tune hit feedback, add the first boss, build the demo end screen |

Name each release with a build number and the milestone it reaches, so the order and the goal are both clear. The active release is the build you're making playable now; anything you might cut stays in the Backlog until it earns a place.

"Combat" is an area because it lasts the whole game. "0.2 Steam demo" is a release because it ships once.

## A week in the loop

1. Pick up the next task in the active milestone from **What's Next**, or hand it to your agent with the task's implementation notes.
2. Play the result before marking it Done. A task is done when it works in the build, not when the code compiles.
3. Log what you see in playtests with **Capture** on the User Signals page: one signal per observation, such as "Players miss the dodge prompt on floor 2".
4. Once players have the build, share your [Feedback Portal](https://getfrostbyte.dev/docs/feedback-portal-overview) for bug reports.
5. Review signals weekly. When several point at the same problem, make one task and link the rest to it.

## Bug reports and playtest notes

Player reports and your own playtest notes land in the same queue. A report from the portal shows who sent it:

- A **Bug** from the **Portal**, sent by a player during the demo.
- Turn it into a task in the active milestone if it blocks a run, or leave it in the Backlog if it can wait.

A note you capture yourself shows **Manual** and where it came from:

- An **Observation** from a playtest, captured with **Capture** on the User Signals page.
- One signal per thing you saw. When three testers miss the same prompt, link all three to one task.

## Plan the next milestone

When the current build is nearly done, open the next release and decide what it must include to be playable.

1. Write the milestone's goal as the release description, such as "Two floors and the first boss, ready for Steam Next Fest".
2. Move tasks in from the Backlog with [bulk actions](https://getfrostbyte.dev/docs/views-and-filters#change-several-tasks-at-once). Start with the fixes your playtests turned up.
3. Cut anything that doesn't serve the goal back to the Backlog. A smaller build you can ship beats a bigger one you can't.
4. When the build is out, complete the release, publish its notes as patch notes and set the next one active.

## Features that matter most

- [Product](https://getfrostbyte.dev/docs/product): the game's pillars, so every task and agent works toward the same feel.
- [Signals](https://getfrostbyte.dev/docs/signals): playtest observations and player reports in one queue.
- [Releases](https://getfrostbyte.dev/docs/releases): one playable milestone at a time.
- [Tasks](https://getfrostbyte.dev/docs/tasks): subtasks and implementation notes for acceptance criteria. Your agent reads the notes with the task.
- [Connect your agent](https://getfrostbyte.dev/docs/connect-your-agent): your agent works in your Unity, Godot or Unreal project using the same plan. Every plan, Free included.

## Next steps

- [Quickstart](https://getfrostbyte.dev/docs/getting-started): create the project and your first task.
- [Product](https://getfrostbyte.dev/docs/product): write the pillars.
- [Signals](https://getfrostbyte.dev/docs/signals): set up playtest capture.
- [Release notes & changelog](https://getfrostbyte.dev/docs/release-notes-generator): publish patch notes for each build.