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

原创 作者:银狐 2019-02-28


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


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

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

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

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

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

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

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

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

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

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

最新评论
暂无评论
参与评论

Facebook游戏出海峰会
推广
商务合作 查看更多

编辑推荐 查看更多