最近切了小组，其实老实讲，心中有点不舍，其实内心中还是更想研究具体的渲染效果的算法，原因嘛所见即所得，看着自己落地的算法（抄来的算法hhh），渲染出了想要的效果，那感觉多爽…另外还有对之前小组的Leader的一点愧疚，毕竟从她当上PL开始就一直跟随着，算是在这个组里最老的了，就这么离开了哎，奈何在大主管面前不敢表述自己的想法（不过这个问题也太难答了：“切到另一个小组，有没有什么抵触”，让我咋回答嘛），就这样到了一个新的组里。新的组也挺好，看着是在做“向上捅破天”的战略任务，但是技能点得洗干净了重新点。既来之则安之吧，把手头事情做好才是首要的。
新的小组目标是做云游戏的框架，又是个从0到1的任务。近两天重点关注了这篇论文，一边看一边翻译翻译。
开始之前：【】中的内容为作者的个人观点，与论文本身无关。
论文：Palazzi-engine-iscc16
论文地址：https://www.math.unipd.it/~cpalazzi/papers/Palazzi-engine-iscc16.pdf
SMASH：分布式游戏引擎体系结构
摘要
在过去的几年里，我们目睹了视频游戏实现方式的变化。早期的时候往往由一个开发人员负责领导整个游戏的创作过程，现在我们已经逐渐演变为具有多层次组织的非常庞大的团队。团队组织的复杂性不断增加，加上项目规模的快速增长，在这样的背景下，要求我们要采用更具可扩展性的和分布式计算环境的开发方法。
不幸的是，今天的游戏开发和运行环境（通常称为游戏引擎）正受到许多体系结构限制。因此，我们坚信，当前的引擎将无法提供下一代游戏开发者所需要的灵活性和可扩展性。
为了克服上述限制，在本文中，我们提出了SMASH（用于共享环境的无堆栈微内核体系结构）：这是一种体系结构，其中游戏引擎被分解为几个动态和独立的软件模块，通过类似微内核的消息总线方式进行交互。一旦游戏模块的内部消息传递协议被明确定义，独立的模块就可以从正在运行的引擎中动态地插入、调试和删除。此外，遵循这种方法，游戏模块可以在多台计算机上动态地移位，以获得一个真正分布式、可扩展和具有故障恢复能力的系统，在这种系统中，适配工作基本上可以在不停机的情况下实现。
简介
在过去的几年里，开发者实现视频游戏的方式正在经历巨大的变化。在视频游戏刚兴起的时候，通常一个非常小的群体，甚至是一个人，就能够负责游戏软件生产的各个方面。事实上，我们可以看到许多80年代的家庭娱乐大片游戏，比如陷阱、俄罗斯方块、波斯王子等都有一个开发商的名字。如今，随着娱乐市场的演变和预算高达七或八位数的项目的兴起，这种情况正在改变。
视频游戏的创作现在是数十名甚至数千名程序员协作努力的结果。他们分组组织，并被分配到特定的任务中。当然，团队组织复杂性的不断增加和项目规模的巨大增长迫使游戏公司寻求利用可扩展性和分布式计算环境的开发方法。
为了更好地分配能力和精力，并加强代码和资源的可重用性，视频游戏目前通过称为游戏引擎的软件环境来实现。正如《J. Gregory, Game Engine Architecture, 2nd ed. A K Peters/CRC Press, 2014.》中主要讨论的那样，游戏引擎通常被设计架构为基于操作系统的软件库，抽象程度逐层不断提高，直到达到能够描述游戏机制的程度。
采用这种体系结构作为大型游戏的开发和执行环境可能会导致许多限制，如《D. Maggiorini, L. A. Ripamonti, and G. Cappellini, “About Game Engines and Their Future,” in Proceedings of EAI International Conference on Smart Objects and Technologies for Social Good (GOODTECHS 2015), Oct 2015, pp. 1–6.》中已经介绍的那样。总之，视频游戏可能会受到以下限制：它可能是整体的，它可能是集中的，很难向上扩展，它可能依赖于平台。尽管有上述所有限制，现代游戏引擎仍然是非常好的工具。
然而，我们有理由质疑当前的引擎是否还能支撑次时代游戏开发者对灵活性和功能性的需求。我们坚信，为了适应未来的演变，游戏引擎不仅应该瞄准更好的性能和更先进的功能，而且还应该提供更具适应性和可服务性的内部结构。因此，我们在这里提出了一个分布式游戏引擎：SMASH（用于共享环境的无堆栈微内核体系结构）。
使用SMASH，游戏引擎被分解为几个动态和独立的软件模块，通过类似微内核的消息总线相互交互。这样，一旦游戏模块的内部消息传递协议被明确定义，游戏模块就可以从正在运行的引擎中插入、调试和删除。此外，模块还可以在多台计算机上动态地移位，以实现真正分布式、可扩展和具有故障恢复能力的系统。在这种系统中，适配工作基本上可以在不停机的情况下实现。通过遵循SMASH方法，开发工作从协调编码转向协调功能，这里的协调任务，我们指的是属于主机游戏引擎的游戏模块和功能的全球组织。
本文的剩余部分如下：第二部分将介绍我们讨论的这一主题的相关工作。第三部分提供了游戏引擎的背景信息。第四部分提供了有关SMASH内部体系结构的所有详细信息。第五部分将讨论它的实现和演示应用程序。第六部分是结语，并提出之后的工作。
相关工作
在过去，相当多的科学贡献被用于实现游戏引擎的内部数据结构。然而，在撰写本文时，就我们所知，只有非常有限的论文专门讨论引擎体系结构。
大多数文献似乎集中在优化特定方面或服务上，如3D图形（例如，《T. C. S. Cheah and K. W. Ng, “A practical implementation of a 3D game engine,” in Computer Graphics, Imaging and Vision: New Trends, 2005. International Conference on, Jul 2005, pp. 351–358.》）或物理（例如，《G. Mulley, “The Construction of a Predictive Collision 2D Game Engine,” in Modelling and Simulation (EUROSIM), 2013 8th EUROSIM Congress on, Sep 2013, pp. 68–72.》，《D. Maggiorini, L. A. Ripamonti, and F. Sauro, “Unifying Rigid and Soft Bodies Representation: The Sulfur Physics Engine,” International Journal of Computer Games Technology, pp. 1–12, May 2014.》）。除此之外，《R. Darken, P. McDowell, and E. Johnson, “Projects in VR: the Delta3D open source game engine,” IEEE Computer Graphics and Applications, vol. 25, no. 3, pp. 10–12, May 2005.》(#9)、《V. Guana, E. Stroulia, and V. Nguyen, “Building a Game Engine: A Tale of Modern Model-Driven Engineering,” in Games and Software Engineering (GAS), 2015. IEEE/ACM 4th International Workshop on, 2015, pp. 15–21.》(#10)和《J. Munro, C. Boldyreff, and A. Capiluppi, “Architectural studies of games engines: The quake series,” in Games Innovations Conference, 2009. ICE-GIC 2009. International IEEE Consumer Electronics Society’s, Aug 2009, pp. 246–255.》(#11)处理了与可移植性和发展有关的问题。
其中(#9)的作者建议通过在其他现有引擎之上提供统一层来提高可移植性。事实上，他们用额外的平台无关层扩展了每个体系结构。
在(#10)中的作者重点关注了开发复杂性，并提出了一个基于现代模型驱动工程的解决方案。
而在(#11)中，对Quake引擎的开源版本进行了分析，但是目的是帮助独立开发人员为项目做出贡献。其他的一些文献中试图通过创建现有引擎的分布式实现（[12]~[14]）来提高性能。
不幸的是，所有这些方法都旨在通过将分布式系统方法应用于特定的内部服务，如模拟管道或共享内存，仅提高特定案例研究的性能。可以观察到，上面引用的论文都没有指向一个全新的体系结构。
无论如何，我们还必须提到，并不是所有现有的游戏引擎都被设计为一个库的形式。为此，我们可以提到Z-Machine [16]的Inform解释器[15]。使用Inform，文本算法描述被编译为二进制包。这个二进制包反过来由Z-Machine执行，Z-Machine是一个可用于许多平台的软件。不幸的是，Inform仅限于基于文本的游戏（如Zork [17]），而且从未向现代界面技术发展。然而，我们认为现代游戏引擎应该重新考虑Inform和Z-Machine作为一种可行的方法。【我理解是作者想让我们参考它的架构实现模式】
游戏引擎的背景
尽管游戏引擎自80年代中期以来就已经被研究和完善，但到目前为止我们还没有为它们找到一个正式的和全球公认的定义。尽管缺乏定义，但游戏引擎的功能相当明确：它的存在是为了抽象执行常见游戏相关任务（有时依赖于平台）的细节，如渲染、物理和输入管理等，以便开发人员可以专注于实现游戏特定的功能。
现代游戏引擎的标准体系结构的总结如上图（图1）所示。从图片中我们很容易看到，游戏引擎所采用的体系结构与需要分层抽象的非游戏环境中所采用的其他解决方案并没有真正的区别。
最底层是直接怼到硬件的接口。
往上走一层首先提供第三方库的包装函数和不对外公开的API供内部使用，然后在往上提供一定程度的平台无关性（统一平台抽象），最后提供与游戏相关的服务。
在与游戏相关的服务中，我们可以找到核心服务，如内存管理和IPC，以及更高层次抽象级别的库，如图形界面、物理模拟或音频子系统等等。
为了实现创作游戏的目标，游戏引擎通常分为两部分：工具套件和运行时组件。
运行时组件将硬件抽象所需的所有内部库组装在一起，并为游戏特定功能提供服务。运行时的一部分通常链接在游戏内部，或者与可执行文件一起分发。工具套件通常是外部程序的集合，可用于管理运行时的所有数据馈送并操纵运行时本身。
当前游戏引擎的潜在缺陷
正如前文中已经提到的。
第一，现代游戏引擎所采用的体系结构模型可能有三个缺点。让我们简单总结一下。
首先，现代游戏通常是一个整体软件。整体式意味着开发人员必须在每次更改时重新构建和链接整个项目。对于大型存储库，全量重建可能会成为一个重要的瓶颈。无论如何，即使在小型项目中，全量重建也需要一个干净且同步良好的源树，以及开发人员之间的良好协调，以避免构建中断。
其次，游戏功能通常是集中的：所有执行计算活动的软件都位于同一台计算机上。特别是，在线游戏客户端连接并依赖于负责数据一致性和更新系统状态的集中式游戏服务器。考虑到在线游戏的最近趋势（例如，[18]），特别是MMO（大规模多人在线游戏）和MOBA（多人在线战场）开始统治了游戏市场，在多个节点上分发工作的负载均衡能力对于游戏网络基础设施的稳定性至关重要。集中式服务通常难以向上扩展，而且在高工作负载下性能较差。在当前的实现中，游戏本身必须知道服务的位置（在同一台机器上或其他地方），并实现分布式计算。
第三，每一个游戏都暴露了一定程度的平台依赖。即使引擎声称是跨平台的，并使用其下层来适应特定于供应商的硬件，跨多个平台无缝部署也不总是可能的【参考Android和iOS不同服的体现】。这种行为取决于许多因素：一些是平台相关的扩展API，这通常引发由于特定硬件优化而导致的性能损失。如今，开发人员需要在同一引擎内编写基于底层平台的不同行为的代码。因此，引擎在技术上可能是跨平台的，但开发人员的技能和一部分代码得具有跨平台的属性。
SMASH架构
在本节中，我们将详细介绍SMASH体系结构。为了设计我们的体系结构，我们从“引擎”这个词本身获得了灵感。
正如Merriam- Webster所描述的那样，Engine是“将任何形式的能量转换为机械力和运动的机器”。那么，游戏引擎也应该只是启动游戏，而不是成为游戏的一部分。
游戏开发者应该把能量（数据资产）放在引擎中，并描述机器应该移动的方式（游戏规则），而不是每次运行时组件与游戏规则重新组合（重新链接）以获得独立软件。这种方法认为游戏引擎更接近运行时环境（例如，参见Java[19]和CLI[20]），而不是库。【我理解为：类似于操作系统和应用之间的关系，操作系统是应用的容器环境，引擎应该是游戏的容器环境】
SMASH引擎基本上是一个执行环境，提供三个基本功能：
（i）软实时调度器
（ii）动态游戏模块管理器
（iii）模块之间的消息传递系统
如上图（图2）展示了SMASH体系结构。该方案是从微内核体系结构（例如Amoeba[21]、QNX[22]）中汲取灵感而设计的，旨在解决前文中提到的当前游戏引擎的潜在缺陷。
软实时调度器负责及时调用调度函数，并确保系统以正确的速度发展。调度程序将只调用调度模块中的方法，不会参与演进。游戏模块是提供游戏功能的独立实体。模块不需要是特定于游戏的，但可以实现通用引擎服务（如图形渲染或物理模拟）。在运行时交换模块的可能性将允许开发人员使用插件方法修改和扩展游戏，直到非常细的粒度。
由此产生的游戏将不是单一的，而是由独立和可替换的模块所一同组成。新的和更改的功能可以编译为独立的实体，然后加载以在运行环境中进行测试和调试。单一模块中的编译错误不会产生整个大构建系统的中断，也因此不会阻塞非相关的开发人员的工作。
程序在运行时按需加载二进制代码的技术已经可用。所有现代语言都具有动态类加载功能；此外，动态库管理设施已经包含在主流操作系统中。从技术上讲，可以仅编译游戏项目相关的目标代码，让引擎识别它，并使用类加载器将代码拉起，以便在游戏中立即可用。
消息总线实际上是我们体系结构的核心，因为它负责实现模块之间的通信。模块之间的通信通过函数调用实现。这种方法是可行的，因为所有模块都将共享相同的执行环境，并允许实现良好的性能，因为不需要参数编组【parameters marshalling，计算机数据通讯的概念，编组与解组：把可执行的对象表示变换为适合于存储或传输的对象的表示称为编组，把已经变换为适合于存储或传输的对象的表示变换为可执行的对象表示的过程称为解组。类比于序列化和反序列化的过程】。每个软件模块将使用消息总线调用其他模块中的服务函数。
有一个事实问题是，这些函数调用将不是直接的：通用代理函数将在属于消息总线库的共享对象上调用。
调用代理函数时，调用者将指定目标模块、目标函数名称和所有参数。然后，代理将从其参数开始构建特定的函数调用。在现代语言中，反射可以轻松地以独立于体系结构的方式实现这一目标。使用代理还允许执行额外的健全性检查，并验证目标模块和函数的存在。如果没有可用的目标，代理可以安全地放弃调用。
当然，消息总线还可能不限于本地计算机。事实上，消息总线可以打开网络连接，并链接到属于远程游戏引擎的其他总线。这样，构建一个真正的分布式系统就很容易了。
为了在网络上实际分发我们的引擎，我们所要做的就是扩展消息总线的代理功能。在此扩展代理函数中，调用的目标将是目标模块和目标引擎。如果目标模块未连接到本地总线，则将执行参数编组，并将调用转换为通过网络发送的消息（一个MessagePack[23]数组）。网络消息的目标将是负责解码请求、执行（现在是本地）调用并使用应答消息将结果返回给调用者的远程消息总线。
我们体系结构的一个有趣的特点是，我们可以在不同的引擎上启动模块的多个实例。通过在网络周围复制相同的模块，我们可以通过容错实现高可用性。如果托管模块的节点出现故障，其他副本仍然是可用状态。每个消息总线都可以保留远程可用模块的列表，并在目标无响应或往返时间增加过多时切换到另一个副本模块。
到目前为止，我们描述的体系结构是非常动态的。只需调整消息总线的配置，就可以更改覆盖拓扑。每当系统过载且需要更多的可扩展性时，我们可以在新计算机上启动另一个引擎，重新定位（或复制）一些游戏模块，并将新引擎链接到现有基础架构，这些事情在这个体系结构下是很容易达成的。这样，计算负载将迁移到另一个节点上。特别的是，这样的迁移操作可以实时执行，而不会有任何停机时间。
最后，我们还必须指出与基础设施管理相关的几个问题。要实现最佳的负载平衡和对故障的反应性，非常重要的一点是要在每个节点上都有正确的拓扑信息（包括游戏模块）。为了保持寻址系统的同步，每个消息总线应立即将其可用模块中的每一个更改广播给所有连接的对等体。发送定期刷新消息也是合理的，这也可以作为托管节点的保活消息。关于对等发现，节点的地址可以在配置中硬编码（适用于互联网上的隧道），也可以使用SSDP（简单服务发现协议）[24]进行无辅助编码（尤其是在本地网络上）。
SMASH实现
在定义了体系结构之后，我们需要开始决定应该采用哪些技术和方法来实现SMASH。
选取一种语言
第一件事是选择我们的实现语言。这是一个重要的步骤，因为语言可能会决定游戏引擎的实现形式【原文中是“the level of adoption”，直译是采用水平，结合上下文我觉得应该翻译成“实现形式”】。
先如今，游戏引擎中采用最多的面向对象语言是C++，其次是Java，然后才是C#。我们的最终决定是选择C#，原因有很多。对于多平台来说，Java是一个很好的选择，但它被抛弃的主要原因是它的低性能，特别是在处理垃圾收集时。C++绝对是游戏行业中使用最多的语言，因为它的性能非常好，而且它能够访问低级硬件。UE4[25]时至今日已经被认为是游戏引擎界使用C++最重要的商业产品。但不幸的是，C++不提供反射机制，这可能会使得在消息总线中提供高效的代理功能变得困难。反射可以在用户级别添加，但性能会显著下降。此外，C++也不提供运行时类加载器。有第三方的中间件实现可以在运行时加载类，就像DCOM[26]提供的那样。但不幸的是，DCOM是微软的专有技术，对跨平台实现来说并不是个好兆头。而C#有原生的语言层面的反射和动态类加载。此外，Unity[27]引擎也采用了C#，它是目前游戏市场上的大触之一，也已经把C#运用得相当好。但是，C#也有一个渐进的学习曲线。通过CLI[20]中间语言，C#还可以与许多其他面向对象编程语言互操作。
运行时性能分析
一旦我们选好了语言，第二步是确保底层执行环境能够提供足够的性能来满足游戏应用程序的要求，即使调用是由消息总线代理中介的。使用代理函数将在本地和远程调用上引入开销。为了估计代理开销，我们通过定义一个测试函数接受两个浮点值作为参数并返回它们的总和来进行测试。该函数将被调用1000万次，最后计算平均执行时间。
主机是一台PC，配备英特尔i5-2410处理器，运行频率为2.3GHz，内存为8GB的DDR2双通道RAM，运行频率为667MHz。主机操作系统是安装了.NET 4.5.1版的64位Windows 7 SP1。测试期间没有其他应用程序运行。我们测试的基准（benchmark）是不用代理函数的直接调用。在基准下平均执行时间为7.8纳秒。
如果我们把代理添加进来，情况就变得复杂了。代理所产生的开销不仅只有执行额外调用的增加时间，还有引入执行环境的管理时间。
当软件模块在运行时加载时，执行环境将其放置在共享地址空间但具有专用访问权限的独立容器（称为域）中。跨域调用需要在操作系统和.NET中间件上进行额外的管理。因此，平均执行时间上升到211.4纳秒（是基准的27倍）。尽管事实证明开销相当大，但该系统仍然能够提供良好的用户交互。
当访问远程引擎上的游戏模块时，执行时间显然会进一步上升。为了将网络添加进来，我们使用TCP和UDP在同一主机上的两个模块之间执行调用。这样，我们就可以估计执行中间件和操作系统产生的开销。在评估中排除传输延迟是合理的，因为网络行为将不取决于软件实现。基于此，使用TCP观察到的执行时间为63.1微秒，使用UDP观察到的执行时间为56.4微秒。可以观察到，性能约为基准的10,000倍，跨域调用的370倍。就是这样，我们仍然还可以以每秒15,000次同步交互的速度运行我们的系统。
因此，性能损失是可接受的【原文为“sustainable”，直译是“可持续的”，感觉怪怪的，根据上下文我理解为应该是“可接受的”】，我们的体系结构似乎完全能够胜任任务。如前所述，只要我们使用操作系统中实现好的协议，网络引入的延迟就不取决于软件基础架构。在连接良好的数据中心中，我们可能会期望每个遍历的链路额外增加一个毫秒。当然，这将对整体表现产生明显的影响。无论如何，在数据中心中，这种传输延迟预计是相当恒定的，并限制在部分链路上。此外，我们希望从体系结构的角度来解决这个问题：识别受类似时间限制的游戏服务集，并相应地分发它们。【原文“Moreover, we are expected to address this from an architectural standpoint: identifying sets of game services distringuished by similar time constraints and distributing them accordingly.”，没有很明白这个识别的过程是什么，以及如何分发？】
原型的软件架构
最后一步，如上图（图3）中所示实现了一个SMASH原型。
正如我们在图片中看到的，有一个数字或服务类：引擎中的每个基本功能都有一个。【原文为“As we can see in the picture, there are a number or service classes: one for every basic function in the engine.”，我没有看到所谓的数字或服务类，而classes是复数，我理解是原作者打错了，应该是“ there are a number of service classes”，是of而不是or，这样理解感觉就通了，整张图中的所有类就是这些服务类】
两个主要的类是Node和Module。
Node类负责管理引擎，它实例化所有其他类并负责配置设置。鉴于其功能，Node被实现为单例类。
另外Module类是一个抽象类，开发人员必须扩展它才能创建游戏自定义模块。在这个抽象类中，已经提供了所有从引擎注册和注销的功能。
继承自Module的许多类实例可以与Node单例关联。关联通过ModulesManager类执行。ModulesManager负责加载和卸载引擎中的模块。模块的加载和卸载已使用文件系统实现。ModulesManager监视特定目录，当新包（“.dll”或“.exe”文件）添加到目录时ModulesManager将检查文件内容并加载专用域中继承Module的所有类。反之亦然，当包文件移出目录时，与其域关联的所有模块都将卸载。
连接到Node类后，我们还拥有管理其他两个基本功能的类：调度器（SchedulingManager）和消息总线（MessageBusManager）。
调度管理器类保留高分辨率计时器，并接受来自模块的调度请求。当调度到期时，调度管理器将通知将执行调用的节点单例。如前所述，模块之间的调用将通过MessageBusManager类管理的消息总线进行。当继承Module的类需要调用另一个模块中的函数时，它将使用ModuleProxy类作为代理，ModuleProxy类将请求中继到MessageBusManager，以确定被调用者是在本地还是远程模块中。根据ModuleProxy的指示，MessageBusManager将在本地或通过网络执行调用。
所有网络操作都必须经过NodeNetwork类。NodeNetwork负责管理到其他引擎的链接，发送和接收调用消息，以及接收来自其他引擎的模块更改的通知。
尤其是，输入进来的调用消息被转发到MessageBusManager进行本地传递，同时远程模块更新被中继到Node单例，以更新其数据结构。MessageBusManager将使用这些数据结构来构建远程模块的地址。另一方面，当本地模块列表发生变化时，ModulesManager将通过Node单例通知NodeNetwork，并将更新发送到所有链接的引擎。
示例程序
为了测试我们的SMASH原型，我们实现了一个益智游戏的分布式版本：魔方模拟器。
在这个游戏中，我们使用了三台PC，每一台PC都运行SMASH原型的独立副本。这三个引擎在一个网状链路中相互连接。
在第一台PC上有一个主引擎，它负责使用专用模块（RCSimulator）模拟魔方数据。
在第二台PC上，引擎包含三个模块：一个用于管理来自用户的命令的InputManager模块，一个使用ASCII来显示当前魔方状态的RCConsoleRenderer模块（见上图，图4），以及一个用于调试的RCLogger模块。
在第三台PC上，有与第二台类似的配置，但RCConsoleRenderer被RC3DRenderer取代，RC3DRenderer将用3D形式来绘制魔方（见上图，图5）。
在第二和第三台PC上【原文为“On each satellite PC”，卫星PC是个啥，根据下文理解，这些PC上要有InputManager模块，那么可以理解为是第二和第三台PC，即玩魔方的用户可以操作的PC】，InputManager模块要求引擎以固定速率调度，并轮询键盘以获取用户输入。当输入有效时，按键消息将被发送到第一台PC上的RCSimulator模块。如果请求正确，RCSimulator模块将更改表示魔方状态的数据，并将新的魔方小方块的颜色通知所有已知的渲染器。所以，第二和第三台PC上的玩家实际在玩同一个魔方。
此外，在第二台PC上，只需加载RC3DRenderer的另一个实例，就可以很容易地将视觉效果从ASCII升级到3D。这个新实例在本地引擎中注册，消息总线将把新模块的加入广播给体系结构的其余部分。从此时起，第二台PC上的新的3D渲染器也将能从主引擎中获得更新。
结论和接下来的工作
在本文中，我们对现代游戏引擎的内部结构提出了质疑，因为我们认为它不太可能提供下一代游戏开发者所需要的灵活性和功能。
作为一种可能的解决方案，我们提出了SMASH：用于共享环境的无堆栈微内核体系结构。SMASH具有完全分布式架构，灵感来自微内核操作系统。在SMASH中，游戏模块可以在引擎运行时动态添加和删除。
我们还提出了一个在windows环境下使用C#实现的原型。性能测试表明，该系统适合托管软实时应用程序，如视频游戏。
最后，我们还展示了一个演示应用程序：魔方分布式多人游戏示例。此应用程序运行良好，可以在运行时应用和更改多个渲染模块。
未来，我们计划扩展我们的原型，并在更复杂的环境中测试它，以便了解它在大规模网络上的行为。这对于实际部署广泛分布的游戏非常有用，如[28]和[29]中设想的游戏。
参考文献
这还翻？直接看原文呗。
PS: 文中的[]标识其实就是参考文献，一开始想把它直接替换到文中的（确实文章的前面也这么干了，后来发现文献都一页了，整文章里面影响美观，决定还是保留文献索引号，有需要再跳过来看，前面已经替换的就继续保留吧）。
协议
本文以上内容遵循CC BY-ND 4.0协议，署名-禁止演绎。
转载请注明出处：https://tis.ac.cn/blog/kongdeyou/smash/
并署名：kongdeyou(https://tis.ac.cn/blog/author/kongdeyou/)
