# Azura Custom Gaming Modules In this section, we will introduce the custom gaming modules developed by Azura, such as Player Profiles, Matchmaking, State Channels, Asset Management, Game State Management, etc. Each module provides a comprehensive overview of its functionalities and is accompanied by conceptual-level sequence diagrams for key operations. ## Player Profiles Module The `Player Profiles` module is designed to capture all the essential data related to each player, such as storing player statistics, achievements, and rankings. The main procedures for carrying out the key operations are outlined below, ensuring that every detail about a player's performance and accomplishments are recorded and maintained. ### Profile Retrieval ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgGetPlayerProfile Module->>Keeper: GetPlayerProfile(address) Keeper->>Store: Get profile data Store-->>Keeper: PlayerProfile<br>{ statistics,<br>achievements,<br>rankings, ... } Keeper-->>Module: Return PlayerProfile, found Module-->>Client: Return player profile data ``` This diagram presents how to retrieves a player's profile. The `Client` sends a `MsgGetPlayerProfile` request to the `Module`, which then calls `GetPlayerProfile` on the Keeper with the player's account address. The `Keeper` asks the `Store` for the profile data using this account address. The `Store` sends back the profile data (e.g., statistics, achievements, rankings), which the `Keeper` processes and forwards to the `Module`. The `Module` finally returns the profile data to the `Client`, completing the cycle. ### Profile Update ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgUpdateProfile Module->>Keeper: UpdatePlayerProfile<br>(fields) Keeper->>Store: Get profile data Store-->>Keeper: Existing profile Keeper->>Keeper: Update profile fields Keeper->>Store: Save profile data Store-->>Keeper: Confirm storage Keeper-->>Module: Return success Module-->>Client: Return result ``` This diagram explains how to update a player's profile. First, the `Client` sends a `MsgUpdateProfile` request to the `Module`, which forwards it to the `Keeper` via the `UpdatePlayerProfile` function. The `Keeper` gets the player's existing profile from the `Store` with the account address, updates and saves it back to the `Store`. The `Keeper` then reports success to the `Module`, which informs the `Client` of the result. ## Matchmaking Module The `Matchmaking` module is designed to create a robust and efficient system that facilitates the seamless connection of players in multiplayer games, ensuring a fair and competitive gaming experience. By leveraging advanced algorithms, this module aims to optimize the process of pairing players based on their skill levels, preferences, and availability. The conceptual procedures for the key operations are outlined below. ### Match Creation ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgCreateMatch Module->>Keeper: CreateMatch(player, metadata) Keeper->>Keeper: generateUniqueID<br>{metadata, timestamp} Keeper->>Store: Save matchID<br>and matchData Keeper-->>Module: Return matchID Module-->>Client: Return result ``` This diagram depicts the match creation process. It begins when the `Client` sends a `MsgCreateMatch` to the `Module`. The `Module` calls the `CreateMatch` method of the `Keeper` with necessary details like `player` and `metadata` (e.g., skill levels, preferences, availability). The `Keeper` generates an unique ID and stores the match data in the `Store`, and then returns the match ID to the `Module`, which passes it back to the `Client`. This sequence ensures the match is created, recorded, and confirmed within the system. ### Match Joining ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgJoinMatch Module->>Keeper: JoinMatch(player, matchID) Keeper->>Keeper: Player matching algorithm<br>to choose a match ID Keeper->>Store: Get matchData<br>by matchID Store-->>Keeper: matchData Keeper->>Keeper: Update match data Keeper->>Store: Save match data Keeper-->>Module: Return success Module-->>Client: Return result ``` This diagram demonstrates the match joining process. The `Module` receives the `MsgJoinMatch` request and forwards it, along with player info and `matchID`, to the `Keeper`. The `Keeper` uses a matching algorithm and checks the `Store` for current match data. After updating the match data with the new player, the `Keeper` saves the updated data back to the `Store`. The `Keeper` then confirms the successful join to the `Module`, which informs the `Client` of the result. ## Asset Management Module The `Asset Management` module is a component that provides NFT-like functionality for in-game assets. This module empowers game developers to create, delete, and transfer unique digital assets within their games. The following outlines the conceptual procedures for the key operations of asset management. ### Asset Minting ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgMintAsset Module->>Keeper: MintAsset(owner, metadata) Keeper->>Store: Get asset count Store-->>Keeper: Asset count Keeper->>Keeper: Generate new asset ID Keeper->>Keeper: Create asset data Keeper->>Store: Store asset data Store-->>Keeper: Confirm storage Keeper-->>Module: Return result, success Module-->>Client: Return result ``` This diagram highlights how to mint a game asset. The process starts with the `Client` sending a `MsgMintAsset` message to the `Module`. The `Module` instructs the `Keeper` to mint the asset with details like owner and metadata. The `Keeper` queries the `Store` for the current asset count, generates a new asset ID, creates an asset data, and stores the data in the `Store`. After storing the data, the `Keeper` sends a success response to the `Module`, which then informs the `Client`. This process ensures the asset is properly minted and recorded. ### Asset Burning ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgBurnAsset Module->>Keeper: BurnAsset(owner, assetID) Keeper->>Store: Get asset data Store-->>Keeper: Asset data Keeper->>Keeper: Verify ownership Keeper->>Store: Delete asset data Store-->>Keeper: Confirm storage Keeper-->>Module: Return result, success Module-->>Client: Return result ``` This diagram outlines how to burn a game asset. It starts with the `Client` sending a `MsgBurnAsset` message to the `Module`. The `Module` asks the `Keeper` to burn the asset, providing the asset owner and asset ID. The `Keeper` retrieves and verifies the asset data from the Store. If ownership is confirmed, the `Keeper` deletes the asset from the `Store`. The `Store` confirms the storage, and the `Keeper` informs the `Module`. Finally, the `Module` notifies the `Client` that the asset has been successfully burned. This process ensures the removal of the asset. ### Asset Transfer ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgTransferAsset Module->>Keeper: TransferAsset(from, to, assetID) Keeper->>Store: Get asset data Store-->>Keeper: Asset data Keeper->>Keeper: Verify ownership Keeper->>Keeper: Update owner Keeper->>Store: Store asset data Store-->>Keeper: Confirm storage Keeper-->>Module: Return result, success Module-->>Client: Return result ``` This diagram illustrates how to transfer a game asset. It starts with the `Client` sending a `MsgTransferAsset` to the `Module`. The `Module` asks the `Keeper` to handle the transfer by `TransferAsset(from, to, assetID)`. The `Keeper` retrieves and verifies asset data from the `Store`, updates the owner, and stores the new data back in the `Store`. After confirming the storage, the `Keeper` informs the `Module`, which then notifies the `Client`, completing the transfer. This ensures the asset transfer is verified and updated. ## Game State Management Module The `Game State Management` module provides efficient storage and retrieval of game states, as well as support for saving and loading game progress. This module enables game developers to seamlessly manage the state of the games, allowing players to save their progress and resume gameplay at a later time. The conceptual procedures for the key operations of game state management are outlined below. ### State Saving ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgSaveGameState Module->>Keeper: SaveGameState(gameState) Keeper->>Keeper: Convert gameState to JSON Keeper->>Store: Store state data Store-->>Keeper: Confirm storage Keeper-->>Module: Return result, success Module-->>Client: Return result ``` This diagram depicts how to save game state data. First, the `Client` sends a `MsgSaveGameState` message to the `Module`. The `Module` then requests the `Keeper` to execute `SaveGameState` with the state data. The `Keeper` converts the state to JSON and stores it in the `Store` as a key-value pair. The `Store` informs the `Keeper`, and the `Keeper` reports success back to the `Module`, which then notifies the `Client`, completing the process. ### State Retrieval ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgGetGameState Module->>Keeper: GetGameState(key) Keeper->>Store: Get state data Store-->>Keeper: State data Keeper->>Keeper: Convert JSON to gameState Keeper-->>Module: Return gameState, found Module-->>Client: Return state data ``` This diagram highlights how to request game state data. The `Client` sends a `MsgGetGameState` request to the `Module`, which calls the `Keeper`'s `GetGameState` function with a specific key. The `Keeper` queries the `Store` for the state data, converts the JSON data into a game state object, and returns the state object data to the `Module`. The `Module` then sends the game state data back to the `Client`. ### State Removal ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgDeleteGameState Module->>Keeper: DeleteGameState(key) Keeper->>Store: Delete state data Store-->>Keeper: Confirm storage Keeper-->>Module: Return result, success Module-->>Client: Return result ``` This diagram demonstrates how to remove game state data. The `Client` sends a `MsgDeleteGameState` request to the `Module`, which then passes the game state key to the `Keeper`. The `Keeper` tells the `Store` to remove the state data. Once the `Store` confirms storage, this is sent back to the `Keeper`, which returns a success message to the `Module`. The `Module` finally informs the `Client` of the result, completing the process. ## Random Number Generation Module The `Random Number Generation` module is to incorporate a Verifiable Random Function (VRF). This addition aims to ensure that the random numbers generated are both fair and transparent, making the system more reliable and trustworthy. The conceptual procedure for the random number generation is outlined below. ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Note over Client,Store: Request Random Number Client->>Module: Submit MsgRequestRandom Module->>Keeper: RequestRandomNumber<br>(requester, seed) Keeper->>Keeper: RequestRandomNumber<br>via VRF service Keeper->>Store: Store RequestResponse<br>{ requestID } Store-->>Keeper: Request ID Keeper-->>Module: Return Request ID Module-->>Client: Acknowledge request Note over Keeper: Wait for block finalization Keeper->>Keeper: GetRandomResult(requestId)<br>via VRF service Keeper->>Store: Store RandomResult Store-->>Keeper: Confirm storage Note over Client,Store: Query Random Number Client->>Module: Query random number Module->>Keeper: GetRandomResult(requestID) Keeper->>Store: Get RandomResult Store-->>Keeper: RandomResult Keeper-->>Module: Return RandomResult Module-->>Client: Return random number ``` This diagram explains the process of a client requesting and obtaining a random number. The `Client` starts by submitting a `MsgRequestRandom`, which the `Module` forwards to the `Keeper`. The `Keeper` requests the random number via the VRF service and stores the response with a request ID in the `Store` and returning it to the `Module`, which acknowledges the request back to the `Client`. After block finalization, the `Keeper` retrieves the random result via the VRF service by the obtained request ID and stores it in the `Store`. The `Client` can later query the random number, which the `Module` fetches from the `Keeper` (retrieves the result from the `Store`) and returns to the `Client`. This process ensures the randomness is secure, verifiable, and trustworthy. ## Governance Integration Module The `Governance Integration` module is designed to pave the way for on-chain governance of game parameters and rules. This module enables game developers and participants to propose, vote on, and implement changes to the parameters and rules that govern the gameplay experience. The key operational steps involved in the governance process are outlined below. ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Note over Client,Store: Proposal Submission Client->>Module: Submit ParameterProposal<br> or GameRuleProposal Module->>Keeper: SubmitProposal Keeper->>Store: Store Proposal Store-->>Keeper: Proposal ID Keeper-->>Module: Proposal ID Module-->>Client: Proposal ID Note over Client,Store: Proposal Voting Client->>Module: Vote on Proposal Module->>Keeper: AddVote(proposalId) Keeper->>Store: Store Vote Store-->>Keeper: Vote Confirmation Keeper-->>Module: Vote Confirmation Module-->>Client: Vote Result Note over Client,Store: Proposal Retrieval Client->>Module: Retrieve Proposal Module->>Keeper: GetProposal(proposalId) Keeper->>Store: Retrieve Proposal Store-->>Keeper: Proposal Details Keeper-->>Module: Proposal Details Module-->>Client: Proposal Information Note over Client,Store: Proposal Execution Keeper->>Keeper: Check Voting Results(proposalId)<br>Execute Proposal If Passed Keeper->>Store: Update Game Parameters or Rules Store-->>Keeper: Execution Confirmation Keeper-->>Module: Execution Status Module-->>Client: Proposal Execution Result ``` This diagram presents the game proposal process. It begins with the `Client` sending a `GameParameterProposal` or `GameRuleProposal` to the `Module`. The `Module` then forwards the proposal to the `Keeper` using the `SubmitProposal` function. The `Keeper` stores the proposal in the `Store` and provides a Proposal ID to the `Client`. When it comes to voting, the `Client` submits their vote through the `Module` to the `Keeper` using the `AddVote` function along with the proposal ID. The vote is stored, and the results are sent back to the `Client`. For retrieving proposal details, the `Module` requests the `Keeper` to fetch the proposal details associated with the proposal ID from the `Store`, and then returns them to the `Client`. After the voting period concludes, the `Keeper` checks the voting results for the specified proposal. If the proposal is approved, the `Keeper` executes the changes of game parameters or rules, which are saved in the `Store`. Finally, the execution status is communicated back to the `Client`, confirming whether the proposal was successfully executed. This ensures that any changes to the game environment are controlled and transparent, with on-chain governance providing a reliable framework for decision making. ## State Channels Module The `State Channels` module incorporates state channels for off-chain gameplay with periodic on-chain settlements. State channel is an advanced technique that aims to enhance blockchain efficiency by handling multiple transactions off-chain and settling the final state on-chain. The conceptual procedures for these operations are outlined below. ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: Submit MsgOpenChannel Module->>Keeper: OpenChannel Keeper->>Store: Record Channel State Store-->>Keeper: Acknowledgment Keeper-->>Module: Acknowledgment Module-->>Client: Return result Note over Client: Off-chain operations Client->>Module: Submit MsgSettleState Module->>Keeper: SettleState Keeper->>Store: Modify Channel State Store-->>Keeper: Acknowledgment Keeper-->>Module: Acknowledgment Module-->>Client: Return result Note over Client: Off-chain operations Client->>Module: Submit MsgCloseChannel Module->>Keeper: CloseChannel Keeper->>Store: Delete Channel State Store-->>Keeper: Acknowledgment Keeper-->>Module: Acknowledgment Module-->>Client: Return result ``` This diagram shows the procedure for state channel management, which involves three types of operations: open, update, and close. Initially, the `Client` sends a `MsgOpenChannel` request to the `Module`, which then forwards it to the `Keeper`. The `Keeper` updates the `Store` with the new channel state and confirms this back to the `Client`. Subsequently, the `Client` performs off-chain tasks and sends a `MsgSettleState` to the `Module`. The `Module` instructs the `Keeper` to modify the state in `Store` accordingly. Successful changes are then confirmed to the `Client`. Finally, to close the channel, the `Client` sends a `MsgCloseChannel` to the `Module`, which directs the `Keeper` to remove the channel state from the `Store`. Confirmations are subsequently relayed back to the `Client`. This ensures consistent recording and validation of changes. ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Store Client->>Module: MsgCreateLobby<br>(LobbyID, Players) Module->>Keeper: CreateLobby<br>(LobbyID, Players) Keeper->>Store: Record Lobby<br>{LobbyID, Status, Players} Store-->>Keeper: Acknowledged<br>{LobbyID, Status} Keeper-->>Module: Success {LobbyID, Status} Module-->>Client: Result {LobbyID, Status} Note over Client: Players off-chain gameplay Client->>Module: MsgSettleState<br>(LobbyID, States) Module->>Keeper: SettleOnchain<br>(LobbyID, States) Keeper->>Store: Modify State<br>{LobbyID, States} Store-->>Keeper: Acknowledged<br>{LobbyID, Status} Keeper-->>Module: Success {LobbyID, States} Module-->>Client: Result {LobbyID, States} Note over Client: Players departure Client->>Module: MsgCloseLobby(LobbyID) Module->>Keeper: CloseLobby(LobbyID) Keeper->>Store: Delete Lobby {LobbyID} Store-->>Keeper: Acknowledged<br>{LobbyID, Status} Keeper-->>Module: Success {LobbyID, Status} Module-->>Client: Result {LobbyID, Status} ``` This diagram further provides a practical usage example of state channels, illustrating the complete process of creating, settling, and closing a lobby using state channels. - The process begins with the `Client` sending a `MsgCreateLobby(LobbyID, Players)` request to the `Module`. The `Module` then asks the `Keeper` to create a new lobby, which is stored in the `Store`. The `Store` confirms the creation, and the `Module` notifies the `Client` of the successful operation. - Players operate in off-chain gameplay and settle states on-chain using `MsgSettleState(LobbyID, States)`. The `Module` forwards this request to the `Keeper`, which modifies the state in`Store`. The `Store` acknowledges the update, and the success is sent back to the `Client`. - To close the lobby, the `Client` sends `MsgCloseLobby(LobbyID)` to the `Module`, which instructs the `Keeper` to delete the lobby from the `Store`. The `Store` confirms the deletion, and the success is relayed back to the `Client`. ## Interoperability Module The `Interoperability` module is designed to facilitate cross-chain asset transfers and game interactions using the IBC protocol. This protocol enables seamless communication and interoperability between different blockchains, allowing for the transfer of assets and the execution of game actions across multiple chains. The key operational steps involved in the functionality of this module are outlined below. ```mermaid sequenceDiagram participant Client participant SourceChain participant IBCRelayer participant DestChain Note over Client,DestChain: Cross-Chain Asset Transfer Client->>SourceChain: Initiate transfer SourceChain->>SourceChain: SendCrossChainTransfer SourceChain->>IBCRelayer: Send IBC packet IBCRelayer->>DestChain: Relay IBC packet DestChain->>DestChain: OnRecvPacket DestChain->>DestChain: Process transfer Note over Client,DestChain: Cross-Chain Game Interaction Client->>SourceChain: Submit game action SourceChain->>SourceChain: SendCrossChainGameAction SourceChain->>IBCRelayer: Send IBC packet IBCRelayer->>DestChain: Relay IBC packet DestChain->>DestChain: OnRecvPacket DestChain->>DestChain: Process game action ``` This diagram shows the cross-chain communication for asset transfers and game interactions. In asset transfers, the `Client` starts the process on the `SourceChain` with the `SendCrossChainTransfer` function. This creates an IBC packet sent by the IBC Relayer to the `DestinationChain`, which processes it using `OnRecvPacket`. For game interactions, the `Client` submits a game action to the `SourceChain` via the `SendCrossChainGameAction` function. This action is also sent as an IBC packet to the `DestinationChain` for processing. Both scenarios demonstrate the IBC protocol's role in enabling smooth data and action transfers across different blockchains. ```mermaid sequenceDiagram participant Client participant SourceChain participant IBCRelayer participant DestChain Note over Client,DestChain: Cross-Chain Asset Transfer Client->>SourceChain: Initiate transfer of weapon SourceChain->>SourceChain: Lock weapon and create IBC packet SourceChain->>IBCRelayer: Send IBC packet IBCRelayer->>DestChain: Relay IBC packet DestChain->>DestChain: OnRecvPacket (Receive weapon) DestChain->>DestChain: Mint weapon on DestChain Note over Client,DestChain: Cross-Chain Game Interaction Client->>SourceChain: Use weapon in game<br>on DestChain SourceChain->>IBCRelayer: Send IBC packet IBCRelayer->>DestChain: Relay IBC packet DestChain->>DestChain: Validate weapon ownership DestChain->>DestChain: Execute game action DestChain-->>Client: Return game action result ``` This diagram further provides a practical usage example of cross-chain asset transfer and game interaction. - In asset transfer, the `Client` transfers a weapon from `SourceChain` to `DestChain`. `SourceChain` locks the weapon and sends an IBC packet through `IBCRelayer` to `DestChain`, which mints the weapon upon receipt. - In game interaction, the `Client` uses the weapon in game on `DestChain`, with `SourceChain` sending another IBC packet through `IBCRelayer` to validate ownership and execute the game action, returning action result to the `Client`. ## Gas Optimization Module The `Gas Optimization` module provides gas subsidies or optimizations for frequent game actions. This module aims to improve the efficiency of gas usage in a blockchain environment, reducing costs and enhancing overall performance. By incorporating gas subsidies and optimizing gas usage, game developers can ensure a smoother and more cost-effective gaming experience for the users. The key operational steps involved in the gas optimization process are outlined below. ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant Blockchain Client->>Module: Submit MsgOptimizeGas Module->>Keeper: OptimizeGasUsage(action) Keeper->>Keeper: Get Subsidy<br>for action (Store) Keeper->>Keeper: Apply Gas discount Keeper->>Blockchain: Update Gas Usage Blockchain-->>Client: Execute action with optimized Gas ``` The diagram illustrates the process of gas optimization. The `Client` starts by submitting a `MsgOptimizeGas` to the `Module`, requesting optimization for a specific action. The `Module` forwards this request to the `Keeper`, which retrieves the appropriate subsidy for the action and applies a gas discount. The updated gas usage is then recorded on the blockchain. As a result, the action of `Client` is executed with the optimized gas settings, leading to reduced costs and improved efficiency in the blockchain environment. ## AI Integration Module The `AI Integration` module is designed to provide integration with AI services, enabling features such as NPC behavior customization and dynamic difficulty adjustment. This module allows game developers to incorporate AI algorithms and models into the games. The key operational steps involved in utilizing the AI Integration module are outlined below. ```mermaid sequenceDiagram participant Client participant Module as Module (Handler) participant Keeper participant AI Service Note over Client,AI Service: NPC Behavior Update Client->>Module: Request NPC Behavior Update Module->>Keeper: Submit AI Request (behavior) Keeper->>AI Service: Process NPC Behavior AI Service-->>Keeper: NPC Behavior Response Keeper->>Keeper: Update NPC Behavior (Store) Keeper-->>Module: Return Updated NPC Behavior Module-->>Client: Return Updated NPC Behavior Note over Client,AI Service: Difficulty Adjustment Client->>Module: Request Difficulty Adjustment Module->>Keeper: Submit AI Request (adjustment) Keeper->>AI Service: Process Difficulty Adjustment AI Service-->>Keeper: Difficulty Adjustment Response Keeper->>Keeper: Update Difficulty (Store) Keeper-->>Module: Return Updated Difficulty Module-->>Client: Return Updated Difficulty ``` This diagram shows how NPC behavior updates and difficulty adjustments are managed with AI services. The `Client` requests an NPC behavior update, which the `Module` sends to the `Keeper`. The `Keeper` forwards this to the AI Service. Once processed, the updated behavior is sent back through the `Keeper` to the `Module`, which updates the `Client`. For difficulty adjustments, the `Client` requests a change, submitted by the `Module` to the `Keeper`. This request goes to the AI Service. The AI Service responds to the `Keeper`, which updates the difficulty, and then it's communicated through the `Module` back to the `Client`. > [!NOTE] > In Cosmos SDK, **Stores** are key components used to manage and persist data within a blockchain application. They function as a database for storing state and information required by the various modules. For more details of the Cosmos SDK Stores, please refer to https://docs.cosmos.network/v0.50/learn/advanced/store.