第一章   杯具，又见杯具
      公司最终还是散伙拉倒了。一起战斗的兄弟们也四分五裂，各保其主了。
      虽然公司不是我开的，我不亏一分钱，可是还是有一丝的难过。在我的极力抢救下，程序总算是基本稳定了，可是还是回天无力，没能挽回散伙的厄运。
      我只想对老板说：洒家已经尽力了。
      倒闭的原因种种，有公司高层的原因，也有项目质量和进度的原因。
      首先，游戏策划方案失败。游戏逻辑漏洞百出，比如到了Beta测试阶段才还没有经济系统；一些游戏逻辑玩法单调，比如任务简单，战斗技能简单；数值失衡。
      其次，美术太粗糙，给人的第一印象槽糕。
      再次，客户端引擎程序员的离职，现存的bug无人解决，令老板担心后期的开发和上线后的维护能否顺利进行下去。
      现有的游戏如果强行推向市场的话，老板预计收益无法赚回后续的投入。如果推倒现在的策划方案重新开发的话，研发周期估计在6~8个月，研发周期和资金投入上老板无法接受。所以老板最终还是终止了投资，停掉了项目。
      公司给我的离职证明拿到了，上面写着“辞职”、“未予本公司签订竞业合同，可以自主择业”的字样，也算是给足了我面子，对得起我在最后阶段的努力了。
      被遣散之后就又得找工作了。没上班之前，正好可以反思一下这大半年来的开发历程。

                                                                    第二章   本项目的开发历程（只是总结而已，不算泄露商业机密吧）
2.1   启动
      时间：2009年3月
2.2   游戏创意
      时间：2009年3月~2009年9月
      创意草案：无，反正照着《梦幻西游》做呗。
      策划文档：几乎没有，大都凭口述。
2.3   开发   
2.3.1  服务器及客户端程序框架
开发时间：2009年3月下旬~2009年4月中旬。
实现功能：服务器组架构基本完成，客户端与服务器端实现通讯。单个服务器程序底层结构完成，应用层各功能模块划分完成。
存在问题：
（1）网络通讯尚不稳定，服务器性能低下。
（2）此阶段结束时大部分游戏逻辑还是一片混乱甚至空白。

2.3.2  原型阶段
开发时间：2009年4月中旬——2009年7月底
实现功能：
（1）场景管理。包括地图管理，人物行走，传送，寻路。
（2）UI。包括登录界面，人物选择界面，创建人物界面，游戏主界面，人物模型，NPC模型，战斗中怪物模型，装备，武器，动作，光标，物品icon，文字。
（3）人物管理系统。包括人物属性，技能，职业。
（4）物品系统
（5）战斗系统
（6）任务系统
（7）召唤兽系统
（8）组队系统
（9）NPC系统。包括店铺，交易，给予，启动战斗，发布任务，发放物品，更改人物及召唤兽属性。
（10）帮派（未完成）
（11）网络通讯不稳定的问题解决，服务器性能提高。
存在问题：
（1）服务器性能仍然不高。
（2）游戏逻辑编码有错误，导致服务器频繁宕机。

2.3.3 Alpha阶段
开发时间：2009年8月上旬——2009年9月底
实现功能：
（1）生产生活
（2）工厂
（3）帮派
（4）聊天
（5）GM工具
（6）好友
（7）系统设定
（8）小区家园（未完成）
（9）组队系统客户端开发者更换，组队客户端模块大幅修改，组队基本完成。
（10）游戏功能测试及各功能模块bug修正。
（11）服务器性能优化。
存在问题：
（1）组队系统仍然存在一些bug。
（2）服务器性能仍有待提高。

2.1.4 Beta阶段
开发时间：2009年10月——2010年2月14日。
实现功能：
（1）游戏功能测试及各功能模块bug修正。
（2）游戏压力测试。
（3）服务器架构调整。
（4）服务器性能优化，单个游戏逻辑服务器承载人数达到2000以上。
（5）代码整理及修改。
（6）新增PK系统。

存在问题：
（1） 游戏逻辑的实现仍然存在bug。
（2）服务器架构仍需完善，Gate Server数量需要增加。单区承载人物仍需进一步提高。

2.1.5 Close Beta阶段（尚未进行）
开发时间：2010年2月14日——2010年3月中旬。
目标：
（1）修正全部发现的游戏逻辑bug。
（2）新增防沉迷系统。
（3）游戏服务器客户端基本稳定。
（4）服务器性能进一步提高，单区承载人数突破10000。

         

                                                                    第三章   我对游戏开发的理解
3.1   游戏项目开发的生命周期
游戏也是一款软件，如同软件开发项目生命一样，如下图所示。
      
                                                                           


3.1.1 商业环境参数
      包括可投入的资金，产品市场定位，产品的风格及特色，产品的赢利点，竞争对手的调查等等。
      可公司前期应该没有做过认真的商业环境参数分析，如同众多的小游戏公司一样，看到《梦幻西游》赚的钵满盆盈，于是乎热血沸腾，一哄而上，没想好游戏的思路，马上项目开始动工，马上我要见到Demo。反正就照着《梦幻西游》做呗，他徐波一个脑袋俩肩膀，咱也是一个脑袋俩肩膀吗。
      至少公司没有把产品的定位想清楚就开始开发了。《梦幻西游》已经是4、5年前的游戏了，还跟在它腚后学走路，怎么也不可能超越它。

3.1.2  游戏创意
3.1.2.1 教训
      在没有理清全盘的游戏设计思路的时候，就开始编写程序代码了。程序怎么可能不返工？！
      从软件工程的角度讲，需求分析阶段的任何更改，对项目的影响是最大的。也许是项目主管忽略了这个问题，也许是在老板迫切的心情和强大的进度压力面前，不得已而为之。但项目主管应该清楚，躲得过初一，躲不过十五。用脑白金的话说，“出来混，是要还的”。
策划的失败之处总结：
（1）游戏核心可玩性
      恐怕现在公司也没人知道。
（2） 游戏支撑系统
      经济系统几乎等于没有。连这个都没想好，万一上线了靠什么来赚钱呢？
（3）游戏各功能见缺少联系
      任务，帮派，物品，装备，家园，工厂间的游戏逻辑联系不够紧密，各个模块相对较独立。
（4） 游戏逻辑设计前后矛盾，漏洞百出
      我在做战斗模块的时候深有体会，常常程序写不下去了，因为不知道游戏该怎么玩了。去问策划的时候，他也不知道！然后登陆《梦幻西游》，进入战斗，告诉我，“哦，，，就这么玩，，，”。
      过几天做召唤兽模块的时候，程序又写不下去了，因为不知道召唤兽进入战斗该怎么打架了。去问策划的时候，他也不知道，然后再登陆《梦幻西游》，进入战斗，告诉我，“嗯，，，这么玩，，，，哎不对，，，有冲突，，，哦，该那么玩，，，，”      
      我内牛满面。
       (后来开发进度延时的时候，被领导K的当然是我)  
（4）部分游戏逻辑简单
      比如任务较单调，没有副本等等。
      公司需要一名有创意的剧情策划。
（5）数值失衡
（6）艺术创意失败
      由于缺少有实力的主美术，游戏界面各个元素颇为粗糙。
      公司欲开发游戏，主美必现行。有了主美，才好找到合格的美工。

3.1.2.2 理想的游戏逻辑设计规范
（1）游戏逻辑框架定义
      初步确定游戏逻辑框架，形成草案。
（2）核心可玩性
      确定游戏的核心玩法。
（3）游戏机制
      即游戏有哪些功能（即玩法），各个功能的详细流程，需要编写策划文档。
（4）游戏界面风格
      a.主界面
      b.场景
      c.人物、怪物、宠物、NPC
      d.菜单
      e.子窗口
      f.按钮
      g.图标
      h.光标
      i.动作
      j.特效
      k.音乐（个人喜欢中国古典音乐，看见玩劲舞团的非主流，就想踢他的屁股，然后把他的空格键扣了）
（5）玩家间交互机制
（6）剧情
      a.剧情
      b.游戏场景的背景故事
      c.人物背景
      d.任务

3.1.3 架构设计
我理解的一种常用的服务器架构如下图所示：

3.1.4 游戏技术设计及实现
3.1.4.1 软件开发过程
      采用统一软件开发过程。核心工作流程：需求，分析，设计，测试。
      各个工作流程采用迭代方式。
      一个好的软件开发过程强调在项目开始的时候全面思考整套游戏逻辑，而一个糟糕的软件开发过程在项目开发后期才发现了需求、分析或设计阶段出现偏差。
      在实际的开发中，开发进度永远赶不上开发计划，所以在实施开发的早期，程序部为了一味地追求进度以换取不懂程序的领导的暂时的满意，从需求阶段就犯下了许多致命的错误。
      这就发生了在接近Beta版测试时（即游戏行业所谓的“内测”），才发现游戏根本不好玩，游戏的经济系统有缺陷等等诸多问题。
      开发中，尤其注重早期的游戏设计与技术设计的衔接，技术设计与编码的衔接，编码与测试的衔接。
3.1.4.2 程序设计文档
      明确了软件开发过程后，便对程序部每位程序员明确程序设计文档的重要性。
      在程序各个模块的开发前、开发中及开发后，开发者要及时编写、修正程序设计文档。
      程序设计文档采用UML进行设计。
3.1.4.3 代码review
      定期组织程序部的程序员进行代码的review。
3.1.4.4 测试
      由于游戏软件公司的开发周期通常较短，经费普遍不足，因此在游戏项目中展开UT通常是不实际的。但功能测试一定必不可少，而且要加强。
3.1.4.5 部署
1、程序何时可以更新由程序部决定。运营只需要给出里程碑日期，何时提交程序由程序部按当时的开发程度决定，仓促上交的版本必然有各种bug。
2、开发的游戏最新版本在公司内网经测试无误后，方可以发布到外网服务器上部署。
3、部署到外网后公司内部员工登陆外网游戏经测试无误后，方可以对普通玩家开放。