今天，我读到了 FRP（函数响应式编程）。但是，我不知道这在引擎本身中有多少适合。
阅读Gerold Meisinger 的文章后，我的问题是，是否值得使用 FRP 而不是基于组件的架构。这是游戏引擎架构设计的近期未来吗？这只是解决基于组件的架构的小问题的简单方法吗？我将不胜感激任何文章，解释，个人意见等。
想想商业游戏的引擎，特别是射击游戏或赛车类型（3D 游戏）。不要考虑 2D 平台游戏或其他更简单（谈论引擎复杂性）的平台游戏。我会使用 C/C++（我注意到使用 FRP 的人依赖于 Haskell，因为它的性质。但是，我看到了这个文档并且更喜欢站在 C++ 上，作为“行业标准”）。
C++ 自然不适合 FRP；您使用的任何库（Boost.Phoenix是一个不错的库）都会带来一些您很可能不想在商业 3D 游戏中处理的开销。
不仅如此，FRP 还不是一种非常完善的游戏技术，即使在 Haskell 中也不是，afaik；你想制作游戏还是想开发制作游戏的技术？
基于组件的实体系统已经存在了很长一段时间，并且是一个经过验证的概念。它们确实有其局限性，最值得注意的是，组件如何相互通信？— 一种解决方案是拥有两种类型的组件、属性和行为；后者可以访问任何属性，但它们不能相互访问。
如果您想制作游戏，请选择 CBS。如果你想帮助开发游戏中的 FRP，那就去做吧。
顺便说一句，你说 2D 游戏有简单的引擎是非常错误的。:)
2014 更新
此后出现了一种新语言，它广泛使用了函数式反应技术，并针对 Web 开发，称为Elm。它与 Haskell 非常相似，并且由Prezi和 afaik 提供支持。语言设计师有一个很好的演示文稿，他在其中使用 FRP 制作了一个小游戏。任何对如何处理 FRP 感兴趣的人都可能想观看该视频。
简短的回答：可能都没有！
但是，我不知道这在引擎本身中有多少适合。
我不明白你的意思，但每一个涉及时间（即使用update( float elapsedTime )）的代码通常都适合 FRP - 在理论上。关于“适合引擎”，也许HaskellWiki Yampa - Game Engine有助于回答您的问题（我的论文的精简和英文翻译版本，它解释了整体架构）。从关于 FRP 的讨论和阅读一些 FRP 论文来看，整体理论概念似乎仍有一些未解决的问题，因此我建议在商业项目中使用任何 FRP 库之前进行一些彻底的测试（尤其是性能和内存问题）。看看Frag 视频。这是一个用 FRP 编写的射击游戏，也是当今最先进的例子。
想想商业游戏的引擎，特别是射击游戏或赛车类型（3D 游戏）。
嗯，你的重点是什么？你在开发商业游戏吗？然后使用现有的引擎，不用担心！你在开发引擎吗？那么 FRP 可能是一个有趣的概念。对于射击游戏和赛车游戏来说，使用组件来改变游戏对象不是必需的，因为它们只使用很少的不同游戏对象，并且过多地关注架构可能会过度设计。没有重点？获得焦点！您无法自己开发下一个 IdTech 引擎和下一个 Doom 游戏。
我看到了这个文档，更喜欢站在 C++ 上，作为“行业标准”
也有一些 C++ 库。搜索“反应式或时间编程”。