ゲームの進展状況63 最難関・リーチ処理

さて、我の作るゲームはなぜか新しく作るごとにシステムの構造がややこしくなっている…ということを踏まえると、今回のJPCのリーチ処理はかなり難しい(変数を膨大に使う)であろうことが分かる。
さて、リーチ処理というのは、現在の状態をどこかに保存し、その保存した領域内で1～25の番号を代入してみて結果をさぐりその結果をcselfか何かに出力して、各マスの番号を取得しその番号でのリーチ状況を見て、演出を決める、というのが普通のやり方?だと思う…。
この場合、演出はスキップするため、演出のためだけに必要な変数はカットできるので、いくらか演出つきより処理は早くなる。

とりあえずまずはJPCの説明をする。
10秒の猶予が与えられ、この間に番号がランダムな時間間隔で入っていく。そして10秒たてばその入っていったストックが全部HITすることになる。そして落下処理や段数増加が行われる。
そしてまた10秒猶予が設けられ…というのを番号が60個分入るまで繰り返す。
GETした(落としたあるいは消した)ドロップ数はJPC失敗時の配当に影響し、全消しの回数でJPになるかどうかが決まるシステム。

つまり、リーチ処理は、ただ単に1~25に入るとどうなるか、ではなく、
この10秒間の猶予の間に、それまで入ったストックの番号たちに依存して次入る番号のリーチ状況が定まる、という点に注意。
まあこれは、現時点での状況を把握して、それプラス1~25のいずれかに入った場合、を調べればいいだけなので見かけに反して難しくは無い。

だが、これ…。

どんだけ変数使う…?

とりあえず、まずはリーチを演出なしで表現するため、
番号HITの処理、連鎖処理、落下におけるグループ分け、落下処理の4つを改造してこれ専用につくる必要がある。段数増加以降は、直近の配当やJP判定を行うのでこれは依存せず、しかもランダム要素なので不要だし意味をなさない。
もしこれをやるなら、ランダム性をリーチ処理に入る前に決定しておかねばならない。
いわゆる、RPGでいうと何回リセマラしても結果は決まっている、というやつ。

実際には退避したものへの操作はせず、もともとのものを書き換え(一瞬なので並立実行していなければ書き換えてもOK)て後で退避のものを戻す(そのほうが書き換えが少なく楽)ことを行う。