工作学习笔记——4月、5月

  这些天给游戏加声音，发现openal真是个好东西，支持3d音效————给音源一个坐标，声音近大远小这种问题就自动解决了。另外我们队引擎对openal的使用有很大问题，游戏中的每个音效在游戏一开始就要被初始化到不同的音源上，这样很快就把openal的音源给耗光了。正确的做法似乎应是把音效载入缓存，游戏初始化时建立固定数目的音源，播放某个音效时把缓存载入某个空闲音源即可。

  游戏资源越来越大，开发时打包的速度越来越慢，虽然我已经采用makefile的方式，节省了未改变资源的重新编译时间，但是还有两个问题：

1、make检查所有资源是否过期这个操作很慢；

2、打包操作本身总是把编译后的资源全部打在一起，这一步不大幅修改打包程序本身（使之支持增量打包），很难有效提高速度。

  目前看来，第一点可以通过使用make的-r选项，大幅提升检察资源是否过期的速度（这个选项禁止make检察隐含规则，具体为什么这样会极大影响make速度，还需研究）。第二点可以使用开发期不打包的方式来绕过，即只使用make将每个资源文件编译为引擎可使用的格式，同时使用路径作为资源的key，这样开发期不打包，发布期打包，但是资源的key是不变的，程序无需修改。

  这次做的ios项目快完工了，对比以前的BREW游戏，规模、效果、细节上都不可同日而语，体会有几点：

1.不管如何快速迭代，初期策划的核心机制一定要打好。改来改去的工作量是一个方面，这种核心的不稳定往往会导致四不像产品是更重要的原因。

2.美术要学会效果实现上的选择，是采用粒子效果，还是一帧一帧的动画；相应的，对游戏速度、内存容量上有没有致命的影响。

3.开发上，即使是2d游戏，能否合理使用3d方式，来达到节省美术工作量，减少游戏容量的目的。例如一个角色多个方向，阴影这些需求，是不是采用3d方式，效果更好、容量更低、工作量更小。

4.能否把工作量合理的分摊出去，比如多使用脚本、UI编辑器这些工具，将一些本来只有开发才能做的事情，让比较闲的美术和策划人员给做了。或者说，让效果的构思者直接来实现，是不是会更好。策划不要再出一篇一篇的文档、表格，美术不要再出一幅幅的效果图，省去了这些间接的东西，借助工具来直接实现，项目总体上来说应该还是会省时间的。分工会提升效率，但也会带来沟通成本，如何确定最优的分工程度也是一门学问。也许总设计师、总美术风格把控者、引擎架构师辅以一些独门水平不怎么高的策划\美术\开发三位一体通用人才才是比较好的游戏团队构成方式。

  对虚拟现实比较看好，最近开始看一些3d方面的东西。发现大量的技术、细节处理，需要应付像头发模拟、角色脚不能离地、阴影光照等等问题。开始怀疑使用IT技术实现虚拟世界是不是一个好的选择，是不是从生物知觉上着手会更好。