汚れたビデオゲーム開発者のトリック

前の部分： one 、 two 、 three 。

ゲームをありがとう！

Wing Commanderの最初の部分では、ゲームを終了すると、EMM386メモリマネージャーから例外を受け取りました。 画面がクリアされ、「Error memory manager EMM386。 何とか何とか」



ゲームをできるだけ早くリリースする必要があったため、16進エディタでメモリマネージャエラーを編集して、「 Wing Commanderをプレイしていただきありがとうございます」のように見せました。



-ケン・デマレスト

100％純粋なフルーツジュース

私が最初にゲーム業界で働き始めたとき、ほとんどの場合、私は様々な小さなまばらに資金提供されたスタートアップで働いていました。 男性が男性でDirectX 7を使用していたときのホラーストーリーを次に示します。私は、出版社が特定の3Dエンジンを使用せざるを得ない会社で働いていました。 私は彼に電話しませんが、出版社は大規模なライセンス契約で彼のためにたくさんのライセンスを購入したと主張したので、彼はそれを使うことを主張しました。



それに直面しましょう-エンジンは動作しませんでした。会社で働いていたほとんどの時間、3Dエンジンにいくつかのテクスチャからシングルパスオーバーレイライティングマップを実装するなど、明白なことを行う方法を教えました。



最も興味深い壊れたものの1つはBSPコンパイラでした。 レベル設計者は、正しい可視性を備えたレベルジオメトリを作成しました。その後、わずかなジオメトリの変更が、マップのまったく異なる部分の可視領域に違反しました。 なぜこれが起こったのかはまだわかりませんが、エンジンのBSPコンパイラーがランダムな順序と特定の組み合わせでブラシをBSPツリーに追加したと思われます。



当時、私はランダム化されたアルゴリズムを聞いていませんでしたが、それでも発明しました-BSPコンパイラに前処理ステップを追加し、ブラシの順序を混合してからBSPコンパイラに渡しました。 レベルジオメトリがBSPコンパイラで破損した場合、有効な組み合わせが見つかるまで他の乱数でブラシをシャッフルしようとし、BSPコンパイラが再び破損するまでそれを保持しました。



ゲーム自体は惨事でした-エンジンとゲームの両方が、 Fennyf * cker 2000が最初に登場したペニーアーケードコミックストリップになりました。 これは私のキャリアの重要なポイントのままです。



-ニコラス・バイニング

早送り

Sega GenesisのNBA JAM TEで働いていました。フラッシュチップを使用してゲームデータを保存しました。 このゲームは数か月にわたってテストされ、すべてのリリースの準備が整ったため、出版社は25万枚のカートリッジを注文しました。 しかし、フラッシュの初期化手順が正しいことを確認するために、テストカートリッジにフラッシュチップを何カ月も投棄した人はいないことがすぐに明らかになりました。 そして、誰もテスト用のカートリッジを注文しませんでした。









すべてのカートリッジを注文して初めて、フラッシュ初期化コードが停止し、カートリッジがゲームを正しく保存できないことがわかりました！ スタジオ全体は、25万個の壊れたカートリッジを製造する方法を見つけようとして夢中になりました。 メーカーの推奨事項を実装して、抵抗器やその他のハックを追加しようとしましたが、何も助けにはなりませんでした。



すべてが失われたように見えたとき、誰かが非常に奇妙で明確に定義された順序でゲームをプレイすると、フラッシュメモリが動作し始めたように見えることがわかりました。 そのため、この「機能」の使用方法を説明したチラシが、カートリッジ付きの各ボックスに含まれていました。



-クリスカービー

煙

私の好きな土壇場でのハックは、 Nitrobike PS2ゲームの4人モードで使用されました。 いつものように、レベルデザイナーとアーティストは、現実の世界でどれだけ実現可能かを知らずに仕事をしました。いつものように、ゲームを「完了する」という仕事は完全に私に任されていました。



多くの論争と衝突の後、レベルグラフィックスを単純化し、視覚的に隠された領域を作成し、不要な動的オブジェクトを削除しました。 しかし、これは映画をテーマにした特定のレベルを保存できませんでした。 レベル設計自体は、余分なものを隠すことに抵抗しました-それは2つの大きな部屋（物語の中で-パビリオンを記録する）で構成され、それらは重なり合わず、2つの開いたドアで接続されていました。









壁の中央に1つのドアがありました。 ある部屋をブロックするために重複するポリゴンを作成する方法はありませんでした。そのため、そのスタイルを破壊せずにレベルグラフィックスを削除する方法がなかったため、別の部屋から見ることができませんでした。 中央の壁に重なる1つの大きなポリゴンを壁に配置する方法を見つける必要がありました。 そして、それは私に気付きました-粒子で作られた「煙の壁」は、中央のドアを閉じて、キノテマティックのレベルにうまく合い、私の問題を完全に解決します。



煙の壁は通り抜けることができますが、それを通して見ることはできず、重複するポリゴンの存在を隠します！ 私は1人のアーティストにそのようなエミッターを作成し、1人のレベルデザイナーにドアの両側にエミッターを配置する機会を与えました。



そして最後に、真ん中に、1つの非常に大きな重なり合うポリゴンを挿入しました。 それは見栄えが良く、速度レベルに関する最後の問題を修正しました。



-スティーブンボズウェルII

...多分ここに？

私は20年以上ゲームを書いてきましたが、最近、THQでテクニカルマネージャーとして働いていたので、あらゆる種類の恐ろしいハックを十分に見てきました。 しかし、私はまだ笑っているものがあります。 彼は1990年代初頭にBeam Softwareに偶然出会った。



便利なIDEやスマートコンパイラがなかった時代に、すべてのゲームをアセンブリ言語で作成しました。 すべての.sファイルには、クリーチャー1.s、コリジョン.s、controls.sなど、ゲームの個々の部分に対応するアセンブリコードが含まれていました。 さらに、メイクファイルを使用しました-プログラマーは新しい.sファイルを作成し、メイクファイル内の他のすべての後に配置しました。



アイデアは、コマンドラインにmakeと入力し、アセンブラーが各ファイルを新しい.oファイルに収集した後、リンカーがそれらをすべてまとめて完成した実行可能ファイルをビルドすることでした。 バグコードを書いたことで悪名高いプログラマーが一人いて、ランダムなメモリ領域を妨害していました。 これらは通常、バッファオーバーフローでした。



彼はこれらのバグを見つけるのにしばらく時間を費やしましたが、成功しなかった場合は、メイクファイル内のファイルの順序を変更して、ファイルがメモリ内で別の順序で静的にリンクされるようにしました！ これは、ランダムに記録されたメモリが別の場所にあることを意味していましたが、純粋な運のおかげで、何らかの理由でゲームが落ちなくなりました。 彼は、メイクファイルへのほとんどすべての変更が失敗し始めるまでこれを行いました。



最後の瞬間、ゲームをリリースしなければならなかったとき、彼はこの問題を解決しました。 彼は単に新しい.sファイルを作成し続け、データの小さな塊で埋め、それが何らかの形でクラッシュを停止するまでmakefileの任意の場所に挿入し、それをリリースしました！ 当時、このような「技術」を使用してリリースされたゲームボーイ用のゲームが少なくとも2つありました。



-シェーンスティーブンス

規格外

PlayStation 3での最初のプロジェクトであるWorld Series of Poker 2008をリリースしたかったのです。PS3はいくつかの異なる画面解像度と2つのアスペクト比をサポートしていました。 ワイドスクリーン用の2Dシェルを作成しましたが、標準解像度の2Dシェルには十分な時間とリソースがありませんでした。 開発者の要件を慎重に検討しましたが、レターボックス化が禁止される理由は見つかりませんでした。



したがって、標準の比率モードは、画像の上下に黒いバーがあるワイドスクリーンモードでした。 パブリッシャーは、それを修正するための要件を調整することに必死でしたが、その後あきらめて、ゲームをそのままリリースしました。 さらに、自分のPS3を購入してから数時間後、標準のアスペクト比のテレビで遊んだ後、ワイドスクリーンテレビを購入しました。 多くの人がこの奇跡の技術（PS3）を古い真空管テレビに接続しているとは思いません！











-スティーブンボズウェルII

定数の追求

何らかの理由で、既存のコードベースと、古いコードライブラリを使用するために作成された新しい数十億行のコードとの間に大きな非互換性がありました。 最初のコードは、「安全な」プログラミングの考えに近い人々によって書かれ、エラーを避けるために可能な限り厳密で制限されています。 したがって、彼らはCONSTと呼ばれるC / C ++言語関数を使用しました。



CONSTは「定数」を意味します。 関数内で読み取り専用変数を変更できないようにします。 CONSTを使用するコードとCONSTを使用しないコードは互いに互換性がないことが判明したため、コンパイラーは呪われました。 開発チームは、コードにハックを挿入することを決定し、トリッキーな小さなトリックを実行しました。＃define const。定数は...何もない、空の場所でした。 したがって、構築はconst int x;



コンパイル前の前処理中に、 int x;



になりましたint x;



。 これは、車を購入し、2つの車輪を外してオートバイとして使用することに似ています。



個人的に、私はCONSTがひどく嫌いなので、このトリックが好きでした。 しかし、このアプローチをシートベルトをハサミで切ることに似ていると考える人もいました。



-匿名

リアリティバイト

PlayStation 3用のUnreal Engine 3エンジンのゲームにバグがありました（これはPS3用UE3で最初にリリースされたプロジェクトでした）：デバッグモードでは、ゲームはマルチプレイヤーゲームに接続したときにprintf（）中に不可解に落ちました。



デバッグモードでは、クライアントは、サーバーをロードするように命じた各コンテンツパッケージのすべてのハッシュを表示しました。明らかに、（このアセンブリの）ハッシュの1つは％でした。 問題に対する適切な解決策を見つけることはできませんでしたが、＃ifndef PS3は、バグが消える次のデータアセンブリまで非常にうまく機能しました。



約1年後、次のプロジェクトで同じバグに遭遇し、まったく同じ修正を使用しました。 クラッシュは、ゲームのリリース後、コンテンツのパッチに取り組んでいたときに発生しました。 DLC /パッチの作成は、コンパイル済みのUnrealScriptにパッチを適用できない方法で実行されましたが、2つのリモートプロシージャコールが信頼できるものとしてマークされないバグがありました。 これは、確認の受信までコールのパケットが再送信されることを意味します。 したがって、接続が不十分な状況では、ロビーでの準備と音声伝送の状態を有効にする機能が呼び出されないことがありました。 ただし、リモートプロシージャコールを信頼できるものとしてマークできるのはUnrealScriptのみであり、UnrealScriptにパッチを適用することはできません。



したがって、ロード時に、ロードされたすべてのUFunctionオブジェクト（C ++のスクリプト関数の表現）をループし、名前の文字列比較を実行し、これらの2つの呼び出しに「信頼できる」フラグを割り当てました。 すべてがうまくいきました。



-匿名

データの準備ができました

最初のXboxのXbox Live Arcadeゲームは、完全に.xexファイルにパッケージ化されていました。 これを実装するために、すべてのデータを.zipファイルに保存しました。このファイルは、実行可能ファイルにデータセクションとして埋め込まれています。 徐々にファイルが大きくなり、データセクションをメモリにロードできなくなり、アンパックするのに十分なメモリを割り当てて、目的のファイルを取り出すことができなくなりました。



この問題を修正するために、ゲームをロードした後、実行可能ファイルのPEヘッダーを読み取り、データセクションにオフセットを書き込むコードを作成しました。 これにより、実行可能ファイルを読み取るファイルストリームは、異なるzipファイルのオフセットに単純に切り替えて、データセクションをメモリにロードせずに実行可能ファイルから直接出力することができました。



-パット・ウィルソン

ピンホールカメラ

古いケースについて説明します。Force21は、現在のチームを監視するためにフローティングカメラを使用した最初の3次元RTSの1つでした。 プロジェクトの終わりに向けて、チームがチームに続いて停止するという奇妙なバグがありました。チームが動き続けている間に停止し、何も動かせませんでした。 これはランダムに発生し、エラーを再現できませんでした。



これは、テスターの1人が、プレーヤーのテクニックの近くで空爆が発生したときにこれがより頻繁に発生することに気付くまで続きました。 この情報のおかげで、エラーの原因を見つけることができました。 カメラは速度と加速度を使用し、衝突にも関与する可能性があるため、このような特性を備えたPhysicalObjectクラスから継承しました。 しかし、彼にはもう1つの特徴がありました。PhysicalObjectは損傷を感知できるということです。 空爆はかなり大きな半径で大きなダメージを与えたため、文字通りカメラを「殺した」。



カメラが損傷を受けないようにこのエラーを修正しましたが、安全のために、装甲とエネルギーの値を膨大な値に増やしました。 私たちのゲームには、世界で最も強力なカメラがあったと自信を持って言えると思います。



-ジムヴァンワース

ヘキサピラビリティ

N64用の新しいテトリスをテストしていました。 いつでも再現できるクラッシュがありました。画面にレジスタのダンプが表示され、その後ゲームがクラッシュしました。 ハングを取り除くには、N64の電源を切ってから入れ直さなければなりませんでした。リセットキーも反応しませんでした。



バージョンごとに、開発者はバグが修正されたと言い、私はバージョンごとにそれをプレイしました。 リリース期限が迫っていたため、ゲームをリリースするために、開発者はクラッシュにつながるすべてのバグを排除する必要がありました。 （任天堂は他社のゲームも独自にテストしたため、任天堂はゲームをリリースするためにそれを承認する必要がありました。）しかし、彼らはこのバグを取り除くことができませんでした。



また、ゲームにはバグに関連しない秘密のコードがあり、さまざまな機能のロックを解除するために入力できました。 開発者が16進ダンプ画面を「おめでとう！ 秘密のコードを発見しました！ コンソールを再度無効にしてから有効にし、HALUCIユーザー名を入力します。 そして彼はそうしました。 これにより、ゲームがリリースされました。



-匿名

ショートスタック

1982-83年、私はIMAGICのいくつかのインターンの1人でしたが、当時は全員がIntellivisionのカートリッジを作成していました。 プログラマーの一人が学校に戻る必要があったので、彼らは私に彼のゲームのハングでバグを修正することを選択しました。 これは、タイマー割り込みハンドラーでのスタックオーバーフローであることが判明しました。



ハンドラーの唯一のタスクはスクリーンタイマーの表示を更新することであるため、スタックの深さをテストするために、割り込み手順の最初にコードを追加しました。 スタックオーバーフローの危険性がある場合、プロシージャは何もせずにリターンを実行しました。 ハンドラーは毎秒何回も呼び出されるため、プレーヤーは何も気付かず、エラーは修正されました。



-匿名

基本に戻る

同僚のマイク・ミークと私は、アーケードマシンからKlaxタイルを収集するゲームをGame Boy Colorに移植しました。 私たちのお気に入りのゲームの1つをシステムに移植するのは、興味深い、集中的な6週間のプロジェクトでした。



Cのソースコード（実際には、ロボットモンスターの惑星からの脱出、ほとんどのロボットモンスターのみがコメント化され、 Klaxコードに置き換えられました）があり、よく書かれた元のアーケードゲームプログラマーのデイブエッカーズとよく話しましたAmiga BASICで週末のプロトタイプを作成し、約1日でCに移植しました。



アセンブラーZ80でゲームをエンコードしました。 興味深いことがたくさんありました。たとえば、実際のデバッガーがなかったため、ホワイトボード上のコードを書き直し、別のホワイトボードのメモリの内容を更新して、行ごとにメンタルウォークしました。 良い時がありました。



締め切りはすでに迫っていましたが、すべてうまくいきました。 アーケードバージョンをプレイし、GBCのバージョンをテストしたところ、奇妙なスコアリングバグが見つかりました。 問題自体は覚えていませんが、大きな十字架がいくつかの対角線に分割されているような状況がありました。 アーケードマシンと比較したGBC上のポイントが正しく計算されなかった可能性があります。



言うまでもなく、私はこれを午後11時30分頃（期限の直前）に発見しました。 アセンブラコードをアーケードマシンのCコードと比較して、コードを100万回実行しましたが、バグは発生しませんでした。 ポイントを正しく数え、コードはCプログラムとまったく同じ順序で実行されました。これは、DaveがAmiga BASICで最初に行ったことを1行ずつ転送するだけでした。 （デイブはマイクに少し似ていたと思う-彼はアセンブラーとBASICについて多くを知っていたが、彼は20年前にKlaxが作られたときにCが好きではなかった。）









最後に、朝の5時頃、これに一晩中費やして、うまくいかなかったかもしれないと思いましたが、試してみる価値がありました。 マイクはスコアシステムをQuick BASICで作成し、ポイントはアーケードマシンとまったく同じ方法でカウントされ始めました。 次に、BASICを1行ずつZ80アセンブラーに移動しました。



うまくいきました。 神はその理由を知っていますが、プログラムはアーケードマシンとまったく同じように動作しました（おそらくこれは、元のコードがBASICで作成されたという事実に何らかの関係があるのでしょう）。 Atariアセンブリを送信し、両方のバージョンのコードを印刷して、カフェに行きました。 朝食時に、コードを1時間見ても、それがなぜ異なる動作をするのか理解していませんでした。 私たちは今日、コードが同一の結果を与えたはずだと誓うことができます！ しかし、時には、手遅れになったら、ブードゥー教のプログラミングをする時が来ました！



-クリス・チャーラ



ハッキングが状況を救えるのはゲームだけではありません。 ボーナスとしてそれらを含めないためにあまりにも好奇心が強い2つのゲーム以外の例があります。

窓用ワッシャー

5年前、私はビデオ監視用のソフトウェア開発の分野でプログラマーとして働いていました。 非常に繊細で洗練されたセキュリティソフトウェアを作成しました。 素晴らしい、機能の良い製品がありました。 ソフトウェアの最も難しい部分は、画面上に50のビデオストリームを同時に表示することでした。 ソフトウェアには膨大な量のメモリが必要で、24時間年中無休で機能する必要がありました。



リリースの数週間前に、ベータ版を顧客に配信しました。 1週間後、1分あたり約4 KBの巨大なメモリリークが発生しました。 リークの調査に数日を費やしましたが、結果が得られず、リリース前に修正する時間もありませんでした。 メモリはソフトウェアの重要な部分であり、このサイズのリークはアプリケーションを完全に殺してしまいます。 テスト中（Windows）、コードウィンドウに戻るためにソフトウェアウィンドウを最小化する必要があり、その間に占有メモリの大幅な減少に気付きました。



その後、ウィンドウを通知領域または[スタート]メニューバーに移動すると、Windowsは未使用/解放されたメモリを即座に復元することを思い出しました。 これは私たちのチャンスでした！ アプリケーションにタイマーを追加しました。これにより、数分ごとにウィンドウが[スタート]メニューパネルに移動し、すぐにフルスクリーンで展開されました。 画面上ではちらつきのように見えましたが、うまくいきました！ その後、アプリケーションを起動することができました。これにより、バグを修正するためにもう少し時間がかかりました（数日後に発見されました-ウィンドウハンドルが適切にクリーニングを実行しませんでした）。



-ヨハン・ラウニ

結果は異なる場合があります。

1970年代、チームと私は銀行システムに取り組みました。 長い間忘れられていたプログラミング言語MPL2で作成しました。 この言語には256個のグローバル変数の制限があり、それらはすべてシステムに新しい関数を追加するために使用されていたため、コードのさまざまな部分で2つの異なる目的のために解放または使用できる変数を探す必要がありました。



それは危険で長いプロセスでした。 プログラム内では、各関数は、関数のスコープによって制限される256個の独自の変数を持つことができます。 かつて、私が家にいたとき、洞察が私に降りかかった。 翌朝、私は上司にすべてのコードを関数にラップすることを提案しました。 次に、プログラムに256個のグローバル変数を使用します。これは、これまでに使用された256個が「内部」関数に確実に保存されるためです。



プログラム自体は、さらにいくつかの変数を宣言するだけで、ソースプログラム全体が配置される関数を呼び出します。 しかし、彼女は自分の256個の変数だけでなく、新しい256個のグローバル変数も「見る」ことができました。 私の上司は懐疑的でしたが、2時間の編集時間枠を与えられ、それが機能することを見てst然としました。 数年間、チームが直面した問題を回避することができました。