Pair Project - 吃豆子++

作者:洪锴(本小组),高亦陶(Seven小组)

 解压后运行Pacman.html即可。


背景介绍

Pac-man就是常说的吃豆人了,可以说是一个家喻户晓的游戏。这个游戏最早在1980年推出,很快赢得了各个年龄段玩家的喜爱。《吃豆人》是易学难精的典型:控制吃豆人吃掉迷宫里面的所有豆子,同时尽可能躲避小鬼怪。在Pac-man游戏中也有很多有意思并具有各种功能的道具。在原版游戏中,迷宫的左右是相通的,玩家可以通过这个特点来躲避鬼怪。2010年,谷歌为纪念祝Pac-man推出30周年,在首页上放置了网页版Pac-man,引起了很大反响。

java吃豆子游戏代码 吃豆子的游戏什么名字_3D

              

java吃豆子游戏代码 吃豆子的游戏什么名字_3D_02

Pac-man游戏曾经推出过很多版本,而其中的最初版本存在着一些问题。首先,原版游戏中的道具位置是固定的,且种类有限。其次,原来版本中小人的AI也不是很强,且不具有可选择性,这都是Pac-man可以改进的地方。 

我们所做的改进

基于以上这些原因,我们的游戏添加或更改了原版Pacman的以下特征:

(1)    更多的道具,包括生命,加速,减速,无敌。

(2)    更多的地图,包括很多自制地图。此外边界的上下和左右也联通了起来,提供了更多有意思的玩法。

(3)    可以自选AI难度,包括Normal,Hard,Hell三个难度。三个难度的AI是如下设计的:

  1. Normal: 所有敌方小鬼都随机运动
  2. Hard: 有的小人随机移动,还有的小人按照一定的概率用最短路径算法进行追击。
  3. Hell: 所有的小鬼都有智商,以很高的概率追击玩家。

(4)    评分标准同原版相比也发生了改变。 

以下分别是Normal难度的AI和Hell难度的AI下小鬼追击的对比图

java吃豆子游戏代码 吃豆子的游戏什么名字_Pair_03

 

java吃豆子游戏代码 吃豆子的游戏什么名字_Pair_04

                                         Normal难度的AI                                                                                             Hell难度的AI


游戏开发过程

在工作过程中,我们Pair的两个人经过了很多次讨论,开始时也提出了一些想法。然而由于时间紧迫,很多之前提出的想法并没有得到实施。我们整个游戏的开发过程分为以下几个阶段:

时间点

工作进度

3.9

一起讨论了初步的想法。在讨论了做什么游戏之外, 也讨论了使用什么技术。

这一天主要讨论了对3D的看法,没有否定用3D,于是最后得到了三种使用3D的想法:(1)将blokus扩展到环面上。(2)有高度元素的坦克大战。(3)3维俄罗斯方块。技术上决定使用WPF。

3.10-3.11

周五中午继续讨论游戏的想法。之前的三个想法都有一定的缺陷,主要是不知道3D技术在这些游戏上实现的难度。于是在讨论这些缺陷的过程中得到了一个新的想法:在坦克大战中加入物理引擎。

3.12-3.13

确定了我们要做的东西是坦克大战++。两个人找到了一些关于Wpf和Silverlight的代码和资料进行学习,也看了一些现有的坦克大战的代码。还尝试使用了一个叫Farseer的物理引擎。

3.14-3.16

搭出了坦克大战的大体框架,能有一个坦克在走,能撞墙、转弯,发射子弹。初步处理了碰撞事件。

3.17-3.19

后来发现基于时间的碰撞有时候会出问题,并且坦克大战的元素比较多,且难以创新,于是决定改成了一个相近的游戏:Pac-man。改动的过程还是很快的,并且完成了美工、道具、AI、地图部分。处理了一些bug。

3.20-3.21

共同讨论,完成后期文档。

通过做小游戏,我们学习了WPF和Silverlight的技术,用来实现了我们的Pacman++。


我们所做的改进

 这次Pair-Project的经历让我们得到了很多锻炼。首先让我们对c#的更多特性得到了解,并且也学习了WPF和Silverlight的技术,学会了初步的UI设计和User Experience Design技巧。

结对编程的好处还是很多的,主要有以下一些:

(1) 两个人可以互相分担工作量,可以提出更多Idea,这样就比一个人闭门造车好很多。

(2) 两个人可以面对面交流问题,直接对代码进行回顾和交流。

(3) 与别人工作可以增加自己的工作效率和责任感。

(4) 这种方式有助于发现程序的漏洞和盲点。

 当然,在Pair-Programming的过程中也遇到了一些问题,这些问题主要是由于不在一起交流造成的。当在不同地方写程序时,两个人程序的对接不可避免需要一些调试。

 这个Pair-project大约用了两个人共30-40小时的工作量,同估计的时间是相符的。但对应到每个小模块,所用的时间都比估计的略多。比如我在添加wpf控件时,经常出现估计会用半小时的部分实际上花掉了一个多小时的时间来保证程序畅通的情况。

以下是我们合作时的照片:

  

java吃豆子游戏代码 吃豆子的游戏什么名字_坦克大战_05


Partner的评价

我的Partner高亦陶同学表现的非常优秀,在合作过程中他表现出了很多优点。首先,他的创新能力很强,提出了很多有趣的Idea。其次,他有着很丰富的coding经验,阅读代码和coding能力都很强,也有很好的解决问题的能力,是个很全面的程序员。他写出的代码美观性也很好。此外,他对于TFS的使用也比较熟练,给了我很多帮助。

如果说有什么不足的话,在最开始的设计时应当多考虑一些细节问题。这也是我们都需要注意的地方。

        最后,感谢大家对我们pair project的支持!如果有什么改进的意见,也可以通过留言的方式联系我们,谢谢大家!