もんしょの巣穴blog

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

mapやsetを大量に使うのはありなのか?

ここ最近遊んだデモと言えば、PS3の『KILLZONE2』とXbox360の『Halo Wars』。
KZ2はコンシューマFPSとしては最高峰のグラフィックで、特にモーションはずば抜けていると言っていいでしょう。
GoW1みたいに色が薄い、と言うかモノクロ調なので派手さは感じませんが、さすがに待たせただけあるものにはなってます。
ただ、もっとカバーオブジェクトとか破壊できるものと思ってたんですが、全然破壊できず。
体験版だからなのか、そういうステージなのかはわかりませんが、ちょっとがっかり。
あと、操作性が悪すぎる。半分はPS3パッドの所為とは言え、半分は間違いなくゲームの所為。
カバーアクションとかもただしゃがんでるだけとしか感じられない。ボタン押しっぱなしなのも個人的に×。
リアリティを追求した結果かも知れませんが、私は遊びやすいゲームの方が好きです。
対照的に遊びやすかったのがHWの方。まさか、コンシューマRTSがこんなに遊びやすくなるとは思ってませんでした。
確かに所々「マウスとキーボードの方が」と思う部分はありますが、ほぼ不満がない出来映えです。
ゲーム自体もうまい具合に簡略化されていて、Halo世界の表現としても秀逸。
Haloは好きだけどRTSはちょっと…という人でも体験してみるといいと思います。
問題は、初心者には難しすぎて、上級者には簡単すぎるかもしれないと言うこと。
RTS初心者をうまく取り込めればいいですが、そうでなければ上級者に底が浅いと言われる可能性も否定できません。
しかし、体験版としては成功したのではないかと思います。

今日は思うところがあってGameProgrammingGemsの1章を中心に読んでいたんですが、Gems5の1.3 コンポーネントベースのオブジェクト管理がちょっと面白かったので簡単に紹介。
ゲーム中のオブジェクトを管理する伝統的な方法としては、たとえばCObjectみたいな基底クラスを用意し、すべてのオブジェクトはそこから派生させる、と言うものだと思います。
つまり、シーンはCObject*をvectorとかで管理するわけです。
問題は、あるオブジェクトに今までなかった機能を追加しようとする場合に発生します。
記事にも書いてありますが、たとえばアニメーションしないはずのオブジェクトがアニメーションすることになったとすると、そのオブジェクトは継承ツリーの別の場所に移動させる必要が出てきます。
また、その機能がそもそも存在しない場合、どこかのクラスにその機能を追加させ、そのクラスから派生しているすべてのオブジェクトにその機能の実装を求める必要が出てきます。
これは結構面倒ですし、ゲーム開発末期にそんな話が出てきたりするとかなり危険です。
そこで、機能ごとにコンポーネントを作成し、オブジェクトとコンポーネントを動的に関連づけることで継承による問題をなくしてしまおうというもの。
オブジェクト、コンポーネント、インターフェースの関係は以下のような1つのデータベースで管理されます。

struct SObjectManagerDB
{
    SComponentTypeInfo     mComponentTypeInfo[NUM_COMPONENT_TYPE_IDS];
    std::set<EComponentTypeId>   mInterfaceTypeToComponentTypes[NUM_INTERFACE_IDS];
 
    std::map<CObjectId, IComponent*> mComponentTypeToComponentMap[NUM_COMPONENT_TYPE_IDS];
 
    std::set<EComponentTypeId>   mMessageTypeToComponentTypes[NUM_MESSAGE_TYPES];
};

オブジェクトとコンポーネントの関係は mComponentTypeToComponentMap で管理されます。
たとえば、キャラクタの体力を示すHPコンポーネントを考えます。
EnemyオブジェクトはPlayerオブジェクトのHPをチェックし、その行動を変化させるものと考えてください。
まず、Enemyオブジェクトは mComponentTypeToComponentMap からHPコンポーネントのIDに対応するmapを取得します。mComponentTypeToComponentMap[ CID_HP ] って感じで。
その中からPlayerオブジェクトIDに対応するコンポーネントインターフェースを取得します。
NULL以外が返ってくればコンポーネントは見つかったので、そこからHPの値を取得することができます。
また、メッセージディスパッチは mMessageTypeToComponentTypes から指定メッセージを受け取るべきコンポーネントIDのsetを取得し、やっぱり mComponentTypeToComponentMap からmapを受け取ります。
特定のオブジェクトならそのmapからコンポーネントを取得し、不特定の相手ならそのmapすべてのコンポーネントにメッセージを送るというわけです。
オブジェクトはコンポーネントという形の能力を持っていて、その能力に従ってメッセージを受けたり処理を行ったりすると言うわけです。
しかし、個人的に気になったのはsetやmapをかなり使っていると言うこと。
コンポーネントの数が増えれば mComponentTypeToComponentMap の数が増えます。
メッセージが増えれば mMessageTypeToComponentTypes の数が増えます。
どちらも10個くらい、とかならともかく、どんどん大きくなってきたらメモリ管理が大変そうだと思ったり思わなかったり。
っていうか、そもそもゲーム本体の中でsetやmapってそんなに使うかなぁ?
もちろん、ピンポイントで使用するならそれほど問題ないですが、この技術のように配列で大量に使用するっていうのはいまいち納得できないというか…。
技術的には面白いだけに、別の解決策は模索できないのかなぁと思ったりするわけで。
皆さんはどう思います?

スポンサーサイト
  1. 2009/02/11(水) 23:41:06|
  2. プログラミング
  3. | トラックバック:0
  4. | コメント:0
<<OpenGL ES 2.0 その02 | ホーム | OpenGL ES 2.0 その01>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://monsho.blog63.fc2.com/tb.php/96-0a025cde
この記事にトラックバックする(FC2ブログユーザー)

プロフィール

monsho

Author:monsho
ゲームプログラマ?

最近の記事

最近のコメント

最近のトラックバック

月別アーカイブ

カテゴリー

ブロとも申請フォーム

この人とブロともになる

ブログ内検索

RSSフィード

リンク

このブログをリンクに追加する

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。