Event Handling

The game handler in Race Protocol is event-driven, meaning that it processes incoming events to update the game state and trigger corresponding actions. These events can be categorized into two main types:

• Custom Events: These are game-specific events defined by the developer to represent player actions, decisions, and other occurrences within the game. Examples include placing a bet in a poker game or choosing rock, paper, or scissors in a Roshambo game.

• Built-in Events: These are predefined events handled by the Race Protocol itself. They represent system-level actions and state changes, such as game initialization, player joins and exits, randomness generation, and settlements.

Processing Custom Events

When the game handler receives a custom event, it typically follows these steps:

• Deserialization: The event data is deserialized from its binary format into the corresponding custom event struct defined by the developer.

• Validation: The handler validates the event based on the current game state and rules. For example, it may check if the player sending the event is allowed to perform the action at the current stage of the game.

• State Update: If the event is valid, the game handler updates the game state accordingly. This may involve changing player attributes, transitioning to a different game stage, or triggering other game-specific logic.

• Effect Generation: Based on the updated game state and the nature of the event, the handler may generate effects using the Effectobject. These effects can trigger actions like revealing hidden information, assigning secrets, or initiating settlements.

Processing Built-in Events

Built-in events are handled by the Race Protocol itself, but the game handler may need to respond to them or perform specific actions based on the event type. Some examples include:

• GameStart: When the game starts, the handler may need to initialize game-specific data structures, generate randomness, and assign initial states to players.

• Join: When a new player joins, the handler may need to update player lists, adjust game state accordingly, and potentially trigger game start logic if enough players have joined.

• RandomnessReady: When the randomness generation process is complete, the handler can access the revealed random values and use them within the game logic.

• SecretsReady: When secrets are shared for revealing hidden information, the handler can decrypt the information and update the game state accordingly.

• Settle: When a settlement transaction is confirmed on the blockchain, the handler may need to update player balances and potentially trigger game-end logic.

Event Loop

In a real-world scenario, the Transactor server runs an event loop that continuously processes incoming events. This loop reads events from both the client and any pending dispatched events (e.g., timeouts) and passes them to the game handler for processing. The handler then updates the game state and potentially generates new events or effects, which are handled by the event loop and broadcasted to participants.

This event-driven architecture ensures that the game progresses smoothly and that all participants have a consistent and synchronized view of the game state.

By understanding how to define custom events and respond to built-in events, developers can build complex and engaging game logic on top of Race Protocol, leveraging the benefits of blockchain technology and a secure, transparent runtime environment.