« 「Game Developers Magazine」Post Mortem(事後分析)第3回 | トップページ | 「Game Developers Magazine」Post Mortem(事後分析)第5回 »

2010年12月 3日 (金)

「Game Developers Magazine」Post Mortem(事後分析)第4回

※以下の内容は日本語の原文となりますので「Game Developers Magazine」の英語訳と一部異なる場合があります。
---------------------------------------------------------------

 
 
 
5つの“誤”-開発でもっと上手く出来たであろうこと-

Gdmp_017

当初、次世代機開発への挑戦ということもあり、今までのコンシューマにはない膨大なメモリ量に感動しながら開発を開始しました。そのため、それが過信を生んでしまい、データ量の算出が甘くなるという最悪の結果を招きました。

その状態でのメモリ配分作業は非常に危険でしたが、その危険度を認知できないまま制作を進行してしまい、最終的にはメモリの残量との格闘になりました。特にモーションデータについて、それが如実に反映されてしまい、非常に膨大なデータがメモリ上を占拠する形となり、後々のシステム改造にまで発展しました。

他にも、屋外の処理に関しては、設置されているオブジェクト数が非常に多く、それら全てをうまく処理できませんでした。特に樹木の処理が非常に困難でした。

かといって、設置されているオブジェクトを減らしすぎると、広大な屋外に対してのオブジェクト設置数があまりにも少なくなりすぎるために、世界観と処理の最適化を常に考えながら作業しなければならない状態でした。

Gdmp_018

また、ヒットチェックに関しても、同様に、対象が非常に多くなってしまったため、処理速度低下の大きな要因となり、こちらも判定を最適化する等、最後まで念入りな調整が必要となりました。

ライティング、影の項目にも書いていますが、これらも処理に大きく影響しました。処理全体を通して、常に最適化を行わなければならなくなり、作業時間的にも大きくロスしました。

他に同様のものとして、水の波紋演出、屈折演出、鏡面演出等の描画処理が上げられます。スキルアップとして考えれば、非常にためになる内容だとは思いますが、開発として考えた場合は、大きなミスだと言えるでしょう。全体的な影響を考えても、この項目が最も上手く行かなかった一つであることは、言うまでもありません。

 
 
 
 
Gdmp_019

次に、本作ではシェーダーを使用できるということで、様々なライティング処理に挑戦しました。具体的には、フラットライティング、ポイントライト、スポットライト等のリアルタイム処理です。しかしながら、計算処理を非常に真面目に行ってしまったために、処理速度の激しい低下を招きました。

さらに悪いことには、様々なライティング手法をそのままゲーム中に使用する前提でデータフォーマットが策定されていたために、テクスチャでのライティング演出等が全く行われず、後のデータ修正に大きな影響を与えました。

ポイントライトとスポットライトは、描画処理速度が非常に重く、それでいて屋内の明るい場所(ダイナー等)では、これらのライトが大量に使用されていたこともあり、ライトの位置や総量の調整だけでなく、元のリソース自体の修正にまで発展しました。

影の扱いについても同様に苦労がありました。屋外でのフラットライティングでの影、屋内でのポイントライトでの影、特定箇所で使用されるスポットライトの影、これらを実装して行く過程において、処理速度との激しい闘いがありました。広大な屋外での影処理は、影処理の対象となるオブジェクトが非常に多く、遮蔽物も少ないために、美麗な影をきっちりと描画する必要がありました。しかしながら、それだけ美麗な影を生成するためには、莫大なVRAMが必要になり同時に処理速度も激しく低下する結果になりました。

Gdmp_020

PSM・LSPSM・カスケードLSPSM等、様々な技法を試して調整するという繰り返し作業となってしまい、多くの作業時間が割かれました。結局、美麗な影ではなく、ある程度妥協したものになってしまっただけでなく、ほとんどのリソースを修正するという事態に陥ってしまいました。

また、屋内の影に関しても、オブジェクトが複数の光源内に存在した場合、重複した影処理となってしまうため、激しい速度低下を招く原因となりました。

他にも、キャラクターのセルフシャドウが同様の結果となりました。セルフシャドウは、画面上で非常に目に付く可能性があるので、美麗に描画しようと試みましたが、美麗さを求めれば求めるほど、処理速度とVRAMを奪っていくため、ジッターテクスチャ等を使いつつ微妙なバランスで作業しなければなりませんでした。このあたりは今では当たり前の開発スタイルですが、当時はノウハウが無く非常に苦労してしまったのです。

-------

次回 12月10日公開予定
 ・物理エンジンの使いどころ
 ・SEとサウンドについて

Gdmp_021

|

« 「Game Developers Magazine」Post Mortem(事後分析)第3回 | トップページ | 「Game Developers Magazine」Post Mortem(事後分析)第5回 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: 「Game Developers Magazine」Post Mortem(事後分析)第4回:

« 「Game Developers Magazine」Post Mortem(事後分析)第3回 | トップページ | 「Game Developers Magazine」Post Mortem(事後分析)第5回 »