上一项目的总结
项目大事记
2007.3 项目基本上算是进入真正的开发阶段
2007.6 新的投资人老陈，老谭加入
2007.12.31 第一次面向玩家测试，程序频繁崩溃
2008.1-2009.3 研发由短平快迅速上市的方针改为做高品质的产品
2009.3-2009.6 和山东某公司合作运营,效果不理想
2009.3 拟被某上市公司收购，未成功
2009.4.18 第一次面向玩家的大规模测试,效果比较理想但人数上不去,内存占用太高
2009.7 被另一公司收购
2009.12 换游戏名称第一次面向玩家的大规模测试,客户端报错平凡,服务器宕机,人数上不去
2010.3 再次正式上线运营,效果不理想
我的情况
我于2008年5月加入公司,进入公司主要负责世界编辑器、粒子编辑器、物理系统的编写。我并没有直接参与到游戏客户端代码的编写。大多数工作都是在负责游戏相关工具的开发以及技术难点的公关工作。
我的责任：
一、没有过多的参与到游戏本身代码的编写和监管之中。
二、没有顶住来自市场或投资商的不切实际的需求变更。
程序问题
一、程序底层没有细致规划，各模块耦合太大。
由于游戏最初的定位非常简单，只是简单将美术资源替换和修改，以及非常简单的程序功能的改动（源有代码为2005年左右的基于DX8的代码），然后马上上线运营。不过经过市场检验发现游戏程序根本无法达到基本要求。于是开始大刀阔斧的改程序加功能。当然这些改动还是有一定的成效的，不过对于一款商业游戏软件来说还是有很大的距离。当我加入项目组时，整个游戏连世界编辑都没有，美术在设计场景时还要两个人一起，一个用人在游戏里面跑，一个用笔记录对应的坐标点。。。。。。无语。最初游戏中连最基本的场景管理等都没有。而且各个模块之间基本上没有界限，该分开的地方不分开（一个与脚本相关的CPP文件居然有24000多行。。。。。。），该抽象的地方不抽象。可以这样说大部分人都还停留在以面向过程的程序设计思想在写程序（虽然项目后期有了很大改观，可是参与者基本上都已经无能为力了）。由于各模块的偶合太大，也就造成了以后对任何功能的修改和添加都可能引起一连串的BUG。
二、第三方库的选择和使用都有很大问题。
每个第三方库都有自己的特点和使用技巧，但是在我们的项目中对第三方库的使用很有问题。比如CEGUI，到项目结束我们团队里面的人还没有一个人敢拍胸脯说“我能把CEGUI用好！”。还有lua脚本的使用也是如此。
三、需求不断变化已有功能不断返工。
这个不太好说，如果有一个项目统管者我想应该好很多吧。
四、程序员水平参差不齐，编程经验及其缺乏。
这个没有什么好说的。公司的待遇只有这么多，招聘的人员水平也只有这个样子（大部分是没有从业经验或才从学校毕业的）。唉只有叹息。。。。。。不过团队中的人能在这样的框架下写成这样效果我已经感到欣慰了。至少他们通过这一次锻炼提高了非常多。
五、具体功能的实现缺乏细致的设计规划以及充足的时间来具体实施。
具体功能的实现缺乏规划这个是一个比较普遍的情况。当然这有如下几个主要原因a、需求提的太匆忙，给程序留出的时间太少。这一点我的体会非常深，从我进入该项目组以来整个项目组的人都是在不断的赶新功能，缺乏一些大的规划和设计。这些功能基本上都是想到一个感觉不错就立马要加，而且都是说，没有这个就不能上线。等这个功能完成了又会要求做另外一个类似情况的功能，如此循环程序就不断重构原有代码和添加新代码。b、具体实现人员由于缺乏经验或太过于繁忙没有去设计和规划，只是一味的为完成任务而完成任务。这也是造成一旦需求有所变化或调整，那么代码改动会非常大。c、游戏功能的添加与取消太过随意。这个问题我的影响特别深，游戏原来有基于二维格子的自动寻路功能，没有精细碰撞，没有跳跃等，一段时间后提出要求说需要精细碰撞和跳跃（由于时间等原因去掉自动寻路），好既然决定那么程序就开始动吧，程序写碰撞算法，美术准备碰撞模型等。过来一段时间这些基本ok后，另一个运营商要求自动寻路必须加，好又再次把自动寻路（本来想直接加3D自动寻路的结果又一次被否决了，还是使用2D寻路,实际效果并不好勉强可用。。。。。）加上去。
六、项目前期及中期基本上没有必要的测试。
我们的项目可以说能走到今天简直是奇迹。在项目的前期和中期基本上没有专门的测试。我所了解到的测试基本都是程序员自己实现了功能后自己简单的测试（有的可能根本就没有测试过），最多在加上相关的策划人员配合测试。经过几次阶段性开发后，公司内部才开始组织专门的测试部门进行相对系统的测试。在短短的有限的一两个月中测试出的BUG个数就高达2800多个，当然这里面还不包括那些我们已知但由于底层等原因无法彻底解决的好几个重大Bug（比如客户端的CEGUI的使用，服务器端的数据库访问机制和效率问题等）。
