今井守
《Fate/Grand Order》（简称FGO）自2015年7月发行以来，至今已突破900万下载。游戏在App Store和谷歌Play的销售排行榜上屡次获得1位，在日本平均稳定在畅销榜第5的位置。而后游戏还在国内掀起了二次元的热潮，凭借活动多次进入畅销榜前五。
《Fate Grand/Order》
在FGO早期发行的时候，曾面临过多次服务器崩溃问题，前半年成绩波动很大。但现在FGO已经保持优秀的成绩运营了2年，在长期的运营过程中，游戏更新和数据资源分配则成了开发团队主要去解决的问题之一。
近期，在一次学术交流会上，FGO服务器工程师今井守公开了游戏长线运营方面的更新、数据管理等方面的经验。
今井守是DELiGHTWorks的服务器程序设计师，大学毕业后作为系统工程师就职。后转职游戏公司，担当智能手机方向的游戏开发，并于2014年入职DELiGHTWorks担当FGO的服务器程序设计师。
在2015年7月游戏发行后，面对新的活动和功能，大量的问题导致开发组不断的对已有功能进行修正。在开发、运营过程中今井体会到了“定期更新、长线运营的管理方法”和数据结构设计的重要性，下面是他的分享内容：
定期更新：数据管理规范与自动更新
FGO基本每周都会进行主数据和资源包的更新。游戏会在不进行应用更新的情况下，每周更新小中规模活动和宣传，并进行轻微问题的修正。然后大约每月一次会进行大规模活动和新故事章节的更新，新活动和主线的功能、常规的新功能、已有功能的改善、重大的问题修正等内容一般会在这个时候更新。
那么，面临如此频繁的更新应该如何进行数据管理，首先针对主数据有以下几个要点：
1. 数据录入还是Excel好。虽然不能合并是很大的一个缺点，但由于多数开发者的使用习惯，最终还是选择了Excel录入数据。（译者注：如何管理文档就因团队而异了，不过优化管理方式的目标是一样的）
2. 多人数据输入。高频度的更新仅靠一人是很难应付的，所以需要多人共同作业。比如，活动和任务的文件分开管理。任务相关的内容很多，所以在更新时会分成很多个文件。
3. 基本每周都进行主数据的更新。
4. 多个更新的并行开发。提前1、2个月或者1周进行更新的并行开发。
5. 尽量在1个Excel里分成多个TAB处理数据。
6. 未来的更新内容不提前进行数据传输。
未公开的角色的信息在下一个活动前绝对不能泄露。只限制客户端显示的方法并不够好，因为当主数据传输到客户端的时候就有被解析的风险，所以不提前进行数据传输的设计是必要的。（译者注：这一部分就是为了防止提前泄露游戏的活动、素材）
同时，为了清晰的进行定期更新，实现自动化更新的方式，我们在文档中引入了tag标签进行分割。
橙色的部分为TAG，以时间分割，如“tag_20170101”
用Excel内置工具转换成CSV文件时，各自的tag也能导出
实现了自动更新
根据这个，在指定了文件夹的状态下让阶段更新主数据就可行了。并且除了看出区别外，QA步骤可以多数同时进行。
下面就是关于主数据管理工作流的完整图示：Excel→CSV→DB的常规流程，其中CSV不会进行直接编辑。
数据管理工作流
另外，FGO除了用时间tag自动更新外，用户全员的点数合计值（比如伤害、敌人击破数）到达特定的数值之后，系统将进行判定并进行版本的自动更新。
利用tag自动更新
在过去，需要手动更新才能满足这些要求，工作到深夜这件事非常辛苦，而现在自动化方式成为了我们主要去研究的形式。
为了优化数据管理流程，我们还引入了migrate版本管理工具。在普遍方法中，为了在不同版本中添加或删除数值列，需要在代码层面上解决。
左下、右下分别是对value数值列的添加、删除代码
而FGO通过使用版本控制工具migrate，可以立即切换数据库的版本，不需要在代码层面上重新实现。（译者注，这可能是针对数据库的操作，相比svn等版本控制工具会便利一些）
migrate实现了数据库版本迅速切换
将到这为止的内容总结如下：
1. “为数据阶段性释放的管理方法”的目标需要多下功夫；
2. 管理方法没有正确答案，还是请选择对应项目的必要方法。
长期运营：思考数据结构的扩展性
接下来我会围绕长期运营的数据结构进行讨论，并结合两个例子进行说明。首先我们来看第一个例子“任务的开放条件”。
设问“当任务A达成后，开放任务B。当任务B达成后，开放任务C。”，为满足这种条件应该怎么设计数据表呢？下边有来两个数据结构案例。
这两个方法都是可行的，但随着持续的运营，需要的判定条件也会越来越多，数据表就得进一步扩充。
当同时存在“A、B两个任务同时达成后，任务D开放”、“持有物品A，任务E开放”、“关卡A达成后，任务F开放”几个需求。那么，按照方案2规划数据表会多出一堆无用数据“0”，并且不断积存。
很多0都是无用数据
所以为了打破这种现状，请务必把任务和开放条件分开，并且只定义必要的条件。如图所示，两个表分开以后，在下方的开放条件表里，逐条增加条件类型。这样结构清晰，也没有多余的浪费数据，数据十分容易扩展。
不过，OR判断条件不适合上述方法，为此我们使用了条件组的追加，不同组的条件为“or”关系，同组的条件为“and”关系。
这里举例“当任务A或任务B达成后，开放任务G”时的三种解决方案：
方案1 条件类型定义在一个表上，较为繁琐且产生了多余数据；
每个条件类型都需要补充一长串数据
方案2 条件类型进行分表，把条件组单独成表进行判断；
利用数组让案1、案2结合起来
方案3 定义数组，利用数组[101，102]的情况代表or关系，将两种条件合并到一张表中。[101,102]可能拥有特殊的规则去定义他们的关系，[101，102]代表or，[101；102]代表and，这样就很清晰和方便了。
第二个例子是任务的报酬图标。FGO中报酬图标会直接显示或用宝箱表示，2种报酬同时存在时，图标会交互显示。
两种图标
当报酬图标ID是否为零时，两者的区别是：等于0时，报酬ID参照右边的报酬主表显示图标。不等于0时，将图标按照报酬ID直接显示。
报酬表（右）的ID是可扩展的物品、装备
对于长期运营的数据结构设计，总结如下：
1. 考虑主数据的“可扩展性构造”，使其可以普遍适用于今后的内容。
2. 从现在的要求出发，设想“今后必须要的扩展”。
特别要说的是，FGO为了实现主线故事中的特殊活动，特殊功能的开发也是必要的（比如，完成特定的任务需要对Servant的真名进行判断）。而且，新的活动每次都必定会有新的功能。
在运营过程中，也许就会遇到一些意料外的情况，所以需要开发这可以提前设想一些应对措施。
比如我们在FGO某个新章节活动开放前一天发现了问题：
1. 活动日期不能更改；
2. 玩家在某关中必须观看2分钟左右的动画，且无法跳过；
3. 我们必须给出一个跳过动画的功能；
4. 已经来不及等待iOS审查通过。
我们迅速创建了一个可以跳过剧情的关卡任务X+，如果玩家没有一次性通过任务X，那么下一次开始他们只会进入任务X+的循环流程。这么做的目的是让玩家在看完一次动画后，就能在有动画跳过功能的新任务中进行游戏，从而解决强制看动画的问题。
流程树右边是任务X+的循环过程
为了让玩家玩上游戏，有时强行进行更新修改也是必要的，不过也要考虑到对服务器负荷的影响。
最后，我以一款长线产品服务器程序设计师的身份，为大家分享两条工作建议：
1. 套用已有功能：
在处理新功能需求时，工程师要经常考虑是否存在已有的功能可以套用，以及已有功能的扩展能不能满足新功能的需求。因为相似的功能增加后，程序的维护成本就会随之增加，所以在制作新功能前一定要进行已有功能的确认。
2. 主动提出需求实现方案：
在只需要对已有功能进行较小改动，就能实现新需求的时候，工程师可以积极提出更易实现需求的方案。这可以避免相似功能的增加和多余工作量的产生。
在提案时，最重要的是理解新功能的目的，其次是对工作量的正确评估。
以上就是演讲的内容，我们可以看到，产品长期发展一定会遇到数据管理和产品迭代问题，只有化繁为简、理清思路才能让产品稳定运营下去。
