我的游戏引擎由一系列松散耦合的模块组成,可以加载和卸载.
一些示例是：基本模块,处理窗口管理和响应OS事件,实体管理器,Lua管理器,物理管理器.
现在,这些模块被组织为命名空间,它们的状态通过各自源文件中的局部变量来定义.每个命名空间都有一个Open(),Close()和Update()函数.
>它不够灵活
>即使实际上可能不需要它,但是具有创建模块的多个实例的简单能力似乎是正确的
>好像我没有在这里使用OOP – 具有虚拟Update()成员函数的模块基类听起来更合理
>确保当模块关闭并重新打开时,所有变量也将被重置(具有构造函数和析构函数的类将更容易)
>如果没有显式调用Open(),Close()和Update(),就无法正确管理模块
所以,我的想法是使用从模块基类派生的每个模块的类.模块类实例将由ModuleManager类处理,后者会更新它们.
但是OOP的解决方案带来了模块应该如何通信的问题.现在,基础模块告诉控制台模块通过console :: print()打印一些东西
>如何解决这个问题,而不必使用像g_ModuleManager.GetConsoleModule() – > print()这样的东西？
>这个模块管理器怎么能详细工作？
我的最后一个问题是：
>对于使用OOP在C语言中编写模块化游戏引擎的主题,您对我有任何进一步的提示吗？
>在这种情况下,是否有任何设计模式可以帮助我,甚至可能是具体的阅读材料？
解决方法
命名空间变得非常不灵活.
保持松散耦合的一种方法是通过中央消息调度程序使用消息传递;而不是说控制台::打印你会说messenger-> sendMessage(PRINT_MESSAGE,stuffToPrint).
控制台会将自己注册为PRINT_MESSAGEs的监听器,并以其想要的方式运行.发送者不需要关心某人是否在监听,每个消息甚至可能有多个监听器(对调试很有用).
保持松散耦合的一种方法是通过中央消息调度程序使用消息传递;而不是说控制台::打印你会说messenger-> sendMessage(PRINT_MESSAGE,stuffToPrint).
控制台会将自己注册为PRINT_MESSAGEs的监听器,并以其想要的方式运行.发送者不需要关心某人是否在监听,每个消息甚至可能有多个监听器(对调试很有用).
关于阅读材料,Jason Gregory的“Game Engine Architecture”非常好,讨论了几种架构的优缺点.
