Utility-Based Agent

最近連續兩個projects都用到utility-based agent來處理bot的AI
發現AI效率瓶頸都不在short interval的update上
反而都集中在long interval的evaluation

最近在想 或許可以試asynchronous evaluation,
比較不迫切的behavior或許不需要那麼頻繁的評估
但是換個角度看, 如果在不同時間evaluate所得到的fitness (utility) value是否還具有相同的意義?
拿不同時間得到的utility value做比較的結果 是否能得到相同的most-fit behavior?

大概還是要測試比較後才知道吧

[後續]
最近比較閒所以試了一下asynchronous evaluation
結論是不值得這麼做
原因如下
1. Fitness value的可靠性需要一點blind faith 在某些遊戲種類中這是不允許的
2. 需要fallback behavior, 而fallback behavior的eval通常抵銷掉asynch eval帶來的好處
3. 所有behavior都需要加fitness decay或是momentum, 調整 = 頭痛
4a. 使用lockstep network model時需要特別容易desync
4b. Client-server之下AI decision通常不會造成瓶頸, 沒有asynch eval的必要
所以最簡單的做法還是eval cycle中做optimization: sensory data能cache的就盡量cache; 用d^2取代d做距離比較; LoS之類這種比較慢的運算就留到target pool sort完再做, etc

E3 Rants

上星期五總算把E3 build 送出去了
老實說以工程師的角度來說我亂討厭E3的
因為E3 build裏面很多東西都是為了展覽臨時寫的
E3過後這些code大概一半都會丟掉
即使留下來的, 通常也不是用best solution寫的, 而是the first solution working而已, 效能和維修性其實都比平常爛
所以development cycle中多了一個E3等於少了一個月的development time
而且還多了不必要的crunch

每次聽到一些producer在媒體訪問時說什麽他們多辛苦 工作量有多少
幹 不要拿你們的懶叫比我的火雞腿

Milestone Postmortem

好久沒有update了, 除了自己懶以外當然忙也是原因之一
上個星期為了趕milestone從星期四一直crunch到星期一, 其中有兩天還做到天亮
稍微整理一下和我有關的問題根源, 免得以後再度發生慘劇

- 這個project cycle原本就超短, 加上這次milestone是1st playable, 要求的delieverable又特別多.

- 大家都忙著完成各自的task list, 導致快到deadline前才恢復multiplayer playtest, 測試中發現的bug沒有足夠的時間修理.

- AI programmer(就是我啦)和network programmer間的溝通不夠, 不知道進行中的multiplayer容許新玩家加入並take over一個AI以保持角色總數. 原先的design是遊戲一旦開始就不容許player加入, 所以我的一些clean up code放在AI的destructor裡. 但是新的design會導致遊戲進行中clean up機制被提早啟動.

- 太晚做framerate optimization, 所以optimization本身沒有經過足夠的測試而造成其它問題. 原本的design是所有的AI每個frame都會收到update, 但是timeslice後update的間隔太長, timescale後超過安全範圍, 例如有些AI轉身因delta time過長而轉太多導致無法轉到設定的角度範圍內, 然後subsequent action就被無限期延後.

Flash UI on Ogre

用Flash來做game UI大概快變成主流UI處理方式之一﹐連Ogre上都出現支援Flash的UI Hikari。

說實在的用flash來做game UI真是一個蠻屌的的構想。幾年前在Game Developer Magazine的postmortem有讀過某公司在他們的自己的engine裡面加了built-in flash control﹐所以他們的designer可以在不需要programmer支援下獨立製作各種動態UI﹐而且當需要改變UI design時(一般情況下UI design改變的頻率差不多等於每天尿尿的次數)不會distract到programmer。可能是Flash的performance overhead方面的顧慮﹐當時這種UI處理方式算是蠻另類的。不過在PC和console都這麼猛的今天﹐犧牲一點點resource給Flash用以避免development時的頭疼我覺得這個代價非常值得。