基于Unigine引擎构建的应用的典型架构

不管您的应用属于什么种类或类别，其架构都是无比重要的，因为您对它所作的决策将会直接影响到整个项目的实施。 因为我们收到的很多问题都是有关这一话题的，遂在这里给出一些指导。

请注意，本文讨论的内容不涉及引擎的内部构成，纵使您购买了含有源代码的版本，修改Unigine底层也属下下策，否则的话您极有可能会破坏引擎的完整性。

Unigine引擎提供有大量特性，也支持各种硬件，尽管如此，这也肯定不足以支撑您的项目：游戏也好，虚拟现实应用也罢，情况都一样。 摆在您面前的最基本任务是添加应用/游戏逻辑，但不光如此，您肯定也需要做其它工作，像添加对不常见硬件的支持等。 每当您进行这样的工作，并确实需要编写扩展来实现的时候，不重复Unigine引擎已实现的功能以及选用正确的实施工具都至关重要。

为了避免功能的重复，请您彻查自己的目标是否可借助Unigine引擎独立完成。 有关实现扩展所需实施工具的选用原则会需要较长篇幅的讲解，内容如下。

Unigine引擎的扩展根据所用界面的不同可以被分成三类：

• C++ API （使用C++来编写组件）
• Material system（材质系统） （使用GLSL/HLSL语言来编写着色器）
• Interpreter（解释器） （使用UnigineScript来编写脚本）

那么，该如何从这些界面中选择合适的那个呢？ 告诉大家，这里有几个选用规则。 当然，除了这几个也【或许】还有例外情况，不过那都是十分罕见的，也是有争议的。

• Material system（材质系统）。 当您需要使用某种特殊的渲染方式时就需要编写自定义的着色器。 不过在动手之前，还请先检查是否同样的效果可由现成的Unigine材质来实现。
• Interpreter。 得益于UnigineScript的语言特性以及Unigine库所提供的功能，脚本处理不仅能，而且也应该被用在System（系统）脚本（应用的启动和关停），World（世界）脚本（主游戏逻辑和状态），AI（状态，简单决策）以及GUI的执行中。 您可不要低估UnigineScript的作用，它是专为减轻开发者的工作负荷而研发的；即便是很初级的开发者也都能很快使用它来编写脚本。 有关UnigineScript的语言特性及其解释器特性的完整列表可在UnigineScript一章中查看。
• C++ API。 C++组件应被用于与硬件的交互，网络连接，巨型通用模块代码以及像寻路这样的复杂决策。 此外，如果您想使用第三方库，则可用C++封装器将那些库提供的功能导入到UnigineScript。 您应避免使用C++编写游戏逻辑， 这样做不仅不方便，还容易出错，同时也可能导致您开发的应用只能局限在某一系统平台。

我们举个小例子来更具体地说明上述选用原则。 比如说，您想为专用外设开发一款名为“法杖”的电子游戏，该外设会与游戏一同推出。 同时，您还想使用第三方AI库为玩家的敌人注入生命。 接下来您要做如下事情：

1. 使用C++实现对外设的支持，将必要的功能导入到UnigineScript。
2. 将所需的AI库功能导入到UnigineScript。
3. 使用UnigineScript编写主逻辑。 游戏状态，玩家状态和敌人的状态都会以脚本形式来存储和更新。