能够像生产汽车那样,将各个部件组装起来就能造出一辆汽车,在软件开发领域一直是个梦想。组件开发思想的出现,让我们离这个梦想更近了一步。组件,意味着高内聚、高复用,我们只需了解其外部接口规格,就能使用其功能,无需知道其内部如何实现及运作。
在游戏开发中,UI管理是一个比较麻烦的问题,特别是针对那种需要根据不同场景切换不同UI的游戏,UI的组织和管理尤显重要,能不能像将各个UI(比如:聊天窗口、系统界面)作为一系列的组件来管理呢?下面是笔者在实际开发中采用的一种方案:
根据UI组件的一般划分粒度,将所有UIObject对象在GUISystem初始化时全部生成并放入_uiMap,是合理的,因为这里还没有对每个 UIObject调用InitUI,只是简单的new,完成这些只需要极少时间。LoadCurUI能够让我们只需传入一个场景id号,就可以载入对应的 UI,为了灵活方便,可以将场景id与其对应的UI组件名放在配置文件中。
所有UI组件都必须从UIObject继承而来,其中包含了一个指向具体实现窗口功能的Window对象的指针。这样一个UI类就相当于一个 Window的Wrapper类,以便GUISystem统一管理。对于UI组件之间的交互,通过GUISystem作为中间层,彼此解除了较强的耦合。
在下一篇文章中,我将介绍如何利用CEGUI+Lua实现这种设计方案。
在游戏开发中,UI管理是一个比较麻烦的问题,特别是针对那种需要根据不同场景切换不同UI的游戏,UI的组织和管理尤显重要,能不能像将各个UI(比如:聊天窗口、系统界面)作为一系列的组件来管理呢?下面是笔者在实际开发中采用的一种方案:
根据UI组件的一般划分粒度,将所有UIObject对象在GUISystem初始化时全部生成并放入_uiMap,是合理的,因为这里还没有对每个 UIObject调用InitUI,只是简单的new,完成这些只需要极少时间。LoadCurUI能够让我们只需传入一个场景id号,就可以载入对应的 UI,为了灵活方便,可以将场景id与其对应的UI组件名放在配置文件中。
所有UI组件都必须从UIObject继承而来,其中包含了一个指向具体实现窗口功能的Window对象的指针。这样一个UI类就相当于一个 Window的Wrapper类,以便GUISystem统一管理。对于UI组件之间的交互,通过GUISystem作为中间层,彼此解除了较强的耦合。
在下一篇文章中,我将介绍如何利用CEGUI+Lua实现这种设计方案。