我觉得必须从问题的结构入手，尽可能恶心写RL的程序员。核心不是增大搜索空间，而是增大「描述搜索空间」的难度。
- 不规则形状的棋盘，如果强行转成长方形tensor会浪费很多储存空间，总之第一步废掉CNN。
- 棋盘的形状、可部署位置数量随着游戏的进行，会发生改变甚至无限增长。
- 每个棋子具有不同的部署费用，能部署的棋子数量受到玩家当前的部署点数限制，但也可以存在每类棋子的部署上限。部署点数可以无限制增加。这样每轮部署的policy就比较难写成干净整洁的tensor形式。
- 每个棋子的机制（技能）保持不变，但是数值在每次新游戏会重新随机分配，这样棋子的描述也是需要额外探索的。
- 以递归的形式，每个棋子能搭载数量不限的其他棋子（这些被搭载的棋子也能搭载其他棋子，以此类推），这个树的深度可以无限增加。这样就比较难对某个棋子或者位置做embedding。
- 作为对上一条的补充，同一位置可以无限叠加棋子。
- 玩家可以在任意两个位置之间，设立单向/双向传送门，传送门也可以被摧毁，总之进一步破坏local dependency。
- 有多个（>=3）玩家，经典multi-agent加难度。
- 不完全信息，尤其是一个玩家因为随机/玩家使用的道具，看不到其他玩家在过去几轮内的出招、整个棋盘的特定状态。这其实已经能模拟类似石头剪刀布或者囚徒困境的simultaneous game了。
- 游戏总轮数确定，或者用其他方法破坏infinite-horizon/stationary policy的假设。
- 连续时间，随时可以出招，模型的推断时间也会造成影响。
- 把游戏编译成二进制发布，禁止从某个残局存档重开，废掉所有基于backtracking的学习和搜索策略，例如MCTS，但一些经典的policy gradient算法确实不受影响。
- 棋子的部署不是部署在某个位置，而是一整条完整的移动路径（按顺序访问多个位置）。这样进一步加大了表示policy的难度，例如把policy写成长度为n的概率矢量（其中n是可能action的数量）就彻底行不通了，因为n会是一个天文数字，甚至每局都在变。
