OpenClaw Battle Arena：基于WebSocket的AI格斗竞技场设计与实战

1. 项目概述：一个为智能体设计的2D格斗竞技场

如果你正在寻找一个能让你的强化学习（RL）或AI智能体进行实战对抗，同时又不想陷入游戏引擎和训练循环深度耦合的泥潭，那么 OpenClaw Battle Arena 这个项目，或许就是你一直在找的那个“公平竞技场”。

简单来说，这是一个纯2D格斗游戏的沙盒环境。它的核心设计哲学是“关注点分离”：游戏主机（Host）负责一切权威的物理模拟、碰撞检测、生命值计算和动画播放；而你的智能体（Agent）则作为一个远程控制器，仅能通过一个极简的WebSocket协议，向主机发送“左、右、跳、攻击”等离散指令。你的智能体看不到游戏源代码，也无法直接操作内存，它只能通过主机广播的“观察”（Observation）来感知世界，并据此做出决策。这就像是在线游戏：服务器说了算，客户端只负责发送操作。

这个设计解决了我在过去尝试AI对战时遇到的一个核心痛点：可复现性与公平性。很多自研的RL格斗环境，智能体和环境深度绑定，很难将训练好的模型独立出来，与其他模型进行大规模、可审计的对抗。而OpenClaw Battle Arena通过明确的协议边界，使得：

1. 智能体可以独立部署：你的模型可以运行在另一台机器、另一个容器，甚至用另一种语言编写，只要它能连上WebSocket并理解协议。
2. 比赛规则由主机强制执行：攻击冷却、无敌帧、行动速率限制、反消极比赛（Anti-stall）等规则都在主机端实现，杜绝了智能体“作弊”的可能。
3. 便于组织锦标赛：可以轻松地编写脚本，让多个智能体进行循环赛，并自动收集胜率、平均回合时间、造成伤害等统计数据。

项目目前主要面向像我这样的“OpenClaw风格”的智能体开发者，用于进行策略迭代、匹配测试和举办小型锦标赛。它不是一个功能完备的商业游戏，而是一个高度聚焦的AI研究/竞技工具。

1.1 核心设计理念：为什么是“仅输入”与“主机权威”

在深入细节之前，有必要先厘清这个设计背后的逻辑。市面上大多数“AI格斗”或“RL格斗”项目，无外乎两种模式：

模式A：硬编码的自博弈循环。这是最常见的科研做法。智能体和环境（游戏逻辑）通常写在同一个Python脚本里，甚至共享同一个进程。训练时，智能体直接调用环境的方法获取状态、执行动作。这种方式虽然高效，但智能体和环境耦合太深。你想把这个训练好的智能体拿出来，和别人的智能体在另一个环境里对战？几乎不可能，因为接口不统一，环境规则也可能不同。

模式B：为人类玩家设计的游戏。这类项目有完整的图形界面和键盘/手柄输入，但AI需要以“模拟人类按键”的方式介入，比如用pyautogui库发送键盘事件。这种方式非常脆弱，且难以保证时序精确和公平性，更别提大规模自动化测试了。

OpenClaw Battle Arena 选择了第三条路：客户端-服务器架构（C/S）的微缩版。

• 服务器（Host）：拥有绝对权威。它运行着用Pygame实现的完整游戏循环，计算每一帧的物理、处理碰撞、更新角色状态和动画。它定时向所有连接的客户端广播当前游戏世界的“观察”数据。
• 客户端（Controller）：本质上是“输入代理”。它接收“观察”，运行你的决策算法（可以是简单的规则，也可以是复杂的神经网络），然后向服务器回送一个代表动作的整数ID。除此之外，它不能做任何事。

这种分离带来了几个关键优势：

• 安全性/沙盒：不信任的、甚至可能有Bug的客户端代码不会导致主机崩溃。
• 可扩展性：可以轻松接入LLM智能体框架、远程API，甚至举办线上比赛。
• 规则统一：所有比赛规则（如每秒动作数上限、超时判负）都在主机端统一执行，确保了绝对的公平。
• 可观测性：主机可以完整记录每一场比赛的所有事件（events.jsonl），便于事后分析和复现。

2. 环境搭建与快速启动

理论说得再多，不如亲手跑起来看看。整个项目的依赖非常轻量，核心就是Pygame和WebSocket库。下面我会带你从零开始，把竞技场跑起来，并让两个预设的脚本机器人先打一场。

2.1 基础环境准备

首先，把项目代码克隆到本地：

git clone https://github.com/Infans-Digitalis-ai/openclaw-battle-arena.git cd openclaw-battle-arena

项目使用Python 3.7+，强烈建议使用虚拟环境来管理依赖，避免污染系统环境。

# 创建虚拟环境 python3 -m venv .venv # 激活虚拟环境 # Linux/macOS: source .venv/bin/activate # Windows: # .venv\Scripts\activate # 安装依赖 pip install -r requirements.txt

requirements.txt里主要包含了pygame（用于游戏渲染和主循环）和websockets（用于网络通信）。安装过程通常很顺利。

2.2 启动竞技场主机

环境准备好后，启动主机服务器非常简单：

python main.py

执行这个命令后，你会看到两个窗口弹出：一个是Pygame的格斗游戏窗口，另一个是终端日志窗口。在日志中，你会看到类似下面的输出：

[INFO] Starting OpenClaw Battle Arena host... [INFO] WebSocket server started on ws://127.0.0.1:8765 [INFO] Match started: match_abc123 [INFO] Player 1 controller: heuristic [INFO] Player 2 controller: heuristic

这表示主机已成功启动，并在本地8765端口开启了WebSocket服务，同时默认使用两个内置的启发式（heuristic）机器人开始了一场对战。你可以直接在游戏窗口观看它们自动战斗。

注意：第一次运行时，如果Pygame窗口无法打开或立即关闭，请检查终端是否有错误信息。常见问题包括缺少SDL库（Linux下需安装libsdl2等）或显示器设置问题（对于无图形界面的服务器，需要设置虚拟显示或使用下文提到的无头模式）。

2.3 初体验：让两个脚本机器人对战

观看内置机器人打架有点无聊，我们试试用项目自带的示例机器人脚本进行对战。这不需要编写任何网络代码，是最快的入门方式。

打开项目根目录下的settings.py文件，这是一个关键的配置文件。找到玩家控制器设置的段落：

# settings.py 示例片段 P1_CONTROLLER = "heuristic" # 默认值 P2_CONTROLLER = "heuristic" # 默认值

将其修改为使用脚本控制器，并指定脚本路径：

P1_CONTROLLER = "script" P2_CONTROLLER = "script" P1_SCRIPT_PATH = "bots/aggressive_heavy.py" P2_SCRIPT_PATH = "bots/defensive_kiter.py"

保存文件后，重新启动python main.py。这次，竞技场将加载bots/目录下的两个Python脚本作为机器人。

• aggressive_heavy.py：一个激进的机器人，喜欢靠近对手并频繁使用重攻击。
• defensive_kiter.py：一个防守型机器人，倾向于保持距离，并伺机使用轻攻击。

你会立刻在游戏窗口中看到两种不同风格的AI在搏斗。这是理解机器人如何通过choose_action(obs)函数与游戏交互的绝佳方式。

2.4 无头模式：快速批量测试

如果你需要快速测试机器人的性能，比如跑100场对决来计算胜率，而不想每次都打开图形界面，那么“无头模式”就派上用场了。项目提供了trial_runner.py脚本。

python trial_runner.py --matches 100 --best-of 5 \ --p1 script --p1-script bots/baseline.py \ --p2 script --p2-script bots/random.py \ --out my_results.json

这条命令的含义是：

• --matches 100：总共进行100场独立比赛。
• --best-of 5：每场比赛采用五局三胜制。
• --p1/--p2：指定玩家使用的控制器类型，这里是script。
• --p1-script/--p2-script：指定机器人脚本的路径。
• --out：将每场比赛的详细结果汇总输出到my_results.json文件。

运行后，终端会显示进度，并在结束后打印一个简要的统计摘要，包括胜/负/平局场次、总回合数、平均每回合时长等。my_results.json文件则包含了每一小局的详细数据，非常适合进行数据分析。

实操心得：在开发机器人早期，我强烈建议使用无头模式进行快速迭代。把你的机器人bot_v1.py去对抗一个固定的基线机器人（如bots/baseline.py），跑上几百场，看看胜率是否稳步提升。这比肉眼观察几场比赛要可靠得多。

3. 核心协议详解：智能体如何“观察”与“行动”

要让你的智能体在这个竞技场里战斗，你必须理解它和主机之间的“语言”，也就是通信协议。协议设计得非常简洁，目前是v0版本，通过WebSocket传输JSON数据。

3.1 观察（Observation）：智能体的“眼睛”

主机以大约30Hz的频率（可在settings.py中调整TICK_RATE）向所有连接的控制器广播观察数据。每一条观察消息都是一个JSON对象，结构如下：

{ "type": "obs", "player": 1, "obs": { "my_x": 150.5, "my_y": 300.0, "opponent_x": 450.5, "opponent_y": 300.0, "my_health": 85, "opponent_health": 100, "my_state": "idle", "opponent_state": "attack_heavy", "my_state_frame": 2, "opponent_state_frame": 0, "my_facing_right": true, "opponent_facing_right": false, "stage_width": 800, "stage_height": 400, // ... 可能还有其他字段，取决于 settings.OBSERVATION_FEATURES } }

对于智能体来说，obs字典就是它感知世界的全部。你需要从中提取关键信息：

• 位置信息(my_x,my_y,opponent_x,opponent_y)：决定了距离和方位。你可以计算相对距离dx = opponent_x - my_x。
• 生命值(my_health,opponent_health)：最直接的目标，将对手生命值降为0即获胜。
• 状态(my_state,opponent_state)：角色当前在做什么。常见状态有idle（待机）、walk（行走）、jump（跳跃）、attack_light（轻攻击）、attack_heavy（重攻击）、hurt（受击）等。了解对手状态对于预判和防御至关重要。
• 状态帧数(my_state_frame,opponent_state_frame)：当前状态持续了多少帧。例如，attack_heavy状态可能持续10帧，其中前3帧是攻击前摇，中间4帧是攻击判定框生效期，后3帧是恢复期。通过帧数可以精确判断攻击时机。
• 朝向(my_facing_right,opponent_facing_right)：true表示面朝右。这会影响移动方向和攻击判定。

注意事项：obs的字段列表不是固定的，它由settings.py中的OBSERVATION_FEATURES列表控制。默认列表包含了对战所需的核心信息。如果你需要额外的信息（比如对手上一帧的动作），你需要修改主机代码来广播它，并确保所有参赛机器人都在同一套观察标准下运行，以维持公平。

3.2 动作（Action）：智能体的“手脚”

智能体在分析完观察数据后，需要向主机发送一个动作指令。动作指令同样是一个简单的JSON对象：

{ "type": "action", "player": 1, "action": 4 }

其中，action是一个整数ID，对应下表：

ID	动作	说明
0	noop	无操作（保持当前状态）
1	move_left	向左移动
2	move_right	向右移动
3	jump	原地跳跃
4	heavy_attack	重攻击（伤害高，速度慢）
5	light_attack	轻攻击（伤害低，速度快）
6	jump_left	向左跳跃
7	jump_right	向右跳跃

这里有一个非常重要的设计细节：动作是瞬时的，而非持续的。当你发送action: 1（向左移动）时，它的效果是“在这一帧，给角色施加一个向左的力”。如果你想持续向左走，你需要在接下来的每一帧（或每隔几帧）都发送action: 1。这与许多游戏API中“按下按键”和“松开按键”的设计不同。这种设计简化了协议，但要求智能体有基本的“状态记忆”能力，例如实现“长按移动”的逻辑。

3.3 协议流程与超时控制

一个典型的远程智能体工作流程如下：

1. 连接到ws://主机IP:8765。
2. 进入循环： a. 等待接收主机发来的{"type": "obs", ...}消息。 b. 将消息中的obs字典输入到你的决策函数中。 c. 决策函数计算出动作ID（0-7）。 d. 发送{"type": "action", "player": X, "action": id}回主机。
3. 当比赛结束（一方生命值为0或超时），主机会发送特定消息或直接关闭连接。

主机对智能体的约束（公平性保障）：为了阻止智能体通过“思考太久”或“发送垃圾动作”来破坏游戏，主机端实施了严格的规则：

• 每帧决策超时(SCRIPT_ACT_TIMEOUT_MS)：在settings.py中定义（默认可能是50ms）。如果你的choose_action()函数在这个时间内没有返回，主机将自动为你执行noop（动作0）。更严厉的是，如果某次调用超时，该控制器在本场剩余所有回合中都会被标记为“已超时”，后续所有帧都直接返回noop。这是为了防止一个卡死的线程持续占用资源。
• 每帧缓存：在同一游戏帧内，如果主机多次向控制器请求动作（理论上不应该），控制器会返回缓存的结果，而不是重新运行一次决策逻辑。这保证了每帧决策的一致性。
• 反积压速率限制：如果上一帧的choose_action()调用还在执行（即函数未返回），主机将不会为当前帧发起新的调用，而是直接使用noop。这防止了由于机器人反应过慢导致动作指令队列无限堆积。

这些规则在controllers/script_file.py中实现，对于远程WebSocket控制器也有类似的逻辑。这意味着你的智能体不仅要比对手“聪明”，还要比对手“快”和“稳定”。

4. 编写你的第一个战斗机器人

理解了协议之后，是时候动手创建你自己的斗士了。我们将从最简单的规则机器人开始，然后探讨如何接入强化学习模型。

4.1 从模板开始：一个“直冲型”机器人

项目在bots/目录下提供了一个极简模板template_bot.py。我们复制一份并开始修改：

cp bots/template_bot.py bots/my_first_bot.py

打开my_first_bot.py，你会看到核心就是一个函数：

# bots/my_first_bot.py import random def choose_action(obs: dict) -> int: """ 根据观察信息，返回一个动作ID (0-7)。 obs: 字典，包含了当前帧的游戏状态观察。 返回值必须是整数。 """ # 这是一个最简单的随机机器人 return random.randint(0, 7)

让我们把它变得有点策略。假设我们想做一个“直冲型”机器人：永远面向对手，靠近后使用重攻击。

def choose_action(obs: dict) -> int: my_x = obs[“my_x”] opponent_x = obs[“opponent_x”] my_facing = obs[“my_facing_right”] opponent_facing = obs[“opponent_facing_right”] # 计算水平距离 distance = opponent_x - my_x # 策略逻辑 if abs(distance) < 50: # 距离很近 # 在攻击范围内，使用重攻击 return 4 # heavy_attack else: # 需要移动靠近对手 if distance > 0: # 对手在我右边 if not my_facing: # 如果我面朝左，需要先转身 # 发送向右移动指令也会让角色转身 return 2 # move_right else: # 面朝正确，向右移动 return 2 # move_right else: # 对手在我左边 if my_facing: # 如果我面朝右，需要先转身 return 1 # move_left else: # 面朝正确，向左移动 return 1 # move_left

这个机器人虽然简单，但已经具备了基本的追踪和攻击逻辑。你可以修改settings.py，让P1_CONTROLLER使用这个脚本，去挑战bots/defensive_kiter.py，看看效果。

4.2 进阶技巧：状态机与帧数利用

更强大的机器人通常是一个有限状态机。它根据自己和对面的状态，在不同的行为模式间切换。例如：

• 追击模式：当距离较远时，持续移动接近。
• 攻击模式：当进入攻击范围且自身不在硬直中时，发动攻击。
• 防御模式：当检测到对手正在发动攻击（opponent_state为attack_*且opponent_state_frame处于攻击判定帧），进行后退或跳跃躲避。

利用opponent_state_frame是关键。假设你知道重攻击的动画共10帧，前3帧是前摇，第4-7帧是攻击有效帧。你可以写这样的逻辑：

def choose_action(obs: dict): opp_state = obs[“opponent_state”] opp_frame = obs[“opponent_state_frame”] # 如果对手正在出重攻击，并且处于攻击有效帧 if opp_state == “attack_heavy” and 3 < opp_frame < 8: # 并且对手离我很近 if abs(obs[“opponent_x”] - obs[“my_x”]) < 60: # 快速后跳躲避 if obs[“opponent_x”] > obs[“my_x”]: # 对手在右，向左跳 return 6 # jump_left else: return 7 # jump_right # ... 其他逻辑

4.3 接入强化学习模型（DQN示例）

对于更复杂的决策，规则会变得极其臃肿且难以维护。这时就需要强化学习。项目在controllers/dqn.py中提供了一个深度Q网络控制器的示例框架。它展示了如何加载一个训练好的PyTorch模型，并将观察数据转换为模型输入。

核心步骤：

1. 观察预处理：将obs字典中的各种值（位置、生命值、状态等）归一化并拼接成一个一维向量。
2. 模型推理：将向量输入神经网络，网络输出8个动作对应的Q值。
3. 动作选择：根据策略（如epsilon-greedy）选择一个动作ID。
4. 发送动作：将ID通过控制器接口发送出去。

dqn.py中的choose_action方法大致如下：

def choose_action(self, obs: dict) -> int: # 1. 预处理观察 processed_obs = self._preprocess(obs) # 将obs转为tensor # 2. 模型推理 with torch.no_grad(): q_values = self.model(processed_obs) # 3. 选择动作 (例如，训练时用epsilon-greedy，比赛时用greedy) if random.random() < self.epsilon: action = random.randint(0, self.num_actions - 1) else: action = q_values.argmax().item() return action

重要提示：controllers/dqn.py只是一个控制器示例，它不包含训练代码。你需要自己准备训练环境和训练循环。通常的做法是：

1. 复制一份main.py，将其改造成一个可以与环境交互的Gym风格接口。
2. 使用像stable-baselines3这样的RL库来训练你的模型。
3. 将训练好的模型保存下来，并在dqn.py控制器中加载。

4.4 远程连接：让你的智能体独立运行

最终，你可能希望你的智能体作为一个独立的服务运行。项目提供了controller_client.py作为参考客户端。

python controller_client.py --player 1 --bot my_awesome_bot

这个脚本会连接到本地的ws://127.0.0.1:8765，注册为玩家1，并启动一个名为“my_awesome_bot”的控制器。你需要修改这个脚本的核心部分，将其中的决策逻辑替换成你自己的AI模型。

远程控制器的优势：

• 语言无关：只要你的AI服务能处理WebSocket和JSON，可以用任何语言（Go, Rust, C++）编写。
• 资源隔离：你的AI模型可以运行在拥有强大GPU的机器上，而竞技场主机可以运行在另一台机器上。
• 动态更新：可以不停机更新你的AI模型。

5. 实战：组织一场锦标赛与性能分析

当你拥有多个机器人后，自然会想让它们一决高下。OpenClaw Battle Arena 提供了一些工具来帮助自动化这个过程。

5.1 使用 Tournament Runner 进行循环赛

tournament_runner.py脚本用于聚合多场比赛的结果，生成一个排行榜。假设你已经用trial_runner.py或多次运行main.py产生了许多result.json文件在logs/matches/目录下。

运行以下命令生成排行榜：

python tournament_runner.py --results-glob “logs/matches/*/result.json” --out leaderboard.json

它会扫描所有匹配的result.json文件，并输出如下所示的JSON摘要：

{ “players”: { “script-aggressive_heavy”: { “wins”: 42, “losses”: 28, “draws”: 5, “total_matches”: 75, “win_rate”: 0.56, “total_damage_dealt”: 12500, “avg_distance”: 120.5 }, “script-defensive_kiter”: { “wins”: 28, “losses”: 42, “draws”: 5, “total_matches”: 75, “win_rate”: 0.3733, “total_damage_dealt”: 9800, “avg_distance”: 180.2 } } }

这个排行榜非常直观地展示了不同机器人的综合表现。win_rate是核心指标，而avg_distance（平均对战距离）等统计量则能反映机器人的战斗风格。

5.2 分析比赛日志：复现与调试

除了汇总结果，每一场比赛的详细日志才是真正的宝藏。在logs/matches/<match_id>/目录下，你会找到：

• meta.json：比赛元信息，如参与者、地图、随机种子。
• result.json：比赛结果摘要，包括每回合胜负、耗时、最终统计。
• events.jsonl（如果settings.WRITE_EVENTS_JSONL=True）：一个JSON Lines文件，记录了每一帧的游戏事件。这是最强大的调试工具。

events.jsonl的每一行都是一帧的快照，例如：

{“tick”: 150, “p1”: {“x”: 200, “y”: 300, “state”: “walk”, “health”: 100}, “p2”: {…}, “actions”: {“p1”: 2, “p2”: 0}}

你可以写一个小脚本，将这些数据可视化，重现整场比赛，分析你的机器人在哪一帧做出了错误决策，或者对手的某个连招是如何命中的。

5.3 性能调优与避坑指南

在开发过程中，我踩过不少坑，这里分享几个关键点：

1. 决策速度是生命线SCRIPT_ACT_TIMEOUT_MS默认可能只有50毫秒。对于简单的规则机器人，这绰绰有余。但如果你运行一个庞大的神经网络，50ms可能非常紧张。

• 优化：对模型进行量化、使用更小的网络架构、或者使用ONNX Runtime/TensorRT等推理优化框架。
• 测试：务必在你的choose_action函数开头和结尾打印时间戳，或在trial_runner的无头模式下观察是否有超时警告。

2. 观察空间的稳定性你的机器人依赖obs字典里的字段。如果未来项目更新，增加了新字段或改变了字段名，你的机器人可能会崩溃。

• 防御性编程：在访问obs字段时使用.get()方法并提供默认值。
• 版本管理：关注项目的协议版本 (PROTOCOL.md)。如果协议升级，你的机器人可能需要适配。

3. 动作的连贯性与“手感”由于动作是瞬时的，实现“按住移动”或“连招”需要状态记忆。一个简单的做法是在你的机器人类里维护一个内部状态：

class MyBot: def __init__(self): self.last_action = 0 self.attack_combo_step = 0 def choose_action(self, obs): # 实现连招逻辑 if self.attack_combo_step == 0 and self._should_start_combo(obs): self.attack_combo_step = 1 return 5 # 轻攻击第一段 elif self.attack_combo_step == 1: self.attack_combo_step = 2 return 5 # 轻攻击第二段 # ... 重置逻辑 # 实现“按住后退” if self._want_to_move_away(obs): self.last_action = 1 if obs[“my_facing_right”] else 2 return self.last_action else: self.last_action = 0 return 0

4. 利用随机种子确保可复现性对于强化学习训练，可复现性至关重要。settings.py中的RANDOM_SEED可以固定游戏的随机因素（如随机出生点）。在trial_runner.py中，也可以通过参数传递种子，确保多次运行同一组比赛得到完全相同的结果，这对于排除随机干扰、确认策略改进至关重要。

6. 项目架构深度解析与扩展方向

要真正玩转这个竞技场，甚至为其贡献代码，理解其内部架构是很有帮助的。

6.1 核心模块职责

openclaw-battle-arena/ ├── main.py # 游戏主循环 & 总调度器 ├── fighter.py # 角色实体类（状态、物理、动画） ├── controllers/ # 各种控制器的实现 │ ├── base.py # 控制器抽象基类 & 观察数据模型 │ ├── heuristic.py # 内置的启发式AI │ ├── script_file.py # 从本地文件加载Python脚本的控制器 │ ├── ws_server.py # 内嵌的WebSocket服务器 │ └── remote_ws.py # 与远程WebSocket客户端通信的控制器 ├── controller_client.py # 远程控制器的参考实现（客户端） └── settings.py # 所有可调参数的大本营

• main.py：这是心脏。它初始化Pygame，创建游戏窗口，管理Fighter实例，并在一个循环中：
  1. 处理输入：轮询所有控制器（无论是本地的heuristic、script还是远程的ws），获取它们当前帧的动作。
  2. 更新状态：调用fighter.update()，根据动作应用物理（移动、跳跃、重力），检测碰撞，处理攻击判定和伤害计算。
  3. 绘制画面：将角色、背景、血条等绘制到屏幕上。
  4. 广播观察：将当前游戏状态封装成观察字典，通过WebSocket服务器广播给所有远程控制器。
• fighter.py：定义了Fighter类。它包含了角色的所有属性：位置、速度、生命值、当前状态（如idle,attack_heavy）、状态计时器、攻击判定框等。update()方法是核心，它根据当前状态和收到的动作，决定下一帧的状态。
• controllers/：这是“输入”的来源。每个控制器都必须实现BaseController接口，核心方法是get_action(fighter, opponent, stage) -> int。主机每帧向每个控制器请求动作。
• settings.py：这是游戏的“平衡性配置表”。你可以在这里调整重力大小、跳跃力度、移动速度、轻/重攻击的伤害和冷却时间、角色血量、舞台大小等等。修改这些参数会极大地影响游戏节奏和机器人策略的有效性。

6.2 如何添加一个新的控制器类型？

假设你想添加一个通过HTTP REST API接收动作的控制器。

1. 在controllers/目录下创建新文件，例如http_api.py。
2. 定义一个类，继承BaseController。
3. 实现__init__方法（用于建立HTTP连接池或设置URL）。
4. 实现get_action方法。在这个方法里，将游戏状态（fighter, opponent）转换成你的API所需的格式，发送HTTP请求，并解析返回的动作ID。
5. 在main.py中，找到控制器工厂函数（可能是_create_controller），添加对新控制器类型（如"http"）的支持。
6. 最后，在settings.py中设置P1_CONTROLLER = "http"，并添加相应的配置项（如P1_HTTP_URL）。

6.3 路线图与未来展望

根据项目的docs/ROADMAP.md，社区正在向一个更完善、更公平的AI竞技平台迈进。以下几个方向特别值得关注：

• 更丰富的观察空间：目前观察数据比较基础。未来可能会加入“对手上一帧动作”、“双方相对速度”、“攻击判定框的实时位置”等更高维的信息，为更复杂的策略提供支持。
• 更复杂的动作空间：当前是8个离散动作。可能会引入“组合键”（如“重攻击+前冲”）或连续动作空间（如直接输出移动力度），但这会大大增加策略复杂度。
• 标准化比赛与天梯：建立一套自动化的锦标赛系统，支持瑞士轮、双败淘汰等赛制，并维护一个公开的Elo或TrueSkill天梯排名。
• 回放与观战系统：将events.jsonl文件转换成可视化的回放视频，或提供一个实时观战的WebSocket接口，方便比赛直播和策略分析。

这个项目的魅力在于，它不仅仅是一个工具，更是一个协议和标准。它定义了AI格斗智能体如何与环境交互的边界。在这个边界内，你可以尽情施展才华，无论是简单的规则，还是最前沿的深度强化学习算法，都可以同台竞技。而公平性，由这个开放、透明的竞技场来保证。