【转】基于gamebryo引擎开发过程中组件的应用和取舍 By 宋晓宇

（文中有些地方采用了拟人的手法，和组件开发公司都没有关系，别误会）

宋晓宇 2009.10
又是做游戏，而所谓的做游戏在我这里就是客户端表现，就是客户端强大的扩展能力和足够的稳定性。每个人经过一段时间的开发都会沉淀出一些东西，做些其他的事情，然后再去开发就
思索到了更多的东西，今天实在太想说下这个感受，最后起了个这么论文标题的名字。要是还是研究生阶段指不定我又投到那个会议上去发表下了。呵呵，过来了就算了。
gamebryo，speedTree，scaleForm，umbra，beast，fmod，lua。总共7个组件，gamebryo（以下简称gb）就是一个性价比较高的引擎了，其实主要是适合国内游戏开发的国情，我们国内有程序员，有美术，我们还不是傻瓜式的开发，gb简直太合适了。当然gb3.0后的lightspeed不在讨论范围内。于是在选定这个游戏引擎后会开发游戏层次及其相关需要的各种东西，有时候为了提高效率或者提高效果也要买东西。于是应用而生的speedTree，scaleForm，umbra，beast，fmod，lua就这样出现了必要的中间接口叫做NiSpeedTree,NiScaleForm,NiUmbra,NiBeast,而fmod我们必须把他的游戏接口专业化到我们的程序中去,我们制作了NiSoundFmod,lua则用了第三方的第三方叫ToLua++把我们的逻辑组件全部变为lua组件.至此,接口问题算解决了.
介绍下功能,可能功能介绍完后就发现接口白写了或者有些地方需要返工了,呵呵.假如游戏中出现了大量的森林场景,那么就需要绘制大量的树,首先我们要相信我们的美术制作树的3dMax能
力,可以制作一个树用2000个以下的面片,而且能精确到树枝公告板级别的数量上,但是看到密密麻麻的树叶的时候我们要制作平滑的Lod提高效率可能要花一阵子,干脆用speedTree算了,省了人
力,但降低了风险,谁知道找到一个什么样子的游戏程序负责这部分工作哪,狠狠心,买了!买回来没几天可能就哭了。游戏UI当然要做，当然我们也不想从头开发，开发一个完整UI起码得半年以
上吧，要不然拿CEGUI好了，挺方便的，就是可能美术说这个东西不好用，要是用flash做UI多动感，而且我还能做特效，做个圆形按钮，五角星按钮，做个鼠标跟随，做个飞动的字幕菜单等等
，于是我们还是听美术的吧，这个东西一老永逸嘛，可这年头找个做游戏的flash程序员太难了，那些个猎头一天天的狂打电话找哪，他们肯定比你找的快，找到了也轮不到，轮到了价格也高
，而且指不定做出来是啥样子的，算了，我们scalform提供了完整的flash制作UI的解决方案，不如买回来用吧，你能想到的flash都能做，flash能做到的，as2语言写的都能放到游戏里去。一
狠心，也买了!买回来高兴几天也得难受。这么颠覆思想的东西也不是谁都能用的了的。umbra和beast就不多说了，小组件，不买就得自己写代码，而且那代码我感觉写好了拿到国际图形学大
会也能发表，有点技术含量的东西，一个专做遮挡剔除一个专门做lightmap，而这两部分也算是3d实时图形中表现效率和展示效果的一个重点。但是这个东西我觉得不用也行，而且beast我感
觉肯定会有被淘汰的一天的，而且就这几年应该就不见了，实时的东西才是今后发展的重点，特别是游戏。声音组件当然也能用directSound代替，只是那样就需要自己去混声，自己做3d音效
了。麻烦，而且主要fmod本身便宜，懒惯了，就买了。脚本大家看到魔兽世界都用的lua，我们也当然要跟风用lua了，tolua++还这么好用。
看样子构成我们游戏的东西齐了，只要美术去做模型出来，画UI出来，动作师拿动作来，客户端把任务，商铺，换装，个人属性，既能，战斗，组队等等逻辑显示出来，然后那个服务器的
gs就去计算吧，我才不管你怎么算的。这个时候发现很多技术难题没解决，物理怎么弄，算了，买phyX回来好了，行，反正买了那么多了也不差这一个了，然后突然感觉市面的游戏场景怎么跑
也不到头的，要地图分块了，算了，引入多线程，引入无缝服务器，服务器的问题搞不定的话那可和我们客户端没关系啊，我们地图boost的线程管理加载的，不怕。又发现特效上占据了大量
的资源，没有重用，不怕，魔兽世界都8G多了，我们这个算啥，声音资源也狂大，不管，有魔兽世界的借口所有的容量问题都好说。
单说上面说的组件吧，speedTree那个东西真不错，真的，打心里觉得这个东西作出来的树就是漂亮，可是和gb结合的时候，完全不考虑gb的感受，属于个人主义太强的一个人，自己去管
理，自己去绘制，只用了gb的照相机，还好gb现在都是桢渲染技术，要不然好多组件都用不了。一个团队好像领导都喜欢听话的，自己管得了的人，这个不听话，无奈啊。sclaeform听话，自
己成立了一个管理团队，用来管理自己的东西，然后被gb一下子收购过来就行，只能怪speedTree本来就是团队里的人还想成立团队，真难受。umbra好，作为一个低层领导，可以把低层管理的
十分有序，gb这类领导喜欢这类人，但是有他没他不影响大局，无非就是没他了领导忙些，对外办事可能不积极，但是这类人还是在团队里的好。beast其实是一个让领导很为难的角色，他在
游戏里负责制作lightmap，就是制作全局光，属于一个很漂亮的女人，有了他团队很漂亮，但是他的存在对其人的绘制方式都会有一定的影响，gb很难取舍，不过漂亮的女人人人喜欢，gb最终
应该会答应他留在这个团队里的，但是如果有一个更好的方式让gb取舍，gb肯定会选择新的实时全局光而抛弃beast。gb对音效本来就没啥要求，给我个喇叭我出生就可以了，gb很满意fmod多
功能性。lua则和gb没关系了，gb不想和他扯到一起，只想让他们共同有个后代，后代会在一起，只要用心栽培lua和gb能过的很幸福。
其实说了这么多，我感觉我没乱，但是写出来的东西真看不下去了。组件的应用设计模式肯定少不了，但是不能强求，特别是图形方面的组件一起应用的时候，会互相牵制，很麻烦，很乱
。而服务器的设计每一个消息都牵动着客户端的心，引导着客户端往那个方向走，有空还得去关注下服务器。
太多的设计思路会乱，太少设计代码又纠结。
不好的图形没卖点，好的图形吃显卡。
反复的策划累死程序，单一的策划程序怀疑。
用太多的组件总得升版本，用太少的组件总的改bug。
（原先发在我qq空间上，不好整理，挪过来了，有看了一遍，有点乱，后续需要整理）