设计目标与主要问题.md

目标

1. 易用. 有着简单且清晰的API接口. 可以无缝对接AI方面的伪代码.
2. 快速. 复制一次游戏状态应该在毫秒级别.
3. 易于维护. 由于mhy会定期更新, 因此代码必须可以维护.

可以做出妥协的:

1. 不准确模拟. 允许在部分环境下出错, 只要这些场合并不常见.
2. 人机交互. 本项目的重心并非GUI. 但也需要保持最低限度的可供调试的界面.

难点

游戏状态定义

为了提供易用的API, 需要将游戏定义为可以以矩阵数据表示的形式.

行动定义

为了易于AI训练, 需要将行动定义为矩阵形式. 然而, 行动存在维度爆炸问题, 例如打出一张2费卡牌需要同时指定卡牌和所消耗的骰子(这会导致10*16*16个选项).

费用预计算

七圣召唤中有很多减费或者增费机制, 这些机制要求提前知道执行的动作是什么. 因此我们需要在获得动作后, 执行动作前增设一个预计算阶段来处理这些问题.

伤害结算

复杂的增伤流程(经典问题, 莫娜大招的增伤顺序和其他增伤不一样). 如何处理结算顺序?

复制游戏状态

许多AI算法要求在博弈树上的每一个节点都保存一次游戏状态, 因此需要快速的状态复制方案. 为了使得复制足够快速, 任何组件都不能引入循环引用; 在监听器架构下这会导致复杂的编程问题, 该如何避免?

架构

说白了, 上面两个问题其实都是架构问题. 监听器真的是一个好方案吗? 除了监听器有其他什么方案? 监听器能否改进一下?

API

可以确定的是, API大致应当如下:

Game:
    proceed(action)->Game: 根据action转移到下一个状态. action是一个特定的类. 注意返回的状态必须完全是深拷贝以避免引用.
    state: 返回当前游戏局面, 一个良好定义的numpy矩阵格式.
    valids: 返回一条布尔掩码, 表明可行的行动.
    mover: 返回当前行动方
    phase: 返回当前游戏阶段. 注意行动阶段只能切人和死亡切换阶段只能切人是两码事,所以这很重要.

游戏不会实现log功能,因为这会极大地加重复制成本. 涉及到历史的卡牌结算(比如说艾琳)可以通过增设记录位来解决.

log可用于DEBUG.