游戏逻辑

推荐游戏方在游戏的 README 中附上游戏逻辑的 Git仓库 链接，让选手们能通过 Git 轻松获取最新的游戏逻辑 代码、文档 等。我们认为这比在平台上提供「下载游戏逻辑」的功能更方便选手使用。

How it works

Hiper 使用 Docker 构建、运行游戏逻辑。

游戏逻辑程序目录会被绑定到 /app 目录。

build game logic

源码文件命名为 src，后缀名与上传时的后缀名相同。

构建容器请将构建产物保存在游戏逻辑程序目录中。

run game logic

游戏逻辑容器命名为 game_logic。

其 ENTRYPOINT 并非必须是“启动游戏逻辑”，更准确地说应当是 “对局控制程序”。

评测机 会将 AI列表 与 对局定制信息 作为参数传递给 游戏逻辑容器 的 ENTRYPOINT。

• AI列表：按顺序给出各参加对局的 AI 的 id。以 JSON 格式传递。e.g. ["1", "2", "3"]
• 对局定制信息：一般由游戏开发方自行约定，评测机只负责传递。以 JSON 格式传递。e.g. {"seed": 123}

游戏逻辑容器应当提供的输出：

• 比分，按顺序给出参与对局的每个AI的分数，与输入的 AI列表 对应。
• 回放数据。

由 游戏逻辑容器 来决定如何将 AI程序 运行为实例的 玩家；因为可能出现 THUAI6电子系赛道 那样要打上下两半场才能决定一局胜负的。一份 AI 程序在一场对局中可能会运行多个实例，这种实例称为玩家。

Hiper 允许有不管怎样花里胡哨的游戏流程，只要最终的输出和输入匹配即可。

游戏逻辑容器与评测机的通信

游戏逻辑容器可通过「命名管道」与评测机通信。命名管道的路径为 /tmp/pipe。

• create_player <container_name> <ai_index>. 用某个参加对局的 AI 程序创建一个玩家。container_name 为玩家的容器名（游戏逻辑应自行保证容器名的唯一性，即「一场对局内」不能同时存在多个同名容器）。ai_index 为 AI 程序在 AI 列表中的下标（从 0 开始）。
• remove_player <container_name>. 移除一个玩家。container_name 为玩家的容器名。
• end_match <end_info_json>. 结束对局。

// end_info_json
{
    "scores": [0, 1, 2, 3], // 比分，按顺序给出参与对局的每个AI的分数，与输入的 AI列表 对应。
    "replay": {} // 回放数据
}