第一章   杯具，又見杯具
      公司最終還是散伙拉倒了。一起戰斗的兄弟們也四分五裂，各保其主了。
      雖然公司不是我開的，我不虧一分錢，可是還是有一絲的難過。在我的極力搶救下，程序總算是基本穩定了，可是還是回天無力，沒能挽回散伙的厄運。
      我只想對老板說：灑家已經盡力了。
      倒閉的原因種種，有公司高層的原因，也有項目質量和進度的原因。
      首先，游戲策劃方案失敗。游戲邏輯漏洞百出，比如到了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、部署到外網后公司內部員工登陸外網游戲經測試無誤后，方可以對普通玩家開放。