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


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


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

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

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

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

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



しかし、問題が・・・

大量の処理時間

→　処理落ち　との戦い




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

●できるだけ処理しない

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

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









→ その考え方を応用




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

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

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


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




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

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




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

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


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

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


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


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



ケース１．　草木が多い場所 　　（草木のアニメが重い）

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

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



ケース２．　兵士が多い場合

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

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

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



ケース３．　画面中がエフェクトだらけ

→　必殺技中 などで起きる

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



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




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

●マルチコア

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

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

→　マルチコアに対応



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


ゲーム制御・ＵＩ　　　　　　　　　　５％
ゲームアルゴリズム　　　　　　１０％
キャラクター制御　　　　　　　　２０％
キャラモデル・モーション　　　２０％
その他（マップ、エフェクト）　　１５％
ドローコール　　　　　　　　　　　３０％

（制御する兵士は ２５０人）


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




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

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

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




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

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

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





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

●マルチコアへ対応

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

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

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



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

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

処理細分化


同期をとる事は大事

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

（下の図の例で言うと　座標計算は　Ａの処理内で済ませておく
そうすると、Ｂ，Ｃ 内で 他の兵士の座標を取得できる）



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










・結果

ゲーム制御・ＵＩ　　　　　　　　　　５％
ゲームアルゴリズム　　　　　　１０％
キャラクター制御　　　　　　　　　２％
キャラモデル・モーション　　　　３％
その他（マップ、エフェクト）　　１５％
ドローコール　　　　　　　　　　　６５％


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

６～７割を ドローコールへ回すことができるように

６０ｆｐｓが 楽勝で出せるように


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




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

●今後の課題

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

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

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