围棋博弈程序的实现与思考（6）——博弈树的构建

为了实现UCT算法，需要在内存中构建一棵博弈树，博弈树的每个节点是博弈过程中的一个局面。

一个显而易见的方法是——构建树形的数据结构，每个节点保存3类信息：1）该节点所代表的局面。2）局面信息（当前收益值与被尝试次数）。3）子节点的索引。

出于以下两个考虑，我并没有用这个方法。

1）尽可能地减少内存占用。

2）细究之，围棋博弈过程中产生的拓扑结构并非树，而是图——不同分支下的局面亦可能重合，尽管这种菱形重合的频率是很小的。

我用了一个哈希表来保存必要的信息，而只在逻辑上存在树形（包含少量的菱形重合）的数据结构。哈希表的表项保存两类信息：1）哈希值。2）局面信息。由于采用的哈希算法重合率极低，我假定不同局面的哈希值是不会重合的——即使有重合，在UCT这样的概率算法中亦无伤大雅。在这个哈希表中，哈希值不但是局面的索引信息，而且是局面的唯一标记。

两种方法优劣不明。

这里贴一下前文中所述的UCT算法：

1) 从博弈树的根点开始向下搜索，执行2）。

2)遇到节点a后，若a存在从未评估过的子节点，执行3），否则执行4）。

3) 通过MonteCarlo方法评估该子节点，得到收益值后更新该子节点至根节点路径上所有节点的平均收益值，执行1）。

4) 计算每个子节点的UCB值，将UCB值最高的子节点作为节点a，执行2）。

5) 算法可随时终止，通常达到给定时间或尝试次数后终止。

根节点下平均收益值最高的子节点作为算法的输出。

在步骤2）中，也就是要判断子节点存不存在于哈希表中。在步骤3）和4）中，则需要更新哈希表中的局面信息。

最后提一下我采用的哈希算法——zobrist hashing，这个真是哈希棋类游戏局面的利器啊，维基百科zobrist hashing词条：zobrist hashing。