第5回 終わりよければすべてよし

前回まででザックリとしたゲーム製作の流れを説明させて頂きましたが、ゲーム製作はこれで終わりではなく、ここからが本番とも言うべき恐ろしい時期に突入します。

出来上がってきたゲームが正しく動くか、仕様どおりになっているか、きちんとセーブした後にロードができるか、優しすぎたり、むずかしすぎたりしないか、はたまたバランスを崩すような不具合などがないかをチェックする「デバッグ作業」がそれにあたります。

簡単に言うと「ゲームを遊んでみておかしなところが無いか確認する」という作業なのですが、ただ普通に遊んでいるだけだとチェックになりませんし、「ゲームを遊んでお金が貰える楽な仕事」と勘違いされそうなので具体的な作業内容を。

1.街の中にある店の中に入ったらすぐに外に出る。外に出たらまたすぐに店の中に入る。……以上を一時間程度つづける。

2.メニューボタンを押してメニューを出すと同時にキャンセルボタンを連打する。メニューが閉じたら再度メニューボタンを押す。……以上を一時間程度つづける。

3.セーブしたら電源を切って一度ゲームを終了した後、再度ゲームを立ち上げてさきほどセーブした場所から再スタートできるかチェックする。……以上をありとあらゆる場所で試す。

などなど。

これ、ほんの一部の作業です。お店は一軒や二軒だったらたいした作業ではないかもしれませんが、お店にかぎらず街の出入り、ダンジョンと呼ばれる洞窟の出入りや階段移動などについても同様にチェックすることになりますし、メニューを出すタイミングは下手したらゲーム中すべての場面なので、チェックリストを作って「ここのチェックは終わったからつぎ……」という感じで作業しなければわけが分からなくなります。

「こんなことする必要あるの?」

あるんです。このチェックが適当だと「せっかくのラスボス戦でメニューを開いたら画面が止まった」とか「新しい武器を手に入れたから装備しようと思ったらメニューが開かない」といったことが起こる可能性があるんです。とはいえそういったことはまれなんですけどね。そんな怪しい挙動の場合、作っている途中で発覚するのでデバッグ前に修正されているはずです。ですが、それがたまたま発覚しなかった場合、大問題となるのでチェックを行なうとお考え下さい。

メニューチェックなどは実際には全画面でやる意味は弱いのですが、「新しい武器が手に入ったらメニューの中に【New】マークが付く」という仕様の場合だと、その【New】マークが正しく出ているかなどのチェックも必要となります。当然、【New】マークが付いてなければデバッグシート(※1)に不具合内容を記載してレポートとして上げます。

プログラマーさんやデザイナーさん、企画屋は上がってきたデバッグレポートを確認し、同じことを再現してみて問題だと判断すれば修正を行います。そうでなければ? それは後述します。

やらないことをやる

デバッグ作業は簡単に言うと上記のような「あらゆる項目、あらゆる場所での動作チェック」なのですが、基本的な挙動やゲームスタートからゲームクリア(ゲームオーバー)までなら問題無い状態というのはデバッグ作業の入り口で、そこまで動く状態になってからが本番。

ゲームは発売されたらどういう遊びかたをするのかは買ってくれたお客さんしだい。1万本売れたら1万人がそれぞれの遊びかたで遊びますので、まっすぐ進む人もいれば寄り道ばっかりする人もいる。つまり……「どんなことをされるかわからない」んです。

そのため、どんな遊びかたをされても大丈夫なように普段はやらない特殊なことをチェックしなければなりません。

たとえば、某有名オーバーオールおじさんのゲームを例にすると……。

1.ゴール直前の柱にタイムアップと同時に飛びつく(同時に、という部分がミソ)。
2.大きくなるアイテムを取ると同時に敵にぶつかる(こちらも同様)。
3.自動セーブ中にゲーム機をリセット(本来ならばやっちゃダメだけどあえてやる)。

「こんなことやる必要ないだろう」って? いえいえ。たとえば1のゴールと同時にタイムアップですが、ゲーム中にお母さんから用事を言いつけられたお子さんがいるとします。ゴール直前まで行っていたゲームを一時停止し、用事をすませようとします(いい子だ)。用事が終わってゲームを再開しようと思ったら一時停止したつもりのゲームが止まっていなかった。残りタイムは1秒! あせってゴール! 残りタイム0と同時にクリア……のはずが、ゲームが止まってしまった。

「お母さんのせいだ!」

となったらイヤですよね。お母さんは簡単な用事をお願いしただけなのに怒られるわ、お子さんはせっかくクリアできると思ったところがやり直しだわでちょっとした家庭内不和が起きる。そんなことが無いようにしなければならないのです(その前に一時停止できてない方が問題じゃないのかな→デバッグレポートに記載しませう)。

しょうがないので仕様です

直せる不具合は直さなければなりませんし、さほど重要でも無い不具合とは呼べないような報告でも簡単に直せるのであれば直します。

ただ、直すといろいろなところに影響があり、その影響の度合いをチェックする時間が無いといった場合も出てきます。そういったときはどうするか。「ごめんなさい!」します。つまり、直さない。

えええ~!?

という声が聞こえて来そうですが、事実です。たまにあります。本当にごくたまに。ほんとですよ。信じて。

ただし、そういったことは「ものすごい特殊な操作で特定の敵に対してしか起きない」とか「ゲームを一度クリアしたあとのオマケモードでのみ起きる」といったきわめてレアケースで、なおかつゲームが止まるといった致命的な問題ではない場合にかぎります。ゲームが停止したりデータが壊れてしまうような致命的な問題を抱えたまま発売することはありません。絶対に。無いはずです。たぶん無いと思います……。

ただ、最近はネットワーク普及の影響のせいかちょっと事情が変わって来ており、発売後に不具合を直す「パッチ(※2)」と呼ばれるプログラムを配信することで逃げる場合があります。ゲームは完成品をメーカーさんに出したあと、製造→発売までに最低でも2~3週間程度の日数があります。そのあいだに完成品では直せなかった不具合を修正し、発売日にネットワークからそのプログラムをダウンロードしてもらって不具合が出ないようにすることが増えてきました。

この修正パッチ、私は大嫌いです。バグが分かっているのにそのまま完成品として納品する神経も分かりませんし、ネットワーク環境が無い人は修正パッチが受け取れません。今のご時勢、どこでも受け取れるだろうという考えもあるのかもしれませんが、受け取れない可能性がゼロでないかぎり、そんなモノはただの言い訳です。発売前にしっかりチェックし、発売日までに直せないのであれば仕様変更を行なうか、発売日を延ばしてでもいいので修正すべきです。どうせ後で問題になるのは分かっているのだから、最初から責任を持って対処すべきだと私は思います。

おっと……またもや愚痴っぽくなってしまいました。ダメですね、オッサンは愚痴っぽくなって。

基本的にはバグは直して発売するように開発者は努力しておりますし、メーカー側もチェックは可能なかぎり行なっています。ですが人のやることですのでチェック漏れがあったり、想定していない遊びかたで問題が起きる可能性もありますので、そのあたりはご了承頂ければと思います(誰に向けて発言してるのやら)。

長くなりましたね。今回はここまでとしましょうか。

※1……デバッグシート:開発者にとっては恐怖の紙。今はデジタルデータ、メールや専用のツールでレポートが来るのですが、昔は本当に紙に不具合内容が記載されてFAXで送られてきたり、郵送されていました。自分の担当箇所のデバッグシートが大量にあると凹みます。

※2……パッチ:ズボンなどが破けたとき、その場所の上にちがう布を当てて取りつくろうことがあり、それも「パッチ」と呼ばれます。内容的には同じで、それがデジタルデータになっただけです。見た目もよろしく無いので私は嫌い。デジタルデータでは見た目は関係無いけど私は嫌い。

(文・風来の企画屋)

このエントリーをはてなブックマークに追加

著者プロフィール

風来の企画屋ゲームプランナー
中古ファミコン屋店長からスタートし、プログラマーを経てゲーム企画屋に。ディレクターも頼まれればやるし、プロデューサー経験もあるが「やっぱり企画が面白い!」と企画に固執いているオッサン。来年発売のダライアスをPS4版でやろうかVita版でやろうか悩み中。