从上线崩服到2年稳居畅销榜前5,FGO工程师复盘长线运营经验

来自 游戏葡萄 2017-07-13
深度

[ 游戏葡萄原创专稿,未经允许请勿转载 ]

从上线崩服到2年稳居畅销榜前5,FGO工程师复盘长线运营经验

今井守

《Fate/Grand Order》(简称FGO)自2015年7月发行以来,至今已突破900万下载。游戏在App Store和谷歌Play的销售排行榜上屡次获得1位,在日本平均稳定在畅销榜第5的位置。而后游戏还在国内掀起了二次元的热潮,凭借活动多次进入畅销榜前五。

fgo1副本.jpg

《Fate Grand/Order》

在FGO早期发行的时候,曾面临过多次服务器崩溃问题,前半年成绩波动很大。但现在FGO已经保持优秀的成绩运营了2年,在长期的运营过程中,游戏更新和数据资源分配则成了开发团队主要去解决的问题之一。

近期,在一次学术交流会上,FGO服务器工程师今井守公开了游戏长线运营方面的更新、数据管理等方面的经验。

今井守是DELiGHTWorks的服务器程序设计师,大学毕业后作为系统工程师就职。后转职游戏公司,担当智能手机方向的游戏开发,并于2014年入职DELiGHTWorks担当FGO的服务器程序设计师。

在2015年7月游戏发行后,面对新的活动和功能,大量的问题导致开发组不断的对已有功能进行修正。在开发、运营过程中今井体会到了“定期更新、长线运营的管理方法”和数据结构设计的重要性,下面是他的分享内容:

定期更新:数据管理规范与自动更新

FGO基本每周都会进行主数据和资源包的更新。游戏会在不进行应用更新的情况下,每周更新小中规模活动和宣传,并进行轻微问题的修正。然后大约每月一次会进行大规模活动和新故事章节的更新,新活动和主线的功能、常规的新功能、已有功能的改善、重大的问题修正等内容一般会在这个时候更新。

那么,面临如此频繁的更新应该如何进行数据管理,首先针对主数据有以下几个要点:

1. 数据录入还是Excel好。虽然不能合并是很大的一个缺点,但由于多数开发者的使用习惯,最终还是选择了Excel录入数据。(译者注:如何管理文档就因团队而异了,不过优化管理方式的目标是一样的)

2. 多人数据输入。高频度的更新仅靠一人是很难应付的,所以需要多人共同作业。比如,活动和任务的文件分开管理。任务相关的内容很多,所以在更新时会分成很多个文件。

f3.png

3. 基本每周都进行主数据的更新。

4. 多个更新的并行开发。提前1、2个月或者1周进行更新的并行开发。

5. 尽量在1个Excel里分成多个TAB处理数据。

6. 未来的更新内容不提前进行数据传输。

未公开的角色的信息在下一个活动前绝对不能泄露。只限制客户端显示的方法并不够好,因为当主数据传输到客户端的时候就有被解析的风险,所以不提前进行数据传输的设计是必要的。(译者注:这一部分就是为了防止提前泄露游戏的活动、素材)

同时,为了清晰的进行定期更新,实现自动化更新的方式,我们在文档中引入了tag标签进行分割。

f4.png

橙色的部分为TAG,以时间分割,如“tag_20170101”

f5.png

用Excel内置工具转换成CSV文件时,各自的tag也能导出

f6.png

实现了自动更新

根据这个,在指定了文件夹的状态下让阶段更新主数据就可行了。并且除了看出区别外,QA步骤可以多数同时进行。

下面就是关于主数据管理工作流的完整图示:Excel→CSV→DB的常规流程,其中CSV不会进行直接编辑。

f7.png

数据管理工作流

另外,FGO除了用时间tag自动更新外,用户全员的点数合计值(比如伤害、敌人击破数)到达特定的数值之后,系统将进行判定并进行版本的自动更新。

f8.png

利用tag自动更新

在过去,需要手动更新才能满足这些要求,工作到深夜这件事非常辛苦,而现在自动化方式成为了我们主要去研究的形式。

为了优化数据管理流程,我们还引入了migrate版本管理工具。在普遍方法中,为了在不同版本中添加或删除数值列,需要在代码层面上解决。

f9.png

左下、右下分别是对value数值列的添加、删除代码

而FGO通过使用版本控制工具migrate,可以立即切换数据库的版本,不需要在代码层面上重新实现。(译者注,这可能是针对数据库的操作,相比svn等版本控制工具会便利一些)

f10.png

migrate实现了数据库版本迅速切换

将到这为止的内容总结如下:

1. “为数据阶段性释放的管理方法”的目标需要多下功夫;

2. 管理方法没有正确答案,还是请选择对应项目的必要方法。

长期运营:思考数据结构的扩展性

接下来我会围绕长期运营的数据结构进行讨论,并结合两个例子进行说明。首先我们来看第一个例子“任务的开放条件”。

设问“当任务A达成后,开放任务B。当任务B达成后,开放任务C。”,为满足这种条件应该怎么设计数据表呢?下边有来两个数据结构案例。

f11.png

这两个方法都是可行的,但随着持续的运营,需要的判定条件也会越来越多,数据表就得进一步扩充。

当同时存在“A、B两个任务同时达成后,任务D开放”、“持有物品A,任务E开放”、“关卡A达成后,任务F开放”几个需求。那么,按照方案2规划数据表会多出一堆无用数据“0”,并且不断积存。

f12.png

很多0都是无用数据

所以为了打破这种现状,请务必把任务和开放条件分开,并且只定义必要的条件。如图所示,两个表分开以后,在下方的开放条件表里,逐条增加条件类型。这样结构清晰,也没有多余的浪费数据,数据十分容易扩展。

f13.png

不过,OR判断条件不适合上述方法,为此我们使用了条件组的追加,不同组的条件为“or”关系,同组的条件为“and”关系。

这里举例“当任务A或任务B达成后,开放任务G”时的三种解决方案:

方案1 条件类型定义在一个表上,较为繁琐且产生了多余数据;

f14.png

每个条件类型都需要补充一长串数据

方案2 条件类型进行分表,把条件组单独成表进行判断;

f15.png

利用数组让案1、案2结合起来

方案3 定义数组,利用数组[101,102]的情况代表or关系,将两种条件合并到一张表中。[101,102]可能拥有特殊的规则去定义他们的关系,[101,102]代表or,[101;102]代表and,这样就很清晰和方便了。

第二个例子是任务的报酬图标。FGO中报酬图标会直接显示或用宝箱表示,2种报酬同时存在时,图标会交互显示。

f16.png

两种图标

当报酬图标ID是否为零时,两者的区别是:等于0时,报酬ID参照右边的报酬主表显示图标。不等于0时,将图标按照报酬ID直接显示。

f17.png

报酬表(右)的ID是可扩展的物品、装备

对于长期运营的数据结构设计,总结如下:

1. 考虑主数据的“可扩展性构造”,使其可以普遍适用于今后的内容。

2. 从现在的要求出发,设想“今后必须要的扩展”。

特别要说的是,FGO为了实现主线故事中的特殊活动,特殊功能的开发也是必要的(比如,完成特定的任务需要对Servant的真名进行判断)。而且,新的活动每次都必定会有新的功能。

在运营过程中,也许就会遇到一些意料外的情况,所以需要开发这可以提前设想一些应对措施。

比如我们在FGO某个新章节活动开放前一天发现了问题:

1. 活动日期不能更改;

2. 玩家在某关中必须观看2分钟左右的动画,且无法跳过;

3. 我们必须给出一个跳过动画的功能;

4. 已经来不及等待iOS审查通过。

我们迅速创建了一个可以跳过剧情的关卡任务X+,如果玩家没有一次性通过任务X,那么下一次开始他们只会进入任务X+的循环流程。这么做的目的是让玩家在看完一次动画后,就能在有动画跳过功能的新任务中进行游戏,从而解决强制看动画的问题。

f18.png

流程树右边是任务X+的循环过程

为了让玩家玩上游戏,有时强行进行更新修改也是必要的,不过也要考虑到对服务器负荷的影响。

最后,我以一款长线产品服务器程序设计师的身份,为大家分享两条工作建议:

1. 套用已有功能:

在处理新功能需求时,工程师要经常考虑是否存在已有的功能可以套用,以及已有功能的扩展能不能满足新功能的需求。因为相似的功能增加后,程序的维护成本就会随之增加,所以在制作新功能前一定要进行已有功能的确认。

2. 主动提出需求实现方案:

在只需要对已有功能进行较小改动,就能实现新需求的时候,工程师可以积极提出更易实现需求的方案。这可以避免相似功能的增加和多余工作量的产生。

在提案时,最重要的是理解新功能的目的,其次是对工作量的正确评估。

以上就是演讲的内容,我们可以看到,产品长期发展一定会遇到数据管理和产品迭代问题,只有化繁为简、理清思路才能让产品稳定运营下去。

文章评论
游戏葡萄订阅号