Join Game
Response
Indicates if the player was successfully created
Unique player identifier (random decimal string)
Example
The player ID is a random decimal string generated using
Math.random(). Store this ID for all subsequent API calls.Assign Mokepon
Path Parameters
The unique player ID obtained from the
/join endpointRequest Body
Name of the Mokepon to assign. Valid options:
Hipodoge(Water 💧)Pydos(Water 💧)Capipepo(Plant 🌱)Tucapalma(Plant 🌱)Ratigueya(Fire 🔥)Langostelvis(Fire 🔥)
Response
Indicates if the Mokepon was successfully assigned
Example
Error Cases
- 400 Bad Request: Missing
playerIdormokeponName - 404 Not Found: Player ID doesn’t exist in the active players list
Remove Player (DELETE)
Path Parameters
The unique player ID to remove from the game
Response
Indicates if the player was successfully removed
Description of the operation result
Example
Remove Player (GET - Beacon API)
Path Parameters
The unique player ID to remove from the game
Response
Indicates if the player was successfully removed
Description of the operation result
Example
This endpoint uses the same logic as the DELETE endpoint but accepts GET requests to support the Beacon API, which typically uses GET or POST methods.
Implementation Notes
Player Storage
Players are stored in an in-memory array on the server:Player Class Structure
Each player is instantiated from thePlayer class with the following properties:
CPU Regeneration Logic
The server checks if human players remain active after each player removal. The regeneration logic (player-management.mdx:280):
- Removes all existing CPU players from the players array
- Generates 3 new CPU Mokepons with random selections
- Assigns random positions spread across the map
- Initializes each CPU with a standard attack set
Mokepon Type Detection
When a Mokepon is assigned, its type is automatically determined by thegetMokeponType() function (player-management.mdx:105-119) based on the character name.