`
javahigh1
  • 浏览: 1225454 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

冷雨——随笔04-11-9

阅读更多
很久没有写BLOG了,其实是很久没有为技术而写BLOG了。
有人说技术是这样一樽美酒,只有在平静的时候,你才能品味出它的甘甜,不幸,最近我的头脑里正逢乱世。
今天北京下雨了,非常高兴,非常难得的机会能让自己冷静下来,坐在这里,写上一点什么东西。
---------------------------------------
这几天跟CGamer是一半吵架一半研究,在工作上也不甚顺利,总是提不起精神。跟CGamer一起把Irrlicht引擎基本看完了,他总结道:引擎的构成方式是在不变性和效率的前提下提取出最大程度的可变性。我想我没有异议。至于这个不变性究竟是指什么,我想主要可能就是数据,数据集。我跟CGamer争吵的核心就是在于不变性和可变性的定位问题上,或许,这本不是我们这种毛头小孩子可以解决的问题。
例如图像,假设说我们想让File和Render层脱离,那么除了Render把对象联系转化为标号联系之外(把利用File*变化为利用文件名,这样在对象这个层次的抽象上,File看不见Render,Render也看不见File。只是在具象实现的时候才需要建立对象联系。),还需要一点就是抽象层就要做到把数据抽象到底。
为什么呢?我们假设这几点:
1、假设数据不抽象到底,只留一个最小化的ImageData,会出现什么情况呢?当在File的具象层准备为ImageData填值的时候,它发现,有很多数据ImageData并不准备记录,那么,File具象层(注意是具象层不是抽象层)必须实现自己的XXImageData,这就有一个问题,在Render抽象层只可能知道File抽象层,那么当Render抽象层需要获取ImageData的时候怎么办?当然你可以把ImageData做成一个DataChunk来解决,但这总归不是很方便的事情:因为标准是由具象层来定的,抽象层再神通广大,怎么可能知道尚未出现的——从他角度所不可见的——具象层如何定制这个标准呢?!
还有一个问题,在Render具象层,是否要和File具象层耦合?现在看来必须是要耦合的。否则即便知道DataChunk是什么,也不知道里面如何排列这样那样的值,仍然是什么事情都做不了。好在这种耦合只是一种标准上的耦合,你只要符合这种DataChunk组织标准就可以。那么问题是,File具象层一换,很可能不再遵循XXImageData的标准,而换做支持YYImageData标准,这下就郁闷了。所有跟ImageData有关的地方全部需要重写或者重改。
设想我们为什么要设立抽象、具象层分开?具象层不互相访问?主要就是为了让各个模块脱离耦合,但是现在的设计只可能是逼迫着我们无法脱离耦合。
既然是无法脱离的耦合,我们就可以试图确定之为不变性。在抽象层设立最大化的ImageData,无论是抽象层还是具象层都应遵循此标准。如果你不知道会发生什么,那么你应该如此:设立DWORD dwReserved1、dwReserved2……dwReservedN,以方便具象层去定制标准了。反正最为核心的数据你都已经握在手里,具象层为了方便其实现订立的一些别的数据,即便在更换具象层的时候发生了更改,也会方便得多。这就类似于DX的思路,核心数据和方法我牢牢控制在手里,一切可变性都应在这些不变性的基础上来完成。
2、但是当这个思路遇到了高层引擎系统,则会复杂很多,众所周知,高层引擎系统可以说是每个游戏每个样子,但就地图格式而言,地图格式对于不同游戏几乎是完全不同的,怎么办呢?可能抽象出来这样一个高层核心数据吗?
答案是,不可能抽象出完全适应于各个游戏的核心数据,但是我们应当尽量试图把数据打散到各个部分,并为之抽象尽可能多的模式和细节。就拿地图来说:我们把地图本身的一些细节独自抽象(长宽高),而高级细节包括区域表和区域控制方式(例如阻挡和阻挡格子表),可能LightMap等也需要记录,或者暂不记录,在地图编辑器里面即时演算生成,其实是一样的。我们把现有的东西尽可能多抽象为不变性,这样一来必然会消耗大量的空间和效率,这就是设计者的问题:在效率和开发效率之间,做何权衡的问题。地图可能还受到一些牵制:包括场景管理器类型(BSP、四叉树、八叉树),那样就需要根据当前注册了哪些场景管理器,针对这些被注册的管理器抽象一些场景管理器所需的数据。肯定会有更好的方法,但是我和CGamer都比较蠢一些,呵呵
如果说地形、地图就是很多现有技术的总结,把这些东西抽象出来就可以,那么物件可能会稍稍复杂一些。我给CGamer提出的、并且几乎瞬间就被那丫挺否了的解决方案是:除了基本数据外,利用大量Reserved数据和脚本配合。我程序:无论具象层和抽象层都可以不知道数据是做什么用的,那无所谓,数据都交给一个比较强大的脚本来处理。例如我可能在做即时战略的时候,btReserved1是用作指定各方的标号,但在做RPG的时候,这个btReserved1又开始指这个物件是Player?NPC?还是触发器?可见Reserved这种抽象数据组织,势必要求一个强大的脚本系统作为补助,否则,其存在只配给大家造成更大的混乱。不过这个天才的(众人:你丫欠扁吧)方案,居然被CGamer那丫挺的瞬间就否决了,不知道他怎么想的。(CGamer:你丫敢说我坏话?!
呵呵,如果大家还有更好想法,一定要告诉我啊,跟回复,或者发信到laburas AT sohu.com都可以(AT应为@,不用@为了避免很多邮件搜索工具的搜索)

--------------------------------
最近几天另一个头疼的就是输入法,Windows下的伪全屏和IME,Linux不知道,这应该是标准的方法,但CGamer看来不想用。支持IME的输入法本身不是很多,据说微软拼音对IME的支持也是有问题的,只有智能ABC才是完全标准,这个我不太清楚,伪全屏降低效率,这地球人都知道。反正最近一段时间颇多心烦,所以经常在下班什么时候搞搞这个,查查资料。搞到了一个Linux下的开源的小企鹅输入法,很不错。但是说实话,那没有注释的函数看得我满身流汗,幸好系统本身不大。

以后的生活估计还是这么些东西:工作就是打包和上传工具、下来跟CGamer继续为他那些鬼点子吵架、最后看看输入法什么的。上帝保佑,或许,这段日子会很快结束吧。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics