Delta3D 引擎 框架 结构分析

在上层设计中，Delta3d引擎 设计非常简单，只包含了三个主要部分。最中间是“GameManager”，主要负责管理角色Actors和消息分发。GameManager是Actor和Component两子系统通信的管道。

引擎中的第二个子系统是GameActors。GameActors是仿真环境中的实体，进一步又可以分为两个小部分：代理Proxy和角色Actor。actor是实体对象， actor只包含很少一部分内部分内部逻辑，也可以通过actorcomponent添加一些额外功能逻辑。proxy的存在可以透明地访问网络，并为GameManager和其他工具tools（如STAGE）提供了一个通用的访问数据的接口。

引擎中的第三个子系统是“Component”。Component接收消息，并针对这些消息做出相应的逻辑。例如可以执行发送网络数据、更新player的分数等。

Actors是仿真环境中的实体，actors和proxy可以通过继承关系获得相应的功能。在创建一个实体时（最终的创建必须通过ActorPluginRegistry或LibraryManager创建的 参见http://blog.csdn.net/zhuyingqingfen/article/details/19497497），必须创建两个对象，一个是actor本身，另一个是proxy。proxy存储了一个actor希望暴露给外边的属性。这样其他的工具tools（如STAGE）就可以通过proxy获取actor的属性，并对其进行操作。

Component子系统含有消息处理功能，提供了一个很强大又很灵活的方式来向Game Engine中添加新的功能。在上面可以看到一些Delta3D内置的component。例如一个BaseInputComponent提供了处理鼠标键盘点击的能力，游戏开发者可以扩展这个组件来添加一些类似“点击空格键进行射击“的功能。

一个component 只用来监听消息，然后针对消息执行相应的逻辑。游戏开发者可以通过component的方式来实现一些如”游戏规则“，”网络数据收发“等。组件时应用程序添加新的功能变得非常简单。

性能：对于Actors，由于其的多继承原因，并没有太好的办法来充分分离功actor的能函数来利用多核CPU计算。而对于Component ，将很容易充分利用多核CPU的功能，就目前来看，components之间还没有太大相互之间的依赖关系（降低充分利用CPU的能力），不过有一些是必须依赖的如你在执行”Networking Component“之前要先执行”Rules component“组件。

可修改性：component的设计使得Delta3D的可修改性大大提高，例如如果你不喜欢内置的network component ，你完全可以写一个你自己的network component ，而不用修改太多引擎本身。但由于actors的渲染和物理功能是通过继承实现，这就意味着如果你想移除渲染的OSG或者物理引擎 ODE，或者扩展这些功能，那么你必须付出很大的代价了。

可移植性：Delta3D所依赖的第三方库都是跨平台的，可以在window、Linux上 运行，在mac 上目前还没有得到官方的回应。

可重用性：component的可重用性在基于Delta3d的工程中很容易（可以直接把一个工程中的component 用到另一个工程中），而actor是在继承关系上是可重用的。

开发周期：这个对Delta3d来说是非常好的因为它内部已经包含了相当大的一部分功能。开发者只要要开发自己的actor实体，提供相应的component即可，所以利用Delta3d开发项目可以大大提高效率。

概念的完整性：这个是Delta3d不太好的地方。引擎有着很简单的概念，但又提供了一个混合的消息来扩展引擎功能。例如，如何为我的游戏人物中添加AI功能？如何为我的actor对象添加新的渲染和物理功能？像网络和规则都是用”components“来实现。我个人认为，他们应该把功能从从actors的继承关系中分离开来，全都用component的方式实现。Unfortunately, I am not emperor of the world – so no one asked me ☺.