2-16 チェーンボンバーのPO率推移

実際のチェーンボンバーとはちょっと違うが、以下を仮定した下でのPO推移。
番号は均等に配置され、マスはランダムに初期状態で連鎖しない形をとり、さらに開始時爆弾は0個とし、オッズアップはすでにGETした配当にもかかるとする。(ここは本物とかなり違うので修正すべき部分）このようにいろいろ本物と違うところがあるが、だいたい似ているので、とりあえずこれを超マルチモードで回したときのPO率の推移が以下のグラフとなる。

ちなみに、チェーンボンバー大辞典でのカードの配置パターンの順位の中央値が69%程度なので、正規分布とすると平均値と中央値が一致するはずで、我のデータPO70%と比較すると類似している。実はランダムにカードのパターンを組んでもちゃんとそれっぽい挙動を示すという。そして直近の100ゲームを見てもやっぱり全消しをしておらず、意外と全消しは起こりにくいこともわかる。

2-15 メダル大量ゲット()

大量メダルゲットやん!!(笑)

まあ冗談はさておき、ようやく処理遅い問題が少しだけましになり、さらにまあ見てて気持ち悪くないチェーンボンバーになってきた。
リーチ処理を全部処理速度優先で書き換えたんや…。
それに伴い、リーチ処理の高速化が可能となったのも処理速度向上の一つ。
ようやくそれっぽくなった、といえる。
ちなみに上の状況は、初期爆弾率75%の設定でのプレイ。
実際のアニマロッタでは昔は爆弾は最大1つ、いつのまにか2つくらいまで出るようになった。ただそれでも下4段だと思う。
ちなみに番号は25個なので、当然番号のつかない爆弾が発生することになる。
まあこれがあっても一応動作するようにはなっているが、アニマロッタでそのような爆弾は存在しないので意味ない。

さて…。ビンゴガーデンやアニマツリーなどを作ってもいいが、まあせっかくやし全消しチュピチュピリーチと全消しキランッキランでも作るか…。(どちらもその時の効果音を擬音化している)

せっかくなので、爆弾配置率を50%としたものを動画にした。

2-14 とりあえず動画に

なんか、ピクチャが一瞬中央に表示される問題、処理がなお重い(動画処理ソフトを導入するとさらに重い)問題がありこれはゆゆしき事態なんだが、とりあえずどんな感じか動画にしてみる。

やっぱり…なんか…満足いかない出来や…。プログラム自体は問題なさそうだが、やっぱり処理を軽減できていない…?結構あれからいろいろピクチャ移動の統制やウェイトをいたるところにいれたんやけど…。

2-13 ピクチャ表示ディレイ

我はちょっと前に連鎖文字ピクチャの消去において一度だけ使ったことのあるピクチャ発動事例。これは指定したピクチャ変形をディレイ分だけ遅らせるというもので、連続でピクチャの移動を指定すると直近のものが優先されて何個も移動を指定するのは無理だと思っていたが、簡単な例で実験したところ成功。

これまでは例えば10回何か54マスのピクチャに対して処理を行うのを、10回分すべてに変数を呼び出してきてある条件下のもとで動作をせよ、ということをしていたが、これをすると特に連鎖の動作などの処理が軽減されるのではないかと期待している。

もし3ゲーム目以降を作るならこれを念頭に入れておく。おそらくこれは非常に便利なので変数呼び出し値と同様に必要不可欠のものになるだろう。
ていうかなんでいままで気づかなかったんや…。

2-12 処理軽減努力中

ちょっなんとか処理を軽く…したい
内部処理としてはちゃんとたぶんいけてそう

2-12 なんやこの処理の重さ

ちょっとゲーム数が増えるほど番号が重複配置されるバグがあるが、それはおいといてもなんか、ビンゴバルーンをはるかに上回る処理の重さ…。

とりあえず内部的には問題なく動作しているが、かなりかくかくなのでここからはいかにして並立処理を減らして処理を軽減するかが重要となる…。

確認はしていないが、ビンゴバルーンとの同時開催もできると思う。
写真だけ見るとなんかいい感じなんだが…。

2-11 配当落下表示

さて、いよいよ効果音をつけ、配当の落下表示と配当GET演出を加えた。
残るは色爆弾に関する処理と、全消しリーチと全消し時の演出が残っているが、それ以外はだいたいできあがったといってもいいのでいよいよこの記事の次で8ゲームモードにする。はたしてこれがうまくいくか…。

とりあえず1ゲームだとこんな感じになる。

2-10 オッズアップ演出付与

上記のように、5連鎖以上した場合にオッズアップが付与される演出を追加。内部処理はこれから作るがこれはまったくたいしたことない。なぜならオッズアップを加味した処理をすでにこれまでにつくっているからである。
ちなみになんで9連鎖やねん、というつっこみはなし。ちょっとデバッグのためにある数値をいじっただけ。一応29連鎖まで表示できる。30以降は不要。
なぜならどれだけ連鎖してもたぶん54/2で27連鎖なので、30連鎖以上は決していかない。

肝心の配当が全然表示されていないが、それはこれからや…。

2-9 リーチ演出強化

以下のように、リーチがより分かりやすく表示されるように。

ただやっぱりリーチの処理が重いようで、リーチの表示に若干時間がかかるのが難点。

2-8 配当計算処理

チェーンボンバーの配当については以下を基準とする。

5連鎖以上である場所がオッズアップしていき、以降のオッズアップでは同じ場所がオッズアップしていくとする。ただし、連鎖回数がリセットされればオッズアップ対象列は再抽選されるものとする。(たぶんこんなルールだったような気がする…)

そして列ごとのマス設置状況を見て、全部0(空白)ならば配当GETとし、全部のマスの値が0ならば全消し。

配当が1以上期待されるものについては「リーチ」、全消しが期待されるものについては「リーチ」と「全消し」を両方付け加える演出にしようと思っている。

2-7 リーチ内部処理完了

とりあえず演出そぎおとしなどにより、リーチ処理が完成。とはいっても内部だけなのでこれらをタブ側などに関連付けるのはまだ。まあこれは難しくはない。

とりあえず1,2,3が入って上記のような配置になった。
この後は20番に入るように指定されているのだが、それを予測したデバッグ文が以下。
20番に入ると以下 -->[ｺﾓﾝ198/45行]
0 0 0 0 0 0
 1 0 0 0 0 6
5 6 0 0 0 6
4 6 6 0 0 4
 5 1 6 0 0 3
2 5 6 0 0 2
3 1 3 6 6 3
 5 4 2 1 6 5
3 1 3 5 3 4 -->[ｺﾓﾝ198/46行]
そして実際に20番に入って実行されたものが以下。

右3つの配置が変わったが、本当にそれを体現しているかというと、
確かにマスを見るとそれが証明されている。(赤が1、ピンクが2、黄色が3、緑が4、青が5、黒爆弾が6としている)

これにより、ある番号に入った場合の先行抽選ができるようになったので、列ごとに番号を見ていくことにより、ついに配当の処理に移っていくことができる。
…で、配当の処理をどうしていくかは次の記事で書いていく予定。

2-6 おおまかな流れが完成

とりあえず、チェーンボンバーらしき挙動ができるようになってきた。
リーチ処理や演出などはまだ全然だが…。

実をいうと、まだ音源などがそろっていないので無音にしている。
だが、おそらく1週間もたつとしっかりと演出つきのゲームになっているのではないかと期待できるかも。

ここからは各演出の考察に移っていく。

2-5 爆弾が降ってくる

いや別に物騒な話ではなくて、普通にチェーンボンバーで爆弾と化したものが上から降ってくるというアニマロッタの仕様を忠実に再現。
ちゃんと爆弾になった順で下から並べられたものが出てくるようになっている。
同時に爆弾になったものは上のほうにあったものが先に爆弾化するようにしている。
とりあえずもっとも上に表示したものが以下。

ここからの落下処理は、普通にブロックの落下処理と同じ。

なのでそれを流用すればよい。

このように消えたマスは爆弾として再び落下してくる、というのがアニマロッタのチェーンボンバーである。一応区別として、爆弾のほうが速く落ちるようにしている。

今のところはブロックは1マス移動4フレーム、爆弾が1マス移動3フレームという状況。

あとはリーチ処理などをつくっていくのだが、このmyチェーンボンバー、肝心の爆発機能が全く定義されていない。これはHIT処理に付加する形となるが、たぶんこの作業は難しくはなさそうだがさして時間がかからずにすむ、というわけにもいかなさそうなので朝に回すか…。

はあ来週はセミナーがあるうえ、すかさずその週末に模試、さらにまた5日後にセミナーという超ハードスケジュール。それでいて予備校はほぼ毎日あるし、おまけに塾講師のバイトまでかかっているようで…。この超多忙スケジュールはヤヴァイ…。

2-4 連鎖システムを構築

とりあえず落下と連鎖システムを構築して、球が入ればそれでどんどん連鎖するようになった。ついでに各列の爆弾の発生状況も変数に格納して以後の操作をスムーズにできるようにもしておいた。
いやしかしなんというか、連鎖するときのブロックの「ジャンジャン」の音に伴う色や透明度の変化を再現するのは難しい。

なお、爆弾と化したブロックは先に連鎖で爆弾になったものの順から先に落下してくる性質があるらしく、さらに同じ連鎖数目で爆弾となったものは上のマスのほうから順に先に落下する爆弾となる模様。もちろんこの法則にしたがって爆弾つめあわせセットを構築しておいた。

次からは、爆弾が降ってくる処理とHIT時の起爆処理を中心に行っていこうと思っている。
振ってくる処理は内部的には下から空白マスを見ていって発見すればそこから爆弾格納部分を1個目から投入するだけ。
HIT時の起爆処理は自分自身HITまたは自身が起爆により消える判定ONかつ自身が爆弾、という条件になる。ちなみにこれと似たような動作はかつてのアニマロッタ風ゲームのアニマドロップみたいなゲームで実装している。
これらができればいよいよ配当の判定が可能となる。

結構すぐ終わりそうに見えるが、たぶんいろいろあってあと数日はかかるのではないかとみている。なにしろいそがしいもので

2-3 番号のみ配置

爆弾の設置は後にして、まずはとりあえずシャッフルされた1~25の番号を振り分けるようにした。

現段階では回収期などの数字位置偏りは考慮していない。
ちなみに細かいところなんだが、番号の背景にはうっすらと爆弾が表示されるようにしている。なぜかというと本物もそうなので。（意外と気づいていない人も多いと思うが)
これは消えたのちに爆弾が出現することを示唆している。
描画方法としては普通に不透明度50程度でマスと数字の間にピクチャ番号を設定しているだけ。
しかし現段階では、もはや何もゲームとして成立していないので、ここからいよいよ本格的なプログラミングへと移っていく。

やるべきことは大別して3つである。

1,HITによる待機モーションからのマス消去
2,落下処理
3,連鎖処理

この3つができれば、あとは配当や全消し判定などおまけとなる。
まあ結構リーチ処理は長い作業になるとは思うし、これをどう処理を軽くするかが重要になるが…。

1については所定数ボールが入るまでは点滅状態にさせておいて、その後マスを消して落下処理に移る、というまあ特に難しくない処理。これもよくプレイ動画をみて演出をまねする必要がある。
2について以前は下の空きマスをみて空きがあれば1マス下に移動、それを繰り返す、という操作を行っていたが、どうも実際は下の空きマス分すぐに移動させるほうがいいと考えた。自作カラコロッタのあにまだまではすでにこれを採用しており、本物さながらの動きを導出できている。
下のマスに空きがあるかどうかは普通に6マス後の状況を判定していくだけなのでここも非常に簡単。
3については、これはまあ以前失敗したのを生かしてちゃんとしておく。
とはいえあにまだまとは違ってグループ分けの操作が不要なので2つつながって消滅、という連鎖ゲームは作りやすく、処理も軽くて済む。
まあすでにチェーンボンバーみたいなゲームは1年以上前に作っているような気がするので、現段階ではこれくらいできなければ、という心持ちで作成するか…。

以上3つは、まあもう見え透いているやり方だが、やっぱりこれを実際にやるとなれば
時間がかかるんや…。また来週にセミナーをしかもLATEXを使った資料で発表なのでこれもこの1週間でいきなり使いこなさなければならん…。
しかもその発表が終われば今度はすかさず全国模試があるし…。

もう多忙や…。

2-2 チェーンボンバーマス配置

まあここまでは以前にアニマロッタ風ゲームで作ったことがあるので、それをよりよくコンパクトに(位相空間的な意味ではない)まとめておいた。

このあたりはもはやただの作業である。

今後チェーンボンバーを作成するにあたり苦労しそうな場所は、しいて言えば特にみつからなそうな気がする。なぜならばユーザーの介入が入らず、ゲームの流れを定式化しやすいからかもしれない。

ちなみに、上の画像のチェーンボンバーの配置は我が最低条件「となりあうものは色が位置しない」に基づいて適当に配置させたものなので、実際のアニマロッタでこのカードはでないかもしれないが、…まあ一人でやっているのでチェーンボンバー大辞典みたいに600種類以上のカードを全部手打ちとか、もうそれだけで嫌気がさすのでここはまあ…。

まあゲーム開始前に色の変更(組み合わせ?は変わらないが)ができる処理は後でもいいので保留。ゲームが開始すると爆弾と番号を配置するシステムをこれより構築する。

2-1 チェーンボンバー背景設定

さて、そろそろ新しいゲームを作るとするか…。LATEXで行列一つ表示するのに小一時間悩んだ我は休憩がてらに作ることにする。ほんまあれなんか使いづらいわ…。

とりあえずがんばってチェーンボンバーのピクチャをがんばって加工して作った。

1-32 FREE数別に見るPO率推移

まあこれくらいならやってもええやろ…。
というわけで、今度は普通のアニマロッタと同じく、シンキングタイムまでしか移動を許さない、という仮定のもとビンゴバルーンをおまかせにした場合のPO率の推移をウディタで作ったグラフとして貼り付けることにする。

なお「おまかせ」の基準だが、これは次の1球で配当が最大のものを若い番号から選んでいき、その中で最大配当が全部0だった場合、リーチの場所を若い番号から当てはめていき、それでもなかったらランダムに配置する、という条件だったはず。

本物のアニマロッタは4個ラインまであと2つでFREE2個ならうまく4個ラインを作ってくれるが我のおまかせはそんなことはできていないので、まあ実際にはアニマロッタの「おまかせ」あるいは自分でバルーンを設置すれば、ほぼ間違いなくこのPO率を上回るだろう。

上から順に、FREE1個、2個、3個の順番。うまく配置しないとFREE3個ですらだめらしい。
さて…デバッグモードらしきものも作ったし、そろそろビンゴバルーンも完成間近か…?あとは「おまかせ」ボタンの挙動くらいか…。

1-31 PO表示機構構築中

現在、宣言通りグラフにしてPO率の推移を表すものを作成している。
なんか1ゲーム目だけ表示がおかしいというバグがあるが、これはいつか修正予定。
これまでシンキングタイムなど込みで1ゲームを回すのに時間がかかっていたが、
ウェイトを大幅に減らすことによって1ゲーム3秒程度で終わるアニマロッタに一時的になった。それにより、とりあえずたくさんゲームを回してPOの挙動を見ることにした。

高速にするとピクチャのウェイトなどの関係上、演出が表示されなくなったりするが内部処理はちゃんと行われているみたいなのでセーフ。

なおグラフはどう描くかというと、普通に図形表示コマンド<LINE>を使うだけ。

以下は我の自動配置システムを用いた、ビンゴバルーン8面での常時FREE3つ、しかもシンキングタイム後も動かすのを許可する、という相当緩い仮定の下でのPOを示すグラフである。なおこの画面には右クリックで遷移し、また右クリックでもとのゲームへ戻るように設定してある。
1つ目が降り切れているのは、突然オッズアップ付き7個ラインが成立したからである。
まあこのシステムを使えば、もちろんPO率をいろんな条件下で求めていけるが、それをするなあ普通にmathematicaでプログラムを書いたほうが速いので特に意味のないこととみて今回はそこにはあまり立ち入らないことにする。

うんなんか…トータルINが17600?たしか1ゲーム800BETなので22回…。
しかしグラフは明らかに100回分くらい表示されている。
これはのちに修正した。

これができれば現在POと設定POとの乖離状態がわかるので回収期、放出期をつくることができるようになるわけである。

1-30 自動配置システム実装

変数のON/OFFにより、自動で配置してくれるシステムを実装した。
まあまだシンキングタイム後にも動いてしまうが、そこはたったひとつの条件分岐を加えるだけなので気にしない。これにより、配当やリーチが相対的に増え、ゲーム画面が華やかに。

ちなみに、ウディタでのグラフ描画のめども立ったので、そろそろデバッグメニューを作成してもいいかと考えている。

1-29 IN/OUTグラフの表示

デバッグメニューではIN/OUTの管理などをしようと思っている。
その中でPO率やIN,OUTグラフを作りたいと思っている。まあINはさすがにいらんか…。
とりあえず個別POを描画してみたい。
だが、ウディタでのグラフ描画はそう簡単ではない。
mathematicaならlistplotでもはやほぼ何も考えずにおしまいだが…。

とりあえず、PO率は最大値は5000%を超えるが、少なくとも上限値20000%くらいではおさまるだろう。しかしもし100個のPOデータがあり、1つだけ10000%とかでほかが50~100%程度におさまっていたら、同じ大きさのグラフでは縦方向に圧縮せねばデータを表現できず、これは非常に視覚的にもよろしくない。

とはいえ、そのようなことはあまり起こらないので、これだけを例外としてもいいだろう。
つまり、縦軸は最も下の軸をPOが0%、つまり「もう1回だにゃあ」あるいは「次こそGETするポギン」状態で上の軸はたまに発生頻度のある10倍程度かよいだろう。

さて、その下の軸をy=500、上の軸をy=100とするとき、どのようにPOに応じてyの値を定めればよいのか。
まあこれは簡単な話で、例えばPO350%ならば、yが400分で1000%分、ならば350%分はy座標が下の軸から140移動している。したがって描画すべきy座標は500-140=360となる。
x軸は、過去100回分のデータを記録するとするならば、左からn個目のデータは、とりあえず累計回数が100まではそのままn個目でよいが、100+k(kは自然数)回累計で行われるとn-kになるはず。
まあこのあたりは簡単な定義で済む。
だがや…。
どうやって折れ線を引くんや。

折れ線が点の集合とみなすと2点間の座標を100等分くらいする点を集合させれば疑似的に線を作ることはできる…がなんか…。
確かウディタには<LINE>とかで折れ線を引けるコマンドがあったような…。
まあ使ったことないが、今回初めてその恩恵にあずかってみるか…。

1-28 バルーンの良解の探索

我は機械学習に全然詳しくないので、ビンゴバルーンの最適解を求めることは時間がかかりすぎて非常に難しい、ということが実際にmathematicaでプログラミングしてわかった。

じゃあしょうがないので最適解ではなく良解を探そう、ということで基準を定める。
各ボールが次に入った時の最高WINをFREEとして配置、という具合。なのでこれだと、FREE2個でその2つで7個ラインが成立するときでも、それを探索できないのが弱み。
まあ店舗側などからしたらPOが減るのでありがたいからそれでいいか…ていうか自分でやるためのものなのでそんなんも関係ないが

とりあえずそういう具合でおまかせ配置をさせてもよいと考えている。

1-27 内部リザルト処理

まあとりあえず、リザルト画面は以前カラコロッタでつくったもののピクチャを変えて流用すればいけそうな気がするような…。
それはともかく、我はちょっとPO率推移などをやってみたい、というのが思惑にあるので、その話を以降していくことにすると思う。

リザルト処理はどうするかというと、各ゲームのWIN数を足し合わせるだけ。
もはや何も言うことはない…。

ただ問題なのは、次ゲーム開始処理である。何が大変かというと、
それぞれコモンイベントは1ゲームで使われており、変数値がもとのままでないのでうまく動作をしてくれない。とするともはや…。
全コモンイベントを初期化、するしかあるまい…。
これにはある変数を持ってきて、その変数が1ならばコモンセルフ0からコモンセルフ99までのすべての値を0にし、かつイベント処理を中断、という作戦になる。
まあこれまではその作戦でやってきたんだが。
ビンゴバルーンだけでコモンイベントは130個くらい?作っているので、ふう…面倒やな…。ただこれをやらないと確実にアウトなのでやるしかない。

それが終わったら、デバッグメニューを作成しようかと思っている。
具体的に何をするかというと、PO率の管理やWIN枚数の推移などである。
背景が黒色の画面で、白色の文字を用いて表現するのはアニマロッタのデバッグメニューと似ている。文字列をピクチャとして描画してくれたりもするのでありがたい。

とりあえずそのあたりをやってみるか…。

1-26 BETタイムだいたい完成

ついにBETタイムがだいたい完成し、こちらが持っているCREDITに応じてBETできるようになった。加えてその後のゲームスタート処理を合わせることにより、なかなかそれっぽくなったような気がする。
それを動画にしてみる。

なんかアニマロッタらしくなってきたような気がする。
今度はリザルト画面を作成し、ゲームがまわるようにする。

1-25 BETタイム作成中

とりあえずゲーム開始時のSTARTの文字列が右から出てきて左にさようならする演出を作った。あとはBETタイム時の挙動である。
とりあえずこの間は並立処理でボタン判定(クリックとXY座標によって定まる)を8ゲーム(超マルチの場合は)をしてBETをしていく処理を行う。

今回はREBETの機能も入れるつもりなので、以前の自作ゲームに比べるとさらに煩雑性を増す。とりあえずこれができれば、自由にBETしてゲームをだいたい行うことができるように。そして後はリザルト画面を作れば、いよいよゲームを回すことができてPOとかの話に持っていくことができる。なにしろプログラミングといってもただ値を出すのではなく演出まで加える必要があるのが大変。ただその代わり、見栄えはよくなる。

1-24 シンキングタイム実装

まあとりあえず現在は単純に、残り10秒から一斉にスタート、ということにしている。
必要に応じてプログラムは変えていく予定。そもそも今の段階では有無を言わさずこれが出てくるので、ビンゴガーデン、ビンゴバルーン以外はこれを出してはいけないという状況についてはよろしくない。ただそれは後でそのときに修正を加えればいいだけ。

ちゃんとシンキングタイム終了後の禁止マークも再現。ただ通行止めマークのところを進入禁止にしてしまった…?

1-23 ビンゴバルーン仮完成

オッズ表に関して、オッズアップ時、あと表を超える配当のところがまだできていなかったがまあそれは後でいい。とりあえず残りFREE使用数が書かれたミニ雲配置。

一応ゲームのタブを変更しても動作することは確認済み。まあなんかややこしくてやっている感があまりないが。
ひとまずこれでだいたいのビンゴバルーンの動作にひと段落ついたことになる。

となると次やるべきことは何かというと、ビンゴバルーンの最適解探索…だがFREE2個とかになると大変なので最適とはいかないまでも良い解を得たい。ということで次からはその話をしてもいいかもしれない。

今度はBETタイム、シンキングタイムの明確化、リザルト画面、そして次ゲームへの接続である。これができればゲームを回すことができ、さらに良い解探知システムが組み込めればおまかせとしてビンゴバルーンのPO率をプレイしながら知ることができる。


おまけ:我もハイベットするぞ…うん配当が少ない…?

おわた

※右下になぞのオッズ表があるがこれは右のアクティブが上から2つ目の時に、上から1,3,4番目のやつを縮小モードにし、かつオッズ表などを消去する、というズーム処理の部分であやまってピクチャ80000台(右下のゲームはピクチャ80000台で制御されている)とするところを70000台にしていたため、ピクチャが消去されなかったために起こった事態。修正完了。

ちなみに言っておくと、動画やスクリーンショットにしたものより実際のゲーム画面は画質が良い。いつも貼っている画像よりもう少し良い感じの画像になっている。
それでも解像度はウディタだと1280*720程度なので、これ以上だせないためにやはり粗がでるのが残念。加えて手作業で画像を加工しているのでやはりこれも粗が。

1-22 オッズ表強化

現時点でのGET状況、さらに次の1球で期待できる役を示した演出がたぶん完成。
ちょっと解説するために意図的に「手入れモード」にしている。

この画像で説明したいことは何かというと、右下の番号表示がバグっていることはともかく(普通のパターンではうまく動作しているので特に問題ない)
GET!とリーチの文字がオッズ表に加えられているというところである。

まあこれは単純な考えで、次のリーチで成立しうる配当役の部分のものを1~25のリーチに対して行えばよいだけの話。現時点での確定はそれに加えて変数の値を変えて区別している。もちろんシンキングタイム終了までに自由にバルーンを組み替えてもちゃんとこのリーチやGET!の状況はそれに応じて変貌する。1秒弱のラグがあるが…。これを解決しようとするとたぶんウェイトを減らす必要があり、そうなると処理が危うくなるかもしれないのでやっていない。

じゃあちゃんとこのリーチ、GET機能が動作しているのかを確かめる。
複雑な状況を再現するために8回の抽選は我が強引に指定した。左側で考える。
現時点では確かに4個ラインが成立しておりそこが光ってGET!となっている。
13番に入った場合4個ラインは2つ、25番に入った場合4個ラインは3つとなる。なのでその両方のパターンが網羅されており、これらにリーチの文字が表示されている。
なお13番で4個ラインが2つとならない場合は、25番そのものが4個ライン1個から3個への昇格、ということになるので、4個ライン2個の部分にリーチはつかないようになっている。
それ以外は特筆すべきことはないので省略。
でもちろん25番の配当は当然10倍を超える(15倍)ので文字は紫。

これでほとんどの作業が終わりに近づいてきたといえる。

じゃあ次はなにやんねんというと、やっぱり残りFREE可能使用数の明記である。
これもインターネットから画像をダウンロードして、残したい部分の外側をペイントで手作業で黒く塗って…ということから始める。
こんなことからやっている我なので、途中で飽きてやめるのもわかるだろう…。
行き詰ったからやめるわけではなく、興味がなくなったからというだけ。
ただこのFREE可能使用数、ゲームモードによって移動するのでめんどい…。
まあとりあえず気にせず大きな雲の右下にしておくか…。

1-21 HITでFREE追加を追加

誤字ではない。特定の値がHITすることによってFREEが追加する機能を追加したので。
どういうことかというと、普通に[+FREE]のマスに入った場合、配置可能FREE数が1個増える、というものである。これまではFREE25個とかいう無茶ぶりで遊んでいたが、以後はこれになる。

これにより、もう実際にゲームで遊ぶことが可能な領域まで来ている。まあリザルト画面すら出ないが。なおもちろんのこと、+FREEの文字はシンキングタイム後に消滅する。

次は「あとn個FREEを置ける」というミニ雲と一緒にある文言を各ゲームの右下に添えることが必要。まあこれは非常に簡単な作業。

しかし、ここまでくると避けられないのが以前から言っている「おまかせ」機能である。
これはまだ我の思考では最適な方法がFREE2個以上に対して求められない…というか求められるが時間がかかりすぎる、という難点がある。
FREE1個ならば大学のmathematicaにすでにプログラムを組み込んでいるのでそれを動かすだけ。あれもやはり53130*25*1140通りの試行を要求され、単純にビンゴガーデンの3.125倍の時間がかかるので72時間程度はかかるか…。
ただ、こちらはビンゴバルーンの左右、鏡面などの対称性からその試行回数を実質1/6やそれ以下にできるので、結局はたぶんもう少し早く終わるとみている。
まあそれでFREE1個はいいんだが…。FREE2個…。
これは単純にFREE1個の最適解にしたがって配置し、その後残り1個を最適解にしたがって配置する、ということが無理。例えばあと2個で7個ラインというとき、確実に2個一気に配置する最適解はそれを優先するが、そうでないときは7個ライン成立を選ぶかどうかはわからない。しかもそもそも、2個目を選ぶときは1個目がすでに埋まっているので6個マスが埋まっている状況になり、最適解は5個埋まりの状況(25C5=53130通り)に対して与えられているのでそもそも定義すらされない、という問題が。これは致命的である。

しかし結構FREEが2個になるパターンは普通にある。これはいかん…。
まあ実際のアニマでも最適解を選んでいるとは到底いいがたいシーンばかり(というか我はそれを信用せず全部自分でやる)なので、この配置アルゴリズムを解析したいがそんなことまではやりたくないというのが本音。

とりあえず残り使用可能FREE個数表示は早急にやるとするか…。

1-20 動画にした

とりあえず現時点での進行度合いを静止画ではなく動画で見せることにしよう…。
まだまだ問題点ばかりだが、遠くから見るとそれっぽい挙動をしているような気がする。

これからの課題点としては、先ほどのべた通りオッズ表がもはや無意味状態であること、リーチ文字表示中にFREE配置を受け付けないこと(原因は呼び出しによるウェイトがかかっているからだがこれを並立にすると処理が重くなるかもしれない恐れにより直ちに実行しづらい)、あとは使用可能FREE個数の話がまったく実装されていない、そもそもりんごはどこやねん問題。
そして我を悩ませる最大の問題、それがビンゴバルーン最適化問題。
理論上は計算により求まるがその膨大な計算時間ゆえほぼ不可能という問題。
FREE1個の最適解ならたぶん1日あれば求まりそうかもしれないが、2個以上ともなるとそうはいかん…。単純に考えてFREE4個ともなるとたぶん兆レベルのオッズアップ処理が必要に。
これらの課題は、あまり難しくはないが実際に実装するとなると1日程度ではできない。なにしろ全部一人でやっているわけなので。画像も効果音もBGMもすべてカットやコピペ、透過処理などでがんばってつくった。

セミナーなどで忙しく合間を縫って作成したとはいえ2週間でまだこの程度…ということはおそらく完成する前にこれは飽きるな…。

ちなみに次に作るゲームはチェーンボンバーあたりを想定している。
ワンダーとサンダースマッシュはそれっぽいのがすでに作ってあるので流用するか…。

1-19 リーチ演出強化

いよいよリーチ演出が強化された。具体的には、タブの部分にリーチ番号が新たに発生、あるいはリーチのグレードがアップしたときにそれを表現するように。

これにより、タブ部分はリーチ番号のスライド式表示、そしてオッズアップ番号の表示、さらにオッズアップ時、nラインビンゴ時、各種期待度別リーチの表示、配当表示とだいぶんにぎやかになってきた。

実をいうと、結構ここまでくると難易度が上昇してきている。

どういうことかというと、かなりのプログラム量となるため、いたるところに隠しウェイトやその他さまざまな工夫が必要となっている。

バルーン以外ではたぶんこれほど重くなるゲームはたぶんないと期待しているが…。

あとやるべきこととしては、FREE関係の処理、そしてオッズ表がオッズアップで羽根井されたりGETした部分を明滅させる、あるいは7個ラインリーチのときのバルーンの演出など。現在はFREEを25個おくこともできる状態にしているので、この部分は当然後で変える予定。

1-18 BETとボール履歴

ついにBET額が表示されるようになった。さらに、ボール履歴まで表示されるように。

だいぶん我の求めるビンゴバルーンっぽくなってきたような気がしないでもない。

1-17 配当表示演出

ついに獲得配当が表示されるようになった。ちなみに全部10BETという暗黙の了解。
しかし10BETとかどこにも書いていないのでもちろん今後はそのBET額関係をタブ及び左下の部分に描画したり、入った番号の履歴を右下に描画したりする予定。

それらが終われば、いよいよゲームとしても成立(1ゲームだけだが)するようになるので、久しぶりの動画化を考えている。まあyoutubeにはアップロードしないが。

我はあまり一般と合わないような気がしないでもないので、自己満足的にこのブログで遊んでいるだけにとどまり続けている。そして今後もほぼ確実にyoutubeなどをやることはないだろう。

一つ疑問に思うのが、なんかほかのウディタのゲーム作成などを見てみると、3Dを作ったりしている人もいるので、アニマロッタの作成くらいならここで述べなくても意外とできる人ばかりなのではないかという疑問がしばしば起こる。
いったいそこのところはどうなのか我も知らない。

1-16 ビンゴ演出(2)

いよいよそろったラインに線が引かれるようになった。これでどこがビンゴかわかるように。さらにオッズアップを示す処理も追加した。これにより、FREE追加関係の処理以外はだいたいできたことになる。

次に行うべきは、配当表示である。すでにこれは以前作った雛型があるので、それを用いることにする。

それが終わり次第、そろそろゲーム繰り返し処理などに手をつけていこうかと思っている。結構ビンゴバルーンは予想外に作るのに手間がかかるので。その理由は何かというと、やはりボールが入ると処理が行われるのではなく、ユーザーがバルーンを2ndロッタの後まで自由に動かせ、その都度ビンゴやリーチを判定しつつ、あと赤と黄色バルーンの区別を考えながら処理を行うという点で難しいからだろう…。
なお、本物のアニマロッタ5と同じく、配当があればピンク色、配当が2倍以上で紫色、ということにする。たしか初代は吹き出しが丸いかとげとげかという違いだったが。

1-15 ビンゴ演出(1)

なんとかリーチ処理の軽減ができたので、次はビンゴ演出となる。

具体的にやることとしては、シンキングタイム終了後、6,7,8球目終了後のビンゴ判定となる。すでに配当などは求まっているので、そのあたりのフラグからビンゴ判定をひっぱってくればよいのでフラグ建築はたぶんすぐ。

以下はその施策例である。ただ演出の問題なので解説は別にいいか…。

とりあえずビンゴになった判定は行ったので、次にやるべきは配当の表示である。
あとはオッズアップ表の該当部分にGET!の文字と明滅処理。
明滅処理に関しては、オッズ表の背景それぞれのピクチャに分けていないので
わざわざピクチャ10個を作る必要がある。ううんなんか面倒やな…。

以前と違って以下に処理を軽く、かつこちらのプログラム入力の手間も省くかに焦点を置いた作り方を最近はするようになったので、8ゲームモードにしているとはいっても実質1ゲーム分とあまり変わらない。しかしやっぱり8ゲームモードは自分で作ってみるとなかなか面白い。まあほぼすべてのピクチャ番号が変数指定になって難易度が上昇するが。

あっそういえばFREEのマスとかの処理もしなければならないので、これはまあどこかの間に挿入しとけばいいが、「あとFREEn個置ける」旨を伝えるピクチャもそういえばあったのでそれも付け加える必要がある。

ただ、配当表示を先にしたほうがなんか見栄えがよくなってうれしくなる気がするので、先にそれを行う。こちらはアニマと違い、配当表示は斜めにしないことにする。
そうするといろいろ面倒なので。そのかわり、配当が出てくるときの数字の回転処理、そして配当部分が明滅を繰り返す部分は再現するつもり。まあすでに2作前のゲームで実装できているのでそれを持ってくればいいか…?

あとそれと、ボールの入賞履歴はそろそろ作っておいたほうが後々のことも考えるとよいかもしれない。BET,WIN,CREDIT欄は配当処理などの後でいいだろう。

それらがいろいろ整ったら、デバッグモードでも作って日ごとのプレイのPO管理画面でも作ってみるのもよいかもしれない。FREE4個のときの最適解の期待値などはちょっと大変すぎてシミュレートできないので。

1-14 リーチ処理緩和

いろいろがんばって、先ほどまでの処理の重さがどうしようもなかったので、それを軽減。ゲームの上部に出ているEv処理が常にほぼ40や60とかだったが、ようやく10前後に押しとどめることができた。

そろそろビンゴをしたところにラインなどを引いていこうと思っている。
ただこれ以上並立処理を増やすのもなかなか負荷がかかりそうで問題なんだが…。

その後、処理を1個にまとめることにより相当な処理の軽減を実現した。
これで心置きなくビンゴ処理にとりかかれる。

1-13 リーチ処理演出(4)

とりあえずある程度リーチの処理などを行い、8ゲームにしてみた。

やっとアニマロッタっぽいものになってきたような気がしないでもない。

1-12 リーチ処理演出(3)

いよいよリーチっぽい演出が少しずつ整ってきた。上の画像では現在の配当はないが、
12,19,22に入れば配当は得られないがビンゴが一応成立する。14に入ればオッズアップ効果と4個ライン2個により配当は4倍つまり赤色で表示されている。
これらはアニマロッタ5の定義に基づく表示であり、我の作成したプログラムはこれを体現している。もちろんこのあとにはオッズアップの候補が「23,24」と出てくる。3はすでに入っているのでオッズアップの候補に入れないようにしている。

あとはこれらの演出を左上に平行、拡大縮小移動させておいて、これを8ゲーム化すればついに我の思い描いていたビンゴバルーン8面がかなり形になる。

ここからは祭や！といいたいところだが、セミナーの発表が本日控えている我はブルーな気分や…。

1-11 リーチ処理演出(2)

とりあえずリーチのマスに演出を加えることにした。

ちゃんと演出なので動く。次はHITしているマスを明滅させることが必要。

あとはバルーンにも動きはあったか…?

その後はオッズ表で今どのオッズなのかを示してみて、そしていよいよタブ部分のリーチ表示とオッズアップ表示を行っていく。

イメージとしてはこんな感じ。

あとはこれを配当ごとに色づけたりリーチのピクチャを付けたりすることになる。
まだアニメーションしていないのでそこをがんばらなければならない。

1-10 リーチ演出処理(1)

あずはリーチ演出をするための条件を考える。
ビンゴバルーンは、ただ配当が大きいものをリーチと表示するだけではなく、大きく分けて、「リーチ」と「オッズアップ」の2つがある。
そして特筆すべきは、配当が増えなくても、つまり3個ライン1個となる期待がある場合でもそれはリーチとして扱われるのである。

すると、まずはリーチとして描画されるべき番号はどのように考えるかというと、
これは各7,5,4,3個ライン数いずれかがリーチ処理によって1つでも増加したもの、ということになる。これは今しがたプログラムを組んでどの番号がどうかの判定を行っておいた。
当然重複する番号では増加するはずがないので、この定義によって自然にはじかれる。

そしてそれらリーチの番号に対して、リーチ処理後の期待オッズを3以上10未満、10以上、それ以外に場合分けし、10以上のものは特別に拡大縮小処理を行う。

リーチに関してはこれでよい。

オッズアップについては、黄色バルーン状態のものだけが対象となる。これはわざわざプログラムを組むというよりは、もはや明らかなのでその必要はほぼない。そしてそれがHITした後の状況はリーチ処理のほうで一括処理しているのでなんの問題もない。

そして期待値別の色分けはリーチのものと同じ。

これらを用いることにより、我の思い描いたゲームタブにリーチ→1 2 6 10などの番号をアニマロッタのように表示することができるわけである。
そしてそれを8ゲームモードにしたら…。これはきっと圧巻だろう。感動もんやで

なお、ビンゴバルーンのゲーム画面のほうのリーチ!の文字の扱いも、当然ゲームタブ側のリーチの番号に準ずる。

ちなみにアニマロッタ5の仕様通り、シンキングタイムが終了するまでリーチ番号は示さないことにする。これはユーザー操作が入るものがそうなっており、ビンゴガーデンとこのビンゴバルーン以外はそうではなく、最初からリーチの文字は普通に出る。たぶん。

とりあえず表示させるだけさせる。

1-9 リーチ内部処理

とりあえずリーチの内部処理がおおむね終わった。各番号が入った場合のラインを計算し、そこから配当計算の関数にかけて、そしてあとはオッズアップの処理。
例えば上の状況ではすでに4個ラインが成立しており、さらにオッズアップが1個あるので配当は2倍となる。このとき、6番に入ればもともと2倍でオッズアップ1個なので4倍、12番も同様。そして11,20,23に入った場合はオッズアップが2個で結局の配当は3倍に。
以下はデバッグによりそれが端的に示されたことを意味している。
1番で現2 新2 -->[ｺﾓﾝ39/526行]
2番で現2 新2 -->[ｺﾓﾝ39/526行]
3番で現2 新2 -->[ｺﾓﾝ39/526行]
4番で現2 新2 -->[ｺﾓﾝ39/526行]
5番で現2 新3 -->[ｺﾓﾝ39/526行]
6番で現2 新4 -->[ｺﾓﾝ39/526行]
7番で現2 新2 -->[ｺﾓﾝ39/526行]
8番で現2 新2 -->[ｺﾓﾝ39/526行]
9番で現2 新2 -->[ｺﾓﾝ39/526行]
10番で現2 新2 -->[ｺﾓﾝ39/526行]
11番で現2 新3 -->[ｺﾓﾝ39/526行]
12番で現2 新4 -->[ｺﾓﾝ39/526行]
13番で現2 新2 -->[ｺﾓﾝ39/526行]
14番で現2 新2 -->[ｺﾓﾝ39/526行]
15番で現2 新2 -->[ｺﾓﾝ39/526行]
16番で現2 新2 -->[ｺﾓﾝ39/526行]
17番で現2 新2 -->[ｺﾓﾝ39/526行]
18番で現2 新2 -->[ｺﾓﾝ39/526行]
19番で現2 新2 -->[ｺﾓﾝ39/526行]
20番で現2 新3 -->[ｺﾓﾝ39/526行]
21番で現2 新2 -->[ｺﾓﾝ39/526行]
22番で現2 新2 -->[ｺﾓﾝ39/526行]
23番で現2 新3 -->[ｺﾓﾝ39/526行]
24番で現2 新2 -->[ｺﾓﾝ39/526行]
25番で現2 新2 -->[ｺﾓﾝ39/526行]（数字nはn倍のオッズを表す)
本来定義されない同一番号への入賞可能性があるが、まあこれは後で除外するだけなので(具体的には25個それぞれの番号がこれまでに入った球と一つも一致しなければリーチの対象とみなす、という具合)
アニマロッタ5の配当表示の作法によると、3倍以上は赤色表示なので、この場合すでに6,11,12,20,23が3以上なので赤色となる。

配当の大きさに関する話はこれでいいのだが、一つ問題点がある。
それが、配当0でも現在ビンゴより大きければリーチとして扱う、という話である。

ということでそのプログラムも作っておいた。
次の記事ではリーチの演出をどのようにしていくかを考える。

1-8 ビンゴ、リーチ処理

ビンゴの条件とかは、もはやいうまでもないので省略。
リーチの条件については、いつも通り1~25に入った場合に演出抜きのシミュレートをしてその枚数に応じてリーチのグレードを決めるというもの。

アニマロッタ5の場合、3倍以上のリーチは赤色、10倍以上のリーチは紫色で表示される。
そのn倍以上、というのは最終的な配当を示しており、現時点からの配当増加ではないことに注意。例えば5個ラインオッズアップ×2のときは、それ以外のライン成立は少なくとも3個ラインであっても赤色である。これはなかなか実際やっていると紛らわしい…。

ただ我はアニマロッタに似せる、という理由からもちろん表示はそれと同じ方針。
オッズアップも表示することにする。
そうなるとちょっと難しいかもしれないが、こういうのはセミナーの発表に比べればもはや息抜きでしかないほど簡単なことなのである。
そんな難しいセミナーが隔週でだいたいあるもんやからまいるわ…。
もうあと3日後にはそれが控えているので、準備しなければならない。
よって更新頻度が遅くなるだろう。

あ、それとリーチはもちろんゲームのタブだけでなく本画面側にも反映させたい。
なんか7個ラインが成立しかけると全部のバルーンのふちが光ったりする謎のエフェクトがあるが、あれも実装してみてもいいかもしれない。

1-7 黄色バルーン配置

黄色バルーンはユーザー側の操作によって成立する。ただ、この操作はドラッグ状態、タッチ時にどのバルーンがどう動くか、タッチ座標など相当定義しなければならない難しい動作であるといえるだろう。ビンゴガーデンの比ではない。

まあとりあえず、タッチ時の挙動を考えようか…。
とりあえずマスの座標を呼び出してそこ中心の座標からＸ軸方向とY軸方向の距離がともにある値以下という数学で言うなら絶対値のグラフのようなものを考えることになる。
ちなみにそのある値は28である模様。
しかも何が厄介かというと、これは超マルチ時で成立するものであって、シングルなどだとまた別に定義しなければならない。
ここはなんとかしてプログラムの行を減らせるように工夫したいところである。

とりあえずすぐ思いつきそうなやり方は、ビンゴバルーン面のズームの定義により、これもそのように移動させてしまうという手で、
例えば中心(-900,150)でズーム75%にしている。つまりこれは中心座標へのピクチャの一斉平行移動とともに、各ピクチャの中心からのベクトルを75%に縮小して描画しなおしているはずなので、(300,400)のものはというと中心からＸ軸方向に1200,Ｙ軸方向に250の移動とみなせて、これを75%すると900,187あたりになるので、それを(-900,150)にそれぞれ足すだけというシンプルさ。
こうすることにより新たに座標範囲を指定せずに既存のもので楽にできる。
昔はこういうことをしなかったので必要以上にプログラムが長引いたんや…。


それはそれでいいとして、
次にすでにバルーンが2個置かれていた時、残りバルーンが0個となった場合にタッチ操作をした場合が問題で、これはたぶん一番最初に置かれたものから移動していく、という挙動だと仮定しておく。となるとそのタッチごとにバルーンを置いた順番を最高で4つ変数を定義しておき、それをシフトしていくプログラムが必要となる。

まあいろいろがんばった末、ドラッグ禁止条件のもとFREE1~4個を置いた履歴に従って上書していくことができるようになった。
もうここまでいけば、ビンゴ判定とオッズアップ判定があれば一応ゲームとしては最低限の要件を満たしているともいえるかもしれない。まあバルーンに描かれた番号を表示する必要があるし、その他リーチやラインの演出も必要なので、できたとかいうどころかまだ始まったばかりだが。
ドラッグしてバルーンを移動する操作は別に実装しなくてもよいと思うし後でもできるのでこれは保留しておく。

次にやるべきことは、バルーンの上に番号を書くことである。
いかがそれ。ついでにアクティブタブを描画し、そうでないノンアクティブのものは不透明度を下げるように。

ある程度得体のしれない何かのゲームから逸脱出来てきたので、そろそろ背景を用意するか…。この後はビンゴ判定とリーチ判定を作ることになる。

さすがに夜から作っているとこれくらいしか進展しないか…。
またセミナーの難しすぎる発表もあるしこればかりやっているわけにもいかん…。

1-6 とりあえずタブ配置

上記のようにタブを8個配置しておいた。

あっ9個になってる
まあいいか…。理由も想像がつくし。7個ラインのピクチャ欠けはバルーンとの競合ピクチャが発生したため。修正しておいた。

さて、とりあえず赤バルーンの配置は終わったのだが、
ここからがおそらく最難関であるユーザー介入の操作となる。
おまかせ操作はどういうシステムなのかわからないのでとりあえずラインが成立する方向、ということで定めておく。最適解ではない。

次の記事ではユーザー側の介入が入る黄色バルーンの動作について考察していく。

1-5 オッズ表配置

ただ単にオッズ表を配置しただけ。ゲームモードによって描画位置や拡大率が変化するので、下が画面内に収まりきっていないが特に気にすることはない。

さて、配当表示が終わればなんとなくそれっぽいのだが、まだ何もゲームシステムすらつくっていない。いわばただの絵である。18についてはいつか消すので気にしないこと。

いずれにせよ、まずはゲームシステムの構築から始めていくことにしよう。

ゲームのルールはここでは省略する。

とりあえずあらかじめ画像を加工して作ったバルーンなどがIN番号に応じて表示されるように組む必要がある。とりあえずここからは8球の抽選が行われるシステムを作る。

でないと何も始まらないので。

1-4 ビンゴバルーンのピクチャ配置

ちゃんとアニマロッタっぽいフォントを探してそれを作り、そして色なども頑張って似せて配置してみた。もちろん複製前提で作ってある。少し手を加えるだけでこれの番号配置の異なるものを8個作ることもできる。
なおアクティブでない場合はたぶんこれのみがゲームタブに入ってくる形になるので
オッズ表などはその場合消去することになる。
まあとりあえず

1-3 ビンゴバルーンのプログラミング

ここではビンゴバルーンのプログラミングを書いていく。

とはいっても、もはや何も記述する必要がないくらいにおおまかな流れは見え透いている。

どういうことかというと、
番号抽選→各マスに赤バルーン配置かのチェック→FREEの扱い(常時、5球目終了まで)→虹バルーン条件→ビンゴ判定　とこのくらいしかないからである。

アニマロッタのプログラミングで難しい場所というと、やはりアニマドロップあたりだろうが、ここまでの記述でアニマロッタを作ろうなどと大それたことをいうからにはそれなりの理由がある。それも追々述べていくことにしよう。

それより「おまかせ」の基準が非常に難しく、悩んでいる。
あと、ビンゴバルーンのおまかせが最適解なのか、というのもなかなかに厳しい問題。
プログラムとしては単純だが、その試行回数が億どころか兆とか行く始末なのでこれはＰＣ数万台とかになって話にならん

FREE1個ならまあ数日あればシミュレートは終わると思うが、2個になるとその12倍になるのですでに厳しい。

とにかく暫定的なおまかせ配置を作っておくしかない。
あとシンキング終了後勝手に配置されるところや、2個以上のFREEのときにどちらのバルーンがどのように動くか、など。

ただ、まったく画面が完成していないのでなんともいえない。

5月5日は模試なので終日アニマロッタ作成はできない。寝よか…。

参考までに我が過去に作ったゲームをスクショを張る。

これだけは言っておくがウディタを最近一から始めた超初心者、というわけではない。
以下くらいのクオリティのゲームを一人で暇な時間に作ったりしている。