デバッカーに応募しました『LIFE IS PARADISE ODYSSEY』【本日発売】

↑紹介ページはこちら

　先月、デバッカー募集を見て応募して。約一ヶ月間ずっとデバッグしていたが、遂に発売。めでたい。細部にまでイベントが詰まったライフゲームなので是非触ってみて欲しい。

　自分は某アーケード格闘ゲームのデバッグにしか参加したことしかない（そのゲームのアーケード版のスタッフロールに載ってる）。なのでRPG系のデバッグは初めてだったものだから、勝手がわからずにけっこう右往左往してしまった部分がある。その辺は反省点だ。

　デバッグをしていて学んだのは、バグというのは無秩序に発生するわけではないということだ。ほぼ必ず他の仕様と競合して起こる。それ以外には、関連付けのミスとか範囲設定ミスとか、終了命令の入れ忘れとか。一目見て総合的に考えれば解るものが殆どである。それを予想して実際に動かしてみて、本当に動くかどうかを確認する。それがデバッグというものなのかな、となんとなくだけれど思った。

　一つのバグを見つければ、それと同じ動作が起こりそうな場所というのがだいたい見えてくる。だからそこで同じことをすれば、同じバグが起こったりする。あと修正内容を見て、ならこういう動作をすれば修正されてない部分が見えるだろうな、と考えてやってみるとやっぱりそうなったり。そういうのを実際に体験すると、ゲームというのはとても合理的に作られているのだな、と実感できてとても楽しくなった。

　逆に一番大変なのは個別イベントである。他のイベントや仕様と競合する部分も多いし、そのくせそれぞれが独立してるから総当たりで探らないとバグが出てこない。だからとにかく時間がかかる。修正してもその修正で新しいバグが出たりと、なかなか手ごわい相手だった。

　画面内の表示データはレイヤーで分けられていると聞くと、なんか画像みたいだな、と知識の連結が起きたり。ゲーム内時間での明るさ変更はレイヤーの明度が違うのが差し込まれてくるのかな、とか。建物内は転移できないし、明度も変わらない。そのはずなのに、明度が変わる建物がある。じゃあ転移してみよう。転移できた。ならこの建物は室内属性が設定し忘れているんだな、などなど。ゲームの仕組みには興味が尽きない。

　スキルの脱出にバグがある時は面白かった。何故こういう挙動になるのか、というのを一つ一つ吟味していくと。どうやら「ダンジョン判定、施設判定になっていない建物で脱出を使うと、直前に入ったダンジョンや施設を参照して脱出する」というのが分かった時。思わずガッツポーズしたりした。難解な謎を解いた時は、やはり楽しい。

　設定に合ってないシナリオ上の演出を一つ一つ指摘して整えていくのも大事なことだと学んだ。そのおかげで、ある演出がとびきりの効果を持った演出に昇華された。あれは自分でも重箱の隅すぎるかな、と思っていたけれど。最後の最後で結果を出してくれたので、指摘してよかったと思った。プレイしてくれた人は、どれがそうなのか予想してみて欲しい。商品は別に無いけれど。

　一番頻発するのはキャラクターが分身するバグだったような気がする。イベントは基本的に標準マップを参照して起こるようなので、そのマップにイベントフラグが既に立っていた場合。基本マップ上にいつもはいないキャラがその時だけ配置されていたりする。なので、イベント中、そのイベントに関係ないキャラが配置されていたり。配置されているキャラと一緒に別の場所で固定イベントを起こして該当のマップを参照するイベントを発動させた場合、イベントフラグが並列することによりそのキャラがマップ上に二人存在するという現象などが起こる。私はこれを分身と呼んでいた。でも分裂かもしれない。

　後半は他のデバッカーさんと調べてるところが被るといけないから、今日自分はどこそこをデバッグします、とか宣言したり（個人的な心がけなので、他の人には宣言する理由は説明しなかったが）、修正報告や他の人の報告を待ったり（他の人がやってそうなところは自分もやるとタスクの無駄だから避けた）。何か起こった時は一旦手を止め、報告してから他の部分をデバッグしたり（修正が終わってから改めてデバッグしたほうが手間が減る）。ホウレンソウを徹底して、二度手間や無意味な作業を徹底して対策した。眠かったけど修正後の挙動にバグがあったらいけないし、手を止めさせるのも時間もったいないかな、と思ったりしたからわりと深夜まで頑張ったりもした。

　ゲームというのは全てのマップが部屋のようなものであり、それを正しくつなげることでゲームとしての形にしていく。その部屋の中にはイベントや敵、味方などキャラクターが配置されていて、それらも同じ部屋をたくさん作り、中身を変えて進行度によって別の部屋に入れるようにつなげられている。そのつながりにミスがあると、動作不良として表に出てくる。私の中のゲームというものの骨組みは、このデバッグを通してこんな感じになっていった。

　デバッグとは、「ゲームを本来の仕様に近づけていく作業」である。そのゲームにおける動作やイベントなどを、最終的にどういう動作をすれば正常であるかを考えながら、正常に動作しない可能性のある行動をしらみつぶしで試していく。その観点で考えると、「このゲームが販売されるためには、どのイベント、どの動作がデバッグされればいいのか」を考えてイベント数なんかの全体数を出すことができる。そうすれば、それらを日数で割り振っていけば、何日後にデバッグが完了するかもだいたい分かる。

　しかし、こうやってブルドーザー方式でデバッグをしていると、どうしてもフルコンプ方面のデバッグはできない。決めた一か所を順番に正常にしていくので、どうしても時間が足りなくなるのだ。だから今回、もう一人の方と製作者の方が博物館コンプ＋コンプ報酬の取得挙動＋取得アイテムの動作確認をしてくださったので本当に助かった。

　バグ探しより時間がかかったのは、修正箇所が正常動作しているかを確認する作業である。デバッグというのは、バグを探すだけじゃない。バグを修正した後に、正常動作をしているか確認して報告することで初めてデバッグとして完結する。投げっぱなしではいけないのだ。だから、作業量が単純に二倍以上になるから、めちゃくちゃ時間がかかる。直ってなかったらどういう風に直ってないのかまでレポートを上げる。文章では説明できない場合はセーブデータを提出する。修正版のファイルが上がるまで待たないといけないので、日にちもかかる。大変だ。

　更新されたパッケージをDLする時も注意しないといけない。DL中にゲームを起動してしまおうものなら、データがクラッシュしてセーブデータごとおじゃんになってしまう。一度それをやってしまって、デバッグ用データを一日がかりで作り直した。それからデバッグ用セーブデータを、ラベルをつけて保管するようにした。

　このデバッグで多くの得難い経験をさせていただき、たくさんの知識を学ばせてもらった。この場を借りて、改めてWLCソフトさんのユウコ氏にお礼を申し上げます。ありがとうございました。そして、一緒にデバッグしたばいおれんじさんもお疲れ様でした。

↓紹介ページはこちら