※ 引述《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