ツクールの何がよくて何がよくないのか、ということをあらためて考えていた。
ツクールは、というかツクールMZは、JavaScript製のゲームエンジンで、PIXI v5の描画と、Effekseer統合があるので、2Dに限っては一定モダンなゲーム開発環境だと思う。んで、インディーで3Dをやりたい理由がなければぜんぜんUnityやGodotに行く必要がなくて、ツクールは選択肢に入る。
ツクールが苦手なもの
あくまで主観であって統計的な根拠がある話ではないです。
- 大量のオブジェクトを動かす（ヴァンサバみたいなやつ）→ ECSを導入すれば……と思ったが、JSがECSをやるのに向いてない。できなくはないんだけど、メモリ最適化みたいなのをJSでがんばるのはけっこうしんどい。
- 3D → three.jsとかbabylon.js があるので技術的には可能。ただ、ここのしんどさって「3Dのレベルエディタが統合されていない」ことなので、それをどう解決するか。babylon.jsにはシーンエディタがある。blenderをシーンエディタにすることもできる。でも実は筋がいいのはUnityをシーンエディタにしてエクスポートされたjsonを読み込めるようにすることかもしれん。そこまでしてなんとか……という感じだけど、でもそのしんどさはUnityだったら緩和されるかというとあんまそうでもないかもしれない。素直にBakinを使ったほうがいいと言われれば、それはそう。
- Live2D → できなくはない。ただ、いくつかのゲームを見た感触では読み込みが重め。非同期ロードをどう最適化するかの設計が鍵になりそう。
- Spine → いくつかのゲームを見た感触では、Live2Dよりは軽い印象がある。
- ノードベースの状態遷移 → ツクールはコマンドリストベースなので、ノードベースを組み込むのはちょっとしんどい。局所的に取り入れるのはできるとは思う。ノードエディタを誰が用意するのかという問題はある。ノードベースの状態遷移があればNPCのAIの挙動を作りやすくなる。
- 非グリッドベースの衝突判定 → 上に書いたものに比べれば導入可能性は高い。コリジョンマップの外付けで十分実現可能。
- 物理演算 → 導入を検証したことがあるが、問題ない。matter.jsやrapier.jsは統合可能。重さも問題にならない。設計は相応に重い。アクションゲームが作りたいなら、GodotやAction Game Makerのほうが筋が良い。アクションRPGやアクション移動つきRPG（ヴァルキリープロファイルのような）を作りたいなら、ツクールMZの出番はある。
- リアルタイム性が重要なゲーム → GC制御が困難なので、もしリアルタイム性が重要ならGodotやUnreal Engineで作ったほうがいい。リズムゲームなどは明確に不向き。
- 暗号化 → とはいえ Unity も別に完全に暗号化できるわけではない。フォルダ除いただけでデータファイルが見えちゃう、くらいは防ぎたいが、これは技術的にはぜんぜん不可能ではない。正直、暗号化したからといってゲームが面白くなるわけではないので、こんなところに力を入れるくらいなら他にやることありそう。簡単に抜き出せなくするくらいの対応は十分できるし、それで十分と割り切るべき。これは Unity でもいっしょ。
ツクールが得意なもの
- コマンドリストベースの状態遷移 → コマンドリストベースなので、復元が容易。任意の地点からレジュームできる作りは、たとえばアドベンチャーゲームのようなシーケンシャルなゲームデザインと相性がいい。処理の流れが上から下なので、シーケンスを追いやすい。ここは一長一短ある。
- グリッドベースの衝突判定 → 実装が枯れていて、十分機能する。
- セーブ・ロードできるゲームデータ管理 → ゼロから実装するのは意外と大変。
- キャラクター・アイテム・スキル・敵のマスターデータ管理 → これもゼロから実装するのは大変。ただし拡張性はあまり高くない。拡張の実装自体の難易度は低いので、デメリットというほどでもないかも。
- メッセージシーン → これを作るのがどれだけ大変かは、Unityでゼロからゲームを作ったことがある人は知っていると思う。
ツクール自体に起因しないが、問題になりやすいもの
- 巨大なテクスチャーの読込・破棄を繰り返す → 一枚絵マップでありがちなんだけど、これをやると簡単にVRAMを食い尽くして死ぬ。我々に必要なのは最適化されたテクスチャーアトラスを使って、最小コストで描画する努力。そしてそれって、ツクールだけに求められるものではない。Unityでも雑に作れば重くなる。illusionのSBPRなんか今のマシンでプレイしても重いからね。
というわけで、ツクールMZにもそれなりのアドバンテージがあり、ここは見落とされていると思う。Unityにメッセージシーンのプラグインは、たしかにある。それを自分のゲームに組み込むには相応の設計スキルが必要で、一方ツクールはシーンに統合されている。より正確に言うと、マップシーンも戦闘シーンも、メッセージシーンを拡張して実装している。この作りが手堅い。
ツクールのよさをどう伸ばすか
ツクールの苦しさは、独自のシーンを作るために独自のUIを実装しようとすると、そのためのインターフェースがないので、自作シーンクラスを提供するプラグインを用意するか、さもなくば大量のピクチャボタンや文字列ピクチャを並べた複雑なコモンイベントの組み合わせ、という感じになる。とはいえ後者はウディタでもそうなりがち。ウディタとの違いは、ウディタにはイベントスコープがあること。イベント内に閉じた変数を使えることで、コモンイベントのポータビリティが高い。ツクールもこうなっていれば、苦しみは軽減される。
コモンイベントに引数と戻り値を用意し、イベントスコープのローカル変数を用意し、そしてデータベースや変数を名前解決できるようにすれば、原理上、ID固定の依存関係がなくなって、プロジェクト間を行き来して移植可能なコモンイベントが作れるようになる。リファクタリングもしやすい。そう思い、作り始めた。4割くらいできている。残りの6割は、名前解決を利用した既存のイベントコマンドの置き換えがまだ終わっていないから。イベントコマンドの大半がプラグインコマンド、というイベントを組むことになりそうだが、それで問題はなさそうに思う。文章の表示などはローカル変数を参照できればいいだけなので、そのまま文章の表示コマンドを使える。条件分岐はスクリプトを書くしかなさそう。evalしない内部コマンド呼び出しを行うスクリプトというアイデアはあってもいい気はする。
自作シーンクラスは大量のボイラープレートコードを繰り返し書くことになり、メンテ性も悪い。イベントで組んだほうがよくないか？と最近思い始めた。
イベントコマンドから汎用ウィンドウを並べられるようにできればいい。quince を使えば、ウィンドウや要素の自動レイアウトができる。今その仕組みを作っていて、3割くらいできている。3割というのは、quince統合ができてシンプルなテキスト描画や変数のデータバインディングなどが機能しているという状態。データバインディング層がまだスカスカなのと、画像描画などの機能が不足していて、これではまだ実用できない。あとテストも足りていない。quinceは十分テストされたライブラリだけど、ツクール上で機能するかはいろんなデモを組まないとわからない。
どちらも、思想的には「イベントコマンドで戦える範囲を広げる」であって、任意のプログラムコードで拡張可能にするというものではない。それはもうあるからね。
というわけで、地道にコードを書いたり、書かせたりしている。設計を自分ひとりで煮詰めなくてもよくなったこと、テストコードを書かせて検証しやすくなったこと、いろんな理由でこの試みがうまくいきそうな気はしている。うまくいったらいいなと思う。
こちらからは以上です。
