一、网络游戏架构的前世今生——计算篇

上文： 网络游戏架构的前世今生（2）

计算方案演进

游戏的分类

游戏的分类方式有很多种，从玩家容易理解的玩法角度，我们可以把游戏分为ACT、AVG、TCG、RPG、SLG、FPS、RTS等类别，从战斗流程来划分，可以分为即使战斗、回合制等类别。从游戏开发的角度来看，可以把游戏简单分成两类，会话类（session-based）和非会话类游戏。我最近玩的较多的游戏 糖豆人 就属于会话类游戏。

我们来深入理解一下会话（session）这个概念。会话指的是，区别于一个连续不断的虚拟世界，玩家进入游戏大厅后，会进入一个个的游戏房间，完成一局游戏后回到大厅等待下一轮的游戏。当然，我们也可以把一个连续不断演进的世界看成一个无时间边界的会话，即非会话类游戏。我理解的会话类游戏的前身是桌面游戏（当然传统棋牌也属于广义上的桌面游戏），我们召集到一群玩家，在固定的规则下，为了胜利各司其职；而非会话类游戏的前身是虚拟世界，电脑的发明促使了这一想法的落地，我们可以在一个虚构的世界内自由探索，体验游戏世界的时间流逝，享受虚拟世界带来的快乐。

既然非会话类游戏是一个独立的虚拟世界，世界中也可以塞入一些相对独立的会话类小游戏。很多日系老RPG游戏，会在世界中放入精心设计的关卡、小游戏，以增加游戏世界的丰富程度。巫师三中塞入昆特牌，魔兽世界中塞入的炉石传说，都是很好的例子。非会话类游戏中的pvp玩法，也可以看成一个内置的会话游戏。对于这些游戏，我们按核心玩法分为非会话类，但其中包含的会话玩法，也可以按照会话类游戏的架构方案进行演进。

会话游戏的简单架构

前文中已经有所涉及，我们直接从 c/s 架构开始。假设我们开发了一款线上五子棋游戏，最简单的结构是，我们在客户端中写入一系列可用的服务器地址，每次都随机的进入任意一个会话对局中，等待一个对手到来并开始对局。更进一步，我们允许玩家查看每个服务器现在的玩家状况（即是否存在对手，对手的基本信息等），玩家会自行挑选合适的对手进行游戏。

这样的结构很类似早期的线上棋牌游戏大厅，那时候玩家对这种线上游戏乐此不疲。

我们发现，给客户端开放了过多且复杂的能力，这会让整个游戏变得不安全且难以维护，所以我们需要做一个游戏大厅，而把承载游戏会话的服务器“隐藏起来”。同时，我们需要一个匹配（matchmaking）机制，自动分配玩家到实力相近的对局之中。我们将“服务器”这个概念拆解为两个，一个是逻辑服务器（逻辑服，logic server，负责对局外的逻辑处理），另一个是战斗服务器（战斗服，game server，负责对局内的对战信息处理）。

至此，我们已经完成了一个基本能玩的会话游戏，可以自由匹配，进入对局完成局内对战，然后再进入新一轮循环。为了增加更多的可玩性和成长玩法，我们可以加入玩家资产（背包）相关的功能，让玩家能在战局之外也能感受到自己在“成长升级”，给予持续不断的正反馈；我们也可以加入玩家数据相关的功能，让玩家可以查询自己的游玩数据，例如总游戏时长、胜利局数等；我们还可以加入别的功能，例如邮件系统、挑战任务系统等等，来进一步丰富游戏的玩法和增加用户粘性。

伴随游戏发售后，新一波的挑战随之而来。我们的游戏涌入一大波新玩家，新玩家开始抱怨匹配时间过长/排队等待时间过长，我们需要应对日益增长的玩家数量的要求。同时，由于过多的人涌入大厅，单个大厅应用不堪重负，时长发生崩溃导致停服的事件。所以我们需要扩展我们单体应用的计算能力，以应对持续增长的同时在线人数。

上图同时展示了一种当下主流的战斗服管理方式，即由会话管理器（session manager）管理战斗服的生命周期（开启、人员加入、关闭）。根据策略，将一局需要的所有玩家，尽可能分配到最合适的会话对局之中，完成对局后再回收。

分服、合服、全球同服

玩家有时候会产生困惑：当前在线玩家很多，为什么我还是匹配不到人？为什么我在大厅遇到的很少是同一个国家地区的人？我们当前只是粗暴的水平扩展了大厅的数量，却无法满足玩家多样化的需求。所以我们决定，把选择权交还给玩家，把一个游戏拆分成多个区服，同一个区服的玩家总会进入同一个大厅，他们总是能见到同样一批队友或对手，互相加好友社交，一起游戏。我们可以按照国家地区进行分服，也可以按照其他的规则进行分服，让玩家可以自行选择区服进入。

分服之后，我们将玩家分隔在一个个独立的区服之中。刚开始一切都很美妙，随着游戏的持续运营，玩家数量走下坡路，在个别区分难免会遇到玩家过少，难以正常游戏的情况。遇到这种情况后，我们选择将两个或多个人较少的鬼服合并，从而保证游戏的正常运营。

合服的技术难点主要在玩家数据的整合之上，这一点数据库章节会展开讨论。

分服和合服容易在商业游戏中被滥用，逐渐消耗玩家的游戏热情。越来越多的玩家开始渴望，所有玩家能够在一起游玩、社交、组队，游戏内的逻辑边界——区服被舍弃，但硬件的发展远远赶不上玩家对游戏品质的要求。所以在2019年前后，全球同服是游戏业内热门的话题，全球同服的游戏，对玩家更具吸引力，也为玩家带来更好的游戏体验，促进了玩家的留存与活跃。全球同服的需求带来了一系列的技术挑战，分布在全球各地的玩家几乎在24小时内不间断的体验游戏内容，每一个玩家都希望体验到低延迟的流畅体验，每一个玩家都不希望在自己想玩的时候遭遇游戏维护，要求更短的游戏维护窗口。

并不是所有游戏都适合实现全球同服，对于要求极高的实时响应延迟的游戏，通常要求50毫秒内的延迟，例如即时格斗、即时运动类游戏，通常的做法还是划分出多个区服，亚洲服，欧洲服等，服务不同分布的玩家群体。对于那些能忍受100毫秒左右延迟的游戏而言，最简单的做法是逻辑服集中式部署，战斗服分布在全球各地部署，在匹配时收集玩家的延迟数据，尽可能分配到低延迟的战斗服之中。而逻辑服的操作较为低频，玩家对延迟的感受相对较弱，这种架构是最常见的，也是初期应该采用的架构。

如果我们想要进一步优化逻辑服的延迟，我们可以在全球范围内部署多个代理做中转，以达到更好的游戏体验。

更进一步想，如果我们把逻辑服分布部署到全球各地，效果会更好，但需要特别注意的去处理数据存储方案，对于跨洋数据同步性问题的处理，可能会导致灾难，需要慎重考虑。我的建议是，除非是上线后其他优化方案还是不满足需求，否则不要轻易尝试。

本文只从游戏架构的角度介绍了优化全球同服体验的方案，但在实际开发过程中，游戏渲染、游戏设计的角度也能起到不可忽视的优化作用。例如：我们可以通过技能前摇、放置冷却等数值设置，配合游戏动画的播放时间降低网络延迟的影响。如果技能的前摇是300毫秒，而这个释放技能指令在网络上消耗了130毫秒，那接收到指令的客户端只需要播放剩余的170毫秒前摇动画，就能降低非竞技型玩家对延迟的感知。这些例子在弱竞技场景下还有很多案例。

未完待续……