2025年のゲーム開発 エンジンなしってどうなの？

Unrealは詳しくないけど、Unityはスクラッチでプログラミングするより断然速いよ、楽に10倍以上。
分かりやすい例は物理挙動だね。これは1分足らずでゲームに追加できるけど、自作エンジンだと外部ライブラリをちゃんと組み込むのに1日か2日はかかるだろうね。Noelさんがここで見せてる内部状態の可視化は、Unityだとデフォルトで全部入ってるんだ。
バウンディングボックスを描画したり修正したりする良いツールもあるし、エンジンの挙動だけじゃ足りない稀なケースでも、拡張性がすごく高い（ImGuiとか、俺が好むUnityのYogaベースのCSSエンジンを使ったりして）。
Unityにはこういう機能が無数にあるんだ。洗練されたパーティクルエディタ、膨大な複雑さを抽象化して「一度書けばどこでも動く」高レベルなシェーダー言語、モジュラーデータをストリーミングして追跡するシステム、その他にもたくさんたくさん。
理想の世界なら、こういうのは自分で書きたいんだけど、時間は刻々と過ぎていくし、残念ながらゲームを早く完成させることを優先したいと思ってるんだ。

過去に2Dゲームを作るのに手を出した経験があったんだけど、Unrealでゲームを作るのに、チュートリアルとアセット作成のドキュメントを数日かけてこなしたら、アセット制作がボトルネックになるレベルになったよ。Godotなら、数時間でひどいゲームを作れるようになるポイントに到達したね。
モダンなゲームエンジンがどれだけ多くのことを代わりにやってくれるかは驚異的だよ。既存のエンジンでゲームを実装するより、スクラッチでエンジンを書く方が速いと主張する人は、自分を欺いてるだけだと思う。

この時点では、Unity以外のエンジンを使うのが何でもマシだね。Unityは信用できないって何度も示してきたし、彼らをベースにゲーム（やビジネス）を構築することはできないよ。

＞スクラッチでエンジン作るの時間がかかりすぎだってよく言われるよね。でも、UnrealとかUnityをアイデアをゲームにスムーズにできるレベルまで”ちゃんと”学ぶのにどれくらいかかる？
＞おそらく、一度自分のエンジンができちゃえば、そのレベルの専門知識は”即座に”手に入るわけだから、これはものすごい時間節約になると思うんだ。
一度、自分のゲームエンジンを作る実験をしたことがあるんだ。構築と学習に約1年かかったよ（試行錯誤で、最初は多くの行き止まりがあった）。
ゲームに通常あるようなたくさんの機能（ベルとホイッスル全部付きの3Dレンダリング、flexboxに触発された適応型UIフレームワーク、スケルタルアニメーション、セーブファイル形式、スマートオブジェクトシステム、パスファインディング、スクリプト言語、オーディオ、物理などなど）を備えてた。
具体的には、Braidのシステム（それが存在することを知らずに）を再現しようとしたんだ。これは、ゲームを任意の時点に巻き戻せるってもの。スクリプト、物理など、エンジンの全てのサブシステムからのサポートが必要だった。
自分のゲームエンジンのあらゆる細かい詳細を知ってるのは、確かにプラスだったね。エンジンが”だいたい”完成した後、どんなに野心的な機能でも追加するのはせいぜい数時間くらいだったよ。何か動かない時も、何が起こってるか正確に分かった。
ただし、1年構築した後、多少燃え尽きて、続けるモチベーションが全部消えちゃったんだ :)

＞一方で、ハイパーリアルなオープンワールドRPGを作りたいなら、自分でやるのは多分良いアイデアじゃない。
俺はそれとは正反対だと思うね。そのジャンルなら、自分のエンジンをロールするか、オープンソースを選ぶのがベストだよ。俺が直接経験した問題のリスト：
エンジンにはたくさんの機能やオプションがあるけど、それら全部を同時に使えるわけじゃない。ある機能は別の機能を無効にするんだ。エンジンができる全ての素晴らしいものリストを見るんだけど、ある時点で、”絶対に”必要なことができない（あるいは効率的にできない）と気づくんだ。あの素晴らしく見えるグラフィックは全部、実際には使えない、単にパフォーマンスが出ないか、互換性がなくて使えないんだ。
”ベイク”モードでしか動かない機能がある。”ベイク”はエンジンのエディタで行って、ゲーム実行時にそれを変える方法がない。Unrealはこの点で最も制限があるけど、Unityも大差ない。一部のゲーム開発者は、実行時に機能の挙動を変えるために、Unityの内部アセット形式をヘックスエディタでリバースエンジニアリングしてるくらいだよ。その時点では、自分でエンジンをロールする方が理にかなってる。俺が見た例の一つは、開発者がライトプローブグループのアセットファイルをリバースエンジニアリングして、実行時に新しいライトプローブグループを追加できるようにした例だね。
エンジンのAPIはバージョンごとに劇的に変わる。全てのコードとスクリプトは、常にリファクタリングが必要になる。致命的なバグに遭遇して、唯一の解決策がアップグレードだけど、アップグレードはコードベース全体を壊すことを意味する。
エンジンの抽象化を通る必要があって、それが効率的にできない場合は運が悪い。これの例：Unity HDRPはスクリーン空間アンビエントオクルージョン（他のエフェクトと共に）を適用する。これは画面全体にエフェクトを適用するんだ。キャラクターの三人称視点が近いか、一人称の手/武器がレンダリングされてる場合、それらの上にも適用される。その結果、一人称の手/武器の周りに白いハローができて、見た目が悪くなる。カスタムエンジンなら、解決策はシンプルだ。一人称の手がレンダリングされる前にフルスクリーンエフェクトを適用し、その後エフェクトなしで手を描画する。これは、数行のコードの順番を切り替えるだけの問題だよ。
解決策はgithubと、BSD/MIT/Apacheライセンスのゲームエンジンやライブラリだね。

人の好み、経験、専門知識、哲学を考慮せずに、”妄想カード”に手を伸ばすのは全く不誠実で、ゲーム開発を全体的に見ていないことを示してるね。確かに、既存のエンジンは特に3Dレンダリングや物理に関して多くのことを代わりにやってくれる。でも、物理のないゲームはどう？あるいは、予想とは全く異なる物理を持つゲームは？
アセットがボトルネックだって言ってたけど、アセットを全く使わないゲームはどう？3Dが解決されてるのは素晴らしいけど、もしゲームが4Dをエミュレートしようとしてたら？あるいは、GUIがただ嫌いで、それが作業を遅くするだけなら？
もっと具体的な議論をしよう。Unrealをチュートリアルで学ぶのに数日かかったとも言ってたけど、それは”超基本的な理解”について話してる場合を除いて、確かに不可能だよ。同じように、OpenGLの上に基本的なエンジンを作るのに数日かかることもあり得るんだ。

もし君のビジョンが変わってたりニッチだったりするなら、最初からそれに特化したツールセットを作る方が長い目で見れば全然効率良いことあるよ。

時として信用できない相手とも取引しなきゃいけないんだ。エンジンに競争相手がほぼいない多くの種類のゲームにとって、「全部かゼロか」のアプローチを取るのは未熟だし現実的じゃないね。

武器にもポストエフェクトがかかるように、別のポストエフェクト設定を持ったレンダリングレイヤーを用意するのが多分いいと思うよ。これコード変えなくてもエディターのGUI設定でできるはず。
確かSRP全部C#で、「ソースコード利用可能」なオープンソースだから編集できるよ。
https://github.com/Unity-Technologies/Graphics/tree/master/P…

信用できない相手にビジネスを完全に依存するなんて、ちょっとおかしな話に聞こえるね。

まあさ、開発スピードに関する全く間違った主張に反論しようとして、君は個人的な好みや「もしこうだったら？」みたいな話を持ち出してるけど、それが君の立場を正しいとは限らないんだ。例えば、もし俺のゲームが4Dをエミュレートしようとしてるとしても、俺自身のエンジンはそれ以外の全部、グラフィックとか入力とかオーディオとか物理とかもやらなきゃいけないんだよ。Godotで4D作るのと、自作エンジンで4D”と”グラフィック”と”入力”と”オーディオ”と”物理”と…を作るのとじゃ話が違うってこと。

＞特に、ゲームを任意の時点に巻き戻せるBraidのシステム（存在は知らなかったけど）を再現しようとしたんだ。それはエンジンの全サブシステム──スクリプト、物理なんかの巻き戻し──のサポートが必要だった。
いや、必ずしもそうじゃないよ。
君は自分の「スナップショット可能なアロケーター」を書けるんだ。それを使えば、たとえ修正してないサードパーティライブラリやインタープリターの状態だって巻き戻せる（それらが君のアロケーターを使うように設定できればね）。
これについてhttps://www.jfgeyelin.com/2021/02/a-general-state-rollback-t…に書いたよ。

AntichamberみたいなゲームはUnreal (3)で非ユークリッド空間とレンダリングをやってるし、Enera（開発中のアクションゲーム）はUnrealで時間巻き戻し（Braidみたいな）を実現してる。SuperhotはUnityだしね。
一番良いツールは君が知ってるツールだよ、たとえ君のビジョンが変わってたりニッチだったりしてもね。結局のところ、Unityが提供するあれこれを全部無視して、MonoBehaviourスクリプトでカスタムロジックを書いて、それをプラットフォームツールキット、入力ハンドラー、コンテンツパイプライン、スクリプタブルエディター、レンダラーとして使うことだって常にできるんだ。特に長い目で見れば、そこから得られる機能には言うべきことがたくさんあるよ。

これに関して、開発者の振り返り記事とかある？ Cities: SkylinesやOvercookedはすぐ思い浮かぶ例だけど、俺のお気に入りのゲームの中にはUnityで作られたのがいっぱいあるし、それらのゲームを全然失敗作だなんて呼ばないけどね。

＞そこにはゲームによくあるものがたくさん含まれてた（3Dレンダリングに全ての飾り付け、flexboxに触発された適応型UIフレームワーク、スケルタルアニメーション、セーブファイル形式、スマートオブジェクトシステム、パスファインディング、スクリプト言語、オーディオ、物理などなど）。
でも、本当にそれ全部必要だった？

俺が言いたかったのは、もし君のビジョンがそういうエンジンの「普通」の流れから大きくかけ離れてるなら、時として自分で作った方が摩擦が少ないってことかな。

「エンジン自作は時間かかるって言うけど、Unreal/Unityをアイデアすぐ形にできるレベルで学ぶのは？」って二つの質問だね。適当なアイデアでも数時間で形に。UnrealはBlueprintで”ほぼゲーム完成”ってとこまでいける。Unityはプログラミング要るけどね。
ほら、この10分の動画[0]でSuper Hexagonみたいなのが10分でプロトタイプできて、ツールの強力さが分かるでしょ。
動画にUnity特有なのはコンポーネントくらいで、他は”gamedev agnostic”（ゲーム開発全般に共通）。
俺Unreal使いだけど、Unityでも1時間くらいで同じプロトタイプ作れると思うよ。[0] https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI

「エンジンができたら」って？ 多分永遠にできないんじゃないかな？
GameObject.Instantiate(myPrefab, Vector3.zero)みたいな基本操作一つ理解するのと、それをちゃんと実装するのに必要な全部やるのとじゃ、かかる時間ケタ違いだよ。
2D/3D physics、shaders、platform supportとかになったらもっと大変。
目標がエンジン作る事なら作ればいい。ゲームを完成させる事なら、ゲームを作りなよ。

「アイデアをすぐゲームにできるレベルでUnreal/Unityを学ぶのにどれくらい？」
エンジン作れるくらいのゲーム開発知識があるなら…本気で、プロトタイプ作り始めるまでたぶん1日くらいだよ。
マスターするのはすごく時間かかるけど、ゲームを完成させるのが目標なら、かかる時間は全然違うレベルじゃない？

えーと、俺は2008年からUnity使ってるよ。他のツールとかSaaS会社よりは長く存続するって信じてるかな？たとえいくつか微妙なビジネス判断をしててもね。

少なくともplatformersに関しては、physics feelが体験全体にとってめちゃくちゃ重要で、エンジンに任せると君のゲームが”cookie-cutter”（金太郎飴みたい）な感じになっちゃう可能性高いよ。

GUI設定は結果が分かりにくくて副作用もあるから、設定いじりは生産的じゃない。
SRPやshaders置き換えも選択肢だけど、SRPには疑問も。Forward+のライトソートみたいに、少数ライトだとjob system通すのが無駄に見える。
これはスケール向け最適化で、俺のケースには合わないかもって。
SRP置き換えがC++でエンジン組むのと比べて、労力とパフォーマンスに見合うか？
エンジンに超特化したコードになるから、asset file formatsリバースよりはマシだけど、これも大変なコミットメントだよ。

ゲーム、Graphics、Physicsエンジンには重複があるから誤解があると思う。
Graphics（2D/3D, shaders, scene graphなど）、Physics、Game logic/triggers、ui、resource management、ai。
これ全部がエンジンなんだ。異なるアーキテクチャで自作するのはエンジンの仕組み学ぶには最高だけど、全ての詳細を一人でやるのは多分量が多すぎる。
Unreal Engineにどれだけ詰まってるか見たら驚くよ。

大きなエンジン使うとタダで手に入る良いものたくさんあって、自作だと面倒くさいんだよね。特にUnity storeとか。
個人開発はLibGDX好きだけど、締切大事な本格開発だとdialog trees、UIとか、そのまま使えてedge casesも洗練されてるのが超いい。
コンソールcross platformも自作はめちゃくちゃ大変で、これ結構デカい。
そういうところがSlay the Spireが続編でUnity/Godotに乗り換えた理由だと思うよ。

raw C++ memoryのスナップショットはいじるのはヤバそう（落とし穴自分で挙げてたじゃん）。
俺のスナップショットはscripting runtimeレベルでやった。そこならwell-definedで分かりやすい。
VM heap, green threads stack/pointerとか手動でスナップショット。定義済みファイルフォーマットだから壊れたsavefileでもsegfaultせず安全に検証できた。
time-travel snapshotter/savefile format両方いけた。
これは危険でremote execution attackにつながると思う（ネットワーク越し交換の話）。
physics/audioはmotion vectors/playback timeとか復元必要。君のと同じく、textures, 3D models, audio, UIは別allocatorで確保すべき。

任意の2D spritesとか、そのレベルとか、何でも1日でレンダリングできるエンジンなら君のために用意できるよ。Game Jamで君が話してるより面白くて高度なもの作ってる人たちいるし。
単に2D spritesを詰め合わせるっていう仕組み自体は、たとえエンジンをゼロから書いても大した作業じゃないんだ。そこから実際に面白くて興味深いものを作るのが時間と労力かかるんだよ。

現代のゲームエンジンはめちゃくちゃ大変なことやってくれてるから、ゼロから作るより既存エンジンの方が絶対早いって言うのは、標準的なゲームなら合ってるかもね。でも、一般的な構造から離れるほど、そうとも言えなくなるんじゃない？

Unrealはよく知らないけど、Unityはゼロから作るより断然速いよ、たぶん10倍とかそれ以上。ただUnrealのEditorはめちゃくちゃ重くて、Unityよりリソース食うのは注意ね。UnrealのBlueprintはゲームロジック書くのにすごく良いよ。C++とかC#知らなくても大丈夫だし、非同期とかイベント駆動のコードの抽象化にも便利。個人的には入門にマジでおすすめ。

技術的には問題ないんだけどね、ここ数年のライセンスの遡及変更とか、怪しい買収とか、主要なサブシステムのサポートが何年も放置されてるように見えたりとか、そういうので結構不安定な印象なんだよね。ちなみに、元Unityの社員だったよ。

友達がGodot Engineで4次元のデモを見せてくれたんだけど、めっちゃ面白かったんだ。これ見て→
https://github.com/godot-dimensions/godot-4d

なんでもできる巨大エンジン無しの方が、ゲーム作りは楽で楽しいし、オーバーヘッドも少ないって正直思うよ。そんな”なんでも”ゲーム作ってないし、エンジンの機能の9割は要らないんだもんね。←これに対して：
その意見、そういうゲームならもちろんエンジン要らないね。でも、UnrealのIKとかAnimation blendingみたいな特定機能を掘り下げてみると、”マジでゼロから自分で書かなくてよかった～”って毎回思うんだ。ミニマリズムとか無駄省きも確かにいいけど、エンジンが人気なのは、ホントに大変な部分を肩代わりしてくれるからなんだよ。

Inverse kinematicsとかAnimation blendingのことね。
それがゲームの中心機能なら、自分で書く価値はあるよ。そうじゃないなら、ただの技術的な無駄になるだけで、必要ないんじゃない？

”マジでゼロから自分で書かなくてよかった～” ←この意見に対して：
もしOPみたいにインディー開発者として何十年もやっていくのが目標なら、数週間かけて
a) そのトピックを深く理解すること、b) 自分が深く理解してて100%所有してて、将来のプロジェクトで再利用できるソースコードを持つこと、
これって、何の問題があるの？むしろ将来への投資でしょ？

エンジンを使うと、インフラ作るのに大量の時間を使わずに済むから、プロジェクト自体を先に進められるんだよね。車輪の再発明って、多くの人にとってはそんなに面白くないでしょ。

最近の3Dアニメーションでは、これはもう最低限必要なものなんだよね。アニメーションがパッと切り替わるのって結構恥ずかしいし、もっと複雑な使い方じゃなくても、Look IKくらいは絶対欲しいはずだよ。

逆にさ，ゼロから作るの楽しむ人っていっぱいいるんだよ．それってさ，めんどくさいクリエイティブな選択とか，ゲームを完成させて出すリスクを避けるためなんだよね．

＞ 3Dアニメーションならこれくらい基本でしょ
君のインディーゲームで3Dスケルタルアニメーションやるの？ どれくらいの数のスケルトンとアニメーション作るつもり？ そしてそれは主要な機能じゃないって思ってるの？

それか，インディープロジェクトにどれだけ時間があるかってことに対して，単純に非情になれてないだけじゃない？

アニメーションやるならブレンドとかIK欲しいでしょ．自分で作るとそれが主要機能になっちゃって他の機能作れなくなるよ．エンジン使えば，わざわざ自分で作らなくても簡単に使えるんだ．2.5Dプラットフォーマーでもブレンドや足IKは欲しい機能だよ．

そういう機能は「あったらいいね」くらいで，もし手間がかからないならやる価値あるって考え方もできる．例えば，エンジンがやってくれるとかね．でも現実ってそんな簡単じゃないし，ゲームの「ポリッシュ（完成度）」ってすごく重要なんだよ．

俺も15年ゲーム開発で飯食ってるよ（Noelよりは下だけど）．色々なエンジン使ったけど，自分でゼロから作ろうとした時は後悔したな．時間と労力をたくさん損したよ．俺はエンジンじゃなくてゲームを作りたいんだ．Epic GamesとかUnityとかで何千年もの人が費やした時間ってすごい量だから，たとえ全部使わなくても一部だけでもありがたいんだよ．

アニメーションブレンドやIKは主要機能なら良いシステム作るのに時間かけてもいいかもね．でもIKがない3Dゲームはいっぱいあるし，プロシージャルアニメーションなんてあったらそれがメイン機能でしょ？ エンジンにあるかどうかにかかわらず，機能にはコストがかかるんだ．たいていのゲームでは，IKのためにリグ調整しても製品は良くならないよ．

俺の卒業論文はさ，NeXTSTEP/Objective-CからWindows 95/Visual C++に，OpenGLベースで，マーチングキューブみたいなサンプル付きで，パーティクル可視化エンジンを移植することだったんだ．これってさ，今のエンジンだと機能リストのたった1つの項目なんだよね．

確かに，俺は価値判断とかデザインの好みで話してるんだ．永遠の真実じゃないよ．で，原則として，俺は最も重要な機能に労力をかけたいんだ．そうすれば，君の最高の機能はUnityで適当に寄せ集めるよりも良くなるはずさ．

アニメーションブレンドはそんなに悪くないよ．もし四元数と位置のリストとして2つのポーズがあるなら，四元数の間をslerpして，位置の間をlerpするだけでいいんだ．FABRIK IKアルゴリズムはだいたい100行くらいの関数だよ．

これってどこでも起こる話だよね。多くのB2B SaaS製品なんて、MSSQLのT-SQLスクリプト一つとかで済むのに。開発者の多くは、進捗や方向性のなさへの合理的な批判をそらすために、イデオロギーに頼ってる気がするな。UnityとかUnrealは、ちゃんとしたアイデアがあって、できるだけ早く多くの顧客に届けたいっていう熱意があるなら、絶対強力なツールだよ。

で、一度自分でやってみたなら、多分その何分の一かの時間でもっといいものが作れるんじゃない？

コンテンツを見栄え良くするために手間がかかる。インディーゲームにとってそれは重要なリソースだ
まさにこれがエンジンを使う目的だよ。ユニークじゃない機能のコーディングじゃなくて、コンテンツに時間を使えるんだ。そしたら急に多くの種類のコンテンツがずっとお手軽になる。

俺のゲームアイデアは多くの既製エンジンには合わないことが多いんだ。だから、俺が作りたいゲームのためなら、自分でゲームエンジンを書く方が、多分ずっと良い選択肢になるって確信してるよ。

俺、V-SekaiってFOSSソーシャルVRプロジェクトやってんだけど、何年もツールの開発（アセット、IK、アニメーションとか）に費やして、ゲーム自体は進んでないんだ。
予算ゼロでUnityやUnreal並みのプロレベルのツールを自分で書くのが超大変。安定したコンストレインツとかマジ難しい。V-Sekaiのdiscordで話そうぜ。俺はiFire。

同意。でもその理解に至るまでが時間かかるんだよね。あと、ソロ開発者ならどんな助けでも喜んで受けるべきだっていう似たような話題は文字通りいっぱいあるよ。オーディオとか入力、パスファインディング、AIの意思決定ツリー、物理とかも、同じように簡単だって思ってるんでしょ、多分。

自分でエンジン作るかどうか決める時、これもトレードオフだって覚えておこうぜ。俺、物理エンジン自分で手作りしたんだけど、コード全部理解できるメリットはあるけど、プロが作ったものには全然及ばないってすぐ分かった。物理開発ってマジで変なこと起こりやすいんだわ。
今のでもは動いてるし誇りだけど、まだ色々調整に時間かかりそう。
仕組みに興味あるならいいけど、『ゲーム作りたいならエンジン作るな』って言う通り、エンジン作るのには時間かかるし、全部自分で責任負うことになる。
既製エンジンのルール内でやる方が良い時もあるんだよ。

それは、寛大に言っても、俺が考えられるどの実用性にも対応しない、かなり極端でニッチな価値判断だな。現実世界には『重要な機能』のスペクトルと、それに対応する正当化される努力のスペクトルがあるんだよ。もしそれが君の芸術的誠実さのアイデアなら、勝手にやればいいけど、他の誰かにとっては多分ナンセンスだよ。

それただ間違ってるよ。こういうのってすごく標準化されてるし、大抵の人はみんなが使ってる普通のやつが欲しいだけなの。ほとんどの場合、これを自分で書くってのは、自分のSHA256を自作するみたいなもんだよ。