components - 将对象建模为 "collections of components"的游戏引擎在运行时如何工作？

Question

我正在编写一个轻量级游戏引擎，并且在为它做一些研究的同时，我遇到了许多令人信服的文章，它们提倡通过“组件集合”模型而不是“从具体类继承”模型来实现游戏对象。有很多优点:

可以使用数据组合对象
驱动设计技术，允许
设计师想出新的
对象不涉及
程序员;

源文件往往较少
依赖，允许代码
编译速度更快；

发动机整体变得更加
一般的;

不得不做的不可预见的后果
改变具体的类(class)
继承层次可以是
避免；

等等。

但是系统的某些部分仍然不透明。其中主要是同一对象的组件如何相互通信。例如，假设在游戏中模拟子弹的对象是根据以下组件实现的:

视觉上的一些几何图形
代表

世界排名

用于碰撞的体积
其他对象

其他

在渲染时，几何图形必须知道它在世界中的位置才能正确显示，但它如何在对象中的所有兄弟组件中找到该位置？在更新时，碰撞体积如何找到物体在世界中的位置，以测试它与其他物体的交集？

我想我的问题可以归结为:好的，我们有由许多组件组成的对象，每个组件都实现了一些功能。这在运行时工作的最佳方式是什么？

Answer 1

可组合架构通常依赖于接口(interface)。组件然后是实现+数据，使设计人员能够重新使用具有不同数据的可用实现。例如使用火箭代码一次与火箭图形，一次与箭头图形。灵 active 来自于能够在实际运行时之外“配置”这样的组合。

在运行时，对象通过接口(interface)接收和提供必要的信息。例如，一个对象将接收一个原点和一个引用方向来定位自己在世界中。对于实际绘制的东西，我假设将传递一种图形上下文，并且基础设施负责为当前对象适本地对齐默认偏移/投影。