各位看官老爺們，這里是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工作室，一個做單機游戲的興趣作坊，希望你對我們的項目能提出各種意見和想法，也歡迎各種合作！
下期再見！
