実はこれ、ちょっとしたピクチャ番号のつけかたに失敗があるがわかるだろうか…。
まああまり大した問題ではないのでほうっておく。
注意すべきは30番目から31番目のマスへの移動で、
傾きを0にもどし、かつマスが緑色ものは青色に戻し、それ以外のマスは色を変えずに傾きのみ戻す。なぜか文字列ピクチャは回転できない不具合?がウディタにあるのでそのピクチャは特に傾きは変わらない。というか変えられない。
オッズアップの枠は最下段に来ると消える、という仕様から消去するようにしている。
ここで、以前の我は1マス移動するごとに変数を68個移動し、かつそれにたいしてピクチャも移動、それを繰り返す、という手法をとっていたが、このやり方だと、処理が重くなる可能性を見込んで一括移動作戦を考えた。
過去に作成したもので、チェーンボンバーのブロック落下処理やアニマドロップのドロップ補充処理でたぶんこのことについて触れていると思う。今回のも同様の事態になると見越していたのであらかじめ処理を軽減する方法をとった。従来の手法より手が込んだやりかたなのでほんの少し考えたが。
右側が描画されていないのは、ランダム設置ではなくてパターン設置型に変更させたため、未定義になってしまったためである。
あとは変数も一括移動しておく。これは移動先の変数位置が移動回数分シフトするだけなので、後ろの変数から順に代入処理を行う。(でないと上書きが起こる。この問題はたぶん変数Aと変数Bの値を入れ替えたいときのプログラムで初心者があれっとなるあの問題に類似している)
そうすれば処理を軽くしたまま、移動処理が完了する。
あとは何回移動処理を行うかだが、これは比較的簡単な場合分けによって可能である。
例えば32と67マスが雷マスとなった場合、8個の専用変数でも用意しておいて、
2個目と5個目に1を代入。
そしてそれぞれはじめと終わりから、はじめて1になる変数位置をサーチしていき、
その位置が一致しない場合のみにはさまれた部分を消去する、というプログラムである。
(一致した場合は最下段に雷マスが1個、ということになりこれはサンダースマッシュの落雷要件を満たさない。もちろん0個の場合はそもそもはじめて1、にすらならないので論外)
その後、左と右側の移動回数が直ちに分かるので、それだけ移動プログラムをループ。
これによっておおまかな流れができてくる。
実をいうと1年くらい前?にすでに簡易バージョンのサンダースマッシュを作っているので、やっぱり今回はよりクオリティの高いものを作りたい。
いやしかしこれ、初期配置パターンを手動でいれるという作業はどうしようもないので、
ここが根気のいるところや…。
↓両面移動実装
