プログラムのバグを発見

vol 2.15からずっと存在していたバグですが、発生頻度がかなり少ないのと私の環境では再現できなかったのでずっと原因不明のまま、もしかしたら個々の環境に起因するバグなのでは…と思っていました。

幻の未確認生物「UMA」、私にとってそんな存在だったかもしれません。

今回、実ボクユーザーであり受験生のゆっけ氏らにバグが発生した試合のリプレイデータを提出していただき、掲示板で話題になったのがキッカケとなりバグに対しての再調査が始まりました。

実ボクの開発も一段落、ちょうど仕事も二日間空いていたタイミングだったので、朝から本腰を入れて作業できたのは幸運だったかもしれません。

原因とは遠い場所からのスタートでしたが、確実にバグが内包されたデータが手元にあるのは心強かったです。
更に自分の中でバグ発見に向けたこれまでにない仕組みを構築でき、原因箇所の特定に向けてジワジワと迫っていく様はある意味その作業自体がゲームのようでした。

膨大な文章、文字列の中にたくさんのストッパーを設置して、ゆっけvsUMEのスパーを5倍速再生。正常動作した箇所からはストッパーを撤去していき、徐々に原因へと接近していきます。結果、7Rのある一点のフレームに辿り着きました。ガードキーの数値が0になる時と1024になる時がある！

ここからはなぜここで意図せず分岐されてしまうのか、プログラミングの中身の調査である。チェックすべき変数をタイトルバーに表示させながらリアルタイムで確認すると同時に異常値の場合は警告ダイアログが出るように罠をあちこちに設置して目を凝らす。

バグが発生するのが7Rとやや終盤だったので、5倍速とはいえさすがに長い。発生タイミングを見落としてしまうとまた最初から再生のやり直しなので気が抜けない時間が続きました。何度も再生したので途中からは彼らのスパーの動きを完全に暗記しちゃいましたね。（と同時に5倍速でもけっこうスパー成立するんじゃないか？とも）

やがて怪しい変数がジャブの連射動作に関する変数に絞られ、私の環境で発生しなかったことに納得が感じられる。私のジャブはスローテンポだからだ。UME氏というスパ天史上トップクラスの高速ジャブの使い手、そしてそれを引き出した若きゆっけ氏のボクシングに感謝、感謝である。

しかし、絞られた結果、怪しいのがジャブだった事実に私は気が遠くなってしまった。ジャブのプログラミング領域は他のパンチの領域と比べると膨大、あまりに膨大。洞窟の狭い通路を這って進んでいったら、広大な地下湖に辿り着いてしまったような気分でした。

この時点で集中力が限界に近づきつつあるのを感じ、こっから作業の能率が落ちていくかも知れない、下手すれば今回も原因に辿り着けないのかもしれない、と気弱になってしまいました。

こんな時、若い頃なら「根性だ！ もっと集中だ！」と思ったかもしれませんが、長く開発作業をしてきた中でスピードよりも確実な作業が大事だとわかってきたので、深呼吸をして今後のプランを練る。

疲れて短期的な記憶能力が低下すると同じことを繰り返したり、自分が何の作業をしているかさえあやふやになってしまう。こんな時こそ確実な記憶「メモ」をこれまでになくしっかりとって、多少ペースが落ちても同じことを繰り返さないように気をつけて牛歩大歓迎で進んでいくぞ！

詳細なメモをとったことで、仮に眠ってしまったとしても作業の途中経過を絶対に忘れない、という安心感が生まれた。妻が入れてくれたコーヒーもナ～イス！ タイミングだった。

そして、唐突にその時が訪れる。

「あ、あぁーーっ！！ ここだ！」

iが正しいのにoになっていた変数名の誤記を発見、思わず大声が漏れてしまい家族をビックリさせてしまいました。椅子から立ち上がりガッツポーズ、もうすぐバグ探しから開放されるかと思うと興奮してしまいました。（この時は散らばった罠の撤去に苦労するとはまったく思いませんでした）

誤りが見つかって本当に良かった…。
なんだかつかえが取れたようなスッキリした気分です。

毎回毎回プログラムを開いて追加修正して保存、閉じる。
こういった作業をもう何千回と繰り返している中でどこかに一文字だけ間違いがあるんじゃないか…と不安になったりします。

でも幸せなことに実ボクには大勢のユーザーがいて、日々プレイしまくってくれています。
それをテストプレイといったら怒られそうですが、ひとりっきりでチマチマ作っている状況と比べれば格段に不具合を発見できる可能性は高い環境だな、開発者として幸せだな、と思います。

ありがたい…！
ホントにありがとーーーーうっ！