Engine Architecture（引擎架构）

在实际应用中，我们可以有不同方法来设定游戏架构，您能选择引擎与游戏逻辑融合的一体化解决方案，也能使用数量众多的独立模块，让它们中的每一个都来负责一部分功能。 Unigine引擎正是结合了这两种方式的优点，将针对游戏或3D应用的实现所需的全部要素（应用逻辑，网络连接和AI除外）都囊括其中。 Unigine只包含了典型的游戏逻辑以及各种常见类型的应用，并且这样的设计还是有意为之。

做或许算不得有什么优势：为了开发游戏，人们不仅需要进行大量的程序设计，还要靠自己来实现在主要类别的游戏中被广泛使用的那些常用功能。 不过话又说回来，没有特殊类别的游戏逻辑也不见得是坏事，因为这让Unigine引擎成为了能在不同项目中被轻松重复使用的多用途程序库。 而且，如果开发者的开发不被限定为某种特殊类别的话，他们就可以同时尝试多种类别，但假如引擎是被用作特殊用途的话，那要想这么做是极其困难的；例如，您要将专为第一人称射击游戏创建的引擎用来制作结合了射击和竞速的混合游戏，这种实施难度可想而知。 此外，Unigine也允许加载外部模块，这些模块拥有特殊类别功能，也可以被重复使用。 以上种种使得Unigine为我们构建多种多样的3D应用提供了十分灵活的基础。

能够理解Unigine引擎的架构，对开发者和内容创建者而言都至关重要。 前者通过对它的了解能知晓引擎的编程原理，可以实现的功能，以及Unigine所能提供的实现途径。 而后者通过对引擎架构的了解则能知晓自己所创建的内容将会被如何处理。 这也是为什么本文给出了一段虽简短但却很深入的有关Unigine引擎工作流介绍的原因。

下图展示了Unigine引擎的内部组件与不同的外部实体（Entities）间的相互关系。

当自定义的Application Logic（应用逻辑）调用Unigine的API功能时，引擎的运行机制便启动了。 这些调用可由UnigineScript或C/C++直接完成。 前者是一种更为可取的方法，因为使用它程序员就无需考虑多线程和内存管理的问题。 此外，如果应用由UnigineScript编写，那它将能在Unigine引擎支持的每一种平台上运行。 如果应用逻辑有特殊需求，API组件也能加载可扩展Unigine功能的Modules（模块）。 这类模块可以包含有像第三方中间件。

API的调用会被传给Interpreter（解释器），它将初始化必要资源：注册扩展，加载核心数据，配置文件，脚本以及用户界面文件。 由于所有这些资源都使用特殊的数据目录来组织，而且还能被打包，因此它们可以通过File System（文件系统）组件来加载。 另外，文件系统组件也可以跟踪文件的字节序标记（BOM）。 请注意，如果您是在初始化完成后将文件添加到该目录的，那就需要重新加载文件系统组件。

待初始化完成后，World Manager（世界管理器）开始接手接下来的工作。 它会加载构建当前场景所需的必要文件，并确定可视节点集合，这些节点过后要被发往Render（渲染）组件。 世界管理器也会告知Sound（音效）组件何时以及如何播放环境声音；这些音效源被放置在虚拟世界中的某些地方并且它们还具备空间属性。 当然，世界管理器也会与Physics（物理）组件协作，一起来执行物理计算（碰撞检测，连接器求解，流体浮力计算等等），当然，也可能更新节点层级。 简而言之，世界管理器本身不负责绘制对象，播放音效或执行物理计算。 它反而会将这些任务委派给指定的组件来执行。

Render（渲染）组件和Sound（音效）组件需要作用于附加资源才能完成它们各自的任务：前者需要纹理，网格和动画，后者需要声音文件。 因此，它们会让Resource Manager（资源管理器）来为其提供所需资源。 资源管理器的任务是加载必要图形和声音，以及缓存它们；如果不再需要这些资源，它还要负责卸载它们。 提供资源管理器的目的就是为了让游戏开发者无需考虑如何以及何时应该加载和卸载数据。

由于应用逻辑会下指令给Interpreter（解释器），因此如有所需，解释器也可以调用GUI组件，让其通过Render（渲染）组件来绘制用户界面。 不过，在Unigine引擎中，GUI对象不仅能独立运行，它们还可以成为被显示的虚拟世界的一部分。 这种情况下，世界管理器就会像管理其它节点那样来管理它们。

当被渲染的图像中可能包含有要呈现给用户的GUI时，它们当然也可启动与虚拟世界的交互。 用户可以借助各种输入设备来作用于虚拟世界。 来自这些设备的输入信息被发往GUI组件以及Controls（控制）组件。 GUI组件被用来处理输入信息，检测被点击元素并执行相应的回调函数。 Controls（控制）组件则负责处理那些与GUI不相关的输入信息，例如，游戏中玩家的动作。 注意，由于GUI组件总是先于Controls（控制）组件获取输入数据，它也因此拥有更高的优先级。

经处理的输入数据会被传给Interpreter（解释器），它要检测是否有用户动作作用于渲染或物理设置等等。 如果有，解释器会让相应的组件来更新画面或计算。 如果用户的输入改变了虚拟世界中的某些参量，世界管理器便会更新可视节点集合，并将新请求发送给指定的组件。

这些动作会在循环中重复执行，直到用户退出应用为止。