- 1 名前：名前は開発中のものです。 [03/07/10 00:10 ID:6FQp6G+O.net]
- 比較的地味なボードゲーム専用のスレが欲しくて立ててみました。
私はc言語で作ったデータベースを使って人間と対戦できる将棋かチェス
みたいなソフトを作りたいと思ってますが、グラフィックインターフェースの
作り方がわからなくてつっかえているレベルです。
- 345 名前：310 mailto:sage [2015/11/19(木) 14:23:44.03 ID:W/V+CKXD.net]
- 定石部分もクラス化が終わりました。クラスなんての扱うの初めてなので、もうちょっと
綺麗にできたかなと思う面もありますが、C++習得が目的ではないので。
終盤確定読みは０．０５秒刻みで速度アップ。FFO#40で２．３秒になりました。
今まで、速いプログラムでは３０手目くらいから勝敗判定を始めると言う記述を読んで、
なんて速いんだと思いつつ、何に使うんだろうと思っていましたが、ようやく腑に落ちました。
オセロというゲームは勝敗だけが問題で、勝つんなら２石差で十分。「少なくとも負けない
手」というなら、(-1,0)のNull windowで探索してβカットされた手を選べば良い。評価値は
不定（これより良いという値）でも負けない手であるという点では「確定」手順です。moveorder
が正確なら、極端に石差を減らす手も選ばない。これなら現状でも２５手ちょいくらいは行けそう。
ただ、これは勝勢の時の話で、敗勢の時の評価値は「これより悪い」という数字だし、
逆転は相手のミスに期待するしかなく、相手も同等のロジックのAI相手だと必敗となる。
結局定石段階で勝負がつく事になります。
今、定石DBは３０手を前提に組んでいますが、３１手目から勝敗判定ができるんなら、定石
を外れない限り中盤探索が不要になり、定石から外れた時にのみ中盤探索が必要になる。
つまり中盤探索は対PC戦では重要度が低く、定石が切れたら、即、終盤探索が始まる。
そもそも評価関数が良ければ、中盤もあまり深く探索する必要がないわけで。
深く読む意味って、なるべく評価が正確なステージを使いたいからなんだなぁと。
というわけで、次はそろそろ中盤探索です。Multi Prob Cutの英語論文を読まねばならぬ・・・。
- 346 名前：310 mailto:sage [2015/11/21(土) 00:05:47.02 ID:WWzrsUCT.net]
- 定石DBを使って３０手目まで着手した盤面の予想石差が２で勝ち判定だったので、
試しに３１手目から勝敗判定をしてみました。
(-1,0)のNull windowで７分３０秒ほどで解けました。
（参考）勝ちと引き分けを区別するために(-1,1)で計算すると９分３０秒ほど。
探索ノード数がintではオーバーフローしてしまった・・・。
これから、３３〜４手目（残り２６〜７手）くらいで、１０秒程度で解けると予想されます。
勝勢ならこれで良いのですが、敗勢の時は、初段がβカットされないので１０倍程度
時間がかかる。そうすると、残り２５〜６手目くらいが勝敗読みの限度かなと。
もっと高速化が必要なのか。それとも、何か発想の転換ができるのか。
|
 |
