当我为用户提供一个在浏览器中玩《无实体游戏》的解决方案，并且不需要硬件时，我意识到这项任务花费的时间要比我预计的两周多出不知道多少倍，后来我还是花了一个多月的时间使其达到可接受的状态，仅仅是实现《无实体游戏》在线播放的Pixel Streaming实现罢了。

尽管如此，我还是认为这是值得的。这项成就可能是值得的。实现这个项目最大的成就就是我能够在浏览器中启动一款《无实体游戏》仅用41秒。

这个组件是我的职业生涯中最困难的事情之一。我已经在12岁时开始学习编程，使用C++，而这个项目差不多让我想考虑放弃整个项目。

这是我的第一个关于Glitch的开发日志，这是一个游戏平台，它允许游戏在不下载任何应用程序的情况下直接在线发布，而开发者也可以根据游戏运行时间获得支付。这个日志的焦点是实现Unreal Pixel Streaming。

是什么是Unreal Pixel Streaming？

如果你是新手，了解Unreal Pixel Streaming的能力就是在无需硬件的情况下以互联网的方式播放一款《无实体游戏》。

在Unreal中搭建的游戏玩家一直存在一个问题：硬件。如果一种游戏在PlayStation、Xbox这样的大型家用游戏机上，这些问题就不是那么大，你知道需要做什么来让游戏在这些平台上正常工作。移动设备，特别是iOS比Android更可控，因为游戏限制都是相对的一致的。

而PC则是个完全不同的问题，因为它有无数种硬件配置，各种各样的GPU硬件，这个问题是很难解决的。

最终，在Pixel Streaming中，你可以完全避免这个问题。通过设置一个你知道硬件配置的服务器，你可以按照这些硬件配置来优化游戏。我的项目中，我使用的Azure NC4as T4 v3：

• CPU：4核
• RAM：28GB
• GPU：1颗T4
• GPU内存：16GB
• 临时硬盘：176 GB
• 最大NIC：2
• 最大带宽：8000 Mbps
• 主机家族：AMD EPYC 7V12（罗马）
• 架构：图灵
• 张量核：320
• CUDA核心：2560
• FP32：8.1 TLOPS
• FP16/FP32混合精度：65 TLOPS
• int8：130 TOPS
• int4：260 TOPS
• 内存：16GB GDDR6
• 内存带宽：NVIDIA的数据sheet指出为300 GB/s，而它的数据页上描述了更高的速度320+ GB/s
• 接口：PCIe 3.0 x16
• 功耗：70W
• 体积：PCIe低配置，通过散热器热却

在开发者眼里，每个开发者都知道该如何优化游戏的硬件配置。对于用户来说，游戏将在服务器上启动，通过WebRTC传输给用户，这意味着对于用户来说，无需再担心硬件问题了。同时，包括桌面和移动设备在内的所有设备都可以访问这些游戏。

Pixel Streaming的挑战

实现这个功能的成本是很高的，因此我们需要考虑以下几点

• 人工智能会误导你
• Unreal 4.x、5.x、5.5+
• 启动速度快
• 扩展流畅度
• 控制成本

Unreal 4.x、5.x和5.5+

作为一个平台，我们希望为所有的游戏提供服务，而Unreal项目中有一部分游戏仍在使用4.x。事实上，我们收到的游戏主机申请中的大部分游戏都是在4.x版本上开发的，这也许是因为在实战中，许多游戏开发者都是独立开发者，团队相对较小。

小团队面临的问题很大，因为他们往往会在更低的速度开发游戏。在这种情况下，独立开发者往往面临的困难和挑战比其他开发者更大。许多独立游戏开发者在Unreal 4.27之前开发这款游戏。考虑到目前的情况，似乎不少独立开发者仍在使用4.x。

然而在Pixel Streaming中，每个版本的Unreal都有所区别：

• Unreal Engine 4.x：

UE4-Era中的游戏用的是较旧的PixelStreaming 1 stack，这个栈基于Epic的 Cirrus.js 运行时信号服务和一个更加简单的静态Web前端。因此，它的部署路径是相对较轻的，但是它的执行流程较老。那么，这个版本家族的游戏就需要采用经典的关注鼠标输入的处理和采用较旧的 UE4-Era 的配置和启动模式。

• Unreal Engine 5.0到5.4：

UE5.0至5.4依然用的是较旧的Pixel Streaming 1 side，也就是说他们获得了在5.0至5.4版本中使用的旧版配置和启动模式。在5.0至5.4版本中，这些游戏使用了较新版本的鼠标输入处理，并且性能相比于4.0的鼠标输入处理更加流畅。但是，5.0至5.4仍然属于较为过时的系统。

• Unreal Engine 5.5：

UE5.5是最具挑战的系统之一，因为它采用了较新的Pixel Streaming2 stack来优化游戏启动过程，它具有全新设计。这个系统允许更快速的启动和更加轻松的运行，但它也意味着对于开发者来说，它更为容易出错。

# 每个版本的支持

支持每个版本并不简单，它们的支持都是相对独立的，每个开发者都需要在不同版本之间调整和适配，每个版本都是非常不同的。

快速启动

还一个问题就是启动游戏。特别是对于那些注意力容易让人分散的移动用户来说。我们优先考虑冷启动来节省成本，而冷启动正是指一个玩家启动游戏时，并不会马上启动游戏，而是延迟一段时间。这种情况使得我们节省了GPU的额外费用，减少了启动成本。有关更多详细信息，请查看我接下来会写的部分相关文章。

要了解如何解决这个问题，我们需要了解启动过程：

• 玩家需要请求启动游戏
• 请求发送给创建服务器的服务
• 服务器上需进行GPU分配，包含了文件系统、配置和其他组件，同时游戏可以在服务器上传输
• 服务在服务器启动后，开始启动，并传输给玩家
• 服务启动后，游戏启动并载入所有相关图像

这一系列过程很长，玩家想要启动游戏，就需要经历这个一系列的流程。

我当时启动这一系列的流程需要3-5 分钟，而这样的启动时间对于玩家来说太长了，经多次尝试后，最终我成功地利用优化后的程序，降低了这个过程的时间，总共约为21秒，其中18秒都花在了启动服务器上，剩下的3秒就是启动游戏了。显然我还有许多事情要做，我想我还不能说我已经达到最好的流程了。

扩展流畅度

现在我们成功提高了启动速度，接下来要做的就是确保游戏能在全球范围内流畅。通过在不同的地区分配GPU可以更好地解决这个问题，显然不只是在一个地区而已。如果要在整个世界范围内流畅，显然需要在最靠近玩家位置的地区分配GPU，所以就需要在每个地区都拥有计算能力的分数。

A.全球性基础设施

要实现这个目的，首先需要确保计算能力的分数已经在全球各地的最靠近玩家的地区。然而，并不是所有的机构提供商都会接受这样一个请求。然后还有另一个问题就是不同地区的GPU硬件，并不是都相同的，因此显然还需要进行设备硬件的设备校验。

B.全局性基础设施

一旦硬件设备分配完成，就需要进行设备配额，确保每个地区都能分配出相应的设备。在这个阶段，我们需要通过优化好的流程将服务器进行相应的处理。

C. 用户路由

最后，我们需要路由玩家到最佳的服务区域。也就是说，需要使用服务来了解玩家的具体位置，以便让GPU更接近玩家，玩家也能够在最短的时间内获得玩家所需要的服务。

# 控制成本

最后要做的就是控制成本。显然,GPU设备成本都不菲。大多数开发者在设备分配时会受到这些限制。

在这个项目中，我们需要了解设备成本和设备资源的配置。这不仅仅是考虑GPU的成本，还需要考虑GPU的配置和使用频率。并且，这一系列的流程也需要经常进行调整。显然，在这一系列流程中，重要的方面是控制成本，而在实际操作中，我们也得要考虑控制成本。

总的来说，像这样的系统不仅仅实现难度很大，仅仅是配置和成本控制方面的挑战。