營運型手遊開發、測試、正式的三階段開發架構

在手機遊戲的暢銷排行榜上，可以看到大多數的遊戲都是營運型的遊戲。所謂的營運型遊戲，指的是遊戲的開發並不是上架後就結束，而是需要持續的配合遊戲營運的需求，進行遊戲的更新、內容調整以及後續內容的開發。這樣的遊戲雖然相對來說獲利較佳，不過對於遊戲開發團隊來說人力的需求相對也比較高。


或許是因為排行榜看起來營運型的遊戲獲利比較佳，因此有部份的中小型團隊為了追求獲利也投入營運型遊戲的開發。之前銀狐去協助某個獨立開發團隊的時候，它們在做的也是一款營運型的遊戲。這之後銀狐又陸陸續續接觸到一些中小團隊，也看到它們正在開發營運型的遊戲。

不過，或許是因為這些團隊並沒有做過營運型的遊戲，也或許是他們把做營運型遊戲的這檔事想得太簡單，所以銀狐在聽了他們對於遊戲版本的管控以及更新的作法後，不禁要為他們的未來擔心。銀狐曾經擔任過線上遊戲（注：網路遊戲）製作人很長的一段時間，當時負責的專案也線上上跑了非常長的時間，因此對於遊戲版本的管控以及更新的流程有相當程度的瞭解。因此今天就利用這篇文章，來說明一下我們當初是怎麼做版本管控以及更新的。

當初在銀狐問到要怎麼做更新的時候，某個團隊給了銀狐一個很讓人驚嚇的回答：

“就把開發站的東西全部倒到正式站。”

銀狐當時為了避免誤會，還接著再問到了在遊戲開始營運後，下一次的更新會怎麼做，該團隊的成員則是再一次重覆的說：

“就再把開發站的東西全部倒到正式站就好。”

聽到這裡，銀狐確認了該團隊的確是把開發營運型遊戲的這檔事想得太簡單。而他們對於遊戲版本的管控以及更新，更是完全沒有思考過這樣做會碰到什麼樣的問題。如果真的照他們這樣的方式去搞營運型遊戲，那麼可以預見很快的遊戲就會出大包。

那麼，當銀狐在擔任線上遊戲製作人的時候，我們是怎麼做的呢。首先，我們的專案會有三組機器，這三組機器分別是：

開發站(Develop)
測試站(Test)
正式站(Official)

這三組機器，故名思義可以知道它分別是用來用開發、測試以及正式對玩家開放使用的機器。如果遊戲是多個伺服器的架構，那麼可能就會有正式站一、正式站二等等一連串族繁不及備載的名稱。

看到這裡，也許有人會說，這個主機的架構不過就是多了一層測試站而已，看不出來多這一層有什麼好處。當然，如果只是將機器分成這三層並沒有什麼稀奇，重點是有了這三層的架構之後，接下來的版本管控以及更新的流程才是最重要的。

以營運型遊戲的開發狀況來說，通常會有許多不同進度的專案同時在開發中。換句話說，在遊戲還沒正式上線之前，在開發站上就會同時有第一版(以下稱為1.0版)、後續的更新內容(以下稱為1.1版)等等的專案同時存在開發站上。因此當遊戲準備要正式上線時，那些1.1版的內容因為尚未開發完成所以不應該放到測試站與正式站。

就假設今天開發小組的版本管控與開發工作切割得很乾淨，是真的把1.0版的遊戲內容都開發完成，將它們釋出到測試站與正式站再進入下個階段好了，那麼這個階段還可以採用把開發站的內容全部倒到測試站與正式站。但就算1.0版的時候可以這樣做，等到遊戲正式上線後，之後的1.1、1.2等等的版本，就無法再用這麼簡單的方式來進行更新。

營運型遊戲為了持續提供遊戲內容，因此當1.0版上線後，開發小組會立刻進行下個版本內容的開發，此時三臺機器上的版本就會變成這樣：

開發站：1.0 + 許多未來要更新的開發專案
測試站：1.0
正式站：1.0

因此每當一個預計要在1.1版開放的專案開發完成後，負責的程式人員必須將需要更新的專案做成Patch(以下稱之為Patch 1.1-1)，然後將它放到測試站上。這個Patch 1.1-1依據專案的不同，有時會包含伺服器端、客戶端以及資料，有時則只有其中的一個或兩個部份。

而這個Patch放到測試站後，相關的人員就會在測試站上行測試，確認這個Patch 1.1-1的內容是否能夠在測試站上正確的運作。如果有問題，那麼就會在開發站上進行修正，然後重新制作Patch 1.1-1再將它放到測試站上再做確認，一直到Patch 1.1-1在測試站上運作無誤，才算完成這個專案的測試。

在1.1版預計要更新的專案中，可能會有好幾項，因此還會有Patch 1.1-2、Patch 1.1-3等等的更新內容。假設1.1版預計有三項新功能，那麼在完成了1.1版的開發工作後，這時三臺機器上的版本就會變成這樣：

開發站：1.0 + 許多未來要更新的開發專案
測試站：1.0 + Patch 1.1-1、Patch 1.1-2、Patch 1.1-3
正式站：1.0

等到要開放1.1版的那一天，工程師就將測試站上的Patch 1.1-1、Patch 1.1-2、Patch 1.1-3這三個部份放到正式站上。由於測試站和正式站的基礎都是1.0版，然後Patch 1.1-1、Patch 1.1-2、Patch 1.1-3這三項在測試站上都已經經過了測試，只要測試的過程夠仔細，那麼在正式站上原則上不會出現問題。然後在完成這個動作之後，就可以將測試站上的版本打包起來正式稱它為1.1版，接著就以這樣的流程持續的開發下去。

說到這裡，或許又會有人說，為什麼要用這麼麻煩的方式。簡單的說，這樣的開發流程，就是要確保放到正式站的專案是正確的。如果我們採用那個全部倒過去的方法，那麼那些還沒有要開放或是還沒有開發完成的專案就會跑到正式站，可能會造成一些問題。而且這樣的方式，開發人員對於更新專案內的各項物件有更好的掌握，也更清楚它們之間的關連，未來如果出了狀況時要找問題也會知道從何找起，是比較安全的開發模式。