0でない数字を詰めていくという結構使うかもしれないプログラム。
実際には、BETしていないゲームにはリンゴは出現しないので、
cself[20]で各ゲームのBETを取得している。BETや設定はいつでも変更しやすいように可変DBに登録している。
そしてBETが0でない、すなわちゲームに参加している場合のみ、カウントという変数を用意して順番に所定の変数にその番号を代入するようにしている。
例えばビンゴガーデン、チェーンボンバーのみにBETしていたら、ナインビンゴにおけるこれらのゲームIDはそれぞれ5,2なので、全部BETで9ゲーム(ナインビンゴには虹は出現しないとしている)より9つの変数のうち、前から2,5を返されることになる。
ちゃんと次ゲームでこのカウントは初期化する必要があるので、これはリザルト画面後のローカル変数初期化処理を作ってそこは対処している。
そしてこの2,5というのは明らかに長さ2の列(この長さ2というのはカウントの変数そのものである)なので、確率変数として1or2をランダムに生成することにより、賭けているこの2ゲームのいずれかに虹りんごが出現する、というプログラムである。
もちろん1~9ゲームをランダムで選んで、その後BETしているかどうか判定してBETしていなければまたランダムで選んで…を繰り返しても良いが、これだと1ゲームしかBETしていないと無駄に処理の繰り返しの確率が上昇して処理がわずかだが重くなる可能性がある。あとしかるべき処置をしなければBETなしで無限ループする。
そういうわけで、時間がかからないという保証を得られる前者のプログラムのほうがよいだろう、という結論に最近至った。
これまではあまり考えていなかったが、ハニーエイトのSTARTやLUCKYの規定をおこなうあたりからこの案が自然と芽生えてきた。以前はそんなことを考えていなかったが、このほうが良いような気がした。
ただでさえこのゲームは並立コモンが莫大な量存在して、なんとかプログラムの処理を軽減しようとひたすら特にチェーンボンバーとアニマドロップでがんばったものなので。
話を戻して虹りんごが出現するゲームが消えた後は、りんごの内部値を現在のもの(BETタイム時に既定)から-1に変更する。内部値情報を失うが、そもそも虹りんごは平均BET依存なので問題ない。あと-1にしておくことでリザルト画面でのワンダーステップへのりんご内部値の代入及び水平投射運動も、1以上の内部値に対して行う、という定義からりんご未取得同様、無視できるので都合がよい。
羽りんごやクリスタルりんごは、内部値をもっているのは明らかなのでこの場合は、10万の位が1のものという位置づけをすることが考えられる。
内部値100000をこの定義以外で出すには、MAX3000BETのアニマでは内部値は21000周辺なので不可能である。もちろんワンダーチャンス140000付近からの0ラインを連発すればいつかはたどり着くが…。
まあこういうのはあとで考えればよいので割愛。
あとはピクチャとして「(りんご)出現!」というマークを出すのが鉄則になっている。
余談だが、アニマ4,5ではとりあえず虹りんごの場合はSTARTの文字出現と同時にでてきて、羽りんごの表示は各ゲームがSTARTによってゲーム開始許可を与えられてから行われる。ただ、アニマ1,2付近はそうではなく、やはり後者の表示タイミングに準じていた。
たっだコモンイベント1個のしかも50行程度のプログラムでも結構話す内容がある。
…となるとこの1個あたりこれの数倍から数十倍のものが多い800個近いコモンイベントを話しているとたぶんとんでもないことになるので、全部の説明はいやや。
