zookeeper项目日志

 

第一天（3月17号）

项目主题确定为构建一个类似于zookeeper的小游戏。组队完成，人员构成：小H、小D、小C、小J和我。四个人都不熟悉，以后要多加留意。这次的项目，一定要比上次有所进步。不光是项目的结果上，更重要的是在项目所用的软件工程方法上，以及项目软件的质量上。

 

第二天

1、原版游戏试玩结果：

zookeeper这款游戏很容易上手，故事也简单，游戏规则很明确：满足横或竖有三个或以上一样的图标则会消去。操作是每次只可以交换相邻的两个图标，但是如果交换后没有任何图标被消去，这两个图标还是回到原地。背景音乐应当是很简单的midi音乐。

功能都在首页菜单项里，主要有：Game Start, How To Play, Story, High Score。游戏等级划分主要是时间条移动的快慢以及升级所需消去图标的个数。游戏有类似于道具一样的额外奖励是一个随机跳转的小图标，单击时跳到哪个小图标，整张图里所有的同类图标就会消失（这个东西很有用，可以一下子连带很多图标被消掉，但是是随机出现，看人品）。

2、关于游戏制作所找到的一些材料：

大部分大型商业游戏应当是用C++所写，小型游戏用Java写的也有。我们这个游戏应当算小游戏吧（植物打僵尸也算小游戏）。

下面是一篇介绍游戏开发工具的文章：

“ 业界标准的游戏制作团队包括设计师（策划）、艺术家（美术）、架构师（程序）三部分，同时也要加上QC（测试）小组以保证迭代开发中的快速验证、除bug与模块稳健度。那么这次就主要介绍各个工作岗位的开发人员需要使用和建议使用的各种开发工具。

    先从程序说起。程序员需要使用的工具，依据游戏平台的不同、开发端的不同有着不同的区分。但是一般都离不开C++，因此必备的开发工具就是Visual Studio。以前PC平台上多用C开发，现在基本已经全部采用C++，但考虑到运行效率，有些网络游戏的服务器端开发仍然使用C。但是完全依靠人工写代码不但低效、劳累而且容易出错。因此出现了许多中间件（MiddleWare）开发套件，这些是封装好的图形、物理、粒子、AI、网络、声音、UI模块，内部嵌入了各种游戏中使用的函数。程序员只需要写好接口、加入针对性的运算函数便可以把这些部分的工作量减少很多了。而比较大型的中间件可能包含了这其中的许多模块，这便是游戏引擎（Game Engine）。游戏引擎有很多种，有综合性的，比如unreal tournament、quake 3D、LithTech、jupiter等等。也有专注性的，最主要专注于两个方面——图形和物理。比如专注图形的ogre和专注物理的havok、ode，现在由于网络游戏开发比较热，引擎的网络部分也得到重视，一般采用C/S方式，也有P2P的方式，有些引擎会提供强大的分布式运算和ado技术。但也有一些引擎没有网络部分，一是由于调用数据的不确定，二是网络端会有专门的优化，许多程序员会写专门的算法处理这一部分。图形用户界面（GUI）有的为团队自己写，因为各种游戏界面需求不太一样。有的用引擎或第三方提供的GUI包写的。有很多……比较著名的是GTK+、wxWidgets、Qt

美术方面，二维的标准开发工具是painter和photoshop，三维的标准开发工具是3D max和maya。二维不用多说，基本多少年都没什么变化。输出的标准格式早期是pcx、bmp，现在最常用的是tga、dds，tga是标准工业格式，已被业内大多数企业所接受很久。dds是为对应directX节省缓存的一种压缩格式，本身也有很多种格式，效果没有无损压缩图像那么好，但对于提高显示效率和节省游戏容量效果很好（图形是游戏中最占容量的部分）。png也是很好用的一种格式，正被逐渐接受。jpeg很少被使用，一是因为图像有损压缩，二是不支持alpha通道，无法实现一些特定效果。三维最早是max和lightwave，但maya的崛起使得其也逐渐成为游戏开发的标准工具。现在不少制作团队都开始转向maya，lightwave在欧美开发团队使用的比较少，日本的开发团队则非常喜欢lightwave。除此之外，由于CG产业的迅猛发展以及开发要求的提高，许多新型的优秀三维工具也进入游戏开发领域。比如softimage、motion builder等，它们在动画制作方面有着强大的功能。三维输出的主要格式是max（流行）和obj。游戏中各种绚丽的效果是用粒子实现的，这也是美术工作的一部分。一般没有什么标准的工具，只要美术制作出粒子最基础的纹理材质图片（很小的二维图形，常用png格式），再导入到程序中计算路径、发射角、密度、生命周期、着色、受力等。也出现了一些独立的专门制作粒子特效的工具，二维游戏里面最常用的是particle illusion（它本来是用于影视粒子特效制作的）。三维的有很多，比如particle accelerator、particle editor等等。”

除此之外，还有一些网站：

http://resource.gameres.com/ 

目前看，做游戏的语言最主流的是C++，但是据说上手不是很简单，而且我觉得C++确实比Java复杂。

 

 

第三天

今天软件构造课上听郑滔老师讲C++对于一些设计模式的实现，对于C++实现我们这个游戏我又有了点信心。想到我们这次的项目一定要有一个可行的策划。

晚上看见小C和小D在写文档，女生真是好，勤快。小D说要做一个新的logo~我嚼着很有意思。。。Logo一定要有的~~

定下来后天开会，想了想开会要讨论的事：我举得有：1、需求分析，当然包括各种东西。2、讨论实现语言、工具，这样我们可以确定要不要借书，要不要看些东西。3、计划安排

 

第五天

今天我们开会，从上午9点一直讨论到中午1点多，中间还有一个吃饭的过程。大致讨论了项目的需求，后面还讨论了创新杯的事。

关于项目，需求分析并不像我想得那么复杂，这个系统的需求还是很明确的。但是为什么只实现单人游戏的部分，而连多人游戏一起实现了。我觉得其实并不复杂，后面的软件设计与构造中，我一定要坚持将软件做的具有可扩展性，方便后面实现网络功能。我分到的工作是画时序图，以及每个人都要写的用例及用例分析。其实我不赞成每个人都写一个用例分析，这样似乎是浪费人力。

关于创新杯，我觉得我们的想法都很局限，完全没有什么令人兴奋的点子。以后要注意留心。

晚上画操作游戏用例的流程图，没有画出来，一是时间分配不合理，效率太低，导致很多时间不知不觉都过去了，自责自责。开始还向大家提醒一定要规定合适的计划，结果竟然第一个不遵守计划的就是我自己。还有就是这个确实很难画啊，好纠结，游戏系统还没有合适的划分，画了一点之后脑子又乱了，又不敢“独断专权”地自己将系统结构设计好。

 

 

 

第八天

昨天晚上奋战到1点种，终于是完成了关于游戏操作部分按照MVC所画的类图草图。今天开会进行了讨论，我们对设计的细节进行了一些讨论。

对于界面设计，和别人还是有点冲突，因为我一直坚持设计的精简。在功能上也是如此，实在觉得没有实现多个难度的必要，这些都不符合简单主义。而且独立的游戏设置界面也是我不想看见的。没有设置！才最好。讨厌玩什么都要我自己去一点点的设置。应该为用户作出最体贴的打算。晚上看了篇网摘叫：Web设计中的苹果风。喜欢那种精致的图标，大大的图像，清晰地组织，巧妙的留白。设计，就应当是这样。

对于类的设计，很高兴自己关于MVC的一些想法大部分都被采用了。和大家讨论也使自己对自己的设计更加明确，也讨论出了一些自己想不出的细节。