程序的主体框架

15.3　程序的主体框架

一个程序主体框架的优劣与否，在很大程度上决定了该程序的整体质量，就如同盖房子，尽管每一砖每一瓦都很重要，但是，最终出来的房子是什么样子，却是和动工前的设计密切相关的。

我们的围棋程序也不是一蹴而就的，它需要不断的测试、不断的摸索和尝试，以及不断的交流才能使得棋力不断的提升。对目前计算机围棋发展水平而言，围棋程序的开发在短时间内是看不到终点的。为此，我们就更需要一个具有很高适应性的程序框架，为日后的维护和不断的改进留有充足的余地。这就需要我们在整个开发过程中要始终坚持面向对象的程序设计思想，让程序的各个模块的划分尽可能的合理，保证各个模块独立性的同时，又要注意将模块间的沟通规范化，总之，在程序开发中，通过合理的使用继承和多态等抽象的手段来达到程序框架化的目的。

就像人类棋手的对弈包含两个人和一个棋盘一般，我们首先也将程序分成两个大的部分，棋盘和对弈引擎，对弈引擎也就是对弈者，它们的主要任务就是像人类棋手一样，根据当前棋局状况找到落子点。

接下来，再从这个基本结构上进行扩展。棋盘和引擎都是表面上的东西，是在对弈中看得到摸得着的；但是，在整个对弈过程中，有的东西尽管不是以实体形式存在，但它也是确实在那里的。比如说对局，也就是在棋盘和对弈者之间的一个关联，棋盘可以记录当前的对弈状况，对弈者可以想出如何下棋，但是，比如目前对弈者甲乙是在棋盘A上下棋而不是在棋盘B上下棋，而这件事情却是超出棋盘和对弈者能力范围的，这也就需要对局这个概念才能描述。类似的还有评估器、着法生成器、模式的相关操作等。这些概念虽然不是在对弈过程中切实存在的，但是，它们要么起着一种连接的关系，将其他实体联系起来，要么是大的实体的一个个小的组成部分。尽管这些大大小小、或虚或实，然而，它们的一个共同点就是，它们都具有一个完整的概念，都是一个独立的功能体，它们通过共同的协作，来实现程序的对弈的能力。

“棋盘”是整个围棋程序的基础，它保留着对弈过程中的各种信息。就像真实的棋盘一样，它需要记录棋盘上各个点的状态信息，但是，对于围棋程序来说，仅有这些还不够，这些仅能保证其完成最基本的功能。为了让引擎在对弈时更有效率，避免引擎每次都动态计算一些基本的常用信息而浪费计算性能，棋盘上最好还保存可下点、棋块、气、眼、打吃状态等相关信息，并且保证每次棋盘状态改变时都增量更新这些信息，以此来获得更高的对弈效率。具体的相关实现细节将在后面章节中提到。

前面也提到对局的概念，棋盘和对弈者之间本身并没有直接的联系，只有当两个对弈者想下棋时，他们才和棋盘发生关系，通过对局的概念将两个对弈者连接在棋盘上。如图15.1所示，在对局中涵盖棋盘的全部内容，对局将一些和对弈者有关的信息附加到棋盘上，包括黑白双方的信息、轮到哪一方来落子等。

图15.1　围棋程序结构

对弈引擎是整个围棋程序的核心，一个围棋程序能力的高低，从根本上讲，就是由其对弈引擎水平所决定的，并且，在我们开发程序过程中，引擎模块也是需要花费最多精力的，而且也是需要不断调整和改进的。由此，在设计引擎模块时，既要考虑到性能的需求，同时还要兼顾到结构的灵活性。

为了让对弈引擎能够更加准确合理的生成着法，生成器和评估器作为两个主要辅助模块发挥作用。

生成器和引擎在大体功能上多少类似，都是生成可选点。但是，从定位上讲，引擎是用来进行最终决策，而生成器则起到辅助决策的功能。定位的不同也就决定了其功能的不同，相对于对弈引擎来说，生成器只是一个粗选的过程，它不是像对弈引擎一般只生成一个落子点，它有一系列判断选择策略，通过这些策略，它便可以生成多个候选点，为对弈引擎的进一步挑选做准备。

评估器，顾名思义，就是用来评估某一方在当前这个局面下的优劣程度的，根据实际的需要，要么得到一个或好或坏的直接评价，要么给出一个具体的分数来更加准确的评估。比如，如果想知道一个棋子落下前后的局面的变化情况，那么得到一个数值的评分就更加有意义些。但是，如果只是在蒙特卡洛博弈树搜索过程中想对某个叶子节点进行评估，那么，只得到好或者坏这样的评价就足矣。

除此之外，另外一个主要的模块就是模式相关的部分，该模块在对弈过程中并不直接发生作用，它主要采用间接的方式，通过被其他模块调用来进行辅助决策。模式模块，主要也可以分为两个子部分，其一是模式的获取，其二则是模式的使用。在模式的获取模块中，程序自动从大量棋谱中抓取模式，并获得相关的统计数据；而模式的使用模块则是关于如何将模式以一种更加便捷的方式应用到对弈程序中去。当然，在前一部分也提到过的模式的表示和编码问题也在该模块中涉及。