git push -f origin

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、部署到外网后公司内部员工登陆外网游戏经测试无误后，方可以对普通玩家开放。