ゲームエンジンなしでビデオゲームを開発する方法（2025年）

 (noelberry.ca)
33 ポイント 投稿者 GN⁺ 2025-05-21 | 5件のコメント | WhatsAppで共有
  • 商用ゲームエンジン がなくても、ゲーム開発は十分に簡単かつ楽しく行える
  • 大規模エンジンの機能の大半は不要で、ツールを自作すれば 柔軟性と開発効率 が大きく向上する
  • 現代的なC#とオープンソースライブラリ を活用すれば、チーム規模に関係なく十分な開発環境を整えられる
  • FMOD、SDL3、Dear ImGui のようなライブラリと自作ツールを組み合わせることで、必要に応じたパイプラインを構築できる
  • クロスプラットフォーム開発、保守性、移植性 の面で、自前で構築した軽量フレームワークは非常に有利である

序文: 20年目のゲーム開発者の所感

  • 2025年になっても 商用ゲームエンジン なしでビデオゲームを開発している
  • 周囲からは商用エンジンを使わないことに驚かれることが多い
  • UnityやUnrealのような大規模エンジンの基本機能は、自分で実装する場合と比べて満足できないことが多く、結局かなりの部分を作り直すことになる
  • 商用エンジンを使うと、頻繁な ビジネスポリシーの変更 やアップデートによる問題にさらされる
  • 個々のプロジェクトにぴったり合った 小さなツール を自作するほうが効率的で、長期的にも保守しやすい

ゲーム開発に必要なプログラミング言語の選択

  • 長年にわたり C# を主力言語として使っている
  • 現代のC#は、過去と比べて 性能、文法、開発体験 が大きく改善されている
  • dotnet watch のようなホットリロード機能があり、リアルタイムでのコード修正やテストに非常に便利である
  • 非開発者でも扱いやすく、チーム内での 役割分担と協業効率が高い
  • 組み込みの reflection 機能により、エディタやツール制作で強みを発揮する

クロスプラットフォームライブラリとレンダリング・入力の実装

  • SDL3 を使って、ウィンドウ、レンダリング、コントローラー、クロスプラットフォーム対応など、あらゆる基本機能を実装している
  • SDL3のGPU abstractionによって、DirectX、Vulkan、Metal など多様な環境への対応が容易になった
  • SDLの上に自作した C#レイヤー（例: Foster）を共通ユーティリティとして活用している
  • FMOD を最後に残った商用オーディオツールとして使用し、それ以外はオープンソースベースのパイプラインを構築している
  • 以前はOpenGL/DirectXを直接実装した経験もあるが、SDLの安定性は大きな利点である

アセット（Assets）の処理方法

  • エンジンを自作する場合、ゲームで必要なファイルだけをシンプルに読み込めばよい
  • ピクセルアートゲームのような小規模アセットでは、初期化時にすべてのファイルを一括で読み込む
  • 大規模プロジェクトでは、必要なアセットだけを要求時にロードし、シーン切り替え時にメモリを解放する方式を採る
  • 変換が必要な場合も、コンパイル時に自動処理するスクリプトを書くだけで十分である

レベルエディタとUIツール

  • LDtk、Tiled、Trenchbroom などのオープンソースのレベルエディタとはデータ連携がしやすい
  • たいていはプロジェクトごとに カスタムエディタ を自作している
  • UI本体は自作せず、Dear ImGui のイミディエイトモードGUIを積極的に活用している
  • C#のreflectionとImGuiの組み合わせにより、ゲームオブジェクトの状態をリアルタイムに可視化できる
  • 必要に応じて、目的に合った外部ツールと自作ツールを併用する

クロスプラットフォームとコンソール移植性

  • 以前はコンソール移植の問題からC++を選ぶ必要性が高かったが、C# Native-AOT の登場で解決された
  • FNAなどのオープンソースフレームワークでも、コンソール対応の拡張が積極的に進められている
  • SDL3が提供する汎用抽象化レイヤーを活用すれば、ほとんどのシステムで同じコードベースを運用できる

開発環境: Linux中心のオープンエコシステム

  • 主力の開発プラットフォームを Linux に移行し、オープンソースツールチェーンとの相性が非常によい
  • 特定の商用ソフトウェアとのつながりは残っているが（例: vscode、github）、オープンソースエコシステムが広がるほどサポートも拡大している
  • 個人的には Steam Deck など、さまざまなLinuxベースのプラットフォームで同じ作業環境を構築している

追加Q&Aと事例

  • Godotの利用に関する質問: オープンソースエンジン中心の開発ニーズがあるなら Godot を推奨し、それ以外ではカスタムツールを好んでいる
  • 3D作業: 大規模エンジンに利点はあるが、小規模で特化したプロジェクトには カスタムフレームワーク で十分である
  • 高性能技術が必要な場合: 要求水準に応じて Unreal などの大規模エンジンを使っても問題ない
  • チーム単位でのエンジン変更: 小規模・単独開発に向いており、中～大規模スタジオでも 長期的リスク回避 を理由にカスタムエンジンへ移行する事例が増えている
  • アセットワークフロー: Aseprite ファイルは、ビルトインのタグとタイミングを活用して自動的にアニメーションへ変換できる

結論

  • 商用ゲームエンジンなしでゲームを作ることは、好みと作業スタイル によって決まる選択である
  • 必要性と楽しさを最優先に、自分に合った方法を選べばよい

関連記事

5件のコメント

 
assembler 2025-05-29

良い取り組みですね。
私は第1世代のゲーム開発者でした。
Unrealが出る前は、開発会社がエンジンを開発するのは当然のことで、
それ自体が競争力でもありました。
エンジン開発では、コア、カーネル、レンダリング、その他の入出力を
基盤として、ツール開発が大半を占めていました。
私は当時、パーティクル、サウンド、レイヤー、オブジェクトのツールを
担当していましたが、チームメンバーは7人で、ざっと集めると20個程度は
軽く超えていたように思います。

ある日からUnrealが登場して量産型のゲームが
あふれ出すようになると、もうエンジン開発には投資しなくなりました。
その頃、多くの人が独立して会社を立ち上げた気がします。
もう27年前の話ですね。

私もいつの間にか歳を取り、ゲームではない別の仕事をしています。

グラフィックカードに応じてDirectX、OpenGLのモードごとに
コア作業をしていた、あの懐かしい時代を思い出します。

がんばってください...
 
chanapple 2025-05-21

最近、戦略ゲームを作ろうとして長い間エンジンを探していたので、それならいっそ自分で一つ作ったほうがいいのではと思っていたのですが、実際にそれをやり遂げて成功した事例を見ると、勇気が湧いてきますね。
 
GN⁺ 2025-05-21
Hacker Newsの意見

  • 5年間ひとりで2Dゲームエンジンを開発し、関連する有償の仕事もしてきた中で、人々があまり気づいていない重要な点を説明したい
    エンジンは簡単な部分
    本当に重要なのは、エンジンの周辺にあるツール群、コンテンツ、アセットパイプライン
    さまざまなデータソースやフォーマットからテクスチャ、オーディオ、モデルファイル（gltf、fbx、アニメーションなど）をインポート
    エディタアプリで切り取り、コピー、貼り付け、元に戻す、やり直し、保存、削除のような基本的な編集機能
    開発者がエディタで実際のデータを作成し操作できるようにする可視化と機能（エンティティ、アニメーション、シーン、オーディオグラフ、スクリプティング支援など）
    静的ジオメトリのベイク、シェーダーコンパイル、テクスチャ・オーディオのリサンプリングとパッキング、ゲームコンテンツのアセットパック作成のようなデータのパッケージングと前処理
    これらがすべて終わると、実際にはランタイム部分（つまりゲームのメインループと下位サブシステム）はシステム全体の中では小さな部分
    だからゲームスタジオではエンジン担当は少数で、ツールを作るプログラマーが大半を占める
    detonatorエンジン: https://github.com/ensisoft/detonator

    • 汎用性よりも、自分のゲームに合ったエンジンを作ることに集中するのが重要
      UI、圧縮などはライブラリやフレームワークで解決可能
      OPがimGUIのような小規模ライブラリを使っているのも良い例
      すべてのゲーム向けのエンジンを作るわけではないので、実際にはやらなくてよい作業がかなり多くなる

    • エンジンはアセットパイプラインにぶら下がる小さなランタイムの付け足しのような存在
      今ではシェーダーコンパイラも3D APIよりますます重要になっている状況
      面白い部分はシェーダーコンパイラに集中しており、3D APIはシェーダー実行とデータ受け渡しの役割にとどまる

    • 人々はエンジンと言うと、しばしばアセットパイプラインやエディタまで含めて話す傾向がある
      今日のエンジンは、メインループ + 3D API関数だけではない
      Unityのようなエンジンを使っていても、レンダリングコードだけを書く開発者はごく少数
      もちろんUnity/Unrealを使っているからといって、独自のアセットツールをまったく使わなくて済むわけではない

    • 最近、続編用にエンジンを作り直していて、この点にとても同意する
      ポストモーテムにも書いたが、たいていエンジンというとゲーム実行ファイルに含まれるコードを思い浮かべる一方で、実際にはレベルエディタ、コンテンツパイプライン、デバッグ/プロファイリング、開発ワークフローのようにゲームと一緒に配布されないコードの比重のほうが大きいと思う
      ツール開発はエンジン開発より退屈で消耗しやすい作業
      こうした理由で、多くのカスタムエンジンによるゲーム開発が途中で止まる現象が起きる
      ポストモーテム: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • エディタを最初から作るのはかなり大きな作業
      可能なら既存のエディタを活用する
      たとえばTrenchBroom（Quakeエディタ）+ func_godotの組み合わせ、2DではTiled
      ゲームデータ管理にはCastleDBもあったが、今ではHide（本格的な3Dエディタ）と統合された状態
      ツールを作った後は、ゲーム設計とコンテンツ制作がまた主要な段階になる

  • 数年前にSDL2と少しのC++で簡単な"sprite"クラスを作り、コリジョンなどの簡単な機能を追加した
    自分が作ったものをあえてエンジンと呼ぶなら、電動自転車の補助程度のものだった
    "エンジン"がプロジェクト/ゲーム全体を主導する状況がしばしば起こるという点
    ゲームをエンジンに合わせることになる場合が多いので、Unityのような大型エンジンは常に避けている
    こうしたエンジンは結局いつも同じゲーム構造しか作れず、違うのはアセットだけ
    個人的には、エンジンを学ぶのに時間を無駄にするより、SDLなら短い学習曲線で始められ、ゲーム以外のクロスプラットフォームプロジェクトにも活用できる
    自分のゲーム: https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • エンジンを自作するのは時間がかかると言うが、UnrealやUnityをしっかり習得して、アイデアをすぐゲームとして実装できるレベルになるまでにはどれくらい時間がかかるのかという質問
    結局、自分のエンジン制作が終われば、その時点でまさにそのレベルの専門性を得ているので、長期的には時間の節約になる
    エンジニアとしての経験が積み上がるほど、自分で作るほうが時間の観点では有利になる
    ゲームが独特だったりニッチであるほど、自作のほうがより妥当
    Unrealの複雑なUIの中で何か月も迷い、そもそも自分の望むものが汎用エンジンではほとんど不可能だと知る経験は非効率
    一方で、超大規模なオープンワールドRPGなら自作は良い選択ではない
    カスタムエンジンの制約がむしろ創造性を生み、最高水準でなくても、より独創的なゲームが出てくる

    • 実際にエンジンを自作したことがある
      最初は数え切れない試行錯誤や行き止まりを経験しながら、1年ほどかかった
      3Dレンダリング、適応型UI、スケルタルアニメーション、セーブファイル、スマートオブジェクト、経路探索、スクリプティング、オーディオ、物理など、ゲームにあるほぼすべてのサブシステムを実装した
      特に巻き戻し機能（Braidのシステムのようなもの）を自分で実装した
      こうした機能にはエンジンのあらゆるサブシステム（スクリプト、物理など）の支援が必要
      自分の作ったエンジンのすべての部分を把握しているので、追加機能の開発に非常に大きな自由がある
      だが1年の開発後、徐々に燃え尽きて意欲が消えていった

    • Unrealは分からないが、Unityは直接コーディングするのと比べて10倍以上速く開発できる
      物理機能は1分で追加できるが、自作エンジンだと外部ライブラリの統合だけでも1日か2日かかる
      UnrealユーザーのNoelが見せている内部可視化機能もUnityには内蔵されている
      バウンディングボックス操作のような編集機能も標準搭載
      もしエンジンの基本動作が足りなければ、ImGuiやYogaベースのCSSエンジンで簡単に拡張可能
      高度なパーティクルエディタ、複雑さを解消したシェーダー、モジュール式データストリーミングなど数多くの機能を提供している
      理論上は全部自分で作りたいが、結局は時間の問題なので完成を優先する

    • UnrealやUnityを習得してゲームのアイデアをすぐ実装できるようになるまでの時間と、自分でエンジンを作るのにかかる時間は別の問い
      少しアイデアを与えれば、数時間以内にゲームプレイ可能なプロトタイプを作れる
      Unityは初期段階ではプログラミングだけでよく、Unrealはブループリントだけでもほぼ発売直前の段階まで行ける
      10分でSuper Hexagonスタイルのゲームプロトタイプを完成させる動画を参照: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      Unity固有の要素はプレハブ程度で、残りはゲーム開発一般の概念
      Unreal開発者の立場であっても、Unityで1時間以内に似たようなプロトタイプを作れる

    • 「エンジン完成後」という前提自体が非現実的かもしれない
      GameObject.Instantiateのような簡単な動作ですら、エンジンで直接実装するには膨大なリソースが必要
      2D/3D物理、シェーダー、プラットフォーム対応などの複雑さも考慮すべき
      エンジンが目標ならエンジンを作り、ゲームが目的ならゲームそのものを作るべきという意見

    • ゲームエンジンを作れるほどのゲーム開発知識が十分にあるなら
      UnrealやUnityを習得してプロトタイプを作るのに1日で十分
      完璧な熟練には長くかかるが、望むゲームのプロトタイプ完成までの時間は比較にならない

  • 「何でもできる」大型エンジンなしでもゲーム作りはもっと簡単で、もっと楽しく、ときにはもっと効率的
    ただしエンジンの特定機能（たとえばUnrealの逆運動学、アニメーションブレンディング）を掘り下げていくと、「自分で2〜3週間苦労しなくて本当に良かった」と思うこともある
    ミニマリズムや肥大化防止も重要だが、こうしたエンジンが重い仕事を肩代わりしてくれるから人気がある

    • 以前は自分もこういうやり方だった
      最初の3Dゲームを作るとき、入力、オブジェクト管理、カリング、モデル読み込み、数学ライブラリ、グラフィックス、法線マップ、SSAAなどを全部実装して、肝心のゲーム完成度は0%だった
      それでも趣味の2Dプロジェクトでは今でもブラウザのキャンバスだけで依存なし開発をしている
      実質的にはブラウザがエンジンの役割を果たしている

    • 「自分で作らなくてよかった」という意見に対して
      長期的にインディー開発者としてのキャリアを考えるなら、数週間かかったとしても、テーマを深く理解でき、100%ソースコードを所有でき、再利用価値も高いほうが大きい

    • 自分の卒業論文は、NeXTSTEP/Objective-CベースのパーティクルエンジンをWindows 95/Visual C++へ移植するというテーマだった（OpenGLベースで、marching cubesのサンプルを含む）
      こういうテーマも今のエンジンでは単なる1行機能の一部

    • エンジンを使えばプロジェクト進行ははるかに速くなり、インフラ開発に時間を費やさずに済む
      車輪の再発明はたいていの人にとってそれほど楽しいものではない

    • 逆運動学やアニメーションブレンディングのような機能は
      もしゲームの中核なら実装する価値があり、そうでないなら不要な技術的落とし穴

  • Lua & Love2Dを使って自分なりのやり方でゲームを作っている
    自分で制約を課すこと自体が楽しさの核心
    開発が楽しくなくなったら何かが間違っているサインなので、よりよい方法を探す
    自分のゲームYOYOZOは39KBと小さいが、Ars Technicaの2023年ベストゲーム一覧に大作と並んで載った
    https://news.ycombinator.com/item?id=38372936

    • そのゲームは覚えている
      Playdateを買ってから数年たって、ようやくSDKで遊び始めたところで、Luaも初めて学んでいる
      強い型付けや言語的な安全性が欲しい気持ちはあるが、状況に応じて十分ではある
      クランクに合わせてテキストが擬似3D空間で回転する小さな技術デモを作っただけ
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      このプロジェクトをしながら、昔のCRUD/ウェブアプリの経歴のせいで三角法をほとんど忘れていたことに気づいた
      Playdate開発の最大の利点はキャンバスが固定なので、ピクセル位置さえ決めればすべての機器でそのまま動くという解放感
      これまでの開発経歴ではレスポンシブUIばかり作ってきたので、この体験はとても新鮮

  • ゲームエンジン（Godot、Unity、Unrealなど）で何かを作ろうとすると、いつもエンジンと格闘することになる
    結局、決められたゲーム形式にアセットを載せる感覚になり、自分の作りたいゲームを作りにくくなる
    ウェブ開発でたとえるなら、WordPressのような完成品の感覚
    基本構成が意図と違うときは、膨大なハックや回避作業が必要になる

  • 著者（Noel）はCelesteというゲームを作っており、300万本以上を販売した
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • 自分もかなり同意していて、コードベースのC#ゲームフレームワークを作っている（XNA/Monogameの精神的後継で、SDLの代わりにSokolを使用）
    https://zinc.graphics/
    モダンC#の強み: クロスプラットフォーム、NativeAOTコンパイル、ネイティブホットリロード、リフレクションなど
    個人的にはソースジェネレーターも追加した
    過去のネガティブなイメージは残っているが、この5年ほどのCoreCLRと言語の進化は驚異的なレベル
    唯一欲しいのはUnion Typesで、現在提案されており来年の追加を期待している
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • こういうプロジェクト向けにC#を学び始める際の参考資料があるか気になる
      C#はWin32やUnityでしか使ったことがなく、C/C++寄りの低レベルエンジン知識はあるが、ゲーム機などのクロスプラットフォームでC#は無理だと思っていた
      自分の考えが間違っていたと今は分かった

  • どんなソフトウェアでも最初はゼロから始めるのを好む
    大規模プロジェクトの経験がある人には遅く見えるかもしれないが、スタートアップ段階ではむしろ速い
    最小限だけ実装し、抽象化が入ってくると新機能追加の速度はさらに上がる
    企業向けの大規模ソフトウェアと、自分で書いたミニエンジンの生産性はまったく違う
    自分で書いたコードはすぐに切り詰めたりリファクタリングしやすく、はるかに速い
    こういう理由でマイクロサービスと小規模チームを好む
    自分で作るときは試行錯誤や壊れた地雷原を必ず通ることになり、言語やプラットフォームの本当の特性を身につけるにも何年もかかる
    だがその過程自体が最終的には開発者の地力として残る
 
kissdesty 2025-06-10

エンジンではなく、MonoGame レベルのフレームワークを使うくらいならどうなのか気になります〜
 
lazyhack 2025-05-23

「その過程自体が、結局は開発者の地力として残る」――強く同意します