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

上文: 网络游戏架构的前世今生(2)

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

  • 计算方案演进
    • 游戏的分类
    • 会话游戏的简单架构
    • 分服、合服、全球同服

计算方案演进

游戏的分类

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

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

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

会话游戏的简单架构

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

一、网络游戏架构的前世今生——计算篇_第1张图片

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

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

一、网络游戏架构的前世今生——计算篇_第2张图片

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

一、网络游戏架构的前世今生——计算篇_第3张图片

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

一、网络游戏架构的前世今生——计算篇_第4张图片

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

分服、合服、全球同服

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

一、网络游戏架构的前世今生——计算篇_第5张图片

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

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

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

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

一、网络游戏架构的前世今生——计算篇_第6张图片

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

一、网络游戏架构的前世今生——计算篇_第7张图片

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

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

未完待续……

你可能感兴趣的:(游戏微服务架构实践,游戏后端,架构,游戏)