第一个是日本网站 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)