ご無沙汰しております、グローⅥのディレクターの高田です。

さて、今回もグローの開発苦労話、特にデバッグ時期の話をしたいと思います。
グローのデバッグは、特にシナリオ班の作業が大量のバグを出し、
いつ終わるともしれないマラソンをしているような状況に陥っていました。
自分の開発経験の中でも、最も厳しいと言いますか、正直、しばらく記憶が飛んだデバッグでした。ｗ

特にグローの場合、以下の理由から、大量にバグが出やすい状況でした。
・あちこちでイベントを発生させるため、
　単純にイベント数がＲＰＧの中では、多い部類になること。
・同じ街へ何度も戻ってくるため、バグ対処やイベント組み込みの作業をした際に、
　他の時間軸のイベントを間違っておかしくすることがある。
・ＲＰＧ製作が初めてだった

というわけで、印象としては３つバグを対処すると、１〜２つバグが増えるような
そんなゴールの見えない絶望的な状況の中、バグ取り作業をしていました。
さらに、このデバッグを泥沼化させた、もう１つ大きな原因があります。
それは、グロー１はＰＳ時代の作品だったので、ＰＳ２と比べメモリ容量が少なく、
イベントスクリプトに避ける容量が小さかったことです。

それがどういう影響を出すかと言いますと…。
とあるバグ対処で、例えば魔法学院のイベントデータが容量オーバーしたとします。
すると、容量がオーバーしているファイルサイズを小さくする必要があります。
ということで、例えばその魔法学院のファイルに、ＡＢＣという３つのイベントが入っていたとすると、
Ｃを切り分けて、ＡＢが発生するファイルと、Ｃが発生するファイル…と
イベントファイルを分割し、１つあたりのファイルサイズを小さくする対処を行っていました。
…ところが、上記の例ですと、「ＡとＣが同時に発生できる場合がある」と、
バグが発生する可能性があります。
つまり、ＡＢのファイルではＣが発生せず、ＣのファイルではＡが発生しないため、
場合によっては進行不能バグになるわけです。
　(進行不能にならなくても、○○というアイテムを持ってきたのに、何の反応も有りません…という
　気まずいバグが発生します…)
そのためバグ対処をすることでファイル容量がオーバーし、その分割作業によって
また新たなバグを発生させてしまう…という、混迷した状況が続いておりました。
　(当然、デバッグ作業自体もやり直しになります)

特に、例に出した魔法学院は、実際に容量オーバーを頻発し、
最終的にはバージョンが８パターンにもなりました。
ここは、すでに７パターンになっていた頃から、不用意に弄ると
バグが簡単に発生する『魔のファイル』として怖れられていました。
なので、容量がオーバーしないよう、皆で祈っていたのですが…。
ついに、どうにもならないバグが見つかり、しかも容量オーバーを起こし、
８パターンに分けることになりました。
当時、この部分を最も把握していたのが葉月だったのですが、
頭を抱えながら、丸一日くらいかけて、慎重にファイルを分割していました。
そして、その甲斐あって、バグはやがて収束し、無事マスター提出できる事になりました。

当時、面白いなぁ〜と思ったのが、数ヶ月の間、毎日１００件くらい来ていたバグが、
急に１０数件程度になり、１週間ほど続いたら、
いきなりバグがピタッと０になったことです。
その後も４〜５日バグが出ず、ようやく「終わったんだなぁ〜」と
ホッとしたのを覚えています。

それにしても、当時バグを２４時間態勢で見付けて頂いた
デバッガーの皆さんには、感謝しております。
もし、あの優秀なデバッガーさん達がいなかったら…。
グロー１のデバッグは終わっていたのだろうか？と、今でも怖くなります。

それにしても、あの時のゴールの見えないマラソン状態は
きつかったなぁ……。ｗ

それでは、また。

[高田慎二郎]
「グローランサー」ディレクター
「グローランサーⅥ」ディレクター
「女神異聞録デビルサバイバー」ディレクター