遊戲物語 - 開發流程及工具

來自專欄遊戲與後端技術4 人贊了文章

開發流程

開發流程可不是指你自己搭建開發環境、寫代碼、提交代碼這個過程，而是指整個團隊如何從0開始開發一款遊戲的全部需要經歷哪些階段。嚴格講這其實是軟體工程方法學的範疇。我們不可能把各種方法學鋪開來一一介紹，那樣恐怕開個專欄都不夠。這裡只聚焦在適合遊戲開發的軟體工程過程。

這裡只推薦一種我認為非常適合中大型遊戲開發的方法：裁剪過的Scrum（對Scrum還不了解的讀者可以閱讀官方文檔）。為什麼是裁剪過的？因為遊戲這種產品對變更和故障的響應速度要求很高，很多時候需要跳過各種繁文瑣節，快速處理問題。儘管Scrum本身就是敏捷開發方法，有時候依然不夠快，需要裁剪。

我們先從宏觀上了解一下一個遊戲從無到有的產生過程。

通常，製作人會給出一個願景，定義需要做一個什麼類型遊戲，大概的設計思路是什麼。這就好比電影導演說想拍一個電影，它的主要的故事梗概是什麼，風格是什麼。接著策劃團隊領會了領導精神，開始細化遊戲的需求，並文檔化。技術團隊只需要知道遊戲類型，就可以進行技術棧的準備。比如需要做SLG類型的遊戲，那就需要前後端有長連接的通訊方式，並以此來選擇和搭建開發框架，前端選擇2d還是3d的引擎。美術團隊也可以準備原畫了，定義整體UI風格、角色等等，3D建模工作也可以開始。

準備工作搞定後，進入具體開發階段。程序員、美術根據需求文檔的要求進行開發、聯調、整合等。同時測試團隊也可以介入，編寫測試用例，demo開發出來後進行測試。測試通過後進行打包和部署並發布新版本。運營團隊收集BI數據進行決策分析，上線運營活動、道具、功能等等。

注意，除立項和前期的準備工作外，整個開發周期都是一個迭代過程，每次階段性發布都有這樣的迭代。

接下來我們了解一下，Scrum是如何運行的，以及如何針對遊戲項目進行裁剪。

在Scrum方法中，會把所有的需求細化成一個個的backlog，形成一個總的產品backlog，其實就是任務列表。然後根據需求的優先順序，在Planing（就是安排當前階段做什麼事的會議）中把這些任務劃分到各個Sprint（Sprint就是具體的開發迭代周期，時間根據情況長短不一，一般是1-2個月）。接著開發團隊就可以根據sprint backlog領取任務進行開發工作。通常每天都有一個daily meeting，每個人講述自己昨天幹了什麼今天要幹什麼，遇到了什麼問題，需要什麼資源等等。一個Sprint結束時會有一次review，同時還會有一個Retrospective（說白了就是批評與自我批評，表揚與自我表揚，BB這個開發周期那些地方做的好，哪些做的不好）。最後增量的發布這一迭代周期的產品，進入下一個迭代周期。

根據團隊、項目大小的不同，甚至是人員特性的不同，每個公司都有自己特有的開發流程，完全教條的遵從某種方法學是不可取的，通常都要根據自身情況進行裁剪。遊戲這種需要快速響應變化的2C產品，儘可能的壓縮事務性工作和流程性工作，專註在產品開發本身才是最重要的。

首先，遊戲團隊不需要遵從Scrum的團隊角色構成。遊戲開發人員的職能分工相當明確，PO、Master這樣的角色沒有太大必要。策劃專註在需求的細化和準確度上，及時和開發團隊溝通即可。其次，減少事務性的工作。task的建立、分配等工作可以交由項目經理並由Lead協助完成；daily meeting可以降低頻度，但一周必須至少有一次。程序員不需要編寫詳細設計文檔，描述清楚思路，確定設計方案，定義清楚介面就可以。Review是很有必要的一個環節，整個團隊坐在一起檢驗完成情況，需求實現是否偏差、是否有明顯bug等等。而Retro環節可以只involve 各team的lead參加，匯總問題即可。

另一個需要注意的是，遊戲產品每次迭代更新都需要看到較明顯的變化，這就意味著sprint不能設置的過短。否則一是產品變化不明顯發布的意義不大且增加風險，二是事務性工作的周期縮短佔用了更多時間。通常建議一個迭代周期以6-8周比較合適。

這部分推薦的開發流程並不是唯一標準，只是筆者多年的積累和實踐後認為比較科學、操作性強、行之有效且能很好的把控進度和質量的一種方法。上面已經解釋過，方法千變萬化，只有適合自己團隊的才是最合理的選擇。感興趣的讀者可以去下載一份Valve公司（沒錯，就是那個大名鼎鼎的開發半條命的公司，也是Steam平台所屬的公司）的新員工手冊，了解一下Valve的開發流程，相信一定會給你耳目一新的感覺。

工具

適當的使用工具可以幫助你高效的完成工作，這裡推薦幾個匹配上面介紹的開發流程的工具、以及輔助開發和部署的工具。

JIRA & WIKI

JIRA現在幾乎成了敏捷開發的標配工具，你的公司不使用JIRA去進行項目管理你都不好意思和人打招呼。無論是任務分配、項目追蹤還是Bug彙報，都和Scrum結合的天衣無縫。加上Confluence做wiki，基本上軟體開發周期需要文檔化的東西都齊活了。

Git/SVN

代碼管理工具，現在是個碼農就沒有不會用的。Git基本上已經一統天下了，列出SVN的原因是遊戲項目中的美術資源，甚至是一些大項目的前端代碼，因為佔用空間太大的原因並不適合用Git去管理，反倒是SVN更加適合。

另外推薦一款Git的可視化工具Sourcetree，用它做命令行的輔助，很多使用場景下有奇效。

Jenkins

Jenkins也已經成DevOps的標準了，CI/CD的重要集成工具。使用它可以讓伺服器端的代碼一鍵部署。

Sonar

sonar是一個代碼質量管理工具，能幫助你消除代碼中的缺陷和壞味道，保證代碼質量並建立良好的編碼習慣。

Gmail & Gtalk & Google Doc

Google的這三個套件並不是必須的，你也可以找到對應的替代品。但當你基於它們進行團隊的溝通和信息交流時，你會發現十分的好用，特別是對遊戲開發團隊。無論的郵件，內部的IM，文檔的共享，一個鏈接就能搞定一切。牆裂推薦這套工具作為公司的信息交互平台，當然前提是需要科學上網。