5.6 局面判定

　　局面判定主要包含两个部分：将军判定、胜负判定。将军判定是为了实现双方在被将军时必须解将的逻辑，胜负判定是为了迅速判断游戏是否结束。这两个部分在整个象棋游戏中不可或缺。

　　5.6.1将军判定

　　在将军判定当中，项目中采取了一些小技巧，即在走完一步棋之后，将对方的将(帅)看作车马炮兵等走出一步看是否能够吃到本方对应的车马炮兵等，如果能够吃到，即表明被对方处于被将军的状态(在将的行走中，“别马腿”的判断与马本身有区别)，反之则表示没有被将军。

　　5.6.2胜负判定

　　在人们的认知中，该回合中执棋的一方，若搜索完所有的可走方法，依旧处于被将军的局面，那么就认为本方已经被将死。如果采用走完一步便搜索对方是否被将死，无疑会导致每次走子会多搜索一层，所以项目采用了本回合开始时正常搜索走法，若走完被将军便跳出循环，采用新的走法，若所有走法都是走完依旧被将军，则执棋放被将死。

　　如此便有效完成了胜负判定。

　　5.7 图形界面生成

　　图形界面的生成主要基于windows的窗口消息机制，并且在游戏中使用的是不阻塞

　　的消息循环。所幸，cocos2dx自身封装了windows装口的创建，并提供了Ontouch()来响应点击事件。在绘制窗口前，将所有的节点加入场景中，在每次窗口更新(在封装的消息循环内，绘制之前都会调用)的时候，对于加入的元素做对应的操作，即可实现元素在窗口的绘制。效果如图5-7-1：

　　图5-7-1 棋盘初始界面

　　5.8 数据通信

　　为了不局限于人机对战，增加其适用范围，我在项目中加入了人人对战的功能。当点击按钮“联网对战”，就会创建一个监听套接字，指定ip地址，不断监听是否有客户端接入。点击按钮“链接服务器”，该程序就会产生一个客户端套接字，尝试与服务器端通信，若链接成功，便开始通信。在通信过程中，采用自定义的数据个事，在发送和接受端采用统一的格式进行存储和解码，然后做出相应的操作，再继续发送消息。

　　测试与分析

　　6.1 着法正确性测试

　　着法正确性测试实际就是棋子移动逻辑的测试，测试方案也比较简单，我穷举了所有的着进行测试法，因游戏中也会很清楚的显示行走路径，可以很清楚的看到着法是否正确，行走界面如图6-1-1：

　　图6-1-1 行走界面

　　测试了八种棋子的所有走法，确定棋子走法完全无误。

　　6.2 局面判断测试

　　6.2.1 将军判断测试

　　在这里已经可以确定所有着法的正确性，且ai逻辑为被将军时必须解将，那么只需要不断与ai对局，将军ai，看是否会正常解将(在存在解将的方案的情况下)，经过测试得出在被将时，ai能够正确解将，故而将军判断正确。

　　6.2.2 胜负判断测试

　　同样在对ai进行测试即可(因若ai回合玩家依旧处于被将的状态，说明玩家被将死，故不需测试)。项目逻辑设定为当ai无棋可走时，ai不会走棋，自动认输，故只需反复进行多盘游戏，看ai是否符合逻辑即可，被将死界面如图6-2-2-1：

　　图6-2-2-1 胜负界面

　　6.3 按钮测试

　　界面上共四个按钮，只需程序运行时点击按钮看是否实现相应功能即可，按钮功能见表6-3-1：

悔棋	联网对战	链接服务器	新局
还原到玩家上一步状态	作为服务器监听客户端的链接	作为客户端连接到服务器	回到最初的棋盘设定，开始红方回合

　　图6-3-1 按钮功能

　　联网对战测试界面结果如下(分别对悔棋和新局也做了测试)：

　　服务器端如图6-3-2：

　　图6-3-2 服务器端界面

　　客户端如图6-3-3：

　　图6-3-3 客户端界面

　　可以观察到，服务器与客户端数据完全正确，并且同步，四类按钮功能皆正确。

　　总结 在项目的开发过程中，主要还是看到了自身的不足，直到最后，也没有令人满意的人工智能。不过在开发中，还是体会到了很多的快乐，有徜徉代码世界的自由自在，有调试bug时的无力，程序更进一步的欣喜愉悦，最终还是感觉自己交出了一份大学四年的答卷。