Service

• 1 MyBot: Library for bot system
  • gRPC
    • Provides an API for controlling the ON/OFF state of the bot.
  • HTTP Internal Setting
    • Offers an API for importing scenarios and group settings, allowing for updates.
  • Scenario + group bot
    • Involves defining specific use cases and interactions for the bot.
    • Designed for use within group chats or channels.
  • Health check
    • Checks the health of the bot system and takes action if issues are detected, such as restarting the bot.
  • Refill Balance
    • Requires operator approval to replenish the bot's balance when requested.
  • Schedule
    • Reads a schedule to execute tasks at specific times, possibly sourced from the Scenario + Group settings.
• 2 Bot service (xocdia, baucua, tala): Extend from mybot to implement logic and deploys service for each game, resulting in different pods for each game.
  • Logic Game
    • Contains the logic for running games
• 3 Issue when registration bot
  • Registration Directions
    • From the game:
      • Advantage: Merchant doesn't need to provide a lot of data and implement many steps. They only need to request bot creation.
      • Disadvantage: They must handle history, leaderboards, and jackpots. They need to manage money transfers between the bot and the house, and between the bot and players.
    • From the Merchant
      • Advantage: The game doesn't have to worry about bots because the gateway treats bots as humans.
      • Disadvantage: The gateway must handle financial data, report to the bots as if they were humans.
        • They must take responsibility for initializing and depositing money for bots (a risk for merchants).
        • In cases where the game operator does not have a gaming gateway, the game will not have bots to play.
  • Who will approve balance refills?
    • Bots will send requests to the Back Office, and the Back Office will approve and deposit money for bots.
  • Virtual Money from a game
    • Depending on the type of game, this part is implemented differently.
    • For slots and table games, virtual money can be used. However, transactions need to be saved for statistics and leaderboard display.
    • For card games, TXMN (money transfer) occurs between users and bots. Bots are virtual money, but the money must be obtained from the house. If someone bets, but the leaderboard is empty, who will fill it?
  • Current Standalone System
    • If there are two merchants on the same game server, the money flow is shared among the merchants on one game.
    • For example, if Merchant A wants to initialize a bot, and Merchant B does not, if the bot is requested to be initialized for Merchant A, it will disadvantage Merchant A if B does not release the bot because the bot's money initialized by Merchant A will be lost.
    • The game must have a mechanism to differentiate the money flow according to each company key.
  • Conclusion for all issue above
    • It is possible to create users from the game's side. Nautilus will initialize the service for registration and differentiate bots.
    • Nautilus will create a company key for bots.
    • Merchants integrate and agree to initialize the amount of money for bots and agree to transfer money to bots.

Conclusion

• The system is designed to be easy to deploy and integrate with new games.