tag:blogger.com,1999:blog-69069804286053587972012-02-16T05:21:45.661-08:00R2D2http://www.blogger.com/profile/17203930024697324180noreply@blogger.comBlogger41100tag:blogger.com,1999:blog-6906980428605358797.post-36480277886731343472010-09-23T13:29:00.000-07:002011-07-26T16:14:36.570-07:00最近連續兩個projects都用到utility-based agent來處理bot的AI<br />發現AI效率瓶頸都不在short interval的update上<br />反而都集中在long interval的evaluation<br /><br />最近在想 或許可以試asynchronous evaluation,<br />比較不迫切的behavior或許不需要那麼頻繁的評估<br />但是換個角度看, 如果在不同時間evaluate所得到的fitness (utility) value是否還具有相同的意義?<br />拿不同時間得到的utility value做比較的結果 是否能得到相同的most-fit behavior?<br /><br />大概還是要測試比較後才知道吧<br /><br />[後續]<br />最近比較閒所以試了一下asynchronous evaluation<br />結論是不值得這麼做<br />原因如下<br />1. Fitness value的可靠性需要一點blind faith 在某些遊戲種類中這是不允許的<br />2. 需要fallback behavior, 而fallback behavior的eval通常抵銷掉asynch eval帶來的好處<br />3. 所有behavior都需要加fitness decay或是momentum, 調整 = 頭痛<br />4a. 使用lockstep network model時需要特別容易desync<br />4b. Client-server之下AI decision通常不會造成瓶頸, 沒有asynch eval的必要<br />所以最簡單的做法還是eval cycle中做optimization: sensory data能cache的就盡量cache; 用d^2取代d做距離比較; LoS之類這種比較慢的運算就留到target pool sort完再做, etc<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6906980428605358797-3648027788673134347?l=codefighter.blogspot.com' alt='' /></div>R2D2http://www.blogger.com/profile/17203930024697324180noreply@blogger.com0tag:blogger.com,1999:blog-6906980428605358797.post-2383268967843705132009-06-01T17:39:00.000-07:002009-06-05T15:56:47.362-07:00上星期五總算把E3 build 送出去了<br />老實說以工程師的角度來說我亂討厭E3的<br />因為E3 build裏面很多東西都是為了展覽臨時寫的<br />E3過後這些code大概一半都會丟掉<br />即使留下來的, 通常也不是用best solution寫的, 而是the first solution working而已, 效能和維修性其實都比平常爛<br />所以development cycle中多了一個E3等於少了一個月的development time<br />而且還多了不必要的crunch<br /><br />每次聽到一些producer在媒體訪問時說什麽他們多辛苦 工作量有多少<br />幹 不要拿你們的懶叫比我的火雞腿<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6906980428605358797-238326896784370513?l=codefighter.blogspot.com' alt='' /></div>R2D2http://www.blogger.com/profile/17203930024697324180noreply@blogger.com2tag:blogger.com,1999:blog-6906980428605358797.post-39335530897540595362009-04-29T10:01:00.000-07:002009-04-29T10:55:26.886-07:00好久沒有update了, 除了自己懶以外當然忙也是原因之一<br />上個星期為了趕milestone從星期四一直crunch到星期一, 其中有兩天還做到天亮<br />稍微整理一下和我有關的問題根源, 免得以後再度發生慘劇<br /><br />- 這個project cycle原本就超短, 加上這次milestone是1st playable, 要求的delieverable又特別多.<br /><br />- 大家都忙著完成各自的task list, 導致快到deadline前才恢復multiplayer playtest, 測試中發現的bug沒有足夠的時間修理.<br /><br />- AI programmer(就是我啦)和network programmer間的溝通不夠, 不知道進行中的multiplayer容許新玩家加入並take over一個AI以保持角色總數. 原先的design是遊戲一旦開始就不容許player加入, 所以我的一些clean up code放在AI的destructor裡. 但是新的design會導致遊戲進行中clean up機制被提早啟動.<br /><br />- 太晚做framerate optimization, 所以optimization本身沒有經過足夠的測試而造成其它問題. 原本的design是所有的AI每個frame都會收到update, 但是timeslice後update的間隔太長, timescale後超過安全範圍, 例如有些AI轉身因delta time過長而轉太多導致無法轉到設定的角度範圍內, 然後subsequent action就被無限期延後.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6906980428605358797-3933553089754059536?l=codefighter.blogspot.com' alt='' /></div>R2D2http://www.blogger.com/profile/17203930024697324180noreply@blogger.com2tag:blogger.com,1999:blog-6906980428605358797.post-87616436843830541842008-06-10T16:30:00.000-07:002008-12-11T02:49:22.242-08:00<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_cf--F3bR2cE/SE8V3StA8cI/AAAAAAAAAB4/YkfOYcTXQFA/s1600-h/hikari-logo.png"><img style="cursor: pointer;" src="http://3.bp.blogspot.com/_cf--F3bR2cE/SE8V3StA8cI/AAAAAAAAAB4/YkfOYcTXQFA/s400/hikari-logo.png" alt="" id="BLOGGER_PHOTO_ID_5210407333548585410" border="0" /></a><br />用Flash來做game UI大概快變成主流UI處理方式之一﹐連<a href="http://www.ogre3d.org/">Ogre</a>上都出現支援Flash的UI <a href="http://www.ogre3d.org/phpBB2/viewtopic.php?t=41999">Hikari</a>。<br /><br />說實在的用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時的頭疼我覺得這個代價非常值得。<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/6906980428605358797-8761643684383054184?l=codefighter.blogspot.com' alt='' /></div>R2D2http://www.blogger.com/profile/17203930024697324180noreply@blogger.com10