Component basedgameenginedesign

Component based
game engine design
@DADA246

自己紹介
• ゲームプログラマやってます
• 低レベルから GPU,web,DB まで幅広く書いて
ます
• Steam,Origin,iPad で海外ゲームを遊んでいま
す
• Starcraft2 hots 楽しいですね

はじめに
• 今回の話は 1999 ～ 2003 年付近で議論さ
れていたものです
• 特に新しい話ではありません
• ゲームごとに最適な設計は異なるので、
今回の話が正しい設計ということではあ
りません

stackoverflow
• http://
stackoverflow.com/questions/1901251/componen
「コンポーネント主体のゲームプログラム
について情報を教えてほしい」
→ コンポーネント関係のリンク集になって
いる

Entity
• プレイヤーや敵などを表現する
• Game Object とも呼ばれる
class Entity
{
public:
void Update(float time);
void Render();
}

継承
• 継承で Entity を構築した場合

継承問題
• 継承はハードコーディングなので、変化に
弱い
• FPS にて、ゲームデザイナーから
「弾を操作したい」と言われたら？
例： Unreal Tournament
Redeemer
→ 撃った弾を操作出来る

継承の追加
• 弾を操作したいため、弾クラスを継承し
て「操作可能な弾クラス」を作る
→Player クラスと似たクラスが出来てしまう
→ 継承をコーディング
しなければならない
→ コンパイルも必要

継承問題
• ゲーム開発には試行錯誤が必要
→ 開発が終盤になるほど継承関係を変更す
る手間が増える
• Entity の種類が増えると基底クラスの機能
が肥大化する

has-a
• 継承を避ける
→is-a ではなく、 has-a にする

コンポーネント
• コンポーネントを基底クラスとする

Entity
• Entity はユニークな ID とコンポーネント
のリストを持つ
→ ユニークな ID はコンポーネント管理クラ
スからコンポーネントを参照するときに
使う
class Entity
{
private:
int32_t id;
std::list<component*> componentList;
}

Entity の構築
• コンパイル時ではなく、実行時に Entity の
種類が決まる
auto pPlayer = new Entity();
pPlayer->RegisterComponent(new Human());
pPlayer->RegisterComponent(new Player());

Data Driven
• Entity の構築はコードに書かなくても良い
<Entity>
<Name>Player</Name>
<Component>Human</Component>
<Component>Player</Component>
</Entity>
{
“Name”:”Player”,
“Component”:[“Human”,”Player”]
}

ゲームエディタ
• ゲームエディタの入力から Entity を構築す
る
→ ゲームデザイナが Entity を構築できる
→ コンポーネントの組み合わせで多様な
Entity を生成出来る

コンポーネントの種類
• 更新処理や描画処理もコンポーネントと
して抽象化出来る

コンポーネントの例
• Input( コントローラー入力 )
• Updatable
• Renderable
• Physics
• Collision
• Motion
• Actor
• Audio
• Network
• AI
• Health( 体力 )
…

コンポーネントの組み合わせ
• 賑やかしのための NPC
→Collision を外して軽量化する
• 壁
→Updatable を外して軽量化する
• 音の発生地点
→Renderable を外して描画させない

LOD
• コンポーネントを動的に付け外しすると
、処理負荷を下げられる
例：カメラから遠い NPC はアニメーション
しない
pNPC->RegisterComponent(COMPONENT_MOTION );
pNPC->UnRegisterComponent(COMPONENT_MOTION );

更新頻度の変更
• 数フレームごとに実行される Updatable を
作ると、処理負荷を下げられる
例：ドアは 15 フレームに一度しか更新しな
い
auto pDoor = new Entity();
pDoor ->RegisterComponent(new DefferedUpdatable() );

更新処理
• 継承ベースの設計でよく見かける処理
→ 全 Entity の Update を呼ぶ

更新処理
• Entity を処理するのではなく、登録されて
いるコンポーネントを処理する
→ 全 Entity を検索する必要がなくなる

Messaging
• Update 処理を抽象化してしまったら、何
を呼べば良い？
→ コンポーネントに対してメッセージを投
げる
→ 処理負荷は掛かるが、ポインタよりも疎
結合に出来る
class Component
{
private:
Entity* pOwnerEntity;
public:
virtual void HandleMessage(const Message& message);
}

Messaging
• メッセージに対する処理を書いていく
void PlayerComponent::HandleMessage(const Message& message)
{
switch(message.GetType() )
{
defalut:
break;
case CREATED:
// コンポーネント生成時の処理
break;
case JUMP:
// ジャンプ時の処理
break;
case GAME_OVER:
// ゲームオーバー時の処理
break;
}
}

Messaging
• メッセージはコンポーネント間のやりと
りにも使える
void PlayerComponent::HandleMessage(const Message& message)
{
…
//Entity のユニーク ID を指定してメッセージを発行
PostMessage(enemyEntityId,new Message(DAMAGE) );
// 全 Entity にメッセージを発行
BroadcastMessage(new Message(SAVE) );
…
}

実装例
• コンポーネントはあくまでも設計論なの
で、様々な実装例がある

実装例
• Entity にコンポーネントのリストを持たせ
るパターン
→ 純粋なコンポーネント実装
class Entity
{
public:
void RegisterComponent(Component* pComponent);
void GetComponent(std::list<Component*> pComponentList);
}

実装例
• 処理速度を上げるために、 Update と
Render はコンポーネントにしないパター
ン
→ コンポーネント化は設計論の一つなので
、ゲームごとに最適解は異なるclass Entity
{
public:
void Update(float time);
void Render();
void RegisterComponent(Component* pComponent);
void GetComponent(std::list<Component*> pComponentList);
}

実装例
• コンポーネントを継承させていくパター
ン
→ コントローラー入力の代わりに自動テス
ト用ダミー入力を使うなど

実装例
• コンポーネントは C++ で書かれていなくて
も良い
→Entity の一部をゲームデザイナーが書く

懸念点
• メッセージを多用すると、ポインタアクセス
に比べて処理速度が落ちる
→ 入力処理など、処理速度が遅くても良い箇所
に限定してメッセージを使用する
• データドリブンの場合、コンパイラを通せな
いので、エラーが見つかりにくい
→ デバッグ機能を強化する
• Generic なプログラムを求められる

まとめ
• Entity を継承ではなく、 has-a にしてコン
ポーネント化する設計もある
• ゲームタイトルごとにデザイン、対象プ
ラットフォーム、開発規模が違うので、
コンポーネント化が常に正しいとは限ら
ない
設計手法の一つとして考慮するのも面白い
と思います

参考文献
• A Data Driven Game Object System(GDC 2002)
• Theory and Practice of Game Object Component Architecture
(GDC Canada 2009)
• Game Engine Architecture
• Game Programming Gems 4: A System for Managing Game
Entities
• Game Programming Gems 5: Component Based Object
Management
• Game Programming Gems 5: A Generic Component Library
• Game Programming Gems 6: Game Object Component System
• MSDN XNA Programming Guide “Application Model Overview”

ご清聴ありがとうございました

Component basedgameenginedesign

Recommended

More Related Content

What's hot (20)

Similar to Component basedgameenginedesign (20)

Component basedgameenginedesign