遊戲企劃必修課：來聊聊「版本管理」
遊戲開發如何借鑒工廠流水線的流程設計？
常常聽到遊戲上線前開放「公測版本」，上線後的「改版更新」，這些耳熟能詳的詞彙究竟是什麼意思？
今天就來聊聊遊戲的「研發流程」以及「版本控制」吧。
什麼叫做「版本」？
所謂的版本，是產品在研發過程中「有差異的不同內容」。無論是硬體生產或是軟體研發，都有所謂版本的差異。而用來辨識版本的東西，就是「版本號」。
例如出書有「修訂版」、「初版再版」或「限定典藏版」，成衣工廠的衣服也有不同「形状」的「版」（稱為版型），在生產過程中，版本是相當常見的名詞。
軟體研發中的「版本」
在軟體研發領域中，所謂的「版本」指的就是整個軟體在研發週期中「某個時間點的狀態」。
可以參考維基百科「軟體版本週期」的這張圖：
以遊戲開發為例，通常會分為三個大的階段，包括
- Alpha版本：內部研發版本。
- Beta版本：類似的名稱包括先行版、快照版本、測試版等等。
- Release版本：正式釋出版本。
以下簡單的介紹一下各階段的差異。
Alpha版（開發中版本）
最前期的版本，可能只比Prototype完整那麼一點點，但實際上離產品完成還有非常遙遠的距離。Alpha版本的開發時間通常是最長的。
通常Alpha版本比較少會開放給使用者，以遊戲為例子，Alpha版本很可能連一個完整的遊戲週期都無法完成。例如玩家進入地牢死亡後沒辦法重來，也不支持存檔功能等等。
Beta版（開發和測試）
Beta 版本是相較 Alpha 更為穩定和完整的版本，通常在這個時期遊戲的大功能已經完成，循環週期已經建立，可以進入大量測試的階段。
Beta也是通常研發公司會對外公開的版本，以Steam平台而言，通常 Early Access 的遊戲大都是達到這個完成度的。
一般常見營運類遊戲的「封閉測試」、「刪檔測試」等等也都是這個時期進行，讓部份獲得資格的玩家協助除錯並提供改進建議。
Release版（正式版）
這個稱呼或階段比較複雜，但基本上可以統一視為「正式上線」的版本。對於接外包的研發公司來說，這個版本就是要交付給顧客的版本了。
原則上在這個階段，惡性BUG（阻礙性的，例如閃退或無反應等等）要被完全修復，其餘問題也要修復到一個比例以下，符合上線標準。
Stable版（穩定版）
Stable版本通常是在軟體或遊戲有「持續更新」的情況下，用來標記某個階段性更新完畢，並且做過完整測試的版本。
舉例來說，Minecraft這款遊戲有諸多版本，版本號從最早的Beta，進入到1.0、1.1、1.2，一直到1.16（截止最新的數字）。
在這些大版本中間，會穿插一些小版本，被Minecraft官方稱為「快照版本」（Snapshot），這些快照版本更新了新的系統和功能，但因為還沒有開發完畢，也尚未做過全面性的穩定測試，所以這些快照版本就是研發版本號中的「不穩定版」（Unstable）。相較這些快照版本，有正式版本號的版本就是穩定版。
什麼是「版本控制」或「版本管理」？
所謂的版本控制（Version Control）是指在軟體研發中，維護程式碼架構的一種手段，除了能夠追溯程式碼的歷史版本、回復修改和合併不同人寫的程式碼之外，也方便處理程式碼之間的衝突。
而協助開發人員做版本控制的軟體就是版控軟體，常見的包括像是SVN或是Git等等。（維基百科上的「版控軟體」解釋）
版控軟體大概是在做什麼呢？
舉個例子，如果今天有個班級，老師希望學生們在同一張表格上填寫自己未來想從事的職業。
這時為了節省大家的時間，讓大家回去自己填寫在小紙條上，再由班長統一收回後轉填到表格上。
這個「收集後轉填」的動作，就很類似版本控管的工作。
但軟體開發沒這麼簡單，並不是像填表格一樣，把大家寫的東西接起來就好了。
因為軟體要運作起來，每個區塊並不是各自為政的。需要確保每個工程師寫出來的程式碼能共同運行，在這個情況下，往往會有不只一個工程師調整了「同一段程式碼」。
這種情況，就稱為「衝突」（Conflict）。到底要以哪個人修改的為準，就是個大問題。一般來說，後面交付程式碼的工程師，需要負責解決這個衝突。（當然，也有不解決，直接覆蓋過去這種暴力解法，但多半會出問題就是了）
而「版本控管」的工作，就是排解衝突、決定哪些工程師交付的程式碼要合併到主幹等等。
一般而言版本控管通常是由研發團隊中的程式主管或產品控管部門（例如QA主管）來負責，也有團隊會特別開一個職位來負責這件事情。
版控軟體的種類
版控用的軟體通常分為兩種類型：
- 集中式
所謂的集中式，指的是程式碼統一在一台主機上進行管理，所有人更改之後都會更新到這台主機上。同一時間「僅能有一個人對同一個檔案進行更改」。 - 分散式
相對於集中式，分散式允許每一位工程師的電腦上都存放程式碼，可以在客戶端進行修改調整。
開發上比較彈性，等到需要把功能整合時，再將各個分支（Branches）合併（Merge）在一起，解決衝突後就能一起運作了。
工程師可以將主幹（甚至是其他分支）的內容先下載到自己的電腦上，做合併嘗試之後，整理好再上傳到主機，相較於中央集中式如果遇到主機掛掉或網路不穩的時候，工程師還是可以單兵作戰。
集中式的版控方式由於比較單純，對「非程式人員」比較友善。例如美術人員知道他只要更新特定資料夾裡的美術素材就行了，不需要學習如何拉分支或是查看一大堆歷史紀錄。
而分散式的版控方式對程式碼的調整則更彈性，許多工程師比較喜歡使用這種類型的版控軟體，但由於門檻較高，操作不太直觀，使用上需要花較多的學習成本。
上面這兩種方式其實各有特色，沒有高低之分。根據團隊的規模和習慣，選擇合適的類型就可以了。如果極小型的團隊（例如只有一個程式人員）那很可能根本不需要版控軟體的協助。
版控軟體介紹
以下介紹一些筆者比較熟悉的版控軟體，讓大家參考。
集中式-TortoiseSVN
SVN（Apache Subversion）是一款開放原始碼的版控軟體，詳情可以參考維基百科的介紹。
TortoiseSVN則是其中一個基於 SVN 開發的圖像化版本，俗稱小烏龜，由於是免費的，入手門檻也低，所以頗受好評。
這邊只提小烏龜，但其實SVN衍生出來的有多個版本可以使用，小烏龜只是最常用的一種，也因為有中文版本，在台灣用的人也不少。
TortoiseSVN支持Lock（鎖定）指定的檔案，修改過程中不允許其他人編輯和上傳。但實際上如果使用者忽略警告，還是很容易把檔案覆蓋過去就是了……
畢竟SVN是集中式的資料控管，在編輯內容衝突的時候很不好解決。雖然支持同時開啟兩個檔案，比對不同的內容，方便合併的時候處理衝突，但整體而言還是相當麻煩。
集中式-Perforce（P4）
P4其實並不是那麼常見，只是筆者剛好有用過，所以特別提一下。
基本上就是高級版本的SVN，費用不便宜（20人以上需付費），所以通常是大公司或大型研發團隊在使用的。人數多的團隊，P4的優勢才會比較明顯。
和傳統SVN的差異是優化了客戶端搜尋和查找分支的操作，也彌補了SVN太過依賴中央伺服器的缺點，允許一定程度的分散式開發，在解決衝突時更方便。
不過筆者實際上使用覺得其實並不直觀（對企劃而言），尤其是從Server同步下來的資料預設是唯讀有點令人困擾……需要解鎖之後才能進行修改，常常會因為忘記這件事情而需要另存再取代。
Git應該是目前工程界最多人使用的版控軟體了。由於是分散式以及免費使用，因此在軟體開發界相當受獨立工程師的青睞。
另外筆者這邊也推薦一款圖像化的Git管理軟體（沒錯，管理版控軟體的軟體）：SourceTree。
在SourceTree中，各個分支（Branch）一覽無遺，圖像化大大降低了學習門檻。
其他工具
可以參考維基百科上對於版控軟體的整理。
此外其實像Unity本身就有內建多人協作的機制，多個使用者可以共用同一個專案並且上傳更動的內容，但由於功能不是非常全面，在大型開發專案通常還是會獨立用一個版控軟體來負責這件事情。
來談談「軟體測試」吧！
前面聊了那麼多版本控管的原理和工具，不知道讀者們看到這裡心中有沒有個疑問：「為什麼要做版本控管呢？」其實除了每個版本之間的差異之外，另一個很重要的原因就是「測試」。
先講一個很重要的觀念，「任何對軟體的改動都可能造成新的BUG」。就連「修復BUG」這件事情本身，都有可能造成新的BUG。
因此，開發到一個程度後，就需要「鎖版本」，也就是限制工程師們往主機上提交程式碼，然後QA們（註1）介入進行測試，等到QA測試的差不多了，回報的BUG也都被工程師們修正了之後，這個「穩定的版本」才能交給客戶，或是更新到外網給玩家們玩。
常常有些錯誤的研發流程，是在「QA還在測試版本」的時候，依舊不斷的往版本裡面加入新功能，這會導致更多的BUG以及衝突，讓版本變得更不穩定。（但是請相信我，有非常多的遊戲公司會這麼做）
而且QA會很崩潰，因為每加入新的功能，他們就得把遊戲從裡到外全部重測一次。
為什麼有改動就要重測？
我們用個比較好理解的比喻。
假設今天，汽水和果汁加在一起，變成「果汁汽水」是好喝的。
香菇雞湯單喝也是好喝的。
但你無法保證，這三種材料加在一起，也會是「好喝的」吧？
因此無論任何微小的改動，都有可能影響到整個軟體版本的穩定性。
而且，這個影響是全面的，有時A功能的調整，會影響到B功能。
軟體就像一杯混合的飲料，QA的職責就是讓最後這杯飲料好喝，但如果一面回報「鹽加太多」或「糖少了」的同時，調酒師還不斷的往杯子裡加新的材料，那無論如何也不可能調出好喝的飲料來的。
「版本穩定性」和「測試」在研發規模越大的專案，就越重要。
「研發」和「測試」都需要時間！
測試遊戲版本也是需要時間的，測試員不是魔術師，並不是把遊戲丟給他們，就能瞬間找出所有BUG然後列成表給到工程師。
那麼，QA在測試遊戲的時候，開發人員是不是就可以休息一下了呢？
太天真了少年。
在QA測試的時候，除了工程師需要修復他們提出的BUG之外，還有很重要的一件事情，那就是「開發下一個版本！」
沒錯，萬惡的研發公司是不可能讓員工閒下來的！（誤）
所以，在同時有「測試版本」和「開發版本」以及「上線的玩家版本」等諸多版本的情況下，版本控管就更顯重要了。
筆者這邊簡單的介紹一下比較正規的長期開發遊戲，所使用的研發流程。
來看看「遊戲研發流水線」吧！
以常見的手機營運遊戲而言，版本的更新時間大約是
- 臨時更新版本：修復嚴重的BUG
- 每週維護版本：修復一些BUG，更新一些資源或配置表
- 3周～6周小版本：新增卡池、活動等等。
- 3個月大更新：新增新系統或大功能。
一般而言一個版本的完整測試時間至少需要1～2周（人力充足的情況下，QA和企劃的人力比約為1:1）。因此3個月這種大型功能更新的版本，在正式上線前至少2周或一個月就需要進入「穩定測試」的階段，否則很可能來不及上線，或是在問題很多的情況下更新給玩家使用。
「四版三線」
所謂的四版三線，指的是持續開發過程中，需要四個版本和三個開發分支。
開發分支分別是
- 主線（Trunk）：大型功能或是未來新增功能的開發分支，工程師主要把功能上傳到這個分支。QA不進行大規模測試，只排除阻礙性的BUG和做簡單的冒煙測試（註2）。
- 測試分支（Test）：下一個小版本預計要上線的功能都在這個分支，鎖版本僅限修復BUG，不提交新功能。QA主要在這個分支上進行測試，確認這些功能都沒問題。
- 穩定分支（Pre-Release）：已經通過QA測試，可以準備更新上線的分支。每週維護的小版本更新通常是由這個分支出的版本。
（備註：分支的稱呼百百種，每個專案有各自的研發流程，這裡僅供參考）
每當到了所謂「研發里程碑」（Milestone）的時候，就會從主線分出一條新的測試分支，而原本的測試分支改為穩定分支，最後將舊的穩定分支封存起來，不做更新。
聽起來有點複雜？我們直接看圖吧。
舉例來說，版本號 1.0 一開始進行開發，開發到基本功能完成時，就會將1.0這個分支當成是「測試分支」，並且從 1.0 切一條新的 1.1 版本當成新的「開發分支」，繼續往裡面開發新功能。
同理，到了第二個切分支的時間點時， 1.0 版本已經測試完畢，變成「穩定版本」，可以準備更新給玩家了。這時從1.1切出新的1.2版本作為新的「開發分支」，而1.1版本則開發告一段落，進入「測試和修復的階段」。
可以看到從1.2版本開始，就會需要至少三個分支來進行持續的開發。
依照這樣的流程，從研發、測試到上線，不斷的輪迴，這就是遊戲研發的流水線了。
值得一提的是，分支BUG的修復需要「往後合併」，也就是說，在舊版本發現的BUG，也需要在新的版本上一起修復。
例如若是在1.0版本的測試階段遇到的BUG，就需要在「1.0」和「1.1」兩個版本都修復。
而前面所謂的「四個版本」，指的就是除了三分支各有一個版本外，更新到外網的版本也算是獨立的版本，因此總共需要三條分支，但實際上卻會有四個版本。
額外補充
其實小規模的遊戲開發不用到四版三線這麼麻煩，有些團隊會將版本縮減為只有開發版本和穩定版本，要測試時直接從開發版本切出一個版本給QA。但這樣做的缺點就是無論開發版本上面有多少新功能，都會跟著從穩定版本一起上線給玩家。
如果是功能比較複雜的專案，分支多一些會保險一點。
註2
所謂的「冒煙測試」，是指在調整完成後，很快速的進行一個初步的測試，確認程式可以正常運轉。
這個詞是來自於工廠硬體設備的同名詞彙，意思是在組裝完機具之後，接上電源看看是否有「冒煙」故障，如果沒有冒煙則通過最初步的測試，因而得名。
這邊順便解釋幾個測試領域的詞彙
- 阻礙性BUG
也稱為惡性BUG，是指QA測試中，遇到會造成「閃退或Crash」、「中斷流程操作」等，讓軟體無法繼續進行下去的問題。例如UI界面沒有反應，卡在某個畫面之類的。
在上線版本中，阻礙性BUG是最急並且需要被優先修復的。 - 白盒/黑盒測試
是指測試工程師是否能得知軟體的運作原理，所做的測試。一般來說前期會先做白盒測試，用來針對例如極值或防呆等等的設計，後期在Beta版本才會進行黑盒測試。順道一題，玩家所作的遊戲測試都是黑盒，因為他們沒有參與研發，也並不知道遊戲的邏輯計算。
以餐廳為例，你能看到廚師做菜過程的餐廳，就是白盒測試，若無法得知軟體的內部運作原理，那麼就是黑盒測試。 - 測試用例（TestCase）
通常是指測試工程師在正式測試之前，針對要測試的功能範圍、以及研發單位提供的說明文件，整理出來的測試要點。例如針對一個按鈕，測試用例有可能會列出「外觀是否正常」、「互動方式是否正確」或是「點擊後的預期結果」等等，整理好的測試用例能方便後續同一個功能快速測試，或是移交給其他測試員來進行。
在一些研發團隊中，也有看過QA在研發初期就加入討論，和企劃一起撰寫TestCase（或是根本由企劃撰寫）這樣的作法。 - 自動化測試
指的是事先寫好另一套測試軟體，用軟體來測試軟體。通常需要在研發初期就由工程師一起進行，雖然開發成本較高，但一旦完成後，基本的邏輯測試和功能測試可以自動運行，省下後續的測試需求。
但自動化測試僅能測試功能錯誤，無法測試設計錯誤，例如他只管計算邏輯是否正確，但無法偵測設計錯誤的公式或是填錯數字的配置表。 - 壓力測試（Stress Test）
通常用來測試遊戲伺服器是否能夠承載大量的玩家湧入。QA一般測試功能時不會創建很多帳號，但在實際營運過程中，玩家的數量是相當可觀的，這時就需要進行「壓力測試」，用來測試遊戲系統在預期的玩家數量時，是否還是能穩定運作。
所以，何謂CB和OB？
以上聊了這麼多，大家可以理解遊戲的開發到上市究竟有多麼不容易了吧？
每次更新版本，研發團隊總是嚴陣以待，就是怕出問題，需要緊急修復。
那麼，常見的「刪檔測試」或是「封閉測試」究竟是什麼東西呢？
CB（Close Beta/Closed Beta）
所謂的CB，又稱為封閉測試，通常指的是遊戲開發到一個階段了，希望能邀請第三方（無論是測試公司或是玩家）來進行測試。
例如常見的「刪檔封測」就是CB的一種，藉由釋出「限量名額」讓玩家參與遊戲，除了行銷之外也能獲得玩家的反饋建議。
通常為了測試方便，封測版本的道具掉落或是經驗值取得速度都是比較快的，能在短時間內讓玩家玩到較後期的內容。但這麼做也有風險就是了，可能會錯估正式版本實際玩家的內容消耗速度以及遊戲體驗。
OB（Open Beta）
所謂的OB就是公開測試了，通常是「不限量」讓玩家可以進入到遊戲中遊玩，但因為還是處於測試階段，尚未正式營運，也有可能是刪檔測試，或者在測試期間不保證玩家的資料穩定性（通常不會開放付費系統）。
順道一題，CCB這個詞其實是誤傳，正式的研發流程通常不會有這個階段，應該是台灣遊戲公司自己發明的一個詞，被當作是「封閉的封閉測試」的意思。
以「崩壞三」為例
這邊舉個長期營運開發，且每隔1.5個月都能穩定更新的遊戲「崩壞三」。
就筆者的觀察，應該也是至少有三個以上的版本分支。
除了玩家拿到的最新版本之外，還有所謂的「測試伺服器」，會讓一些「被選中的人們」，我是指被抽中的玩家，進到測試伺服器當中。
測試服可以玩到下一個版本才會更新的角色和武器，以及關卡Boss等等。
測試服的玩家資料和正式服不能互通，但參與測試的玩家能在正式服獲得一些額外獎勵。
這種方式除了提高行銷力度（釋出部份改版消息讓玩家期待）之外，也能藉機收集玩家反饋，調整數值強弱和部份設計。（例如太OP的角色註定活不出測試服）
版本控制是個繁瑣但重要的工作
遊戲開發真的很麻煩，有太多太多的事情要考量。
這也是為什麼業界通常會把「至少要先準備好3～6個月的版本更新內容」當作是一款遊戲準備好要上線的前提了。
因為上線後，還會有非常多接踵而來的事情，邊應付這些的同時，也要邊開發新內容，著實令人頭疼。
但即便如此，筆者我還是依舊熱愛著這個行業就是了。（根本超M的）
寫在最後
版控是門學問，但也並沒有哪一種方式最好，根據專案的人數和方向，選擇適當的工具才是最重要的。
有時考量到「團隊成員的學習成本」或是「死線」等因素，很難把版控流程做的非常標準，這也都是可以理解的。
最終，研發還是以產品品質來說話，只要能做出好產品，流程倒是其次了。
試著用比較平易近人的方式做比喻，希望今天談的東西不算太硬。
有機會再來談談軟體測試吧，這也是比較容易被忽略的領域。
那麼，今天就到這邊。
我是水狼，我們下次見。
也可以到臉書追蹤我喔： 粉絲專頁連結
最後，請多利用我的個人文章列表，會持續更新：
