第一個是日本網站 http://kamoland.com/wiki/wiki.cgi?RensaWiki 突然被問到，我才有種不知道是否用錯名詞、講得太隨便的疑慮 其實最近才在和組員看程式流程，不保證講的概念一定很對 ... 我就試著大概說明一下 @@" 首先捏... 上面那個網站，頁面左側有個開發kit -> AI-COM SDK 這就是 source code。 在看 code 之前其實也要先說明一下這個 AI 當然不是 「只有」權重判段 puyo 落點的設計，仍然有許多經驗法則和規則整理， 譬如說一對新的 puyo 下來共有 22 手不同落點方式， 在 RensaInfo 的「積み込み決定手法の概要」裡有詳盡說明 由此可知當一組新的 puyo 從上方出現時，盤面的 evaluation 基本上就有 22 種不同的下法要去做判斷。 (特別提醒，這 code 可能不是很好看，連鎖的命名就用 "rensa"(羅馬拼音) 而非 combo or chain 之類的，然後註解都是日文 ... 裡面還會看到很多 "Yomi" "Tumi" ...好像就是 "読み" "積み" 還有 Tumi 的複數形 Tumos (淦！明明是羅馬拼音啊 !!!????) 「干擾」泡泡就直接寫 "Jama" (邪魔，日文阻礙之意)) 在 source code 中 kamoland/rensacommon/ai/ 裡， class TumiDeciderCaller 就是決策器，而 TumiDecider 與 TumiDeciderWithPruning 則是分數評價器的 interface 兩個 Decider 的差異在於，當決策器(Caller)發現本次對戰使用帶有 TumiDeciderWithPruning 介面的分數評價器 impl， 在評價各手時就會去判斷此步到底適不適合下 (當然這部份是須要去 implement 那個 interface 的) 例如當目前狀況不需做緊急消除，而下這手會導致誤發火 (消到不該消的) 或是目前狀況需要緊急消除，下這手沒辦法馬上引發反擊、 還是說這手一下下去就是自殺之類的 ... Pruning 的意思也就是刪去，把 22 手中不合時宜的幾步刪掉。 此 SDK 讓使用者撰寫的主要就是去實作 TumiDecider 介面， 也就是實際上每一手的評價系統。 已經有許多版本在 ai/decider/ 資料夾中可供參考。 AiBasedCom 介面只是在評價器中多加上一些電腦對手的參數 (譬如說思考的時間間隔、AI叫啥名字之類的 ..) 每個評價器的 impl 都還有非常瑣碎的內容，各種不同狀況的考慮 與不同的算分方式、甚至是考慮再下一手的狀況也加入這手的評分之中， 每個實作的寫法差異都頗大，網站上還辦過四次的 puyo AI 連鎖比賽。 不過我想 .. 這種用分數評價的方式應該就是 brute force 了， 因為除了一些經驗法則刪去不合時宜的幾手之外，剩下的每一種下法 都要評價，再走評價最高的那一步，而判斷評價的標準往往都是 實際推演一次看誰連鎖最大，原則上來說就是暴力法吧 ...。 只是說這個暴力法有經過一些經驗法則的規畫這樣 ..... 其實看起來效率上沒什麼問題，打起來 AI 也實在不弱。 之前想說用 learning、NN 之類的可能太 overkill 了。 (當然，還是可以以這個 SDK 為基礎去用 learning 或 NN 發展評價系統， 電腦會依據自己的紀錄來調整評分的比重 ...etc... 好像是不用演變到這麼誇張 XD) 大概就這樣 @@" 希望沒講錯太多東西 ** 補充一下 ** 看到 RensaYomi6ABC 這個實作有個我覺得已經是很難輸的設計了 他有一紅二紅三紅的概念，阿，我絕對沒有說是這個 Xbox 360， 這個版本的實作在評價時會考慮這一手與預測下一手 (資訊已知， puyo 向來都看得見下一手) 一紅的狀況以下，完全不會考慮這一手的連鎖，會考慮連下兩手的最高連鎖 (當然這是暴力法找出來的)，二紅的時候就是有點危險， 評分上會分別考慮這一手的連鎖 + 下一手的連鎖， 三紅的時候則是只考慮這一手的連鎖，力求馬上反擊 所以當敵人對它造成的威脅一直很低的時候， 它永遠都會考慮下一手，永遠不會在這一手就把連鎖擊發， 所以除非運氣不好，遇到非消不可的狀況 (22 手都會發火)、 或是這一手非得堵死自己的發火點， (連續來無用的顏色，自己現有盤面完全無法配合) 要不然它的連鎖很自然的會一直越堆越高。 要避免掉那些狀況除了計算更多手之外好像沒別的辦法， (如果計算範圍已經超過已知範圍，變成是顏色未知的 puyo， 那可能性就太恐怖了，做到這邊應該是已經沒意義？ 或是PS猴大講的... 讓電腦偷偷知道多好多步 ...會太強就是了 XD) 與其計算更多步，可能比較重要的是預留活路， 譬如說盡量保持有第二、第三發火點的做法以應變意外狀況， 每一手下下去之後的發火點數量也要納入評價考量之內， 以防對手突然間用小連鎖瘋狂快攻之類的。 好啦 XD 其實已經花太多時間在打文章 XDDDDD... 基礎程式都還沒寫完呢 :~ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.72.57.78 ※ 編輯: linjack 來自: 203.72.57.78 (12/04 23:24) ※ 編輯: linjack 來自: 203.72.57.78 (12/04 23:54) ※ 編輯: linjack 來自: 203.72.57.78 (12/04 23:57)