手機遊戲開發記事【25】開發、測試、正式的三階段開發架構

Posted by

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

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

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

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

「就把開發站的東西全部倒到正式站。」

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

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

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

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

  • 開發站 (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版,接著就以這樣的流程持續的開發下去。

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

您可以在這裡留下你對這篇文章的意見: