最近看《Game Programming Gems 1》，第一篇是关于以数据为中心的游戏开发，如果能够把一些数据属性甚至是逻辑抽取出来放在plain-text文件里面，就能够获得巨大的灵活性，因为engine programmer和game designer很可能不是同样的人员，game designer能够在不“打扰”engine programmer的情况下通过修改plain-text文件的内容来尝试发挥engine的潜力。文中提到一个Elite游戏，逻辑和数据分割的特别好，所以第三方可以通过修改游戏来扩展游戏。这个游戏我没有玩过，但是我知道Warcraft在这方面做得也非常好，通过Warcraft Word Editor，几乎可以任意编辑这个游戏。在Warcraft中，单位的外表、技能、属性全部都是数据，可以很方便的把一个兽人的机能嫁接到一个箭塔上面，让一个石头能够发出火箭。毫无疑问，Warcraft不是用plaint-text来存储数据的，考虑到效率的因素，用二进制格式更好。实际，我想在开发初期可以考虑用plain-text，随着项目的推进，应该使用二进制，而首要的是建立可视化的数据编辑器，没有谁会忍受长期通过修改枯燥的文本文件来编辑游戏数据。
我曾为一个嵌入式UI系统工作，规划部门想做一个强大的可配置的系统，要求所有的Widget可以skinnable，也就是说，可以通过更改系统当前的skin,所有的widget的外观就焕然一新，比如说在“热带雨林“skin下，所有的widget色调都是绿色的，提示icon是一片绿叶，button是圆角矩形...;在“火焰“skin下，所有的widget色调都是红色的，提示icon是火焰，button是圆形... 这个想法的初衷是规划部门“偶尔”见识了一下CSS在网页上的强大效果，于是要求做一个和CSS一样的系统，现在想来这个idea真的很有野心，应该相当于M$即将退出的Longhorn的XAML吧。问题是CSS的表达能力有限，无法扩展，没法满足这个“野心”，于是通过讨论，决定用xml语言来表示skin，开发人员和规划人员经过几周的讨论，制订了一套xml语言规范。期间，我算是领会了在开发中保持bussiness man和technical man的平等地位多么重要，因为企业文化的原因，我这样的technical man在讨论中完全处于被动地位，没有什么讨价还价的余地，而bussiness man不了解技术，但是他认为他能够想的到，就应该做得到，于是一些技术风险的隐患在一开始就埋下了。
和太多项目一样，开发工作在还没有做成熟的设计和论证的情况下迫于压力开始了。很快，我们就发现效率成了大问题。widget是很基础的component，其效率直接决定了整个系统的效率，根据规划，widget几乎什么属性都是skinnable的，可以和warcraft有一比（夸张一点了：），每显示一个widget，有很多数据都要从xml文件中读取，读xml的过程就非常耗时。为了提高效率，我们尝试了各种办法，首先想到的是减少读xml文件的操作，采用flyweight模式，尽量合并重复的skinnable属性，而且故意不立即释放load过得skin资源，因为很有可能这个资源很快又要被使用。
规划部门似乎没有看到效率潜在的影响，继续添加新的需求，更多的属性被划为skinnable,而且提出了多层skin的概念，如果一个属性第一层没找到，就去第二层找，第二层没找到，继续，直到设备层，设备层应该有一个缺省值。这实际上就是数据的继承，通过引用数据可以实现。问题是运行是需要载入的数据成倍增加了，自然执行时间也成倍增加了。在实践中，我们发现最耗时的是读取xml文件，只要数据读入内存，在实际情况中，在各层中依次寻找一个skinnable属性值消耗的时间还是能够接受，于是就从xml文件中做文章。经过讨论，我们觉得在嵌入式中用xml表示skin没有什么意义，用户不可能在嵌入式设备上编辑skin,肯定是在PC上编辑，然后传送到嵌入式设备上，所以在嵌入式设备上完全可以用二进制的数据格式，既节约可空间（不用存贮大量的xml tag)，也提高了效率。开始享用wbxml(Wireless Binary XML)，但是由于系统没有wbxml解析器，只好作罢，于是我们转向通过Java的Serialize方法（我们用java开发），把load的skin数据变成二进制文件，然后读取这个二进制文件，这样效率得到了提高。在寻找如何serialize java object的时候，得知其实java自带的persistentce方法其实有很多浪费，于是弃之，自己实现对java object的serialize/unserialize，结果表明，平均效率有提高了5倍。最后，花费10秒的读取xml文件操作缩短到1秒之内完成。期间由于自己实现serialize/unserialize没有考虑到多个java变量可能refer同一个object，还一度造成本来100个object被serialize进文件，读出来成了1000个object，还好被profile技术发现了，及时得到更正。
整体而言，这个“野心”的规划还是得到了实现，但是因为进入得太仓促，也没有很好的吸取同类产品的经验教训，还不能称为优秀的软件。如果一开始能够多花时间定义合理的skinnable属性集合，效率应该更快。至于多层skin，个人感觉实在嵌入式系统中实在是画蛇添足。听说.net framework 2.0中也会有强大的theme/skin技术，等正式发布了，一定要领教领教。
