手機遊戲開發記事【25】開發、測試、正式的三階段開發架構 ... | 遊戲開發流程
當然，如果只是將機器分成這三層並沒有什麼稀奇，重點是有了這三層的架構之後，接下來的版本管控以及更新的流程才是最重要的。
以營運型遊戲的開發狀況來 ...Skiptocontent在手機遊戲的暢銷排行榜上，可以看到大多數的遊戲都是營運型的遊戲。
所謂的營運型遊戲，指的是遊戲的開發並不是上架後就結束，而是需要持續的配合遊戲營運的需求，進行遊戲的更新、內容調整以及後續內容的開發。
這樣的遊戲雖然相對來說獲利較佳，不過對於遊戲開發團隊來說人力的需求相對也比較高。
或許是因為排行榜看起來營運型的遊戲獲利比較佳，因此有部份的中小型團隊為了追求獲利也投入營運型遊戲的開發。
之前銀狐去協助某個獨立開發團隊的時候，它們在做的也是一款營運型的遊戲。
這之後銀狐又陸陸續續接觸到一些中小團隊，也看到它們正在開發營運型的遊戲。
不過，或許是因為這些團隊並沒有做過營運型的遊戲，也或許是他們把做營運型遊戲的這檔事想得太簡單，所以銀狐在聽了他們對於遊戲版本的管控以及更新的作法後，不禁要為他們的未來擔心。
銀狐曾經擔任過線上遊戲製作人很長的一段時間，當時負責的專案也在線上跑了非常長的時間，因此對於遊戲版本的管控以及更新的流程有相當程度的瞭解。
因此今天就利用這篇文章，來說明一下我們當初是怎麼做版本管控以及更新的。
當初在銀狐問到要怎麼做更新的時候，某個團隊給了銀狐一個很讓人驚嚇的回答：「就把開發站的東西全部倒到正式站。
」銀狐當時為了避免誤會，還接著再問到了在遊戲開始營運後，下一次的更新會怎麼做，該團隊的成員則是再一次重覆的說「就再把開發站的東西全部倒到正式站就好。
」聽到這裡，銀狐確認了該團隊的確是把開發營型遊戲的這檔事想得太簡單。
而他們對於遊戲版本的管控以及更新，更是完全沒有思考過這樣做會碰到什麼樣的問題。
如果真的照他們這樣的方式去搞營運型遊戲，那麼可以預見很快的遊戲就會出大包。
那麼，當銀狐在擔任線上遊戲製作人的時候，我們是怎麼做的呢。
首先，我們的專案會有三組機器，這三組機器分別是：開發站(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(以下稱之為Patch1.1-1)，然後將它放到測試站上。
這個Patch1.1-1依據項目的不同，有時會包含伺服器端、客戶端以及資料，有時則只有其中的一個或兩個部份。
而這個Patch放到測試站後，相關的人員就會在測試站上行測試，確認這個Patch1.1-1的內容是否能夠在測試站上正確的運作。
如果有問題，那麼就會在開發站上進行修正，然後重新製作Patch1.1-1再將它放到測試站上再做確認，一直到Patch1.1-1在測試站上運作無誤，才算完成這個項目的測試。
在1.1版預計要更新的項目中，可能會有好幾項，因此
以營運型遊戲的開發狀況來 ...Skiptocontent在手機遊戲的暢銷排行榜上，可以看到大多數的遊戲都是營運型的遊戲。
所謂的營運型遊戲，指的是遊戲的開發並不是上架後就結束，而是需要持續的配合遊戲營運的需求，進行遊戲的更新、內容調整以及後續內容的開發。
這樣的遊戲雖然相對來說獲利較佳，不過對於遊戲開發團隊來說人力的需求相對也比較高。
或許是因為排行榜看起來營運型的遊戲獲利比較佳，因此有部份的中小型團隊為了追求獲利也投入營運型遊戲的開發。
之前銀狐去協助某個獨立開發團隊的時候，它們在做的也是一款營運型的遊戲。
這之後銀狐又陸陸續續接觸到一些中小團隊，也看到它們正在開發營運型的遊戲。
不過，或許是因為這些團隊並沒有做過營運型的遊戲，也或許是他們把做營運型遊戲的這檔事想得太簡單，所以銀狐在聽了他們對於遊戲版本的管控以及更新的作法後，不禁要為他們的未來擔心。
銀狐曾經擔任過線上遊戲製作人很長的一段時間，當時負責的專案也在線上跑了非常長的時間，因此對於遊戲版本的管控以及更新的流程有相當程度的瞭解。
因此今天就利用這篇文章，來說明一下我們當初是怎麼做版本管控以及更新的。
當初在銀狐問到要怎麼做更新的時候，某個團隊給了銀狐一個很讓人驚嚇的回答：「就把開發站的東西全部倒到正式站。
」銀狐當時為了避免誤會，還接著再問到了在遊戲開始營運後，下一次的更新會怎麼做，該團隊的成員則是再一次重覆的說「就再把開發站的東西全部倒到正式站就好。
」聽到這裡，銀狐確認了該團隊的確是把開發營型遊戲的這檔事想得太簡單。
而他們對於遊戲版本的管控以及更新，更是完全沒有思考過這樣做會碰到什麼樣的問題。
如果真的照他們這樣的方式去搞營運型遊戲，那麼可以預見很快的遊戲就會出大包。
那麼，當銀狐在擔任線上遊戲製作人的時候，我們是怎麼做的呢。
首先，我們的專案會有三組機器，這三組機器分別是：開發站(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(以下稱之為Patch1.1-1)，然後將它放到測試站上。
這個Patch1.1-1依據項目的不同，有時會包含伺服器端、客戶端以及資料，有時則只有其中的一個或兩個部份。
而這個Patch放到測試站後，相關的人員就會在測試站上行測試，確認這個Patch1.1-1的內容是否能夠在測試站上正確的運作。
如果有問題，那麼就會在開發站上進行修正，然後重新製作Patch1.1-1再將它放到測試站上再做確認，一直到Patch1.1-1在測試站上運作無誤，才算完成這個項目的測試。
在1.1版預計要更新的項目中，可能會有好幾項，因此