c++ - 重构:让游戏引擎更加模块化以及如何重构

Question

我的游戏引擎由一系列松散耦合的模块组成，可以加载和卸载。

一些示例是:基本模块、处理窗口管理和响应操作系统事件、实体管理器、Lua 管理器、物理管理器。

现在，这些模块被组织为命名空间，它们的状态通过各自源文件中的局部变量定义。每个命名空间都有一个 Open()、Close() 和 Update() 函数。

现在，我真的不再喜欢使用命名空间 的解决方案了。

• 不够灵活

• 即使在现实中可能不需要它，但具有创建模块的多个实例的简单能力似乎是合适的

• 看来我在这里没有使用 OOP - 具有虚拟 Update() 成员函数的模块基类听起来更合理

• 很难确保当模块关闭并重新打开时，所有变量也将被重置(具有构造函数和析构函数的类会更容易)

• 如果不显式调用 Open()、Close() 和 Update()，您就无法正确管理模块

因此，我的想法是为每个模块使用类，派生自模块基类。模块类实例将由更新它们的 ModuleManager 类处理。

但是 OOP 的解决方案带来了模块应该如何通信的问题。现在，基本模块告诉控制台模块通过 console::print()

打印一些东西

• 如何在不使用类似 g_ModuleManager.GetConsoleModule()->print() 的情况下解决这个问题？

• 这个模块管理器如何详细工作？

我的最后一个问题:

• 关于使用 OOP 在 C++ 中编写模块化游戏引擎的主题，您对我有任何进一步的提示吗？

• 在这种情况下是否有任何设计模式可以帮助我，甚至是具体的阅读 Material ？

Answer 1

命名空间很快就会变得非常不灵活。
保持松散耦合的一种方法是通过中央消息调度程序使用消息传递；与其说console::print，不如说messenger->sendMessage(PRINT_MESSAGE, stuffToPrint)。
控制台会将自己注册为 PRINT_MESSAGE 的监听器，并按照它想要的方式运行。发件人不需要关心是否有人在收听，甚至每条消息可能有多个收听者(对调试有用)。

关于阅读 Material ，Jason Gregory 的 "Game Engine Architecture"还不错，讨论了几种架构的优缺点。