ハクソク

世界を動かす技術を、日本語で。

2025年にエンジンなしでゲームを作る

2025年5月20日原文(noelberry.ca)

概要

  • 20年にわたりゲーム開発を続けてきた筆者の経験と哲学を紹介
  • UnityやUnrealなどの大手ゲームエンジンを使わず独自ツールを活用する理由を解説
  • C#を中心としたプログラミング言語選定やSDL3・FMODなどのライブラリ活用法を説明
  • アセット管理・レベルエディタ・UIツールの自作と既存ツールの使い分けを提案
  • クロスプラットフォーム開発やLinux移行の実体験を共有

20年続くインディーゲーム開発と独自ワークフロー

エンジンを使わない理由と哲学

  • Unity や Unreal などの大規模ゲームエンジンを使わず、 独自ツール で開発する理由を重視すること
  • 大手エンジンの 90%の機能が不要 であり、独自のゲーム性や操作感を実現するために自作システムを構築すること
  • 商用エンジンの ビジネス的リスク （方針転換やアップデートによる破壊的変更）を避けるため、ツールコントロールを重視すること
  • 問題発生時に 自力で解決 できる安心感と、将来の 保守性 確保を優先すること
  • 小規模チームや個人開発においては、 必要最小限のツール自作 が効率的であることを提案

ゲーム開発におけるプログラミング言語選定

  • C# をメインに使用し、かつては C++ も経験したが、C#の進化と利便性を評価すること
  • 2025年のC#は パフォーマンス と 記述性 が大幅に向上し、 ホットリロード 機能も開発効率化に貢献すること
  • 小規模チーム での学習コストの低さや、 リフレクション によるエディタツール開発のしやすさを重視すること
  • C#のアクセシビリティ が、初心者でも急速に戦力化できる点を強調すること

システムレイヤーとライブラリ選定

  • SDL3 をクロスプラットフォームな ウィンドウ管理・入力・レンダリング の抽象化レイヤーとして活用すること
  • SDL3の GPU抽象化 により、DirectX・Vulkan・Metalなど主要APIに対応し、幅広いプラットフォームで動作すること
  • SDL3の上に 独自C#ラッパー を実装し、プロジェクト間で再利用すること
  • オーディオには FMOD を採用し、ダイナミックな音声制御が必要な場合は商用ツールも適宜利用すること
  • 必要に応じて MoonWorks 等の代替ライブラリも検討すること

アセット管理とロード戦略

  • アセットは 必要なときに必要な分だけ ロードする、シンプルな実装を推奨すること
  • 小規模なピクセルアートゲームでは 全アセット一括ロード も現実的であること
  • 大規模アセットの場合は オンデマンドロード・アンロード を実装し、メモリ効率を最適化すること
  • 必要に応じて プリプロセス用スクリプト を自作し、ビルド時にアセット変換を自動化すること

レベルエディタとUIツールの設計

  • LDtk、 Tiled、 Trenchbroom などの既存レベルエディタを活用しつつ、必要に応じて 独自エディタ も開発すること
  • ゲームデータとエディタの 密結合 を重視し、特定用途に特化したシンプルなツールを自作すること
  • UI実装には Dear ImGui を利用し、 即時モードGUI による軽量なエディタツールを高速開発すること
  • C#リフレクション と組み合わせて、ゲームオブジェクトを自動でインスペクト・編集できる環境を構築すること
  • 複雑なツールが必要な場合のみ、外部ツール（例：Trenchbroom）を併用すること

クロスプラットフォーム対応とポーティング

  • かつては C#のJIT制約 のためC++への移植やBRUTE等のツールを利用していたが、 Native-AOT の登場でC#でも全主要コンソールに対応可能となったこと
  • FNAプロジェクト の積極的な貢献により、C#ゲームのマルチプラットフォーム展開が容易になったこと
  • SDL3 のプラットフォーム抽象化を活用し、幅広い環境で「そのまま動く」設計を推奨すること

開発環境の変遷とLinux移行

  • 開発環境は Windows から Linux へ完全移行し、オープンソース・クロスプラットフォームツールの活用を推進すること
  • Windowsの ビジネスモデルや操作性 への不満からLinuxへの移行を決断したこと
  • 一部Microsoft製品（VSCode、C#、GitHub等）は継続利用しつつ、 Linuxユーザー増加によるオープンソース対応拡大 を期待すること
  • 日常的なゲームプレイも Steam Deck などLinuxベースの環境で完結していること

このように、 大手ゲームエンジンに依存しない開発手法 は、独自性・保守性・柔軟性を重視するインディー開発者にとって、現代でも十分に現実的かつ魅力的な選択肢であると提案します。

Hackerたちの意見

ゲームを「何でもできる」エンジンなしで作る方が、実際には簡単で楽しいし、オーバーヘッドも少ないと思ってる。俺は「何でもできる」ゲームを作ってるわけじゃないし、これらのエンジンが提供する機能の90%も必要ない。そうなると、エンジンなんていらないよね。とはいえ、エンジンの特定の機能に本気で深く掘り下げた時、例えばUnrealの逆運動学やアニメーションブレンディングなんかで、「ああ、数週間かけてゼロからコーディングしなくてよかった」と思ったことがある。ミニマリズムやアンチブロートの主張もあるけど、エンジンが人気なのは、実際にかなりの作業を手伝ってくれるからだよ。

└

アニメーションブレンディングはそんなに悪くないよ。もし二つのポーズがクォータニオンと位置のリストで表現されてるなら、クォータニオンの間をスラーップして、位置の間をレープすればいいだけ。FABRIK IKアルゴリズムは、約100行の関数だよ。

└

昔の俺もこんな感じだった。初めての3Dゲームを作ってた時、入力、オブジェクト管理、カリング、モデル読み込み、数学ライブラリ、グラフィックス、ノーマルマッピング、SSAA...を実装するのに数週間かけたけど、ゲームの進捗は0%だった。でも、趣味の2Dプロジェクトでは、依存なしでウェブキャンバスで自分でやってる。ブラウザをエンジンと呼んでもいいけどね。

└

エンジンを使うことで、インフラを構築するために大きな時間をかけるのではなく、プロジェクト自体の進捗を進められるんだ。車輪を再発明するのは、ほとんどの人にとって楽しくないよね。

└

私の卒業論文は、NeXTSTEP/Objective-CからWindows 95/Visual C++へのパーティクル可視化エンジンのポーティングで、OpenGLをベースにしていて、マーチングキューブのようなサンプルがあった。これは現代のエンジンの機能リストの一つの箇条書きに過ぎない。

└

「ああ、ゼロからそれをコーディングしようと何週間も費やさなくてよかった」と思うよね。もしあなたの目標が独立した開発者として数十年のキャリアを築くこと（OPのように）なら、a) トピックを深く理解するための数週間の投資や、b) 深く理解し、100%所有し、将来のプロジェクトで再利用できるソースコードを持つことは、何の問題もないと思うよ。

└

逆運動学とアニメーションブレンディング これがゲームの中心的な機能なら、書く価値があるよね。逆に、技術的な無駄遣いなら、必要ないってことだ。

多くの人が、エンジンをゼロから作るのに時間がかかりすぎると言うけど、UnrealやUnityをしっかり学ぶのにどれくらい時間がかかると思う？アイデアを持って、それをゲームにするのに摩擦がないレベルまで。おそらく、エンジンが完成したら、そのレベルの専門知識にすぐに達するから、時間の節約になる。俺の意見では、エンジニアとしての経験が増えれば増えるほど、自分で作る方が時間の観点から有利になる。ゲームがユニークでニッチであればあるほど、これはより真実だよ。UnrealのひどいUIを3ヶ月も彷徨って、やりたいことがエンジンの一般的でオフ-the-shelfな性質のせいでほとんど不可能だと気づくのは、いい経験じゃない。一方で、ハイパーリアルなオープンワールドRPGを作りたいなら、自分で作るのはあまり良いアイデアじゃないと思う。たとえそれが常に最も効率的な方法ではなくても、カスタムメイドの専門エンジンを使うことで自分に制限を設けると、創造性が本当に流れ出て、ゲームが最も進んでいなくても、その結果としてもっとユニークになると思う。

└

2Dゲームを作った経験があるところからスタートして、Unrealでアセットを作るためのチュートリアルやドキュメントをいくつか日間かけて進めた結果、ゲームを作るのにボトルネックになったのはアセット制作だった。Godotでは、数時間でひどいゲームを作れるところまで行った。現代のゲームエンジンがあなたのためにやってくれる作業量は驚異的で、ゼロからエンジンを書くよりも既存のエンジンでゲームを実装する方が早いと主張する人は、自分を騙してると思う。

└

Unrealには詳しくないけど、Unityはゼロからプログラミングするよりもずっと早いよ、簡単に10倍以上。明らかな例は物理挙動で、これをゲームに追加するのに1分もかからないけど、自分のエンジンだと外部ライブラリを適切に統合するのに1日か2日かかる。Noelがここで見せている内部状態の可視化は、Unityではデフォルトで既に組み込まれてる。バウンディングボックスを描いたり修正したりするための良いツールがあって、エンジンの挙動が足りない稀なケースでも、高度に拡張可能（ImGuiやUnityのYogaベースのCSSエンジンを使うのが好き）。Unityには、洗練されたパーティクルエディタ、高度な「一度書けばどこでも実行」できるシェーダー言語、モジュラーデータをストリーミングして追跡するためのシステムなど、数えきれないほどの機能がある。理想的な世界では、こういうものを自分で書きたいけど、時間はどんどん過ぎていくし、残念ながらゲームを早く完成させることを優先したい。

└

ゲーム、グラフィックス、物理エンジンの間には大きな重複があるため、誤解が生じていると思う。グラフィックスは2Dや3Dのレンダリング、シェーダー、シーングラフ、アニメーションなど何でも含まれる。物理や関連するものはシーングラフと相互作用する。ゲーム部分は動的な挙動を可能にし、もちろんゲームロジックやトリガーも含まれる。UIやリソース管理を追加して、最後にもちろんAIも。異なるアーキテクチャを持つ自分のエンジンを作ることは、エンジンがどうやって機能するかを学ぶ最良の方法だが、それに伴うすべての詳細は本当に多くて、一人には多すぎるかもしれない。Unreal Engineの中にどれだけのものが詰まっているか、驚くかもしれないよ。

└

多くの人がエンジンをゼロから作るのは時間がかかりすぎると言うけど、UnrealやUnityをちゃんと学んで、アイデアをゲームにするのにどれくらい時間がかかると思う？たぶん、エンジンが完成したら、すぐにそのレベルの専門知識に達するから、すごく時間の節約になるよ。私の意見では、エンジニアとしての経験が多ければ多いほど、自分のエンジンを作る方が時間の面で有利になると思う。私は一度、自分のゲームエンジンを作る実験をしたことがあるんだけど、約1年かけて作りながら学んだ（試行錯誤で、最初は多くの行き止まりがあったけど）。それには、ゲームに典型的に見られる多くの機能が含まれていた（すべての機能が揃った3Dレンダリング、flexboxに触発された適応型UIフレームワーク、スケルタルアニメーション、セーブファイルフォーマット、スマートオブジェクトシステム、パスファインディング、スクリプト言語、音声、物理などなど）。特に、Braidのシステムを再現しようとしたんだけど（存在を知らずに）、ゲームを任意の時点に巻き戻すことができるんだ。これにはエンジンのすべてのサブシステムのサポートが必要だった - スクリプトや物理を巻き戻すためにね。自分のゲームエンジンの細かい部分をすべて知っていることは確かにプラスだった。エンジンがほぼ完成した後は、どんなに野心的な機能でも追加するのにせいぜい数時間で済んだ。何かがうまくいかなかったときは、何が起こっているのか正確にわかった。でも、1年の構築の後、ちょっと疲れてしまって、続けるモチベーションが消えちゃった :)

Hacker Newsで議論の続きを見る