Skip to main content

​
Example gallery

Copy a complete pattern, then adapt it to your game’s lifecycle. Each page explains the runtime it needs and includes the Java class to put in your own integration. These are integration examples, not plugins to install together. They deliberately omit command registration and application-specific match storage. For a guided first example, follow Creating your first recording. It builds FirstRecordingPlugin progressively before the bounded match example below adds arena selection.

Record a match

Recorder: start bounded capture and handle asynchronous save results.

Open a replay

Player: check catalog access, load a recording, and handle playback completion.

Add custom controls

Player: register a menu action and a hotbar item with explicit cleanup.

React to lifecycle events

Save notifications and playback stop events, with the right threading.

Record a milestone

A shared custom payload, its codec, recorder insertion, and player renderer.
New to the API? Complete Setting up first. Examples are integration building blocks rather than ready-to-install plugins.
Use Java 21 and add the matching public API from Maven Central as shown in Setting up. Declare the needed runtime plugin names in your integration descriptor. Do not eagerly load role-specific bindings on a server that lacks that role. Everything needed to understand each example is included on its page. You do not need access to Reverse’s implementation to use it. Important adaptation points:
  • Store recording IDs in your own match state and stop sessions on every match teardown path.
  • Add overlapping-request cancellation/identity handling to a real asynchronous Watch UI.
  • Confirm the hotbar slot is free and your namespace does not replace another extension.
  • Allocate codec IDs deliberately; register once per runtime service, before use/load.
  • Keep callbacks short; a compile check does not simulate a Bukkit server or validate game-specific behavior.