※ 引述《AmosYang (LetMeGoogleThatForYou)》之銘言： : LolAI 的設計 [略] 一開始覺得自己沒空所以沒參與，後來看大家討論到心很癢，於是就試寫了一下... 後來寫上癮了，所以多撥出一些預定外的時間來做這個，但發現還真的是沒什麼時間， 搞到現在覺得有點心神不寧，一直隱隱約約在想這個議題 = =" 雖然想說真是害人不淺，不過回到以前這種解題的感覺也滿有趣味的，很久沒這樣了 anyway, 其實我只是想說，寫完 minei 0.1.0 後，回頭來細看討論，之前都沒細看 是因為不希望影響自己的設計方法。發現 LolAI 的計算法幾乎跟我一樣 @@" 不過用的名詞不太一樣，我不知道是否應該有正確的名詞？ 裡面的 clause 我是命名為 clue, 而我另外有個 clue set, 大致是表達一個 block (cell) 可以得到一個 clue set. 而 N1 則是 clue set 的 overlap (intersection), N2 N3 則是 clue set 在計算機率過程中會產生的。 看到那段 min/max 實在是很眼熟啊 XDDDD 雖然我不是很肯定兩者是不是完全一樣？ (scala code) http://github.com/godfat/minei/blob/minei-0.1.0/Minei.scala#L111-117 val min: MineSize = (set.map((clue) => clue.amount - (clue.poses.size - overlap.size) ) + 0).max val max: MineSize = (set.map((clue) => clue.amount ) + overlap.size).min 很不幸的是，經過 tkcn 測試，0.1.0 輸 Tkcn4AI 很慘，沒贏過 XD 而這版的機率確實計算很不完全，沒考慮很複雜的重疊狀況， 只假設一個 clue set 裡面只會有唯一一個重疊。我自己試玩的感覺是還行， 這證明了我不太會玩這個遊戲 XD 後來想試著加大搜尋範圍，一方面是跑得變很慢，另一方面則是因為搜尋範圍 變廣了，複雜重疊的狀況也增加，導致這種簡易的機率的準確度大降， 反而會讓他變成白痴。用了一些搭乘捷運的時間，好不容易想出考慮所有重疊 狀況的組合，不知道這個週末有沒有時間實作出來... 本來上週想詳細說明計算方法的，結果一直拖到現在都還沒寫。 還是乾脆等全部想法實作完再寫？ XD 目前暫定計畫是這樣... 1. 寫完說明 2. 釋出 0.1.1, 基本上演算法一樣，只是調整了內部實作，希望有跑快一點 3. 寫好調整 input 的 adapter, 還有一些利於 debug 的 methods. 4. 寫好一些比較容易實作的想法，釋出 0.2 5. 視情況調整，看有沒有放 0.2.1 的必要 6. 完成比較困難的實作，釋出 0.3 不知道 tkcn 所提到的考慮剩餘地雷有沒有辦法做進去？因為我原本的想法是 完全忽略剩餘地雷，假設我們在一個廣大的平原上，地雷總數未知。但這似乎影響 也滿大的。考慮極端情況，原本 1/2 的可能，由於剩餘地雷只有一個，當然不會 有需要兩個地雷的情況。再考慮 stimim 提到的考慮對手的盤面，這樣就真的是 minimax 的演算法了，看來這可以發展成做很久的計畫 XD 我最早的想法真的太天真了 XD 本來是想說算得差不多應該就很強了... 像是我現在跟 0.1.0 玩就沒有 100% 的勝算... == 其實我原本真的只是想講幾句話，說 minei 跟 LolAI 很像.. -- 「行け！Loki！」（rocky ロッキー） －Gurumin ぐるみん 王子？ XD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.135.160.129