!続続BlokusDuo/JavaRock
ピースの選択ルーチンにスレッドを使う例．
スレッド毎にそれぞれ盤面をもつような構成になっている(そうせざるを得ない)．
{{ref SimplePlayerSearchThread.java}}
{{ref SimplePlayer2.java}}
SimplePlayerSearchThreadが実際に探索(というほどじゃないけど)を行うスレッドで，
SimplePlayer2は，二つのスレッドのインスタンスを生成してハンドリングしている．
探索ルーチンは，'u'から'a'までのまだ置いてないピースを順にあてはめていくというもの．
""

それぞれ，JavaRockでコンパイルしたHDLは↓の通り．
{{ref net_wasamon_blokus_javarock_simpleplayersearchthread.vhd}}
{{ref net_wasamon_blokus_javarock_simpleplayer2.vhd}}
JavaRockでコンパイルするときには，Threadの終了とか開始とかのビジーループの中の
Thread.sleepはコメントアウトしないといけません．
""

[[Diary/2013-6-11]]で公開しているののSimplePlayer.javaと置換可能なので，
使うときには↓のようにインスタンス生成のとこを置換すればいい．
{{ref GameAgent.java}}
生成されたHDLは↓の通り．
{{ref net_wasamon_blokus_javarock_gameagent.vhd}}
""

こういうことをしたいときに，
継承とかインタフェースとか使ってJavaプログラムらしく切り替えられないのは，
現状のJavaRockの弱いところ．
""

気になる(？)合成結果は．スレッド使わない版に比べて約+10%でした．
""

ちなみに，両者を対戦させてみたら，今日のの方が弱かった．
評価関数とかないけど，よりたくさん，コマ数の大きなピースを探索してるってだけで
単純に強くなるのかな，とか思ったけど，そんなことはなかった．
DOSプロンプトが実際にFPGA同士で対戦させた場合で，
綺麗な(？)画面がJavaプログラムとして対戦させた結果．
このプレーヤ達にはランダム要素がないために，
実機でもソフトウェア実行でも結果が同じになっているのがJavaRock的にはミソ．
""

::6/11版が先攻
{{ref_image thread_2.png}}
{{ref_image thread_2_sim.png}}
::6/11版が後攻
{{ref_image thread_1.png}}
{{ref_image thread_1_sim.png}}
""