RPGツクールMV ロングレビュー マップ仕様編

今回はマップの仕様を微に入り細に入りレビュー

止める奴はいないのか!

マップ関連を見ていく

 今回はマップ関連の主に仕様部分のレビューを行なっていきます。
 JavaScriptの中身を読んだ Map関連クラスを調べてみたを前に書いたので、興味がある方はそちらも参考にどうぞ。
 マップだけで前後編にになってしまいました。
 ツッコミどころが多すぎる!

 もうツクラー以外には何言ってるかわからないと思うし、なんなら大半のツクラーも「いや、そこまでは気にしてないよ」というところだと思う。
 それは全然構わないのだが、ツクール開発部が気にしてないようなんだよね、この辺。
 気にしろよ!! こういうところ気にしないからゲーム開発環境の覇権取れないんだよ!!

 あ、ところでツクラーと区別つきにくいので、ツクール自体を開発している開発者を「ツクール開発部」と呼称します。

マップ関連の基本仕様を見る

 MVは対応プラットフォームがMac、WinといったPCだけでなくスマホ・タブレットも想定していて環境の幅が広く、なかなかフォーマットを決めづらいところがある。
 MVのデフォルト設定がなぜそこに決まったのかを考察し、それを踏まえてどのフォーマットにすべきだったのかも考える。
 前回も書いたが、ゲームの背景を構成する最小単位はマップチップが一般的だと思うのがMVの用語ではタイルなので、本項ではタイルと書く。
 VX Ace まではマップチップって呼んでたようなのだが。ドウシテカエタノ…。

画面のサイズについて

 デフォルトの画面サイズが、816×624ピクセルというのがどうにも意味不明だ。
 スーパーファミコンなどの目指すべき家庭用ゲーム機のサイズとも異なり、現在主流のパソコンの画面タテヨコ比16:9とも違い、4:3かというと微妙に違う、と言ってスマホやタブレットに最適かと言われるとそれもどうかという、なんとも気持ち悪いサイズだ。
 過去のツクールにもこのサイズはないらしい…謎すぎる!!

 そこで、歴代ツクールの仕様を調べてみた。間違いあったらごめんなさい。
 参考に、WOLF RPGエディター(ウディタ)で主に使われてる(らしい)モードと、ファミコン・スーファミのデータも載せた。

タイトルタイルサイズキャラサイズ歩行パターン画面サイズ画面タイル数
Dante16×1616×162176×14411×9
DANTE98・Ⅱ32×3232×322640×40020x12
9532×3232×322640×48020×15
2000・200316×1624×323320×24020×15
XP32×3232×484640×48020×15
VX・VX Ace32×3232×323544×41617×13
MV48×4848×483816×62417×13
ウディタ32×3232×323640×48020×15
ファミコン16×1616×162256×22416×14
スーファミ16×1616×243256×22416×14

 これを見ると一目瞭然だが、MVはVXの仕様を1.5倍にしただけで、PC、スマホ環境でどれがベストか、という方向からは決定されていないようだ。
 無責任な感じもするが、対応するプラットフォームが広くなった場合、どこかにターゲットを絞るより、すでに信頼性のあるシステムの仕組みを引き継げる、という要素を優先するのもアリだと思う。
 ただ、VXの544×416がどこから導き出されたのかは、やはり謎だ。

マップタイルのサイズ

 マップ画像に1タイル48×48ピクセルもの解像度はいらなかった。
 多分1タイル48ピクセル使ってるゲームタイトルってMV作品以外でないのではないだろうか。
 それだけ大きなタイルが使えるようになっているなら、タイルを細かく分けて組み合わせのバリエーションを出すのが当然の選択だと思う。
 キャラのサイズを小さくしてしまうと、画面全体に対して小さくなりすぎてチマチマしすぎるので、キャラのサイズはそのままで。

 解像度が高くなるとドットの良さが無くなってしまう、×2ぐらい拡大してドットらしい絵を出すのも良かったかと思う。
 流石にMVリリース時でも640×480はもちろん800×600もちょっと小さい。
 いろいろ考えるに1280×720(720p相当)はYoutubeでHDとして判断される大きさであり、switchが採用している解像度でもあり、市販ソフトを参考にしやすくて良いだろう。
 ちなみに、MV発売当時switchはなかったが、Xbox 360、PlayStation 3、Wii Uが採用している解像度でもある。いいね!
 古いゲームの再現を大切にするなら、ファミコンの倍の32×32 が妥当かと思うが 720 を綺麗に割り切れないのが少し問題かもしれない。

 ただし、48という数値は良いところも多く、2・3・4・6・8・12・16・24と多くの数で割り切れる。
 綺麗に割り切れると、線が2ドットにまたがるような微妙な絵を描かなくて済む。
 つまりドット絵としての良さが生かせるってこと! …なんだけど、あんまり公式の収録素材はこの良さが生きてないのよね。

 以上を踏まえて、先ほどの表だと以下のような仕様のどれかが良かったのではないかと思う。
 スマホ向けに左右にソフトウェアパッドを配置する前提なら、4:3タイプがお勧めできる。

タイトルタイルサイズキャラサイズ歩行パターン画面サイズ画面タイル数
16:9タイプ20×2040×6031280×72064×36
16:9タイプ×220×20×240×60×231280×72032×18
4:3タイプ24×2448×723960×72040×30
4:3タイプ×220×20×240×60×23960×72024×18

 タイルがキャラの半分なのですごく多く見えるが分割すればいいだけなので、見た目をキャラと揃えれば自然に配置できるはずだ。
 実際、オートタイル(後述)は内部的に24×24のタイルを組み合わせて作られている。

 ちなみに僕はdrowsepostさんの DP_MapZoom.js プラグインでマップ×2して作っている。
 タイルサイズを48以外にすると、マップエディットがアクロバティックなことになってしまうし、タイルを標準以外から用意する必要があって、疲弊するのが目に見えてるので回避した。
 ということで、折衷案として48のまま×2した。
 画面の左右が黒いの勿体無いので1280×720全部マップに使った。
 なお、マップ以外の画像やウィンドウ、フォントの解像度はそのまま。戦闘背景のみ×4している。

タイトルタイルサイズキャラサイズパターン画面サイズ画面タイル数
鳶嶋式48×48×248×72×231280×72013.3×7.5

 タイル数が非常に中途半端なのが何だが、きっちり画面端とタイルが合うよりむしろ自然な感じだろうと、ポジティブに考えておくことにした。
 実際どんな感じかは、ゲームをプレイしてみてほしい。

タイル画像とそれに付加される属性

 マップのタイルは、画像を用意しただけでは役に立たなくて、それに付随する情報を設定する必要がある。
 非公式リファレンスのRPG.Tilesetのビットフラグの解説にビットの説明がさらっとしてあるが、ここで詳細に追ってみよう。

地獄のように分かりにくい通行判定

 まず、下通行不可・左通行不可・右通行不可・上通行不可・高層に表示[☆]、これが極めて分かりづらい。
 [データベース][タイルセット]の[通行]という設定で○・×・☆の設定ができるのだが、この記号が意味するのは次の通り。

  • ○ … [通行(4方向)]の設定が全て通行可(←↓↑→)で、高層[☆]ではない
  • × … [通行(4方向)]の設定が全て通行不可(・・・・)で、高層[☆]ではない
  • ☆ … [通行(4方向)]の設定は無視され常に通行可、高層[☆]である

 いきなり出てきた[通行(4方向)]って何?って思うのは当然だ。
 [通行]のすぐ下にある[通行(4方向)]という設定は[通行]の中の通行可否設定を詳細化したもので、要するに設定が2箇所に分散し重複しているのだ。
 …ぅわかりづらいぃぃ。

 素直に設定を作るなら☆のON・OFFだけ設定する[高低]と、四方向の通行設定をする[通行]に分けると思うんだが…どうしてこうなった。
 たぶん、前のVXかさらに前には4方向の通行設定がなくて後付けの機能なので整理されてないんだと思うんだけど、なんたる付け焼き刃。
 機能を追加するときは必ずUIの整理もしましょうよ。

 [通行(4方向)]は狭いタイルをさらに4分割した部分に書かれた記号をクリックして設定する必要があるが、クリック領域が小さすぎて誤爆が頻発する。
 そもそも公称17才の僕はそろそろ老眼…以下略。

〇〇社長さん、操作を難しくてゲームっぽくしておいたのねん!!

 また、[通行(4方向)]はタイルとタイルの境界に通行判定がある、というのがなかなか理解しがたい。
 これむしろウィザードリィとか世界樹の迷宮みたいな3Dダンジョンの発想だ。
 通行可の記号が→で通行不可の記号が・というのも良くない。
 3Dダンジョンの2Dマップみたいに、素直に通行不可の部分に壁を描いてくれ、つまり・ではなく▕ だ。
 多分最初は▕を描いてみたんじゃないかなー、そうしたら隣のタイルとどっちかわからなくなったんで、しょーがなく・にしたというところかと思う。
 どっちにしろ、通行不可の方が目立つデザインを採用して欲しかった。

 こういう変な設定にするより、タイルを田の形に分割してそれぞれに通行設定のON・OFFをつけて、移動を半タイル単位にするべきだったし、できれば通行設定だけでなくタイルそのものも4分割して欲しかった。

 トリアコンタンさんの HalfMove.js を導入すれば、その名の通り移動が半タイル単位になるのに加え、境界の通行判定に加え4分割型の通行設定が行え、ついでに8方向移動まで実現してしまうので、当然僕は導入しています。
 神プラグインと言って差し支えないでしょう。これがなかったらたぶん僕はMVに挫折してました。

 さて、境界の通行判定の場合、同じ境界線上に隣り合ったタイルの通行判定が重なるのも、分かりづらい点のひとつ。
 同じ場所に二重に設定することになるので、データ的に無駄なところがあるのも嫌な感じだ。

 加えて、タイルは最高で4枚同じ位置に重ねられるので通行判定も当然重なる。
 その際に優先されるのは上に乗せたタイルの通行判定だが、直感的にはよくわからないことが多い。
 装飾のつもりで置いた草花が通行可になっていて、通り抜けできないはずの場所が通り抜けられるようになってしまう、なんてミスはツクラー全員が体験していると思う。
 できれば、装飾的なタイル用に[通行判定に影響しない]という属性が欲しかった。

 あと分かりにくいのは…よくマップ通行判定の仕様だけでこれだけ分かりにくくしたなと感心してしまうぐらい分かりにくいな…オートタイルの通行判定だ。
 オートタイルというのは周囲のタイルを調べて、適切なパターンでタイルを置いてくれる機能。道なんかをマップに引くのに便利だ。
 ただし調べて変更する範囲が狭いので、セミオートって雰囲気ではある。

 当然これにも通行判定があって、エディタ上は[通行]の○・×のみが設定可能になっていて、☆や[通行(4方向)]の設定はできない。
 しかし壁の上部に設定されるオートタイル(A4奇数行)は、⊓ の方向が通行不可で、南(下)からは侵入できるのだ。
 これ、MVでの制作を4〜5年やっててゲームを何本も出してるツクラーですら気づいてなくても全く不思議じゃない。
 公式では「壁の上も通れるよえっへん」って説明しているんだが、エディタの設定で×って出るから通れないと思っちゃうじゃん! せめて記号は ⊓ にしてくれよ!!

マップ上で通行判定を確認できる機能があれば、右の花の部分から通り抜けられることが事前に分かるが、MVにこんな機能はない

 最終的な通行判定をマップエディタ上で確認するすべがないというのも、分かりづらさに拍車をかけている。
 結局通れるか通れないかは、実際テストプレイしてその部分にキャラをぶつけてみるしかないのだ。
 めーんーどーくーせーっ!!!

梯子

 この上を通るときはキャラが上むきに固定される。それだけの機能だが、なかなか使い勝手はいい。

茂み

 腰から下が半透明になるんだが、その変化が中途半端でイマイチ面白みに欠ける。
 高さと不透明度の設定が欲しかったところだ。

茂み感が弱い上に肩まで半透明になってしまう

 それとはべつになんとこれ、エンカウント率が倍に上がるのだがヘルプに書いてない!! うそやろ。
 エディタのツールチップにも書いてない。
 コードを直接読んで確認するか、だれかからの伝聞しか知る方法がない。
 ちなみに公式アカウントが当たり前のように「エンカウント率があがります」ってツイート流してたけど、まずヘルプをアップデートして下さい中の人。

カウンター

 この設定をしたタイルがある部分を1タイル飛び越して[イベント]を調べることができる。
 店のカウンターやテーブルごしの会話を想定した属性だ。
 なお、[イベント]というのはMV特有の変な用語で、マップ上に置かれる機能付きの画像、ここではキャラのことだと思っていい。

 それ以外に、A2タイルに設定するとタイルが下に少し伸びる。A2タイル左側に使っても伸びるが、意味がない。
 使う分には割と自然に設定できるのだが、いざ素材を作ろうとするとわけがわからない複雑さを持っている。

絨毯と比べてカウンター設定された机の足が方が伸びてるの、分かるでしょうか?

 あまりに分からないので、他のオートタイルを含め、つながりが(若干)わかりやすくなるテンプレートを作った。

ダメージ床

 その名の通り、上を通るとダメージを受ける設定。
 これびっくりするんだけどダメージ量10固定なのだ。ダメージ床軽減装備とかスキルとかで変わるが。
 「ダメージ量の設定ないなー、どうやって変えるのかなー(まさか変えられないとは思っていない)」ってかなり探して諦めた僕の時間返してください。

 たぶん、ダメージ床を導入してるツクラーはプラグインとか[イベント]でごり押しとかで実装してて、この標準機能使ってない。

小型船通行・大型船通行・飛行船着陸

 小型船・大型船はA1タイルの通行不可部分を通行でき、通行可部分を通行できない。
 ブロックC・Eがあると通過できない。
 また、小型船はA1タイルのBブロックを通過できない。
 いやこれ、機能とタイル位置が結びつきすぎでしょ。
 (ブロックとはA1の中がさらに細かく分かれた領域。詳しくはヘルプ見てください)

 ヘルプにこれらの性質の記述はあるが、エディタ上には何の情報もなく、マニュアル読まない系ピープルは積む。
 位置固定なのはしょうがないと諦めるとしても、エディタでなんか情報出してくれないと困る。

 飛行船が着陸できる地形については「歩行できる場所のみ」と書いてあるが、歩行はできても全周囲に通行不可の設定のないタイルでないと着陸できないような感じで、ちょっとヘルプの記述に不安を感じる。

地形タグ

 [イベントコマンド]やプラグインで何に使ってもいいメタ情報として、0〜7の数値を地形タグに指定できる。
 正直少なくて100ぐらいは欲しいのだが、ないよりはずっとマシ。
 酷いのが、設定するときクリックして数字を増やしていき7から0にループする仕様。カチカチカチカチカチ!! めんどくせぇ!!
 なんと、MV作った人は親切だから隠し機能として右クリックで数字を減らせるのだっ!
 じゃねーよ! 一覧表示してそこから選択させてくれ!! あと機能を隠すな!!!
 それから数字で管理しようとするなー!! 各値に名前をつけさせてくれ。

タイル属性の仕様

 属性がどのように結びついているか、その結び付け方は適切なのか、その辺りを探っていく。
 いやもう予想つくでしょうが、全然適切とは思えないんですよね。

タイル画像と属性の対応

 MVはそれぞれのタイル画像に対して1対1に属性を設定するようになっている。
 そのため(タイルセット内では)、同じ画像に別の属性を持たせたものを作ることができない。
 分かりやすくもあるが、素材データの有効利用という意味では、ちょっといただけない仕様でもある。
 キャラなどを配置する[イベント]の方は、別の[イベント]に同じ画像を設定することが可能なのに…。

 そんな機能必要ないよ画像と性質1対1で十分ですよ、というツクラー多いと思うけど「かくしつうろ」と囁くだけで、もう欲しくなってくるよね!

 もしタイルでやりたいなら画像ファイルの中に同じ画像をいくつも配置して擬似的に実現する他ない(プラグインという手もなくはないけど)
 しかしタイル画像ファイルは限られた面積しかないので、全く同じ画像データ置くの勿体無い。

 また画像を読み込んでそのままタイルパレットに配置しているため、タイルの位置が固定なのも自由度が低い。
 グラフィックツールで色やテクスチャがソートできるように、タイルが持っている属性によって、タイルパレットをソートできてしかるべきだろう。
 あとタイルの検索・置換も可能になるべき。検索対象はタイルセットの中、マップに配置中のタイル、できれば[イベント]に設定しているタイルだ。

タイルセット

 MVはいくつかの画像をまとめたタイルセットというものを、マップごと、あるいは[イベントコマンド]で切り替えができるようになっている。
 ただ、画像素材(tilesetsフォルダのpngファイル)と属性データ(dataフォルダのjsonファイル)の配置場所が別で分かりづらい上に画像ファイルと1対1に対応していない。

 なので、新しくタイルセットを作ると、全く同じ画像素材でも別に属性を設定する必要がある。
 もちろん、有償無償で配布されているタイル素材を組み込む場合も同じだ。
 これほとんど選択の余地のない単純作業なんだけど、エディタ上で属性のコピーすらできないので、もうなんかの修行、しかも苦行である。
 なぜ、タイル画像と設定を一対一にしてまとめた素材を渡せる作りにしなかったのか!

 一応 Tilesets.json は拡張子の通り JSONテキストファイルなので、テキストエディタ上でコピーできる。
 できるといっても、JSONテキストを見ても、どのデータをどこにコピーすればいいのかわからないと思うので「理屈の上ではできる」レベル。一般的にはそんなことできるのは超能力者と同一視されると思う。

 tilesetsフォルダにIDに対応した行に説明が書いてあるtxtファイルを配置すると、エディタでマップタイル選択パネル上をマウスオーバーした時にウィンドウ左下に説明が出る。
 まず、このテキストファイルMVのエディタで編集できなきゃダメでしょ。こういう裏技的実装は本当にやめて欲しい。

なんと、ここにタイルの名前が出るのです。ご存知でしたか?

 この仕様すごくわかりづらいし、なんなら気づいている人はユーザの3%ぐらいじゃなかろうか。
 ポインタそばに即座にツールチップ出す、ぐらいして欲しい。
 このtxtファイルはなくてもヘルプ表示以外の動作に支障はなく、「オフィシャルの素材にすら」ついてこなかったりする。

マップの重ね合わせの仕様

 MVが採用しているのは「見下ろし型2Dマップ」で、用意されている画像素材は斜め見下ろしの上面と正面が見えるものだ。
 なので、キャラがタイルの後ろに隠れることができるようになっていないと、立体的に不自然さが発生する。
 また、タイル同士を重ね合わせることができれば、タイルのバリエーションを格段に増やし、自然なマップを実現できる。

 これらの重ね合わせを実現するための仕様がMVではどのようになっているのか調べてみよう。

レイヤーの設定

 MVは残念ながら立体的なマップを作るためのシステムが最小限で、ちょっと凝った重ね合わせをしようとすると破綻する。
 簡単にRPGが作れるというコンセプトに対しては、ある程度正しい仕様かと思う。
 しかしグラフィックの解像度が高いため、ファミコンのシステムの上にSwitchのグラフィックが乗ってるような奇妙な感覚がある。
 この方向性の定まらないチグハグっぷりは、ツール内の至る所に違和感や使いづらさとなって噴出している。
 高精細化は至上命題だったろうと思うので、システムもそれに合わせた、ある程度高度なものを選択すべきだったかと思う。

 RPGツクールXPには高さ情報があったけど使いづらかったという評判を聞くので、機能を削除したのだろう。
 だが、そこは削除するんじゃなくて「使いやすく改良する」という方向に行くべきなんじゃないの?
 簡単に利用できるようにしたいが、ビジュアルは豪華にしたい、というワガママな仕様を押し通そうとした結果、むしろより操作もシステムも複雑化してるように感じる。

 さてそれはそれとして今問題にしている重ね合わせは、[通行]の○・×・☆によって設定されるのは先に述べた通り。
 ざっくり言えば、低層・イベント・高層の3つのレイヤーがあって、タイルは低層と高層どちらかに置ける。
 この仕様だと、タイルは常に[イベント]の上か下に存在していることになる。

 手前を通るとキャラが上、奥を通るとキャラが下、といった柵の設定ができない。
 これはかなり辛い。絵的には斜め見下ろしだが、設定としては真下に見下ろした重ね合わせ設定しかできないのだ。
 通行の邪魔になるものが何も存在してないように見えるのに、なぜか行けないという状況が容易に発生する。
 これはストレスマッハ。
 同じ2DRPGコンストラクションツールであるWOLF RPGエディターは、柵用の設定△があるようなのだが…

 それからみんな大好き立体交差も当然できない。
 一応内部にはできる仕組みが用意されていて、プラグインを利用することで若干無理やり気味に実現できる。

 しょうがないので、半年ぐらいかけて柵の前後を通れる TF_LayeredMap.js というプラグイン作りました。
 [☆]設定し、標準では無視される [通行(4方向)]の下を通行不可にすると、柵に使いやすい重ね合わせが実現できる。簡単ですね!
 立体交差もリージョンや[イベント]などの仕掛けなしに実現できちゃう! 素敵!
 めちゃめちゃ有用なプラグインで全てのツクラー導入待ったなしぐらいに思ってたのに、思ったほどの反響がなくてガッカリ!!
 どうも地図を見るような真上からの見下ろし的感覚が強い人、別の言い方だと2Dを3Dに変換せず2Dのまま受け取る人の方が多いということのようだ。
 それ自体は良い悪いことではないんだけど、意外。
 WebGL対応でないと動作しないのが問題視されたのかも…いや、大抵のツクラーWebGLとか気にしてないと思うんだが。

上は標準の状態これ以上柵に向かって進めない。下はHalfMove.js + TF_LayeredMap.js 柵の前後が自然!

タイルセット詳細

 MVはエディタの左側にはタイルパレットがあり、そこにはA〜EとRのタブがある。
 タブが下に並んでるのでツクール始めてしばらくはタブだと認識できなかった。なぜこんな意味のない独自仕様を…
 またA〜Eまでのアルファベットには全く意味はない。MVお得意のマジックナンバー管理の一種だ。
 Aを地表とでも書いてくれれば、グッと使いやすさは上がるし、他のタブも名前を書けるようにして欲しい。
 ちなみにRだけは意味がありリージョンの頭文字だ。

Aタブのタイル

 ○・×設定は低層ということは先ほど説明したが、Aタイルはその中でもさらに下に配置されるタイルで、高層[☆]設定はできない。
 つまり、実際は Aタイル低層・B〜Eタイル低層・イベント・B〜Eタイル高層の4つのレイヤーがあるのだ。
 また、オートタイルはすべてAタブにある。

 オートタイルは自動で複雑なタイルを配置してくれて、非常に便利ではあるものの、オートなだけに想定した配置にならないことがよくある。
 なので、オートタイルを選択した時には、オートタイルで描かれるタイル一覧を表示し、その中からも選べるようにして欲しかった。
 オートタイルの中で必要なタイルを得るために一度マップに欲しいタイルが表示されるように配置して、それをコピーする、という手順は面倒臭すぎる。

 Aタブの中はさらに、A1〜A5の領域に分かれていて、それぞれ別のファイルが設定される。
 特にこの部分はタイル位置(ID)によってガッチガチに役割が決まっていて、一見さんお断り感がすごい。
 エディタだけ使っていても絶対わからない、ヘルプ読んでもピンとこない、そんな魔の領域だ。
 正直言うと、今だに[フィールド]設定の場合のこの辺の挙動を理解できてない。
 がっつり2年使ってるのに…。

A1(アニメーション)

 水面のアニメーションを含む領域。
 3パターンのアニメーションを含むオートタイルで、製作の難度がバカ高い。
 なのでできれば、色変えなどの簡単にバリエーション増やせる方法を用意して欲しかった。

 前述のように船が通行できるのはこの領域のタイルに限定されている。
 また、近海・深海・岩礁・滝といった特殊な組み合わせが多く、挙動がなかなか理解できない。
 特殊な挙動やタイルの配置場所で性質ががっちり決まってるのも、ある程度仕方ないのかなと言う気もする領域ではある。

A2(地面)

 低層レイヤーでも特に地面担当のオートタイル部分。
 実はこの領域、左右で性質が違うのだ。もう笑っちゃうしかないぐらいの配置依存の仕様である。
 なんども書いてて読んでる方も飽き飽きかとおもうが、あえてまた問題点を列挙する。

  • メニューなどツールの情報として出てこない
  • ヘルプ読を隅々まで読んでしっかり理解するのが辛い
  • でも知らないと、どうしようもない
  • 範囲が決まっているので、必要な量の調節ができない
  • 範囲を忘れる!

 長年のツクラーでも「A2右側」って何? って思う人がいると思う。
 A2(地面)ってタイル設定で書かれている場所の、右側半分のタイルは地面に重ねられる地面として設定されているのだ。
 ということで訂正しよう。
 実際は Aタイル低層・A2タイル右側低層・B〜Eタイル低層・イベント・B〜Eタイル高層の5つのレイヤーがあるのだ。
 ちなみに、公式ではA2左側を“ベース”、A2右側を“装飾”と呼んでいる。
 やばい、もうついていけないって感じだが、MVはさらに色々ややこしいかけを仕込んでいる。

 A2右側タイルを置いた場所に、他のAタイルを置くとA2右側タイルが消える、ひどい。
 A2右側は、例えば壁の汚れやヒビみたいなものを表現するのに便利だが、やっぱり壁の種類変えたいという時に、全部タイル置き直しになるのだ!
 JSONファイルを直接置換した方が楽なぐらい。素直にレイヤー選択させてください。

 標準設定ではA2右側に机のオートタイルがあるが、ここに前述のカウンター設定がされており、A2領域のみ足の部分が下のタイルに伸びて表示される。
 これ、エディタ上でも表示されるので、MVにしてはめずらしく結構頑張って作っててえらい(ごくたまに褒める)

 ちなみにここに絨毯があるのだが、絨毯は通常四角以外の形状を取らないので、少々無駄だ。
 ツクール製のゲームで不自然な四角くない絨毯が量産される原因となっている。
 カウンターも、四角以外の形を作れる必要ないだろう。
 四角以外の形が絶対ないとは言わないけど、製作者が家具や建物に対する意識に欠けてる感じはする。

こんな変則的な形の絨毯は、オーダーメイドが必要ですよね

A3(建物)

 この領域は四角のオートタイルが並ぶ。
 A1とA2は例えば┤に配置すればそれに沿った境界が作られるが、四角のオートタイルの場合、境界は常に四角でしか区切られないので、┤と配置すると、─部分と│部分で境界が区切られる。
 要するに内向きの曲がり角がないのだ。個人的には、これ理解するのにかなり時間かかった。
 我ながら、あっちこっちで理解に時間かかってますよね、つまりMVのそういうとこがダメなんですよ。

 ついでに言うと、さっき言った絨毯とカウンターはこっちの領域におけばいいと思う。
 実際僕のゲームではここに絨毯のタイルを置いている。
 ただしカウンターはMVの仕様でA2でないと足が伸びないので、ここには置いてない。

 このタイルは影ペンで描画可能な影が自動でタイルの右側に付加される。できればこの機能OFFにできる設定も欲しかったが、まぁそれはいい。
 問題なのは通行判定を○にしても影が描画されてしまうことだ、いや上通ってるんですよ地続きですよ、なんの影ですか。
 おかげでこの領域に絨毯を置いている僕は配置後にちまちまと影を消す作業を行っている。
 なので、あまりこの領域に絨毯を置くことは、オススメできない。

 でわざわざ特殊な設定してるんだから、屋根の上の方は[☆]設定になってて、後ろを通れるんでしょ、って思うじゃないですか。
 でも、屋根は単なる進入不可タイルなんですよね…ガッデム。

左は標準で互いにそれ以上進めない、右はTF_LayeredMap.js で横に並んでいても奥と手前がある!

 さっき紹介した柵の前後を通れる TF_LayeredMap.js プラグインで、この問題は解消できます。
 しかも、特殊なタイルを使っているのではなく通常のオートタイルに、カウンター+ 地形タグ3を設定するだけ。簡単ですね!

A4(壁)

 A4領域は、迷路の壁を作るのを想定している。
 マップリストのコンテクストメニューから実行できる[ダンジョン生成]で使われるのはこのA4領域だ。

 A4(奇数列)は壁の上面にあたる。A2と同様のオートタイル。通行判定のところですでに書いたように ⊓ 型に通行不可設定されている。
 これは梯子を使って壁を登って、壁上面を歩くことを想定しているためこんな特殊な作りになっている。

 A4(偶数列)は壁の正面にあたる。性質はA3と(ほぼ)同じで四角オートタイルで影が自動描画される。
 実は隣が壁上面と接していると端が描かれないという仕様がある。
 ツクール開発部…お前こんな細やかな気遣いできたのかよ! って変な感心しちゃう仕様だ。
 なんだけどヘルプに記述がない(よね)ので「ただのバグに見えてしまう」のだ(笑) だめじゃん!!

左と中央は上面が横に繋がっていないので両方に柱がある、右は繋がった上面があるので左に柱がない

 なん度も問題が出てくる度繰り返すが、タイル配置(ID)に依存して性質が変わる仕様はマジで害悪でしかない。
 必要な性質を持ったタイルを必要なだけ増やせるようにしていただきたい。

 さて、この領域は上を通れることから、壁以外にも崖とその上部として使われる。
 ただこの時基本的には地面タイルでしかないので、角が鋭角的になってしまうのが気になる。

左は標準の収録素材で角が尖ってる、右はTF_LayeredMap.js + 改変素材で角が丸まってる

 これも柵の前後を通れる TF_LayeredMap.js プラグインと、プラグインに対応した崖タイルセットで解消できます。
 ブラボー!! おおブラボー!!

A5(通常)

 ここはオートタイルでない単体のタイルで、[通行(4方向)]の設定も可能だ。ただし[☆]設定ができないのは他のAタイルと同じ。
 ここに既にいくつかのタイルを合成したタイルを置いて置けば、さらに上にB〜Eタイルが置けるので、かなり複雑なマップづくりが可能だ。
 とっても便利なのだが領域が限られているので、大いに困る。

 とりあえず、標準で用意してある階段は四角オートタイルに加工して、A3かA4(偶数列)に置くと良いと思う。
 サイズ的には変わりがないが、オートタイルの場合入口と出口の部分に変化をつけることもできる。
 ただ、通行[○]判定にすると左右の通行不可判定がなくなってしまうのが問題になることがあるかもしれない。

左は標準のA5にある階段、右はA3かA4(偶数列)用のオートタイル階段

 なので自動で左右の通行不可判定もつく、坂・階段・段差を表現する TF_Undulation.js というプラグイン作りました。
 これを使うと上下だけ、あるいは左右だけに通行判定のある四角オートタイルを作成できます。
 これで橋とか、階段を簡単に設定できるようになります。標準で欲しい機能ですねっ!

B〜Eタブのタイル

 B〜Eタブは全てAの上に配置するタイルで、オートタイルはなく全て単独のタイル。
 B〜Eまでのタブの名前に特に意味はなく、タブによって性質が変わることはない。
 ただしBの左上を除く!(後述)

 B〜Eタブのタイルは、同一位置に2枚まで重ねて配置できる。
 ☆設定がされているタイルは○・×より上に必ず描かれる。ただ、エディタ上では○・×タイルより下に☆タイルが描かれることがある、エディタ上の見た目とプレイ中の見た目が違うのだ。酷い!

 ○・×、あるいは☆どうしのタイルは先に置いたものが下に配置され、3枚目を配置すると1枚目が消える。
 そして、2枚置いている状態で下のタイルだけ変えたい場合はどうするのか。
 3枚目を配置すると1枚目が消えることを利用して2枚重ね直すか、いちどB〜Eのタイルを消して置き直すことになる。
 これはひどい。全く直感的でない。これ理解するのに半年ぐらいかかった。
 流石にかかりすぎな気もするが、そのくらい直感的でないということだ。

 とりあえずできるからいいでしょ、のところで止まっちゃったインタフェースで、素人感が強烈だ。
 簡単に使えるように機能を減らしたら余計面倒くさくなった、というパターンだ。素直にレイヤー指定させてくれ。

 すでに置いたB〜Eのタイルを消すには、Bの左上のタイルが(画像ファイルに何が登録されていようと)透明として機能する。
 こういう、特定の場所(ID)のものだけ特殊な挙動が割り当てられているの、内製の特定のゲーム専用エディタとかならありがちな仕様だと思うんだけど、一般向けのツールでやっちゃダメ。
 ふつーに消しゴムツールつけて! なんでアンタは普通のことができないのっ! と毒親のようなセリフ吐いちゃうが、みんな吐くでしょ、これは。

R(リージョン)タブのタイル

 半透明のカラフルな四角が並んでいて、一見全くなんだかわからないタブ、それがリージョン。
 タイルとは関係なくタイルと同じ位置に値を(1つだけ)置け、[イベントコマンド]やプラグインから値を取り出して利用できる。
 基本的にはエンカウントする敵の種類を切り替える目的に使うことを想定している。
 マップの設定に[エンカウント]という項目があり、そこでリージョンIDを指定できるようになっている。

 地形タグと似ているが、タイルに付随する情報ではないので、タイルを入れ替えても変化がないし、タイルを移動してもついてこないため、移動させる場合はタイルと別に移動させる必要がある。使いづらい!!
 ちなみに市販のソフトでもタイルとリージョンがずれるバグ(に近い仕様)はままある。
 本来出てこない場所に突然強力な敵が出現した、なんて経験はRPGのプレイヤーならだれしもあるかと思う。

 今までに書いた、おなじタイル画像に別の属性を設定できる機能と、地形タグの数を増やす、なんならタイルごとにメタタグ(メモ欄)を採用するという対処をすれば、特に必要ない機能だ。
 「絶対欲しい〜ないほうがいい」までの間なら「無いよりはいいけど、できれば別の機能に置き換えて消えて欲しい」という限りなくないほうがいい感じの機能だ(笑)
 比較的簡単に実装でき、ツクール開発部から見た機能としてはコストパフォーマンスがいいので、開発者目線では理解できる。

 ただ、数字で管理するのやめろ!! まじで!!
 任意の3文字表示できれば、アルファベットだけしか設定できないとしても視認性は爆上がりを保証する。
 漢字2文字が使えるとなお良い。

影ペン

 既にちょっと出ていたが、MVには影ペンという機能があって、タイルの1/4 サイズの黒の半透明を地面の上に置ける。
 おおっと、気づいてしまいましたね。それでは訂正しましょう。
 実際は Aタイル低層・A2タイル右側低層・影ペン・B〜Eタイル低層・イベント・B〜Eタイル高層の6つのレイヤーがあるのだ。
 複雑なのを隠せば簡単になると思った浅はかさ、地面に頭を突っ込んで隠れたと思い込むダチョウみたいなものだ。
 実際は複雑なままなので、隠れているぶん理解しづらくなってるのだからもうね…。
 レイヤー選択させて、レイヤーの見た目をON・OFFできたりしましょうよ。

 正直かなり荒い機能ではあるが、つけると意外に雰囲気が出る。コストパフォーマンスの良い機能で感心した(たまには褒める)
 あと、タイルの1/4の正方形だけでなく斜めのやつとか角丸のやつとかも欲しかったなぁ。
 あと、マップ全体の影を一枚の画像で設定する機能があると、制作は大変だが、よりリアルな影がつけられたのだが。
 あと、色指定もできるとよかった。あと、合成方法も選べて、あと、キャラの上のレイヤーにも置けると…もう別機能(笑)

 まとにかく、影ペンは悪くない機能だが、中途半端でもあり、OFFにするオプションがあっても良かったかと思う。

 そして、影ペンがコピーされないの、嫌がらせ以外の理由があるなら知りたい。
 これのせいで影ペン使うの躊躇することすらある。
 なお、オートタイルのマップをペーストすると影は描画されるが、これは影ペンがコピーされているからではなく、オートタイルの自動影つけ機能が働いているのだ。
 実際、Shift+ペーストすると影は描画されない。

遠景

 もうさすがに展開わかったでしょう。
 実際は遠景・ Aタイル低層・A2タイル右側低層・影ペン・B〜Eタイル低層・イベント・B〜Eタイル高層の7つのレイヤーがあるのだ。

 MVは、タイルで設定したマップのさらに奥に一枚画像を貼りこむことができる。
 単なる絵なので、インタラクションができないのが弱点だが、透明タイルに衝突判定など置くことで、擬似的にインタラクションを実現できる。
 また、これを単純な背景として使い手前に立ち絵のピクチャを置くことで、ビジュアルノベル的なゲームを作ることも可能だ。

パララックスマップという誤用

 ここで、少々脱線する。
 多くのツクラーが遠景を利用したマップの事をパララックスマップと呼んでるのは誤用だ。
 一時、サイトデザインとしてパララックスマッピングというのが流行った。
 これは手前と奥のスクロールスピードを変えることにより、絵に奥行きを出す手法だ。
 ゲームでは「多重スクロール」という名前の方が馴染みがあるかと思う、1980年代に流行し定着した手法で、2Dゲームにはあって当たり前ぐらいの馴染みの手法である。
 パララックス(parallax)というのは視差という意味で、左右の目の位置で見える像にズレが生じることなど、観測位置によって対象の配置に変化が現れることを示している。
 要するに、画像そのものではなく「画像の見え方」を指す言葉なのであり、ゲーム的には演出システムの一種である。

 で、多くのツクラーはタイルによらない一枚絵によるマップ(遠景の画像ファイル名の先頭に「!」をつけると視差は0となる)をパララックスマップと呼んでいるのだが、手前と奥の視差が0なのでパララックスはないのだ。
 あとマッピングという言葉を、ゲーム用語としてのマップ(地図)の意味だと思い込んで、誤用しているのだと思う。
 パララックスマッピングのマッピングはテクスチャマッピングなどと同様に、情報と位置の結びつけを指していている。
 つまりパララックスマッピングは視差配置という意味であり、そこに地図の意味はない。

 正確にいうとゲーム用語のマップも、マップチップを配置(マッピング)したものだからマップと呼んでいる面もあるので、誤用いと言い切るのもナンだし、そもそもが地図と配置が語源一緒だ。しかし間違いなく視差(パララックス)の方は誤用だ。
 誤用を見るたびにモヤモヤして指摘したくなるが、上記のように説明が長い上に伝わりづらいので思いとどまっている。

 MVは遠景画像のスクロール量を手前のタイルマップとずらすことでパララックスマッピング(多重スクロール)を実現できる。
 MVというツール本体には特に誤用はない(そもそもパララックスという言葉をどこにも使ってない)のだが、公式からのゲーム紹介などのアナウンスで誤解を広げている面が見られる。
 頼む自分ところの製品の用語の意味を、ちゃんと! 理解して!! 使ってくれ!!!

追記
 遠景画像は、parallaxesってフォルダに格納することになってる。…これは誤解するわー。
 picturemaps とかが良かったかもね。

 ところで、ファイル名の頭に「!」をつけると視差が0になるという裏技的な仕組み、ホントやめてほしい。
 なんども書くけど、エディタ操作しているだけだと一生わからないから、こういうの。
 エディタ上に[視差]ってオプションをつけて、視差の数値か[あり・なし]の設定ができるべき。

結局レイヤーはどんだけあるの?

 ちょっと大変ですが、コードをしっかり追ってみましょう。

 まず、そもそものデータです。
 Map.jsonに含まれるマップデータ に書いてあるものを見ると「0:Aタイル, 1:A2タイル右, 2〜3:B〜Eタイル, 4:影ペン, 5:リージョン」となっています。
 1タイルにこれだけの情報を持っているわけで、これを読み込んで描画するのが Tilemap(ShaderTilemap) です。

 Tilemap には各種 Sprite が子オブジェクトとしてぶら下がっていて、それをzプロパティとy位置に従ってソートしています。
 細かいことを言うと、ここにぶら下がっている[イベント]や[フキダシ]の数だけレイヤーがあるわけなんですが、大まかには zの種類だけレイヤーがあると思っていいでしょう。
 zの種類は重なりの優先度 に書いてあります。

z Object 内容
9 Sprite_Destination タッチ位置表示
8 Sprite_Animation アニメーション
7 Sprite_Balloon フキダシ
6 Sprite 飛行船の影
5 Sprite_Character プライオリティ [通常キャラの上]・立体交差の上
4 Sprite 高層タイル[☆]
3 Sprite_Character プライオリティ[通常キャラと同じ]
2 通常タイル(未使用)
1 Sprite_Character プライオリティ [通常キャラの下]
0 Sprite 低層タイル( A・影ペン・[○]・[×] )

 ここで、低層タイル・高層タイルは重なりも含めたタイルの組み合わせを一つの画像として扱っています。
 Tilemapの中で、タイルとキャラだけでなく、フキダシやアニメーション、タッチ位置の表示までやっていたのはちょっと意外です。
 これに加えて、実際のゲーム画面では、奥に遠景、手前に天候・ピクチャ・ウィンドウがあるわけです。

 これだけ沢山のレイヤーが実際存在するのに、レイヤーを意識させずに操作させようというコンセプト、仕様書を書いた時点で破綻していると気づいて欲しかった。

 あれ、そう言えば飛行船はどのレイヤー飛んでるんだ? そのうち調べる…かもしれない。

まとめ

 さすが老舗、よく考えられてるというところから、お前は素人か! というところまで、作りの良し悪しにばらつきがあって戸惑う。
 これは、初期に作った基礎の上に増築に増築を繰り返してきたことの弊害がモロに出ていると言っていいだろう。
 特にMVはVXの仕様をほぼ丸っと受け継いで、32→48の変更しただけな感じ。
 このへんゲームのコア部分をRubyからJavaScriptに変えるという大工事を行なっているので、無難な作りかと思う。
 ただVXの時点でもう何十年も作ってんだから、もーちょっと完成度高いシステムになってて良くない?

ロングレビュー マップエディタ編に、つづく!!