11-11 りんごの色実装

これまでは延々と緑リンゴでやってきたが、当然後々赤や銅などのりんごを使うのは明らかだったので、それ用にプログラムを組んでいた。
そして、ちょっと手を加えて、ついにりんごの内部値別による色の描画に成功。
以下のように、りんごに色バリエーションが発生。
別にどうでもいいが、銀リンゴの内部値は一律1000,金リンゴの内部値は2000である。
なので全部この価値の銀リンゴを取った場合、たぶん6500~7500くらいのワンダーチャンスになって6,5,4ラインは7でわると900~1100くらいなので銀リンゴ、0ラインは2100~2500くらいなので金Lv1あるいはLv2くらいのものになる。

次はリザルト画面でのりんご実装や。

11-10 りんご処理実装ほぼ完了

ついにナインビンゴまでりんごの獲得処理を施し、獲得していればフラグ1を返し、あとは内部値を読みにいってリザルトで表示するだけとなった。
ただ、まだ赤リンゴとかのピクチャのいい画像がウェブ上などから探す必要がある。
金リンゴに至っては1~MAXって、これは楽ではないで…。

今日はりんごのピクチャの地道な探しと削り作業、そしてワンダーステップへのりんご移動(放物あるいは円軌道の一部にするか悩んでいる。放物移動なら傾斜度(2次の係数)を指定して2つの座標を指定すれば、当然一通りに定まる。(3元連立一次方程式)
円軌道なら、もちろん2点だけではさまざまな軌跡が発生してしまい、例えば半径を十分に大きくとるとほとんど直線になってしまう。しかも円軌道の場合、cosとsinを使うことになりわざわざそんなことせんでも放物線でええわ…ということで、たぶん放物線にする予定。これによってようやく左上にりんごが出てくるようになる。
なんとなくアニマロッタっぽくなってきたやん。

11-9-1 サンダースマッシュりんご配置

とうとうサンダースマッシュにもりんごが配置されるように。

これにより、9ゲーム分のりんご実装(シングル除く)が終了。
たぶんシングルのこれを実装しようとなるとこれまた結構時間がかかるので省略。

今はこれら緑リンゴの内部値は一律100としているが、いずれはBETと連動させる予定。

今後は、ナインビンゴモードでのりんごライン配置を行い、そしていよいよリザルト画面でのりんご描画、そしてこれまで飾りだったワンダーステップについにりんごがピシューンするときがくる。

11-8-1 ハッピーフラワーりんご配置完了

予想通り、ハッピーフラワーのりんご判定は非常に簡単。特にいうことはない。
8月中には9ゲームのりんごつき処理がほぼ完成するのではないかと思われる。

実はピクチャ番号の関係上結構上書きされやすい位置にあるが…まあいい。

そろそろりんごの音をつけてもいいかと思っている。りんご系統の音は、
BET時のトロンバダリアンとりんご設置時のセッチャンとりんご獲得の音くらいでいいので。羽りんごとか虹りんごとかは、獲得コモンイベントにこれら9つのゲームはすべて集約されるのでそこをいじるだけとなる。

11-7-1 アニマドロップりんご配置完了

さらっと書いているが、実はこれでも数時間いろいろやっている。
結構細かい演出などで問題が発生するもんで…。内部的に正しく動くだけではだめで、演出も本物に極力近づけるので、よりプログラムは難しくなる。
そういうわけでアニマドロップにりんご1個の場合、りんご獲得システムを実装。

これでようやく7ゲーム分のりんごシステムができあがった。
残るはハッピーフラワーとサンダースマッシュ。
サンダースマッシュはりんごの挙動が目に見えてわかりやすく(デバッグしやすい)さらにりんごの挙動も単純(移動のみ)なので、やりやすい。
ハッピーフラワーは完全に固定で、しかもそのマスに花が咲いているかという非常に簡単なシステムなので、ハッピーフラワーがこれらのゲームの中では群を抜いて楽勝であるといえる。
これは明日中には全ゲームりんごシステムが完成か…?
しかし明日からちょうど後期がはじまって朝から晩まで予備校や…。
今週日曜日は3日ぶりの模試やし、あまり猶予がない。
10月からは大学が週4以上でたぶん入るので混沌状態になるとみられている。

11-6-3 アニマツリーりんご配置完了

なんかプログラムがごちゃごちゃしている気がするがまあええか…。
手直しするくらいなら一から作り直したほうが早い。ほぼほぼ思いつきで作っていってそこから行を加えたり修正したりするスタイルなので。
なお適当に組むため猛烈な量のバグをこれまで経験してきたが、それらはたぶん全部解決できると思う。ていうかそうしてきた。
座標定義とか実際に定義したものをゲーム起動させて見比べて…とマスの配置からそれはそれは地味な作業がひたすら続いている。
今回もりんごの配置座標がマスの中心のy座標から70を減じたものであることは、やはり細かく修正を加えていってしっくりきたときに70だったわけで。
ここで注意するのは、なぜかウディタでは鉛直上方への進行がy座標の減少につながる、ということである。例えば画面の上端はy=0である。

そしてようやくアニマツリーのりんご配置プログラムがたぶん問題なく動作したと思う。

今日はマーク試験だったのでちょっと頭がつかれている。
なかなか平均9割はいかんわ…8割は問題ないが。
数学だけ1A,2Bともに満点という。はあ

11-6-2 内部処理は完了

一応マス更新でりんごを表示し、そのマスでりんごを獲得できるようになるゲームは普通に問題なく動作するが、まだフロア上昇時りんごがピシューイといいながら下降(実際はツリーを登り、りんごの絶対位置が固定のため、相対的に下降しているに過ぎない)するところがまだ作れていない。

ちょっとツリーはまだあらすぎる…。
あっりんごのマス黄色になってないやん。まあこれはあの変数に2を代入するだけなのでまたやるとして…。

なお先ほどのべた処理は、上昇中はただピクチャとして移動するだけなので結構すぐに終わる…かもしれない。

いずれにせよ、もうそろそろアニマツリーのりんご処理も終わりを迎えようとしている。
そうすると、あとはドロップ、フラワー、スマッシュ、そしてナインビンゴのりんご処理である。
いよいよワンダーチャンス実装の時が徐々に近づいてきた。

11-6-1 ツリーのりんご初期配置

ピクチャ上書の関係上、切り取ったピクチャを使っていたのをオール、シングル、ナインモード用のピクチャに変更しなおし、ツリーの各階層を再構築。まあここはいいとして、
とりあえず現在階層より0~6階層上にりんごが出現するように設定。
7~8階層上にりんごが出現しないのは本家と同じにしてある。
もちろん同じマスにりんごが重複することはない。同じ階層に出現することはあるが。

さて、まずはりんごの描画が必要なわけだが、当然ながら現在階層より上のりんごは見えない…が、オッズ表のところに小りんごが配置される。
ただ、それだけでなく、マスの上にもりんごを配置し、かつそのマスは黄色になる必要がある。このように最初から一筋縄ではいかない面倒さを我は知っていたため、これはそう簡単にはいかないとかんがえていたわけである。ただ、できないはずはないのでとりあえずやっていくことにする。

とりあえず初期配置はできるようになった。
ここから、HITによるりんごGET処理と、後はフロア移動でピクチャの移動などを行い、4F以上にあるときの処理を行えば完成となる…がこれまた小一時間かかるだろう。

11-5-1 ハニーエイトりんご配置完了

ピクチャに空きがなくてしょうがなくりんごとハチが重なった時の背景の黄色のエフェクトを割愛せざるを得なかった。
そうこうして設定していたが、ふと見ると…。

りんご増殖してるやん…。なんでや
なんでかよくわからん。…と思われたが、どうも開始時連荘処理は1回ということでフラグをこれが起動したら1にしていたが、そもそも起動していなければ最後に起こってしまうという問題だった。
よって修正して完了。ここまではええんや…。
次のアニマツリー以降残り4ゲームのうち、アニマツリーがたぶん難関なほう。
これで9ゲーム中5ゲームにりんごの実装がシングルモードの挙動を除いて終了したことになる。

11-4-1 ビンゴファームりんご配置完了

大変になるかと思われたが、ちょっと工夫をすることにより結構楽にりんご判定を取得できた。ヒントは数列…?

11-3-1 ビンゴガーデンりんご配置完了

順調に、ビンゴガーデンでもりんごの達成要件を定義。
まあこれは新たにラインを示すピクチャを作る必要があったが…。

とりあえずこれで3ゲーム分終わった。残り6ゲーム。
次のビンゴファームはたぶん簡単。
ハニーエイトも簡単。これはりんごのマスにはちみつがひろがったときにりんごを消去しておかねばならないことに注意。
アニマツリーもちょっと考えればできるはず。ただアイテムの部分は黄色になるので、これをどうするかは注意が必要。
アニマドロップとサンダースマッシュは一緒に動くピクチャであることに注意すればよい。ハッピーフラワーは非常に簡単。

これらが終われば、リザルト画面で左上に作ったワンダーステップへのとりこみ作業を定義していく。そうすることでようやくワンダーチャンスの制作に入ることができるわけである。しかし28,29日はマーク試験、今週日曜日は模試と猶予がない。残念。


余談:現在コモンイベントが746までいっている。途中に空白がたまにあるが。
みじかいものは10数行だが、やっぱりHIT処理などゲーム部分をなすものは数百行にのぼるものばかり、これが数百個あると思われるので、やはり50000~100000行はいくのではないかと思われる。しかしこれでもまだまだ本物には程遠い。
せっかくなので、どんな感じのプログラムかちょっとスクリーンショットをはりつける。

こういう感じで、だいたいのコモンイベントにびっしりと組み込んである。
アニマロッタっぽいものを作るのは、そこまで単純明快でウディタがそういうのに向いている…というわけではない。地道な変数処理とピクチャ移動などの組み合わせによってなしえているのである。

11-2-1 チェーンボンバーりんご配置完了

前回ビンゴバルーンでもろもろの処理をやっていたので、2ゲーム目からはそこまで何時間もかからずに実装できる。以下のようにりんごが落下しりんごをGETする。

3000BETなのに緑りんご、とかはつっこんではいけない。
りんごの画像でよいものが公式サイトを利用したこれしかなかったんや…。
これの色相を変えてもうまく赤色にすらならんし…。
とりあえずこれで2ゲーム分のりんご実装が終わった。
次は普通に順番に行ってビンゴガーデンである。
このビンゴガーデンは新たにりんごのラインのところに別のピクチャを付け加える必要がある。基盤の上、マスの下あたりなので下2桁10程度あたりを使用するか…。

11-1-5 りんごGET演出もうすぐ

いよいよタブ側にりんごGETと表示されるようになった。
とりあえずここまでで一区切りとする。本当はこの後リザルト画面でワンダーステップへの投入を行うが、この辺りはまたりんごの色などをいろいろ準備してからのほうがいいかもしれないので。
とりあえずビンゴバルーンだけは以下のようにりんごの獲得処理ができたので、ほか8ゲームのりんご獲得処理に着手することになる。
簡単そうに見えてもこれ、結構演出面で変なことにならないように面倒なんや…。

右のタブのビンゴバルーンのところにりんごGETとなっているのが分かるだろう。
以後のゲームでは、りんごGETの演出などはすでにつくっているので条件とアニメーションタイミングを設定するだけでよいはず。
ただマスが動くゲームたちには注意する必要がある。

11-1-4 りんごGET演出

まだビンゴバルーンだけだが、りんごをＧＥＴしたときにステップGET!と表示されるようになった。

あっもうちょっと上に描画すべきやったか…。修正しておいた。

もちろん演出だけでなく、各ゲームのりんご取得状況に関する変数も準備しておいたのでこれで配当表示のときと一緒に六角形型の星を表示して、このりんごを表示することになる。タブ用のりんごGET!はまだ作っていない。
ひとまずこういう感じで残り8ゲーム、地道にワンダーステップの獲得条件を定義しまくっていくことになる。

11-1-3 りんごGET条件確立

めっさ面倒だったが、各マスに対してりんごGET要件をひたすら書き連ねた。
前の記事の1~24のメモを参考に。以下はたしかに該当マスを含むラインが成立しているのでGETと表示されているのが分かる。

注意すべきは、りんごGET確定からのりんごGETアニメーションはシンキング終了まで行ってはならないということである。よってりんご確定アニメーションを行うかどうかのタイミングはシンキング直後、6,7,8球目ビンゴ判定後の計4回である。

じゃあ次はそのリンゴGETのアニメーションを作っていく。
これは非アクティブ時のゲームとアクティブ時のゲームで挙動が違う点に注意。
アクティブのものは暗転からのステップGET！と表示される。

11-1-2 りんご発生エフェクト実装

とうとうりんごの発生エフェクトを作った。まだ全然進展していないが。

静止画像だと全然わからんな…。ただこれだけに動画をあげるのはあまりにしょぼいし。

後はこれを拡大率、座標などを指定して描画することで各ゲームのリンゴ発生に対応する予定である。以後はそのままリンゴピクチャを表示し続ければよい。
ただし動的ゲーム(サンダースマッシュ、ボンバー、ドロップ、ツリー)はこれも一緒に移動する必要があるので注意。
なお、座標はすでに座標を返す関数をすべてに作っているので配置は楽。
ここからようやくワンダーチャンスへの準備が始まるわけである。

11-1-1 ビンゴバルーンのりんご処理

いうまでもなく、ビンゴバルーンのりんご獲得はそのマスに関連するラインが成立しているかである。

ということは以前定義したそれぞれのビンゴの定義を再確認しなければならない。

以下はメモ。

縦7個ライン　1

横7個ライン　2

上段横5個ライン　3

下段横5個ライン　4

左縦5個ライン　5

右縦5個ライン　6

右上から左下に向かう方向上から順に4個ライン　7,8,9,10

左上から右下に向かう方向上から順に4個ライン　11,12,13,14

横ライン上3個ライン　15

横ライン下3個ライン　16

縦ライン左3個ライン　17

縦ライン右3個ライン　18

右上から左下上から3個ライン　19,20,21

左上から右下上から3個ライン　22,23,24

さて、各マスに設置されたりんごを取得できる条件は、以下で表される。

例えば1マス目(最も上のマス)なら、上の番号でいうと1,7,11の位置のラインが成立しているときにGET判定になる。

一応リンゴが3個でたときのための対応も考えておく。

ビンゴバルーンの場合は、ピクチャ番号10000k+400あたりからが空いていそうなのでそれを使う。とりあえず下3桁401~425をリンゴのピクチャにしておこう。

11-1 ワンダーステップ実装開始

214~357に緑と赤の境目

357~571に赤と銅の境目　

715~928に銅と銀の境目

1072~1285に銀と金Lv1の境目

2143~2428に金Lv1と金Lv2の境目

たぶんこんな感じではないかと思う。
そこで、ひとまず以後ワンダーチャンス作成を進めていく(予定)にあたり、赤を250、銅を500、銀を800、金を1200、以後Lvが1あがるごとに内部値が1150ずつ上昇、ということにする。

さて、リンゴを発生させるためにはBETする必要があるが、どうも1BETと500BETでは、1BETボタンを500回押した確率分布と500BET1回の確率分布はなんか違うような気がするので、ここではおおざっぱに経験から以下のように勝手に定める。
基準とかはあまりなく、本当にとりあえず実装するために適当に定めたものである。
とはいっても平均値がBETの7倍になるようにしており、期待値を等しくしている。
でないとBETごとに得損とかでるのは明らかに本家っぽくない…と思うので。
あ、もちろんシングルモードを除く基準やで。シングルは我もよくわからん…。

1BET→内部値1~13上昇
5BET→内部値10~60上昇
10BET→内部値20~120上昇
20BET→内部値40~240上昇
50BET→内部値120~580上昇
100BET→内部値400~1000上昇
500BET→内部値3000~4000上昇

とりあえずこのようにしておこう。
ガウス関数みたいな正規分布を実装するのはこのウディタの特性上不向きなので(もちろん疑似的に再現することはできるけれど。例えば杭をピラミッドみたいに配置して上からボールを落としてみたときのボールの散らばり具合がそれ。たぶん。)一律等しい確率でそれぞれの事象が起こるものとする。
色々確率について仮定しているが、我自身確率をマスターしているわけではない。
入門あたりがようやくわかってきたかくらいである。もちろん高校程度のものは問題ない(と思う)が。確率とは本当は定義はこうでその考えはおかしい!とかつっこまんとってや。

さて、各リンゴの画像を用意するのは非常に大変なので、とりあえず各ゲームにリンゴシステムの実装の準備くらいは整えておこうかと思う。

とはいえ、この作業は全然楽ではない。なぜなら各ゲームりんごの判定処理が違うからである。そしてこれをやると、過去に作ったゲームのプログラムを思い出す必要がある。
ビンゴバルーンなど最初期に作ったものはプログラムの処理速度軽減や簡略化が甘い。
チェーンボンバーのリーチ処理はもう少し良い方法を思いついたが、それはまたいつか修正するとしよう。
一応ここで述べておくと、爆弾種別の同期と新配当初期判定。
具体的に言うと、爆弾でつながっているものは同じ結果になる、ということと、あるマスがHITした後各列に番号入りマスがあれば絶対そこは配当GETにはならないのでリーチ処理をまるまる飛ばせる、というもの。この前思いついた。
実装は特に難しくないが、まずはりんごや…。

あさってから日曜の模試とか日々の授業が連発してくるので以後は忙しくなってあまりできないので、このあたりでリンゴ処理の礎を築いておきたいところである。

次の記事からは具体的はりんご実装を考えていく。

A-5 ナインビンゴモード高設定

以下の画像は、もし本物ならば大興奮レベルのプレイ動画である。

なんとなかなか成立しないオールラインビンゴが成立した。(させた)

このように初期配置などが明らかに高設定に意図的にすることができるのもやはり自作アニマロッタの特徴である。

そろそろりんごシステムの導入に移るか…?
いやその前に様々なリンゴのレベル別の画像を集めんと…。
リンゴの内部値はだいたい赤が250、動画500、銀が800、金が1200、以後レベル1上がるごとに1150ずつ増加、というくらいにわかってきたので。

A-4 ナインビンゴ詳細ペイアウト率

ちょっとだけ初期設定をいじった。どれも同じPOにするのが理想。

ついでに、8ゲーム全部の処理が終わればゲームを終了するフラグを追加。
これで一定時間のウェイトが包容する以下の2つの問題を解決できる。
1,はやく終わった時待ちすぎ
2,処理が終わってないのにリザルト以降
特に2は最後の球でハニーエイトでマスが広がったり、サンダースマッシュの処理の時間のかかるのはもちろん、これら2つあたりがちょっと危ないわけである。

A-3 メニュー構築中

以下のようにメニュー構築の準備を行っている。

ここに各種情報を与えていく予定である。

それを終えてから今日は寝て、次おきたときにそのデータをみてにやにやしとこ。

A-2 各ゲーム配当グラフの処理

まず、最新100ゲーム分の配当の推移をみる。ただWINはBET依存なので、これに依存しないPOで測る。
以前も述べたと思うが、このグラフの描画は始点と終点をしていしてウディタの特殊コマンドの<LINE>を使用している。

今回、1ゲーム目のプロットはx座標が62であり、100ゲーム目のプロットを1250にしたいので、当然ながらnゲーム目のプロットのx座標は12x+50である。
一次関数の関係から未知数を求める中学入試の問題レベル…?
そして次はy座標だが、POが0%をy座標300,PO率1000%を260と定義したので、
例えばPO率2000%は220である。
これまではPO率500%が上限のような感じでグラフを設定していたが、
基本的にBETより低めのWINが来てたまに高配当が来るというアニマロッタのゲームの性質上、5000%くらいも必要になる。これは配当50倍を意味している。
PO率が60倍~70倍程度を表示上限っぽくしているのは、最高配当がそれくらいだからである。
たぶん知っていそうだとは思うが、各ゲームの最高配当はおおむね以下。
ビンゴガーデン　60倍
チェーンボンバー　55.2倍+オッズアップ分で70倍はまず超えない
アニマツリー　50倍
ビンゴファーム　ちょっと面倒なので省略。ただ普通にすると60倍程度
ハニーエイト　50倍(ボーナス加算で上昇するが…)
ビンゴバルーン　125倍(7個ライン+オッズアップ4個。3個ライン7個はわからない)
アニマドロップ　未知数(全消し7回も。myロッタでは330倍も記録した。いや、させた。)
サンダースマッシュ　70倍程度(オッズアップを踏んでたぶん…適当だが)

これらから考えると、もう70倍で十分やろ、という判断。

さて、描画座標であるが、POをx%とすると、やはり上と同様の考え方により、
300-0.04xということになる。すなわち、PO7500%(75倍)で欄外にはみ出る。
なお、0.04xというのはウディタで表現できないので、実際は
30000-4xを計算させて100で割って終わり。しかし、これだとPOが異なっても同じ座標に描画される可能性がある。
例えばPO100%だとすると、座標は296。悲しいことに100%以下の(等倍以下の)推移はたった座標4つ分になる。
…思ったより大問題なのでもうちょっと縦軸の守備範囲を狭めて代わりに差異を発生させたいかも。まあとりあえず作ろう。

100ゲーム分集まれば、
nゲーム目の座標が上の議論で与えられると、n-1ゲーム目の座標を読み取って<LINE>を引く。ただしn=1はだめ。0ゲーム目を参照するので。

というわけで以下はそのようにして作った画像。ゲームごとに色分けしている。

A-1 デバッグメニューの案

アルファベットで始まる見出しは、ゲーム本編とは関係あるが、デバッグなど実際のプレイでは出してはならない機密事項を含む部分の制作である。
まずはさくっとデバッグメニューのタイトルを作成。

キー入力でメニューを選択できるようになっている。あ、もちろん選択しているものが赤いのは本家リスペクトである。
ウディタではただ単に選択状況という変数を設定してキーの判定でそれを+1するか-1するかだけの処理。わざわざここに書くべきでもない話だったかもしれない。

さて、各メニューの紹介である。
1は例の、日ごとやずっと通しでのペイアウト率を計算するメニューである。
たしかウディタは日付の取得ができたはずなのでそれが使える。
2はいわゆる、これから作ろうとしている各ゲームの詳細のデータを記す予定のメニューである。
3はペイアウト率を詳細に設定するためのメニューである。
4はワンダーステップを任意に補充するためのメニュー。
ラウンドワンとか以外ではステップを手動で補充するときにこのメニューを触っているのがある。我もアニマロッタでこういうのを見てみたいというひそかな野望がある。
購入できればどれくらいうれしいやろうなあ…それができんからこうやって自作アニマロッタを作ってるんや…。
ステップの内部値まで設定するかどうかは不明。
本物のデバッグメニューではたぶんりんごの種類しか選べないのでそのりんごの価値の最低値と思われる。これまでの議論によると金リンゴLv1が1個あたり1200ほどの価値を持っているので金リンゴLv1が7個サービスはつまりJP8000のワンダーチャンス権利を付与する、といっているのとたぶん同じで、ここから期待値を割り出せばおおよそどれくらいのメダル増加につながるかはわかるだろう。
ただ最近ワンダーチャンスのカードが多様化しており、パターンを網羅するのは厳しい。
5はCREDITを無理やりねじこむモードである。
このCREDITはもちろんペイアウト率のOUTに加算されない。

とこのようにいろいろなデバッグメニューをその都度暇なら徐々に作っていこうかと思っている。

次は、各ゲームごとの配当などをチェックする画面をつくりたい。
あと、なんか配当分布とかも作れれば面白いかもしれない。
ただ分布はやっぱりある程度の母体数が欲しいし、何よりPO設定を変えていく予定のこのゲームにとってそれは相性が悪い。
確率を求めるだけなら適当にmathematicaあたりの数式処理ソフトにやらせておけばよいので。あれで確率を求めたこともあったが、やっぱり演出があったほうが楽しい。
確かにPOなどの貴重なデータはほしいが、やっぱりアニマロッタそのものを作るほうが楽しいと思う。

10-12 ナインビンゴモードプレイ動画

とりあえず各ゲームのPO率を調べてみようと思う。簡易的に変数に代入するのみにとどめた。もっと詳しいものはいずれ作ると思う。飽きてなければ。
今夜夜通しで自作アニマロッタを起動して各ゲームごとの配当獲得率とPO率を計算してもらう。以下はその結果。(275ゲーム分)

ビンゴガーデン　IN　825000　OUT　409500　P/O　49.6%

チェーンボンバー　IN　825000　OUT　597900　P/O　72.5%
アニマツリー　IN　825000　OUT　558300　P/O　67.7%
ビンゴファーム　IN　825000　OUT　852000　P/O　103.3%
ハニーエイト　IN　825000　OUT　663600　P/O　80.4%
ビンゴバルーン　IN　825000　OUT　289500　P/O　35.1%
ハッピーフラワー　IN　825000　OUT　724500　P/O　87.8%
アニマドロップ　IN　825000　OUT　1080600　P/O　131.0%
サンダースマッシュ　IN　825000　OUT　1242600　P/O　150.6%
ナインビンゴ　IN　825000　OUT　463500　P/O　56.2%
TOTAL　IN　8250000　OUT6851700　P/O　83%
また、各ゲーム配当獲得率は以下。
ビンゴガーデン　31.2%
チェーンボンバー　41.8%
アニマツリー　50.9%
ビンゴファーム　69.1%
ハニーエイト　45.1%
ビンゴバルーン　25.1%
ハッピーフラワー　68.4%
アニマドロップ　56.0%
サンダースマッシュ　62.2%
ナインビンゴ　56.0%

ただし以下に上記ゲームの前提条件の一部を述べる。
ビンゴガーデン
それぞれのパターンほぼ等確率、リーチのときのみビンゴを狙いに行く考え
チェーンボンバー
初期配置は単純に連鎖が初期から起こらない組み合わせ、下4段いずれかのマスに爆弾が最初に1個、振ってくる爆弾は85%で黒、8%で赤、7%で青、5%で虹
アニマツリー
2FUP出現率70%、3FUP出現率30%、オッズ*2出現率10%、オッズ*3出現率10%、オッズ*4出現率5％、オッズ*5出現率5%
ビンゴファーム
青カード出現率9％、赤カード出現率1%
ハッピーフラワー
初期芽1~4個はそれぞれ等確率
アニマドロップ
仮定が多すぎるので省略。ただし補充されるドロップの段は本物のデータをとっている
ビンゴバルーン
ただ単位リーチの時だけマスを埋めに行く。かなり最適化が緩いのでその分POがやたら低く出ている。プレイヤー介入要素の強いゲーム。よって我はこれを超マルチ8面でやることが良いと思う。なおFREE1個、2個、2個はそれぞれ60%,20%,20%である。

以上のことから、どうもフラワーの初期芽を少し減らし、ファームの緑カードなどのFREE配置個数を下げる必要があると踏んだ。あとはアニマドロップの配置構成見直しと、サンダースマッシュの構成パターンの変更。そしてビンゴバルーン配置アルゴリズム。
まあこういうのは最終的にPO管理でやるので今は置いておく。

今日くらいから、ゲームに区切りもついたのでPO設定やPOの統計画面を
本物らしく作っていこうと思っている。
昔金リンゴを手動で入れてもらった時のデバッグメニューのあの感じ、なんか
無性にわくわくするのだった…。
もちろんワンダーステップも入力してワンダーチャンス可能になるようにしたい。
ゆくゆくはこちらが設定したPOに収束するようなプログラムを作りたいと思っている。


そういえば集大成となるナインビンゴモードのプレイ動画を挙げてなかったのでそれを挙げよう。華やかさを演出するためあえて設定は高めにしてある。

余談:意外に恣意的にINさせてもオールビンゴはなりにくいんやな…。

最近連日の勉強で疲れている模様。明日から3日くらいはたぶん数時間程度あるいはあまりしない期間突入なので休憩するか…。数学だけはすでに国公立大学医学部レベルは普通にあると思う。まあ逆にないと笑われるか…。数学科やし。

10-11 ナインビンゴのPO率

長らくPCにゲームを進行させて、ある程度のデータが集まったのでちょっと見てみる。

 我はショックを受けた。何がって…なんで全消しリーチやねん
これは早急に修正が必要や。ただたぶん演出の問題なので実際の挙動はいけていると信じて以下のPOが得られた。ただし本物に似せるためにたくさんの前提条件があることに注意。

思いつく普通っぽい設定でたくさん回した場合(1回3000/10=30000より、253ゲーム分)
当たりはずれの波が普通にありながら、PO率は82%となっている。
これは10000円で4000枚メダルを購入して1回あたり100BETをした場合、50ゲームくらいしたら3100枚なっているくらいに相当。
450BETくらい毎回するとちょうどなくなるくらいの状態。

とりあえず、普通にメダルのGET枚数のみを追ったのがこの画像である。
仮定を述べるとめっさ面倒なのでまたいつか述べることにする。

とりあえず、ボーナス蜂設置問題と、全消しリーチ誤報バグの修正が必要や…。

10-10 ナインビンゴPO率計算開始

とうとうやってきたわ…。すべてのゲームに「アニマ的矛盾」がないようにして、PO率を整える準備ができた。

もちろんナインビンゴのPO率を求めるといっても、様々な仮定をしている。
しかし、アニマロッタでだいたい知られている性質はなるべく模倣するような挙動にした。

その詳しい仮定はまあ後で述べるとしよう…。

もう実行中や。朝に期待

0-5 アニマドロップ大爆発実装

やはりPOを求めるうえで、アニマドロップのはずれドロップ累計による大爆発は無視できないのでそれを実装。これは一瞬でできるわけではない。
なにしろいろいろと定義や音源などが必要だったりするからで…。

しかしできないとかはないので普通に実装した。これでアニマドロップのPO率はたぶんちょっと上昇した。
以下がその決定的?瞬間である。

察しがつくと思うが、わざわざドロップの68マスすべてに消えるべき周囲のマスを定義しているわけではない。そんなことをすると1つのマスで消えうるマスが3+4+4+4+3で18マスなので18*61=1098回もの定義が必要になる。

なのでそれを簡略化するため、周辺マスで判定したそれぞれのマスにさらに周辺マスを定義するという手法をとっている。ちょっと組み方に工夫はいるが。

これにより、ついにPO計算の準備が整った。
今夜は忙しいで。PCが。

10-9 ナインビンゴモードほぼ完成

音とかはまだだが、ほぼナインビンゴの全体的な処理が完成した。

これによって、ナインビンゴも含めたPO率を求める準備ができたことになる。

しかしや…。

まだアニマドロップのはずれドロップ累計による大爆発や、ビンゴガーデンの8パターンの手動打ち込みなどの課題が残っている。
ちなみに、PO率を求めるうえで最低限アニマに似せたい残りの点としては、
アニマドロップは生成規則が不明なため初期配置だけランダムにして算出。
チェーンボンバーはランダムに初期で連鎖しない構成で、落下時爆弾も一定の確率で黒、赤、青、虹爆弾が出現すると仮定。詳細はPOを求めるときに述べる。
アニマツリーはオッズアップ出現頻度が不明だがこれも憶測で行く。
ファームはちゃんと20パターンかそれ以上?マスの配置規則があるのでそれを打ち込んだので本物再現率は高い。
ハニーエイトもスタートやラッキー、番号配置規則をなるべく本物に近づけて連荘ボーナスも実装したので再現性が高い。
バルーンは本家そのままだが、自動配置システムの最適化がいまいちなので本家のPOより下がることは間違いないだろう。しかしある程度の近似はできそう。
フラワーも初期芽の配置個数を一定の離散型確率分布のもとでシミュレートするが、たぶんこれも大丈夫だと思う。
ビンゴガーデンはほぼビンゴバルーンと同様の理由。
サンダースマッシュはがんばって配置パターンを打ち込んだので、本家にかなり近いものが得られると思う。

総じて、大きくアニマロッタとのＰＯ率が乖離するものはもしかするとないのでは…?と期待している。ナインビンゴは当然ながら最もＰＯの誤差があるものが影響してくるいわば律速段階のような感じなので、なかなか正確な値に近いものことは難しい。

だがいずれにせよ、ナインビンゴモードの完成(もちろん妥協点はあるが)がもはや目前といってもいいくらいにまで来ている。
なお、この自作アニマロッタは急にボールがたくさん入っても誤作動を起こさないようになっている(ただし8球終了後一定時間で次ゲームにうつるのでこの点は注意)ので、ちょっとボールの「発射」間隔をはやめても問題ないと思われる。

それにより各9ゲーム+ナインビンゴの計10ゲームの配当額をグラフにして、デバッグメニューでみられるようにしてゆくゆくはＰＯ管理までできる自作アニマロッタの確率を目指している。

今日も6時間くらい勉強したので、やっぱり疲れるわ…。ねよ

10-8 リーチ演出実装

ついにLINEリーチと表示される演出を作り、さらにビンゴのラインも作った。まあ下の画像では見えてないが。しかし肝心の配当表が未完成なのでここを次は完成させる。
そして後は音源を使えばいよいよたぶん完成となる。

ちなみに、ビンゴガーデンはまだ最良の配置しか出ていないので、ちょっと残り7パターンか8パターンを打ち込んで多様性を高める予定。
アニマドロップはまだスロパジャレン(クラッシュでいう超爆発の音)のシステムを作っていないのでこれも実装予定。たぶん明日までにはできているかもしれない。

0-4 スマッシュとエイト修正

まあそこまで大した問題ではないが、ハニーエイトのスタートとラッキーの配置アルゴリズムを変更。ちゃんと周囲に2個以上の番号が存在するようになった。
あと、連荘ボーナスによるハチも発生するようになり、継続率が若干あがった。

次にサンダースマッシュは、これまではオッズアップ1回で打ち切り、としていたが先日アニマロッタで3種類の配当ブロックがあることに気づき、しかも最高段階のブロック(コイン3つのやつ)がパワーアップしても配当は増加するがブロックの見た目は変わらないことに気づき、それを実装。
本当は、そのマスの基礎配当をオッズアップ都度で加算する、ということをしたいが、知っての通り2回目以降は代入操作によってもとの値は消える。もちろん別の変数に保存すればいいが、あまり変数を増やしたくないんや…。

そこで、1,2,3,4…倍の推移を、結局オッズアップは最大4個や。ということは、1から2、2から3、3から4、4から5倍の推移しかない。ということは、例えば4から5なら、もういっそのこと1.25倍すればええやん、という考えに至った。そして以下のようになった。
たぶん改善点、と画像だけ示されてもわからない。

上の画像は確かに、配当ブロックがパワーアップしているのがわかるだろう。
ちなみに実際にアニマをやって画像を撮影してきた。
まさか周囲も自作アニマロッタのため、とは思うまい…。

なお、一応デフォルトとして各ブロックがオッズアップの対象となる確率は一律80%としている。本当は全消し配当も1.2倍ずつ上昇するが、まあ…別にええか。

しかしながら、チェーンボンバーとサンダースマッシュのあらかじめ配当取得プログラムで3,5球目に適切に、かつ素早く配当入手判定を行う、というものは、ちょっと思考を有する。

10-7 ナインビンゴ配当設定

一見簡単なように見えるナインビンゴだが、実はそこまで簡単ではない。
普通にロッタ単位で処理が終わっているなら楽勝だが、そうでない可能性を考慮する必要がある。
例えばまだ処理が終わってないのに5球目とかの処理を一斉に9ゲームに対して行った場合、終わってないものがその5球目リーチになるまで待つ必要がある。

後、チェーンボンバーとサンダースマッシュはロッタの途中、つまり1,2,4球目でリーチ状況が変わることもあり、ちょっとこのあたりがまだうまくいってないので以後改善予定。

ほんの少しピクチャなどを加えて、なんとなくそれっぽくしたのが以下。
ここにまだ「LINEリーチ」とか、LINEリーチのリーチ演出、ビンゴのライン表示などを付け加えていく…が、とりあえずまずはより良い一斉処理プログラムがないか考えて、あとボンバーとスマッシュの問題解決が先だろうと思われる。
ちょっと眠気が尋常でないので文章がおかしくなってるかもしれない。おやすみ

0-3 細部を修正中

まず、ハニーエイトのラッキーマス出現要件とスタートマスの設置要件を本物っぽくした。
従来はスタートマスは中心以外、としていたがこれではその中心の周囲に配置された場合、拠点周囲の1個しか番号がない可能性がある。
そこで、暫定的に中心及びその周囲も拠点に選ばれないようにした。
たぶん本物はその周囲なら、それらの周囲に2個以上番号があれば配置されそうな気がするが…まあいいか…。

また、ラッキーマスは必ず周囲に2個あるようなマスを選ぶようにした。
雑談などでラッキーマスは3マス連なったところにあるっぽい、と言っているのはこれが理由である。2マスとかだと、そのマスがラッキーに変わると拠点の周囲が1個だけになる。
このようなラッキーの追加はたぶん誰も見たことがないだろう。

以下はその証拠画像。確かにラッキーの周囲には番号が2個以上ある。

というわけで、ラッキーマスがHITした場合、必ず拠点周囲に2個マスが現れるようになった。これでハニーエイトのPO率がほんの少しあがるかもしれない。
これでだいたいほぼ本物とそっくりの仕様となった。

次に、今日アニマロッタでブロックなどの撮影をしてきたので、それを使ってきたないピクチャの解像度を上げる。
そして気づいたことだが、サンダースマッシュのオッズアップは1回でコイン2個分のブロック、2回で3個分のブロックになり、3回以降は配当は3,4,倍と増えるがブロックの見た目はコイン3つのままで変わらない。
いやあこれは我的にはすばらしい展開やった。
まあ本物のアニマ、ぜんぜん当たらないし。かれこれビッグワンダーチャンスも33回くらいになってJPC進出すら0か。厳しいのお
ほんままともにあそべたもんじゃないで…。3の頃はまだましだったような。
2はさらにましで、初代は増えることも多かったような気がする。

ちなみに、昨日でだいたいHIT後、シンキング終了後ほぼ同時にナインビンゴ判定を行う機構を作ったので、本物っぽいナインビンゴの挙動の基盤も完成している。

余談だが、我もPO管理プログラムを構築する

10-6 ナインビンゴを除くPO率推移

さて、夜通し自作アニマロッタを稼働させて、メダルの入手状況をみてみた。
もしかするとプログラムの関係上9ゲーム目(フラワー)が考慮されていないかもしれないが、そもそもこういう確率に正確性を求めるのは、おおもとの事象の起こる確率が分かっていない以上意味がないのでそこは気にしないことにする。

100%とかかれているところが、BET額と同額配当を得た、ということで、
このグラフを考察すると、たしかに配当以上の少し大きな当たりは出ている。しかしせいぜい100回に10回程度。等倍返しだともうちょっと増える。だがそれ以上に配当がBETより少ないゲームも結構多く、そしてこのグラフ最大の特徴は4倍以上の配当が出ていない、ということである。

で、PO率はだいたい75%程度。これは結構低い部類…だが、現実的ではある。
昨日はナインビンゴ構築のための準備をしていた。
ちょっと今日はアニマに赴いてナインビンゴの画像をとりにいくか…。
もちろんその前もその後も3時間ずつ勉強があるが。
知っているとおもうがこんなことをやっていて暇なわけではない。
勉強後の空いた時間でこれをやっている。

10-5 ゲーム間移動実装

超マルチのとき同様に、ゲーム間を移動できるようになった。
あとリーチとかの文字が小さかったのでそこもちょっと修正。ＢＥＴ額も表示されるようになった…が依然としてナインビンゴの開拓は進んでいない。

ナインビンゴで使う変数は非常にわずかだと思うので、専用のものを用意しなくてもよく、予備変数9の一部でことたりるとみている。

少しずつナインビンゴっぽくなってきていると思う。
ちなみに、なんか背景がさみしい気がするので雲のフォグとかを用意して後ろの背景に加えてもいいような気がする。本物のアニマは背景にも変化があるっぽいので。

あれなんかまた左下のＢＥＴとか消えてるやん…。

で、ナインビンゴのリーチ判定はちょっと工夫する。
まず、LINEリーチと出てくるのは、そのゲームにリーチの番号がなくても、ビンゴの状況のみに依存して決定される。
例えばアニマドロップでリーチがなくても、ビンゴガーデンとハッピーフラワーで配当を獲得しているとアニマドロップにLINEリーチと表示される。
ちなみに、ボール入賞待ち状態において、すでにどこがリーチとかは計算されているので、すぐさまビンゴとLINEリーチを判別できる。
問題は同時に入賞した場合だが…。
これはすべてのゲームが同時進行でないため、球数で同期できない。例えばスマッシュとかは遅延しやすいので、まだリーチ判定されるに至っていない時刻だと、その次の球で配当を獲得しているのにすっぽかされるという問題がある。

そこでこれを解決する方法は、順次配当の有無が更新され次第、ビンゴ判定を行う、ということになる。となると並立処理が増えるが、まあこれは1ゲームなのでそこまで処理速度に影響しないだろうという所感。

10-4 ナインビンゴモード基盤配置

以下のように、ナインビンゴモードの基礎となる基盤を配置した。

まだＢＥＴ額とかが正式に移動していないが、だいたいそれっぽい形になった。

なんかBETとが消えているがまあええか…。

さて、ここからナインビンゴの性質をいろいろ加えていくこととなる。

例えば、LINEリーチとか、ビンゴのラインの演出など。

やっぱり疑似的でもいいので左下にボタンをつけるか…あと右下のボール履歴が若干大きいので、相対的に8,9割程度に縮小すべきっぽい。

そしてつい先ほど作ったリザルト画面もこれのためだった。

当然ながら、ナインビンゴの配当は未定義なので0である。

ここからがスタートや。

10-3 各ゲームの座標移動(2)

続いて、各ゲームのタブを所定の位置に移動させた。

ここから次はBET額と、リーチのやつをタブに同期させる。
そこからいよいよナインビンゴの背景などに入っていくことになる。
以下はリーチなどの演出も移動させたものである。

いやしかしこれ想像以上に時間かかるな…。

10-2 各ゲームの位置移動(1)

各ゲームにピクチャエフェクトをかけ、座標を移動させた。タブでは拡大率は16%としているはず。今回アクティブが9ゲーム目つまりハッピフラワーということで以下のようになっている。
まだ構成途中なのでタブとかが中央に集中したまま。

ちゃんと本物のナインビンゴをしたじきにして、適切な位置に配置したんや…。
あとはみでそうなやつはちょっと縮小したりといろいろ時間がかかった。
この次はタブつまり90001~90900あたりのピクチャの一斉移動を行う。

10-1 ナインビンゴ構築準備

さて、リザルト画面もナインビンゴモードを作ったし、いよいよナインビンゴの配置を再現していきたいと思う。とはいえ、このモードの実装には壁がある。
それはボタン判定の刷新である。
いいかえれば、各ゲーム切り替えやベットボタンに関するボタンが押された、という判定を全部作り直す必要がある、ということである。
そして、ボタンが押された判定はボタンの領域についての必要引数が4つ必要なので、これの指定がちょっと面倒。(x座標、y座標、縦、横の長さ。もちろん左上と右下という2つでもボタン判定はできるが、結局2次元の座標を2つ使っている点で4次元。同相?)

あと、PAID画面とか作ったのでそれを張り付けておく。

確かにBETボタンが押されるまではWIN,PAIDの値は変わらない、という本作の特徴を再現している。BETタイムから配置されているのにはつっこんではいけない。


では次の記事からは、いよいよ待ちに待ったナインビンゴモードが徐々に構築される様子を貼り付けていく。ボタン判定はあとでもいいやろ…。
ちなみに、非アクティブのゲームはタブ内におさまっているが、これは中心に描画したものをピクチャエフェクトによって強制的に移動させているので、このあたりのピクチャは一斉移動が利くのでこの辺りは思いのほか面倒ではない。

0-2 リザルト画面構築

ナインビンゴだけだが、リザルト画面を構築した。
今は0だが、ゲームによって配当が発生して代入されたものを取得しているので問題ない。後ろが超マルチなのは気にしてはいけない。

なおこれだけでピクチャの範囲は117個分である。103001~103117を使用している。
あ、もちろん0や各ゲームのロゴの位置もできるだけ本物に近くなるように微調整した。
そういえばロケテストではナインビンゴの欄の枠が端までいってないんやな…。
それから上のような感じに変わったのは一体何の意味があるんや。
さて、ここまでできたのでこの後はPAID発生からのCREDITが離散的だが連続的な増加を行う必要がある。
ところで、たとえば90000WINを得たとき、このPAIDは1フレームごとにどう動いているかについてだが、まさか1ずつ増加、ではないだろう。これさと90000フレーム、すなわち25分かかる。
というわけで、やはり動画などを見て調べてみた。たぶんだれも調べないことなので。
動画ではすうっと一気に目的の数字まで近づいていた。ただ体感では、もっとゆっくり目的のCREDITに漸近するパターンもあった(たとえばワンダーチャンス終了時?)が…。
まあこのあたりはわざわざ2パターン(たぶん次のゲームがおしせまってるかどうかによる場合分け?)組む必要もないので、普通に動画のものとする。
…がしかし、途中から一定法則が崩れたのでどうにもこれはわからん。

詳しく解析をすればわかるかもしれないが、とりあえず以下の法則にしておく。
60フレームでCREDITの充填を完了するとする。
そこで、20フレームごとに増加率を分断する。
はじめ20フレームでは充填の60%までを加算し、次の20フレームで充填の90%までを加算し、最後の20フレームで目的のWIN数まで到達、ということに勝手にする。
例えば10000WINとかなら、はじめ20フレームで6000WINまで上昇。
ということは1フレームあたり300WINの上昇。
なので、一般的にはｎWINに対して
初めの20フレームは　0.03nの増加
次の20フレームは　0.015nの増加
最後の20フレームは0.005nの増加とする。
ただしこれ、nが200未満とかだと最後の20フレームで、フレームが推移しても同じ
値を示すものが出てきそうなところが問題。n=10とかだとその問題は顕著。
まあそのあたりは気にしないでもいいか…いつでも変更可能やし。

じゃあまずはそのPAIDと書かれた枠を動画などからスクリーンショットして、それをbmpに貼り付けてトリミングして周りを加工して透過処理や。

0-1 全体装飾開始

9ゲーム分が終わったので、そろそろワンダーステップなどの導入準備のために、左上にアニマロッタのようにワンダーステップのピクチャを貼る。後BETやCREDITが表示されるようにもする。
ただ、この部分はRESULT画面の詳細ができてからやりたいところなので、とりあえず暫定的なものとしておく。ピクチャを追加するだけでもほんの少しアニマロッタらしくなった。

あとさみしいので左下にボタンを追加したいが、知っての通りまったく作っていないのでここまでたぶん手が回らない。アニマの動きとかむりやん。
称号とかならまだ何とかなるかもしれんが…。

次からはリザルト画面の構築にうつるか…?
この画面の性質はすでに自作カラコロッタで似たものを作っているのでそれを流用しようと思う。ピクチャ番号はだいたい100101あたりから使うか…。
1~9999が後ろの背景などで、
10000*kから10000k+9999がだいたいkゲーム目に関するピクチャ
(9ゲームモードにするときはちょっと工夫をすると解決する)
100001からはSTARTの文字や、左下などの常に上に表示すべき文字やアニメ。

というわけで、まずはリザルト画面を作るために、アニマロッタの公式サイトからピクチャをもってきて、そこから地道にロゴのまわりを削る作業からスタートや。地味。

9-13 初期配置を設定

がんばって34ブロック分、それぞれに番号を指定し、これを12パターン鏡面含めて設定。
これは工夫とかがないので大変や。この初期配置のコモンだけで2500行や。

そしてそれによりPO率がより本物に近くなったはず…に。

なんやこれPO率が112%くらいに収束してるやん。
これではメダルが増加してしまうやん…。
これの原因はおそらく全消し配当がよく発生しているのが原因だろう。
一応配置も12パターン打ち込んだので、まんべんなくパターンがそこそこ分散しているはず。
ということはなんか、全消し配当が発生しやすいパターンでもあるんか…?

ちょっと修正して音問題を解決…?

あとこれとは別だが、変なところのマスが光る問題も解決。

9-12 全体ゲームのPO率

超マルチでは8ゲームしかできないので、ビンゴガーデンをのぞく8ゲームを100回回した結果が以下。
ただ、当然のことながら様々な前提条件が入っている。
ボンバーは色爆弾率が不詳、アニマツリーもオッズアップ率不明、ハニーエイトもラッキーの性質などが異なるし、スマッシュはまだ1パターンしかつくっていないし、ドロップは大爆発が未実装、など。
その後スマッシュは確認された12パターンを打ち込んだが、このコモンイベントだけで2400行近くなった。ちなみにこのコモンイベントナンバーは681である。全部これくらいの長さだと、一人で700*2400=1680000行書いたことになる。
まあ2400行に達したものはほぼないのでこの計算はほぼ無意味だが。
しかしある程度の再現性は担保されているので、その考察に意味は少なくとも皆無ではない、ということで貼り付けることにする。
データが正しくないとか頭ごなしに言ってたらそれこそ何も進展しないんや…。

等倍以上の返しが1,2割程度で起こっており、それ以外はマイナス。ただし超マルチなので0WINとかいうことはないらしい。(左端は存在しない0ゲーム目を読みにいってのPOが0%という意味なので左端のみデータは意味をもたない)
これは本物のアニマロッタでも、オールモードなどでは連荘はすごくするもののメダルは増えない。ただたまに等倍以上の返しがある、というイメーに合致する…と思う。

なお、一律3000BET*8=24000BETでPO率73%というのは、たとえばヤングプラザドットコムで20万円で180万枚?と掲示板に書かれてあったのでそれを信用(実際に行ってみたがたばこ臭かった。10000円より上は特にかかれていなかったと思うのでたぶん秘密レート。帰りにラグナシアによってタオルをドロップする)すると、一回でのメダル損失は6000枚くらい。よって300回程度でなくなる。これはMAXBETをして10時間くらいでなくなるという、我は知らんが妥当な結果なのかもしれない。
今後もこう言った数値に基づく(あたかも正しいように見える)考察を行っていくつもりである。

PO率調整機構などを組み込みたい我は、この程度のグラフで満足するはずがない。今、9ゲームが出そろったからには、それぞれのゲームのPO率の統計を取ってグラフにしたり、いろいろしようと考えている。

9-11 サンダースマッシュプレイ動画

ついにサンダースマッシュが形となり、動画化することになった。

まだまだ至らない点が多いが…。とりあえずこれくらいでええやろ…。
4日もかかった。
具体的にはマスの移動音がたぶん予約数あるいは同時鳴動数を超えているのかは知らないが消える部分が。これはしょうがないか…。

たぶんわかると思うが、サンダースマッシュの攻略…というか連鎖ポイントは、以下に左右を挟んで雷が起爆してかつ雷同士の間のブロックが3個以下にできるか、である。
ちなみに、まだ初期配置パターンは1通りしかつくっていない。
適当に最下段の雷の位置だけひとつずらしたものもあるが、これらは50%、50%の確率で出るようになっている。右側は左と違うように見えるが鏡面なので実質同じ。

これにてアニマロッタのシークレット除く通常ゲームを一応再現したことになる。

そしてもちろん超マルチで自由にゲームを構成することも可能である。

↑操作してないのに全獲りしてる…実機やったらなあ
さて、ここからが本番や。
いよいよナインビンゴモードの準備が開始することになる。
ただそうすぐにはできんので、休憩か…。

9-10 常時演出実装

雷マスが光るようになり、ブロックにリーチとかが表示されるようになった。
あとやることといえば、パターンを手動入力と、音の徴取くらいである。

9-9 リーチ判定完了

今回は8ゲームにしてもそんなに処理が重くなくよかった。まあそうなるように最初からいろいろやったからなんだが。
以下がリーチなどが描画されたいつもの自作アニマロッタ。

例えば右側のゲームでは、14や18に入れば超高額配当となるが、
その理由は14や18が消えることにより、右側の雷と一緒に左側の雷が消えて左側は少なくとも全消しできる、ということからもわかるだろう。
20だとだめな理由は、20の場合は、右側番号22の左にいる雷マスが最下段に出てこれず、左側単独での連鎖となるためで、当然ちょっと考えるとわかるが、そのようなことはこの配置では起こらない。そのため、24の右のブロックの配当を入手し、総合計WINがBETの3倍超え10倍未満にとどまる、ということで20番は赤色になっている。
これらから信ぴょう性が高い(たぶん完ぺきなはず)こともわかるだろう。

本物のアニマロッタは、これに加えて最下段のブロックに期待状況をさらに描画する。
よってほぼ最後の仕上げとして、ブロックのリーチ表示、そして常時演出(雷マスがぴかぴか光るなど)を実装しようと思っている。
そうすれば、このサンダースマッシュも後は音を動画などからきりとったりしてがんばれば完成となる。

9-8 全消し機能を実装

以下の画像のように、全消しの機能を実装した。
さてこれで残すはリーチ処理や…。なるべく処理を軽くしたい。

3球で両側全消しするという快挙。まあ配当マス以外全部雷マスにしたからやけど。

ここにリーチ処理でリーチの番号が加わればもっと華やかに…。

9-7 リーチ処理の案

これまで、リーチ処理といえば1番から25番まで行うのが普通だった。
そうするとこのサンダースマッシュも1から25番を現時点での状況について、それぞれ雷マスなどに変えて先に連鎖シミュレーションする、というのが通常の手法。
だが見ての通り、最下段にHITしなければ必ず配当は発生しない、というこのゲームのほぼ自明な性質により、最大でもこの25回のリーチ動作を8回に絞ることができる。
かぶり番号や雷マスがすでにあった場合、これは7,6…とより少なくなる。

とはいえ、その1回1回が重い処理であることに変わりはない。
ではどういう感じでリーチ処理を構築していくのかをここで書きながら考えることにする。
普通に、まず番号がHITしたときのマスの状況を格納しておく。
後は配当の位置。オッズアップの位置や番号の位置は、HITすればリーチ判定においては無関係なのでこれらは無視してよい。
総じて68*2＝136のデータを予備変数の余ったところに入れておくことになるだろう。
そこから最下段が消えるという話は、これまでのものと同様にする。

その後、左と右で変数のつめ作業を行い、最下段に雷マスが2個以上あれば同様のことを行う、ということを繰り返す。

これくらいならたぶん処理の重さもそこまで大変なことにならないだろう…と期待している。

9-6 配当表示ほぼ完成

ついに配当などがリンクするようになった。

これにより、すでにPO率をだいたい求めることができるようになった。
あとは全消しに関する処理がまだ。
これが終われば、いよいよ問題のリーチ処理に移る。
ていうか、これ8ゲームにしても処理大丈夫なんか…?

ということで試験的に8ゲーム化させると…。


ぶっふぉ

失敗や・・・
いやしかしこれはおそらくウェイトに侵入してくる別イベの干渉だと考えられる。
特に難しい問題ではない。

そして

無事8ゲームで動作した。

さて残りは全消しの処理(アニメは作成済み)、リーチ処理の2つと思われる。
あと細かいところの修正など。

実際にやってみても処理速度はまあまあで、普通にみていて問題はたぶんないくらい。
やっぱり一括変数、ピクチャ移動ディレイ大作戦を講じただけはあったわ。

さて…。ここからがリーチ処理や。その詳細は次の記事。