游戏逻辑
推荐游戏方在游戏的 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": {} // 回放数据
}