走进Unity WebGL技术方案,为什么MMORPG能支持上万人

走进Unity WebGL技术方案

Unity WebGL技术方案在接入小游戏时，面临浏览器JavaScript执行环境的限制，比如单线程模式，这限制了Unity执行上下文的独占性。浏览器的安全策略也限制了JavaScript对本地文件系统的访问，因此开发者需要依赖远程加载，这直接影响了游戏资源的加载效率。不过，Unity在移植方案时已经做了大量工作，将部分实现暴露给JavaScript，以便为APP接入小游戏提供便利。

通过深入研究JavaScript源代码，我们可以更好地了解Unity WebGL平台的输出文件、启动流程以及细节构造。比如，index.是小游戏页面的加载入口，它通过加载webgl.loader.js来创建unityInstance，从而启动帧循环。同时，还会加载webgl.framework.js和webgl.data，以完成初始化和内存文件系统构建，最终实现游戏的渲染和运行。

Unity多线程渲染概述

现代渲染API的设计变革之一是摒弃中心化的渲染上下文，转而采用去中心化的命令队列来支持多线程渲染，使多线程渲染成为现代游戏引擎的基本功能。多线程渲染的主要目标是解决CPU在渲染过程中长时间等待GPU执行指令、导致画面卡顿的问题。为了充分利用现代渲染API并减小画面卡顿，引擎层需要构建基于多线程的渲染框架，将逻辑更新与渲染指令提交解耦到不同线程，以最小化二者间的干扰。以Unity为例，其多线程渲染框架通过主线程生成并写入渲染队列中的自定义渲染命令，同时渲染线程则读取这些命令并提交给GPU。这种流程确保多线程渲染的高效执行。

在主线程频繁向渲染线程提交渲染命令时，多线程策略显得尤为重要。为了优化效率，避免锁的消耗，虚幻引擎和Unity都采用了无锁策略。虚幻引擎使用LockFreeList实现无锁队列，并利用CAS（Compare And Swap）技术。而Unity则采用循环队列（RingBuffer），通过原子操作的Head和Tail指针来实现。这两种策略各有优缺点，循环队列通过原子操作实现生产者和消费者线程之间的高效同步。

Unity渲染框架的实现基于上下文的概念，兼容单线程和多线程渲染API。主线程和渲染线程各自拥有上下文对象，通过命令函数的一一对应实现命令传递。命令队列的原子操作，如入队和出队，采用简单阻塞机制确保线程间的同步。例如，入队前检查Tail指针是否超过Head指针，若超过则阻塞入队线程，直到数据出队。出队流程将检查Head指针是否超过Tail指针，以避免数据丢失。

此外，Unity多线程渲染框架通过RingBuffer策略实现简单高效的同步，无需额外的CPU Fence处理。然而，采用RingBuffer策略导致其多线程间同步仅限于生产者与消费者模式，复杂扩展受限。与虚幻引擎的RHI线程不同，Unity不支持多RHI线程扩展，部分“heavy API call”直接从主线程提交到GPU，这可能会影响主线程性能。

尽管存在一些限制，Unity的多线程渲染框架在实际项目中通常不会引起显著问题，其代码结构清晰、易于维护，是商业游戏引擎的一大优势。

3700X、I7 9700、E3-1230 哪一款适合开发Unity3D？

3700X和I7 9700通常比E3更优秀。

3700X是八核十六线程，具有较高的多线程性能，适合进行复杂场景的渲染等计算密集型任务。

I7 9700则是八核八线程，单核性能较高，在单线程应用中表现优异，适合于游戏开发中的编译、打包、导出等操作。

此外，对于渲染任务建议选择更高性能的显卡。

做个几万人一起玩的荒野大镖客有可能吗？

让我们从技术的角度来探讨这个问题。

多人游戏的规模一直是个复杂的问题。从MUD发展的MMORPG中，同时在线人数超过五位数并不少见，但在《方舟：生存进化》、《ATLAS》和“吃鸡类”游戏中，服务器或者房间的容纳人数一般在70到200之间。

不少玩家曾幻想将《荒野大镖客：救赎2》这样的单人体验转换为大型MMO，让数千名牛仔在西部世界中自由搏击，这样的设想非常壮观。但是，甚至技术力强大的Rockstar也只敢用“32人战局”的设计方式，在删减了一些内容的情况下推出《荒野大镖客Online》。

扩展多人游戏规模的瓶颈并不仅仅是资金问题。很多开发团队面临着“想做大却无法做到”的技术困境。《绝地求生》和《堡垒之夜》将玩家人数设置在100，并非全是为了关注数据，实际上他们的设计面临多种技术挑战。

我在CJ展会时接触了田桑，他之前在EA负责在线游戏的功能设计，之后在英礴担任游戏解决方案工程师，跟进过多个MMO项目。他对多人在线游戏的构造颇有研究，因此展开了我们的讨论。

为什么MMORPG能支持上万人

线上多人游戏的规模并不是一蹴而就的。早在1996年，MUD《侠客行》就曾在大学设置服务器，将在线玩家规模推至1000人，但那时却是一个极限。

同时期的图形化网游，因为用户状态复杂，更要求频繁数据同步。像《子午线59》，即使其号称是领先的产品，一个服务器的在线人数也仅为250人。

《网络创世纪》制作团队对用户规模操心不已，曾在测试过程中努力将并发人数提升到3000，虽然结果是漏洞百出。

在田桑看来，90年代是一个快速发展的时代。那时的用户扩容大多依赖于增加带宽和硬件，然而如今成本高昂，采用这种方法的代价也在不断上涨。此外，传统MMORPG使用的C/S（客户端-服务器）架构为实现数千人同时在线奠定了基础。

C/S最早为两层结构，玩家的电脑（主机）负责渲染，服务器处理游戏逻辑。后来又增加了一层数据库，保存游戏结果。

为了实现大规模用户，传统MMORPG在“保真度”上做出了很多妥协。保真度可理解为游戏细致程度，包括物理模拟和网络同步要求。

《黑色沙漠》在MMORPG中的保真度算得上不错，但与单机游戏相比仍显不足。

从单机游戏逻辑来看，通常在启动时将每个关卡中的图像从GPU中读取完毕。而在线多人游戏中的图像则具有不可预测性，需要频繁同步。

为了在保证用户规模的同时降低服务器负载，C/S架构需要设计一个复杂的后端。暴雪工程师处理这一问题的能力在于，利用“空间分割法”将地图划分，分配给不同的服务器进程。

另一个变种是“空间复制法”，即将世界复制多份，每份都放入一个服务器。而当玩家因获取物品或挑战高难度怪物而聚集时，又需要用“实例法”分副本为每波玩家提供有限区域。

由此可见，基于C/S架构的MMORPG在技术上具有相当高的门槛。市场需求与技术门槛相结合，使得不少开发者面对巨大挑战。

至于“100人”的数量级，即使市场上流行许多线上多人游戏，传统DS（专用服务器）架构则能最大限度提高网络游戏保真度。这种架构旨在解决FPS游戏的同步问题，追求高精度和低延迟，涵盖多个技术的运用。

田桑以虚幻引擎为例，指出DS结构下引擎在服务器上运行，客户端与物理计算、AI等逻辑解耦。然而，DS架构对服务器负载的要求也非常高。

例如，《光环5》的战区模式支持的最大玩家数仅为24人，原因在于服务器负载问题，因此NPC的行为也受到简化。

如果采用C/S架构的扩容思路，增加几台服务器就能够解决负载过高的问题，但服务器的主频和引擎的单线程设计都限制了承载量的扩展。

Epic为《堡垒之夜》能支持100名玩家苦思良策，优化引擎与服务器通迅，避免客户端频繁更新信息导致服务器负载过高。

在Unity中，尽管面临类似的挑战，但开发者仍需要在保真度与用户规模之间做出选择。多种方法的结合，也是未来游戏开发的方向。

像《ATLAS》这样的产品，虽然质量存在争议，却使用DS架构来支撑一万名玩家同时游戏。它通过自建世界服务器与数据服务器后端，拼接多个DS实例，实现了较高的人数。

英礴为了完善G的整个技术路线，开发了SpatialOS，这一工具兼具云端服务器托管及技术支持，适用于虚幻和Unity等引擎，主要目的是实现DS架构下的扩容。

SpatialOS的一种扩容思路，如同《ATLAS》，若一个DS不能满足需求，就将多个DS拼接，实现跨区域无缝游玩。

另一个技改便是“AI负载拆分”，任何不高耦合的部分都可以拆分到其他服务器上进行处理，从而为玩家扩容腾出空间。

虽然SpatialOS具备众多优势，田桑也提醒开发者需考虑到层间通讯带来的成本，这一问题无疑将影响开发者的决策。

综上所述，尽管技术上有余力推动《荒野大镖客：救赎2》至万人在线的目标，但实现难度和相关成本不可小视。