SRPG開発戦記

第5話 タイルセットについて語る

　２ＤのＲＰＧやＳＲＰＧはのマップは、レトロ風なものはタイルセットやマップチップと呼ばれるものを利用して描かれる。これらは、１マスずつの絵柄が並んだパレットのような画像だ。そこからスタンプのようにマスを配置していき、マップを作っていく。

　このタイルセットだが、ものすごく古いゲームでは、一種類の地形に一つの画像を割り当てていた。しかし時代が少し下ると、周囲のマスが同じかで、貼り付ける画像を自動で割り当てる方式が現れてきた。

　分かりやすい例としては海の地形がある。非常に古いゲームでは、海は一種類の画像が各マスに貼り付けられていた。しかし少し新しくなると、海の角が丸くなっている。これは、複数の形状の海マスを持っておき、隣接マスが同じかを見て、自動あるいは手動で配置する画像を割り当てているのだ。

　この「地形角丸配置」という感じのレイアウトをおこなうためには、同じ地形に対して、何種類かの画像を用意しておかないといけない。有名なところでは、「RPGツクール」のオートタイルの画像がある。同作のフルオートタイルでは、２マス×３マスの領域に複数の画像を配置しておき、地形に応じて画像の各部をコピーして並べていく。

　２マス×３マスの画像は下のような形状だ。等幅でないときちんと見えないので、崩れていた場合は脳内で変換してほしい。

+----+----+

|┏┓|┛┗|

|┗┛|┓┏|

+----+----+

|┏━|━┓|

|┃■|■┃|

+----+----+

|┃■|■┃|

|┗━|━┛|

+----+----+

　この画像を、どのように使うかの話をする。各マスを、ホールのケーキを四等分したような感じで分割する。

+--+--+

|┏|┓|

+--+--+

|┗|┛|

+--+--+

　そして、周囲の繋がりに合わせて参照する場所を変え、コラージュするように貼り付けていく。

+--+--+

|┏|━|

+--+--+

|┃|■|

+--+--+

|┃|■|

+--+--+

|┗|━|

+--+--+

　これは知らない人には手品でも見ているように感じる。画像のさまざまな場所を貼り付けていき、滑らかな形状を生み出していくからだ。

　手動でさまざまな地形を貼り付けていくこともできるが、私はこうした自動レイアウトのプログラムを書くことが多い。短いプログラムを書くだけでマップ作成のコストを大きく下げることができるからだ。

　今日は、この自動レイアウトの処理を書いたのだが、だいたい130行ぐらいだった。これぐらいの手間で、手動でレイアウトする作業を劇的に減らせる。書かないと損なプログラムだと言える。

　先ほど、「RPGツクール」のオートタイルの画像は２マス×３マスで１つの地形のレイアウトだと書いた。実は他の方式もあり、１マス×５マスの方式もある。私の場合は、プログラムも画像も一人で作っているので、画像作成の手間は少ない方がよい。そのため、１マス×５マスの方式を採用している。

　こちらは、下のような形状だ。こちらも等幅でないときちんと見えないので、崩れていた場合は脳内で変換してほしい。

+----+

|┏┓|

|┗┛|

+----+

|┃┃|

|┃┃|

+----+

|━━|

|━━|

+----+

|┛┗|

|┓┏|

+----+

|■■|

|■■|

+----+

　この画像をどのように利用するのかも書いておく。

　自マスを中心とした３×３の９マスを調べて、それぞれが自マスと同じ地形かを確認していく。そして「左、左上、上」「右、右上、上」「左、左下、下」「右、右下、下」の状態を調べて、繋がりを確かめる。最終的に、各マスの「左上、右上、左下、右下」の各位置について、タイルセットのどこを参照するかを決めていく。

　書いておいて何だが、言葉で説明しても分かり難いなと思った。

　さて、話を進めよう。ゲームのマップを作る有名なソフトに、「Tiled」という海外製のものがある。タイルの画像を複数種類読み込め、レイヤー機能を持ち、作成したマップをJSONなどで出力することができる。

　便利なソフトなのだが、ちょっと不便なところもある。先に二つ挙げた、各マスを四分割して自動レイアウトする機能を持っていない。周囲の形状に合わせて、１マスずつ自動で並べてくれる機能はあるのだが、半分ずつ貼り付けてくれる機能はない。

　また、以前開発に使ったときは、内部のＹ方向の並び順が、Unityのタイルの並び順と逆だった。そこでJSONをインポートするときに自動で逆向きにする処理を書いた。

　UnityもGodotも、開発ツール上でマップを描く機能がある。しかしデータは別途テキストで持っておきたいので、私は「Tiled」のようなプログラムを使うことが多い。

　はるか昔に開発していた頃は、「Excel」を使ってマップを描いていたこともある。Excel方眼紙と揶揄される使い方だが、けっこう便利だ。マップだけではなく、そのステージに必要な情報も全て１つのファイルにまとめることができる。その情報を、自作のプログラムで短いテキストに変換して出力する。

　ゲーム側では、そのデータを読み取るプログラムを書けば、Excelファイル１つにつき、１ステージを管理できるので都合がよかった。

　タイルセットについてもう少し書く。周囲の状態を読み取った自動レイアウトだけでは、マップの表現としては不足している。自動レイアウトを最大限に活かすには、さらに２つの要素を付け加える必要がある。

　１つはレイヤー機能だ。最下層の地形、その上に自動レイアウトを何層か、そのようにしてようやく、見た目的に自然なマップを描画できる。

　二つ目は、手動のレイアウトを組み合わせることだ。特殊なマスだったり、飾りのマスだったりを付け加えることで、マップの表現力はぐんと上がる。本当は全て手動にして、大量の種類のタイルセットを用意して配置した方がリッチな画面になるのだが、それはコスト的に大変だ。一人で全てを作っているので効率化を考えないといけない。

　ついでなので、地形判定の話をしよう。

　マップをレイヤーで表現したときには、地形の判定に注意しなければならない。何層も重なったマップの中から、一番上に表示されている地形のみを集めて、地形判定用のマップを作っておく必要がある。このマップは、ステージを読みこんだ際に自動で作る。手動で作るとミスが紛れこむからだ。

　マップとユニットのデータについても書こう。

　ＳＲＰＧのマップは静的なものだが、たまに動的な表現が必要なこともある。たとえばマップに宝箱を置いて、空けられるようにしたいとする。その場合に、宝箱をマップにするか、ユニットにするかは悩む。

　マップにすれば、ユニットとして管理しなくてもよいが、マップを変化させる処理と、その情報を管理するデータを持つ必要がある。ユニットにすれば、マップは固定化できるが、ユニット管理が煩雑になる危険性がある。

　戦闘シーンで見えるもののうち、何をマップにするか、何をユニットにするかは、企画段階でけっこう悩む。表現したいものがあるときに、その処理を最も効率的におこなえるようにしないといけない。そうしておかなければ、プログラムは複雑化して、管理が面倒になる。できれば、複数の表現を単一のデータとシンプルな処理で実現できるのがベストだ。そうしたことを考えながら、企画と開発のあいだの交通整理をおこなっていく。

　まあ、全て自分で作っているので、破綻したらその部分を作り直すこともできる。ただ、上手くデータと処理を作ることができれば、開発者として非常に気分がよくなる。

　話が逸れたので元に戻る。オートタイリングをおこなうタイルセットは、作成しないといけない画像の量を劇的に減らしてくれる。しかし、ゼロにはしてくれない。今回はドット絵でマップを作ろうと思っているのだけど、ドット絵はサイズが変わると描き直しだしなあと、ちょっと不安になる。

　昔作ったゲームは、全てSVGで作っていたので、どのサイズにも拡大縮小することができた。そのデータをまた使ってもよいのだが、毎回同じ見た目だとなあと躊躇して、ドット絵にしようかなと思っている。

おまけ：

いろいろな同人誌や、ゲームを作って公開しています。ぜひ見てください。

最近、ゲームブックも書きました。遊んでください。

https://crocro.com/shop/