新手必讀:常規遊戲項目開發流程

VR-monument-Valley-01500.jpg

文/GAD

概述

常規遊戲指一般的具備網絡服務器端的客戶端遊戲、頁遊、手遊。開發這類遊戲,一般會分以下四個階段:

1.籌備階段:籌建團隊,確定項目的基本方向。

2.原型階段:實現一個遊戲原型,發佈Alpha測試版,以驗證和調整預定的方向。

3.發佈階段:發佈遊戲的Beta測試版本,供內部封閉測試,做上線前最後的準備。

4.迭代階段:完成對Beta測試版的修改,上線後按迭代周期,持續開發和調優產品。

在這些階段中,我們都必須註意開發流程中的一些重要因數:

  • 角色:定義一些角色,規定其工作權力和責任,避免過度討論或盲進
  • 交付物件標準:每個角色都必須按照一定標準來交付工作成果,避免在長長的工作鏈條中出現很多誤差。
  • 工作方法細節:由於遊戲開發是一個涉及多個專業的復雜過程,所以這個過程中有一些工作方法,是必須要遵守的,否則將會嚴重降低開發效率。

作為一個完整的遊戲開發團隊(不包含運營團隊),整體的結構應該大致如下:

phpqaCLX0.png

籌備階段

角色定義

  • 投資人:根據市場狀況和投資預期,提出商業目標和項目邀約,和制作人討論並審核確定《產品方向》,制作《投資計劃》,按計劃安排資金投放,並承擔投資後果。
  • 制作人:根據投資人的商業目標,整理和組織市場調查數據和《競品資料》,制訂《產品方向》。根據《投資計劃》組建核心團隊。在某些項目裡,投資人和制作人是同一個人。
  • 核心團隊:一般由制作人和主程,主策,主美組成,有些時候還包括項目經理。在某項項目裡,制作人可能由核心團隊裡的任何一個人兼任。
  • 項目經理:負責制訂工作計劃,監督進度,安排各種資源。初期可能會有很多秘書工作需要擔任。在某些項目裡,項目經理可能由核心團隊中任何一個人兼任。

交付物件

  • 《投資計劃》:由時間、金額、項目進度檢查標準,這三列組成的一個表格。需要附帶上修改日志和完成記錄。
  • 《產品方向》:一個具體的文檔,記錄瞭產品概念所依據的市場狀況(數據)、競品的情況(數據);也記錄瞭項目產品的基本情況:遊戲的題材、遊戲的玩法、遊戲收費方法的基本概念,以及市場推廣、運營的基本思路。
  • 《競品資料》:羅列所有主要的競爭對手產品的情況,包括產品市場數據,開發方案(如能搜集到),評測資料,用戶反饋等。需要由制作人持續更新關註,隨時整理添加。

重點註意

產品概念討論方法

  • 針對用戶特性:遊戲產品形態非常豐富,細節也很多,所以在討論任何設計的時候,都必須按照既定的用戶畫像來做標準判斷,避免大而全或者鉆牛角尖。在各種“調查報告”無效的情況下,邀請幾個目標用戶作直接溝通,往往能獲得最真實、最有效的情報,不用過於擔心“代表性”不夠,因為共性往往是比較明確的部分。
  • 針對競品:在用戶、市場情報不夠充分的時候,競爭對手能提供最直接的產品信息。通過分析競爭對手的產品,特別是跟蹤競爭產品的變化,就能猜出用戶和市場的反饋。就算本產品的競爭對手不多,方向相似度不高,隻要是目標用戶群體接近,也可以通過競爭產品的用戶感受來瞭解用戶心理。切記閉門造車,不接觸市場風潮。
  • 不應該深入的部分:在籌備階段,容易陷入頭腦風暴,所以我們不應該深入討論產品的開發過程、開發工具、開發人員。對於產品的細節,也不宜過細,但應該找出一些簡單明確的概念來代替,如“經過XX修改的競品A”這樣就很好。

團隊缺人對策

  • 招聘渠道:首選熟人朋友圈,其次畢業生和培訓機構,最後是網上投遞簡歷。由於現在的培訓機構一般都需要簽就業協議,所以對於創業團隊,小型公司來說可以作為一個比較穩定的人員來源。大型公司最好就是各種高校的招聘會瞭。獵頭也可以考慮,但是對候選人需要仔細甄別。
  • 選擇簡單的工作方法:缺人的情況下,往往是缺牛人。所以一定要選擇簡單的工作方法,各種高大上的流程,一定要在有IT技術保障下實施,不要直接推行而不顧實際情況,這些可能有問題的方法包括:定期匯報制度、全自動化項目管理、沒有足夠儲備的技術開發方案等等。
  • 培訓準備:根據初期可能到職的人員,進行基礎能力的培訓,比如SVN的使用,BUG跟蹤系統的使用,基礎的開發技術、美術、策劃文檔標準。這些培訓都是需要多次進行,所以應該先準備好培訓資料,避免新成員入職措手不及。時間控制
  • 會議:籌備階段大概有一半的時間是在做溝通,因此會議時間需要特別控制。要嚴格遵守議題議程。如果有遺留問題,應該有專人搜集整理並且跟進,而不是在會上去解決。因為會上提的方案,往往沒有自己在認真思考的環境更完善。另外就是避免“挨個報告”那種沒有明確議題的會議。這種溝通瞭解放到其他時間,少部分人溝通會更清楚。
  • 招聘期限:根據經驗,核心團隊具備的情況下,要組建到項目正式啟動的團隊,基本需要3個月左右。假如接近3個月都沒有什麼進展,應該和投資人反映,並研究解決方法。一般最簡單的就是提高工資和雇傭獵頭。

原型(Alpha)階段

角色定義

  • 主策:提出產品原型的概念,交付《項目總體設計》,並協助原型開發,突出產品特點。
  • 主程:選擇技術方案,定義美術、策劃資源的技術標準。搭建開發環境,編寫產品原型。在客戶端開發方面,和美術同事合作,調整原型效果以達到測試的目的。
  • 主美:選擇美術風格,在策劃和技術的共同討論下,確定各美術組件的基本技術標準,如大小、尺寸、容量。並且確定美術資源的格式。
  • 項目經理:有些團隊由制作人、或者主策兼任。此階段在明確遊戲原型後,產品、技術、美術人員都會需要各自開發一些內容,然後再整合到一起。因此項目經理應該負責組織大傢共享這些信息,一起討論和評審各階段產品,確保各環節不脫節。

交付物件

  • 《項目總體設計》:規定瞭遊戲的題材、玩法、收費模式。確定遊戲的重點樂趣和表現特點。列出遊戲的長期開發計劃所需要的系統、關卡、內容綱要。作為後續策劃工作的總需求列表。
  • 《美術風格指導》:以實例原畫圖來規定整體美術風格。
  • 《美術資源格式標準》:對遊戲原型的美術資源格式,做出標準規定,包括美術文件的格式、尺寸、精度標準、命名、SVN路徑規則等。
  • 開發環境:SVN服務器地址、BUG跟蹤系統地址、IDE選擇產品和版本、開發和測試的內網服務器、演示用外網服務器。
  • 《技術方案選型方案》:開發遊戲所用的客戶端和服務器端引擎、框架版本;程序的基本模塊代碼結構;項目文件目錄規范;測試和CI方案;技術難點的預設解決方案。
  • 可運行的原型產品(DEMO):突出表現遊戲核心玩法和美術風格的一個程序,可以是一個單獨的遊戲關卡。

重點註意

原型開發階段,主要目的是驗證產品的基本面問題:題材和玩法的融合是否合適,美術風格和技術實現是否能達到策劃的初始目標,有沒有一些難以解決的基本障礙。需要特別註意的,開發原型所需要耗費的資源制作和邏輯編寫時間,因為這反應瞭後期遊戲持續更新所需要消耗的成本。

另外,由於遊戲原型的制作,也帶出瞭個制作環節的溝通問題,所以必須註意從一開始就積累和訂立各工序的交付標準,如策劃案應該包含圖量表、測試方案;需要預先溝通美術草圖並簽名;美術資源格式需要確定;遊戲原型的測試環境設置。——這些標準和接口往往會變動,但是需要預先明確這些接口流程。

發佈(Beta)階段

角色定義

技術開發團隊:

  • 客戶端開發:開發和優化客戶端代碼和單元測試用例、文檔,完善客戶端程序打包、發佈的CI流程
  • 服務器端開發:開發服務器端代碼和單元測試用例、文檔,維護項目數據庫,安裝部署測試環境
  • 測試開發:維護和管理CI系統,監督運行單元測試用例,開發專項測試如性能測試、自動化冒煙測試。

交付物件

phpJIUh4w.gif

  • 《策劃需求文檔》:重點說明要達到的產品目標,使用的主要設計手段
  • 《策劃案》:產品使用流程圖,GUI草圖,須配置的遊戲數據項目,美術圖量表以及風格參考
  • 《草圖》:美術風格參考,UI構圖
  • 《技術設計方案》:代碼模塊命名以及職責,代碼結構模式及關系,重點技術問題解決方法
  • 《美術資源格式》:文件名和路徑規則、文件格式、精度、尺寸或其他更細節內容
  • 《遊戲數據格式》:庫名、表名、字段解析、字段內容結構
  • 《Bug報告單》:策劃案ID、重現步驟、現象

重點註意

此階段是建立穩定完整的版本開發流程最重要的階段。關鍵點是各交付件標準的嚴格遵守和流程監控。項目經理須組織對於流程、標準的討論和確定,並且監督這些規定的執行。由於每個遊戲都不一樣,所以這些流程和標準都會有所差異,項目經理要隨時應對不同的策劃案,即時組織大傢建立流程標準。另外需要準備發佈的工作,包括宣傳資料,測試環境,運維工具等工作,也需要花時間準備。——在發佈前至少安排一周時間來做發佈前的準備,和運營、運維、客服人員做好溝通和交接準備。

迭代階段

角色定義

1)開發團隊:依照迭代標準開發迭代所需內容。

2)運維團隊:

  • 運營人員:負責推廣、發行工作,提供技術資料給運維人員做產品部署,關註產品數據和運營情況。反饋意見給開發團隊。
  • 客服人員:輔助遊戲推廣,提供玩傢咨詢、故障報告、投訴處理、事故安撫等工作,需要運營人員和開發團隊進行持續的信息共享。
  • 運維人員:提供遊戲的部署和監控工作,開發管理運維部署工具。準備硬件資源和運行環境。有些運維工作由開發團隊中的服務器端程序員一起分擔。
  • 運營開發人員:開發“GM系統”給客服人員使用;開發“數據統計報表”和“活動系統”、“官網”等系統給運營人員使用;某些遊戲團隊由服務器端程序員兼任。

交付物件

  • 《版本發佈計劃》:每個版本開始開發前,都需要編寫此計劃,列明本版本內需要開發的內容,預計時間,以及開發設計人員名單。此計劃需要提交給運營人員,提早準備《運營計劃》中的推廣活動和安排推廣資源。
  • 《版本發佈說明》:每個版本進入內測後,由開發團隊編寫後,提供給運營人員,包含本版本的所有在產品上的變更細節。以及這些版本內容的開發成員。供運營人員培訓客服掌握,以及運營人員自己做測試,用以作為《運營計劃》的材料。
  • 《運營計劃》:根據每個版本,運營人員提交此文檔,包括運營活動內容和所需的推廣資源和資金支持。以及需要包括此次運營預計要達到的商業效果和衡量手段。
  • 《產品部署、升級方案》:由開發人員提供給運維人員的技術部署方案。包括如何部署安裝進程,設置CDN或DNS,運行SQL或者修改配置文件。某些團隊會開發自己的產品部署工具,如Chef這類軟件,用以自動化處理運維工作。
  • 《產品統計需求》:由運營人員提交給運營開發人員,定義統計報表的格式和統計周期,描述每個表頭的含義。運營開發人員根據此需求文檔,開發統計程序,自動定期反饋數據報表給運營人員。

重點註意

一般遊戲的持續更新,需要遵循一個版本列車的設定:

phpwLfX1y.gif

由於開發的內容有長有短,所以開發過程中的代碼必定要維護多套版本分支,這需要在SVN上做嚴格的定義:

php5mpjqn.gif

Comments are closed.