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率は以下。
上記配置可能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ゲームにするのみである。
そしていろいろあって、ようやく完成。
我のUWSCのプログラムへの慣れがなさすぎるせいで500行程度に膨れ上がってしまい、なんかループ対応も汚い。あとでどれとどれがつながっているか見づらい。
おまけに表現方法をあまり知らないので原始的な関数の組み合わせになってしまっているし。
何よりすぐにゲーム画面がかたまるのがもういやでならない。
しかしここまで来れば、我の描いているマクロツールにずいぶん近づいたことになる。
明日にはもっといい線行っているかもしれない。
かなり苦戦したが、なんとか最適解を実際においてくれるようになった。
この間、赤バルーンの強固な判定を得るにはどうするか、シンキングタイムをどう見分けるか、FREEの配置可能個数をどう判別するかなどかなりいろいろ試行した。
その結果が↓。
なんかchkimgではうまく画像を読み込めないので、それを拡張しているchkimgxを導入することにした。
さて、我が行いたいのはFREEの設置である。
とりあえず最適解の取得は完了したので、これを座標指定してBTN関数でぶちこむ。
約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,クリック状態の時間を延長する
このあたりをいろいろいじくって、完璧にクリック判定をしてくれるパターンを探ろうと思う。
ここまで書いているのでなんとなくわかると思うが、我はアニマロッタ初心者などではない。
いずれはとある大きな野望を達成しようとしているが、ここではそれは言わないでおく。
題名にあるように、チェーンボンバー大辞典というものの存在を我は知っている。これを作ったのはみそodenさんで、我がすごいと思う人物の一人である。
彼はアニマロッタ初代、2のころにボール落下位置を予測してアニマロッタで大稼ぎしたり、このようにプレイヤーに有利に働くツールをいろいろ作ったりした大物である。たしかKACに出場までしたという人物である。
我がこのチェーンボンバー大辞典を目にしたのはアニマロッタがまだ初代だったころ、すなわち中学生くらいである。あっ年齢がばれるな…
実際に使うことはなかったが、これはすごいサイトや！と感嘆した記憶がある。
ただ、残念ながらアニマロッタは、まだ確定していないランダム要素が大きすぎて、チェーンボンバーの理論PO率を正確に推量することはできない。なぜなら番号が上に偏ったり、爆弾が1~2個発生したりするからである。しかしそれでも画像認識を用いてあそこまで仕上げたのはやはり非常にすばらしい。我も一度会ってみたい。
なお我のビンゴバルーンの理論PO率は、一応3個ライン7個が判明しておらず、これをたぶん50倍と勝手に仮定していることなど、非常に些細なことを除けば、全パターンから算出しているので極めて正確である。しかし、わざわざ自作のツールを作ってアーケード版でやっていると、周囲から白い目で見られそうな気がする上、なによりそれをしていても楽しくないという問題点がある。
しかしコナステならば、KMPやスターを稼ぎつつ、5BETでも放置しながら延々と行え、かつPC上なのでマクロ操作ができる、という非常に大きな利点を持つ。
マクロを実際に組み込むのは、3日前に初体験でいろいろ苦労も多かったが、とりあえずなんとか機能した。
チェーンボンバーは、実は一応演出付きで自作している。
ちゃんと本家になるべく似せるように、爆弾の出現位置も下4段などにしている。
ただあれ、リーチ処理を各球数ごとにやると処理が重くなるという問題点がある。しかし本家は一瞬でなめらかにリーチを表示する。これはあのゲーム画面以外に何か別のPCがあるやろ…と推測した。
プログラミングは独力で学んだ。というより、RPGエディターでRPGを作っているうちに自然修得した。とにかく何かを作るのが好きなのは小学校のころから変わっていない。
とうとう最適解設定までこぎつけた。
ちゃんと実際の画面を見ても4,6,7,11,21のマスに入っていることが分かる。
しかしなんか、最適解を与える2というものが不穏。
これは3ではないか、と思われるが…。よく見てみると、3の位置(リーチ12となっているところ)に入れると、3個ラインが完成し、さらにもうひとつ3個ラインのリーチができていいように見える。しかしよく考えてみてみるとその左の8番と書かれているマスにバルーンを配置したほうが、3マス目(12番にHIT)すれば3個ラインが一気に2個完成し、かつ14マス目(14番)にも4個ラインのリーチが発生する。したがって2マス目(8番)に配置するのが適当、という判断は正しいと推測できる。
このように、一見最適と見えるような場合でも、そうでないときがあるので、そこのところのPO率を理論上最大にすることにより、PO率の底上げを図るのである。
せっかくなのでほかにも実験してみる。現時点では配置FREEは1個としている。
パターン1
さて、いよいよ2ndロッタまでのID変換が行われた(未確認)
ではいよいよ、それをエクセルのセルの指定の引数としていく。
まず、とりあえずFREE1個の場合で機能するかどうかを実験する。
この配置可能FREE数の取得は、置けるFREEの数の数字をやはりpeekcolorなどで判断するかが必要だが、それは時間がかかりそうなので後回し。
一応FREE1,2,3,4個で分岐するものは作っておく。
ところで4つの分岐ってどうすんねん…。
どうもifbとelseifを使えばいいらしい。初めて知ったわ…。
あと行は100で、セルをAを指定したいときは+A+100とかいう文字列の結合表記を使うらしい。
とうとう、指定したエクセルのセルの値を返すことに成功。
このセルの指定は後々していく。今のところ、以下のようなプログラムとなっている。
id = GETID("コナステ クライアント ver.1.0.0")
Hnd = GETCTLHND(id, "CloudClientGameWindow")
DIM baloon[] =0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
DIM Xaxis[] = 442,411,442,473,380,411,442,473,504,349,380,411,442,473,504,535,380,411,442,473,504,411,442,473,442
DIM Yaxis[] = 88,119,119,119,150,150,150,150,150,181,181,181,181,181,181,181,212,212,212,212,212,243,243,243,274
ACW(id,0,0)
while true
for a=1 to 25
x=Xaxis[a-1]
y=Yaxis[a-1]+21
red=peekcolor(x,y,COL_R)
blue=peekcolor(x,y,COL_B)
if red > 99 AND blue < 99 THEN baloon[a-1]=1 ELSE baloon[a-1]=0
next
sleep(2.0)
DIM list[]=0,0,0,0,0
i=-1
for a=1 to 25
IFB baloon[a-1] = 1 THEN
i=i+1
list[i]=a
ELSE
i=i
ENDIF
next
c21=list[0]
c22=list[1]
c23=list[2]
c24=list[3]
c25=list[4]
c26=c21-1
c27=c22-c21
c27=c27-1
c28=c23-c22
c28=c28-1
c33=c24-c23
c33=c33-1
c30=0
c29=0
for a=1 to c26
c29=c29+1
c31=25-c29
c31=c31*(24-c29)
c31=c31*(23-c29)
c31=c31*(22-c29)
c31=c31/24
c30=c30+c31
next
c29=0
for a=1 to c27
c29=c29+1
c32=c29+c21
c31=25-c32
c31=c31*(24-c32)
c31=c31*(23-c32)
c31=c31/6
c30=c30+c31
next
c29=0
for a=1 to c28
c29=c29+1
c32=c29+c22
c31=25-c32
c31=c31*(24-c32)
c31=c31/2
c30=c30+c31
next
c29=0
for a=1 to c33
c29=c29+1
c32=c29+c23
c31=25-c32
c30=c30+c31
next
c30=c30+c25-c24
oExcel = GETACTIVEOLEOBJ("Excel.Application");
value1 = oExcel.ActiveSheet.range("J53130").value;
MSGBOX(value1)
sleep(100.0)
wend
あとは、このJ53130となっているところ(ちなみにこのセルは、位置21,22,23,24,25に赤バルーンが生成したときの、FREE4個が配置可能な場合の4つ目の配置場所となっており、この値は25である。なおその他は9,15,20という番号になっている。
これは、3個ライン3個をとり、かつオッズアップで倍率5倍を確定させているということになる。オッズアップは本来若い番号から入れていく規則であるが、以前のべた通りこの53130通り目は1通り目の180度回転で同一となるため、各マスの置換を考えてそれに基づいている。1マス目は180度回転すれば25であるから、オッズアップの番号に25が組み込まれているのである。もしそうしなければこの53130通り目にもPO率を厳密に計算する処理が発生してしまい、効率が悪い。1と53130通り目が「同一」であるかどうかの判定は以前にやっているので省略。ただそんなに簡単な話ではない。
ではいよいよ、アニマロッタで指定した赤バルーンの位置を取得し、それ先ほどの対象セルとうまくかみあわせて、最適解をたたき出し、そこからコナステに入力する。これを行っていく。
以下の画像のように、IDを順番に並べたときの最適解の位置データが明確に示せるようになった。これをするためにウディタ側でプログラムを再構築し、現時点では53130個の出力と並行して記事を書いている。
この参照は、おそらくUWSCのエクセルファイルを参照する関数があったと思うので、それが使える。IDはすでに先ほどの記事で述べたようにこのCSVファイルに都合の良いように変換済みである。
するとあとはその得たデータを実際にコナステに組み込む…というのが現在の状況である。しかし果たしてそう簡単にうまくいくか…。
そうや…最適解のデータは重複のない辞書式組み合わせの昇順に一次元のＩＤとして並んでいるんやった…。つまり、このＩＤを配置すべき組に変換する必要がある。
悲しいことに、これを行うプログラムはmathematica上で実行していた。そしてそのmathematicaが現段階では使えないという悲劇。おまけにエクセルもライセンス云々でオンラインのアレでないと使えない。
なんとかエクセルに{1,2,3,4,5}をID1として、{21,22,23,24,25}をID53130とする変換を簡潔にやってくれるコードは存在しないのかなと思っている。
まてよたしかウディタにはＣＳＶファイルとして結果を放出する機能があったはず！
そしてウディタにはこの1次元と5次元の相互変換を行うプログラムを組んでいるのでそれの流用ができるやん！
そのウディタで何をやっていたかというと、ビンゴバルーンの最適解の視覚化。
普通にやるならこれでいいが、やはり自動化を目指しているのでこれでは物足りない。
なお我がウディタで初めてＣＳＶ化できるコマンドを使ったのはゴブリンが提供するお楽しみ広場。あの当時はわけもわからずなんとなくしょぼいＲＰＧを作って自分で遊んでたらしい。中学校入って1年くらいと思われる。
ＣＳＶの書き換えはライセンスがないためできないが、ウディタ上で計算してそのデータをＣＳＶに移動させることはできる。そして結果はエクセルオンラインのほうに書き込めばいいし、これは最適解を求めるというよりは結果を記録するという少々逸脱した話なので後回しでもよい。
ちなみに、以前作ったビンゴバルーン解析プログラムはウディタ製で、以下。
いよいよ、所定のプログラムを組むことにより、以下のような場合においてバルーンの位置を取得することができるようになった。例えば以下の場合では、マスの順番の定義に従って、9,10,12,15,18という5つの値をリストに格納している。
まずは、画像認識が必要である。そして幸いなことに、アニマロッタの画像認識はかなり楽である。というのも、あるマスにバルーンがあるかどうかは、そのマスが赤っぽいかどうかで判別がつくからである。とはいえ、それを実践するのは一瞬ではない。
そこで、ちょっと練習を兼ねてみる。
下のような画像を作って、ちゃんと色の取得が行われているかをチェック。
//---シャッフル関数 |
Procedure shuffle(var list[]) |
Dim n = length(list) //配列の要素数 |
Dim i, r, tmp |
for i = 0 to n -1 |
r = random(n) |
tmp = list[r] //ランダムに選ばれたr番目の配列の値を取得 |
list[r] = list[i] //配列i番目の値をr番目に入れる |
list[i] = tmp //入替え完了 |
next |
Fend |
