1 歴史と沿革
ゲームエンジンの発展は、コンピュータゲームの歴史と密接に関連している。初期のゲーム開発では、各タイトルごとにゼロからコードが書かれていたが、技術の進歩とともに共通機能の再利用が志向されるようになった。
1.1 黎明期（1990年代以前）
1980年代以前のゲーム開発は、ハードウェアに密接に依存した個別制作が中心であった。しかし、ゲームの複雑性が増すにつれ、共通の基盤技術を抽出する動きが生まれた。
1.1.1 ゲームエンジンの概念の誕生
「ゲームエンジン」という用語が定着する以前から、開発者はコードの再利用を試みていた。1980年代後半、アドベンチャーゲーム開発では「スカム」ツール（例：SierraのAdventure Game Interpreter）が使用され、同一エンジンで複数タイトルが制作された。また、日本のロールプレイングゲーム（RPG）分野でも、任天堂の「RPGツクール」シリーズなど、汎用的なゲーム制作ツールが登場した。
1.1.2 id TechシリーズとDoomエンジン
1993年にリリースされたid Softwareの『Doom』は、ゲームエンジン史における画期的な転機となった。同社はレンダリング、衝突検出、ネットワーク機能を分離したモジュール設計を採用し、このエンジン（のちに「id Tech 1」と呼ばれる）を他社にライセンス供与するビジネスモデルを確立した。1996年の『Quake』では、本格的な3Dレンダリングパイプラインを搭載し、「QuakeC」スクリプト言語によるカスタマイズ性を提供。これにより、ゲームエンジンが独立した製品として認識される基盤が築かれた。
1.2 商用エンジンの台頭（2000年代）
2000年代に入ると、ゲームエンジンの商用ライセンス市場が急速に拡大し、開発者は自社開発の負担を軽減できるようになった。
1.2.1 Unreal EngineとUnityの登場
1998年にEpic GamesがリリースしたUnreal Engineは、高いグラフィックス品質と統合開発環境を提供し、『Unreal Tournament』シリーズで実績を示した。一方、2005年に登場したUnityは、軽量なエディタとマルチプラットフォーム対応を強みに、特に独立系開発者（インディー）の支持を集めた。両エンジンは、ブループリント（UE4）やアセットストアなど、開発効率を高める独自のエコシステムを構築していく。
1.2.2 コンソール専用エンジンからの脱却
2000年代以前、多くのゲームは特定のハードウェア向けに内製エンジンで開発されていた。しかし、マルチプラットフォーム展開の需要増加に伴い、商用エンジンがコンソール間の移植性を提供するようになる。例として、CryEngine（2004年）は『Far Cry』でPC向けの高品質レンダリングを実証し、後にPlayStation 3やXbox 360にも対応した。
1.3 現代のエコシステム（2010年代以降）
2010年代以降、ゲームエンジンは開発ツールとして成熟し、オープンソース化やクラウド技術との統合が進んだ。
1.3.1 オープンソースエンジンの拡大
2014年に公開されたGodot Engineは、MITライセンスのもとで完全なソースコードを公開し、コミュニティ主導の開発を実現。同エンジンは、軽量なインストーラと独自のスクリプト言語GDScriptを備え、教育用途や小規模プロジェクトで広く利用されている。また、CryEngineやUnreal Engineも部分的なオープンソース戦略を導入し、開発者コミュニティの拡大を図った。
1.3.2 クロスプラットフォームとクラウドゲーミング
UnityとUnreal Engineは、PC、コンソール、モバイル、Web（WebGL）に加え、クラウドゲーミングプラットフォーム（例：Google Stadia、NVIDIA GeForce Now）向けのビルドを標準サポート。エンジン側でプラットフォーム間の差異を抽象化することで、開発者は単一のコードベースから複数環境へデプロイ可能となった。また、クラウドでのレンダリング負荷軽減技術として、NVIDIAのCloudXRなどの統合も進んでいる。
2 主要な機能モジュール
ゲームエンジンは、ゲーム開発に必要な中核機能をモジュールとして提供する。これらのモジュールは独立して動作し、開発者は必要なものを選択・統合できる。
2.1 グラフィックスレンダリング
グラフィックスモジュールは、3Dまたは2Dのビジュアルを生成する。現代のエンジンは、DirectX 12、Vulkan、Metalなどの低レベルAPIを抽象化し、GPUの効率的な活用を実現する。
2.1.1 レンダリングパイプライン
レンダリングパイプラインは、3Dシーンデータを2D画像に変換する一連の処理手順を指す。エンジンは通常、複数のパイプラインバリアントを提供する。
2.1.1.1 フォワードレンダリングとディファードレンダリング
フォワードレンダリングは、各ライトに対してオブジェクトを描画する古典的手法で、透明度やアンチエイリアシングとの親和性が高い。一方、ディファードレンダリングは幾何情報を中間バッファに格納し、後段でライティング処理を行う。多くの動的光源を扱えるが、透明度処理が複雑になる。Unreal Engineはディファードを、Unityは両方をサポートする。
2.1.2 シェーダーとマテリアルシステム
シェーダーはGPUで実行される小さなプログラムで、頂点変換やピクセル色の計算を行う。エンジンは、ノードベースのマテリアルエディタ（例：Unreal Engineのマテリアルエディタ、Unityのシェーダーグラフ）を備え、プログラミング知識なしでも視覚的にシェーダーを編集可能。また、HLSL/GLSLのテキストベース記述もサポートし、高度なカスタマイズを可能にする。
2.2 物理エンジン
物理モジュールは、現実世界の力学をシミュレートする。多くのエンジンは、NVIDIA PhysXやBulletなどのサードパーティライブラリを統合する。
2.2.1 剛体・ソフトボディ物理
剛体物理は、変形しない物体の運動（衝突、重力、摩擦）を計算する。ソフトボディ物理は布、髪、ゼリー状の物体など、変形するオブジェクトを扱う。例えば、Unityのクロスシミュレーションや、Unreal EngineのChaos Physicsが該当する。
2.2.2 衝突検出と応答
衝突検出は、オブジェクト同士の接触を判定する。単純な境界ボックス（AABB）から凸包（Convex Hull）まで、形状に応じた検出アルゴリズムを選択可能。衝突応答では、運動量保存則に基づく反発や、オブジェクトの並進・回転を計算する。エンジンは通常、コリジョンレイヤーやイベントコールバックを提供し、ゲームロジックとの連携を容易にする。
2.3 オーディオ
オーディオモジュールは、効果音、BGM、環境音の再生を管理する。
2.3.1 3D空間オーディオ
3D空間オーディオは、音源の位置に基づいて音量、位相、減衰を動的に調整する。エンジンは、ドップラー効果、指向性音源、リバーブゾーン（例：洞窟、部屋）をモデル化し、没入感を高める。Unreal Engineは「Audio Link」、Unityは「FMOD」や「Wwise」などのミドルウェア統合が一般的。
2.3.2 音声ミキシングとエフェクト
複数の音声を同時に再生するためのミキシング機能。エンジンは、マスターボリューム、サウンドグループ、エフェクトチェーン（リバーブ、コンプレッサー、EQ）を提供する。例えば、Godot Engineはオーディオバスシステムを内蔵し、ビジュアルなミキサーエディタを持つ。
2.4 スクリプティングとロジック
ゲームの振る舞いを定義するためのスクリプトシステム。
2.4.1 ビジュアルスクリプティング vs テキストベース
ビジュアルスクリプティングは、ノードとコネクターでロジックを構築する方法で、プログラミング未経験者にも扱いやすい。Unreal Engineのブループリントが代表例。テキストベースのスクリプトは、C++（Unreal）、C#（Unity）、GDScript（Godot）など、高いパフォーマンスと柔軟性を提供する。両者は併用可能で、プロトタイプから本番コードまで段階的に移行できる。
2.4.2 イベントシステムとコンポーネント指向
エンジンは、オブジェクト間の通信をイベント（例：衝突時、ダメージ時）で管理する。コンポーネント指向アーキテクチャ（ECS）は、ゲームオブジェクトに機能（移動、攻撃、描画）をモジュールとして追加する方式。UnityのGameObject/Componentが典型的で、Godotはノードベースで類似の構造を持つ。
2.5 アセット管理とパイプライン
プロジェクトで使用するリソース（モデル、テクスチャ、音声）を効率的に管理する。
2.5.1 インポート・エクスポート形式
エンジンは、FBX、OBJ、glTF（3Dモデル）、PNG、JPEG、HDR（テクスチャ）、WAV、MP3（音声）など、業界標準のファイル形式をサポート。インポート時に、圧縮、ミップマップ生成、フォーマット変換（例：DXT、ASTC）を自動実行する。
2.5.2 依存関係とバージョン管理
アセット間の参照（マテリアルがテクスチャを参照、プレハブがモデルを参照）を追跡し、変更時に自動再インポートを実行。また、Unityの「Addressables」やUnrealの「Data Assets」を活用したアセットバンドルシステムにより、ランタイムの動的ロードを可能にする。バージョン管理との統合（例えば、Gitでバイナリファイルの差分を検出するプラグイン）も重要である。
3 代表的なゲームエンジン
ゲームエンジンは、商用・オープンソース・専用のカテゴリに分類され、それぞれ異なるコミュニティと機能を持つ。
3.1 商用エンジン
商用エンジンは、ライセンス料やロイヤリティを課す代わりに、包括的なサポートと高品質なツールを提供する。
3.1.1 Unreal Engine
Epic Gamesが開発するUnreal Engineは、AAAタイトル向けの高機能エンジンとして知られる。最新バージョン（UE5）では「Nanite」仮想化ジオメトリと「Lumen」動的グローバルイルミネーションを実装し、映画品質のグラフィックスをリアルタイムで実現。
3.1.1.1 ブループリントとC++開発
ブループリントはノードベースのビジュアルスクリプトで、プロトタイピングやアーティスト・デザイナーによる開発を促進。一方、C++コードはパフォーマンスが求められる部分で使用され、ブループリントと相互呼び出しが可能。両者を組み合わせたハイブリッド開発が一般的。
3.1.1.2 大規模オープンワールド向け機能
UE5は「ワールドパーティション」機能により、巨大なマップをセルに分割し、動的ロードを自動化。また、レベル・オブ・ディテール（LOD）制御やストリーミングレベルを内蔵し、『フォートナイト』のような広大なゲーム世界を効率的に構築できる。
3.1.2 Unity
Unity TechnologiesのUnityは、モバイル、2Dゲーム、XR向けに最適化されたエンジン。2023年時点で、モバイルゲームの約70%がUnityで開発されているという統計もある。
3.1.2.1 コンポーネントシステムとC#スクリプト
すべてのゲームオブジェクトはコンポーネント（Transform、Rigidbody、カスタムスクリプト）で構成される。C#スクリプトはMonoBehaviourクラスを継承し、Start()、Update()などのライフサイクルメソッドに処理を記述する。ECS（Entity Component System）もオプション提供され、データ指向設計による高速化が可能。
3.1.2.2 モバイル・2D向け最適化
Unityは、モバイルデバイス向けの軽量レンダリング（Universal Render Pipeline、URP）と、高品質向け（High Definition Render Pipeline、HDRP）を選択可能。2Dゲームにはスプライトシェイプ、タイルマップ、アニメーションシステムを標準装備。アセットバンドルとAddressablesによる動的リソース管理もモバイルメモリ制限に対応する。
3.2 オープンソースエンジン
ソースコードが公開され、誰でも無償で利用・改変可能なエンジン。
3.2.1 Godot Engine
Godot Engineは、MITライセンスの完全オープンソースエンジン。軽量（約50MBのインストーラ）で、3Dと2Dの両方をサポート。コミュニティ主導で開発が進められ、教育や小規模スタジオでの採用が増加。
3.2.1.1 独自スクリプト言語GDScript
GDScriptはPythonに似た構文を持ち、学習コストが低い。ノードのシグナルシステム（イベント駆動）と密接に連携。また、C#（Mono統合）やビジュアルスクリプトも使用可能で、柔軟性が高い。
3.2.1.2 ノードベースのシーンシステム
Godotでは、すべてのオブジェクトが「ノード」で構成される。ノードはツリー構造で配置され、親子間でプロパティやシグナルを継承・伝播する。「シーン」はノードツリーのテンプレートで、再利用可能なゲームオブジェクトとして機能。この設計により、直感的なオブジェクト構成が可能。
3.2.2 CryEngineとLumberyard
CryEngineは、2004年のデビュー当時、『Far Cry』で高品質レンダリングを実証。その後、Amazonがライセンスを受け「Lumberyard」として発展させ、AWSクラウドサービスとの統合を強化した。しかし、ライセンス条件の複雑さやコミュニティ規模の小ささから、採用は限定的。現在、Lumberyardは「Open 3D Engine（O3DE）」としてApache 2.0ライセンスで公開されている。
3.2.3 その他（Panda3D、Ogreなど）
Panda3Dは、カーネギーメロン大学とDisneyが開発したエンジンで、Pythonスクリプトをネイティブサポート。教育・研究用途で利用される。Ogre（Object-Oriented Graphics Rendering Engine）は、レンダリングに特化した軽量ライブラリであり、多くの商用・非商用プロジェクトの基盤として使われてきた。C++向けのSDKとして、カスタムエンジン開発の出発点としても人気。
3.3 専用エンジン
特定のゲームスタジオやジャンル向けに開発されたエンジン。
3.3.1 内製エンジン（例：Frostbite、RE Engine）
Frostbite Engine（Electronic Arts）は、『バトルフィールド』シリーズ向けに開発され、破壊可能な環境と大規模マルチプレイヤーに最適化。一方、CapcomのRE Engineは、『バイオハザード7』以降のタイトルで使用され、ホラーゲームの演出に特化したライティングとアニメーションシステムを持つ。内製エンジンは他社へのライセンスは稀だが、自社タイトル間で技術を共有する利点がある。
3.3.2 レトロエンジン（例：RPG Maker、GameMaker）
RPG Makerシリーズは、日本のロールプレイングゲーム制作に特化したエンジンで、タイルマップ、イベントコマンド、データベース（アイテム、スキル）を直感的に設定可能。GameMaker（YoYo Games）は、2Dゲームに特化し、独自のGML（GameMaker Language）スクリプトとドラッグ＆ドロップ操作を提供。初期の『Undertale』や『Hotline Miami』など、インディー作品で実績がある。
4 開発フローとツールチェーン
ゲームエンジンは、開発プロセス全体を効率化するための統合ツールチェーンを提供する。
4.1 エディタインターフェース
エディタは、ビジュアル編集・管理の中心となる環境。
4.1.1 シーンビューとヒエラルキー
シーンビューは、ゲームオブジェクトの位置、回転、スケールを3D/2D空間で直接操作可能。ヒエラルキーパネルはオブジェクトの親子関係をツリー表示し、選択やグループ化を容易にする。Unreal Engineは「ワールドアウトライナー」、Unityは「ヒエラルキー」、Godotは「シーンドック」として機能を提供。
4.1.2 エディタ拡張とカスタムツール
エンジンは、エディタ機能を拡張するためのAPIを公開。Unityは「エディタスクリプト」（C#でツールを作成）、Unreal Engineは「エディタユーティリティウィジェット」（ブループリントでカスタムUIを作成）をサポート。GodotはGDScriptやC#でプラグインを作成可能。これにより、プロジェクト固有のパイプライン（例：ボーンリターゲット、文字列置換）を自動化できる。
4.2 ビルドとデプロイ
開発したゲームを実行可能なファイルに変換する工程。
4.2.1 プラットフォーム設定と最適化
エンジンは、ターゲットプラットフォームごとに設定（解像度、テクスチャ品質、シェーダーアーキテクチャ）を管理。例えば、モバイル向けにはETC2/ASTC圧縮、PC向けにはBC7圧縮を自動選択。また、スクリプトのAOT（Ahead-of-Time）コンパイルや、不要アセットの削除（コードストリッピング）を実行し、実行ファイルサイズを最小化する。
4.2.2 パッケージングと配信
ビルド後、エンジンはプラットフォームごとのパッケージ形式（APK/iOSアプリケーションバンドル、.exeインストーラ、Steamビルド）を生成。Unreal Engineは「プロジェクトランチャー」、Unityは「ビルド設定」から一括操作可能。クラウド配信向けには、WebGLビルドや、Steamの「Steamworks SDK」との統合も提供。
4.3 パフォーマンスプロファイリング
ゲームの動作を分析し、ボトルネックを特定するツール。
4.3.1 CPU/GPUプロファイラ
エンジンは、フレームごとの処理時間を計測するプロファイラを内蔵。Unreal Engineの「Unreal Insights」、Unityの「Profiler」は、CPUスレッド、GPUレンダリングパス、スクリプト実行時間を可視化。Godotはデバッガ内蔵で、関数呼び出しのスタックトレースを表示する。
4.3.2 メモリ管理とGC制御
ゲームエンジンは、オブジェクトのライフサイクルを管理するメモリアロケータを持つ。UnityはC#のガベージコレクション（GC）に依存するため、頻繁なアロケーションがパフォーマンス低下を招く。対策として、オブジェクトプーリング、構造体（struct）の活用、手動メモリ管理が推奨される。Unreal EngineはC++の手動管理が主体だが、ブループリントで生成されるオブジェクトの廃棄（DestroyActor）は自動化されている。
4.4 バージョン管理とコラボレーション
複数人での開発を円滑にするためのシステム。
4.4.1 Gitとプラグイン
業界標準のGitに対して、エンジンは大規模バイナリファイルの管理用プラグインを提供。Unityは「Git LFS」（Large File Storage）との統合、Unreal Engineは「Perforce」を推奨するが、Gitプラグイン（例：GitHub Desktopとの連携）も利用可能。Godotは.vs文件（非推奨）としてテキストベースのシーン保存が可能で、Gitとの親和性が高い。
4.4.2 アセットパイプラインの自動化
CI（Continuous Integration）ツールと連携し、アセットのバリデーション（例：欠落テクスチャの検出）、自動ビルド、テスト実行をパイプライン化。Unityは「Unity Cloud Build」、Unreal Engineは「BuildGraph」で自動化を構成。Godotはコマンドラインでのヘッドレスビルドをサポートし、JenkinsやGitLab CIとの組み合わせが可能。
5 応用分野と将来動向
ゲームエンジンは、ゲーム以外の領域にも拡大し、技術的な進化を遂げている。
5.1 ゲーム以外の用途
5.1.1 建築ビジュアライゼーション
Unreal EngineやUnityは、リアルタイムレンダリングを活用した建築ウォークスルーに使用される。BIM（Building Information Modeling）データのインポート、物理ベースのライティング、昼夜サイクルをシミュレート。日本でも、ゼネコンや設計事務所が内覧用VRデモの制作に利用している。
5.1.2 映画・アニメのプリビズ
プリビジュアライゼーションは、映画の撮影前にシーンをCGで事前視覚化する工程。Unreal Engineは「バーチャルプロダクション」として、LEDウォール撮影とリアルタイム合成を可能にする技術を提供。『マンダロリアン』などの作品で採用され、映画制作ワークフローを変革した。
5.1.3 シミュレーションとトレーニング
軍事、航空、医療分野では、ゲームエンジンを使用したトレーニングシミュレータが開発されている。例えば、Unityを使用した手術シミュレータや、Unreal Engineを使用したドローン操縦訓練システムが存在。物理エンジンとインタラクティブ性を活かし、低コストで実践的な訓練が可能。
5.2 技術的トレンド
5.2.1 リアルタイムレイトレーシング
NVIDIA RTXシリーズの登場により、ゲームエンジンはハードウェアレイトレーシングを標準サポート。Unreal Engine 5の「Lumen」は、ソフトウェアベースの間接照明も含めてリアルタイムGIを実現。Unityの「HDRP」もレイトレーシングエフェクト（反射、シャドウ、アンビエントオクルージョン）を提供。ただし、パフォーマンス負荷が高いため、高品質とリアルタイム性のトレードオフが課題。
5.2.2 機械学習の統合
機械学習モデルをゲームエンジンに組み込む動きが加速。例としては、テクスチャの超解像（NVIDIA DLSS、AMD FSR）、アニメーションのブレンド予測、NPCの行動学習（強化学習）が挙げられる。Unityは「ML-Agents」ツールキットを提供し、エージェント学習を容易に実装可能。
5.2.3 WebGPUとブラウザベースエンジン
WebGPUは、Webブラウザ上でGPUを直接利用する次世代グラフィックスAPI。UnityとUnreal EngineはWebGPU出力を試験的にサポートし、ブラウザで高品質な3Dゲームを動作させることが可能に。Godot 4.0もWebプラットフォームへの出力を改善し、今後、クラウドゲーミングに依存しないWebネイティブゲームの普及が期待される。
5.3 コミュニティと教育
5.3.1 オンライン学習リソース
各エンジンは、公式チュートリアル、ドキュメント、認定資格を提供。Unreal Engineは「Unreal Online Learning」、Unityは「Unity Learn」プラットフォームを運営。YouTube上にも多数の無料講座が存在し、初心者から上級者まで段階的に学習可能。
5.3.2 ゲームジャムとオープンソース貢献
ゲームジャム（短期集中開発イベント）は、エンジンの普及に大きく貢献。Global Game JamやLudum Dareでは、UnityやGodotの使用率が高い。また、Godotのようなオープンソースエンジンは、コミュニティメンバーによるバグ報告、機能提案、プルリクエストが活発に行われ、ユーザー参加型の開発が継続している。