Skip to main content

Robot Solution

This module is currently in closed beta.

tip

Online Examples : https://a.iohao.com

Online game examples : https://a.iohao.com

Introduction​

Room + Robot + Code generation (sdk) = a fast way to build multiplayer online games with bots.

Provides bots for many room-based game types, for example:

  • Tank games
    • Tank shooting behavior
    • Movement
  • Dou Dizhu games
    • Playing cards
  • Mahjong games
    • Playing cards
    • Chii/Pon/Kan, draw, win, self-draw, and other actions
  • Monopoly-like games
    • Dice-based movement
    • Build houses, buy items, use items, etc.
  • Aeroplane chess games
    • Dice-based movement

Includes many bot behaviors such as bot-created rooms, bots joining games as players, bots joining other rooms, and bots leaving rooms.

Online Examples​

Online Examples delivered both frontend and backend in just one week, thanks to code generation and reuse of the room module. During development, network integration interface code was generated quickly, which made frontend-backend joint testing much easier.

Here, the framework generated the TypeScript code required by Cocos Creator. If we later switch to Unity or Godot, that is straightforward. Existing server code requires no changes to generate corresponding network integration code for Unity and Godot. Players can even enter the same game from different engines at the same time.

example

This demo reflects the initial Robot design. Planned follow-up demos may include:

  • Real-time large-scale dungeon raids with boss fights and loot drops.
  • Strategy-heavy games like Dou Dizhu or Mahjong.
  • Turn-based battle scenarios.
  • Monopoly-style board games, etc.

Problems Solved​

  1. Balancing player win rates (similar to LoL-style balance)
  2. Helping maximize company benefits
  3. Reducing costs (replace companion players with bots)

SCQA, 3C Architecture Analysis​

example

Robot Behavior Strategies​

example

Real-World Cases​

A brief summary of module usage is shown below, using a separated architecture pattern.

The following diagram shows project structure: game-fair-logic contains concrete game business code, and game-fair-robot contains robot-related code. Robot code is fully separated from game business code.

robot_project

If you have prior Robot development experience, you may have mixed these two parts together. When Robot code is mixed into game business code, the business code becomes messy. You often end up with many if branches just to handle Robot logic.

With separated mode, game business developers carry less cognitive load. They do not need to think about Robot-specific branches and can focus only on core game business logic. Likewise, Robot developers only need to care about which operations the game exposes (in-room gameplay operations).

If mixed together, both sides must constantly watch each other's code. For example: "If I change this part, will it affect theirs?" This mixed mode increases cognitive burden for both teams.

From this, we can see at least two advantages of separated mode:

  1. Reduced cognitive load for both sides.
  2. Since Robot-related code is almost invisible in game code, non-core project members cannot easily access this Robot business logic, helping protect company assets.