「自作ゲームエンジンあれこれ」ゲームのエンジンとは ver0.0.1

0x00 ゲームのエンジンとは

私たちは、ゲームエンジンがゲーム開発を支える存在であることを知っています。では、ここで一つシンプルな問いを立ててみましょう──「ゲームエンジンとは何か？」。

もちろん、Godot、Unity、Unreal Engine は、一般的に“ゲームエンジン”として広く認められています。では、Godot、Unity、Unreal より raylib や SDL はどうでしょうか？

ここで私の答えを述べるなら、前者 は 標準的なゲームエンジン に分類されます。一方で 後者 は、厳密にはゲームエンジンというより、ゲーム開発用のライブラリ（あるいはフレームワーク） と捉えるのが適切だと思います。なぜそう言えるのでしょうか。

なぜこのような違いが生まれるのでしょうか？まずは、raylib／SDL とは何者？

• SDL（Simple DirectMedia Layer）
  基本は マルチメディア/プラットフォーム抽象化ライブラリ（ウィンドウ、入力、音、タイマー等）。典型的には「ゲームループは自分で書く」前提。

• raylib（レイリブ）
  SDLより上のレイヤーで、描画・入力・音・簡易3Dなどを“すぐ使える形”で提供する ゲーム開発用ライブラリ/フレームワーク寄り。

どちらも「ゲームを作るのに十分便利」なので、記事によっては雑に“エンジン”と言われます。理由も単純で、初心者向け記事だと「これでゲームが作れる＝エンジン」みたいに言葉を簡略化しがちだからです。

0x01 何を満たすと「エンジン」と呼びやすいか（実務的な線引き）

一般に「エンジン」と呼ばれやすいのは、少なくとも次が揃っているときです。

• 実行の骨格（Main Loop）と時間管理を“枠”として提供
• Scene/ECS など、ゲーム側の構造を規定する仕組みがある
• Asset 管理、デバッグ、開発ツール（エディタ等）まで含むことが多い

逆に SDL は「土台の部品」 で、エンジンというより エンジンが依存するライブラリ という立ち位置が自然です。
raylib は“ミニエンジン”と呼ぶ人がいるのは分かる、という感じ（ただしエディタや資産パイプラインまで含む“統合環境”ではない）。

raylib や SDL は、描画（Rendering）、入力（Input）、音（Audio）、ウィンドウ生成など、ゲーム制作に必要な“部品”をとても手軽に提供してくれます。ですが一方で、エンジンの骨格になりやすい領域――たとえば次のようなものは、基本的に「開発者が自分で設計して実装する」前提です。

• 時間管理（Time Management／タイム・マネジメント）
  タイマーAPIはあるが、ゲーム全体の時間設計（固定更新・補間・再現性を含む枠組み）は提供しない
  （ここはゲーム体験や再現性に直結する重要ポイントなので、詳しくは別記事にまとめます）
• Scene / ECS（シーン／ECS）などのゲーム構造
  「更新順」「依存関係」「シーン遷移」「コンポーネントの組み合わせ」みたいな、ゲーム全体の“設計図”を決める仕組み。
• 完全な資源管理（Asset Management）
  重複ロード防止、参照の。一元化、ライフタイム（寿命）管理、キャッシュ、ホットリロード（Hot Reload）など。

だからこちらでは、raylib/SDLを 「ゲーム開発用ライブラリ／フレームワーク」 と呼びます。
それらは“土台として非常に優秀”ですが、ゲームの実行基盤として統合された枠組み（＝エンジンの中核） は自動では付いてこない。
なお、近年は raylib-extras のような拡張コンポーネント群や、raygui のレイアウト/スタイル編集ツール、プロジェクト雛形生成ツールなど、“制作を支える周辺ツール”が増え、エコシステム全体としては標準エンジンに近い方向へ広がりつつあります。

0x02 何が“ゲーム側”の責務なのか

前の説明でゲームエンジンの定義を整理したことで、同時に「エンジンがどこまで責任を持つか」という責務の境界もはっきりしました。
では最後に、その上に乗るゲーム側（Game Logic） が何を担当するのか――つまり “ゲーム固有の処理の範囲” を確認します。

結論から言えば、ゲームロジックが担当するのは 「この作品は何が面白いのか」「どんなルールで進むのか」を決める部分 です。

たとえばゲーム側（Game Logic）は、以下を扱います。

• ルール／進行：勝利条件、スコア、HP、ゲーム内イベントの進行、状態遷移
• 振る舞い／判断：敵AIの意思決定、行動パターン、難易度調整
• 内容／構成：ステージ構成、敵配置、アイテム効果、報酬設計
• 作品固有の遊び（Game Design）：そのゲームならではの体験や手触り

ここがゲームの“個性”そのものであり、エンジンはそれらを実行するための土台（描画・入力・時間管理・リソース管理など）を安定して提供する裏方です。

0x03 主要ゲーム会社 × 代表的な採用エンジン（抜粋）

大手各社のゲームエンジンの使用状況を、ざっくり整理してみました。以下は「各社が近年の主力タイトルで使っていると公表・広く確認できる代表エンジン」を中心にまとめたものです（実際には会社内で複数エンジン併用が普通です。特に子会社・スタジオ単位で違います）。

会社（例）	代表エンジン	区分	補足
Electronic Arts (EA)	Frostbite	自研	EA傘下で広く利用 (Wikipedia)
Ubisoft	Snowdrop /（他にAnvil等）	自研	Ubisoftの主要内製エンジンの一つ (Ubisoft)
Capcom	RE ENGINE	自研	カプコンの基盤技術として言及 (Capcom)
Rockstar Games	RAGE	自研	Rockstarのプロプライエタリ・エンジン (Wikipedia)
Bethesda Game Studios	Creation Engine（2含む）	自研	Skyrim/Fallout/Starfield等 (Wikipedia)
Valve	Source 2	自研	Valve Developer Communityで明記 (Valve Developer Community)
Blizzard Entertainment	（Overwatch等）自社エンジン	自研	GDC Vaultで「proprietary engine」明記 (GDC Vault)
Riot Games	（LoL等）社内エンジン	自研	Riot公式Tech Blogで「League’s Engine」扱い (Riot Games Tech Blog)
Remedy	Northlight	自研	Remedy公式 (Remedy Games)
IO Interactive	Glacier	自研	Hitman系のin-house engine (Wikipedia)
Paradox Development Studio	Clausewitz	自研	自社エンジンとして説明 (Wikipedia)
SEGA（Sonic Team等）	Hedgehog Engine	自研	SEGA公式インタビューで言及 (株式会社セガ)
Supercell	内製エンジン/ツール	自研	公式ブログで明言 (Supercell)
BANDAI NAMCO	Unreal Engine	通用（商用）	Epicの事例紹介 (Unreal Engine)
CD PROJEKT RED	Unreal Engine 5	通用（商用）	UE5採用を公式発表 (CD PROJEKT)
miHoYo/HoYoverse	Unity	通用（商用）	作品ページでEngineがUnity (Wikipedia)
Epic Games	Unreal Engine	通用（商用）	（エンジン提供側）
Amazon Games周辺	O3DE（Lumberyard後継）	開源（オープンソース）	AWSが後継をO3DEと明記 (AWS Documentation)
Konami	近年の大型作でUE5採用例	混在/移行中	例：MGS ΔがUE5 (GamesRadar+)
Square Enix	Luminous + UE/Unity併用	混在/移行中	Luminousは社内エンジン (Wikipedia)

割合（自研／開源／通用）

注意：これは上の「抜粋サンプル（20社）」を1社=1票で集計した“目安”です（売上規模やタイトル数で加重していません／複数エンジン併用も単純化しています）。

• 混在/移行中（2社）を除外（n=18）

  • 自研：72.2%（13/18）
  • 通用（Unity/Unreal等）：22.2%（4/18）
  • 開源（オープンソース）：5.6%（1/18）

• 混在/移行中も別枠で含める（n=20）

  • 自研：65%
  • 通用：20%
  • 開源：5%
  • 混在/移行中：10%

上のデータから分かるように、実際には大手各社の多くが自社エンジン（または自社で管理・運用するエンジン基盤）を持っています。これは単に技術力を誇示するためではなく、各社がそれぞれ固有の開発要件や“その会社らしいゲーム体験”を抱えているからです。商用エンジンだけでは要求を十分に満たせない場合、企業は自社エンジンの開発・採用へと舵を切ります。

また、ゲームには多種多様なジャンルがあり、エンジンにも得意分野と弱点が存在します。したがって、現場で「これ一つだけで全てを賄う」という形になりにくく、複数の選択肢を使い分けるのが自然です。たとえ汎用エンジンを採用している会社であっても、内部では高度なカスタマイズが行われることが多く、場合によっては“名前は同じでも中身は別物に近い”状態になっていることすらあります。