各位看官老爺們，這裡是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的使用經驗和線上交流和團隊管理經驗，希望這些內容能夠對已經閱讀到這裡的你有所幫助，特別是關於團隊管理方面的心得。
感謝您閱讀到這裡！那麼今天的分享就是這些，歡迎訪問：
整個專案原型github地址：
www.gitHub.com/yunshiyue/elementgame
最後，這裡是RuaiRuai工作室，一個做單機遊戲的興趣作坊，希望你對我們的專案能提出各種意見和想法，也歡迎各種合作！
下期再見！
