营运型手游开发、测试、正式的三阶段开发架构

小篱

文/银狐 授权游资网发布

在手机游戏的畅销排行榜上，可以看到大多数的游戏都是营运型的游戏。所谓的营运型游戏，指的是游戏的开发并不是上架后就结束，而是需要持续的配合游戏营运的需求，进行游戏的更新、内容调整以及后续内容的开发。这样的游戏虽然相对来说获利较佳，不过对于游戏开发团队来说人力的需求相对也比较高。

或许是因为排行榜看起来营运型的游戏获利比较佳，因此有部份的中小型团队为了追求获利也投入营运型游戏的开发。之前银狐去协助某个独立开发团队的时候，它们在做的也是一款营运型的游戏。这之后银狐又陆陆续续接触到一些中小团队，也看到它们正在开发营运型的游戏。

不过，或许是因为这些团队并没有做过营运型的游戏，也或许是他们把做营运型游戏的这档事想得太简单，所以银狐在听了他们对于游戏版本的管控以及更新的作法后，不禁要为他们的未来担心。银狐曾经担任过线上游戏（注：网络游戏）制作人很长的一段时间，当时负责的专案也在线上跑了非常长的时间，因此对于游戏版本的管控以及更新的流程有相当程度的了解。因此今天就利用这篇文章，来说明一下我们当初是怎么做版本管控以及更新的。

当初在银狐问到要怎么做更新的时候，某个团队给了银狐一个很让人惊吓的回答：

“就把开发站的东西全部倒到正式站。”

银狐当时为了避免误会，还接着再问到了在游戏开始营运后，下一次的更新会怎么做，该团队的成员则是再一次重覆的说：

“就再把开发站的东西全部倒到正式站就好。”

听到这里，银狐确认了该团队的确是把开发营运型游戏的这档事想得太简单。而他们对于游戏版本的管控以及更新，更是完全没有思考过这样做会碰到什么样的问题。如果真的照他们这样的方式去搞营运型游戏，那么可以预见很快的游戏就会出大包。

那么，当银狐在担任线上游戏制作人的时候，我们是怎么做的呢。首先，我们的专案会有三组机器，这三组机器分别是：

开发站(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版，接着就以这样的流程持续的开发下去。

说到这里，或许又会有人说，为什么要用这么麻烦的方式。简单的说，这样的开发流程，就是要确保放到正式站的项目是正确的。如果我们采用那个全部倒过去的方法，那么那些还没有要开放或是还没有开发完成的项目就会跑到正式站，可能会造成一些问题。而且这样的方式，开发人员对于更新项目内的各项物件有更好的掌握，也更清楚它们之间的关连，未来如果出了状况时要找问题也会知道从何找起，是比较安全的开发模式。