把所谓某萝的技术贴里面的一个回帖专门贴出来好了

lele487

看了楼主的帖后忍不住也去拆包来看……毕竟自个儿公司用的 graphic engine 也是 Gamebryo，有很多先天的优势可以去拆包。

认认真真的分析了下，顺道想办法解开 zpk（这个弄了好久）包，这才发现……唉～楼主提出的数据……呵，一派胡言。

文内很多数据都只是去将目录底下的档案大小直接提出来而已，也不去算实际解包后的状态。而且很多东西说的都有些似是而非，感觉很容易误导群众的说。

底下就几点清楚的（呃，因为是纯程序，对美术建模的什么好坏很难做客观的评论，故此省略）说一下看后的感想。

首先，shader （就是那个渲染脚本）的容量本来就不需要大，一般而言，就算是同样是 Gamebryo 的上古4 与 Fallout 3，用到的 shader 也不会逆天到了好几 mb。

要搞清楚 shader 只是辅助画面处理而已，举个例子，一个 outline（描模型外框）的 shader 顶天了不起写个 2kb 就很偷笑了，Depth of  field （景深处理用的，就是远景模糊强调近景的那种）的顶多 10 来 KB 就很吓人了。所以，六百多 kb 的 shader？坦白说，已经有点太多了，虽然没有一个一个仔细去看每一个 shader 是拿来做啥用的，不过举个小例子：Mass Effect 2 中所使用的 shader 也不过只有三百多 kb，当然，他用的是 unreal engine，用来同比很不恰当，但是，懂得 3D 游戏开发的人都知道一件事实：说白一点，shader 这玩意儿比的不是容量、数量，真正该比较的是质量，所以拿容量来说嘴？这也算技术帖？

再来，音效的采样 352 Kbps……这个，说真的是有点太过了。不过见仁见智啦，有人喜欢高音质无损的，很难说好还是不好。不过楼主提到的：“至于用openAL实在让某萝想笑，gamebryo难道用的测试版的，还需要再用第三方开源代码做支持？”，这个就很……有问题了。

要知道，Gamebryo 只是一个很单纯的 Graphic Engine，也就是“绘图引擎”，他并不是包山包海的 Game Engine（游戏引擎，也就是什么死人骨头都包的那种很好用又贵死人的玩意）。喵的，Gamebryo 我用了三年多，还不知道原来 Gamebryo 还有内附提供专业的音效引擎可以使用。他都嘛是“强烈建议”用户使用与他合作的第三方商业引擎，好比是我们公司用的 Wwise 或是老牌一点的 miles sound system。至于用 OpenAL？这个有啥好奇怪的，省钱呗，而且资源多又稳定。况且商业游戏就不能用开源库？Square Enix 的最后遗迹 PC 版也是有用到 OpenAL 啊，难不成这也是同人游戏？

第三，模型面数跟容量一点关系都没有。要有一个基本观念，模型的面数能占多少容量？一个 10 万面的“空”模型顶天容量不超过 1 mb。那耗容量的是啥？真正占容量的是贴图！所以说什么一个高模武器 10M 的，见鬼，麻烦看一下他的贴图有多大好呗！还有是不是有用到 light map、normal map 的材质，跟面数一点关系都没有。

更不用说 20 面的怪物了……你妹的，20 面能拉出古剑里游戏怪物的模型？见鬼了，原来中国的能人这么多。

第四，楼主所说的“脚本：241K+43K （再次无语，容量决定内容，也就是个触发器吧）”，这个原来可以用容量来算的啊？真是天才的行为。一般而言，script 语言（例如 lua 或是 python）是可以用 JIT (Just In Time) Compiler 编译出 byte code 来加快 virtual machine 的执行效率。呃，这么说太专业了点，说白一点，就是可以将原本文字型态的脚本语言转换成方便虚拟机执行的程序。一般而言，转换后大小都会缩减许多。所以拿这个来说只是个触发器？唉～～又是直接拿容量来忽弄……

算了，太认真就输了。

不过说真的，古剑怎么不用一些挺便宜且帮助很大的第三方引擎来帮忙完善场景与效能？例如 SpeedTree，这个拿来做花草、树木的场景建置非常的好用（也好看），并且可以节省容量与效能。

还有就是帮助绘图引擎 culling 的 umbra，这个对空旷场景的效能很有帮助（而且挂进游戏也就才几行程式的功），毕竟 Gamebryo 的 culling……不是一般的烂。

以上是一个刚放假挺无聊的程序员的乱喷，唉～网路上的帖，不是全部都是能信的啊！