Overview

Create simulated players from an active ScenarioContext. They belong to that execution and start disconnected. Each name must be unique among the players currently registered in the context.

Use these clients in an automated journey or create them in an environment's setup hook when a human-run scenario needs prepared participants. A real Minecraft client you join from is separate from these code-controlled players.

1. Create and configure a player. Offline players are the default.
2. If the journey needs an online account, configure authentication.
3. Use capabilities to connect, observe arrival, and perform actions.
4. Release players when their work is complete, or let scenario teardown release them. Connection changes are covered by Session.

Tests and embedding applications receive a ScenarioContext through JUnit or an embedded engine. A setup hook instead receives ScenarioAccess, which exposes the same player and process services without owning context closure. Choose the surrounding workflow separately from the player behavior.

A player is a network client, so asynchronous effects need explicit waits. A connected session proves login completion; to await arrival on a named backend, watch that backend's Players capability before the action and wait for the join. The backend's own agent reports that join. Assert application state separately.