> For the complete documentation index, see [llms.txt](https://docs.marioded.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.marioded.com/use-reverse/recorder.md).

# Recording gameplay

Capture gameplay, choose who owns the recording, and understand the save result.

**Install on:** the gameplay server · **Command:** `/reverserecorder` · **Permission:** `reverse.admin`

Use the recorder to capture the world where a match happens. Start with a named recording, stop it when the scene is finished, and wait for the saved replay ID.

{% code title="A simple recording" %}

```
/reverserecorder start --name "Arena final"
/reverserecorder stop
```

{% endcode %}

## What starts a recording?

Install the recorder on the gameplay server. A recording starts through `/reverserecorder start` or an API call from another plugin. Reverse does not automatically know when your minigame starts or ends: integrate those match lifecycle events using the [recording API](/api-how-to-guides/recording.md).

Each session has its own UUID, start tick, owner list, event stream, and terrain identity. Recording the same world twice creates separate recordings rather than overwriting the first one.

## Capture scope

The command records the current world. API integrations can additionally specify:

* A spatial bounding box, to isolate an arena within a larger world.
* A set of participant UUIDs, to select players without using ownership as a capture filter.
* Independent concurrent sessions in one world.

Owners define who can see/manage the finished recording. They do not select the captured players. Bounded capture and participant selection are API features; there are no corresponding command flags in the current recorder command.

{% hint style="info" %}
**Owners are viewers, not a capture filter.** Add owners to grant access to the finished replay. Use the API's participant selection when you need to choose which players are recorded.
{% endhint %}

## Initial scene and terrain

Reverse saves the starting scene along with the recorded actions. The chunk capture radius defaults to 4. Only terrain currently loaded by the server can be captured; Reverse does not generate a whole world for the recording.

Consequently:

* Start while the relevant arena chunks are loaded.
* Test the scene you expect a viewer to see, including locations away from players.
* Raising the radius cannot recover terrain that was never loaded or captured.
* A spatially bounded recording can still contain full-height chunk payloads for horizontally intersecting columns.

See [terrain](/configure-and-customize/terrain.md) for the separation between initial chunks and timeline block changes.

## Templates

Use `--template arena` only when `arena` is a template that the playback terrain provider can serve. An explicit template bypasses runtime terrain capture and points the recording at that template's terrain identifier.

Template names are trimmed; blank means no template. They are not inferred from the live world's name. Do not add `template:` or `slime:` prefixes. For SWM, make the exact template available through a configured loader on the replay server too.

Changing template terrain later changes the base scene available to replays that reference it. Treat published templates as versioned assets operationally, for example `arena-season-2`, rather than overwriting a template name used by old replays.

## Saving and failure outcomes

`stop` unregisters the live session and saves asynchronously. There are three important outcomes:

| Outcome     | Interpretation                                                                                          |
| ----------- | ------------------------------------------------------------------------------------------------------- |
| Saved       | Events and usable terrain/template reference are available.                                             |
| Degraded    | Events were saved, but terrain capture/finalization failed. The replay may load without its base world. |
| Save failed | Event persistence failed; do not advertise the recording as available.                                  |

A stop event is not a saved event. Match integrations should publish a “watch replay” link only after save completion, and handle degraded terrain explicitly.

## Supported content and practical limits

Recordings include supported player/entity movement, equipment and animations, block changes, chat, sounds, and visual effects. The exact result depends on your game and supported Minecraft version.

Reverse is not a video recorder. Custom plugin screens, resource-pack animations, and some sounds heard by only one player may not appear in a replay. Make a short test recording of your game's important mechanics before relying on it for match reviews.

## Recommended match workflow

1. Load/prepare the arena.
2. Determine participant UUIDs and replay owners separately.
3. Start recording before the first meaningful game event.
4. Store the returned session ID in your match object.
5. Stop that exact session on match end, cancellation, and plugin shutdown paths.
6. Wait for save completion before exposing the replay ID.
7. Keep failure logs with the replay ID for support.

## Next steps

* [Find every recorder command](/use-reverse/commands.md).
* [Watch and control a saved replay](/use-reverse/player.md).
* [Start recordings automatically from your minigame](/api-how-to-guides/recording.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.marioded.com/use-reverse/recorder.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.