六象棋设计文件.docVIP

一个六子棋的设计文档 详细设计 一、 数据结构 本程序采用的一个很严谨的数据结构。在经过仔细分析之后发现，不管是自己要获胜还是对手要获胜，都需要在棋盘上构造一条6个子的直线。这样，本程序把所有的可能组成的6个子直线都存下来（总共924条）。于是，我们可以很容易构造出对手和自己的活棋表，存下各自现在有几个活2活3等等。每次我们判断一步棋放下后产生的影响的时候，我们就只要把这个子放入棋盘，然后再次更新自己和对手的活棋表更新，然后和放入之前的活棋表进行比较就可以得出这个棋到底产生了什么样的作用，这样对实现我们的算法提供了很方便的方法。本程序已经通过chList和PointStr这两个类来实现了相关功能。 二、程序结构 Main()函数。Main()函数实现了，程序与平台通信，和对searchGoodMove函数的调用。 Bool Judeg()函数。这是一个评估函数，它可以返回两个着法的优劣。 SearchGoodMove（）。这个函数使整个程序最关键，也是最核心的函数。函数从前往后，分为两大部分。分别是对找到一个颗子的着法，和找到第二颗子的 着法。执行过程如下： 一直找到连1都没有了，那么可以任意填子了。第二颗子的走法跟第一个子的走法是一样的，不同的是它们有不同的判断顺序。 这样只要searchGoodMove()执行完了，那么程序就找出了目前来说最好的一种着法。 （四）系统实现 参加这次比赛，真正体会到了团队协作开发程序的不容易，两千多行的代码，调试时更需要较高的调试技巧。惭愧的是，第一次验收的时候，由于时间仓促，我们只交了一个只会堵四的简单程序，勉强通过了第一次验收。 第一次验收之后，我们才真正开始着手六子棋程序的开发。 一、 规划 — 整体构架。经过讨论后，我们决定了基本的开发思路，即根据棋盘中四线的个数，三线的个数，二线的个数来决定棋子的位置，同时兼顾堵敌人和构造自己，刚开始的时候，我们考虑的情况比较简单，下棋的时候才发现真正下棋比我们想象的复杂多了，经过几次实际下棋后，我们重新进行了设计，进一步加强了程序的判断能力。 二、 分工 — 共同努力。以前我们参加过几次ACM程序设计大赛，有一定团队合作的经验，于是我们明确了各自的任务，就开始了艰苦的开发工作，当出现一个问题而无法进行下去的时候，我们三个人就会聚到一块，共同讨论，即使有时候我们不能想出一个比较好的算法去解决这个问题，但我们总是尽量使算法能够贴近我们的实际想法。为了使程序能够尽可能多的考虑到各种情况，我们首先画了流程图，然后下了一晚上六子棋，把我们程序没有考虑到的情况都加到流程图中，接着我们就根据流程图模块化实现程序，每当写好一个子模块后，我们首先进行模块化测试，想出很多测试用例，不断测试这段代码，直到发现不了任何问题，这也为我们最后进行整体调试节省了很多时间。 三、转型 — 面向对象实现。在开发过程中，有时我们也会因为观点不同而争吵起来，但这种争吵使我们的技术水平整体提高了很多，使我们对六子棋的认识也加深了很多。随着程序的不断开发，我们发现用面向过程开发有很多缺陷，于是我们转向面向对象开发，将写好的函数都封装到类中，便于调用。 四、调试 — 坚持就是胜利。当开发出初步版本后，调试成了开发之路上的第一只拦路虎，由于程序量过大，我们整整花了一晚上时间才让程序能够基本按照我们的意图去走，有时候是因为一些字符写错等等的小错误造成的，或者是复制代码后没有进行相应的修改，这些错误还都比较好改正，困难的是实际下棋很多步后发现它没有按照我们当初的设想执行，尽管VS2008具有强大的调试功能，有时候还是需要单步跟踪很长时间，以至于很多次我们都产生了放弃的念头，但最终比赛的信念支持着我们，使我们坚持了下来，条件断点，单步执行，执行到光标处，是我们常用的调试手段，最后在我们三人的共同努力下，终于将我们当时能够发现的BUG全都解决了。 五、检验 — 小试牛刀。实践是检验真理的唯一标准，为了检验我们程序的能力，我们找来了很多其他队伍的程序，逐个与他们PK，每当我们输了的时候，我们就会一起讨论我们的棋的缺点，然后尽力去改进，我们首先赢了去年的冠亚军，接着与别的队伍PK，在这个过程中，我们又对我们的程序做了很大的提升，并且将我们能够找到的程序都比了一遍，经过这一环节后，使我们对自己的程序有了很大的信心，这也是我们能够继续坚持下去的动力之一。 六、提高 — 未完结之路。经过预赛的一番较量，我们顺利的杀入了决赛。预赛之后，我们就开始考虑如何进一步改进程序，我们想到做搜索，起初由于对时间和数据量估计不足，第一次修改后我们认识到想要每一步都做搜索，只能搜索有限的一两步，对程序改进不大，于是我们想改为只做VCF搜索，经过一整天的开发