エクセルへの反映状況

 6BETでやっているのに、メダルが何百枚あってもすぐに消える。

なお、上がその自動稼働の際に入手したエクセルのデータである。

ライセンスがないらしく、操作はできないし保存もできない。しかし平均ならばとれるみたいなので、それをやったところ、平均は4.987とでた。

これは26ゲーム分、つまり78個のビンゴバルーンの実践で得た結果となる。

このデータを取得するときに、やはりバルーンの最適解入力がどうも甘いので以後はここを確実にする方法を考えようと思う。ところどころ欠けているマスがあるが(５ケタの部分)、これは最適解に至るまでのＩＤを算出するところで、賭けているということはその操作に到達していないことを意味する。ただしリザルトは完全に入力できている。

あと、最も上のゲームにFREEが３個配置されたことは一度もないらしい。

これではＰＯ率が83%なので、以前よりましになったといえども、まだまだ実機の標準ＰＯ率には程遠い。

なお、FREE配置個数は

1個　53回

2個　22回

3個　2回

となっている。うち1回はプログラムがおかしくなり、0を返してしまった。

入手個数は、判明しているもので

1個　45回

2個　19回

3個　0回

4個　0回

他にも2ゲーム目と3ゲーム目のFREE出現位置が同じなど、かなり怪しい部分もあるので上記の値はあまり信用できない。ただし、この値からそこまでぶれることはないと考えてよい。

ちなみに、過去の我の計算によると、各FREE配置可能個数での平均PO率は以下。

FREE0個配置　7.6%

FREE1個配置　43.8%　

FREE2個配置　189.9%

FREE3個配置　488.2%

FREE4個配置　1535.8%

上記配置可能FREE数とこの平均PO率から理論上のPO率をたたき出すと、

(49/64)*0.438+(15/64)*1.899=0.765625*0.438+0.234375=0.33534375+0.445078125

=0.780くらいとなり、PO率は78%である。

実際のPO率83%にかなり近い数字となっている。

他にも、初期配置FREE個数から理論PO率を算出できるし、少々大変だが、初期配置FREEの位置から理論PO率も計算できる。

もし初期の段階での理論POが高いのに、後半に行けば行くほど低くなり、実際の値はさらに低い、となると操作をしている疑いが高くなる。

とりあえずはもっとデータを正確にとれるシステムの構築を目指していくことになる。

あとエクセル、これはもう買ったほうが良いだろう。

ちなみに、せっかくなのでチェーンボンバー大辞典のように、画面上に配置された番号、色、爆弾の位置関係から理論PO率を推測し、それを実際結果と比較するチェーンボンバー超大辞典みたいなものも暇なら作ってみようかと思っている。

チェーンの内部処理はuwscでは大変なので、そこはすでに演出付き8ゲームすら実装できている我の自作アニマロッタのプログラムを流用するとする。

ここへきていろいろ役に立ってきたわ…。

ビンゴバルーン自動稼働の様子

 いよいよ放置しながらエクセルに結果を反映させ、その様子を見ている。

その雰囲気だと、赤バルーンの判定はほぼ確実に行われている。ただ、少し移動できるよ！の文字がシンキングタイム中に一瞬でかくなるのでそのときに若干の誤作動がごくまれに発生するくらい。

ＦＲＥＥの配置可能個数の判定は極めて正確。ただしその後の最適解配置は、やはり6連続クリックを行っていてもなかなか認識してくれない。そのため、1ゲーム分の処理に時間がかかり、たまに3ゲーム目に間に合わないことも。

別のＰＣに動作させたため、処理速度が遅い問題はかなり軽減され、夜通し放置していても大丈夫そうなくらいにはうまく動くようになった。

なお、6BETずつ3面という非常に少額で自動マクロを行っているが、メダルの減りが速すぎる。とてもではないが遊べるような設定ではない。

そういうつもりならこちらもそれ相応の策を練らねばならない。

２：１３　１２　０　６　メモ　ワンダ30

エクセルへの入力方法

 難しそうかと思われたがこれは普通に、(名前).CELLS(1,11)=""みたいな感じでよいらしい。

エクセルを本来は複数個起動してやりたいが、なんか面倒そうなので最適解データの11列目からを使うことにする。そのデータをエクセルオンライン側に送り込んで、そこで編集をしようと思う。あくまで暫定的な保存場所ということになる。

あとはこのエクセルへのゲーム状況のコピペを、3ゲームにするのみである。

そしていろいろあって、ようやく完成。

これは我の考案したコナステ自動最適解配置機(仮)である。

上野画像で、黄色にバルーンを配置しているが、これは3面分を最適解配置プログラムにのっとって自動で配置したものであり、下のエクセルにはそれらの情報が保存されている。ちょっといろいろ未完成だが。

一応デバッグウィンドウ的な感じで、ちゃんと操作を行っているかを確認している。

いやしかしこの動作の挙動を見ていて思ったのだが、十数秒に1回くらい画面がかくかくして1ゲームに数回は数秒間まったく動かないラグが生じるので、このプログラムでもその間にクリックしようとするとそれが通じず、後々の操作もくるってしまう。

こうなれば、もっと快適にゲーム画面を見られるようなＰＣへの移行が必要ということになる。

ちょっとそれで夜通しやってみるか…?いやしかしまだそこまで堅固でないので怖さはあるが…。

我のUWSCのプログラムへの慣れがなさすぎるせいで500行程度に膨れ上がってしまい、なんかループ対応も汚い。あとでどれとどれがつながっているか見づらい。

おまけに表現方法をあまり知らないので原始的な関数の組み合わせになってしまっているし。

何よりすぐにゲーム画面がかたまるのがもういやでならない。

しかしここまで来れば、我の描いているマクロツールにずいぶん近づいたことになる。

明日にはもっといい線行っているかもしれない。

最適解を実際に自動配置

 かなり苦戦したが、なんとか最適解を実際においてくれるようになった。

この間、赤バルーンの強固な判定を得るにはどうするか、シンキングタイムをどう見分けるか、FREEの配置可能個数をどう判別するかなどかなりいろいろ試行した。

その結果が↓。

たしかに、マウスカーソルが3マス目(18の番号)に行っていることを示そうと思ったが…そうやスクリーンショットはマウスポインタが入らないんや…。

しかし、勝手にマクロが最適解を探知し、しっかりと3マス目においてくれた。cando(感動)

あと一応、初期FREEの個数も取得して、シンキングタイム中にのみこの動作を行う(判定は左下の残り球数が3と表示されているとき)

FREE配置可能個数もやはりchkimgxで行っている。バルーンはchkimgxではうまくいかなかったのでpeekcolorに回帰した。

次のパターン。

今度は、3球終了時点での各種状況。

たしかにFREEの配置可能個数は、数字2を参照できており、2の値をとっている。

さらにINした位置もしっかりと正しい位置を正確に把握している。

ここまでくるといよいよ実用化も近づいてくる。

あとはちゃんとクリックしてくれるプログラムを作り、それをエクセルへとぶち込む。

他には、5球終了時とその後3球がどこに入ったかのデータが欲しい。

ビンゴバルーンにおいては、この5球を境とした前と後ろでは、順不同である。

例えば(1,2,3,4,5)ときて(6,7,8)ときても、(1,2,5,4,3)ときて(8,6,7)ときてもこれは同一。ただし(1,2,3,6,7)と(4,8,5)の組は同一でない。なぜなら5球目まではFREEを任意に配置できるからである。

したがって各ボールの番号を判別する必要はない(入った番号を判別するのは結構面倒なにおいがする)

実際に自動配置した様子は以下。

これは、我が操作したわけでもなく、はたまたおまかせオートをしたわけでもない。

画像データからこれをID化し、それをもとにあらかじめ蓄積した最適解データを取得し、それをuwsc側に戻してきて、その位置をクリックさせたのである。

しかしこのクリック動作、万が一クリックしたが向こうに反映されていないという可能性も考慮し、このクリックの動作の後、FREE配置可能個数が0となればうまく配置できたことになるが、そうでない場合は、配置しきれていないのでもう一度同様の動作を行わせるようにしている。ただしその際自身の置いたバルーンが誤作動しないように最適解配置位置の固定が必要である。

あとはこれらのデータをエクセルに反映し、さらにこれを3ゲームでできるようにし、加えてその精密性を何度も実験して確かめなければならない。

しかしここまで来たら、いよいよ実用化できる段階にまで来ている。

まあいつもFREE1個でHITせずの状態ばっかりなのでたぶん最適解配置をしても大負けすると思うが…。

そこのあたりはもっと後の話となる。

あと入った番号の順番も一応記入しておこうと思う。何か法則があるかもしれないし、はたまた録画の可能性ももしかするとあるかも。

とにかくたくさんのデータが必要なので、6BET3面で18BETを行い、PO70%だったとしても1回あたり5枚程度のロスなのでこれならかなりの試行回数を稼げる。

chkimgに再度挑む

なんかchkimgではうまく画像を読み込めないので、それを拡張しているchkimgxを導入することにした。

さて、我が行いたいのはFREEの設置である。

とりあえず最適解の取得は完了したので、これを座標指定してBTN関数でぶちこむ。

750枚を使ってＰＯ率やFREE個数の推移を検証

 約50ゲームを20BETずつ、3面で計60BETを行い、その様子を見た。

上野グラフは、各面ごとの配当数を表している。一律20BETなのでPO率を表しているといってもよい。(ただしスケールは違うので注意)

20という値を上回っていれば、PO率は100%を超えている、ということになるが…。

このグラフを見てわかることは、50ゲーム、すなわち150ゲームやっているにも関わらず、7個ラインはおろか5倍以上の配当が一度も出ず、星がワンダー数回分しか増えないというもの。全体としては総計3000BETなので、3000BETで通常ゲーム分の☆は0個、ワンダーチャンスはこの間に3回行われており、合計55WIN。

PO率としては50ゲームの区間でおよそワンダーなしが73%、ワンダーありが75%というものである。このPO率は、極めて悲惨というほかはない。

実際、設定PO率が90%程度であるらしいので、これは相当当たっていない、といえる。

具体的に言うならば、もし1万円で4500枚のメダルを購入し、1ゲームごとにビンゴバルーンに100BETずつ、計300BETしたとき、60ゲーム分、すなわち実機ならば1回あたり2,3分なので、2,3時間経過すると4500枚すべてを失う、ということである。

しかし我がやりたいことはこれではなく、この統計で山と谷をうまく把握する方法を得たいというものである。

そこで、ゲーム開始時に配置されるFREEの数とPO率の関係を集計したところ、相関係数は0.28程度で、これは相関がほとんどない、とみてよい。つまり最初に配置されるFREEの個数では、PO率を判定するのは難しいということになる。

一方、配置されたFREEに対するHITしたFREE(取得率と定義する)とPO率の相関係数は0.56もある。これはそこそこ相関があるということになる。

あと、各ゲームごとのPO率の推移をみると、BET数以上WINを得たときの次のゲームでBET以上を得られるのは、17回中わずか4回である。

なお、全体を通じてみると、51回中BET数以上の返却は、17回である。

まだ誤差の範囲であることを否定はできないが、やはり大きく当たった後は次の回でBETを下回るイメージである。

他にも、BETを下回ったWINの4回以内にBETを上回るWINが発生していることもわかる。

この辺りの考察は、まだ50回しか試行していないのでもはや確証性はないが、とりあえずこのような仮説を立ててみて実際にプログラムを動かして、だいたいの場合でうまく行っていればよいわけで、その精密性はここでは問題ではない。

例えば上記の結果から、以下のようなプログラムを組んで、普通にやる場合と比較してみるのもよいのである。

1.毎回5BET3面で賭け続ける

2,毎回5BET3面だが、BET以上のWINを得た場合、その次の回だけは賭けるのをやめ、

BET未満のWINとなったとき、BET以上のWINが出るまで賭けることを続ける

など。

とりあえずは、まずは最適解をコナステに打ち込むプログラムが必要であるから、ここから作っていく。

(いやしかしワンダー込みのPOが75%ではどうやってもこれ勝たれへんのちゃうか疑惑が浮上)

コナステに最適解を入力

 後は最適解をコナステに入力するわけである。すでに各マスの座標は定義してあり、念のためにマスの中心をクリックする、ということにしようと思う。

さらに、そのクリックが確実に行われなければならない。その確実性を高めるための方法の模索がこの記事でのメインとなるだろう。

以前実験したところ、コナステではクリックの動作をしているにも関わらず、クリックした判定にならないということがまれに発生する。

それを避ける方法は以下。

1,複数回クリック信号を送る

2,クリック状態の時間を延長する

このあたりをいろいろいじくって、完璧にクリック判定をしてくれるパターンを探ろうと思う。