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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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 inStore. 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.

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.

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.

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.

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.