《五行》從0到1設計遊戲——專案管理經驗總結

這次是關於《五行》開發覆盤系列文章的最後一篇了，前面講完了策劃向和美術向的內容，這次是專案管理的內容惹~這次的經驗主要來自於之前實習偷偷觀察俺們專案組PM（偷吃果凍的站神木子）的工作內容，照葫蘆畫瓢+偷師學藝來的一點點知識，然後就試著看看能不能用到這次比賽中，感覺自己用的很湊合，俺也不是專業的，有專業的讀者姥爺看到了可以多多評論指出問題~~

依然是展示下我們整體的時間進度表。在前期頭腦風暴的時候基本上是比較放鬆的階段，所以我也沒有特別要求我們團隊裡的同學需要完成什麼任務，大家基本靠自主意願做一些關於這次比賽的嘗試。


到了7月底的時候，莉莉絲公佈了本次筆試的遊戲主題，於是我開始對我們的開發進行了時間規劃和專案管理。

一、排期&確定時間節點

這次用的排期工具是trello~強烈安利給小團隊的朋友們，這個真的是一個特別方便的專案管理工具，是一個免費的線上網站，你可以在裡面建立自己的team，然後把小組成員的郵箱輸入進去就可以成功新增你的組員了，大家都可以對自己的任務單進行建立，看到每個人的工作程式，輕便好用~https://trello.com/

okok，話說回來，我們的時間還是比較短的，從7.24莉莉絲公佈主題到最後的提交時間8.21，這中間加起來就1個月不到的時間，但是我學著之前實習專案組做周版本的方法，將時間按周進行劃分，每週都設定一個版本日，在這天我們需要測試自己的遊戲，來檢查目前遊戲的不足之處，基此我們對每個人釋出下一週的具體工作任務。


接著在大的看板裡，我分了幾個模組，分別是大家持續思考的、本週在做的、已完成的、下週要做的和待排期的。像比如遊戲名字命名這種，我們在開始的很長時間裡都沒有決定要叫什麼，這種集體任務，我就會把它放到“大家持續思考”裡，提醒大夥要思考，但是暫時不用限定具體的時間截點。



二、資源管理&開發工程檔案版本管理

我們的團隊結構很簡單，一個程式、一個策劃、兩個美術。只有一個程式的話，程式碼方面就不需要做共享式的管理了，這一步就省去了。對於我們專案中比較重要的是美術和開發檔案的銜接。

首先就是我負責的UI美術資源的共享了，考慮到我們是mini game型別的專案，所以最關鍵的就輕便快捷易上手，我們在QQ上組建的團隊群，QQ給了群檔案很大的記憶體空間（至少對於我們來說是綽綽有餘的），所以我就在群檔案了建了一個專門的UI資料夾，切圖命名按程式的要求（第一個單詞首字母小寫後面單詞的首字母大寫）


如果需要有迭代替換的美術資源，需要直接在群檔案裡上傳相同名字的圖片，群檔案是允許存在相同名字的檔案，這時候需要把之前上傳的舊的圖片刪除掉。如果重新上傳的圖片，在群聊天裡也會展示出來，所以我們的程式也會發現有迭代圖片需要更換，方便協同工作。

第二個就是3D模型的美術也是需要協同工作的，美術佈局和程式功能開發在這一塊是有衝突部分的。這時候是美術同學用建模軟體把場景搭出來，再逐個匯入引擎來調整比例和大小，來保證人物移動距離和場景模型尺寸相適應。程式先會把具備功能的引擎工程檔案發到QQ群檔案裡，這時候下載這個版本的檔案，將美術資源匯入，再之後程式要修改bug或者增加功能時，也是接著美術匯入好的工程檔案進行加工，每個分支版本都會上傳到QQ群檔案。如下圖，我們用命名的方式來備註每個分支工程檔案的內容。


其實一開始我想說我們可以用SVN，但是後來考慮到我的的開發週期短，軟體還需要大家適應學習，會耗費掉一部分的時間精力。再者，莉莉絲的引擎提供了資源雲存的功能，也就是我們上傳了工程檔案後，我們的工程檔案內自動生成的資原始檔夾會上傳雲端，這樣引擎檔案大小其實就不大，方便了我們互相下載上傳檔案。

三、BUG測試

BUG測試也是開發中很重要的一環，其實我們在這次比賽中的這個部分做的不是很好，畢竟大夥都是第一次參加比賽，經驗不足，有時候計劃趕不上變化。

本來我們打算每週都測一次遊戲的，來保證最後成品裡不會有太多bug，完成度會比較高，但是隨著後面遊戲玩法的豐富，很多時候根本來不及修，這次其實在遊戲測試上，我們做的不是很好，所以在我做我畢業設計的時候，我和程式有了經驗，這裡穿插介紹下。

因為我做畢設時，遊戲開發的時間也很少，在我產出策劃案到最終畢業設計展覽大約一個月的時間，其中2/3的時間在完成基本功能，剩下10天就是測bug和改bug，為了高效的記錄我們遊戲的每個bug，並且確認修復情況，我和千千用了騰訊線上文件。線上文件能夠讓我們協同工作，共同編輯，來檢查bug的修理情況。

如下圖，我用的是線上excel表格：


幾個主要的使用方法：①當我們登記新一天的bug的時候需要新建表單；②文字填表包括的專案有：序號、負責人、優先順序、修理情況、修改說明；③修改情況需要分別用紅、黃、綠的顏色標出，這樣查詢檢查更方便一點；


四、風險處理

風險處理其實就是處理任務延期的問題啦。因為事情沒法完成很容易影響到後面的進度。

我們有的時候也會出現來不及完成任務的情況，比如我的介面美術設計包括了很多子專案，這時候會把子專案進行拆分，把大專案分解成具體的小專案，再對小專案設定各自的時間節點，優先順序高的放前面，優先順序不高的排在下一週或者本週末尾。

為保證最後遊戲能順利執行，最基本的功能要保證實現是最重要的，因此設好任務和bug的優先順序是至關重要的。

五、總結

總體來說，我本次的專案經驗應該更適用於短期的遊戲專案，mini game或者gamejam。真的不太適合大型的商業專案，因為那種應該工作量什麼的各種體量都會比較大，需要做更加詳細的分類。

我自己的感受這次專案管理很大程度上是基於自己之前商業遊戲的實習經驗，把商業遊戲的製作週期和資源使用的這些方法和流程都簡化，其實同樣也會很適用於小團隊的管理~

到目前為止，關於《五行》的三篇文章我都分享完啦~感謝各位讀者姥爺的閱讀~這是我第一次參與這種mini game型別的活動，還有很多不成熟的地方，自己在這次遊戲比賽的活動裡收穫了經驗，當然最重要的是我的小夥伴，都是俊男美女，說話又好聽，個個都是人才，俺們在這次比賽結束後還經常在群裡聊一些有的沒的哈哈哈~~老開心老有趣了~~

相關閱讀：

《五行》從0到1設計遊戲——策劃向開發記錄
《五行》從0到1設計遊戲——美術向覆盤


來源：GameTube
原文：https://mp.weixin.qq.com/s/H_r7Ed9m9pd0iLNdkmPjIw