忍者ブログ
ゲームを作ったり、ゲームを遊びまくったりしている せっき~の生き様。   まずは目次をご覧ください
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

2010年9月1日 にあった、CEDECの講演についての記事です。

コーエーの作品における、大量のキャラクターを同時に表示・制御する手法
「シングルスレッドからマルチスレッドへ」



コーエーで、無双シリーズで リードプログラマをされた方の講演です。
(キャラクター制御を多く担当)


-------------------------------------------------------------

●なぜ 大量のキャラを表示・制御が必要?

とにかく 出せるだけ出そう と言うスタンス
(何千人ものキャラを表示・制御)

→ 合戦シーンを リアルタイムに、インタラクティブに (歴史SLG)
→→ ゲームの世界を成り立たせるため

→ 一騎当千 を実現するために  (無双シリーズ)
→→ ゲームをより面白くするため



しかし、問題が・・・

大量の処理時間

→ 処理落ち との戦い




-------------------------------------------------------------

●できるだけ処理しない

・処理するものを限定する

→ カメラによる クリッピング、LOD に似ている
(LOD ・・・ Level of Detail  遠くにあるモデルは、どうせ良く見えないので ポリゴン数を減らし 描画負荷を軽減する方法)
LOD








→ その考え方を応用




・カメラクリッピングの応用

視野外の兵士達 ・・・ 大ざっぱに動かす
              → 何人かまとめて、集団で動かす

視野内の兵士達 ・・・ 単独で動かす


→ 兵士達は 基本的にグループに属すようにする
 普段はグループとして動き 必要があるときのみ、単独で動けるようにする




これを利用する事で、ゲームに出てくる兵士は 何千人いるとしても
基本はグループのみで扱う事で、最小限の処理に留める事ができる

→ 大きな処理軽減に繋がった




-------------------------------------------------------------

●処理が落ちている状況を把握


・その状況に応じて、効果ある対応を模索

例: エフェクトが出すぎ、草木アニメが多い場所、兵士が多すぎる場所


全てに対して、問題が無くなるように削っていってしまった場合
ほとんど何も出すことができなくなり、面白味のないゲームになってしまう


→ 問題が発生してから、その都度対応するのは キリが無い
→ 事前に、判断材料を用意する。
 そして、対応策のパターンを作る



ケース1. 草木が多い場所   
(草木のアニメが重い)

→ マップデータから、そう言う所がどこか? 判断できる

→ 草木のLOWモデルを用意して、ここでは それを描画する



ケース2. 兵士が多い場合

→ ゲームの進行状況 で判断できる

→ 多くの兵士がぶつかり合うような場所には、重いオブジェクトを置かない
 (大軍と大軍がぶつかるような場所では、単なる広い平坦 にしてしまう)

 たくさん兵士がいる場合は、LODの判断基準を動的に変えれるように
 少しでも遠くにいる兵士は、LOWモデルにしてしまう



ケース3. 画面中がエフェクトだらけ

→ 必殺技中 などで起きる

→ エフェクトが かなり派手に出ているので
 奥にいる兵士は、どうせ見えないので 表示しない



このように、問題が起こる場所に その都度 ベストな対策を施す事で
普段の ”たくさん出す”を阻害することなく 処理軽減を図る事ができます




-------------------------------------------------------------

●マルチコア

これだけ工夫してきたのですが、ハード性能の向上の結果 モデルのスペック増加

→ 上記の工夫だけでは、どうしようもありませんでした。

→ マルチコアに対応



・シングルスレッド時の パフォーマンス


ゲーム制御・UI          5%
ゲームアルゴリズム      10%
キャラクター制御        20%
キャラモデル・モーション   20%
その他(マップ、エフェクト)  15%
ドローコール           30%

(制御する兵士は 250人)


→ 全体的に 均一に処理負荷が分散していた




・無双シリーズ 特有の問題


既に(シングルスレッドとして)完成している物を マルチスレッドへ移行しないといけない

→ 一から作るよりも とても大変




・依存関係のある直列なプログラムを 並列化しないといけない

難易度 低 モーション制御、描画処理
難易度 高 当たり判定、キャラクター制御

つまり、前の兵士の変更された内容を参照するような処理(異動後の座標とか)
は、依存関係ができているため 並列化が大変





-------------------------------------------------------------

●マルチコアへ対応

・お互いの依存関係を切る

初めから 念頭に置かれて設計されていたなら 問題無い

→ 過去からのソースなので、安全に手を入れるのが大変



・マルチスレッド化するための プログラム手法

変数退避型処理へ (1フレーム前をバッファに退避、その数字を参照するように)

処理細分化


同期をとる事は大事

→ 兵士Aの座標を取得したくても、兵士Aの座標計算が終わっていないかも知れない
 そんな問題が起こらないように 必ず同期は取る事

(下の図の例で言うと 座標計算は Aの処理内で済ませておく
そうすると、B,C 内で 他の兵士の座標を取得できる)



・最終的に ↓のような形になりました。

マルチスレッド








・結果

ゲーム制御・UI          5%
ゲームアルゴリズム      10%
キャラクター制御         2%
キャラモデル・モーション    3%

その他(マップ、エフェクト)  15%
ドローコール           65%


並列処理した キャラクター制御、 モデル・モーション の負荷が激減

6~7割を ドローコールへ回すことができるように

60fpsが 楽勝で出せるように


→ 半年かけて、並列化したが その苦労が報われた




-------------------------------------------------------------

●今後の課題

大規模なプログラムの マルチスレッド化は 必須

オフロード環境の構築と、設計思想の浸透が大事

プログラマのみでなく、プランナーも 並列化を考慮したゲームの設計に臨むのが好ましい
 

拍手[0回]

PR
この記事にコメントする
お名前
タイトル
文字色
メールアドレス
URL
コメント
パスワード   Vodafone絵文字 i-mode絵文字 Ezweb絵文字
この記事へのトラックバック
この記事にトラックバックする:
プロフィール
HN:
せっき~
性別:
男性
職業:
ゲームプログラマ
自己紹介:
古いパソゲー、ボードゲーム、カードゲームを熱狂的に遊んでいます。


ついったー
http://twitter.com/seki_seki_seki

連絡先は
sekisekiseki(あっと)gmail.com
最新コメント
[05/25 http://gzytn.net]
[05/25 carpet cleaning in chelsea]
[05/24 Madge]
[05/24 Madge]
[05/24 ブランド激安市場_ルイヴィトンコピー品 掲示板(bbs)]
カウンター
ついったー

Copyright © [ せっき~のゲーム屋さん ] All rights reserved.
Special Template : 忍者ブログ de テンプレート and ブログアクセスアップ
Special Thanks : 忍者ブログ
Commercial message : [PR]