ゲームを別のエンジンへ移植する
ゲームを別のエンジンへ移植する
他所のプロジェクトを読んで動くゲームを出すインポーターはない。アセットはファイルとして移り、ロジックは書き直し、本当の元は設計だ。
ゲームの別のエンジンへの移植とは、権利のあるゲームをそのエンジンで作り直すことだ。開かれた形式のアセットはファイルとして移る。エンジン固有のスクリプト、シーン、プレハブ、エディタのツールは移らない。どの二つのエンジンの組み合わせでも同じだ。
これは聞こえるほど悪くない。完成したゲームで高くついた部分は、設計、コンテンツ、調整、そして何が効くかという知識であり、そのすべてが残る。コードはたいてい作り直しが最も安い。設計を発見するのではなく、分かっている仕様を実装し直すからだ。動くゲームを最初に作ったときより速く作り直すことは、実際よくある。
Summer Engineはその作り直しのために作られている。普通の言葉で仕組みを説明して最初の版を生成し、その後は実際のプロジェクトをC++かGDScriptで編集する。C#はwebを除くすべての対象で使える。Godot 4のワークフローと互換があり常にGodotの上流に追随し、百万行を超える独自コードを持つ完全な独自エンジンだ。一つのプロジェクトがデスクトップ、モバイル、web、コンソールへ書き出す。
移るものと決して移らないもの
移るもの。テクスチャ、スプライト、音声、フォント、glTFかFBXの3Dのメッシュとアニメーション、ローカライズの表、バランスのデータの表計算、そして参照としてのシェーダーの数式。決して移らないもの。エンジンのAPIに結び付いたスクリプト、シーンとプレハブのシリアライズ、視覚的なスクリプトのグラフ、アニメーションの状態機械、特定の解法に依存した物理の調整、エディタの拡張。マーケットのアセットは一つのエンジンにのみライセンスされていることもあるので、再利用の前に確認する。
古いプロジェクトを仕様として扱う
古いコードを開いて数値を書き留める。移動速度、加速、重力、ジャンプの高さ、ダメージ、クールダウン、出現の頻度、ドロップの表、カメラのずれ、アニメーションのタイミングだ。原版のゲームを録画し、並べて比べる。作り直したゲームがおかしく感じるのは、構成が変わったからではなく値を近似したからだ。正確な定数を書いた短い文書は、どんな移植でも最も価値のある成果物だ。
まず垂直スライス、コンテンツは次
何よりも先に、レベル一つ、敵一体、プレイヤーのコントローラ、ポーズメニュー、セーブの仕組みを作り直す。そのスライスがエンジンの適合を証明し、残りの本当の日程の見積もりを与える。レベルはデータなので、仕組みができればコンテンツは速く移る。先にコンテンツを移したチームは、後で仕組みが変わったときに作り直しが必要になるアセットに何週間も費やす。
移植をやる価値がある理由
よくある動機は、ロイヤリティとライセンスの費用、古いエンジンでは届かないプラットフォーム、ビルドの大きさ、反復の速さ、性能の上限、チームと噛み合わないツール、そして企画と方向が合わなくなったエンジンだ。始める前に理由を書き留める。それが、移植が成功と言えるために何が良くならねばならないかを決め、作り直しが退屈な中盤に入ったとき日程を守ってくれる。
よくある質問
エンジン間でプロジェクトを変換するツールはあるか
汎用のものはなく、Summer Engine向けのものもない。アセットのファイルは変換できる。ゲームのロジック、シーンの構造、エディタのデータは変換できない。一押しのエンジン変換をうたうものは、よくても壊れたプロジェクトを出す。
エンジンの移植にはどれくらいかかるか
コンテンツではなく仕組みで測る。コントローラ一つといくつかの仕掛けの小さなゲームなら、数週間であることが多い。独自ツールと大量のコンテンツを持つ大きなゲームなら数か月だ。垂直スライスを作れば見積もりが本物になる。
アセットは失われるか
権利があるなら失われない。テクスチャ、音声、モデル、アニメーション、フォント、データのファイルは標準の形式で移る。マーケットのコンテンツはライセンスを確認する。特定のエンジンに限定されているものがあるからだ。
書き直しをAIに任せられるか
最初の版の大部分は任せられる。仕組みとその正確な値を説明すれば、Summer Engineが動くシーンとスクリプトを生成し、それを自分で確認して調整する。確認は自分の仕事だ。原版がどう感じられたかを知っているのは自分だけだからだ。
移植したゲームの手触りは同一になるか
数値を持ち込み録画と比べれば近くなる。物理の解法はエンジンごとに違うので、紙の上で値が一致していても、移動と衝突には調整の工程が要ると考えておく。
さらに見る
Summer Engine で創るその他の方法
AI ゲームメーカー
説明するだけで完全な 2D・3D ゲームを作れるハブ。
開くHow to port a 3DS game
The full process, in order: rights, asset inventory, rebuild, screen and input redesign, testing, export, and store submission.
開くPort a game to Steam
Steam takes a desktop executable, a depot, and a store page. This is the checklist for getting any game from another platform onto it.
開くPort a game to iOS
Any iOS release needs a Mac, an Apple Developer account, a signed build, and a design that works with thumbs. This is the full path.
開くPort a game to Android
Android has the lowest barrier to testing and the widest device spread. Signing keys and the target API level are what actually block releases.
開くPort a game to Nintendo Switch
There is no self serve Switch export. Nintendo approves developers, provides the SDK and dev kits under NDA, and certifies every build.
開くPort a game to web
A browser build has no filesystem, a hard memory ceiling, and a download the player watches. Those three facts shape the whole port.
開くPort a game to console
Every console platform gates access. Approval, an NDA covered SDK, dev kits, and certification come before any build reaches a store.
開くPort a game to Steam Deck
Steam Deck runs your existing Steam build. The port is a compatibility pass: controller first input, readable text, and a power budget.
開くプラットフォーマーのテンプレート
既成のプロジェクトから始めて、変更を説明するだけ。
見るすべてのゲームテンプレートを見る
既成のプロジェクトから始めて、変更を説明するだけ。
見る