AAAのグラフィックで遠方まで見えるのを自分で実装することを考えてみろよ
LODを使うとしても、その座標までのモデルデータの一部がメモリに載ってることは変わりないし、その全ての詳細データにアクセス可能な状況なわけだよ？
しかも遠くになれば浮動小数点の誤差が激しくなる(浮動小数点使ってた場合)
しかも景観はエディタで確認可能な必要があるわけだ。
そうでないと「遠くに映るあれを目立たせたい」って言うのが見て確認できない。
つまりだ、
各レベルを別ファイルにして個々で作業し、そこから景観専用のハイトマップとかの中間データを作成して、実行時には低ポリだけ読む、みたいな方法ではまともに作れないわけ。
これだけでも相当作るのが難しいのが想像できて来ただろう。
それに加えて、街、バトル、フィールド、イベント、全てシームレスでAI仲間が常駐してて、内部処理もシームレス。
つまり、戦闘用とか、フィールド用とかで、一旦メモリを確保して、切り替わるタイミングでクリアする、みたいな処理も難しい。
暗転という絶対的なロードを持てない。
魔法のデータも敵のモーションとテクスチャのデータも、味方の通常モーションと戦闘モーションも、
全てが暗転によって同期的なロードをはかれない
言い出せば切りがないが、
例えば、ポケモンでバグが連発するのと、
FF15でバグが連発するでは次元が違う。
だったら作って売るなよで終わり
開発難易度が高いからバグがあっても仕方がないなんて言うぐらいなら、難易度下げてバグを減らす方が消費者に対して誠実だよ
>>1の言ってることよくわかる
自分でメモリ管理するゲーム作ってみるようになってはじめて暗転のないゲームの難しさ知ったわ
一般的なゲームだと特定のアロケータを使うnewを複数用意して、フィールド用とバトル用とかで適宜解放して断片化を防ぐけどそう言う作りが出来ない。
そうとう細かく定義して上手く使い分けるんだろうな。
GCでの実装だと、明示的に参照カウンタを元にGCの開放をするのは、流石に重いから暗転中に仕込まなきゃいけないし、どのみち断片化するからFF15レベルの作品だと相当効率よく使わなきゃすぐリークして落ちるゲームになっちゃう。
FF15を作れるところまでスクエニを成長させたディレクターの田畑ってやつは相当凄いと思う
>>17
オープンじゃなくてもあの規模のグラであれだけ安定したゲーム作るってだけでも尊敬するわ
俺なら仕様を削ぎ落として、動的メモリの確保は本当にごく一部しかしない作りにしちゃうと思う
無駄があっても静的メモリに置いてリーク阻止したい。
オープンワールドとかじゃないなら、ある程度無造作な動的確保がされちゃうのは覚悟してUnityとかのエンジン使ってGC任せって手もあるけど、
オープンワールドなら自社エンジンだわな
技術にも明るい田畑からしたら、自社エンジンなのにオープンワールドから逃げようとするエンジニアは論外だったろうな。
そんなんUEでも使っとけって思ってたはず。
実際FF7RはUEで作ってで技術的に何も面白くないゲームになってた。
下手したらヴェルサスもそうなってたんだろうな。
田畑だけが先を理解して見据えてものを作ってるって感じだわ
FF15よりよっぽど高度な事をやってのけてるからな
自分で料理をするようになって、キャベツの千切りを揃えて切る難しさがわかった
だからレストランで出てきた皿のキャベツは不揃いで全体の盛り付けもボロボロだけど評価すべき
そういう話かね？
なので笑われてもしかたがない
この記事へのコメント
誰もラクなんて言ってないんじゃないか？
大規模開発ならバグが出るのは当然なので、バグを潰す開発体制を組んで、
商品にするまでに潰して発売するべきだよねってだけで。
できないならその程度の技術蓄積しかないんだから、
チャレンジ幅を妥協して開発難易度を下げて発売するしかないよねって話になって
とてもシンプル。
真面目な話普通に遊んでれば深刻なバグ起きんしな、あのゲーム