予想PO率表示(3)

配当の期待値が、6~7球入賞後も表示されるように。8球後はそもそも期待値を掲載する意味がないので「---」で表示する。あと、以前のべた通り、すでに入っている番号は入賞済、という表記にしておいた。

上の画像は、6球終了時点での期待値をそれぞれの枠の右下に示している。
ここで注意すべきは、この黄色のバルーンの配置はあくまで5球後の最適と判断された位置であり、6球後に改めて最適の判断をしているわけではない。6球後にFREEを置けないという本家の仕様上、考える意味がないからである。
上の画像では右下あたりの盤面は4個ラインのリーチ待ちであるが、これが残り2球ともなるとずいぶん期待値が低い。
1~25の番号別期待値を見てもわかる通り、13,14に入ればかろうじて期待値が50%程度になるか、という程度である。なおまだ入賞番号は固定しているので7球目は7番に入賞するわけだが、この場合配当期待値はわずか21%である。
上記から見てわかる通り、FREE1個での配置ではもはやBET以上のWINは絶望的であることが分かる。
参考程度に、FREEを2個、3個、4個とした場合の6球終了時の配当期待値をのせる。

 FREE2個ともなると安定して等倍以上のWINが返ってくることが多い。

 FREE3個になるとBET×3倍程度も返ってくるようになったりする。
たしかアニマでは3倍か5倍かは知らないが、総額BETの何倍のWINを得るかでリザルト画面での効果音(無音、ピュリッ、テンジンジャーン)に変化が起こる。

FREE4個の場合、さらに配当の期待値は上昇し、例えばビンゴバルーン100BET×8面ならば総計800BETで、各番号の期待値は総額BETに対する倍率の期待値を示しているので、およそ5000~6000WINが期待できることになる。なお7と21番がよりよい配当を得られるとされているのは、7個ラインビンゴ成立によるもの。ただし、8面で平均を取られるのでそこまでずばぬけてこの2つの番号の期待値が高くなるわけではない。

さてそろそろ明日以降は、5,6,7球終了時の予想PO率の推移をグラフに表し、さらにゲーム終了時の配当率もグラフにしてみようと思っている。
もちろん5,6,7球と進むにつれて不確定性が下がってくるので、実際の配当率推移のグラフからずれにくくなっていくことが予想される。
どちらかというとこれの本領は実践モードである。もしこの予想PO率のグラフと、実際の払い戻し率のグラフがやたら離れていれば、それは操作疑惑濃厚である。

予想PO率表示(2)

番号モードのときのみ、各番号に入った場合の期待値を算出した。

例えば9番に入った場合は、今後の8面全体の払い戻し率として5.8倍程度が期待される、ということである。つまり、番号の右にある%の数字が高いほど、熱いナンバーである。

まだプログラムは組んでいないが、現時点で8や11は数値が小さいが、これらが入った後はそれぞれ11、8の数字が2段目2列目で7個ラインを形成するため、それらの番号の%の値が急上昇するはず。

なお1~5が0%なのは、すでに最初の5球でINしているため、期待値の総和の対象に入っていないということである。ただちょっと0%だと意味合い的によろしくないので、「入賞済」などにして対応予定である。

せっかくなのでアニマップにおける星獲得期待値も算出してみようと思ったので、それを実装。

%の上に小さく表示されているのが、星の獲得指数である。平均的な星の1面あたりの獲得率は通常、かなり低いので、平均星獲得個数に1000をかけたものとしている。
例えば×1と表示されていれば、それは星獲得平均個数は1/1000なので、平均的に1000回その盤面が出てようやく1個程度の獲得ということである。
左下はビンゴバルーン7個ラインによる星7個と、30倍以上の星3個が平均的であるというある意味直感と似た結果を出している。もちろん25倍で終わって星9個の場合もあるし、50倍を超えて星12個の場合もある。

明日からは、いよいよこの後の3球を実際に抽選させたり、ゲームを複数回行いその履歴をグラフにして表示したりすることを考えている。

予想PO率表示(1)

最適解のもとでの精密な期待値を、ウディタのほうでも計算させて表示させた。
…と1行だけ書いているが、実はこれが意外に時間がかかったりする。

各盤面に右下に色付きで書かれている数字は、もちろん平均払い戻し率(以後PO率と呼ぶ)であり、100%=1倍というわけで、この値が100%を超えれば等倍以上の配当が期待される。
とはいえ、例えば0倍が99%、100倍が1%であってもこの期待値は1倍、つまり100%であるので、値はあくまで目安である。長いこと同じ盤面で試行を繰りかえせば、その期待値に近づくが。

実際にうまくいっていることを念のため確認すると、左上の盤面はすでに3個ライン3が成立しており、これは2.5倍である。しかし平均払い戻し率が7.7倍であるのは、3個ラインがほかにも成立しやすいからである。その右の盤面は普通に5個ラインのオッズアップで400%以上は確定。そこに新規の4個ラインでの6倍、オッズアップ+1での6倍などの確率が上乗せされて553%となっている。

そしてやはり、FREEの個数が少ないと一気に期待値が下がってしまうということもこの8面を見るだけでも何となくわかる。
ビンゴバルーンで+FREEが最初に1個しか出なかった場合の期待値は40%少しつすでに判明しているので、8面全部+FREEが1個とかだと相当げんなりする。

とりあえずこれ以外にも、各番号ごとの期待値も別に計算させてある。これを右側に貼り付けようと思っている。番号を入力しない実践モードでは、これは必要ないというか不可能なので、何か別の機能でもつけようかと思っている。理論上の+FREE獲得個数と実際の獲得個数の比較によって、入ってほしい番号へのアニマ特有の操作があるかどうかを見極める材料にもなったりして。


余談だが、なんかこういう階級別に色付けする視覚的効果を付与するのが大好きだったりする。そして求めづらい数字がぽんっとプログラムの後で出たときの安堵と快感。
これはあのいわゆる極限を求める問題で答えが0や1、無限大以外に収束した場合の感覚と似ている(変態)

HIT処理全般(2)

謎の不具合が発生したがその原因は組→ID変換においての第4項のシグマ内の、単純乗算との混同の勘違いによるものだった。何を言っているかわからないと思うので、これはおいておいて、とうとう最適解をしゅっと与えるプログラムが完成し、それを視覚化した。

赤色が入賞バルーンで、黄色が最適解(平均払い戻し率最大)を与えるバルーンの配置である。なお、上の段から順に配置可能FREE数は4,3,2,1とした。
おまかせオートなどとは違い、しっかりと7個ラインや、5個ライン×2、そしてオッズアップの配置、さらに7個ラインリーチまでも考慮されていることがわかる。
本来は最適解の後に払い戻し率のデータがあったが、よく考えればここから1140通りの残り3球を考えてオッズの平均をとればいいだけなうえ、そもそも最適解をすばやくみつけることが重要なので、この辺りは気にしなくても良い。

なお、オッズアップの位置はいわずもがな赤色バルーンのあるところならばどこでもよい。一応上のほうから順番に、赤色の部分をオッズアップとするようにしているが、上の画像では下のほうに虹色が発生しているのは、これはかつて行った最適解探知での同一配置を得るための回転や対称移動を行った名残である。例えば右の列の上から3段目は、時計回りに半回転すると、組{1,6,13,15,23}に相当して、このとき若い番号1にオッズアップを割り振る。それをもどして(半回転させて)1が25の位置になっているので、下のほうに虹色が来ているわけである。
このようなことをする理由は、以前も相当これに悩まされたが、処理速度の問題である。
この1パターンを探知するのに、FREE4個ともなると相当な時間がかかり、CPUをフルにして何週間かかけることでようやく全パターンを得られるわけだが、それでも回転や対称移動での同一配置をかなり使っての結果である。

だがこれは逆に言えば、それだけ普通ではやりづらい試行であり、その分このデータの価値は高まる。事実、ビンゴバルーンの最適解について論じている人はこちらの知る限りいなかったのでそれだけ難しい(時間がかかる)ということだろう。

ここからは、各番号により配当期待値を出していってそれを色分けしたり、その後のランダム抽選での配当の偏りのグラフなどの作成も考えており、右側の余白に何を作るか楽しみである。


おまけ:ID→組への変換のプログラムの一部

演出がほぼ不要なのでスナック感覚でツールを作れるが、このあたりはノートにいろいろ書いて考えた。

ID→組への変換

さすがに頭の中で構築するにはあまりに難しいので、実際にID3000から組を導出する手順を考えた。
まず、組{1,2,3,4}…{1,2,3,25}までは、22組存在する。
つづいて、{1,2,4,5}…{1,2,4,25}までは21組。以下同様にして{1,2,24,25}までの組は
22+21+20+19+…+1となり、あのよくある等差数列で253個存在。

この後2つ目の番号を3に変えて{1,3,※,※}の形が何個あるかを調べると、これは21+20+19+18+…+1個存在する。

つまり、最初の番号がkであるものは、1を23-k個、2を22-k個、3を21-k個…と足し合わせたものになりこれは全部で(23-k)(24-k)(25-k)/6個存在することになる。ちなみにこれはk+1~25の数字を3つ並べる組み合わせで、25-kC3の値と一致する。

この25-kC3の値をk=1,2,3,4…と足しわせていくと、IDより大きな値になることがある。
例えばID3000の場合、k=1では2024。k=2まで足しわせると2024+1741=3765となり、超過。
つまり、k=2のところでこのID3000が存在していることになる。kの定め方より、ここでついに最初の番号が2と決まる。

この後、2番目の番号を探るために、とりあえず最初の番号が2のものの組み合わせのうち、何番目かを探る。そのためには3000から2024を引く。判定には3765を使用していたので、いましがたたした1741を再び引けばきれいにひとつまえの2024の値が残る。プログラムでも実際に[全体和]-[新規総和]みたいな感じでこれを行っている。

{2,※,※,※}の組で3000-2024=976番目であることがわかる。
この後、{2,3,4,5}…{2,3,4,25}は21個、…と再び同様のことをしていく。
ただし、この21個という値は、最初の番号が2だから21になるのであって、最初の番号がkの場合は23-k個になる。
21+20+19+18+…1は231であり、次の{2,4,※,※}は20+19+…1で210、{2,5,※,※}は190、{2,6,※,※}は171、{2,7,※,※}は153となる。これで和が955となる。
そして{2,8,※,※}は136通りあるので、2番目の数字は8と決まる。

そして3番目の数を同定するため、976から955を引く。すると値は21である。
{2,8,9,※}は16通り存在する。よって17番目は{2,8,10,11}である。
求めたいのは21番目なので、{2,8,10,15}となる。

以上より、ID3000は組{2,8,10,15}となる。実際にプログラムに3000を代入してもこうなることを確認。念のためにID1とID12650でそれぞれ組{1,2,3,4}と{22,23,24,25}が返されることを確認した。

なので組→IDよりID→組のほうが、少々プログラムは面倒になる。
…が、意外とウディタでも70行足らずでいけることが判明。

しかしこれ、4つの場合にしか適用されないので、これとまったく同様の手法を3つ、2つでも作っていくことになる。1つはIDがもはや組そのものなので操作は不要。

ウディタでのIDと組の相互変換

ここでやりたいことは、組{1,2,3,4,5}をID1として、組{21,22,23,24,25}をID53130とするような辞書式組み合わせ(重複なし)を考えるが、この組→IDとID→組の変換をウディタでやりたい、という話である。

過去の記事を見ると、組→IDは記号C(コンビネーション)とsumで表せる。

もちろんウディタにこの機能はないのでループを使って処理することにする。

シグマでよく使ういわゆる「k」的なものを変数として使って、これを利用して和をどんどんとっていく作戦である。難しそうに見えて実は難しくない。

以下はそれをウディタ用にアレンジしたもの。

3番目のIDが小さいことから、おそらくあってそうな雰囲気。

確かめるためには強制的に1,2,3,4,5マス目HITになるように数字シャッフルをしなければよいが、あとで分かるのでここはチェックはしないでおく。

以下はID

30769 -->[ｺﾓﾝ10/78行]
2764 -->[ｺﾓﾝ10/78行]
1803 -->[ｺﾓﾝ10/78行]
24768 -->[ｺﾓﾝ10/78行]
29065 -->[ｺﾓﾝ10/78行]
35402 -->[ｺﾓﾝ10/78行]
30604 -->[ｺﾓﾝ10/78行]
5776 -->[ｺﾓﾝ10/78行]

昨日、可変DBに最適なマスの位置をウディタに入力したので、あとはこのIDから可変にあらかじめ格納された最適解を示すID(1~1140)を呼び出し、それを5つの組に直せばあとは黄色バルーンを視覚的に配置するだけである。

なお、この可変DBへの入力、ウディタでは10000個しか最大でうつせないため、CSVファイルをぶつぎりにする必要があった。この作業も意外にいろいろと問題があって時間がかかった。

可変DBの値の呼び出しについてだが、例えばID12345の場合、

可変2のID2344番目にその最適解が眠っている。この2と2344の値は普通に10000での商にプラス1したものと、12345を10000でのあまりにマイナス1したものなので、ここの変換は一瞬。

次の記事ではいよいよ黄色バルーンを最適解として配置するところまでいく。

HIT処理全般(1)

とりあえず番号1,2,3,4,5,6,7,8に入った場合に赤色バルーンっぽくなるようにした。
加えて過去の自作アニマロッタからのビンゴの定義データを適用。これにより素早く倍率計算まで持っていくことができる。

ちなみにフリーを置いていないと上の状況では配当は0WINである。どこかで計算したと思うがFREE0個の場合のPO率はかなり低い。

なお、この赤色のバルーンは実際に領域を定義して、その領域内をクリックすれば赤色マスを置けるようにし、もう一度クリックすればそれを取り消せるようにゆくゆくはする予定である。
黄色バルーンについては、これは最適解を与えるためのものなので、機械側であらかじめ取得したデータから探って自動で黄色を配置する。
オッズの期待値の計算を行うのは、赤色バルーンが5個置かれたものから適宜、ということにする。ただ、この5つの番号の組み合わせをCSVファイルのIDに合うように5変数→1変数の変換が必要である。
例えばマスの組{1,2,3,4,5}からば1番目、{21,22,23,24,25}ならば辞書式で53130番目。
あとCSVをウディタの可変に入力していくが、悲しいことにウディタはデータを一つのDBで10000しか保有できない。
我の用意したデータは53130*2個のデータが各FREEに対して存在するので、
結局214520*2個のデータを可変に代入する操作が必要になる。
53130*2のデータを収容するのにDBが6個いるので、結局このデータは可変DBを24個ほど占有することになる。
しかしウディタは最初の10000個しか読めないため、以前作ったデータを10000個ずつこまぎれにするという作業まで発生。
これにより最適解データを可変側に導入するまで結構な時間がかかると思われる。