最近連續兩個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
Development Updates
-
因為已經很久沒有新文章,今天就來更新一下開發進度吧。
六月將Switch繪圖底層移植的工作完成後,終於有時間回到自己的專案來工作。之前雖然已經在Unity上將
voxel系統做了一些嘗試,但一直都沒有時間將程式碼做一個整理以及最佳化,所以就趁著還沒辦法開始production的這段時間先來做一些前製的工...
6 years ago
No comments:
Post a Comment