【オセロ,将棋】ボードゲーム Part2【囲碁,War】
■ このスレッドは過去ログ倉庫に格納されています
比較的地味なボードゲーム専用のスレが欲しくて立ててみました。
前スレ
【オセロ,将棋】ボードゲーム【囲碁,War】
http://mevius.2ch.net/test/read.cgi/gamedev/1057763418/ 310さんみたいに既存コード全捨てでやってみようかなぁ?
もう一度まっさらな気持ちになって… まっさらな状態から書いてみようとしたけど、
めんどくさくなってすぐ昔のコード確認しちゃうw
駄目すぎるw ソース喪失以外の時は、結構コピペしていますよw
書き直しの時は、たいていあちこちで使用しているクラスの構造変え
たりする類の後戻りが難しい変更加える時なので、中の関数は一緒です(汗
新しい評価関数は、だいぶ落ち着いてきましたが、遡り28手くらい
でタイムアウトになります。並べ替えに使っているので精度が上がる
と速度が速くなるのです。前は29手、調子が良い時は30手くらい
まで行っていたので、まだ精度が追い付いていないみたいです。
これでしばらく強化学習の具合見ながら待つだけになっちゃいました。
5×5の囲碁くらいならCNNで評価関数作れないかなぁとか、詰将棋を
作るならBitboardを2バイトに拡張しなきゃとか、悪い虫が疼き始めて
います。 後のコード書きやすいように柔軟性のある設計にするかゴリゴリの最適化を目指すか悩み中w 僕が読んだ本では、
最適化するな。アルゴリズムを考えろ。
アルゴリズムなら桁単位で速度アップし、過去に行った最適化は無駄になる。
と言うよな事がトップに書いてあって、それ以来(自分の)読みやすさ優先にしている。
BITBOARDのAVX2命令とか、その辺でいくつかの関数のみ、ゴリゴリにしている。
とはいえ、その辺も一応アルゴリズムの範疇かなぁ。
演算子のオーバーロードとか関数で隠ぺいしているしね。
問題は、最初にクラスの構造とかあんまり考えてないので、あとでごちゃごちゃに
なってしまう事。それで何度か書き直ししている。 まあ、そのセオリーは私もどこかで聞いたことありますがw
アルゴリズムでの改善が行き詰まると結局泥臭い最適化に手を出すことにww
すでに一回実装したことのあるプログラムだしある程度勘所というか見通しは立つかなーと 勢いでコード書きなおしてるけどテストするのが面倒くさいw
言ってもしょうがないけどw またしても問題発覚。
タイムアウトなどでキャンセルしたとき、探索途中の中途半端な評価値の置換表
が作成されている模様。対象の特定はできないため、置換表データをいったん
削除して、全データに対して再度遡りチェックを実施する事で、置換表データを
再作成する事にしました。
むむむ。
評価関数はそれなりの精度になっているので、それなりの速度ではチェックできる
はずですが、またしても…って感じでがっかりです。
同一評価値で変化がある分、記譜は多少は膨れるはずなので、そちらに期待。 9路囲連星、一応ルールと簡単なモンテカルロAIはちゃんと動いたっぽいです。
ここからどう展開するか。 とりあえず軽く遡りチェック完了。28〜30まで遡ると時間かかるので当面25前後まで。
もっとも誤着手なしタイムアウト無しだと30手だろうと遡れちゃうから、28手あたりの
適度なところで止めちゃいましたが。
で、置換表データ激減。いままで間違ったものを相当学習に取り込んでいたっぽい。
あと、MCTSのツリーの末端(以後終盤探索しているので数値確定)の評価が時々
狂う問題がありまして、いつもではなかったので目をつぶってましたが、暇だった
ので着手。原因不明なれど、二重更新問題っぽかったので、ツリー部分のコード
を整理してみたところ、何故か治ってしまった模様。
本当に直っていたら自己対局の精度も少し良くなるはず。
つか、羽生永世7冠誕生ですね。
記譜みてみましたが、何が何だかわけわからんけどw Buroさん型特徴の評価関数もそろそろ限界っぽいのと、今のままだと強化学習にも
かなり時間がかかるので、新しいパソコンが欲しくなってきました。やはりCNNに行く
しかないかもという事で。
ものは試しにi9-7980でパソコン組んだら幾らになるのか、ネットで見積もってみた
のですが…そっと閉じてしまいました(汗
クロック数とか見ると、10コア20スレッドくらいの奴が、一番よさそうな気がするんだ
けど、どうなんだろう。 メモリも山盛り積みたいですよね〜
GPGPUも考えられるし。 今見たorz
夢想段階にあったものをことごとく圧倒的な力量でやられてしまふ。
そのうち、5分でオセロ作ったよとか言われるんだろうなぁ。
学習と評価の実行が完全に二分された今となっては、
学習に使用するハード性能は正義だと思い知らされる。 グーグルのアルゴリズムはマジ万能なんですかね〜?
必要マシンパワーがあれですが、ムーアの法則が解決するでしょう。 そんなに万能ならライブラリとして公開してくれw
囲連星とライフゲーム碁を学習させたいww 9路囲連星のDB作りはじめました。
何日かぶん回そう。 non-MonteCalroなツリー探索(勝手にそう呼んでる)は、MCTSがロールアウト
関数さえ作れれば万能なように、完全情報ゲームでは万能だと思う。
あと強化学習による評価関数の作成も。
ただ、まだAlpha碁Zeroの論文読んでないからわからないけど、CNNの入力
については、人間が介在しているかもしれない。少なくともアルファ碁の段階
では、ちょっと特殊な入力データを用意していた。
それと、完全情報ができない以上、強さの地平線を広げたに過ぎないのも確か。
それを実現するために圧倒的なマシンパワーを使っているわけで。そのマシン
パワーを前提に、それを完全に活かせるアルゴリズムにしたってところが、評価
ポイントなのかもしれない。
かなり悔し紛れな評価だけどorz ガンガンツリー展開して全部DBに突っ込んでたら意外と早くメモリがパンクした。
相変わらず学習しない俺w
しょうがないからDBに入れるのは序盤だけにするか。 Googleがやらかしてから、後だしで俺も考えていたとか悔しいので、
前から思っている事をボソっと書いとく。
十分に深いDCNNの場合、表現の自由度が高いから、強化学習を繰り返す
事で過学習になる事が、起こりうる局面の大半を内部に保持する事につな
がっていて、実は汎化性能ガン無視で良いのではないか。起こりにくい局面の
評価値はグチャグチャでも構わないという事で。
と思っていたりする。 修正してみたけど、8プロセス並列で動かすと意外とまだメモリがきついな。
しょうがないから1プロセスだけで流すか。 うーん、なんか同じ局面しか選ばなくなっちゃう。
これは致命的な欠陥だなぁ。
どうしよう? あ〜ツリーのノードに親ノードポインタ入れてなかったわw
変だと思ったw。
でも対称局面合流させちゃってるから親が一意にならないな。。。
どうしよう。。 なんか、UCTって初期の探索で間違った結果出ると挽回するの凄い大変なのかね?
それこそ修正に指数的な試行が必要になっているような… おっと、なんか挽回してきたw
それはそうとして、メモリが欲しいですねぇ。1TBくらい うーん、局所解にずっぽり嵌ったっぽいorz
地力で脱出してくれないかな〜 うおお、メモリ消費がじわじわ増えてきてる。
今晩一晩耐えられるかは微妙なラインだなぁ。 あれえ、おかしいな。
かなり学習いい感じで進んだと思ったのに、公式AIに全く歯が立たない。
やっぱ読めてない局面に分岐されると無力なのかなぁ DBだけじゃ無理か。
期待が高かっただけにガックリ。 ここでヒューリスティックに走るかDBの更なる肥大化に走るかCNNとかに手を出すか。
分岐点やな。 当たりの石をつがないなぁなぜか。
ロールアウトで当たりの石を抜く確率と当たりの石をつぐ確率増やすか。 キター!初勝利!
最終的にはアルファ碁みたいに100戦100勝したいな。
(
;FF[1]GM[1]SZ[9]
;B[de];W[dg];B[ef];W[cc];B[eg];W[fd]
;B[ec];W[eh];B[ed];W[ch];B[eb];W[fe]
;B[ee];W[ea];B[fa];W[hh];B[da];W[ac]
;B[ea]) ロールアウトの着手確率いじったら黒番の勝率5%だと…?
何が起こってるんだ… 局所解に落ち込むとなかなか抜け出せないのでUCB1のバイアス係数を思いっきり上げてみた。
これで局所解抜けてくれればいいが… MLP版の評価関数がNaN地獄に落ちてた。
何回かやり直したけど、結構簡単にNaN地獄に落ちるので、一旦仕切り直しで、
線形回帰な評価関数に注力する事にしました。
MCTSでテストすると、途中まで割と見知ったオープニングになってきているけど、
評価値自体はあんまり安定していない感じ。まあ、相対関係があっていれば、
絶対値はずれていても関係ないといえば関係ないけど。
しばらく強化学習を続けながら、ちっと別な事を考えてみます。
というか、Alpha Zeroの強化学習の回数が、思ったより少ないなぁと思ったけど、
自分がこれまでにやった回数を概算で考えてみたら、桁が2〜3くらい少なかったorz
やっぱマシンパワーは正義だなぁ。 今晩一晩ながして局所解抜け出せなかったら別の方法考えなきゃな…
zen+が超絶スペックという噂が流れてますが、デマリークともいわれていて、
本当だったらいいなあと思っている今日この頃。 お、局所解抜けてる。
DBがTXTで1GB行っちゃったてへぺろ。 お、凄い、いい感じの勝ち方した。
これの凄さが分かってくれる人がどれだけいるかわからないが…
(
;FF[1]GM[1]SZ[9]
;B[ee];W[eg];B[df];W[fd];B[dc];W[dg]
;B[fe];W[ge];B[gd];W[gf];B[fc];W[cd]
;B[ed];W[cc];B[cg];W[ch];B[bg];W[fg]
;B[gc];W[gh];B[bh];W[hh];B[ai];W[ba]
;B[fd]) 白番でも勝てるかもと思ったがそんなに甘くなかったw うあああ、白番で惜しいところまで行ってバグで不正終了w
とりあえずバグとらなきゃorz うーんまだまだだなぁ。
>>146はたまたまかorz. 新しいパソコン欲しいな〜
現実的な線でいってもメモリ64GBくらい積みたい。 DB作成をマルチスレッド化したいな〜
でもMCTSのマルチスレッド化って結構難しんだよな〜 MCTSのマルチスレッド化は簡単だと思う…
マルチコンピュータは難しいけど。
強化学習がなんかおかしい感じだったので、記譜学習で上書きしたら
かなり過学習になってしまった。強化学習で戻せばよいかと思ったけど
なんかなかなか戻らないorz
強化学習どっかおかしいのかもしれない。 えーそうですか?
排他制御とかしたら性能出なさそう ID違うと思うけど535です。
DBがTXTで1.7GBに。
実行時7GB程になりました。
std::mapを別のコレクションに変えたらメモリ使用量減らないかな〜? unordered_mapにしてみたけどあんま変わんないやorz 排他制御は、まあ普通にしてますけど、PPLのcritical_sectionでlockしたり、
int型ならatomic<int>していたりで、並列ライブラリにお任せです。
またVirtual Lossという方法があって、ツリーを下っていく時は、先に負けた事にして
降りて行って、末端から戻ってくる時に正しい勝敗に置き換える事で、並列探索
の各スレッドが同じ枝に集中しないようにして、排他がかかる可能性を減らしてます。
あとは、排他制御が必要な領域を細かい単位に分割する事ですかね。
#と思って、ソース見たらVirtual Drawになっていた(汗
あ、そうか。DB化しているって事は、合流ありだし、盤面をキーにしなきゃならないから
そうなるとちょっとややこしいのかな?
自分は合流無視で、各ノードに盤面情報を保持していません。直前着手のみ持って
いて、ノードをたどる時に盤面情報を更新しながら降りていきます。着手もBITBOARD
の64bitは無駄なので、char型にしちゃってます(内部的にはintなんだろうけど)。 PPLなんてのがあるんですね。
頭の片隅に入れておきます。
とりあえず、子ノードへのポインタが結構メモリを食ってるような気がします。
これを無くして毎回子局面を計算するようにしてメモリ節約するという手もありますがあんまりやる気がしないなぁ。 PPLはVC++専用の並列処理ライブラリです。
Intel TBBとかと中身はほぼ同じだと思います。
かなり抽象されていて、わかりやすいです。
自分はこれなしでは並列化できません(汗
ツリー構造だと子ノードへのポインタが一番大事な情報になっちゃいますね。
その場合ポインターと直前着手があれば盤面情報は不要になります。
一方で、ハッシュテーブル構造だと、子ノードポインタ不要で、キー(と衝突検出)
のために盤面情報が必須になります。
DB化するんならハッシュテーブルとかの方が向いていますよね。
自分はMCTSでツリーを作ったり消したりなので、ツリー型にしています。
shared_ptr使って、不要になったノードはシステム任せで自動的に削除して貰って
います。ハッシュテーブルだと、そう簡単にはいきませんね。 ノートPCの冷却用(動作周波数に結構影響する)にUSB扇風機使ってましたが、
結構サイズでかくて持ち運び面倒だし、ノートPCのUSBポートに刺していると
安全装置が働いてしまうので、別途電源取っていました。
で、どうせ強化学習回しておくだけで暇だったので、専用のクーリングファンを
自作してみました。
タカチのアルミケースをぴったりサイズに切り欠いて、USBコネクタと5Vの
クーリングファンをセット。ノートPCに装着するとファンが回って冷却開始。
製作時間1時間程度。材料費は3000円くらい。
雑に作った割にはうまくできた。 EigenのSparseMatrixのサイズ制限を変える方法が見つかりました。
現在、簡易版と詳細版の2種類の評価関数を学習していますが、
これにより詳細版を完全にBuroさんモデルにする事ができるように
なりました。
というわけで、詳細版は再度学習し直しです。
簡易版は、多少癖があるようだけど、そこそこまともになっています。
一方、詳細版は何度もやり直し中(汗 DBはメモリの勝負になる。
やはりCNNなどでメモリを圧縮する必要がある。 うお、試行回数0回のデータ削除したらメッチャメモリ使用量減ったw
これで当分DBで押せるww ちょっとづつ良くなってるとは思うけど今一歩だな〜
もうちょっとヒューリスティック入れたほうがいいかな〜 気が付いたらTensorFlowがWindows対応になってるね。
New PC欲しい病再発の兆し・・・ とりあえず、ヒューリスティックのアイディアが2つあるんだが、
下手に手を加えないでDB肥大化で押したほうが、
真の棋理に近づくのかもしれないなどとも思ったり。
悩ましい。 ヒューリスティック一個仮組みしてみたけど上手くいかないや。
がっかりorz. ちなみに仮組したヒューリスティックの内容は
適当な回数プレイアウトして7連が一番多くできたところ付近にしぼって
モンテカルロ木を展開するというもの。 序盤はそんなに悪くないんだけど終盤がなぁ
やっぱ9路でも必至、詰めろルーチンいるなぁ なんか落ちるバグがあるな。
そういえば直してなかった。
は〜 ノードを完全読み切りまで展開した時に、末端ノードの評価が狂う時があるという
バグが以前ありました。おそらく並列処理による2重更新問題だろうと言う事で、
UCT探索の排他部分を強化して対応していましたが、ここにきてまた発生。
昨日原因が判明しました。まさかの、浮動小数点誤差の問題でした。
スコアの合計値と、試行回数を持っていて、合計値÷試行回数で平均スコアを
計算しているのですが、合計値が3500万を超えたあたりで+2をしてもfloat的
には、その2差を表現できる精度が無くなって、少しづつ合計値が不足していく
状態になっていました。
とりあえずfloatをdoubeにしてみましたが、案の定メモリーを消費する速度が大幅
増加してしまいました。小数点以下1桁もあれば十分なのでintに10倍値を持つ
ようにしてみようかなぁと思っています。 intに変更。桁溢れが無ければ、これで大丈夫だと思います。
ついでに速度アップしている分だけ、自己対局の探索時間を短くしました。
評価関数を簡易版・詳細版2種類使っていましたが、詳細版も十分に学習
できたようなので、詳細版一本に絞りました。というか、そろそろ追い抜いた
と思えるようになってきました。とはいえ自己対局の評価値を見ていると
30手目以後はそこそこまともな感じですが、序盤はまだデタラメかなぁ。
完全読み切りですが、30手より前に遡る事がなかなかできません。評価関数
の精度のためか、残り28手あたりから急激に読み切り時間がかかるようになり
ます。評価関数の精度が悪いのでオーダリングが正しくできていないからでは
無いかと想像しています。強化学習で補えるかと思っていますが、まだまだの
ようです。
現在、記譜学習は完全読み切りができている盤面しか使用していませんが、
せめてMCTS探索が始まって以後の盤面も学習に使用してみようか悩み中。
これ以上の精度を求めると、やはりDLに行かざるを得ないですね。
今の探索でもツリーがメモリー内に収まるギリギリに係数を設定しているので
探索延長が起きるとあっという間にスワップ開始になってしまいます。
というわけで大きなメモリーが欲しい今日この頃です。 すっごい微妙な駆け引きができるようになって会心の勝利!
と思いきや勝利目前でバグが出てパス2回した後エラーはいて落ちたorz
くそくそくそくそ!
いい加減直さなきゃだけど再現性低いからバグ潰すの難しいんだよなぁ
(
;FF[1]GM[1]SZ[9]
;B[ee];W[dc];B[de];W[ce];B[ge];W[df]
;B[hc];W[fg];B[gd];W[gf];B[cf];W[eg]
;B[gg];W[gh];B[cd];W[fe];B[fd];W[dd]
;B[ff];W[hg];B[be];W[cg];B[];W[gg]
;B[];W[dg]) 勝利が目前に近づくとパスする。
マジ原因がわからんorzorzorz
ログでも仕込むか? 石を取って必勝形になる形だとパスするのか?
条件絞り込みがムズイ。
とりあえず、ログかなぁ? ログ仕込んだら計ったように再現しなくなったwwww
しばらく対局しまくるしかないか バグの原因わかりました。
ノードに盤面情報登録し忘れてるパスがあった。
これで落ちずに連続対戦できるようになるかな。 連続対戦上手く動いてるっぽいです。
今のところ黒番で8勝2敗
かなりいい感じ。 黒番で13勝7敗
だいぶ追い上げられたorz
でも連続対戦ちゃんと動いてるようで嬉しい。 やっぱりintでオーバーフローしてた(汗。仕方無いのでint64で。doubleでも
メモリーサイズは一緒だけど、intの方がオーバーフローがわかりやすい。
あと、効果あるかわからないけど、置換表再利用回りをちょっと機能追加。
途中でゲーム終了になった時のスコアカウントですが、FFO計算をチェックに
使っている関係で空白マスを勝者総取りにしています。しかし、学習の時には
空白マスを含めない方が回帰の計算的には良いのではないかなと思い始め
ています。MCTS的には終局判定を入れてあり正しく終局時スコアを返すので、
あくまで学習時だけの話です。
ただ、記譜を経由していればスコア再計算で良いのですが、置換表に溜まって
いる盤面情報では、アメリカルールのスコアを割り出しようが無いという…。 実家に帰省しました。
DB作成を流しっぱなしにしてきたので
正月あけどれくらいデータ取れてるか楽しみ 簡単にお金が稼げる方法興味ある人だけ見てください。
グーグル検索⇒『来島のモノノリウエ』
G32792G4ML ふむう。学習は大分進んだと思うのですが、勝率が思うように上がりませんね。 leela zeroがもう有段者くらいの実力をつけているらしい。
もういちどleela zeroパクれるか検討するか?
うーむ。 年末年始で学習進めてました。
学習が進んだ結果、33〜35手目あたりは正確になり、評価値の精度が上がった
事からオーダリングが機能するようになり、遡りチェックの時間は少しづつ減ってきて
いる感じですが、30〜32手目以前はまだまだばらつきがある感じです。
また、以前から気になっていたのですが、MCTSによる記譜作成では35手目以後で
急に頻繁に手を間違える症状が出ています。記譜を膨らますにはちょうど良いので
放置していましたが、いよいよバグ探しを開始。やっぱり、並列処理の排他が不十分
で、末端ノードまでたどり着いて同じノードに探索が集中した時に、スコアの更新が
ぶつかっておかしな値になる事で、別のノードを探索。また探索が集中し、スコアが
狂い別のノードを探索という感じになっていた模様です。
修正したら大幅スピードダウンしてしまいましたが、精度は上がりました。
速度を持ちなおせるか色々調べましたが、ちょっと厳しい感じです。 記譜作成ですが、スコア差が大きなものが少ないため、ランダム着手の所に手を
加えてみましたが、今度は極端になりすぎて、パーフェクト勝敗な記譜が増えて
しまいました。どうしよう。
スピードダウンの影響は結構大きく、探索の終盤で、同じツリーに対する探索が集中
するためか、さらに大きく速度低下し、今度はそちらが原因で終盤間違えるように
なった感じです。あちらを立てればこちらが立たずです。
当初は、こういう問題はなかったはずなので、過去のソースを見直してみるつもり。 alpha zero を参考にしたプロジェクトがgithubにいくつかあるんですがパクれないか物色中。
オセロやコネクト4もあるみたいですね。 ありゃ。すでにあるんだ。
たぶんディープラーニングしてるんだろうなぁ。
そりゃそうと、CPUのバグの影響どうなんでしょね。
あまりに時間がかかるので、ちょっと辛い。
記譜作成やめて、ひたすら強化学習にしてみようかなぁ。
後は細かい精度なので、その方が早い気がしてきた。 わかりにくい文章でした。
「あまりに時間がかかるので、ちょっと辛い。」
は、現状の学習方法だとあまりに時間がかかるので、やはり新PC欲しいんだけど、
CPUバグの話が出たので、ちょっと様子見すべきかどうかって事です。
ただ、MCTSで排他待ち合わせによる速度低下が出ているのと、読み切り探索では
並列探索の効果が頭打ちになりやすいので、本当にCPUに投資した効果があるの
かが不安になってきている面もあります。
むむむ。 並列化で速度出すのは結構難しいですよねぇ
まあメモリ増やすだけでも大分違うかもですが。
python 読めるようになったほうが後々いいんだろうなぁ
でもメンドクサイw アルファゼロを参考にしたコネクト4のプロジェクトのパイソンコード読んでるんですが
パイソンということを差し引いても結構難しいんだろうなって感じ パイソンだからコード眺めるだけでどうせ動かせないやと諦めるのではなく
実際に実行できるところまでこぎつけるべきだろうか うーんこれlinux用なのかなぁ
Cygwinじゃきびしいかなぁ しばらく学習しっぱなしというか、デバッグしながら中途半端に遡り状態で放置した
記譜をガッツリ遡りチェック中なので暇です。で、よからぬ蟲が疼きだして、そろそろ
ボードを作ろうかと思い始めました。ソース消失前は、min-Max版時代のボードが
あったのですが、また作り直しです。
オセロにも碁盤ソフトみたいなのがあれば良いのですが、無いようなので自作を検討。
囲碁のGTPみたいなプロトコルを作って、思考エンジンとGUIを分離できたら良いなぁと。
というわけで、匿名パイプを使ったプロセス間通信について勉強してました。
サンプルコードが10年前のC言語しかなくて解読に苦労しましたがエコーサンプル
を修正しながらテスト。coutとcerrを別パイプに分離して、スレッド管理はPPLにお任せ
にするところまでやって、ようやく納得。
ボードGUI作って、プロトコル決めて、AIエンジン部を対応させてと、まだまだやる事が
ありますが、最終的には自動対局までできたら良いなあと。リソースの限界はあります
が、パラメータで強弱が出そうなので、客観的に評価したい。
というか、GUIの作り方から学習し直しだ…
GUI触りたくないからボードソフト探していたのに、無いから自分で作るという罠。 >>191
色々見直して、若干速度は回復しましたが、最初にRollout外した時のびっくりする
ほどの速度は出なくなっちゃいました。ただ、時々瞬間的に速い時があるので、
単純ではないかもしれません。
30手過ぎるとどんどん選択しが狭まっていきますので、ツリーサイズは小さくなって
いきます。ここで、一部の手に探索が集中して、100万探索単位で追加探索したとき
にようやく他の枝を調べ始めるようで、それでもツリーサイズはそれほど大きくならない
ので、メモリーはそれほどボトルネックになっていない感じです。
UCB1のCをいじったり、ポリシーの探索比率をいじったりして様子をみていますが、
あまりフラットに探索すると、正解にたどり着けないまま終盤を迎えてしまうし、
かといってスティープに探索すると、間違いを訂正するまでの追加探索が大量に
必要になるしで、調整が難しいです。そもそも評価関数の精度が十分じゃないと
言う事なんだと思います。 コネクト4、マルチスレッド化されてるみたいですね。
何か読みにくいと思ったら。 多分、コードに飛びつくのはまだ時期尚早なんだろな。
もうちょっとAlphaZeroの基本アイディアを理解してからじゃないと。 コネクト4のGitHUBってどこにありますか?
ちょっと見てみたいかも。
GUI作ろうと思って調べたら、VS2017からなんかだいぶ変わっているみたいです。
MFCは非推奨との事で、ユニバーサルWindowsとかってやつと、あとはCLRですか。
両方試してみようとしたのですが、ユニバーサルWindowsはWindows10じゃないと
ダメっぽい。CLRはなんかエラーで動かない…。他にもC#だと楽だとか色々ある
みたい。MFCは使えるのですが、もう忘れたし、面倒くさかった記憶しかない(汗
C#で作るって手もあるみたい。
とりあえずC#を勉強してみようかなぁというところです。
脱線しすぎだなぁ。 >>310
オセロ用の確立された GUI はありませんが、
nboard
http://www.orbanova.com/nboard/
xboard / winboard (alien edition)
http://hgm.nubati.net/alien.html
Othello Engine Protocol (cassio)
http://cassio.free.fr/engine-protocol.htm
Edax はいずれもサポートしているので、プロトコルは
ソースでも見られます。 310さんと私以外の書き込みがあるとは珍しいですね。
実はROMも意外といるんだろうか ■ このスレッドは過去ログ倉庫に格納されています