前面已经讲过了棋局表示、着法生成、搜索算法（包括搜索辅助）， 在象棋程序中如果说搜索算法是心脏，那么局面评估就是大脑。搜索算法负责驱动整个程序，而局面评估则负责对搜索的内容进行判断评价。因而搜索与局面评估是整个程序的核心。
首先，先介绍一下在局面评估中需要考虑的因素。就不同的棋类可能要考虑的因素略有差异。在中国象棋中所要考虑的最基本的几个因素包括如下四点：
1、子力总和
子力是指某一棋子本身所具有的价值。通俗地讲就是一个棋子它值个什么价。例如，车值500的话，那可能马值300，卒值80等等。所以在评估局面时，我们首先要考虑双方的子力总和的对比。比如红方拥有士象全加车马炮，而黑方只有残士象加双马，则红方明显占优。
2、棋子位置（控制区域）
棋子位置（或称控制区域）是指某一方的棋子在棋盘上所占据（控制）的位置。例如，沉底炮、过河卒、以及车占士角等都是较好的棋子位置状态，而窝心马等则是较差的棋子位置状态。
3、棋子的机动性
棋子的机动性指棋子的灵活度（可移动性）。例如，起始位置的车机动性较差，所以我们下棋讲究早出车。同样四面被憋马腿的死马机动性也较差。
4、棋子的相互关系（包括攻击关系和保护关系）
这一点的分析较为复杂，因为一个棋子与不同的子之间往往存在多重关系。如：一个马可能在对方的炮的攻击之下同时它又攻击着对方的车。
在我的程序中，估值函数最后返回的是双方总分的差值，而各方的总分就是上面所提到的四个因素的打分的总和。
对于子力打分和控制区域打分，只要遍历棋盘，当遇到棋子时简单地去查事先定义好的“子力价值表”和“控制区域价值表”，取出相对应的值进行累加即可（这些具体值参考了前人的程序并作了适当的调整,今后仍应根据电脑下棋所反映出的实际问题对这些值作适当修改）。对于机动性打分，需要求出各个子总共有多少种走法，然后根据各个子所不同的机动性价值每多一种走法就加一次相应的分数。
对棋子相互关系的打分，我先定义了一个关系表的结构类型
其中nCChessID表明棋子类型，nUAttackCount和nUGuardCount分别记录该正攻击该子的棋子数量和正保护该子的棋子数量，UnderAttack[5]和UnderGuard[5]则存放攻击该子和保护该子的具体棋子的类型。因考虑实战中很难出现同时有超过五个棋子攻击/保护一个子的情况，故数组下标设定为5。
当遍历一遍棋盘之后，子力打分、控制区域打分和机动性打分都可以完成，而关系表也可以填完。之后，再根据关系表来具体考察棋子的相互关系，进行关系打分。
分析关系时，首先，对王的攻击保护应分离出来单独考虑，因为对王的保护没有任何意义，一旦王被吃掉整个游戏就结束了。
其次，对一个普通子，当它既受到攻击又受到保护的时候要注意如下几个问题：
1、 攻击者子力小于被攻击者子力,攻击方将愿意换子。比如，一个车正遭受一个炮的攻击，那么任何对车的保护都将失去意义——对方肯定乐意用一个炮来换一个车。
2、 多攻击单保护的情况，并且攻击者最小子力小于被攻击者子力与保护者子力之和,则攻击方可能以一子换两子。
3、 三攻击两保护的情况，并且攻击者子力较小的二者之和小于被攻击者子力与保护者子力之和,则攻击方可能以两子换三子。
4、 攻击方与保护方数量相同，并且攻击者子力小于被攻击者子力与保护者子力之和再减去保护者中最大子力,则攻击方可能以n子换n子。
可能上面这几条说的大家有点晕，待会结合具体程序可能更易于理解。当然，上述四条只是覆盖了最常见的几种情况，覆盖并不全面。而且，并没有直接地重新考虑双方兑子之后的控制区域及机动性变化情况（之所以说没有直接考虑，是因为搜索继续展开结点后仍会考虑这些因素，只是目前小生尚不知这样效果是否受影响）。所以，如果下一步要对程序进行改进的话，应当在此多做文章……
下面是CChessEvaluate.h的代码实现：
文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览33845 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！