表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。
この作品には 〔残酷描写〕が含まれています。
苦手な方はご注意ください。

データ供養所

救世主ひとりに任せすぎ問題

作者: まい

 あくまでもフィクションでございます。


 フィクションなのです。


 フィクションであってほしいのです。

 ゲーム製作は日々進化している。


 より豊かな表現を求めて。


 より素晴らしい体験の為に。


 より楽しいゲームとは何か? を追い求めるために。





 ゲームの進化は止まらない。


 どうすればより良いゲームが(つく)れるか。


 その模索(もさく)探求(たんきゅう)により、止まらない……いや、止められないのだ。


 そしてそれは、ひとつの致命的な問題を同時に育てる事でもある。




 バグ。




 ゲームの世界に()まう害虫だ。


 思いがけない、変な動きで()()()と笑わせてくれる()()無害なバグもあれば、ゲームが止まってしまう深刻な問題に発展するバグまで。


 それはもう多種多様に存在している。



 (おおやけ)には不具合として発表される、ゲームの製作者が意図(いと)しないゲーム中での挙動(きょどう)を行う全般を指す言葉である。


 これがゲームの進化によって、狂暴化してきているのだ。




 バグの(エサ)情報(データ)である。


 特に、複雑に組み上げられたプログラムデータだ。


 様々なプログラムが幾つも同時に走り、プログラムが他のプログラムと衝突した時に発生する、処理しきれないデータが大好物なのだ。


 そしてゲームの進化と、プログラムの複雑化は切っても切れない関係だ。



 軽く大雑把に出すだけで、幾つものプログラムが並列して走っている。


 例えば三次元(3D)のゲームなら、こう。


 キャラクターのワイヤーフレーム(昔はポリゴンと呼ばれていた)を管理するプログラム

 キャラクターのワイヤーフレームにテクスチャ(つまり絵)を貼り付けるプログラム

 キャラクターの動く(モーション)プログラム

 コントローラー等による操作(コマンド)の命令を待ち続け、実行するプログラム

 背景のワイヤーフレームを管理するプログラム

 背景のワイヤーフレームにテクスチャを貼り付けるプログラム

 背景のギミック(動く部分)を管理するプログラム

 画面で光の強さを管理するプログラム

 光とキャラクターや背景にぶつかって発生する影を描写するプログラム

 キャラクターが何かにぶつかるかを検知するプログラム

 背景が何かにぶつかるかを検知するプログラム

 キャラクターが何かにぶつかったら、それによって受ける影響を行動に反映するプログラム

 画面上のあらゆるものに影響を与える物理計算プログラム

 他にも多数


 パッと挙げただけでもこれで、もっともっと沢山のプログラムが並列して走っている。


 プログラムのミスが無く、完璧にプログラム言語から機械言語へ翻訳(コンパイル)出来たとしても、バグは起きる。



 更にプログラムが複雑化するなら当然、ゲームが要求するデータ量は(ふく)らんでいく。


 それはつまり、バグの温床に他ならない。





 これはどうしても回避できない問題となる。


 そこで出てくるのが、虫取り(デバッグ)作業。


 これはゲームのバグを見付けて、バグが発生する原因を突き止め、原因を修正し(けし)て正常な状態にしようとする行為。


 これでバグは消せるのだ。



~~~~~~



 その作業で、めでたしめでたし とはいかなかった。


 なぜなら、デバッグとは地獄の作業であるからだ。



 昔は単純なプログラムなので、バグは完全に取り除けた。


 現代でも色々な工夫はしている。


 ゲームシステムの簡略化。


 ゲーム製作支援ソフト(エンジン)による自動プログラム。


 他にも。


 だが最近はそんな工夫だけでは、どうにもならなくなってきた。


 それが地獄の作業たる所以(ゆえん)である。




 バグ1つを取り除くと、他の場所にバグが発生する。




 これが繰り返して起きるので、いたちごっこが何時(いつ)までも終わらないから地獄なのだ。


 そんな馬鹿なと笑いたければ笑えば良い。


 実際にそうなるのだが、知らない奴は平和で(うらや)ましい。


 今の時代、バグの無いゲームなど無いと言っても良いほどだ。



 だが、それでも製作が狙ったゲームバランスを壊すバグや、ゲームが進められなくなるバグ、急に一時停止(フリーズ)したり完全停止(ハングアップ)したりするバグ等の、致命的なものだけは何とか取り除きたいと努力しているのがゲーム会社である。


 その努力の1つとして、デバッグ専門の会社にデバッグ作業を依頼する手段がある。


 沢山のデバッグ要員(デバッガー)で人海戦術的にバグを見付ける、実に頼もしい専門の会社だ。


 見付けたバグをまとめてリスト化して、依頼主へ報告するまでがお仕事。


 ゲーム製作がそのリストを受け取り、修正して、再び問題(バグ)が無いかの確認をデバッグ専門の会社へ依頼する。


 それの繰り返し。




 これでデバッグの問題は解決したか?


 それはNOである。


 デバッグ専門の会社はそれほど多くない。


 デバッグ作業には膨大(ぼうだい)な時間と労力が必要だ。


 つまり、後がつかえる。


 つまり、手が足りていない。


 




 デバッグ作業をしていないゲームなど、どこに致命的なバグを抱えているか分からない怖さから発売できない。


 デバッグを依頼しようにも、専門の会社が手一杯。


 ゲーム製作もデバッグ作業は出来るが、そればかりしていてはゲームが発売されず、金が得られない。


 だからと言ってデバッグしてないゲームは発売できない。



 最悪のループがゲーム業界を襲った。



~~~~~~



 その最悪のループは、意外な所から解決手段が転がり込んできた。



 天才デバッガー とされる男が世に出てきたのだ。



 彼の作業量は凄まじく、1人で5千人分の作業がこなせる。


 しかも1日で全デバッグ作業をこなせると言う怪物だった。


 最初は誰も信じなかったが、使ってみて分かる異常性。


 彼自身の経験と(かん)により、次々と挙げられて行くバグにゲーム製作の者達は唖然(あぜん)


 仕事が早く、デバッグの期間が大きく短縮出来たのはゲーム開発費(よさん)に大変よろしく、ゲームの製作からすれば一転してそれはもうニッコリであった。


 本当に天才デバッガーであると、ゲーム業界の救世主であると、そのデバッガーを見た人は口を揃えて言う。



~~~~~~



 天才デバッガーが現れてしばらく。


 この間のゲーム業界は平和で、ゲームの購入者から送られてくるバグ報告はめっきり減り、良いことばかり起こっていた様にも思われる。


 が、見えない危機はすぐそこまで迫ってきていた。




 きっかけは新しいゲーム製作支援ソフト(エンジン)で創られたゲームが、世に出回り始めた瞬間だった。


 天才デバッガーによって、バグが些細(ささい)な、極めて軽微なバグが少数しか報告されていなかったのが、急に増えたのだ。



 そう。 ゲームのプログラムのぶつかり方がゲームエンジンの仕様変更によって一緒に変わり、天才デバッガーの感性とズレが起きてしまう悲劇が起きたのが原因。


 これによりゲーム業界は天才デバッガーに依存しきっていた事でデバッグ体制に不都合か生じた。


 原因が分かった後に慌てて対応策を(ほどこ)すも、それは泥縄(どろなわ)


 既に問屋(とんや)小売店(こうりてん)へ運び込まれ、発売日を待つだけのゲームも多数あった。


 これを急遽(きゅうきょ)販売停止にすれば、ゲーム会社としての信頼と信用を(ひど)く落とし、今回のみならず(なち)の販売本数にまで影響が出るだろう。


 だからと言ってバグが多発するゲームを売りに出したと知られれば、それもまた悪影響となる。


 発売日当日(デイワン)修正データ(パッチ)を配信しようにも、パッチを作る時間が足りない。


 何もかもが駄目駄目(だめだめ)でグダグダ。


 それでもゲームとして、ちゃんと遊べるよう創れねばそれは、ゲームにあらず。


 ゲームの製作としてのプライドから、急に訪れた終わりの無い地獄の試練に、立ち向かう以外の選択肢は無かった。





 ゲーム業界の(デバッグ作業の)救世主に頼りきった運営方法で、楽をしていた者達への罰だろうか?


 救世主はやがて業界を(むしば)む毒となり、旧態依然としたどん詰まりへと立ち返った。


 救世主にも頼るが、それとは別の新規デバッグ体制を組み立てるツナギとして運用していれば、また違った未来が有ったのかも知れない。

 以上。


 救世主が凄いからと頼りきったら、後々(のちのち)痛い目見るぞ?


 を業界の悲しい実態風に書いてみただけです。



~~~~~~



 なお聞きかじりで受け売りですが、現実のデバッグ現場は天才がいたところで1日じゃあ終わりません。


 デバッグはバグを見付けるのもお仕事ですが、ゲームが()()()()()()のを確認する作業でもあります。


 バグを全部みーつけた! 終わり!

 じゃないんですよね。

 そもそもどれだけバグがあるのかも分からない訳で。

 いくつバグが発生しています。 なんて表示されるのはゲーム会社を運営するシミュレーションゲーム位ですわ。



 本当のデバッグ作業は、今までの業界の蓄積(ちくせき)により、どんな時にバグが起きやすいかって場面の想定が出来るようになったらしいです。


 なので、そのバグりやすい所リストをもらって、大人数で範囲分担をしながらリストを消化するやり方だそうな。


 大昔は(やと)ったデバッガーに気ままにテストプレイさせて、見付けたバグを報告って形だったらしいけど。



 んでそのバグチェックリストが地獄。


 通行止めにしている道の、すり抜け(当たり判定(コリジョン)未設定)ポイントが無いか調べるとか。


 □□する時にフラグの○○が立っているか立っていないか、とか。


 特定の△△を持っている時に、どのタイミングでムービー(非操作で勝手に動くイベントの)キャンセルをする~とか。


 様々に条件を変えて同じ会話やイベントを繰り返し、進行不能になる条件やフリーズする条件を探すために、何度も何度も見るとか。


 とにかく苦行みたいなんですよ。



 そんなの知らん。 ゲームにバグは不要、完全に取り除いてから発売しろ?


 それができる時代はもう来ませんて。 プレイ中に発生したバグを、自動で修正してくれる便利な機能が実装されない限り。


 だからゲームの製作としては、とにかく酷いバグさえ無ければ、OKの精神らしい。

 作中に書いた、バグはどうやっても消せないの話になるけど、複雑化するプログラムのどこかに必ずバグが発生するモンなのです。


 上(経営者)の決めた開発期間とか予算とか、そういった事情も絡んできますし、バグを取りきれる環境は何処(どこ)にもありません。





 もし面白いバグがネットで公表されて話題になって、買ってくれるお客が増えたらなぁ……なんて下心も有るかもだけど。

評価をするにはログインしてください。
この作品をシェア
Twitter LINEで送る
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
感想はまだ書かれていません。
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。

この作品はリンクフリーです。ご自由にリンク(紹介)してください。
この作品はスマートフォン対応です。スマートフォンかパソコンかを自動で判別し、適切なページを表示します。

↑ページトップへ