[スケジュールがなくなり、プロジェクトをリリースする時が来たら、プログラマーは汚いトリックに頼って、ついにゲームをドアから押し出すことができます。 この記事では、実生活からそのような「クランチ」の9つの例を収集しました。]



通常、プログラマーは整然としてきちんとしたクリーチャーであり、美しいコードを目指して一生懸命努力しています。 しかし、賭け金が高く、完璧なスケジュールが崩れ、ゲームをリリースする時が来たとき、「どんな費用でも仕上げる」という原則が優雅さよりも重要かもしれません。



そのような場合、苦しみ、過労しているプログラマーは、最適なアプローチを無視し、受け入れがたい解決策に置き換えて、ゲームを終了するだけです。 私たちは、スケジュールを満たすことができず、プロジェクトを保存するためにトリックに頼らなければならなかった瞬間について、実際の開発者の9つのストーリーを収集しました。

可能な限り最高の方法で私を離陸

約4年前[約。 transl .: 2009年の記事]私は、PlayStation 2、Xbox、およびGameCubeのマルチプラットフォームプロジェクトでプログラマーとして働いていました。 開発期間は終わりに近づいていたため、ハッキングがコードに侵入し始めたことは驚くことではありません。 PS2バージョンでは、後から発見された問題を発見するのが非常に困難でした。静止したキャラクターでの最初のレベルの安定性の長期テスト中に、ゲームが「クラッシュ」しました。 残念ながら、このエラーは小売用のディスクアセンブリでのみ発生し、デバッグ情報はありませんでした。 Sonyの技術要件チェック（TRC）からの公開の拒否を恐れて、私たちはこのソリューションに一生懸命取り組みました。



エラーの境界を狭くするために、コードのさまざまな部分に別々の色を使用して、画面の端の周りの境界線を常にレンダリングしました。 たとえば、青はレンダリング設定を示し、緑はプレーヤーコントロールの更新を示します。 常に障害が発生するとは限らなかったため、リードエンジニアと私は大量のディスクを手動で作成し、多くのPS2コンソールで実行しました。 （会社は独立した開発者であり、IT部門とクールな録音機器がなかったことに注意する必要があります。）テストサイクル-コードの変更、ディスクの書き込み、エラーのおおよその境界を狭めるための開始と待機-には長い時間がかかりました。 これが開発の最終段階であり、実行できるサイクルの数は厳密に制限されていました。







週末をオフィスで過ごし、クラッシュを待って、 World of Warcraftの時間を潰しました。 突然、カメラを右に90度回してもゲームが「抜け落ちない」ことに気付きました。 最初、プログラマーはこれを、より深いエラーを隠している事故として正しく却下しました。 この動作を修正しても、問題の根本は解消されません。 ただし、とにかく修正しました！ 時間切れになったら、レベルの最初にカメラを向けて最後のPS2ディスクを作成し（他の2つのプラットフォームのバージョンは既に準備ができていた）、検証のために送信しました。 このゲームはプラットフォーム所有者のすべてのテストに合格し、時間通りに市場にリリースされました。



私はこのソリューションを「コードのトリック」とは呼びませんが、間違いなく「ダーティ」でした。 この修正の謎はまだ明らかにされていませんが、幸いなことに、ユーザーがこのような問題について不平を言うのを聞いたことはありません。



-マーククック

自己決定の危機

この状況は、すべてのゲーム開発者によく知られています：今日、私たちはXbox 1のゲームを「ゴールド」チームに送ります。チームは、すべてが正常であることを確認するために終日ゲームをテストしています。 誰もが楽しくて落ち着いています。私たちにとっては、仕事はすでに完了しています。



昼食後、ゲームバランスの最後の小さな設定で最後のビルドを作成し、最後のテストセッションを開始します。その後、大惨事が発生します。ゲームは頑固に「クラッシュ」します。 作業中のマシンですべて実行し、デバッガーを実行して、何が起こっているのかを把握しようとします。 これは、アサートのような些細なことでも、ゼロ除算などの比較的追跡が難しいことでもありません。 いくつかのメモリに「ゴミ」があるように見えますが、メモリチェックではすべてが正常であることが示されます。 何が起こっているの？



数時間後、予定通りにリリースされるという夢は打ち砕かれました。 エラーを見つけようとし、1つのデータファイルに無効なデータが読み込まれていることを見つけます。 無効なデータですか？ これはどのように可能ですか？ リソースシステムは、CRC32からなる完全なファイル名とCRC32からなる64ビットの識別子を使用して各リソースを管理します。 同様に、同じゲームリソースファイルを1つにマージしました。 数万のファイルと2年間の開発があり、競合は発生しませんでした。 決して。



この瞬間まで。



設計者が昼食後にチェックした無実の小さな修正の1つが、テキストファイルの名前とCRCが完全に異なるにもかかわらず、他のリソースファイルとまったく同じ名前であるという事実につながりました！



問題を発見したとき、私たちの心は沈みました。 このような短期間でリソースインデックスシステムを変更する機会はありませんでした。 一晩中仕事をしていても、午前中にすべてが安定しているかどうかはわかりませんでした。



絶望が私たちを一掃するのと同じくらい早く、私たちがどのように間に合って間違いを修正し、「金」のリリースに間に合うことができるかという認識が生じました。 競合の原因であるテキストファイルを開き、最後にスペースを追加して保存しました。 彼らはお互いの顔に大きな笑みを浮かべて見て、言った：



「送信中！」



-ノエル・ロピス

飲酒運転

私たちのゲームの重要な部分である輸送管理システムで作業するタスクが与えられました。 幸いなことに、ほとんどのコードを別のスタジオから入手できました。 残念ながら、自分で書いていないほとんどすべてのコードがそうであるように、コードは常に理想的とは限りませんでした。 エンジンループから変数を取得するこのかわいいコードを見つけましたが、可能な限り最も愚かな方法で実行しています（リスト1を参照）。

//************************************************** // Function: AGameVehicle::Debug_GetFrameCount // //!       ;  . //! //! \   . //************************************************** UINT AGameVehicle::Debug_GetFrameCount() { BYTE* pEngineLoop = (BYTE*)(&GEngineLoop); pEngineLoop += sizeof( Array<FLOAT> ) + sizeof( DOUBLE ); INT iFrameCount = *((INT*)pEngineLoop); return iFrameCount;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この信じられないほどうんざりするコードの面白い点は、オブジェクトがフレーム数を取得する簡単な関数を持っていたことです。 しかし、それが存在していなくても、このコードを書くことで簡単に自分で追加できます！ 言うまでもなく、私がエラーを指摘したとき、このコードは私のゲームでも、それが取得されたゲームでも使用されていませんでした。 また、これがコード分析を行う価値がある理由の例ではない場合、どの例がまだ必要なのかわかりません。



-オースティンマッギー

10進コード

[Company X]で働いていたとき、[プロジェクト]が完成しないと思いました。 いずれかのレベルで、非表示にすることになっていたオブジェクトがありました。 レベルを再エクスポートしたくなかったため、チェックサムで名前を使用しませんでした。 したがって、エンジンコードの真ん中に、このようなものがありました。 そして、このコードでゲームが完成しました。

 if( level == 10 && object == 56 ) { HideObject();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

約1年後、非常にイライラしたアーティストが私たちのエンジンを使用して私たちに近づき、オブジェクトが10番目のレベルで表示されなかった理由を尋ねました。 本当に、なぜですか？



-匿名

すべての兆候はノーと言う

この問題は、新しいWolfenstein Ravenソフトウェアの開発時に発生しました。 Xbox 360のコントローラーサポート設定を作成しました。Liveと統合する場合、どのコントローラーが入力イベントを送信するかを知る必要があることがわかりました。 使用したDoom 3入力コードは、 Quake 3からほぼ完全にコピーされていたため、かなり単純なシステムでした。



既存のイベントシステムでは、追加のパラメーターが必要な場合に備えて、各イベントに2つの整数引数とNULLポインターが渡されました。 したがって、タスクはコントローラーIDを各入力イベントに関連付けることでした。 問題ないようです-コントローラーIDをイベントの整数引数の1つにパックするだけですよね？ そしてもちろん、両方の議論はすでに取られています。



そのため、別のアイデアが生まれました。断片化することなく、高速で単一フレームのメモリアロケータを使用してメモリを割り当て、コントローラ識別子を書き込み、イベントポインタでポインタを渡します。



イベントシステムは、イベントを処理した後、free（）を使用してnullイベントポインターをクリアすることが判明しました。 もちろん、この動作は、マルチヒープアプローチと完全に互換性がありませんでした。 さらに、コードにはイベントコードでfree（）呼び出しに依存していた古いDoom 3コードフラグメントが含まれていたため、コードベース全体に重要な変更を加えずに呼び出しを削除することはできませんでした。 そして、3番目の整数パラメーターを追加するとどうなりますか？ 次に、数百の関数呼び出しを変更する必要があります。



締め切りはすでに迫っていたため、問題を解決する時間がありませんでした。 したがって、私は考えられないことに決めました-コントローラーパラメーターをポインターパラメーターにパックしました。 完全に「caps」と入力された4行のコメントで、これをひどいハックとしてマークし、コードベースにアップロードしました。 そして、この松葉杖は、入力システム全体が少し優れたものに置き換えられるまで問題なく機能しました。



-デビッドダイナーマン

粘着性の詐欺師

PS2の初期のプロジェクトのストーリーは次のとおりです。 衝突/境界線には多くの問題がありましたが、通常は最後の最後にキャラクターの衝突システムを書き直すことで解決しました。 これは、「コライダー」モデルに変更されました。これは、指向性境界輪郭の階層ツリーよりもはるかに優れた衝突を処理する一連の球体です（これらはHavokエンジンが登場する前の時代でした）。



しかし、私たちは絶え間なく「バグ」を抱えており、それが私たちを夢中にさせました。 私たちはそれを「粘着性」と呼びました-プレイヤーのキャラクターが壁の近くにあり、それに沿って滑るたびに、コライダーの球は突然壁の反対側にあると判断し、それを引き裂きませんでした（つまり、キャラクターが表面にくっつきました）。



それは、「すべてが単純なように思われる」という、とんでもない間違いの1つでした。 球体が反対側にあると考えている理由を見つけて修正するだけです。 問題は、この問題が発生する前に、衝突認識のすべてのケースで何が起こるかを追跡する必要があることです。



奇妙な応答を追跡するコード内の便利な条件付きコントロールポイント、またはコライダーを混乱させる位置の変更で問題を解決できなかった場合、単にフレームレートを下げて「バグ」が発生しないようにしました。 （この問題の実際の解決策は、通常は省くことができる血液、汗、涙、およびその他の液体を必要としますが、それは別の話です。）



テストのためにゲームを送信し、このようなエラーのあるゲームはリリースされないという応答を絶えず受け取りました。 問題の不在を保証するために、球体の境界を増やすという1つの「解決策」を思い付きましたが、これは正しい修正とは言えません。 この「バグ」を使用してゲームをアーティストチームにリダイレクトし、アーティストがそれを修正し、真の深い問題を探す貴重な時間を獲得しました。



テスターは、「プレイヤーは目に見えない壁に直面しているが、これはあってはならない」などのレビューを私たちに送り始めました。 この問題は同じレベルの深刻さです（コライダーの境界を狭くし、粘着性が非常にまれに発生し、再現が困難だったため、キャラクターが壁に近づき始めました）が、ゲームの残りの部分を修正した数サイクル後に、解決策、血、汗、涙が必要であることが最終的に発見され、ゲームは流通と棚への道を進み続けました。



回避と回避によって問題を解決するこのサイクルを誇りに思っているとは言いませんが、少なくとも一時的にこの負担を肩から取り除くことができました。 私たちは常に「ああ、いや、昨日テストのためにゲームを送った」と言って、いまいましい問題を解決し続けました。



-匿名

私と私のパッチ

次のような古いジョークがあります。



患者： 「医師、これが好きなときは痛いです。」



博士： 「それではこれをしないでください。」



面白いですが、これらの賢明な言葉は特定の状況ではありませんか？ 3DサードパーソンシューティングゲームをPCから最初のPlayStationに移植しようとしていたときの痛みを想像してください。



そもそもPS1には浮動小数点サポートがなかったため、コードを再コンパイルし、すべての浮動小数点値を固定小数点値に置き換えて移植を行いました。 そして、衝突の認識に至るまで、すべてがかなりうまくいきました。



ゲームのPCバージョンでは、レベルのジオメトリはうまく機能しましたが、浮動小数点と固定小数点の微視的な違いにより固定小数点値に変換すると、すべての縫い目、T字型ジョイントなどの問題が発生しました。 この困難はそれ自体を感じさせました：メインキャラクター（Dampと名付けられた）は単にこれらの小さな穴を通ってレベルの下の空所に落ちました。



Dampが失敗しないようにジオメトリを調整することで見つかったすべての穴を修正しました。 しかし、テストのためにゲームが出版社に送られたとき、彼は突然「世界中で失敗する」という多くのエラーを私たちに知らせました。 毎日、Dampが通り抜けることができる穴の新しいリストがありました。 それらを削除し、ジオメトリを修正し、翌日には他の場所が12個あることを通知されました。 これは数日間続いた。 出版社のテスト部門は1人の従業員を雇いました。従業員は1日10時間世界中を飛び回り、陥る場所を見つけることだけでした。



問題は、ジオメトリが悪いことでした。 密でシームレスではありませんでした。 PCには十分でしたが、固定小数点演算が問題を大幅に複雑化したPS1には不十分でした。 理想的な解決策は、ジオメトリを修正してシームレスにすることです。



ただし、これは時間のかかるタスクであり、限られたリソースでは時間どおりに完了できなかったため、テスト部門に頼って問題領域を探しました。



この場合の問題は、彼らが常にそのような場所を見つけたことでした。 毎日がさらに痛みをもたらしました。 毎日-古い「バグ」の新しいバリエーション。 終わらないように見えました。



最後に、それは私たちに思いを：せました：本当の問題は幾何学の穴にありません。 問題は、湿気がこれらの穴に落ちることです。 これを実現して、次のような非常に迅速かつ簡単な修正を書くことができました。

 IF (Damp   ()) THEN  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、コードはそれほど複雑ではありませんでした（リスト2を参照）。



リスト2：私と私のパッチ

 damp_old = damp_loc; move_damp(); if (NoCollision()) { damp_loc = damp_old;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

千のバグが一挙に修正されました。 さて、レベルを通って落ちて穴を通り抜けるのではなく、Dampは単にわずかにひきつりました。 私たちは苦しみの原因を突き止め、「これをやる」ことをやめました。 出版社はジャンパーテスターを解雇し、ゲームはリリースされました。



つまり、しばらくしてからリリースされます。 「if A == bad then not a」アプローチの成功に触発され、このツールを使用してさらにいくつかのバグにパッチを当てました。 それらのほとんどすべてが衝突認識コードに関連付けられていました。 開発の終わりに向かって、エラーはますます具体的になり、修正は「any_this_this_actionを実行しない」ようになりました（リスト3を参照：これはゲームに残っている実際のコードです）。



リスト3：私と私のパッチ

 if (damp_aliencoll != old_aliencoll && strcmpi("X4DOOR",damp_aliencoll->enemy->ename)==0 && StartArena == 6 && damp_loc.y<13370) { damp_loc.y = damp_old.y; //    damp'   . ( x  y) damp_loc.x = damp_old.x; damp_aliencoll = NULL; //    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは何をしますか？ 問題は、Dampが特定のレベルおよび特定の場所で特定のタイプのドアに触れたときに発生し、根本原因を修正する代わりに、ドアに触れたときにDampがそこから離れて何も起こらなかったふりをするようにしました。 問題は解決しました。



振り返ってみると、このコードは非常に恐ろしいものです。 彼はエラーを修正しましたが、修正しませんでした。 残念ながら、実際のソリューションは、PS1計算の機能を考慮して、ゲーム全体のジオメトリと衝突認識システムを変更することです。 当初から、スケジュールは非常にアグレッシブだったので、私たちには常に終わりが近づいているように思えました。 当然のことながら、このような状況では、問題に対する複雑で費用のかかるソリューションよりも、クイックパッチの方が常に有利でした。



しかし、すべてがそれほどスムーズに行きませんでした。 数百のパッチが必要でしたが、パッチ自体が問題の原因になり、非常に特殊なケースでパッチの動作を変更するには、さらにパッチを追加する必要がありました。 新しいエラーが発生し、再びパッチでそれらを打ち負かしました。 結局、私は勝ちましたが、代価は数か月間ゲームをリリースするのが遅れたこと、そしてこれらすべての月の毎日の14時間の仕事でした。



この経験により、パッチに立ち向かうことができました。 今では、簡単で一見安全なパッチを使用しても、常にエラーの原因を突き止めようとします。 コードを健全にしたい。 あなたが医者に行き、「私がこれを好きになると私を傷つけます」と言うとき、あなたは彼が痛みの原因を見つけてそれを治すことを期待します。 痛みは、コードエラーのように、もっと深刻な何かの症状になる可能性があります。 道徳：医師があなたを扱うべきであるようにあなたのコードを扱います。



-ミック・ウェスト

私は怒りに怒っています

私はかつてTHQ Relic Entertainmentのスタジオ、 The Outfitで働いていましたが、これは最初のXbox 360ゲームの1つとして思い出すことができます。PCエンジン（シングルスレッド）から始めて、約18か月で。 ゲームのリリースの約3か月前、彼女は360度で約5 FPSの速度で働いていました。 ゲームが深刻な最適化を必要とすることは明らかでした。



パフォーマンスを測定すると、処理速度と「PCスタイル」のコードに加えて、コンテンツの問題も多数あることがわかりました。 一部のモデルは詳細すぎ、シェーダーは高価すぎ、一部のレベルではキャラクターが多すぎます。



プログラマがエンジンのパフォーマンスを単純に「修正」することはできず、多くの人が慣れている作業テンプレートを変更する必要があることを100人のチームに納得させることは困難です。 彼らはゲームのパフォーマンスが誰にとっても問題であることを理解する必要があり、私はこれを冗談として示す最良の方法を思いつきました。



決定には約1時間かかりました。 仲間のプログラマーが私の顔の写真を4枚撮りました。私は幸せで、穏やかで、少し怒って、髪を引き裂きました。 写真を画面の隅に配置し、フレームレートに関連付けました。 ゲームが30fpsを超えるとき、私は幸せでした。20歳未満のとき、私は怒っていました。



これらの変更の後、FPS問題へのアプローチが完全に変更されました。「ああ、これはプログラマーの問題」ではなく「うーん、このモデルを使用すると、ニックは怒ります！ 少し最適化する方が良いでしょう。」 人々はその変化がフレームレートにどのように影響するかを常に見ていました。その結果、ゲームを30 fpsでリリースしました。



-ニック・ワンダース

アンチヒーロープログラミング

私は大学を卒業したばかりで、若くて素朴でした。 私たちは、最初のプロフェッショナルプロジェクトのベータ段階である90年代後半のPCゲームに移行しました。 多くの場合プロジェクトでそうであるように、エキサイティングなジェットコースターでした。 すべてのコンテンツの準備が整い、ゲームは見栄えがよかった。 しかし、1つの問題が見つかりました。使用可能なメモリの量に収まらないということです。



ほとんどのメモリはモデルとテクスチャで占められていたため、アーティストと私は、彼らが占有するボリュームをできるだけ減らすようにしました。 画像を縮小し、モデルを単純化し、テクスチャを絞りました。 時々アーティストは私たちを助け、時には彼らは全力で抵抗しました。



メガバイト単位でメガバイトを削減し、数日間の非常識なストレスの後、私たちはすでに何もすることが不可能になっています。 重要なコンテンツの一部を削減しましたが、メモリを解放することはできませんでした。 使い果たされ、現在使用されているメモリ量を測定しました。 最大許容量より1.5メガバイト多かった！



この時点で、「古き良き時代」の長年の開発経験を生き延びた、私たちのチームの最も経験豊富なプログラマーの一人は、問題を自分たちの手に委ねることに決めました。 彼は私を彼のオフィスに呼び、私たちは仕事を始めました。私は最初に、私の記憶を解放するためのもう一つの消耗マラソンとして発表しました。



代わりに、彼はソースファイルを開き、次の行を表示しました。

 static char buffer[1024*1024*2];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「見て？」彼は私に尋ねた。 そして、彼はワンクリックでそれを削除しました。 できた！



彼は恐らく私の目に恐怖を感じたので、開発の初期にこれらの2メガバイトのメモリを割り当てたと説明しました。 彼は自身の経験から、必要なメモリ量を維持することはほとんど不可能であり、このために多くのプロジェクトが失敗することを知っていました。 したがって、必要に応じて常に適切なメモリブロックを割り当てて解放します。



彼はオフィスを出て、必要なメモリ量を減らしたと発表し、誰もがプロジェクトのヒーローとして彼を称えました。



そのような「野barな」アプローチで当時どんなにショックを受けたとしても、今では完全にサポートしていることを認めなければなりません。 これまでのところ、私はそれを使用できるような考え方に達していませんが、困難な状況にあるとき、「雨の日のために」少しの記憶を持つことは決して無駄ではないことがわかります。 時間と経験が私たちの見解をどのように変えるかは興味深いです。



-ノエル・ロピス