Choice Made

換工作了!

原本的工作:

• 大學裡的研究單位
• 遊戲技術院應用在軍方的研究上, 官僚問題有點煩人
• 薪水和業界比偏低, 沒有overtime, 退休福利超屌
• 離家稍遠, 單程差不多30 miles, 周圍環境不是很理想, 最嚴重的問題是這個路段永遠都在塞車

選項一:

• 規模蠻大的一家遊戲公司, 以前的夢想之一
• 遊戲後端的軟體工程, 和我的專長以及想要做的工作內容有點距離 (想要做的職位interview幾次後被拒 幹幹幹)
• 薪水不低於業界標準, 工作時數不詳, 工作環境和員工福利算是超越同行
• 離家約25 miles, 附近也有不少遊戲公司, 交通一般還好, 算是很習慣的通勤狀況

選項二:

• 規模不錯的汽車音響和車用通訊電子公司
• 行動科技應用在車用通訊的研究, 應該每天會有固定的空閒時間寫自己的indie project
• 薪水算是接近理想的數字, 員工福利普通
• 離家只有5 miles

考慮很久的結果我選擇選項二, 理由主要是離家距離 (家裡有小孩這點很重要) 和可以做自己的project.
除非我夢寐以求的那幾家遊戲公司來南加開工作室, 不然我應該會在這家公司做蠻久的吧 (至少做到indie project完成, 哈~)

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就被無限期延後.