メモリの問題はずっと前ですか？



わかった、いや。 一部の商用エンジンはメモリでの動作が不十分であるだけでなく、多くのプラットフォームにはかなり厳しいRAM要件があります。 さらに、ディスクとカートリッジのサイズにも制限が追加されます。



レベル、テクスチャ、およびゲーム全体を必要な量に絞るほとんど違法な方法について、さまざまな年とプラットフォームからゲーム業界から例を収集しました。 これらの方法はあまり美しくないかもしれませんが、開発者がゲームをリリースすることを許可し、誰もまだ何も推測していません。

プロのロード画面

私たちのゲーム（一人称シューティングゲーム）では、Xboxにレベルを正しくアップロードするのに問題がありました。 メモリの一部を解放できなかったため、レベルの完了と次のゲームへの移行後、常にクラッシュしました。 Xboxのメモリは非常に限られており、PCとは異なり、プログラムがメモリを使い果たした場合に備えて、コンソールには追加の低速ストレージがありませんでした。 彼女はすぐに死にかけていました。



私たちのチームは、実際にこの問題に非常に遅れて気づきました。適切なレベルからゲームを実行する機会があったからです。 レベルエディタのこの​​機能により、プログラマやデザイナーは、メインメニューや以前のミッションをスキップして、作業中のレベルに直接ジャンプすることができました。 このような機会は開発プロセスにおいて不可欠であり、この機能のないゲームを見たことはありません（もちろん、ゲームのリリース前にカットされることがよくあります）。



そのため、便宜上、全員がエディターでゲームを開始し、目的のレベルにジャンプしました。 もちろん、これはメインメニューの開発者には関係ありませんでしたが、彼らはこのメニューのみを起動し、レベルをロードしませんでした。 そのため、ほとんどのプロジェクト開発者は、レベルをメモリからすぐにアンロードできないことをすぐには知りませんでした。



品質管理部門がこのエラーを発見したとき、開発のこのような後期段階ですべての漏れを排除することは非常に困難であることが判明しました。 最初のリークは簡単でしたが、レベルの開始前にメモリの小さな断片をすべて追跡してクリアすることが徐々に難しくなりました。 私たちは多くの仕事をしました-連続して4〜5レベルを実行できましたが、遅かれ早かれコンソールがクラッシュしました。 一度にキャンペーンを完了することは不可能でした。



開発チームはすべてを時間通りに修正できませんでした。 彼らはあまりにも早くあきらめた可能性がありますが、私にはわかりません...しかし、彼らは開発者が利用できる便利なXboxコンソールAPI機能を利用しました。 その後（およびXbox 360でも）、コンソールに再起動を依頼することができました。 開発者は、再起動後に何をすべきかをXboxに伝えることができます。



つまり、特定のパラメーターを使用して同じゲームを再起動して再起動するようにコンソールに要求できます。 そのため、レベルのクイック起動はエディターからゲーム自体に移動しました。 レベルを完了すると、ゲームはコンソールを再起動し、コマンドラインパラメーター（起動するレベルの名前）で再び起動しました。 もちろん、再起動すると黒い画面が表示されたため、暗転画面がすぐに実装され、黒に切り替わりました。 エディターのように、コンソールが再起動して次のレベルに移動し、その後徐々に明るさが増しました。 出来上がり、レベル間のすべてのメモリをクリアする完璧な（？）方法が用意されています。



- ニコラス・メルシエ

RAMとクラッシュ

PlayStation 1用にCrash Bandicootを書いた2人のプログラマーの1人でした（アンディギャビンと共に）。



RAMはそのときでも大きな問題でした。 PS1には2 MBのRAMしかなく、ゲームに合わせてクレイジーなエクスプロイトを行う必要がありました。 フレームレートが30 Hz未満に低下した場合のロード中の遅延を最小限に抑えて動的にロードおよびアンロードすることになっている10 MBを超えるレベルがありました。









基本的に、Crashがレベルを移動したときに、Andyが64 KBのデータページをロードおよびアンロードするすばらしいページシステムを作成したという事実のおかげで、ゲームは機能しました。 これは、高レベルのメモリ管理からオペコードレベルでのDMAコーディングに至るまで、システムのすべての機能を実行するすべての機能のデモでした。 Andyは、CD-ROM上のバイトの物理的な場所を制御し、300 KB / sの読み取り速度で、クラッシュが適切な場所に到達するまでにPS1が各レベルのデータをロードできるようにしました。



サウンド、グラフィック、Lispの敵制御コードなどのリソースを受け取るパッカーを作成しました。 -そして、それらをAndyシステム用の64 KBページにパックしました。 （ちなみに、固定サイズのページに任意のサイズのオブジェクトの理想的なパッケージングを作成するタスクはNP完全であるため、多項式での最適なソリューション、つまり妥当な時間はほとんど不可能です。）



一部のレベルはフレームワークにほとんど適合せず、私のパッカーは多くのアルゴリズム（最初の適切なもの、最も適切なものなど）を使用して、完璧なパッケージオプションを見つけようとしました。 特に、アニーリングのシミュレーションで使用される勾配降下プロセスと同様の確率的検索が使用されました。 本質的に、私はたくさんの異なるパッケージング戦略を持っていました。 プログラムはそれらすべてを試し、最良の結果を選択しました。



ただし、このランダムな検索の問題は、同じ結果が再び得られるかどうかわからないことです。 確率パッカーが「非常にラッキー」だった場合にのみ、一部のクラッシュレベルが最大ページ数に収まる（21ページあったようです）。 これは、レベルのパッケージ化後に、1つのタートルのコードを変更でき、21ページで同じパッケージ構成を再度達成することはできないことを意味します。



時々、アーティストの何人かが何かを変える必要があることが起こりました。 同時に、許容ページ数を超えて、パッカーが適切なパッケージ構成を見つけるまで、他のリソースをほぼランダムに変更する必要がありました（これを午前3時にイライラするアーティストに説明してみてください）。



しかし、振り返ってみると、最良の（そして同時に最悪の）部分は、カーネルコードをC /アセンブラに適合させることでした。 お祝いシーズンにリリースする最後のチャンスである「ゴールデンマスターディスク」のリリース日の数日前に、私たちは文字通り分離されました。さもなければ、1年を失うことになります。 そのため、Cのコードを意味的に同一であるが構文的に異なる構造にランダムに変更し、コンパイラーが200、125、50、そして8バイト少ないコードを生成するようにしました。 変更は次のようなものでした。「for（i = 0; i <x; i ++）」を、他の場所で既に使用されている変数を使用するwhileループで置き換えるとどうなりますか？ これは、ポインターの下位2ビットにデータを詰め込むなど、すべての通常のトリックを使い果たしたときにすでに起こりました（すべてのR3000アドレスが4バイトの倍数であるためにのみ機能しました）。



最後に、 クラッシュをPS1のメモリに収めることができましたが、4バイトはまだ空いています。 はい、2097152のうち4つ。古き良き時代。



-Dave Baggett、inky.com（およびNaughty Dog＃1従業員）

詳細への注意

それは10年前に起こりました。 当時、私はRTSの小さなスタジオで働いていました。RTSはPC専用に制作されました。 チームの規模は中規模（約35人）でしたが、私たちはすでに約1年間働いており、制作プロセスの途中でした。



このRTSはレベルに分割されます。レベルを通過すると、次のRTSがロック解除されます。 他のPCゲームと同様に、異なる構成のマシンで動作する必要があったため、異なる解像度（低、中、高）の3セットのテクスチャを備えたゲームをリリースしました。



つまり、各レベルには2つの追加のテクスチャパックがあり、1つは中解像度テクスチャ、もう1つは高解像度テクスチャ（低解像度テクスチャはメインの大きなファイルに直接パックされました）。



制作は順調に進み、ゲームはほぼ終了しました。 パフォーマンスは一定レベルであり、安定性があり、ほとんどのバグを排除しました。 締め切り前の最終日に近づいています。 翌朝、完成したゴールドマスターCDを焼き付けて工場に送らなければなりませんでした。



そこで、ISOイメージを作成し、英語版、フランス語版、スペイン語版を記録してテストしました。 問題は発生しませんでした。 そして、それはドイツのディスクに来ました！ ISOの書き込みを開始し、「画像がメディアに収まりません」というメッセージが画面に表示されました。



なに？ これはどのように可能ですか？ 他の3つのバージョンを記録したばかりで、クロックはすでに夕方8時になっています。 CDは翌日の朝7時に送らなければなりませんでした。 私たちは理解し始め、録音されたドイツ語の声の演技は他の言語よりも長く続き、他の言語よりも多くのディスク容量を占有することがわかりました。 すべてのボリューム要件は、他の言語を考慮して設定されました。 問題を修正し、CDを焼き、そのパフォーマンスを確認するのに約10時間かかりました。 ディスクスペースを節約するために、音を絞ったり、他のトリッキーな変更を行う時間はもうありませんでした。



次に、素晴らしいアイデアがありました。レベルの1つを選択し、高解像度テクスチャパッケージを削除して、中解像度パッケージのコピーに置き換えます。 バム！ 50 MBを保存し、ISOがCDで壊れます。 そのため、強力なPCを備えたドイツの友人は、平均的な構成を持つ人々と同じテクスチャディテールで、いずれかのレベルでプレイしました。 はい、認めます。長くてストレスの多い夜でした。



-ファークライエンジンアーキテクト、レミーケニン

サイズは重要ではありません...

2008年、私たちはXBLAからロードされたゲームに取り組んでいました。 当時、すべての360にはハードドライブが付属していなかったため、ダウンロード可能なゲームはメモリカードにインストールすると機能します。 ゲームはかなり小さく、約240 MBでした。 つまり、256 MBおよび512 MBのメモリカードで製品をテストする必要がありました。



512 MBのカードでゲームは完全に開始されましたが、256 MBから開始すると、システムの周期的な不安定なブレーキングが発生しました。 私たちは解決策について少し考えましたが、その結果、幽霊と戦うのではなく、ゲームの品質を改善することに努力を費やす方が良いという結論に達しました。



したがって、合計ファイルサイズが260 MBを超えるように、ゲームデータ内に20 MBの音楽ファイルを配置します。 これにより、認証のために、256メガバイトのメモリカードでゲームをチェックする必要がなくなりました。 時間通りにリリースしたのは良いゲームでした。 マイクロソフトとお客様は何も推測していません。



-匿名

たくさんの苦痛

優れたアクションゲームをPCからPS2に移植するとき、多くの「楽しい」瞬間がありました。動的割り当てを積極的に使用する256 MBのPCゲームは、32 MBに収まる必要がありました。 多くの最適化を行い、レベルのストリーム読み込みを追加した後でも、それはあまりにも多くのボリュームを占有しました。したがって、

• アセンブリが実行されたマシンは、システムが起動し、各メモリ割り当てを監視した後にレベルをロードしました。 彼女は、どの割り当て操作がレベルの開始まで生き残ったかを見ました。 ゲームが再開されたとき、彼女はこのシーケンスを使用して各永続的な配置を線形に割り当て、他のすべてをヒープまたは一時メモリに分散しました。 これにより、最大約15％（5 MB）のメモリが節約され、メモリ割り当てが大幅に加速され、断片化が大幅に削減されました。 しかし、それでも、約3レベル後、再び断片化が多すぎたため、次のようになりました。
• ビルドマシンは2番目のステップを実行しました。再起動し、レベルをロードして（最初のステップからの最適化で）、レベルの開始時にヒープ全体のダンプをディスクにダンプしました。 完成したゲームは、各レベルをロードするときに、これらのメモリイメージをヒープの上部に直接ロードするだけです（ローカルプロファイル設定をスタックに一時的に保存します）。

結果：各リリース候補のビルド時間を増やすことを犠牲にして、レベルのロードが非常に高速になり、各レベルの開始時に断片化がゼロになります。



-匿名

ピクセルを詰める

Minecraft for 3DSを開発する過程で、より強力なNew 3DSでさえ、メモリ不足に苦しみました。 したがって、3DSがサポートするテクスチャ形式を試してみました。 3DSの内部テクスチャフォーマットは非常に奇妙でした。 これは、ジグザグパターンのジグザグパターンに配置されたタイルに基づいており、その後、最高レベルで直線的に並べられました。









残念ながら、私たちのチームは誰も変換ユーティリティを作成するための圧縮形式に精通していませんでした。 プログラマーの1人であるIanは、以前はMega Man Legacy Collectionのテクスチャコンバーターで作業していましたが、ほとんど圧縮されていないピクセルデータを処理していました。



このテクスチャコンバーターは.pngを受け取り、独自の形式の「.3dst」ファイルを作成しました。Ianが発明しました-本質的に、それはメモリに書き込むことができる小さなヘッダーと生データでした（「3dst」は「3DS Texture」の略です-論理的ですか？）。



任天堂は独自の変換ユーティリティを提供しましたが、実行時の解析と読み込みのために任天堂ライブラリで使用する必要がある「パッケージ」ファイルに画像をエクスポートしました。 私たちには高すぎました。 そして、ここで私たちは再び運が悪かった-任天堂はこのファイル形式を文書化せず、サポートされている3DS形式で圧縮画像を組み立てる唯一の方法であるように思われた。



そこで、16進エディタをさらに深くすることにしました。 必要なデータをすばやく作成するのに十分なフィールドを決定するまで、Nintendoユーティリティにさまざまなサイズと形式のさまざまな画像をフィードし、ファイルのヘッダーで発生した変更に気付きました。 ニンテンドーパッケージファイルから生データを抽出する小さなユーティリティをスケッチし、必要なすべてのテクスチャにこのプロセスを適用するバッチスクリプトを作成しました。 決定は迅速ではなく、確かにエレガントではありませんでしたが、そのタスクに対処しました。



-キース・キーショット、デジタル・エクリプス・プログラマー

醸造するだけ

プラットフォームの3Dレースに取り組んでいたとき、ヒープは実行可能ファイルのデータセクション内に含まれていました。 これはmodと呼ばれるエルフのような実行可能形式であり、ファイルをメモリにロードするときにアプリケーションがメモリを割り当てるゼロで満たされた巨大な領域が含まれていました。



そのため、多くの場合、動的メモリを使い果たし、メモリ管理を正しく実装する代わりに（このシステムのリソースは非常に限られていました）、より多くのゼロとパッチ.exeを挿入するツールを書くことにしました。 ソリューションは完璧に機能し、良心は私を悩ませませんでした。なぜなら、それはひどいプラットフォームであり、ひどい実行可能ファイル形式だったからです。



-アンドリューハニング