はかせのラボ

私の頭の中を書いていく雑記ブログです

落ちモノパズル どんな感じで処理を作るつもりなのか説明してみる

あいさつ

どうも、はかせです。
今回は私がどんな感じでテトリスのパズルを
作ろうとしてるのかの説明をしたいと思います。

処理の根っこ

テトリスぷよぷよみたいな落ちモノパズルを作るとき
頭を悩ます処理はもちろん多いと思いますが、
その中でも私が頭を悩ますことが多いのは
ピースの移動ピースの格納です。

そんな基本の根っこで悩むのかといわれそうですが
むしろ基本の根っここそ頭を悩ますべきだと考えています。

なぜならこの根っこがイケてないと後で色々するときに
めんどくさかったりバグの温床になったりするわけです。
それでいて、根っこっていうのは往々にして修正時の影響が大きいです。
なのでそう易々と修正も出来ません。

ピースの移動と格納

移動と格納と書きましたが
ぶっちゃけ格納はしません。
最初から入ってるものの更新を行います。
イメージはディスプレイですね。

なぜこのような方法にしたか

なぜこのような方法にしたかですが、
単純に格納漏れやズレが起きにくいからです。

私は過去に、
それこそまだこのブログを始める前に
Unityでなんちゃってぷよぷよを作ったことがあります。
そのときピースの移動と格納はtransform情報から計算して
行っていました。

f:id:hakase0274:20190210234210p:plain

この方法のいいところはとにかく実装が楽なことですね。
Unityに限らず画面描画を行うものは
かならずどこに描画するかという情報を持っています。
その情報を引っ張ってきて使うわけですから
そこまで変な処理も依存関係も必要ありません。

ただこの方法は実装が簡単な分結構がばくなりがちです。
1マス分くらい結果がずれたり計算や判定のミスで
同じところに複数のピースが重なるなんてことも起きやすいです。
(実際過去起こりました)
f:id:hakase0274:20190210234344p:plain

もちろん時間かけて何回も検証したり、
計算ではなく対応表みたいな感じで格納するなどすれば
起こらないでしょう。

ただこれらの対処は問題を無理やり抑制しているだけです。
検証や対応表を作っている時間があるならば
機能の実装や細かいブラッシュアップにあてたいです。

この問題の根っこの原因は画面上のどこにいるかという情報と
ピース管理配列の添え字という遠くもないが近いわけでもない情報を
無理やり変換しているからです。

なら画面→盤面という変換自体無くしてしまえばいいわけです。

具体的にどんな実装

最初から盤面管理配列にピースを格納しておき、
格納されたピースの更新を行います。
↓盤面イメージ
f:id:hakase0274:20190210234547p:plain

Wが壁ピースでSが空白ピースを意味しています。
プレイヤーはまず画面上部にあたる
空白ピースの添え字を取得します。
f:id:hakase0274:20190210235324p:plain

以後プレイヤーの入力によって添え字の値を変化させ
更新するピースを切り替えていきます。
f:id:hakase0274:20190210235451p:plain

変更しているのはすでに格納済みのピースを示す
配列の添え字のためピースの重複などの問題は起こりえません。

あとがき

今回は落ちモノパズルのピース移動と格納についてでした。
最初に言ったようにイメージはディスプレイです。
あれも結局は画面上にあるピクセル1個1個を逐次更新してるわけですからね。

そして今回説明用に画像を作ろうとしたんですが
やっぱり難しいですね。
ただ著作権怖いのでがんばって作ります・・・

それでは今回はこの辺でノシ