mieki256's diary

昔のTVゲーム機は、QVGA = 320x240前後の画面サイズで、タイルサイズは8x8ドットが最小だったのだけど。

今時のPCゲームは、いくらなんでもVGA = 640x480より小さくなることはないだろうから…。画面ドット数が縦横2倍になってるのだから、タイルサイズも、最小で16x16ドットになるのかなと。

でも、本当にそれでいいのかしら。例えば…。

• GPU、もしくは、使用ライブラリが、小さいテクスチャを大量に出すより、大きいテクスチャを少量出すほうが速いのであれば、タイルサイズを32x32や64x64にしたほうが安心できそう。
• 「今時 640x480 の画面サイズのゲームなんてないよ？」「800x600もないよ？」「1280x720 とか 1920x1080 でもいいぐらいだよ」ということなら、タイルサイズも大きいほうがヨサゲ。

ずっとPC向けゲームを作ってきた人なら、このあたり感覚的に分かるのかもしれないけど。どこかに参考記事・解説記事がないものか…。

表示もできたし、当たってるかどうかの判定までは、どうにか動いたような。 後は補正処理 ―― 補正後の座標を返す処理を書かないと、かな…。

先日作ったテスト用マップは、最低限のBGアタリ番号だけでマップを作れないかと思って作業してたけど。プログラムを書いてる最中、やっぱり、属性で分けて、別のアタリ番号にしたほうが良さそうだなと思えてきたので、そのようにマップを作り直したり。ぶら下がり棒や、空中に浮いてる床＝ジャンプして飛び乗れる床は、別のアタリ番号に、みたいな。

Tiled でマップ作成する際にも、見た目からして、「ここは空中に浮いてる床」「ここはぶら下がり棒」と分かるほうが、バグを入れずに済みそうだし。

もし、最低限のBGアタリ番号でどうにかしようとすると、

• 平らな床は、上下2マス分、床タイルを置くこと。
• ぶら下がり棒は、上下2つの斜め床の組み合わせ、及び、空中に浮いてる一マス分の床で配置すること。
• 空中床は、床タイルの下に、高さ半分の床を配置すること。

といった具合に、どうしてソレが必要なのか、プログラマー以外はピンとこない、奇妙なBGマップ作成ルールを強要することになりそうで。

それよりは、それぞれ別のアタリ番号を用意して、配置してもらうほうが分かりやすいだろうなと。

昔、このあたりの処理を書いた時は…。アタリ番号一つ一つに対して、「当たってるか、当たってないか」の判定処理を、わざわざプログラムで書いてたのですが。 当時は、テーブルで持ったらROM容量を圧迫してしまうのではないかと不安だったので…。タイル種類が増えるたびに、その形に合わせて、毎回コツコツと書いていくという、ちとアホみたいな作業をやっていて。

だけど今では、RAMは比較的余裕があるだろうし、テーブルで持ってしまっていいよなと。そのほうが処理もシンプルになるし、どのタイルでも実行時間が一定になるし。 場合によっては、当たってるか当たってないかの判別用に、0/1で、タイルサイズ分の二次元配列 or ビットデータ列を持ってしまってもいいぐらい、かもしれない。 *1

さておき。今はテーブルを用意して処理するとしても、テーブル作成が面倒臭い。ので、プログラム側に画像を渡して、各タイル内のドットの有無をスキャンして、配列に入れる形にしてみたり。与える画像さえ修正してしまえば、即座にテーブルに反映される上に、画像上で凝った形状を作っても、ちゃんと反映されるので、作業は楽になるかもしれないなと。

待てよ？ どうせ画像を渡すなら、当たってるかどうかの判定も、画像中のドットを見て、やっちゃっても良さそうな。いや、どのみち補正用の座標を得るためにテーブルが必要になるのだから、それを使って判定してもいいか…。

このあたりの処理って、どのくらいの個数のオブジェクトが、地形アタリを取るのかで違ってくるから…。やたらと呼ばれるなら速くしないといけないけれど、たいして呼ばれないなら、処理を速くしてみたところで、さほど意味は無いし。動かしてみて重くなったら、その時に最適化を、てなノリでも良さそうな。