2012年8月21日 にあった、ＣＥＤＥＣの講演についての記事です。


『GRAVITY DAZE/重力的眩暈：上層への帰還において、彼女の内宇宙に生じた摂動』
携帯型エンタテインメントシステムゲーム機 PlayStationVitaにおけるオープンワールドゲームの作り方






講演内容を 大きく２つに分けて まとめました。
主に　データの管理の手法 についてです。

（スクリプトについてはこちら  http://sekigames.gg-blog.com/Entry/244/ ）


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

●まず オープンワールドの定義

ジャンル？
街を自由に移動できる？
ステージに境目が無い？
ロード時間に切れ目がない？

→　いろいろな物がシームレスに繋がっている　と言う事



●『GRAVITY DAZE』のオープンワールド性について



・ゲームの世界が立体的な構造を持つ

　水平方向に　±１ｋｍ
　上下方向に　±７ｋｍ　　

の広さを持たせている。
（普通のゲームの場合　水平方向にのみ 世界が広がっているけれども）



・全方位アクション

重力方向を変える空間移動

主人公は壁に立てる。
→　全方向に落ちて大丈夫なよう、コリジョンを設定



・大量のオブジェクトを配置

→　できるだけ壊せるようにした。



●オープンワールドのデータの持ち方について

ゲーム世界は、連続性のあるデータで構成されている必要がある。

→　原点が１つだけ
　　プレイヤーの座標系も１つだけ


地形の連続性に従って、データを連続的に バックグラウンドで読み替えるように実装しないといけない。



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

●オープンワールドを作るのは 難しい？

できるのだろうか？

→　やった事がない
　（ボリューム的に）　作りきれるのだろうか？
　（通常の開発では）　ステージを分けるなどして、分割統治をしてトラブル解決するのだけれども　それと全く逆のやり方だ　



めんどくさそう、扱いにくそう

→　特殊対応や、その場のごまかし　が向いていない
　　全体として一定の水準を保たせた、厳しい品質管理が必要
　　全体ボリュームの見積がやりにくい


オープンワールドのゲーム作成は、チームにとって 大変なチャレンジだった。



●オープンワールドにして　（結果的に）良かったこと

・世界は一つだけ　と言う事

　概念として 理解しやすい
　一貫性に優れる
　見た目の統一感
　無駄な重複がない　　（一つの町に、同じ形の建物を置きたくない　とか）
　効率を重視するようになった


など、オープンワールドは 意外と良かった



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

●広大な街を表現するデータ構造と読み込み戦略


・メモリに入りきらない

→　プレイヤーに移動に合わせて、エリア毎にデータを読み替えていく
→　ＡＡＢＢでエリア分割した。
　　（Axis Aligned Bounding Box　軸に並行な直方体)



・遠くまで見える

→　ＬＯＤが必要　　（Level of Detail)
→　ワールドをツリー構造にして管理した。

　

・プレイヤーが高速で空を飛んで移動する

→　エリアを通り抜けた時や、読み込み遅延が起きた時に問題となるので
　対応が必要



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

●データ構造について

・ツリー構造にした

こんな感じ

エリア一つは　大体８０m
一つの街は、１２～３２個のエリアで構成されている　との事




・アルゴリズム

（図は　灰色はダミーモデル　、青は 詳細モデル　を示しています）

プレイヤーがエリア外に居る時、ダミーモデルを読み込む
→　読み込みが完了次第、ダミーモデルを表示



プレイヤーが接近したら 詳細モデルを読み込む
→　ここで、子エリアのダミーモデルも読み込み始める



プレイヤーがエリア内に入ると、詳細モデルを表示する
→　子エリアのダミーモデルを表示
　　近くにある子エリアの詳細モデルを読み込み


→　と、次々必要な詳細モデルを読み込み 出していく

（ダミーモデルは、詳細モデルを読み込み次第　捨てていく）



・プレイヤーが高速移動で通り過ぎた場合

→　子エリアの読み込みを中止する



●まとめ

この仕組みはシンプルで、実装は容易だった

→　概ね問題なかった
→　後は データの調整、ブラッシュアップで うまくできた。
　（重そうなところは エリアを分割したり など）



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

●緊急読み込み処理　について

プレイヤーが高速移動している時に、データの読み込みが間に合わなかった時

→　最悪、建物をすり抜けたり　壁に中に入ってしまったりする。


→→　大問題


各エリアに「緊急読み込み発動領域」を用意した

→　このデータは 全てオンメモリ

→　プレイヤーが まだ読み込みが完了していない所の 「緊急読み込み発動領域」に侵入しようとした場合　
　ゲームを停止させ、データを完全に読み込み終了するまで待った。
　　（ゲームが　数フレーム ～ 数秒止まる）


→→　これは、あくまで緊急用処理

→→　基本的には こういう事が起きないように レベルデザインを心がけてもらった
　　（しかし、メディアの読み込み状態に依存するため　いつ問題が起きるかわからないので、必要な処理）



●最終的に どうなったか？

歩く速度なら 全く問題なし

もの凄い速度で飛ぶと （ゲーム終盤、キャラクターの成長によってなど） 間に合わない事も起きた


読み込みのスケジューリングの制御がうまくできない事もあり、１００％期待通りのスペックにはならなかった

→　個人的には まだ足りない所を感じつつも、製品としては 問題ないレベル

→→　今後とも 研究は継続して行っていく



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

●パフォーマンスの最適化

とにかく 物が多い

→　至るところで破壊可能

　　１エリアで １０００もの動くオブジェクトが
　　５０００ほどの背景オブジェクトがある

→　それらを全部ちゃんと動かしていたら、処理落ちでゲームにならない



・プレイヤーの周りの物しか動かさないようにした

→　プレイヤーの近くかどうか？　は、ＡＡＢＢによって判定

→　近くにないオブジェクトは システムの大元から強制的に処理をさせないようにした


→→　プレイヤーから離れたオブジェクトは 地形を貫通するおそれある
　　（当たり判定チェックしないので）

　　遠くの敵はコリジョンチェックをせず、あらかじめ設定されたパスを動くのみ
　　物を遠くに投げた場合、遠くの電柱をすり抜けてしまったりする


→→　レベルデザイナー、ＡＩ担当者　は苦労した

　　プレイヤーから離れた場合、処理が行われない事を理解した上で　物を配置したり、ルーチンを書く必要がある



→→→　しかし、処理は物凄く速くなった！！！



●つまり

処理しない　と言うのが一番早い

絶対的に数が多いので、思い切る所が必要



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

●量産効率のためのスクリプトの利用


これについては、 http://sekigames.gg-blog.com/Entry/244/ にて　まとめました。




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

●まとめ

やってみて、オープンワールドのための 特別な技術　と言うのは無かった
（全て 既存のゲームで使う技術）


一番重要なのは、シームレスである事を 常に意識すること


「ＰＳ ＶＩＴＡで、オープンワールドを作ることは可能だ」　と言う事を証明することができた

→　十分な性能、大きいメモリ、シリコンメディア

→→　オープンワールドは怖くない！！