一、网络游戏架构的前世今生(1)

本文中的部分资料内容源于前aws的同事。

第一章将按下述顺序进行展开

  1. 网络游戏架构的基本理解
  2. 网络演进
  3. 计算演进
  4. 数据库演进
  5. 存储演进
  6. 实际案例
  7. 总结

网络游戏架构的前世今生

    • 1. 网络游戏架构与游戏引擎
    • 2. 网络方案演进
      • 2.1 网络同步方案

1. 网络游戏架构与游戏引擎

网络游戏架构(简称游戏架构)是一个听上去既高大上又“原始”的话题,业内其实谈及的场景非常非常非常有限。之所以说它高大上,是因为大家谈论的很少,思考的也相对较少;说它“原始”是因为,大部分谈论的架构、解决方案、场景,通常都是Web应用,与前沿且成熟的Web架构相对比,会产生游戏架构“原始”的感觉。我一直认为这里的“原始”是一定要加上引号的,因为我并不认为游戏架构真的粗糙而简陋,因为技术方向的差异,游戏更多的关注点在于一致且高效的性能——同样一个人能忍受不到半秒的下单延迟,却很难忍受哪怕稍微一停顿的切换装备(专业点这里的例子应该用存档来表述)。玩家希望游戏是极度流畅(这里的极度相比于一般Web应用)、稳定且能提供7*24小时不间断服务的,而游戏架构正是设计为这样的用户需求服务。

这里有必要区分一下“游戏引擎”和“游戏架构”这两个概念。在单机游戏中这两者没有太大区别,但在网络游戏中,我所认为的游戏架构的概念是一个更广的概念。提及游戏架构,往往会想到——客户端使用xxx游戏引擎,网络通信使用xxx网络连接,服务器使用xxx架构;游戏引擎一般指游戏客户端的可视化开发工具和可重用组件,与开发环境高度集成。我接触过白鹭、cocos2dx、Unity、CryEngine、Unreal Engine、Lumberyard,它们中的有一些已经扩展了不少服务器相关的功能组件,例如 Unity 的服务器方案,UE4 的 Dedicated Sever,大部分引擎也拥有自定义的组件市场,里面的功能保罗万象。但游戏引擎不是游戏架构,因为游戏架构不存在固定数量的最优解,而在这些组件包装好的同时,也失去了灵活性,所以这些组件通常只为对性能、对用户体量预期较低的小型游戏服务。游戏架构就像一个一眼看不到边界的大舞台,每个游戏开发者都能在这个舞台上大展拳脚,去实现自己独一无二的游戏。

游戏架构的演进很多时候是出于完全自发的状态,对于游戏本身的追求,部分时候甚至会高过把它当作一个用来赚钱的商品,这是一种强大的自驱力。 当我们做一个第一人称射击游戏,刚开始我们能对一个靶子开枪从而获得分数,自然而然的,我们想和身边的朋友比比谁更准,所以我们需要一个网络联机方案,把朋友们拉入一局对战。而当朋友没空时,我们需要一个机制让陌生人也能一起对战,所以我们需要一个匹配方案。而当我们的枪法水平在短时间得不到明显提升,需要一个成长机制持续不断的感受到正反馈,所以我们需要一个成长方案,例如更好的装备、更好的属性。游戏架构正是在一个又一个想法的产生与实践下不断演进。
一、网络游戏架构的前世今生(1)_第1张图片

大部分游戏都需要持续不断且“短期”的正反馈,这也是游戏区别于其他应用的地方,这也是游戏如此令人着迷的地方。为了提供更持续更高效的正反馈,必须把用户体验做到更好。有些硬核游戏的正反馈流程较长,有些甚至需要几十、上百小时的游戏游玩时间,但这也远比生活中的一般项目获得正反馈的时间成本要低了,也更强烈。

2. 网络方案演进

2.1 网络同步方案

回到网络游戏的早期,MUD、MUX游戏兴起,部分单机游戏提供局域网联机对战的功能,我们在仅由文字、字符画、简单贴图描述的世界中自由探险。在游戏中,我们需要近实时的和其他玩家交互,聊天、合作或对战。游戏把我们连接到一个世界中,进行网络同步,这是最早期的P2P(peer-to-peer)架构。
一、网络游戏架构的前世今生(1)_第2张图片

每个玩家在本地主机上所执行的指令快速同步到其他主机上,让所有主机计算出相同的战局信息,通过程序渲染展示给每位玩家看到,这种同步方案也被称为帧同步。这种帧同步带来了三个最明显的问题:1、逻辑不同步导致对局信息混乱;2、外挂(例全图挂,对于所有指令的本地直接解析显示)3、单局能承载的人数少,更多帧同步相关细节在这里不做展开。
一、网络游戏架构的前世今生(1)_第3张图片

一种思路是,我们可以从这些玩家中选举出一个主机,由它来进行一些仲裁。被选为主机的玩家被赋予了更多的权力,而它的机器性能和网络环境也成为一个重要的影响因素,主机的提前退出、网络中断都会导致游戏的结束,而主机糟糕的网络会严重影响其他玩家的游戏体验。当今,有一些支持自定义地图编辑器的游戏,使用这种方式进行网络联机。
一、网络游戏架构的前世今生(1)_第4张图片

第二种思路是,我们可以部署一系列独立的服务器,由他来作为主机,负责帧信号的同步、少量仲裁。游戏公司承担了服务器部署、维护的职责,游戏公司一般会选择网络条件较好的机房、采购昂贵的大带宽,由于早期网络环境比较复杂,还需要分别使用三大运营商所接入的机房,到后面开始有BGP接入的机房才能削减机房接入数量。这种架构也被成为 c/s (client/server) 架构。
一、网络游戏架构的前世今生(1)_第5张图片

第三种思路也是 C/S 架构,只不过我们换了一种同步方案。我们希望更多的人在同一个游戏世界进行交互,希望百人、千人、万人在同一个世界同时游玩;我们希望解决逻辑不同步导致的灾难性后果。由此我们设计了状态同步的架构,即服务器负责计算不同人物、物体的状态属性变化,并将这种状态属性的变化告知客户端,由客户端进行渲染展示,从而代替了同步逻辑帧(玩家指令)这种做法。这种方案被广泛应用在MMORPG、SLG等游戏中,部分MOBA类游戏在重要对局(例如电竞比赛)时,也会由帧同步切换为状态同步,当然也有全部状态同步的MOBA游戏。
一、网络游戏架构的前世今生(1)_第6张图片

网络同步方案各有优劣,目前不存在完美的网络同步方案适合所有的游戏场景,根据游戏类型和玩法需求选择一种或几种相结合是目前的主流。

未完待续……

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