這些天給遊戲加聲音，發現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技術實現虛擬世界是不是一個好的選擇，是不是從生物知覺上着手會更好。
