Olimi

はじめに#

このセクションの内容は、学堂オンラインの MOOC「3D ゲームエンジンアーキテクチャ設計基礎」から取られています。個人的には、テキストと画像のバージョンに変換しました（個人的にはテキストバージョンのチュートリアルの方が好きで、読む速度がはるかに速いです）。参照用に便利です。
元のコースのリンク：3D ゲームエンジンアーキテクチャ設計基礎。
この記事は、ワード文書全体から変換され、ドキュメント全体を読むこともできます（変換されたウェブ専用コラムを読むと、より快適に感じるかもしれません）。リンクは最後に置いてあります。

マップ#

コースのマインドマップ：

大きな画像の表示リンク：高解像度版
したがって、このセクションはマップのインデックスに基づいて、7 つの章に分けられます。

インデックス#

• 概要
• [シーン管理]((https://olimiya.github.io/posts/3D ゲームエンジン入門コース 2 - シーン管理)
• [リソース管理]((https://olimiya.github.io/posts/3D ゲームエンジン入門コース 3 - リソース管理)
• [シーンレンダリング]((https://olimiya.github.io/posts/3D ゲームエンジン入門コース 4 - シーンレンダリング)
• [キャラクターアニメーション]((https://olimiya.github.io/posts/3D ゲームエンジン入門コース 5 - キャラクターアニメーション)
• [イベント処理とスクリプト言語]((https://olimiya.github.io/posts/3D ゲームエンジン入門コース 6 - イベント処理とスクリプト言語)
• [メモリ管理]((https://olimiya.github.io/posts/3D ゲームエンジン入門コース 7 - メモリ管理とプラグインメカニズム)

概要#

ゲームエンジンの概要#

定義：ゲーム開発の中で、コアの基本機能を独立して抽象化し、ゲーム開発者が呼び出すことができるようにしたコンポーネントをゲームエンジンと呼びます。ゲームエンジンを使用してゲームを開発すると、ゲームの開発効率と品質が向上します。初期のゲーム開発では、デザイナーたちはゲームデザインの共通コンポーネントを段階的に抽出し、これらの機能を抽象化およびモジュール化してゲームエンジンを形成しました。ゲーム開発の成熟とともに、ゲームエンジンの機能はますます強力になっています。

オープンソースのゲームエンジンには、Unreal Engine 4、OGRE、Panda3D などがあり、人気のある商用ゲームエンジンには Unity などがあります。以下では、主に OGRE と Panda3D を例に説明します。

ゲームエンジンのフレームワークの概要#

ゲームエンジンの要件分析、つまりゲームエンジンに含まれるべき機能。

環境要件には以下が含まれます：

• ターゲットハードウェア

• デバイスドライバ

• オペレーティングシステム

• サードパーティのソフトウェアパッケージとミドルウェア

• エンジンをサポートするプラットフォーム固有のレイヤー

機能要件には以下が含まれます：

• エンジンのコアモジュール

• エンジンのリソース管理

• エンジンのシーン管理とグラフィックスレンダリング

• キャラクターアニメーション

• サウンド

• 物理学と衝突検出

• 人工知能

• グラフィカルユーザーインターフェース GUI

• スクリプト処理など

ゲームエンジンの設計原則には、機能の完全性（多数）、高い実行効率（速い）、安定したパフォーマンス（良い）、および良好な拡張性が含まれます。

ゲームエンジンのアーキテクチャ設計では、以下の内容を一定の方法で組み合わせる必要があります：

• 基本プラットフォームのサポートコンポーネント

• サードパーティの基本ライブラリ：データ演算、グラフィックス処理、データ構造など

• エンジンの機能（上記の機能要件に記載されているもの）

ゲームエンジンの階層的な組織構造：

ゲーム機能#

ゲーム機能の分類：

ゲームエンジンのデザインパターン#

生成パターン：

• シングルトンパターン：システム内には 1 つのインスタンスしか存在せず、通常は常に存在します。

• 抽象ファクトリパターン：関連する複数のファクトリクラスのインターフェースを提供し、抽象クラスであり、具体的なクラスを指定する必要はありません。

• ファクトリパターン：関連するオブジェクトのインターフェースを提供し、具体的なクラスであり、インスタンス化できます。

構造パターン：

• アダプターパターン：クラスのインターフェースを別のクラスのインターフェースに変換します。互換性のないインターフェースを持つクラスを一緒に使用できるようにします。このパターンを使用すると、サードパーティの基本ライブラリに統一されたインターフェースを定義できます。

振る舞いパターン：

• イテレータパターン：集約オブジェクト内の各要素を順番にアクセスしますが、そのオブジェクトの内部表現を知る必要はありません。

• オブザーバーパターン：複数のオブザーバーオブジェクトが同時に特定の主体を監視し、主体オブジェクトが変更されると、すべてのオブザーバーに通知し、応答します。

• ビジターパターン：いくつかの操作をカプセル化し、特定のデータ構造要素に適用します。カプセル化された操作を変更すると、適用されるデータ構造には影響を与えません。たとえば、レンダリングアルゴリズムをビジターパターンのクラスにカプセル化すると、メソッドとデータが分離され、データ構造の要素に変更があっても、アルゴリズムのみを変更すれば済みます。

ドキュメントリンク#

[金山ドキュメント] 3D ゲームエンジン基礎.doc