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

画面のサイズについて

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

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

　これを見ると一目瞭然だが、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タイプがお勧めできる。

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

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

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

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

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

• ○ … [通行(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年やっててゲームを何本も出してるツクラーですら気づいてなくても全く不思議じゃない。
　公式では「壁の上も通れるよえっへん」って説明しているんだが、エディタの設定で×って出るから通れないと思っちゃうじゃん! せめて記号は ⊓ にしてくれよ!!

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

梯子

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

茂み

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

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

カウンター

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

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

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

• オートタイル制作の目安用テンプレート

ダメージ床

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

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

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

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

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

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

地形タグ

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

タイル画像と属性の対応

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

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

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

2023-05-22追記：RPGツクールMZではオートタイルに[☆]設定が可能になったので、通行可と通行不可のタイルをまず置いて、[☆]オートタイルを置けば隠し通路が実現できる。

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

タイルセット

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

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

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

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

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

レイヤーの設定

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

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

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

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

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

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

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でないと足が伸びないので、ここには置いてない。

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

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

A4(壁)

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

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

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

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

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

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

A5(通常)

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

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

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

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

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

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

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

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

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