在遊戲的製作上，協同工作又更加的複雜，跨業背景的合作中，每個職責的產出物不盡相同。有趣的是，在控管上第一步碰到的問題不在於要如何去解決不同產出物的版本控管，而是在於版本控管的概念導入，讓每個團隊的成員先認同他們的產出物是需要被控管的。
遊戲製作的成員裡，可以粗分成企劃職責為主、美術職責為主和程式職責為主三類。當然在資源更多的環境下，測試職責為主和音樂音效職責為主的人員也會存在。對於不同職掌的人員來說，產出物是有所不同的。企劃在開發前期會產出設計文件，而在中、後期為進入關卡設計的部份 (有些遊戲可能並無所謂的關卡設計)。美術人員則是以圖檔或模型相關檔 (2D和3D不同) 為最主要的產出物。而程式人員則如前述是以程式碼的產出為主。至於音樂音效人員則顧名思義是產出音樂、音效。測試人員會以報表的產出物來反應遊戲現階段的製作品質。
因此，在建置版本控管的規劃上，亦相對的複雜。不但要考量到不同背景的人員對於版本控管的接受性，也要考量到不同產出物的控管上是否契合於所使用的工具，最重要的是，在資源的使用上能夠投入多少到版本控管上，這幾點是左右著遊戲開發團隊在選擇導入版本控管，所需考量的。
以下依據之前為了開發Unity遊戲而選擇版本控管工具想法，做一記錄。配合當時團隊人員背景、建置所需時間及可調度的資源，讓其他團隊參考：
在遊戲業界，尤其是知名的幾家以研發為主的公司待過，則不論是否為程式背景的人員，都會接觸到到 “版本控管” 這樣的工具。久而久之，自然對於版本控管工具的使用可以慢慢建立起使用的習慣，並在團隊的合作中，將之視為基礎。然而在新創的遊戲公司裡，並不是每一位成員都是來自以研發為主的遊戲公司，有些成員甚至是第一次接觸遊戲的開發。在這樣的團隊中，建立版本控管的流程和選用工具上，都會有不同的考量。再加上要配合遊戲引擎的特性，和資源使用上的限制，讓整個規劃上會有更不一樣的考量。
在開發iOS平台的遊戲時，勢必要導入版本控管的流程。而當時的成員中，佔著過半數的美術人員對於版本控管是沒有任何概念的。對於檔案的管理，習慣最好的是使用日期加上時間的方式，沒有聽過 CVS, SVN 更別說是 Mecurial 或是 Git 等這些年才較為流行的工具。而資源(特指資金)上的運用，公司方面當然是希望能夠以最少的形式投入。開發時所選的遊戲引擎為 Unity，然而在資源有限的情況下，沒有辦法達到有多個專業版可同時作業也沒有額外購買Unity Asset Server。
那時後，已使用Git 一段時間的我，對於用 Git 來做版本控管是有一定偏執的想法，就是想要導入Git 進入專案中，讓團隊的成員來使用。但這樣的想法在一、二次的會議的進行中討論後，就調整成要找其它的代替方案。對於從來沒有版本控管的人來說，要了解Git是很困難的。再加上Distributed Version Control 工具的特質，使得它在控管二進位檔(binary file)上，並不理想。而遊戲的製作上，多數的資料是會以二進位檔(binary file)的形式進來。以Git為控管工具的想法，勢必要有所調整。
當時也從新研究很久沒有理會的 SVN 版本，對於每個被控管的目錄裡都會放著控管所需要的.svn目錄這樣的作法，不管過了多少年後 (第一次使用 SVN 是在2005) 依然無法接受，總覺得這是一種侵入式的管理手法。不可否認的這算是各人好惡的關係，所以在研究後還是沒有想使用SVN。而 Mecurial，雖然是和 SVN 類似的使用難度，但其 Distributed 的特質和 Git 仍然一樣，並不適合 binary file 的控管 (並沒有深入的去了解big file extension的部份)。在網路上積極的尋找後，終於找到很適合開發遊戲或處理binary file的版本控管工具 Perforce。
Perforce之前並不是免費的工具，但有一定規模以下免費試用的 license，在此程度的試用下，使用者是可以無限其免費使用。只是前幾年的版本，這樣的規模是很局限的，只能夠讓二位使用者和5個 Workspace (此為Perforce裡特有的概念) 使用， 或是1000檔案以下不論多少使用者或是Workspace。以下會稍微介紹一下2 users/5 workspace 的概念。
Perforce是 client/server 的架構，所有的資料都會被控管在 server 端(和SVN無異)，但 workspace 並不是等同於 client 的機器的概念，而比較像是目錄的概念。在 Perforce 的架構下，假設一個repository同時開了二個分岐(branch)，而在 client 的電腦上若是想要同時看到這二個branch，則必需使用二個 workspace。這對於不會有多個 branch 的專案或是不需要同時看到不同branch的作業模式來說，沒有太大的問題。而對於1000個檔案以下任一使用者和 Workspace 的作業來說，或許小型的專案是可行的，但隨著規模的增加，很難避開只有1000個檔案可以被控管的限制。這二個使用模式只能擇一，不論是2 users/5 workspace或是1000檔案的模式，都讓早期的 Perforce 很難被小型團隊(通常代表了資源上規模很有限)考量。
Perforce Server Side
Perforce Client Side
所幸在當時考慮使用 Perforce 時，Perforce 就已經將試用規模大幅度的調升至20 users/ 20 workspace(另一模式仍維持1000個檔案)。在量的使用上不會有綁手綁腳的顧慮，再加上 Perforce 所給的 Client 工具很直覺操作，所給的 Admin 的工具在調整使用者和專案的權限上也很容易，且 Perforce 在處理 binary file 效能上又比 SVN 等工具來得好。總總的考量後，決定導入Perforce，和 Git 並行使用，取其各優點，讓版本控管的流程順利被建置。
開發遊戲時對於各跨業背景人員的產出物，藉由 Perforce 控管 binary file 而 Git 控管source code，再加上 Google Docs 的協同工具。看起來都沒有問題，但在 Unity 的專案裡，要對全部的檔案進行控管卻又沒有這麼順利。在過往的經驗中，只有 Unity Pro 的版本才有辦法開啓版本控管的功能，並針對所有的檔案產生相關連的 meta 檔。而整個專案進入Unity Standard 的版本後，所有的 meta 檔並不會被維持下來。對於有專案進入不同 Unity 版本的考量下，控管整個 Unity 特有的專案並不理想。當時想 Unity package，藉由 export 和 import Unity package 來達成資料進入不同 Unity 版本的方式。
按照 Package 相依性的控管，減少 export 的檔案大小。企劃人員產出的主要為 prefab。而 prefab 通常是美術資料和script的組合。所以在 export 時，就請企劃人員移除 package 的相依性，讓 prefab 所需要的美術資料或是 script，另由美術人員或程式人員額外輪出。整個package的 import 上，只需要以反向的方式進入。相將美術人員和程式人員所產出的 package 拉進來，再將企劃人員的 package 拉進來，整個專案就可以重新組合。以 package 的方式還原整個專案，就簡單的避開了不同 Unity 版本之間控管資料的問題。
所有的 package 都由 Perforce 做控管，雖然程式碼還是以Git那做控管，但一樣也export成package，放入Perforce裡，以確保整個專案可以直接由 Perforce 裡的 package 被還原出來。在日後的自動化測試中，這會是很重要的一步。
這樣方式弄出來的版本控管，以目前仍在持續開發中的專案看來還算順利，雖然偶爾也有些異常的小插曲，但合作的美術、企劃人員，慢慢的了解到版本控管，也慢慢地改變之前的習慣，開始接受版本控帶來的好處。而程式人員也接觸到 SVN 以外的控管工具。從專案的開發學習到新的事務，讓整個過程變得更加的有趣！
[小編 碎碎念]
如果你覺得這篇文章寫的不錯，請給我們一個 "贊"，加油打氣吧！ ^__^
使用Unity開發遊戲一段時間，目前在研究已自動化測試的方式協助Unity專案的開發。
沒有留言:
張貼留言