以下の内容はhttps://hakase0274.hatenablog.com/entry/2019/02/10/235907より取得しました。


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

あいさつ

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

処理の根っこ

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

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

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

ピースの移動と格納

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

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

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

私は過去に、
それこそまだこのブログを始める前に
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個を逐次更新してるわけですからね。

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

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




以上の内容はhttps://hakase0274.hatenablog.com/entry/2019/02/10/235907より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14