是否有现有的基于FOSS组件的框架？[关闭]

基于组件的游戏编程范例正变得越来越流行。我想知道，有没有提供可重用组件框架的项目？用任何语言，我想我都不在乎。不是为了我自己的项目，我只是很好奇。

具体来说，我的意思是说有一些项目包括一个基Entity类，一个基Component类，也许还有一些标准组件？如果您不想重新发明方向盘，或者想要GraphicsComponent使用Direct3D制作sprite 的游戏，那么开始游戏会容易得多，但是您认为它已经完成了十几次。

快速谷歌搜索出现了鲁舍尔。有人听说过吗/有人使用过吗？如果没有受欢迎的，那为什么不呢？使这种可重用的东西太难了，并且他们需要大量的自定义吗？在我自己的实现中，我发现很多样板都可以推入框架中。

如果没有受欢迎的，那为什么不呢？

因为在这种框架的运作方式上没有什么像共识。

在Gamedev.net上的一个线程上，我确定，当人们谈论基于组件的游戏系统时，基于3个不同的因素，实际上至少有8种可能的排列方式来期望它们的工作方式：

内侧还是外侧 -组件应该聚合到一个实体中，还是应该是子系统的一部分，并且仅由实体ID关联？

静态与动态合成 -实体应该由一组已知的组件（例如1个物理，1个动画，1个AI等）组成，这些组件可以通过众所周知的接口以代码形式进行通信，或者实体可以添加任意数量的组件它们（以及用于定位其他感兴趣组件的相关策略）

组件上的数据与实体上的数据 -数据应该由主要在其上运行的组件保存吗？还是应该将数据存储在实体中的所有组件都可以访问的共享空间中？

除了组件如何通信（通过共享数据？通过函数指针？通过信号/插槽？或者根本不？）以外，还有其他问题，它们应该如何更新（基于组件类型以固定顺序进行？ -在创建时定义的实体顺序？基于组件相互依赖关系的拓扑排序？）等。

这些选择中的每一个都是完全任意的，用一个系统可以做的任何事情都可以用另一个系统做。但是在每种情况下，您编码的方式都非常不同。人们似乎对哪种方法最适合他们有强烈的意见。

现在，人们仍然对组件不能以某种方式替代面向对象（不是）（而不是面向对象）的想法感到困惑，并且还认为它们与传统的游戏制作方式相比是一个巨大的改变（同样，它们不是-人们已经将实体中的各个子系统排除在外了很长一段时间），因此存在很多夸张而不是太多的共识。也许几年后一切都会安定下来，人们会选择一种或两种相当标准的方法。

有一个Wiki收集了所有这些示例：

http://entity-systems.wikidot.com/

...以及不同方法之间的差异的解释。

检查我发现与该架构有关的这些框架...

www.burgerengine.com

按钮引擎

Arthemis框架-https: //github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis

看看Unity Api。您可以找到许多有关基于组件的体系结构的内容。（一旦找到更多信息，便会更新列表...）

更新：

      https://code.google.com/p/spartanframework/

这很好地解释了有关实体系统的信息 。http://piemaster.net/2011/07/entity-component-primer/

有用于Flash的按钮引擎：http : //pushbuttonengine.com/

还有用于c ++ / python的Panda3D：panda3d dot com（对不起，我只允许每个帖子以n00b的形式发送1个网址）

我敢肯定那里还有更多吨:)