「全ファミ。」ブログ編

しょうゆさしからしょうゆが出なくする方法を5つ考えてください

ご意見をいただいたのと、単にツイッターをまとめるのも見づらく芸がないということで、ブログでまとめることにしました。原稿料が出ないとはいえ、21世紀ファミコンの連載移籍先ですしね、ちゃんとやらなければ。

---------------
ゲーム業界じゃないところで評価の取りまとめをしていたときの話です。製品評価とかデバッグというのは、新人さんに教えるのってけっこう難しいんですよ。感覚的なものといいますか、「ここらへんでバグが出るだろう」というのをつかんでもらいにくい。なので、わかりやすい例を挙げて説明したのがしょうゆさしの話なのでした。
ツイッターのほうでもいくつか方法が挙げられていましたが、ここで一覧を再掲。

1 しょうゆさしを水中/宇宙に持っていく
2 しょうゆを凍らせる
3 しょうゆをあらかじめ空にしておく
4 しょうゆを別の液体に変えておく
5 しょうゆさしの口をふさぐ
6 しょうゆさしに穴を開けておく
7 しょうゆさしの名前を変える

とまあ、こんな具合です。
これらの方法はいくつかのパターンに分かれます。

・環境を変える
・インプット(中身)を変える
・アウトプット(入れ物)を変える
・表現を変える

1番目は環境ですね。環境、つまりしょうゆさしを取り巻く環境を変えることで、しょうゆを出なくする。しょうゆさしを宇宙で使う人はそうそういないと思いますが、「しょうゆさしからしょうゆが出ない」というのは、製品評価の世界ではバグなんです。でも、そういう環境の変化を想定していないものは、仕様屋さんが仕様として「宇宙・水中では出ません」と決めてしまう
バグ出しの面白さってのは、プログラマーさんや仕様屋さんが考えていないところをつっつくところにあるんですね。そして、それを直させるところの楽しさ。しかし、せっかく出したバグに対して、「仕様を今から決めたので、それはバグじゃなくなりました。あしからず」と言われるのがいちばん面白くないんです。でも、「まあ仕様を付け加えさせたんだからいいじゃないか」と若い子には言うんですけどね。そして、こうも付け加えるんです。「宇宙・水中でしょうゆが出るシチュエーションを探そう」って。評価の世界はいたちごっこなのです。

2~4番目は中身の変更。しょうゆさしなんですから、中身がちゃんと出ないとしょうゆさしとしての存在が成り立ちませんからね。2番目の「しょうゆを凍らせる」のはけっこう大変そう。味噌も冷凍庫で凍らないですからねえ。まあそれはおいといて、もしかすると1の環境を変えるほうに含まれることも考えられます。環境での試験をやっているときに中身の試験も同時にやってしまうなんてのは、本当は駄目なんですよ。ま、試験の時間短縮になっていいってことでやらせちゃいますけど。
で、中身の変更で面白いのは4番目の「別の液体に変える」というやつ。確かにしょうゆが出てこないので不具合になりますわな。ただ、しょうゆさしでしたらフタをあけてしょうゆを入れ替えればいいんですけど、ソフトウェアの評価の場合は、「しょうゆ以外の液体がしょうゆさしに入ることはありえない。よって処置なしとする」という回答が普通にあるわけですよ。これは悔しい。なので、しょうゆ以外をいれる方法を見つけて、「こうすればしょうゆ以外が入りますよ。なので、ここにしょうゆが入らない対処をしてください」とやるわけです。ね、楽しげでしょ。やられるプログラマーさんや仕様屋さんはイライラするでしょうが、それがまたいいんです。
あと、面白いパターンとしては、ヤ○サしょうゆなら出てくるのにキッ○ーマンしょうゆだと出てこないというやつ。ソフトウェアの世界ではよくあります。しょうゆの構造がメーカーごとにちょっと違うんですね。その差異を考慮にいれていなかった故の不具合です。でも自家製しょうゆも出てこないんです! って訴えると、自家製しょうゆはユーザーの責任なので、そこまで面倒見ませんって言われてしまうんですよ。切ない話じゃないですか。

5、6番目はアウトプット(入れ物)に何かの変更を加える。しょうゆさしの口をふさぐってのは、使ってるユーザーが故意にやってるわけですよ。なので、仕様屋さんはそんなのしらねえよと言って終わりにしてしまうので、「こうすればユーザーが意図しないのに口がふさがれてしまいますよ」とやる。こういうのを、「不具合を寄せてくる」と私は呼んでました。不具合じゃないものを不具合にしてしまうテクニックですね。あんまりやりすぎると怒られます。でも、「しょうゆが出ないと困るのはユーザーで、最終的にはメーカーにその評判が跳ね返ってきますよ」と言うわけですよ。ソフトに言ってますけど、ようは脅しです。じゃあしょうがないっていうことで、仕様屋さんはプログラマーさんに「ユーザーが意図せずに口がふさがれる現象を対処するのに、どれだけの工数(直すための人数と時間)がかかるのか」とおもんばかる。で、工数が軽そうだから対処するか、っていう話になるわけです。
この工数ってのはお金も時間も人数もかかるってんで、大きな判断基準なんですね。不具合発見が後になればなるほど、この工数が大きくのしかかるんです。だから、バグ出しや評価では重そうな不具合から見つけるようにしていくのです。

7番目。例に挙げた「しょうゆさしの名前を変える」のだと屁理屈にしか見えませんが、しっかりと生かせるシチュエーションがあります。「ほかではしょうゆさしという表記なのに、ここだけιょうゆさし」になっている! というもの。ようするに誤記であり、表記の統一ですね。ソフトウェアの世界では、制作の過程で「同じような機能を違う人が別々に作る」こともあり、それが不統一の原因になったりするのです。あとマニュアルもそう。製品を直したのに、マニュアルが「しょうゆさι」じゃああかんと。注意力もそうですし、ものづくりの過程を理解した上のでチェックが必要となる項目なのです。
ちなみに、「統一」というところでチェックするのも面白いんですよ。前述した「キッ○ーマンしょうゆが出ない」不具合を直してもらったところ、確かに出るようにはなったんですが、「ヤ○サよりもキッ○ーマンのほうが出がよくなってしまった」なんてことがあるわけです。しょうゆの種類によらず、同じように出ないといけないわけですよ。だから、「ヤ○サしょうゆを出すときはいったい何をしていたんだ、プログラマー!」ってわけで、ちょっとした騒ぎになったりしてね。

このように、作り手側で散々波風を起こしておいて、お客さんには平穏無事に使ってもらう。デバッグとか評価とかはそういうお仕事なのです。


---------------
ゲームのバグ出しについて考える
RPGでバグを出す話

RPGでバグを出す話

後ろを向いてバットを振る!! お粗末野球ゲームにネット騒然
http://www.j-cast.com/2008/12/19032594.html

 Wiiのゲーム「メジャー Wii パーフェクトクローザー」でバグがあまりにも多い、という話なんですが、これはバグを出す練習にもってこいの一品ですな。ゲームのみならず、評価・検証の仕事をしている人はすべからく購入すべきでしょう。評価の仕事であっても「もう直せる時期じゃないから不具合出すな」なんて言われますし、自分が趣味で買ったゲームや家電をわざわざ壊すように使うのは、どうしても躊躇してしまいますからね。値下がりしたところを狙うと面白そうです。
 ちなみに、私はこの話を聞いて、ことベースボールで画面端に消えるような超カーブを投げるバグを思い出しました。初代ファミコンだと、端子部分を金属などでさわりながら投げるとそういう状況をつくれたんですね。ただ、それだとファミコンの寿命を縮めることになりかねませんから、外付けコントローラーを使うのがベストなんです。で、1コントローラーで上、外付けコントローラーで下(=1コン操作の逆)を入力しながら投球すると、ファミコンを壊すことなく、超スローボールを投げることができるというわけです。ファミコンが現役のかたはぜひ試してみてくださいね。

おまけ写真:青の山
447.jpg


---------
 デバッガーが表舞台に出てくることはあまりないんですけれども、なかにはデバッガーの苦戦っぷりが読める書籍も存在します。「鬼畜王ランス」の攻略本がそれなんですね。18禁の内容を含みますけど、デバッガー達の笑い話がたっぷり語られており、経験者なら同意を、非経験者ならば笑いを得られるはずです。デバッガーネタについては、ゲームサイドでも何か面白いことができるんじゃないかなーと考えてみてたりしてます。

---------
 本題に戻しまして、下の図をみてください。RPGのフィールドを図にしてみたものです。
AC.jpg

アルファベットは街を表します(Aは最初の街)。さて、あなたならここで何をデバッグしますか?

・A→D→Cと行ってみる
 道なりにいけるかどうかを試す。基本ですね。

・Dを経由せずにCへ行ってみる
 障害物があれば、それをパスする方法を考える。デバッグの基本ですね。

・A→D→Aと行ってみる
 Aでストーリーが勝手に進んじゃってることって、けっこうありますからね。

・Aでずっとレベルを上げ続ける
 そういえば私がRPGのデバッグをやっていたとき、その後に入社してきた若いのは「最強の小学生を目指す」とか言いながら遊んでましたなあ。
デバッグを理解してなかったんだけど、まあグラフィッカーだししょうがないか。

・Aを無視していきなりDに行き、それからC→Aの順番で進む
 せっかく最強の小学生状態になったんだからさ、フラグチェックもしてほしかったよ、サカイくん。

・本当に道が区切られているか確かめる
 基本ですね。区切りが区切りの意味をなさなくなってしまう

・スタート(メニュー)ボタンを連打しながら、区切りに体当たりしてみる
 これで当たり判定が抜けてしまったゲームもあります。月風魔伝とかね。

・フィールドを囲う枠自体の当たり判定を見る
 実際のRPGにこういう枠はそうそうないんですけど、やはりチェックしておく必要はあります。
 抜けてしまえれば、AからCに行けてしまう方法になりますからね。

・スタート(メニュー)ボタンを連打しながら、フィールドを囲う枠に体当たりしてみる
 区切りは強固だったかもしれませんが、意外と枠なら抜けられるかもしれません。

・すべてのフィールドで戦闘をして、敵の出現範囲をチェックする
 ドラクエIIIでも、ある箇所だけ強い敵が登場してましたよね。プレイヤー側としては異様な興奮を味わえるのですが、ドラクエはそういう刺激を与えてはいかんでしょう。

・すべてのフィールドで戦闘をして、戦闘中の背景画面をチェックする
 背景画面が地形によって変わるゲームがあれば、これも欠かさずチェック。氷原地帯で草原の背景が出たら怖いですからねえ。

・そういえばBがないよ?
 実はそういうミスって意外と多いんです。ステータスが存在してるのにまったく使われていない、そんなRPGを私は作ってました。

---------
ゲームのバグだしについて考える。
レースゲームでバグを出す話
『F1レース』で基本的なバグ出しをしよう。
デバッガーに向く人、向かない人
RPGにありがちなバグまとめ
『F1レース』で基本的なバグ出しをしよう その2
テニスゲームでバグを出す話

テニスゲームでバグを出す話

 と言ってもファミコンの『テニス』から続く由緒正しいテニスゲームではなく、画面の両端に板(パドル)が出るテニスである。画面中央で動く障害物の数によって、サッカーになったりバレーになったりするあのテニスゲームだ。
 あんなゲームでバグが出せるの? と思うだろう。実際、あのゲームはプログラム自体もシンプルで、そうそうバグが潜む余地はない。しかし、そういうシンプルなプログラムでバグを出すのはものすごく燃えるのだ。堅いガードを突破する喜びとでもいうのだろうか。ガード破りといえばハッキングを連想する人もいるだろう。それは限りなくグレーな行為だが、デバッグならばいくらでも突破してよいのだ。これが燃えないはずがない。
 
 さて、あなたがテニスゲームをデバッグすることになった場合、まず、何から手をつけるべきだろうか。プログラムの確認? 仕様書の理解? いきなり現物をさわる? どれも面白いのだが、私はプログラムの更新履歴を見る。プログラマーがどんなプログラムを入れ込み、どんなバグを直してきたか、それでわかるからだ。
 特に面白いのは「どんなバグを直したか」。過去に出したバグを直したという記録だが、直しの甘いプログラマーだと、直しもれを残してくれるのだ。

 複数の箇所を直さなければならないのに、一ヶ所しか直していない。
 直してはいけないところまで直してしまい、かえってバグが悪化する。
 直したのだがプログラムに反映されていない。
 プログラムの更新履歴自体が間違っていた。
 
 などなど、バリエーションは様々だ。プログラマーの人となりをよく知っている場合、その人がやらかしがちなミスを先読みしてデバッグするくらいである。これをやると大変にプログラマーから嫌われるのだが、デバッガーはプログラマーから嫌われてなんぼの商売。どんどん嫌われるようにしよう。
 
 さて、最新の更新履歴を見ると、「パドルの両端にボールを当てた場合、ボールがパドルを通過するバグを直しました」と書いてある。パドルには厚みがあるから、その厚みの部分にボールを当てるとすりぬけてしまうバグを対処したのだろう。元のバグレポートを見ると、「パドルを動かしている時に発生した」とある。そこで、パドルを動かしつつボールを受け、さらにパドルを動かさずにボールを受けてみたりした。が、どちらの場合もきちんとボールを跳ね返すようになっていた。
 これは直ったかな? とあなたは考える。そこで、いったん確認をやめ、今度は別の更新履歴を見る。と、「パドルの後ろ側に消える安全地帯をつけました」とある。消える安全地帯とは、パドルの後ろ側にある、“ボールが当たると、ボールを跳ね返した後に消えてしまう”板状のものである。ブロック崩しにも出てくる、ボールを落としても一回は大丈夫なバリアみたいなものを想像してもらうとわかりやすい。
 それを見ていて、あなたはふと気がつく。
「もしかして!」
 そう、「消える安全地帯にボールを跳ね返させ、その跳ね返ってきたボールをパドルの両端に当てる」作戦だ。これまでのテニスゲームは、“正面からボールが飛んでくる”のを跳ね返していた。当然、パドルの後ろ側から飛んできたボールを跳ね返す、そういう処理は組み込まれていなかったのだ。
 
 ちなみに、あなたの作戦は成功した。後ろから跳ね返ってきたボールにパドルの両端を当てる操作は難しく、プログラマーが試せなかったからである。
 かくして、更新履歴に対してレポートを提出したあなたは、プログラマーからこう言われてしまうのだ。
 「またシビアなタイミングのバグを出してきましたねえ。全く再現できませんよ……」

『F1レース』で基本的なバグ出しをしよう その2

『F1レース』で基本的なバグ出しをしようの続き。

 『F1レース』でデバッグを始めたあなたは、あることを思いつく。
「ファミコンロッキー」でロッキーが行った“オーバーマッハ(音速越え)”を、実際にやってみようというのだ。
 ロッキーはAボタン(=アクセル)を秒間50連打することで、オーバーマッハを実現していた。
 しかし、あなたはそれができないことを知っている。
 たとえ秒間60フレーム判定のゲームであっても、50連打をしたところで、せいぜいONとOFFの切り替えが25回できるだけなのだ。
 そこで、あなたは別の方法を考える。
 時速496Km以上にスピードがあがらないのは、496Kmがスピードの上限に設定されているからだ。
 ならば、その上限を何らかの方法で突破すればいい。

 時速495Km近辺になったところでリセット……普通にリセット。
 上ボタン連打……何も起きない。
 ABボタン同時押し……特に変化なし。
 スタートボタンをタイミングよく押下……単なるポーズ。
 495Km→496Km→495Kmと小刻みなスピードアップ&ダウン……問題なし。
 Aボタンと方向キー下同時押し……LOW(低速)になってしまった。
 496Kmに達したと同時にAボタン連打……ロッキー、何にも起きないよ!

 あなたは意気消沈し、つい、アクセルを緩めてしまう。
 見る見るうちに速度が下がるフォーミュラカー。
 と、それを見ていたあなたは、あることを思いつく。
 時速496Kmに達した後、そのまま何もしないでスピードを落とせば何がが起こりそう!

 ───そして、あなたはバグを見つけることに成功した。

「やっぱりな。せっかく496Kmになったのに、スピードをこんな風に落とすプレイヤーはいない、なんて風に思ってたんだろうなぁ」
 気をよくしたあなたは、明日、自分の外付けコントローラーを持ってきて、1コンと外付けコントローラーの同時入力を試してみようと思っている。

ロマサガ2のひらめきに思うこと

 私と『ロマンシングサガ2』との出会いは、学生時代にさかのぼる。
 寮にいる友人と「長いこと遊べるゲームないかな?」という話で盛り上がり、中古屋で買ったのが『ロマサガ2』だったのだ。
 期待に違うことなく、とにかく『ロマサガ2』は面白かった。
 技をひらめく瞬間が心地よかった。
 一本道でないシナリオが楽しかった。
 シンプルで力強いセリフに酔わされた。
 ランダムで入手可能なアイテム集めに燃えまくった。
 アイテム集めにハマりすぎて、入手困難なアイテムを敵が落とすまで、1000回以上、1週間をかけて戦ったこともあった。「これ、ゲームにセーブされている時間は3時間だけど、セーブされてない裏の時間は10倍以上あるよな」などと、友人と笑いあったものだ。
 友人が「ワンダーバングル」の隠れた効果を発見した時も、かなり興奮したものである。攻略本では、「ワンダーバングル」の効果は「突」攻撃を100%防ぐということになっていた。しかし、実際に友人が装備したところ、「敵の攻撃を弾きまくっ」たという。
 2人は瞬時にひらめいた。
「こりゃもう全員分そろえるしかねえ!」
「どの敵が落とすんだよ?!」
「……んー、百獣王らしいな」
「犬か! セーブ&ロードで、やつらと戦って落とすまで繰り返すしかねえ!」
 再びセーブ&ロードである。こんな具合にゲーム進行そっちのけで、アイテム集めをしたものだ。
 話は少し前に戻る。ある程度ゲームを進めていた時、ふと、前の持ち主のデータが気になったことがある。
「……なんじゃこりゃー!」
 そこには、HPが700に達した初代皇帝レオンのセーブデータが残っていた。
「なんだコイツ?!」
「これ、ゲーム進めないで、序盤で鍛えたんだよ!」
「バ、バカすぎる。レオンを操作できる時間はちょっとしかないのに」
「こりゃもう、俺達もやるしかないだろ!」
 我々も負けず劣らず時間をもてあますバカな学生だったので、もちろんその日から始めてしまった。知ってのとおり、『ロマサガ2』の敵はプレイヤーの強さにあわせて強くなっていく。だから、ゲームスタート直後のダンジョンでも十分に経験を積むことができ、HPをMAX999にまで持っていくことができてしまう。さらに、敵が強くなれば、彼らの落とす武器や魔法もそれにあわせて強くなる。これはもう、「序盤で強くなってね☆」という制作者からのメッセージにしか思えなかったのだ(俺達だけだよ)。
 こうして、最序盤の「ゴブリンの穴」で鍛えまくり、モンスターから入手した最強装備で身を固めたHP999レオンは、クジンシーこと新宿に一撃で「うっ、これはたまらん」と言わせることに成功したのだ。それでも、イベントによってレオンはやられてしまうのだが。
 皇帝の代替わりシステムもまた面白かった。技の継承が、ではない。ある単純な方法で、年代が変わっても同じ皇帝でプレイを続けられることをひらめいたからだ。これにより、キャラクターへの思い入れはますます強まった。その一方で、「ランダムで皇帝を選ぶのも面白いよな」という逆説的な面白さも、また強まっていったのだ。
 こんな具合に『ロマサガ2』を遊びこみすぎ、また、そのプレイの一つ一つに思い入れがあったため、4箇所のセーブデータでは足りなくなってしまった。こうなればやることは1つ、カセットの買い足しである。いまも部屋には4本のカセットがあり、それぞれに違うデータが残っている。もし、『魔神転生II』のようにセーブデータが2箇所しかなかったら、所有カセットは8本くらいに増えていただろう。
 また、RPG特集に便乗して、『テラクレスタ』のフォーメーションエディットを使って『ロマサガ2』のフォーメーションを無理矢理に誌面で実現してしまったほどだ。いつか機会を作って、15年分の熱い思いを元に制作者の方へインタビューしてみたいものだ。
 ところで、『ロマサガ2』最大の魅力は、“技のひらめき”だと思っている。あの、“ピカーン!”という心地よい音と共に技をひらめくあの瞬間! あのひらめきを何度も味わいたいから、繰り返し遊び、より多くのひらめきを得るための方法を考え、実行してきた(だから、ジェラールで世界一周とか色々な遊びかたをしてきたけれども、「魔法オンリー」という戦いかただけはしていなかったりする)。
 実は、このひらめきこそがバグ出しの要である。
 我ながらかなり強引なつなげ方だと思うし、導入部分として語ろうと思っていた『ロマサガ2』が濃くなりすぎたものの、とにかく「ひらめき」が大事なのだ。
 しかし、漫然とバグ出しをしているだけでは、そのひらめきを得ることができない。『ロマサガ2』だって、「初めて出会った」、「レベルの高い敵」で、なおかつ「固定敵」であれば、ひらめく確率が高まることがわかってきている。同じように、バグも「初めてゲームに搭載された」プログラムで、それが「手順の多い(出来ることが多い)仕様」であればあるほど、ひらめきを得られる回数が多くなるのである。
 ひらめきを得られる箇所や時期を見逃さず、どうしたらそのひらめきを得られるのかを理論化し、普遍化する。それこそがバグ出しのすべてであり、『ロマサガ2』に通じる面白さとも言える。また、これはゲームだけに限った話ではなく、あらゆるソフトウェアの品質管理や向上につながっていくはずだ。
 ゲームは、観賞するタイプの娯楽と異なり、プレイヤーが様々なことを能動的に行うことが出来る。そして、能動的な行為から得られる経験や考えかたは、何物にも変えがたい素晴らしいものだ。ただ、現時点では、その経験や考えかたをその他のことに転化するための方法と、それの流布が圧倒的に少ない。だから、マイナスイメージばかりが語られ、ゲームが様々な悪しき出来事の原因とされることの多いのだろう。それだからこそ、「ゲームから学べること」「ゲームの役立てかた」を、ゲーム関係者すべてに自信をもって発信してほしいと切に思う。
 私は、ゲームプレイやデバッグから数多くのことを学んだ自負がある(学生時代に勉強をしなさすぎたという事実もあるが)。今もなお、創意工夫することの面白さを学んでいる。だから、銀行ATMや飛行機の予約システムトラブルのニュースを見るたびに思うのだ。
「ゲームのバグ出し職人を雇えばいいのに。そんなバグ、すぐにひらめくから」、と。

---------
ゲームのバグを出す話
ゲームのバグだしについて考える。
レースゲームでバグを出す話
『F1レース』で基本的なバグ出しをしよう。
デバッガーに向く人、向かない人
じゃんけんマシンが史上最強すぎる件
バグ出しを暮らしに生かす話
ロマサガ2のひらめきに思うこと

バグ出しを暮らしに生かす話

 振り返ってみれば、ゲームのバグは常に私の身近にありました。小学生時代、友人が『パックマン』をプレイしてくれたのを見ていたんですね。忘れもしない2面、イチゴボーナスの面ですよ。彼は、1面のパーフェクトなドットイートとは全く違う、ランダムな動きをしはじめました(私にはそう見えたんです)。なんだろうと思ってみていると、そのまま"まちぶせPINKY"に体当たりしていったんですよ! しかし、そこでありえないバグが起こったんです。なんと、パックマンがPINKYをすり抜けるじゃないですか! 
 「パターンだよ」
 彼はこともなげに言いました。いわく、そのとおりに動けば100%すり抜けるんだとか。私も当然、その攻略パターンを真似してみました。
 「すり抜ける! すげー、すり抜けたよ!」
 「な?」
 この時、私にとってバグは、「狙って出せるもの」であり、「通常ではありえない興奮をもたらすもの」であり、かつまた「利用すべきもの」として刷り込まれました。だから今も、商品として売られているゲームや、ソフトウェアが組み込まれた製品でバグが出るのを見ると、「ちゃんと仕事しようなー」と思いつつも、ノスタルジックな思いにもとらわれてしまい、「ま、いっか」っていう風になってしまうんですよ。
 実を言えば、いま私が使っている携帯にも、ブラウザで100%出るバグがあるんですね。あることをしていて見つけたんですけれども、あまりにもシンプルな手段できれいにリセット→再起動するんですよ。だから、この携帯は機種変もしないで使い続けてますし、ことあるごとに、友人や知人にそのバグを披露するんです。
 「こういうバグを残さないように、デバッガーは日夜がんばってるんですよ」
 みたいな感じですね。
 一方、バグ出しを仕事にしている時は、もちろんバグを出さないようにしなくちゃいけませんから、まさに「根こそぎ」、しらみつぶしに出来ることを行っていきます。まあ、これがまた楽しいんですよ。バグそのものもありえない現象だらけで楽しいんですけど、プログラマーさんや納期を守ろうとするディレクターさんとのやりとりがまたいいんです。直すか、壊すか。どのタイミングで報告すれば直されやすくなるのか。どう報告すれば重そうなバグに見えるのか。バグでゲームが出来なくても、それをすりねけてバグ出しを続行するにはどうしたらいいのか。ちょっとした頭脳戦、心理戦ですよ。
 また、ゲーム会社の上司に言われたセリフをいまも鮮明に覚えています。
 「『ドラクエ』なんて大変なんだよ。何百万人ものプレイヤーにデバッグされるんだから」
 これに私はビビっと来ました。
 「よし、何百万人がさわっても、びくともしない完璧なものにしてやろうじゃないか!」
 燃えましたね。人生をかけてやろうと思いましたもん。
 それに当時、バグ出しの社会的評価はとてつもなく低かった。だから、そこで完璧な仕事をすることで、その評価自体を上げていこうと思ったんですね。それもまた、燃える感情をさらに持続させるための燃料になってくれたものです。
 ところで、バグ出し以外の仕事をやりはじめるようになると、やっぱりなかなかうまく行かないんですよ。なんつっても燃えない。私を奮え立たせてくれるものがない。だから悩むし、ぜんぜん仕事もうまく行きませんでしたね。が、ある時、ぱっと気がついたんですよ。
 「バグ出しの考えかたを使えばいいんじゃん」
 それはすなわち「根こそぎ」。1つの事柄に対して、あらゆる角度、あらゆる考えかたで、様々な自分が出来うることのバリエーションを考える。その時々に応じて、その最適な行動をしていけばいい……ってことなんです。
 だから、ファミプロの仕事では、数ある遊びかたを考える中で、最も"アホやなぁ"と思ってもらえるための遊びかたを選んでやってます。ゲームライターとしての個を確立させる合言葉は、「損して得取るな」。日常生活も笑えまして、新聞や小説を見るときなんかもアホですよ。まず誤字探しから入りますから。あと、ロジックの破綻とか。先日も、1面広告のキャッチコピーが「Final Campaign」なんてつづりになってて、思わずそういう単語があるんかと思って辞書を引いちゃいましたからね。もちろん、その記事は切り抜いて大事に保管してあります。キャンペーン第二弾は「Fbinal」なのかしらん、とか思うだけで楽しいんです。
 また、趣味も根こそぎ。RPGとくっつけたゲーム一覧とか逆転の発想で作られたゲーム一覧とか、スーパーマリオ100の世界の遊びかたとかファミコン年表完全版"とか、やる時は徹底的にやっちまいますね。
 当時、ゲーム会社の社長に言われた一言がいまも支えになってます。
 「○ちゃんは、一生、50や60になってもデバッガーでいるつもりなの?」
 いまなら胸を張って答えます。
 「ええ、その考えかたで何でもバグ出ししてみますよ。うひひ」

---------
ゲームのバグを出す話

ゲームのバグだしについて考える。
レースゲームでバグを出す話
『F1レース』で基本的なバグ出しをしよう。
デバッガーに向く人、向かない人
じゃんけんマシンが史上最強すぎる件
バグ出しを暮らしに生かす話
ロマサガ2のひらめきに思うこと

RPGにありがちなバグまとめ

 ゲームのバグ出しについて考える
 レースゲームでバグを出す話
 『F1レース』で基本的なバグ出しをしよう
 デバッガーに向く人、向かない人
 じゃんけんマシンが史上最強すぎる件
 バグ出しを暮らしに生かす

 これまで、いくつかバグ出しの話を書いてきました。今度は、RPGで実際にありそうだったり、ありがちだけどなさそうなバグを並べてみました。ツッコミやボケはコメント欄へどうぞ~。

---------
・アイテム使用画面で、本来使うべきでない相手にあるアイテムを使うと、そのキャラクターのステータスがぐんぐんアップしてしまう
・アイテム使用時、次のページにめくった瞬間に方向キーを入れると、実際に選んでいないアイテムを使ったり、捨てたりすることができてしまう
・移動速度の速くなるアイテムを持った仲間をパーティから特定の方法ではずすと、移動速度が速いままになってしまう
・イベントアイテムを入手するシーンにおいて、序盤ではありえない金額を提示されてくる時、実際にそのお金を持っていても、何もなかったかのように会話が進んでしまう
・イベントで仲間と別れる前に装備をもらっておき、また仲間が入ってくるとその装備を再び身につけている
・イベント時、何も持っていないと後ろに追い出されてしまう、パーティが後ろ向きに入ると、そのイベントを通過するように追い出されてしまう
・ステータス画面で、アイテムを選択した後キャンセルを押すと、ステータスの上限をこえて数値を増やすことができてしまう
・パーティのうち1人だけで来なければならない場所で、そこから脱出する呪文を唱えると、その状態でパーティに加えたメンバーのアイテムを増やすことができてしまう
・パスワード入力画面で、3回に1回は適当なパスワードでも通用してしまう
・レベルアップで、最高のレベルまであげるとレベルが1に戻ってしまう
・レベルアップ時、レベルを上げすぎているとスキルポイントを割り振ることができず、レベルアップ時のスキル割り振り画面から抜け出すことができなくなってしまう
・レベルアップ時、経験値の上限を超える経験値を稼ぐと、経験値を表す表示が「9あ999え」などとなってしまう
・レベルアップ時、特定の手順でステータスポイントを割り振らないまま終了することができ、そのポイントがなくなってしまう
・移動時、イベントが発生した際にリセットしてオートセーブさせると、ロード後にイベントを通過したことになってしまう
・移動時、ボタンを連打しながら進むとエンカウント率が下がってしまう
・移動時、外付けコントローラーを使って特殊な入力方法を行うと、障害物をすりぬけて移動することができてしまう
・移動時、石になっている状態で「DEAD」になると、HPが0なのにステータスが[STONE]のままになってしまう。
・移動時、特定のポイントを通ると、スタート地点に戻ってしまう
・移動時、特定の場所で敵との戦闘になると、普段よりも強い敵が出てきてしまう
・街の人を1人分の間隔をあけて並べた時、町の人が同時に同じ場所へ移動すると、町の人が重なってしまう
・戦闘時、「まもる」コマンドを入力してからキャンセルしても、「まもる」状態が入力されたままで戦闘することができてしまう
・戦闘時、アイテムを選んだ後にキャンセルし、オートで戦闘を終了させると、そのアイテムが増殖してしまう
・戦闘時、エナジードレインでレベルを1以下にすると、レベルがMAXになってしまう
・戦闘時、コントローラーの電池が切れると、その後の入力を一切受け付けなくなってしまう
・戦闘時、使用回数のあるアイテムの使用回数を下限未満にすると、そのアイテムが違うアイテムや敵になってしまう
・戦闘時、呪文を跳ね返す呪文を味方にかけ、その味方に呪文をかけると、敵に100%効いてしまう
・戦闘時、所有数上限を超えるアイテムを入手すると、アイテムが変化してしまう
・戦闘時、所有数上限を超えるアイテムを複数入手すると、主人公のレベルが変化してしまう
・戦闘時、装甲が特定のポイントの時に特定ダメージを受けると、装甲がMAXになってしまう
・戦闘時、仲間が上限までいる状態で、「COMPに戻る」と「呼ぶ」を同時に行うと、先に呼んだ仲間がパーティに加われず、消滅してしまう
・戦闘時、敵がしゃべるイベントでボタンをあらかじめ押しておくと、イベントが始まらず、フリーズしてしまう
・戦闘時、敵を毒で倒すと経験値がもらえなくなってしまう
・戦闘時、魔法の効果を重なることで、100%有効な魔法になってしまう
・道具の預かり所に上限までアイテムをあずけ、さらにパーティのアイテムをフル状態にしておくと、一番最初に預けたアイテムが消えてしまう
・氷の坂道を駆け上がる時、滑らなくなるアイテムを取らず、敵に体当たりしながら弾き飛ばされる方法で、強引に坂道を登っていってしまう
・氷の上を滑って移動している時、ステータス画面を開いて閉じると、氷の上で停止してしまう
・名前入力画面で、名前を入力した後にすべてを消して決定すると、名前欄が空白になってしまう
・ラスボスとの戦いで、主人公を後列に下げると、脇役で最終決戦を戦うことができてしまう
・ラスボスを倒した後、地形ダメージを受けて死ぬと、その後の会話がバグってしまう
・ラスボスを倒した後、画面が真っ暗になって終わってしまう

 「……えっ。あれはエンディングじゃないの?」
 「実は、バグなんです」

じゃんけんマシンが史上最強すぎる件

 昨日、ながら仕事をしつつテレビをつけていたところ、「ジャンケンマシン」の話題が出ていた。人間の手のとある一点を60分の1フレーム(1秒間に60回)ごとにカメラで観測し、人間が出そうとしている手を予測するのだという。見ている限り、通常の方法ではまず間違いなく勝つことができなさそうだった。
 このジャンケンマシンに勝つためにはどうすればよいのか。
 理屈上では他愛がない。60分の1フレーム以下の動きでじゃんけんの手を出せばよいのだ。しかし、ゴルゴ13か範馬勇次郎あたりでもない限り、そのような人間離れしたことはできないだろう。ならば、コンピューターが計測している点をずらすのはどうだろうか。すなわち、関節はずしの技術で、観測しているポイントの形状を変えてしまえばいいのだ。しかし、関節をはずした状態でじゃんけんの手が作れるのか、はなはだ疑問ではあるが。
 ただ、一回きりの勝負ならば、もしかしたら勝てるかもしれない。その方法はずばり、これだ。
ぐーちょきぱー
 小学生並みのイチャモンか、ルパン三世の抜け道トリックみたいなものだ。しかし、ゲームのバグを出す話で書いたとおり、バグ出しというのはこういう発想で行うので、デバッガーにはこのくらいしか思いつかないのも事実である。ただ、この形状も認識されていたら勝ち目はないが。
 と、記事をアップした後に1つ思い出したことがある。テレビの中では、ジャンケンマシンが「最初はグー」という掛け声を出しており、対戦者はすべてそれにしたがってグーを出していた。ここに攻略の鍵がありそうだ。ジャンケンマシンは、カメラで人の手を撮影し、それを観測する。そのため、最初から手の形をチョキやキツネにしておくとか、コンピューターに観測できないように手を裏側に向けておくのも有効なのかもしれない。

 で、「ジャンケンマシン」をネットで調べようとしたところ、Javaスクリプトで組まれた別の「じゃんけんマシン」を見つけてしまった。はっきり言うと、コイツにはどんな手も通用しない。リンク先にはほとんど勝てないだろうと書いてあるが、本当に惨敗した。チョキだけを10回連続で出したのに、10連敗されられたほどである。多少ジャンケンが強いとか、相手の手が読めるとか、確率論を学んだとか、天運をつかんでいるとか、賭博黙示録のカイジ本人だとか、そういう人でもおそらく勝てないと思われる。
 ジャンケンといえば、『アレックスキッドのミラクルワールド』でボスとのジャンケンに勝つにはテレパシーボールが必要だった。じゃんけんマシンに勝つには、プログラムソースの穴を見つけるくらいしかないだろう。まさにデバッガー殺しである。

---------
ゲームのバグを出す話

ゲームのバグだしについて考える。
レースゲームでバグを出す話
『F1レース』で基本的なバグ出しをしよう。
デバッガーに向く人、向かない人
じゃんけんマシンが史上最強すぎる件
バグ出しを暮らしに生かす話
ロマサガ2のひらめきに思うこと

デバッガーに向く人、向かない人

 ゲームのバグだしについて考える。
 レースゲームでバグを出す話
 『F1レース』で基本的なバグ出しをしよう。

 3つもエントリを書いてしまったので、ゲームのバグ出しについてもう少し。

 これまでの経験上、バグを出す仕組みを教えていても全く出せない人もいるし、バグ出しの初日から市場に出回っている製品のバグを出してしまう人もいる。実のところ、「バグを出す仕組み」は知識の集合であり、体系的にまとめることができる。また、それを教えれば誰でも理解することができる。ただ、「ではどうやったら実際にバグを出せるのか」ということになってくると、知識だけではおぼつかなくなってくる。何より、知識もないのにバグを出す人の存在を説明することができない。
 初心者なのにバグを出す人に話を聞くと、こんな答えが返ってくる。
「何となく出そうだと思ったので……」
 おそらくは直感で出しているのだろう。しかし、それが重要なのだ。デバッガーに向いている人のバグは「出そうとして出したバグ」であり、向いていない人のバグは「たまたま出てしまった」ものに過ぎない。だから、バグの種類を見ると、その人がどういう考えかたでバグを出しているのかもわかってしまう。下手すれば仕事に対する姿勢すらも。
 「出すもの」と「出るもの」では全く違う。バグを出す人は、バグを出そうとして操作し、それでバグが出なければ、「ちゃんと作ってるなぁ。じゃあ、ここならどうだ!」とさらなるアプローチ手段を考えることができる。1つの処理に対して、処理のないところを探し、穴を探し、限界を探し、固有のケースを探し、組み合わせを探し、どうやったら効率的に漏れなくバグを出せるかを研究し、本当の意味での「たまたま」、すなわち発生頻度の低いバグですらも「出して」しまったりする。
 結局のところ、バグ出しに特別の才能は必要ない。「バグは出すもの」ということを理解して実践できる人が、デバッガーに向いているのだ。

---------
ゲームのバグを出す話

ゲームのバグだしについて考える。
レースゲームでバグを出す話
『F1レース』で基本的なバグ出しをしよう。
デバッガーに向く人、向かない人
じゃんけんマシンが史上最強すぎる件
バグ出しを暮らしに生かす話
ロマサガ2のひらめきに思うこと

『F1レース』で基本的なバグ出しをしよう。

 レースゲームでバグを出す話に引き続き、『F1レース』を使ったバグ出しについて考えてみる。

 スタートボタンを押してゲームを始めた後、いよいよデバッグだ! と意気込んだあなたであるが、実は肝心なことを忘れている。「仕様書」の存在だ。仕様書を確認しないことには、何が正しい動作なのかわからないのだ。
 ただ、ここで注意したいことがある。「仕様書どおりに動いているかを確認する」のと、「自由な観点からバグを出す」のとは、実を言えばかなり違う。仕様書どおりに動いているかどうかは前提条件であり、かつまた仕様書の見方がわかれば、基本的には誰でも確認することができてしまう(たまにというか、かなりの頻度で読み取り能力の著しく低い人もいるけれども、それはまた別の機会に)。よって、仕様書はあくまでもバグを効率的に出すための参考資料と考えておこう。
 ちなみに、仕様書がなくても(ないままバグ出しをすることもよくある)バグ出しはできる。フリーズ、リセット、ハマり、メモリ破壊などなど、プレイヤーが回避できない致命的なバグを見つけていけばよいからだ。バグを出すのが仕事のデバッガーは、バグを出せば出すほど、重いバグを見つければ見つけるほど、”仕事ができる”という評価につながっていく。デバッガーたるもの、仕様書がない程度で迷ったり立ち止まったりしているわけにはいかないのだ。
 さて、『F1レース』のバグ出しを始めたあなたは、アクセルに割り当てられたAボタンを押して走りだす。そのままスピードアップしていき、トップスピードになったところでギアを替え……、とやろうとして、これは遊びではなくバグ出しの仕事であるということを思い出す。そもそも『F1レース』は、「Aボタン(=アクセル)を押すとスピードアップする」仕様なのだ。ゆえにあなたは、どんな状況でもAボタンを押せばスピードアップしているかどうかを調べることにした。
 そのアプローチは半分ほど正しい。「どんな状況でも仕様を満たしている」というのはバグ出しの基本であり、必ずチェックしなければならないからだ。ただ、「仕様書どおりに動いているかを確認する」段階のうちに、目端の利く人がそのポイントをチェックしてしまっている可能性もある。その場合、あなたのバグ出しは二度手間になってしまう(バグが再発していないかを調べるデグレチェックという試験もあるが、ここではおいておく)。だから、あなたはスピードアップにまつわるバグの核心、「Aボタンを押しているのにスピードアップしない」ことにいきなり迫る必要がある。しかも、ただ闇雲にやっているだけではバグは出てくれない。どうしたらAボタンを押しているのにスピードアップをしない状況になるのかを考え、その上で、バグが出やすい状況を自ら作り出していかなければならないのだ。
 Aボタンを押しているのにスピードアップしない原因として考えられるのは、「なぜかBボタン(=ブレーキ)が押された状態になっている」、「Aボタンが押されていないことになっている」、「Aボタンが押されていると判定されているのに、なぜかスピードアップの処理が動いていない」「ローギアで出せるMAXスピードに到達していると内部的に判定されてしまっている」といったことである。だから、それらのバグをあぶりだすように、あやしい状況状況をピンポイントで狙い撃ちしていけばよい。それらのバグが狙い通りに出せるようになれば、Aボタンを押していないのにスピードアップするバグでさえも見つけ出すことができることだろう。
 「Aボタンでスピードアップしない」なんて地味なことはやってらんない! もっとハデなバグを出したい! という目立ちがりな人もいるだろう(デバッガーには必要な資質である)。そんな人にオススメなのが、敵車との激突。『F1レース』は、敵車と接触すると爆発してしまうので、もちろんここは敵車と接触したのに爆発しない状況を狙う。しかし、単に爆発しないのではインパクトに欠ける。そういえば、ゴールと同時に爆発すると、爆発したF1がいきなり復活して、そのまま走っていったっけ……。よし、狙いどころはここだ! 
 目の付け所がシャープである。しかし、さらなるインパクトを狙うには、それだけではまだ足りない。実を言えば、車がゴールインする時、プログラム内部ではいろいろな処理を行っている。そこで、ゴールと同時に特殊な方法で自車を爆発させ、ゴールしたという判定そのものをさせないようにしてしまうのだ。ここで狙い通りのバグが出ると、自車が爆発したグラフィックのままで走り続け、なおかつ、いつまでもゴールしないことになる。このクラスのバグはファミマガでいうところの横綱技であり、デバッガーならばこういう大物を常に狙いたいものである。

---------
 ゲームのバグだしについて考える。エントリを読んだ人は「バグ出しは大変そう」と思うようだが、私自身はそんな風に思ったことは一度もないどころか、楽しくて楽しくてしょうがなかったりする。普通は決してできない(やってはいけない)ソフトウェアの破壊工作を存分に行うことができ、徹底的に壊せば壊すほど自分自身の評価が高まり、さらにバグをプログラマーに直させ、なおかつお金までもらうことができてしまうのだ。大変さなんて感じるヒマもないくらい、何をやっても面白い仕事なのである。
 私がゲーム制作会社でプランナーのヘルプをしていた頃、とあるゲームのプログラミングが行き詰まってしまったことがある。その時、とある天才プログラマーが行き詰まり打開のためにやってきた。いまや任天堂の社長となった岩田さんである。岩田さんはプログラムコードを一見して、たちどころに問題点とそのゲームの本質をつかみ、修正を開始した。いや、修正ではなくイチから作りなおしていたのかもしれないが、とにかく、行き詰っていたゲーム部分が、あっという間に完成へと近づいていったのだ。
 しかし、神がかり的なプログラミングをしていた岩田さんの前に、とあるデバッガーが立ちはだかった。岩田さんが組み上げたプログラムの穴を的確に突き、次々とバグを出しまくるのである。岩田さんがその穴を埋めても、さらに細かな穴をついてくる。
「岩田さん、またバグが出ちゃいました」
「あぁ~、まだ出ますかー。うーん、あそこかなぁ」
 岩田さんとデバッガーの楽しげなやりとりを聞くたび、何度、「デバッグしてぇぇぇ!」と思ったことだろうか。こんな風に毎日が楽しい、最高にゴキゲンな仕事なのだ。バグ出しってやつは。

---------
ゲームのバグを出す話

ゲームのバグだしについて考える。
レースゲームでバグを出す話
『F1レース』で基本的なバグ出しをしよう。
デバッガーに向く人、向かない人
じゃんけんマシンが史上最強すぎる件
バグ出しを暮らしに生かす話
ロマサガ2のひらめきに思うこと
次のページ

FC2Ad