PETAMPER【PART74】~デバッグ作業~

LINEで送る
Pocket

前回に引き続き、出来る限り軽量化を進めつつ同時にデバッグ作業も行っていきます。

74001

今までも定期的にAndroidの実機で確認作業は行ってきましたが、それはあくまで実装した箇所の「確認」でした。

デバッグ作業というのは「意図的にバグ(不具合)を起こすようなプレイをして不具合を見つけ、修正する」ものになります。【意図的に】というのがポイントです。

1回見つけてもそれでOKというわけではなく、あらゆる角度から検証して「こういう手順を踏むと100%このバグが起きる」と断言できるまで条件を絞り込みます。

 

目次

デバッグに関する色々な話

ちょっと脱線しますが、この機会にデバッグについての話を少々。

 

プロの世界のデバッグ

プロの世界でも開発の中盤~終盤にかけてデバッグを行います。大きな会社ならQA(Quality Assurance)部門があってそこでデバッグしたり、小さい会社ならプランナーやデザイナーもデバッグをしたり、開発終盤だけデバッガーのアルバイトを雇ったりします。デバッグ専門の仕事を請け負う会社なんてのもあるので、そこにデバッグを依頼することもあります。最近のゲームは大抵リリース後にアップデートでバグ修正が出来るので、昔よりも重要度が下がってきている気もしますが。

あと、バグには全てランク(優先度)がつけられます。優先度の高い深刻なバグ(ハングしたり、ゲームが進行不可になったり)は必ず直しますが、それ以外のバグは優先度と納期との兼ね合いで「仕様」になることがあります。(100%バグを取り切ることはほぼないと思います)

普通にゲームをしていてバグを見つけることもありますが、そういうバグは大体開発者も把握しています。大抵の場合は「分かっているけど(時間的に)直せなかった」というパターンだと思います。開発者としては残したバグというのはやっぱり悔しいので、次ではそうならないよう努力を続けるわけですけれども。一方でゲームにバグを残してでも、〆切(納期)というのは厳格に守られなければいけないものなのです。

 

デバッグにも上手・下手がある

同じようにデバッグをしていても、バグを見つけられる人・見つけられない人がいます。その違いを私なりに考えてみると、デバッグが上手い人にはいくつかの特徴があると思います。

①色々なゲームをプレイして細かい所まで見ている
過去のゲームで起きたバグを経験していて「このゲームでも同じことが起きるんじゃないか?」と考え検証してバグを発見したり、問題ない場所と違和感のある場所を敏感に感じ取れたりと、ゲームをプレイしている経験が多い人ほど、バグを見つける洞察力が養われている傾向が強いと思います。逆にあんまりゲームをしない人はバグを見つけるのが苦手です。そもそもゲームの常識を知らないので、ヒドイ人は明らかなバグが見えているのに、それがバグだと認識出来ないことすらあります。

②プログラムの知識がある
「この処理はこういうプログラムで作っているのかな?じゃ、ここに抜けがあるかも」と、プログラマーの立場で想像してデバッグが出来ると、狙ったようにピンポイントでバグを起こすことも出来ます。バグを検証して再現する条件を見つけるのも早いです。例えデバッガーでもプログラムの知識は持っていて損はないです。

③ゲーム以外の知識が豊富
例えば戦国時代や中世の時代など、歴史物のゲームの場合は時代考証というのがあります。この時代の人はこんな言葉は使わないとか、この時代にこれは存在しないとか、歴史に詳しければ他の人が気付かないものに気付くことが出来ます。あとは、日本語(国語)がちゃんと出来ているかどうか。言葉の使い方が間違っている、漢字が違う、送り仮名が違う、誤字や脱字があるか、などなど。アドベンチャーゲームなどの文章の多いゲームのデバッグなどをする時には必須でしょう。ゲームを作るためには学校の勉強もちゃんとしましょう、ということですね。

④観察力がある
「ここでバグは起きないだろう」などという先入観を持たず、フラットな気持ちでゲームをじっくり見れる人は、誰も気付かないようなバグを見つけることが多いです。1フレームだけキャラのポリゴンが欠けている、とか。よくバグを見つける人は、よくゲームを見ている人です。

⑤忍耐力がある
ずっと同じゲームをプレイして、時には同じことを永遠と「集中力を切らさずに」繰り返さなければいけません。これはどんなにゲームが好きな人でも結構な忍耐力が必要です。飽きっぽい人、すぐ居眠りをする人は向いていません。

⑥神(悪魔)の手を持っている
今まで何事もなく動いていたのに、その人がコントローラを持った瞬間ハングする、なんてことが稀に起こります。しかも大概再現性の低い原因不明なバグです。これはもはや才能の一種かも知れません。きっとバグの神様に愛されているのでしょう。プログラマーには嫌われてるかも知れませんが。

 

あと、デバッグの上手い下手ではないですが、デバッガーの能力としては「伝達力」が必要です。バグを見つけたら必ずそれを文章なり、口頭なりで報告しなければいけません。「どういうシーンで、何を、どうすると、どうなる」といったことをキチンと相手に伝えられる文章力やコミュニケーション能力が必要です。たまに新人のデバッガーで、バグを見つけるやいなや「やったー、バグ見つけたー」と言って喜びながらプログラマーのところに報告に行って怒られちゃう人がいます。デバッガーからすれば仕事の成果ですから嬉しいかも知れませんが、割とピリピリムードなことが多い開発の終盤、プログラマーからすればバグ報告は仕事が増える「嫌なこと」です。それを嬉しがっている空気の読めない人は当然怒られます。ちゃんと相手の様子を伺ってからモノを伝えるということも大切です。

 

いざ、デバッグ

さて、今回のような個人での開発となるとデバッグも大変です。何せ「これでOK」と思いながら要素を実装しているわけですから、バグが起こるとは考えていません。まずはフラットな視点でデバッグをするために、食事をとったり本を読んだりして、少し時間を置いて気持ちを切り替えてから始めるようにしています。

デバッグの方法も、とにかく色んなことを試します。

ボタンを同時押ししてみたり、連打してみたり、怪しげなタイミングで瞬間的に押してみたり、何度も死んでみたり、色んな場所で死んでみたり、長時間放置してみたり…。

外部要因的なものも交えてやります。大量のアプリを起動した状態で遊んでみたり、他のアプリのダウンロード中に遊んだり、ゲーム起動中に電源を切ってみたり…。

1つ見つけたらすぐ直すのではなく、バグはリストにして優先順位をつけてまとめておきます。しばらくデバッグをしたら、今度は優先順位の高いモノから修正をして確認するようにします。手当たり次第にバグとりをしていたのでは永遠に終わりませんので。すでに見つけているバグの中には「仕様」として黙認しているものもチラホラあります。

同時進行で軽量化もしているので、データを差し替えたり削除したり設定を変えたりといったこともしています。その都度、変更した箇所を重点的に改めてデバッグもしていきます。

あとは、何人かにお願いして、テストプレイと称してデバッグもお願いしています。本当助かります。

こんな感じで、リリースまで(リリース後も)デバッグは継続して続けていきます。

 

スポンサーリンク

スポンサーリンク

LINEで送る
Pocket