Thursday, September 23, 2010

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