程式設計文檔,遊戲設計文檔

 各位看官老爺們，這裡是RuaiRuai工作室，一個做單機遊戲的興趣作坊。

本文跟大家聊一下筆者團隊中所使用的線上協作的諸多工具，以及使用這些工具的目的和所記錄的内容，希望這些内容在大家團隊工作中有所幫助。

文檔管理

筆者團隊中主要記錄了以下文檔：

遊戲設計文檔

　　玩法及機制文檔

　　劇情文檔

　　關卡設計文檔

　　創意點文檔

程式設計文檔

　　版本說明文檔

　　子產品設計文檔

　　類說明文檔

　　檔案頭注釋及内部注釋

項目管理文檔

　　長期進度規劃

　　短期任務規劃及任務分解

　　bug清單

　　會議記錄文檔

這些文檔中，有些文檔是需要随着進度的定期更新的，如關卡設計文檔、版本說明文檔等，這些文檔一般有專人負責維護，在筆者的小團隊中，一般是誰負責這個子產品誰負責寫該子產品的文檔；有些文檔是實時更新的，比如bug清單、短期任務規劃，一般來說這些文檔是随着工作的推進随時可能更新的，而且任何團隊成員都有可能對這些文檔進行随時修改；還有些文檔是一經編寫、核驗便在整個項目中不會變動或極少變動的，比如長期進度規劃文檔、軟體需求規格說明書(遊戲項目中比較少見)等，這些文檔在整個項目中起到參照、引導方向的作用，故需要謹慎編寫、反複核查。

根據這個分類，筆者團隊中采用不同的方法管理這些文檔：

對于需要定期更新的，文檔名以及文檔頭會根據目前項目的版本号自行擴充文檔版本号，采用版本疊代的方式進行管理，比如

目前項目的版本為0.1.2，那麼相關玩法設計的文檔可能為0.1.2.1\0.1.2.2等。主策劃負責維護這個文檔版本系列，并将以往的所有文檔儲存在文檔管理工具中。

對于實時更新，任何人都可能編寫的，我們采用線上文檔的方式進行管理，一般這樣的文檔隻需要一個檔案即可。文檔内容實時保持目前工作進度的最新進展，已經完成的任務項或是已經失去時效性的資訊便會放在文檔末尾的曆史記錄中留存。

對于一經編寫，極少變動或者不會變動的文檔，在團隊公開文檔中隻需要留存一份隻讀檔案即可，改寫權在項目組的項目經理或組長手中。

在文檔方面，不管使用使用何種管理工具，我們隻要找到一種合理的方案就可以，筆者團隊中使用群檔案管理變動較少的文檔，使用git版本控制管理與版本有關的文檔，使用群線上文檔管理實時更新檔案。　

設計圖管理

 在團隊搭建伊始，大家都沒有協作經驗，隻是簡單地搜集了一下資訊就決定使用ProcessOn來管理和協作各種設計圖。在大佬的指導下，我們了解到了draw.io開源工具，我們才将所有的設計圖搬運到了draw.io下面。

(英文不好的小夥伴記得切換中文界面噢，吹爆draw.io

版本控制

當然首推git，但是在使用git進行版本控制中我們也遇到了相當多的問題，比如.gitignore配置不正确導緻的vs項目同步失敗問題，美術資源導緻的帶寬過小問題，場景資料和prefab資料的merge問題。在此我們隻是對每個遇到的問題做一個解決思路上的概括，不做過多的細節描述，對于上述問題的細節解決方案已經存在很多部落格可以參考。

.gitignore配置不正确導緻的vs項目同步失敗問題

首先，.gitignore檔案中記錄了git在本地倉庫檔案夾中中不予追蹤和同步的子檔案夾、檔案格式等一系列檔案。而在unity中(預設使用vs進行C#開發)，我們隻需要對項目結構中的部分檔案進行同步和版本控制，比如Assets檔案夾下的資源檔案和腳本檔案、package檔案夾下的資源包插件包等。其他的諸如vs本地化配置檔案\檔案夾等則不需要進行同步，這部分檔案我們需要在.gitignore檔案夾中指名，否則如果這些檔案通過遠端倉庫進入了其他機器，會造成路徑丢失、配置沖突等本地化問題。

在這裡建議在github中搜尋.gitignore，在官方給出的unity.gitignore中做一些針對自己項目的改動(如果不确定你在做什麼，直接使用官方的.gitignore就好！)

 美術資源過大導緻同步速度難以接受問題

用其他工具進行資源同步吧！我們沒有做過多思考和調查，簡單地使用一個群檔案+版本号進行控制，當然這種随意的控制方式可能會有潛在的風險，希望有相關經驗的朋友不吝賜教！

場景資料和prefab資料的merge問題

首先我們需要将unity的檔案儲存形式配置為可序列化而不是二進制檔案，這樣做就允許了git比對不同版本的場景\prefab資料檔案的差異，進而進行自動merge操作，當無法自動merge時，便在序列化的檔案中做出标記，訓示我們進行手動merge。我們順着這個思路，便可以将存在merge conflict的序列化檔案以文本格式打開，像手動合并代碼一樣merge這些檔案。

實時交流方案

我們是遊戲團隊是以當然開發了一套最先進的AR全息會議來實作實時交流啦

我在想批次.jpeg

 筆者團隊經曆了時長越2個月的線上協作，這段時間給筆者的最大感受就是：需要像問小朋友要作業一樣問你的組員要成果...

确實，線上協作的距離感無可避免地帶來了管理上的困難，這就需要項目負責人花很多心思在凝聚這個團隊上，在保證團員的緊迫感和摸魚帶來的心理壓力之間找到一個可以忍受的平衡(我是哲學家嗎2333)。當然，團隊管理并不是今天的主要話題，那麼回到主線，在這種情況下如何進行有效的線上實時交流呢？

筆者團隊采用的方案是不定期線上會議+每周工作彙報+1h内找必回制度，即

1. 根據工作進度和團隊成員的狀态不定期(約1~3天)開一次短會，主要是工作進度分享、工作任務分解、問題讨論、團隊氛圍建設(瞎b聊天)等内容。

2. 每周進行一次較為正式的定期會議，每個人口頭彙報工作内容、工作狀态、問題回報等内容，并每周安排一名組員進行激動人心的遊戲安利環節，同時安排另一名組員進行會議記錄。

3. 1h内找必回制度，即在工作群中，若有相關工作的問題交流，對應子產品的負責人必須在1h内予以接洽，否則進行懲罰(0.0我是被罰最多的)(是因為我負責子產品最多啦)a

在這套方案的使用過程中，筆者認為所謂張弛有度還是可以保證的，即讓隊員有一個較為輕松愉快的讨論氛圍，又不至于影響工作效率，或者說流于形式。當然，在具體實施管理交流方案中最重要的還是項目經理和項目成員的各方面能力和性格，所謂人定勝天。

小結

筆者本想通過本文介紹一些工具的使用方法和技術上的問題的闡述，沒想到說着說着有感而發，邏輯就順道了團隊管理的經驗上去，不過這也是我最想和大家分享得内容吧。本文我們介紹了筆者團隊所應用的文檔管理辦法、設計圖管理工具、git的使用經驗和線上交流和團隊管理經驗，希望這些内容能夠對已經閱讀到這裡的你有所幫助，特别是關于團隊管理方面的心得。