あなたの意見はどうですか？
Unity ベースで構築されているので、最適化が進み、より大きなマップなどが実現することを期待しています。ただし、重い Unity アーキテクチャがモバイル（Android）で動作する際のパフォーマンスが心配です。
WIN/Android/Linux への移植がうまくいくことを願っています。
また、webm/webp/ogg 形式をはじめとする多くのフォーマットに対応することを強く望みます。
RPG Maker MV で webp を動作させるための回避策を講じるのは面倒でした。サイズを 3〜5 倍削減できるのは必須だと思います。特に容量が限られたモバイル端末（おそらく古い機種に限られるでしょうが、2〜4GB がまだ上限という状況は続いていますか？）では重要です。
どのようにコーディングされているかを見ない限り、有益なことは言いにくいですが、これが私の経験です。最適化と柔軟性はしばしば相反し、残念ながら RPG ツクールは柔軟性重視で設計されている必要があります。
RPGM Unite のパフォーマンスはいかがでしたか？私は巨大な商用プロジェクトを完成させた後、エンジンを変更したため、あまり深く掘り下げていません。Java のパフォーマンスに満足できなかったのです。
Uniteは非常に低速でした。私はそのコードアーキテクチャについて詳しく調査できませんでしたが、主な誤りの一つは、タイルセットを使用しないエンジンを作ろうとした点にあります。その代わりに、すべての画像を個別のゲームオブジェクトとして扱うシステムを採用しました。その結果、小さなアイコン一つ一つに大量のメタデータがプリパッケージされ、読み込み時間に悪影響を及ぼしました。
もう一つの重大な誤りは、NPCをグローバルデータベースで定義するシステムを作った点です。RPGmakerでは伝統的にNPCをマップに紐づけています。この選択は、NPCがゲームワールド内で単一の場所しか持たず、マップ間を移動する『スターデューバレー』のようなゲームを作っている場合には問題ありません。しかし、ほとんどのRPGはこの機能を必要とせず、私たちがよく使用するイベントシステムの方が適しています。
また、JavaScript自体は正常に動作しますが、世に出回っている多くのプラグインには、一般的に知られていないパフォーマンス上のリスクが潜んでいます。プラグインを実行するためにノートタグでJavaScriptを記述する開発者であればご存知かもしれませんが、通常のプラグインに記述されたJavaScriptよりも数千倍も低速です。JavaScriptは、コンピュータが処理するために機械語に変換される必要があります。プラグインの場合は、ゲーム起動時にすべてが機械語に変換されるため問題ありませんが、データベース内に記述したコードや、イベント内のスクリプトコールに記述したコードは、後から機械語に変換され、メモリアドレスとマッチングさせる必要があり、これは非常に低速なプロセスです。
最終的に、ゲームのパフォーマンスは開発者の責任です。
うーん、つまりこのゲームは通常の2D平面ではなく、UIキャンバス上に全体が構築されていたという事実が、私にとっては驚きでした。Unityにおいてキャンバスはそうした用途には最適化されていません。ただし、前述の通りUnityのワークフローに従えば、驚くほどの柔軟性を達成することは可能です。
しかし、このUnityの書き方は基本的に、「Unityの上にボックスを作り、Unityのアセットと事実上互換性のないものにする」というものでした。
私が実際に返金を行ったRPGメーカーはこれが唯一です。
正直、それほど期待はしていません。自社でエンジンを作ったり独自開発したりするのではなく、他のゲームエンジンを使おうとした時点で間違っていたと思います。
私の最大の懸念は、MV が解像度に応じていかにひどく拡張されるかという点でした。1080p に変更すると、すぐに顕著なパフォーマンスへの影響が現れます。
少しぶっきらぼうかもしれませんが、Unite を使ってみてかなりがっかりしました。以前のエンジンバージョンに比べて多くの機能が削ぎ落とされており、Unity 自体の機能を活用するのにも優れていませんでした。
例えば、ループマップを作成できない点は、多くのエンジン（RMXP を除く）がその機能を持っていることを考えると、いつも奇妙に感じられます。また、学習曲線が MZ などと比べてもあまり変わらないのに、なぜか急勾配に感じられました。
Unity について言えば：
ゲームプレイに Canvas を使ったのは確かに奇妙な選択でした！
しかし、エンジン開発の基盤として Unity を使うのは賢明な判断だと思います。毎回ゼロから構築する必要はありません。また、Unity には開発に役立つ多くのツールがあり、社内で開発するにはコストがかかります。コンソール承認の取得や、早期にツールを利用可能にすること、サポート体制の整備などもその例です。これらは無料ではなく、Unity を活用することで、これらの手間をある程度省くことができます。
Unite で行われたことは、正直あまり良くなかったと思います。一部の決定は理解できますが、一部は過剰設計に感じられました。特にタイルセットのセットアップは私にとって非常に不自然でした。
大まかに言えば、JavaScript は実際には機械語に翻訳されるわけではありません。バイトコードにコンパイルされ、その後、機械語にコンパイルされる言語で書かれた仮想マシンによって処理されます。ブラウザのようなプラットフォームで実行される場合、これらの仮想マシンには、JavaScript ソーステキストからではなくバイトコードから機械語を生成する JIT コンパイラが含まれています。
QuickJS などの埋め込み可能な JavaScript エンジンもバイトコードを実行しますが、JIT コンパイラは搭載していません。
あなたが説明しているのは、データベースやイベントコマンドに含まれるコード文字列に対して eval を起動するコスト（バイトコードへのコンパイル、コールドパス、まだ JIT されていない状態）と、それを単純なバイトコードインタプリタモードで実行するコストです。
これは技術的な観点からも、「社会的」な観点からも最悪のアイデアです。まるで、小型ボート漁の専門家である漁師全員に、油タンカーで漁をさせるようなものです。
無料で多くのものが手に入ると考えているため、魅力的に思えるのもわかります。しかし、そのような思考プロセスが、現在のソフトウェアの姿である「肥大化した混沌」を招いています。
プログラミングに興味のある方全員に、Jonathan Blow による「文明の崩壊を防ぐ」という講演の視聴をお勧めします。
とは言え、GGG には成功を願っているため、RPG Maker U2U が Unite よりも良い成果を上げてほしいと願っています。しかし、その後は Unity を離れ、適切な「メインライン」または「スタンドアロン」版の RPG Maker が登場することを期待しています。
それまでの間、@niokasgami が取り組んでいるエンジン刷新の動向を注視し、MZ の寿命を延ばすためのいくつかのものを公開する予定です。
unite の構築方法には問題があります。彼らはツールの活用を一切行っておらず、事実上他者がそれらを使用することも不可能にしています。あるいは、非常に使いにくいものでした。
ジョナサン・ブロウは余剰資金を何百万も持っている。ほとんどの企業は利益を出そうと努力している。
2つ、初歩的な質問で申し訳ないのですが、UniteはUnity上で動作しているとのことですが、UnityがアップデートされるたびにUniteも更新される必要があるのでしょうか？
また、Uniteで制作されたゲームは、Unityのガイドライン、例えば段階的な収益分配構造に従う必要があるのでしょうか？
UniteとUnityは別物です。まずUnityのバージョンを1つインストールし、その後Uniteウィザードアプリケーションを使ってプロジェクトを作成します。そうすると、必要なパッケージがすべてインポートされ、プロジェクトがUnityで開かれます。
セットアップ時、Uniteは複数の推奨バージョンを提示します。以前Uniteで作業していたとき、6.0を試したらうまくいった記憶があります。今、Unite自体がそれをサポートしているかどうかは覚えていません。
返信ありがとうございます。Unityの仕組みについてあまり詳しくないため、ご容赦ください
私の理解が合っていれば、UniteはUnity上にRPGツクール風のプロジェクトを生成し、その後は通常のUnityプロジェクトとして扱われるということですね。そして、もし新しいUnityのバージョンがUniteと正しく動作しない場合、動作する以前のUnityバージョンに設定できるのでしょうか？
私がこの点をお聞きしたのは、スタンドアロンのRPGツクールが気に入っている理由は、一度購入すればその後の利用に追加費用や条件が一切ないからです。一方、Unityは「これで完成」という感じがあまりしないため、UnityベースのRPGツクールを使うことに少し不安を感じています。
みなさん、U2U の今後の展開にご関心をお寄せいただきありがとうございます。
先月、BitSummit で新しいマップメーカーの初めてのハンズオン体験会を開催し、多くの方から素晴らしいフィードバックをいただきました。また、参加できなかった方々からのコメントもすべて確認しました。「Unite の繰り返しではないか」という懸念や、再び Unity をバックエンドに使うことへの不安など、すべてです。
現時点では新しい情報を発表する準備が整っていないものの、皆様の声は確かに届いていることをお伝えします。次回の情報発信では、U2U が重要な点においていかに Unite と異なるのか、よりご理解いただけるようになることを願っています。
どうか今しばらくお待ちください。また、皆様の要望や希望をぜひ教えてくださいね！私たちの耳はいつでも開かれています！
u2uは良さげな感じだね。サイズはもっと大きくなると思うし、このエンジンなら美術スタッフには結構きついはず。
このエンジンには期待してるから、あとで自分の言葉が当たらないようにしてほしいな。
個人的には、Unity フレームワークを使った非 Unity エンジンに期待しています。なぜなら、コンソール向けに Unity プロジェクトを公開する際にラッパーが必要ないからです。MV と MZ はどちらも HTML5 を使用していますが、ソニーやマイクロソフトはセキュリティ上の懸念からラッパーなしの HTML5 をホストしないため、この新しいアプローチは追加の手順を踏むことなく、コンソール向けのパブリッシングをよりアクセスしやすくしてくれるはずです！
Uniteはグローバル的には失敗でした——高価すぎ、そして残念なことにUnityの問題も絡んでいました。Unreal Engineなら面白い展開になったかもしれませんが、Unityは依然として不十分だと懸念しています。私は個人的にNode.js版が好きでした。
また、U2U2は2Dから3Dへの移行という点で第一歩を踏み出したばかりであり、その分野では『RPG Developer Bakin』に比べて遅れています。MV/MZレベルの品質がないと、人々が使いたがるようにはならないでしょう。
どうなるか見ていきましょう。ただ、期間限定のデモ版も必要です——私はUniteを試していません。公開当時、私には過度だと感じた金額を支払わずにテストする方法がなかったからです。その後、一時的に無料でアクセスできるようになった際にも、機会を逃してしまいました。
編集：どうやらUniteは現在ストアで20€未満のようです——まだ試すチャンスかもしれません。
私の経験では、Unreal は 2D にはやや不向きです。2D は実現可能ですが、2D 向けに特別に優れた機能を提供しているわけではありません。
Unity は少なくとも、2D レンダラーを備えているかのように振る舞おうとしています。
両者は同じアプローチを採用しています。直交投影が設定された 3D 空間に、正面を向くようにカメラを設定する方法です。しかし Unreal は、特別な 2D クラスすら提供していません。代わりに、すべての 3D クラスを取得し、Z 軸方向に固定して、祈るしかないのです。
さらに深く掘り下げると、どちらも真の 2D には対応していません。それには Godot か GameMaker の方が適しています。
U2U は Unreal でも十分機能するでしょうが、それは「透視投影 2D」に焦点を当てた場合に限ると言えます。純粋な 2D については Unreal はやや不向きだと考えているからです。技術的には可能ですが、例えプロジェクトさえもがやや貧弱です。
私が U2U について懸念している主な点は、それが本当に Unite の基本機能を MV/MZ レベルに引き上げられるかどうかです。ここで言うのは特にエディターの操作性です。ゲーム自体はそこそこ動いていましたが、ゲームを編集する感覚は悲惨でした。なぜなら、長年標準であり常識だった一般的な機能が欠けていたり、あるいは備わっていても非常に分かりにくい実装だったからです。
Unite は新しいエンジンとして扱われるべきだと理解しています。つまり、過去のエンジンから機能を引き継ぐ必要はなく、既存ユーザーに合わせる必要もないのです。既存顧客にとって親しみやすいものとして提示するためにはそうすべきだと私は考えますが、機能させるために設計上「必ず」そうしなければならないわけではありません。しかし、現在の設計と現在の体験は物足りないと感じています。
この先はあまりにも率直すぎるかもしれませんが、自己弁護せざるを得ません。昨日 Unite を再確認したところ、開くたびにイライラさせられます。UX として明らかに間違ったことがさらに見つかるからです。一見すると些細な細部に過ぎないと思えるかもしれませんが、それらが積み重なってしまうのです。
MV でイベントを削除するにはどうすればよいでしょうか？Delete キーを押すだけです。バズ、消えました。確認ウィンドウは不要です。それはプロセスを遅くするだけです。イベントでいっぱいのマップを作成した場合、300 個のイベントを一つずつ削除する代わりに、マップごと削除して最初から作り直すのでしょうか？
インターフェースのバグがいくつかありましたが、それについては言及できません。手元にあった Unity 6.3 を使っていたためです。これは私の責任です。推奨バージョンは依然として v2022 です。v6.3 は概ね動作しますが、問題もあります。後で他のテスト用に 2022 をインストールします。
U2U が Unite の欠点から学び、より良いものになることを大いに期待してこの投稿をします。
正直に言って、私はおそらくU2Uは買わないでしょう。というのも、私はUnityがあまり好きではないからです。もしGodotやUnrealに基づいたものを作ってくれたら、試してみようかなと思います。（実際にGodotを試したことはないですが、良い評判を聞きますし。）また、MVやMZと同様のJavaScriptベースのエンジンを作ってくれたら、購入を強く検討するでしょう。
Unrealについてこれが本当に正しいのかは疑問です。私がUnrealでやったことは3Dだけなので、2D機能がどれほど優れているかはわかりませんが、このための専用モジュールとして「Paper2D」があります。タイルシートからスプライトを抽出できることは知っていますし、タイルマップのサポートもあるようです。（Tiledのマップファイルをインポートできるという噂も聞きました。）
また、Unrealでは3Dアセットと固定された視点を使って2Dを作成することももちろん可能です。
