RPGツクールMV ロングレビュー 概要編
今回はゲームレビューの出張所としてロングレビューを展開してます。ナビゲーションが二段ですねっ!!
|
基本情報
RPGツクールMV(以後MV)は、日本はもちろん最近では海外での方がむしろ人気の老舗JRPG制作環境。
今回はMac初のツクールであることが最大の目玉(僕にとってはね)。
それからコアにJavaScriptを採用し、ブラウザやスマホ環境への出力も可能というところも売りとなっている。
販売ルートとしてはパッケージ、公式オンランストア、Steam(直接またはダウンロードコード)のルートがあり、Mac版はSteamのみだ。
30日体験版(現在ちょっとバージョンが古いみたい)もあるので、起動できるか確認もできるので購入の前に必ず確認しておこう。
ちなみに、発売当初から2016年まではスパイク・チュンソフトが販売をしていたこともあり風来のシレンシリーズの無料キャラ素材も(ちょっとだけ)用意されている。
なお、海外版の販売はDegicaが担当している。
Trinityとは違うものなので注意してほしい! すごく!
RPGツクールMV Trinity(以後Trinity)というコンシューマ用の製品も出ているが、バグまみれの似て非なる製品だ。
もちろんMVも、最初はバグがいくつもあり今もあるが、Trinityはデータ破損やフリーズなど致命的な物が大量にあるという「なんで売り物にしていいと思ったのか疑問」レベルなので、混同しないでいただきたい。
なお、 現在は、地道なアップデートで「酷いは酷いけどツクールだしな」程度まで回復していると、風の噂では聞きます。
基本的な部分に関するレビュー
最低限ゲームになる状態まで、特に何もしなくても全部用意されているのが素晴らしい。
プロジェクトを新規に製作してテスト実行すると、もうキャラは動かせるしメニューは開くしセーブなども機能する。
これはお世辞抜きに感動した。
画面表示や音の再生などはプログラムもデータも製作の必要がない。
他の開発環境で意外と手間となるデータベース(アイテム・職業・敵)のデータの準備もしてある。
データ管理用のエディタも内蔵してあり、隙がない。
もっと自分らしさを出したいと思った時も家庭用ゲーム機と違ってデータは全て入れ替えられる。
さらに、出力されたゲームはJavaScriptで組まれているので、いざとなればプログラムは全部改造可能。
実際、RPGを作るツールなのに、アクションゲームもかなり作られている。
直接出力されたプログラムを書き換えることもできるが、プラグインで機能を追加する形が取れるので、比較的気軽に改造可能だ。
素晴らしいのは、これらの画像・音・プラグインが有償・無償、公式・非公式に大量に存在すること。
発売から5年たち40万本を超えるという、開発環境としては規格外の販売本数が、充実した素材として現れている。
過去のツクールを見ても10年以上使われ続けているものも多く、今後も安心できる。
収録素材・追加素材と完全自作の中間の機能として、パーツを組み合わせてキャラを作るキャラクタージェネレーター機能が用意してある。
個人的にモンタージュソフトや着せ替えソフトを作るなどするほど好きな遊びで、もう無限に遊べる。
顔のアップと歩行・サイドビューの戦闘キャラ画像が一気に作れるのも素晴らしい。
絵柄は収録素材と合わせてあるので、違和感なく追加できる。
もちろん、自分で公開サイトを用意して配布することもできる。
これはもう、全方位的に万全の体制と言っていいだろう。
スーパーファミコン時代のRPGぐらいを想定した2Dのゲーム制作環境なので、プレイも作成も比較的わかりやすいのも他のゲーム制作環境とくらべて良い点。
すでに3Dの制作環境には良いものがいくつもあるのだから、3Dに迎合することはない。
とにかくゲームを作ってみたい、という時の最初の一本として強くお勧めできる製品と言える。
参考
そこで結論。
古くて荒い作りだが、やはりゲームを作るのが一番面白いゲームと再認識させてくれる
はい普通に書く感じのレビューは終わりです。これでMVに興味が出た人は(セールの時に)買えばいいんじゃないかなっ!!
詳細なレビュー
キャラやマップの画像素材やプラグイン素材を作って公開し、ゲームも何本か作ってみた立場として、詳細なレビューを書いていこうと思う。
なお僕はMVが初ツクールなので、過去のシリーズと比べてどうだということは、ほとんど言えないので悪しからず。
過去シリーズについて言及した部分は、一応調べたものの自信はない。
ちょうど新RPGツクールの制作が発表されたところなので「同じ過ちは繰り返さないで欲しい」というユーザの意見として、開発の参考にしてほしいという気持ちで書く。
もちろん「いいところはできるだけ引き継いでね」という気持ちも込めたが、いいところはもうだいたい書いちゃったので、もうほとんど出てこないよっ!(笑)
MVユーザの皆さん(以下ツクラー)には「あれはダメだよねー」みたいに共感しながら読んでいただけると幸いです。
以下ではクソミソに書いてますが、素材もたくさん作ってゲームも作ってますし、大いに楽しんでいます。
また、先ほどのレビューに書いたように、お勧めできる商品だと思っています。
「だいたい、気に入ってないソフトに対して、こんなに長文書けませんよ!」
全体の傾向について
まず「今回は」レビュー中に事あるごとに遭遇して指摘する問題を、ざっとあげておく。
端的に言うと、UIに対する基本的な素養が欠けてる。
開発者の中に欠けてる人がいてもいいのだが、ちゃんとチェックできる人や業者を間に入れるべき。
尾島さんにUI任せちゃダメ!! (実際の担当者が誰かは知らないので想像で言ってる)
用語センスが独特
例えば、ゲームの背景を構成する最小単位ってマップチップが一般的だと思うのだが、MVはタイルと称する。
ゲームの画像関連で「タイル」というと中間色や質感を表現するために、ドットを市松状(など)に置くタイリングの方を指すように思うんだが。
海外では背景に対してタイルセット(tileset)などと称することはあるので、とんでもない誤用などというわけではない。
ただ、昔のツクールのスクリーンショットを見ると、チップって書いてるんだけど…
例えばシーズンパスという商品があって順次素材が追加公開される雰囲気なんだけど、もうその時期は過ぎたのか最初からそういう商品ではなかったのか、内容はずっと固定だ。
四季の背景素材が入ってる商品みたいな感じもする。分かりづらい!!
こういう微妙に違和感のある用語が大量にあって理解に手間取るし不安になる。
本レビューでは、一般的ではないと思いつつも、極力MVの用語で説明する。
MVを含めツクールを触ったことがない人には、リアルに用語のズレ具合を体感できることと思う。
説明が下手くそか説明がない
ヘルプや公式Webの情報やアナウンスも含め日本語が不自由な感じで、もしかしたら英語で書いたやつを自動翻訳しているのではあるまいか、と邪推してしまうほど分かりづらい。
ちょっと言ってることわかんないな…と、初手で挫折して2年ぐらい放り出しましたからね、僕。
説明の抜けが多く、特にプラグイン作成のための情報は、本体もサンプルもコード読めるからそれ読めばいいでしょ!って感じの放り投げっぷりだ。
最低でもチュートリアルとリファレンスは必要でしょ。
ということで、個人的に勝手に作りましたので参考にどうぞ。
インタフェースが独特
用語に限らず、エディタのUIやゲームのUIの細かい仕様も、なんだか妙に個性がある。
しかも、世間のツールを使ったりゲームを遊んでたらそうはならんだろうって感じの、ちょっと意味不明の悪い個性だ。
このツクールという閉じられた世界で、ぐつぐつ煮込まれた変な常識はだいたい「意味分からんが受け入れるしかない」に分類されて「最初は意味不明だったけど、これはよく考えられた仕様だ」って分類に入ることあんまりない。
あと「前のバージョンの想定した制作環境では意味があった仕様を、無批判に継承してる」というパターンもある。
例えば、マップのタイルとか「右ボタンでドラッグして選択したあと、ペーストしたい場所で左ボタン」という、ドラッグでの移動でも、カットアンドペーストでの移動でもない、摩訶不思議インタフェースだ。
こんな変態的な操作、マニュアルしっかり読まないと、一生気付かない可能性すらある(※)
個人的な記憶ではPC98時代のペイントソフトでこんなのあった気がする、一太郎でおなじみのジャストウィンドウとかもそうだったかな?
そういやゲーム中のUIでESCキーでメニューを表示するという作法がもうジャストシステムっぽい。
流石にRPGツクールの前身であるDante98から引き継いでいるUI要素は少ないが、パソコン用初のツクールがタイトルについたRPGツクール95から、特にRPGツクール2000以降、ずっと無批判に引き継いでいる。
もしユーザから苦情がなかったとしても、好評だったからではなくて「とりあえずもっと致命的に酷いところにツッコミが入ってた」だけだと思うぞ。
2000の時点でもうUI古臭いのに、それから15年たっても基本構造が変わってないって、ウィンドウに息吹きかけたら埃が舞うんじゃないの?
例えばエクセルも相当変態的なUIだけど、流石にカットアンドペーストでセルは移動できるし、左ボタンドラッグで選択、選択範囲の枠掴んでドラッグで移動できるよ!
40万本売って調子に乗ってるかもしれないけど、所詮ツクールなんてマイナーアプリですよ!! 天下のマイクロソフトですら従ってる一般的なUIに逆らうんじゃあない!! (MSが決めたガイドラインだから当たり前だけどね)
ちなみに、かなり前はエクセルも上述のUIじゃなかったと思うんだけど、前過ぎてちょっと自信ない、かれこれ30年ぐらい前?
てゆーかGUIの黎明期と比べなきゃいけないとか、なんなのシーラカンスなの!? (シーラカンスです)
インタフェースが統一されていない
独特なりにも、全体が統一されているとまだ使い勝手は良いのだが、MVはダメな例としてユーザインタフェースの教科書に載せていいレベルに統一感がない。
例えば検索。他は部分一致でも検索できるのに、なぜかツールボタンから開く検索ウィンドウは完全一致のみだったりする。
メインメニューに表示がある場合とない場合、コンテクストメニューやCmd+Fキーが効く場合、効かない場合。
それに、メインウィンドウだとメインメニューから開く検索ウィンドウと、ツールボタンから開く検索ウィンドウが別なのなに?
さらに一緒に[マップ一覧を検索]ウィンドウも開けちゃうの何。こいつらまとめて一枚でよくない?
検索するIDなんか大した量でもないから、何を検索するかなんて細かく分けずに有無を言わさず全部検索すればいい。
タイルパレットを選択してる時など、Cmd+Fが効かないのも地味に嫌な作りだ。常に検索させていいだろうに。
他にもアンドゥ・リドゥ、ドラッグ、ダブルクリックやスペース・エンターの挙動などがバラバラだ。
統一しようという意思が感じられない、行き当たりばったりの掘っ建て小屋感溢れるUIだ。
固定ウィンドウ一枚主義
一見普通のMacやWindowsのソフトのような外見をしているが、その実マルチウィンドウの概念を持ってない。
おかしい…MVって Multi View って意味も持ってなかったのか?
ユーザインタフェースには、モーダルとモードレスという概念がある。
モーダルというのは状況ごとにモードが切り替わり、そのモード独自の操作法であったり操作範囲になるUI。
モードレスはその逆で、状況が変わっても同じ操作が可能なこと。
極力モードレスであることが良しとされる(というと vi ユーザに噛みつかれるので…)傾向にある。
例えばMVは[データベース]ウィンドウを出すと、メインのマップやイベントを配置するウィンドウの操作ができなくなる。
さらに、ダイアログを開くとメインメニューを殺して操作させないという、雑な実装がなされてる。
典型的以上のモーダルな作りだ。普通はモーダルでもメインメニューの編集は最低限操作できる。
そして恐ろしいことに、メインウィンドウ以外のウィンドウは、大きさを変更できない作りになっている。
なので[データベース]ウィンドウは大きさが変更できないのだ。
完全にDOS時代の画面サイズ固定だった頃のノリ。
いくら画面が広くても、限定されたウィンドウ面積で作業しなければいけない。
覗き穴越しに作業させられているようなものだ。辛い。
特にアニメーションの設定など、固定されたウィンドウが狭い上に、ウィンドウが細かく区切られ、実際アニメーションの設定作業する領域は呆れるほどに狭いのに、操作が必要な画像は多い。
画面余りに余ってるのに大きさ固定で、こんだけしか使えないんですよ。
僕も(公称17才ですけど)そろそろ老眼も気にしなきゃいけないんですよ。
前世に何か悪いことしたのかもしれませんが、今生では善良に生きてると思うんですよ。
パワーポイントの方が100倍使いやすいですし、FlashのUIすらクソだと思ってましたが、MVと比べると不自由なところが思い出せません。
結構本気でアニメーション用のツール作ろうかと思ってしまったぐらいです。
そして、このデータベースウィンドウからさらにウィンドウを表示すると、またさらに狭くなった上に操作はその新たに開いたウィンドウに限定される。
恐怖のUIマトリョーシカですよ!
ツクールとしてMVが革命的(らしい)なのは、テストの際に別アプリで起動して、動作を確認しながら元データを見たり書き換えできること。
マルチウィンドウ(この場合アプリごと別だけど)の良さって、こういうことでしょ。
コンテクストメニュー依存
コンテクストメニュー(いわゆる右クリックメニュー)に機能を依存しすぎだ。
コンテクストメニューを使うなとは言わない、実際便利だ。しかしメインメニューに追加した後にしてほしい。
特に[検索]をメインメニューに置かないというの、異次元の発想だ。
コンテクストメニューは、ボタンなどと違ってウィンドウ内のレイアウトを考えなくて済むし、メインメニューと比べ状況による内容入れ替えが少ないので比較的安易に機能追加されがちだが、にしてもMVは安直にすぎる
Steamだから置いてくれただろうけど、こんなUIじゃAppleやMSストアには置いてもらえないよ!
AppleのヒューマンインタフェースガイドラインとMSのユーザーエクスペリエンスガイドラインを一回でも読んだのか!!
AppleとMSから「こんな作法を教えた覚えはござーませんっ!!」って教鞭で手の甲打たれるがいい!! ビシィィッ!!
ツールチップ依存
ボタンやフィールドなどのUI部品の上にポインタをしばらく置くと表示される、ちょっとした説明が書いてある小ウィンドウ、それがツールチップ。
これが多用されるのも、コンテクストメニュー依存と同じで、全体の設計が整ってないので個別で対処していることの現れかと思う。
ツールチップで説明したからわかるでしょ、という甘えが見える。
本来ツールチップなんかなくても理解できるUIを作らなければいけないのだが。
なお、MVはツールチップの内容読んでも、使い方はわからない!!
というのも表示される情報が、例えば[イベント]ウィンドウの[名前]入力フィールドのツールチップだと。
逆にメッセージ入力ウィンドウのツールチップは明らかに量が多い。
ご覧のように、ツールチップの適切な使い方が全く分かってないのだ。
もっと言うと、GUI部品全般に使い方が分かってない。
数値管理症候群
全体に数字で管理しようとする傾向が強い。
キャラパターンを例にとって、見てみよう。
キャラパターンが上から下左右上向きの順で並んでる意味がわからないと思う。
上向きの方を上におく方が自然だろう。
たぶん昔からの伝統で「向きの情報をテンキーに対応した値で持っていて( d )、それを元に画像の座標を計算し( ( d - 2 )× 48 / 2 )、画像を取り出している」んじゃないかな。
ちょっとコード見てくる……見てきた。
Sprite_Character.prototype.characterPatternY = function () {
return ( this._character.direction() - 2 ) / 2;
};
direction()がテンキーに対応してる向きの値( 2, 4, 6, 8 )を取ってくる。
そんで見ての通りの計算をして、帰ってきた値( 0, 1, 2, 3 )に、キャラの高さを掛けてる。
若干順番が違うだけで予想通りだ。
今時こんな数値に依存したマジックナンバーコード書いてんじゃないですよ。
こういうコード、マイコンBASICマガジンでよく見たよ!!!! 8bit時代の作法じゃん!!
コードレビューは本項の趣旨と異なるので詳しくはやらないが、とにかく固定の数値に依存したコードが多い。
数値フェチと言っても過言ではないように思う。数値管理がとにかく好き、ってことがコードから読み取れる感じだ。
プラグインによってユーザが拡張することを前提としているので、できればコードも数値に依存して欲しくないのだが、百歩譲ってそれは許そう(いやー許したくないなぁ(笑))
このキャラの向きをはじめ多くの部分で、ツクールのエディタにも数値依存が表れているのが非常に良くない。
範囲固定の属性
特にタイルセットで顕著だが「このIDのデータはこういう性質がある」と機能が限定されていて、それをユーザが変更できない。
例えば、A2(というネーミングがもうダメだが)の領域は地面と決まっていて、その場所に置いたタイルは別の性質を持ったタイルとして利用できない。
そして領域のサイズも変更できない。分かりにくいし使いにくい。
タイルを使うときに機能でソートして 、並べ替えたりとかできたっていいのに、とにかくがっちり固定。
ショートカットキーの変更や、ウィンドウのレイアウトが変更できないのも、同じ思想というか、ユーザが使いやすいように環境を変更するという発想自体に欠けてる。
ファイル名による属性
ちょこちょことファイル名によって性質が変わる箇所がある。
例えば、キャラクタの画像ファイル名の先頭に!をつけると、配置するときのY位置がタイルの縁からになる。
ファイル名による性質の変更は、エディタを使っていても絶対気づけない完全な隠し機能である。
特にカジュアル向けの開発環境では、絶対やっちゃいけない機能拡張方法だ。
エディタにオプションをつけて、エディタ上で選択できるようにしなければいけない。
バグ
別のアプリに行って戻ってきたときに、エディタのウィンドウの重ね合わせ順が変わって戻せなくなることがある。
マップ数やイベント数・コモンイベント数などが増えた時に異常に重くなる。
こんなんで、よく長編作る人がいるな。僕なんかマップ数枚でもう不穏な空気を感じて「よし完成!」って完成にしちゃうのに。
僕が作り始めたの2018年で、発売されて時間が経っていたこともあってか、他は比較的安定しているように感じる。
たまに、なんの前触れもなく固まるとか起動できなくなるとかするけど。
「まっ!! ツクールだしな!!」の精神で乗り越えられる程度だ。
なお、Mac版のみの不具合に関しては、Finderのプロジェクトファイルをダブルクリックで開けないとか、結構致命的なのがあるので注意だ。
ここまでのまとめ
- 用語が独特かつ整理されておらず、理解を妨げる
- 説明が下手か説明がなく、理解できない
- インタフェースが独特で、とっつきづらい
- インタフェースが不統一で、操作の予想ができない
- メイン以外のウィンドウが固定サイズで、狭くて見づらい
- 同時に操作できるウィンドウが一枚のみで、作業効率が悪い
- コンテクストメニュー依存のため、いつまでも機能に気づかない
- ツールチップ使いが下手で、ただ邪魔か、必要な情報がすぐ見れないかの2択
- データを数値で管理してるため、ユーザが整理できない
- データの性質が範囲で決まっていて、ユーザが任意に設定できない
- ファイル名でデータの性質が変わり、エディタで設定できない
こうやって並べてみると「お前よくこんなのを『お勧めです』とか言ったな!」って感じだ。
しかし、僕は他の開発環境に個々では優れた機能があっても、やっぱり全体としては劣悪だったりすることを知っているので、相対的に「割といいんじゃない」という感想に変化はない。
他の開発環境「英語しか対応してない」に始まって、割と致命的なの当たり前にあるからね。
ただこういう変な作りになってしまう原因は割と想像できて、初心者向けの開発環境として絶対参考にしておかねばならないHyperCard、Flash、Visual Basic、Scratchをなんも参考にしてないんだと思う。
どれか一つでも参考にしてたら恥ずかしくて世に出せないような箇所、いっぱいあるからね。
出力されるRPG部分も世間のRPGをあんまり参考にしてないところあって、良い部分を抽出するセンスに致命的に欠けてる疑惑も高い。
どっちにしろ、酷い機能を酷いとも恥ずかしいとも思ってない風なのは、使っててこっちが恥ずかしくなる。
「ヤンキー界隈で流行ってる格好をいけてる」って思ってる感じの恥ずかしさというか。
ロングレビュー マップ仕様編に、つづく!!