Siney's BLOG

今天要说的是游戏里的ui, 说到ui, 我的经验是最丰富的, 之前进入网易先开始搞的就是梦幻西游的ui, 是一个图文混排的控件, 可以理解为richview, 允许表情包子和颜色文字混排, 实现聊天记录的实现和编辑. 后来搞天下贰也完整的实现一套3d游戏环境下的ui系统.

按理说ui系统是游戏开发过程中一小部分工作, 但它却贯穿了整个游戏开发的全过程, 直到我离开天下贰项目组, 都还在不断的根据需求修改ui引擎实现新的功能, 可以说整整搞了5年的ui, 所以到我们自己出来创业搞xero引擎, 我一点都不想再搞ui系统了. 所以ui说是小系统, 但却实实在在是一个大问题. 写这篇blog的缘由是上周去参加bigworld开发者大会, 其间与w公司一个技术人员讨论ui实现, bigworld可是说提供了完善丰富的3d引擎基础功能, 但ui系统这块欠奉, 或者不尽如人意, 据我所知, 所有购买bigworld的国内公司, 都需要重新独立研发一套的新的ui系统, 这里需要考虑的问题如下:

1) 功能完整

2) 性能

3) 脚本封装

今天我只说下功能完整性这个问题, 到底什么样的功能才算完整的, 很多初次实现ui系统的同学会类比windows mfc或者vcl等ui框架, 把各种功能的控件, 控件的操作方法都实现到ui系统里, 这样来体现ui系统的强大. 我个人不以为然, 至少在游戏ui系统中, 只要实现几种基础控件, 就能满足游戏里大部分需求. 比如ListView和TreeView这样的控件, 到底有没有必要在ui引擎中提供(注意这里是说的ui引擎级别, 不是应用层面, 从应用层面肯定需要这个控件), 我个人认为没有必要, 但我听很多童鞋抱怨过treeview控件又加入新的需求了--- 要在每个treeitem后面加入一个图标, 因为在标准windows控件里没有这个需求, 一般都是前面有个图标, 后面一个文字, 所以很多ui系统的实现者都会想当然的按照windows的习惯来实现这个treeview控件.

ui实现最重要的原则是抽象, 而不是具象, 以上面的treeview为例, 更抽象的实现是只实现:

Image显示图片(支持动态图片)

Label显示文字

Panel控件容器, 可以作为View, 可以支持裁剪.

剩下的工作就是在脚本应用层面:

使用Panel作为TreeItemView, 根据鼠标操作动态的layout treeview控件, 如果在panel中放入[Label], 那它就是一个基本的文字treeview, 如果放入[图片-Label-图片]就是上面需要的TreeViewItemEx, 将整个TreeViewItem layout进入一个新的panel, 就得到了一个支持裁剪的TreeViewEx控件. 一般这里使用Adapter模式来做TreeView和TreeViewItem的适配, 同时做到数据和view的分离.

关于允许拖动改变窗口的大小

这个问题是我同w公司的同学争论最多的一个问题, 这是一个功能完整性的问题. 他的意思是要支持这个功能, 或者说提供SetSize这样的功能, 于此同时要支持其中的子控件自动relayout, 这里说的不是Windows窗口改变大小后, 如何适应尺寸变化的问题, 我的意思是这是过度设计, 或者是windows想法的照搬. 更重要的是, 他们w公司要因为这个需求重新设计推翻之前的ui系统重新实现,而推动这次ui重构的根本原因, 在于策划早期ui需求的多变不确定性, 需要不断尝试不同大小, 不同布局的ui表现, 所以又是策划一句话,程序跑断腿, 当然这是一个理念和需求问题, 而不是对错的问题. 争论了半天也没有结论, 各执一词.

从理念角度讲, 如果你的ui系统是为了更通用, 能够独立服务更多游戏ui需求, 他的意思是无可厚非的, 但其实大部分游戏的大部分ui表现没有这个需求, 在游戏中大概99%的ui都是一张复杂的底图, 都是只有固定大小, 不需要改变尺寸, 不需要重排, 基本上只要策划需求确定, 美术表现确定, 就是一次编码一次layout就搞定的问题, 不存在动态调整的问题. 当然也有例外, 比如聊天记录框, 为了让用户看到更多的历史记录, 需要根据用户喜好调整合适View尺寸, 一般这种窗口的实现都是9-patch平铺来实现,有这个需求, 实现一个9-patch的Panel控件就解决问题了, 真的需要到重新实现ui系统花费5个月时间吗?

关于ScaleForm

这是个好东西,特别是4.0后,这个ui实现变的更快了,星际二也用它作为ui系统,我之前的博客还写过这个东西, 还自己实现了一个类似的SFlash的替代方案, 它唯一的问题是会flash, 懂得ui, 懂点程序, 懂点游戏逻辑的人太难找, 简单说就是使用门槛太高, 直接导致人力成本提升.