予想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個ずつこまぎれにするという作業まで発生。
これにより最適解データを可変側に導入するまで結構な時間がかかると思われる。

ビンゴバルーンの復習

我の手元にあるデータは、CSVファイルであり、例えば1行目には595,5.095614などと書かれている。右側の数字は払い戻し倍率の平均であり、つまりは何度も試行を行うと5.1倍程度の払い戻し率に落ち着く、という意味である。左の595というのは配置を意味している。

実はこのデータはFREEを4個配置できるという場合であり、オッズアップのようにすでにバルーンが配置されているマスにも黄色のバルーンを配置できるので25C4通り存在する。
その場合の数を辞書式にソート(例えばID1は最初の組み合わせで、これは1,2,3,4の位置にバルーンを配置)した順番が左に記されている。

これの変換の方法はずいぶん前なので作成した式を忘れたが、まあすぐに復元できるので良い。

まずはピクチャを用意する。これは自分で作成したただの●でよい。
縦7マス、加えて8面のようにするため、縦は28マス分の●を生成する予定。
たしか画面サイズは720であったから、一つの●あたり25ピクセルで25*28=700であるのでこれがよい。

地道に座標して以下のようになる。

まだまだしょぼいが、そもそもこのツール?は演出を目的としていないのでこれくらいでよい。
ここからは、番号モードとマスモードを別々に作っていこうかと思っている。
番号モードは、おそらくあまり使わないが、入ったナンバー5つで自動で最適解を探索するというもの。もちろん200マスも入力などしていられないので、これは実際にランダムに番号を振ってイメージトレーニングの一環としてやっていこうと考えている。
こっちのモードでは、せっかくなので次の番号がどこに入れば払い戻し率の平均がどれくらいかも表示したいと思っている。場合の数は20C3で1140通りなので、これならすぐに処理が可能と思われる。実践でないし。それで期待値別に%を色付けして、どの番号に入るとどれくらいの払い戻し率かを視覚化する。わくわくしてたまらん(変態)

通常モードは、普通に5球終了時にすぐに最適解を表示するシステムを考えている。
ただしこの場合、番号別の期待値は計算できない(番号を定義していないため)ので、これ以降の更新は行わない。
ただ、実際のWINとの乖離などを調べる指標として、ゲーム終了後の払い戻し率(理論)と実際のWIN率の関係を示したものなどが準備できればこれも面白いだろう。

まずは番号モードを作って、番号別の期待値を計算するモードを作ろうと思う。
バルーンの列などの定義は、いわずもがな過去作成した自作アニマロッタのプログラムをこちらに転用予定である。

とりあえずピクチャだけ配置。

…がしかしまだまだ先は長い。

再開の恐れあり

なんとか落ち着いてきたので、タイトル通り再開の恐れがある。

この期間中にアニマアンケートなどがあったらしいが、各コメントに200文字以上くらいの感想を書き込んで1万文字くらいになったかもしれない我のアンケートはなぜか向こうに送信できず残念であった。

あのアンケートから、アニマロッタ6ではおそらくフレンド機能でなんかいろいろ解放とかがあるのだろうと予想がついたので、現時点で自作アニマロッタをよいところまで持っていっても最新作の置換によってその威光?を失うと踏んだため、以後は実用的なものを作成しようと計画中である。

その中でもおそらく最も気になるのが、以前mathematicaで何十時間もかけて解析したビンゴバルーン最適解法である。この「最適」は、単にペイアウト率を最大にする、ということにしており、りんごの獲得や抽選の偏りは考慮していない。

そしてそのビンゴバルーンを8面で行った時、ユーザー側がセカンドロッタまで入ったマスを入力することで、最適な位置及び各面での払い戻し率を計算させようかと考えている。

この最適解を得るためには、当たり前だがすべて5球分入力し終えてから処理に入るととても間に合わないので、半年くらい前にPCにやらせまくった例のデータを用いる。

とはいえ、現時点では何もできていないので、以上のことは構想であることに注意。

今からその「ビンゴバルーン最適配置」をいつも通りウディタで作成していこうと考えている。これに関してはそこまで時間はかからないため、数日で出来上がるだろうとみている。