つくりかた兼人録

影響の範囲

　ゲームに限らずプログラムやデータなんかは、修正するとそれによる結果がアプリに反映しますね。

　アプリというのは、バグを見つけて原因を特定し、そこを直せばハイ完了――とはいかないんですね。

　必ず影響範囲というものを検証します。

　その修正によって、何か起きるのか？　どこまで影響するのか？　その全てを洗い出さなくてはなりません。

　分かりやすい例ならば、

　セリフの音声が小さくて聞き知り辛い……からサウンドドライバの音量を上げて、聞き取りやすいようにした。

　なんて修正をしてしまったら大変な事になります。

　音声はセリフだけではありません。効果音も音楽も全て含まれるので、根本的に音量を上げると全部上がってしまいます。

　上記は分かりやすい例ですが、

　それが細かい所になると予測範囲が大きくなり、洗い出しが困難になるのですね。

　それで新しいバグが入る、なんて事も珍しくありません。

　どんなに小さなバグでも、それで先に進めなくなってしまったら致命的なバグになってしまいます。

　これを直す事によって、進行不能にならないか？　という予測はもはや経験が一番物を言う。

　こればっかりは若くて新しい教育を受けた新人でも届かない。

　もっとも不条理だと思えるような例だと、

　とあるゲームが完成し、デバッグも完了しました。

　しかし納品後、プレイ中にハング(ストップ)してしまう不具合が発覚。

　一体どういう事なのか？　確認したロムから何も変えていないはず。修正しないものから再現性100%のハングが発生するなどあり得ない。

　と騒ぎになりましたが、実際には修正はされていました。

　デバッグ終了後、プログラマが使っていないデータを削除をしていたのですね。

　そのデータは本当に使っていないものでした。追加ならともかく消しただけなら無駄がなくなっただけでハングするなどあるはずがない、

　と独断で修正を加え、それを報告する事もなかったのですね。

　しかし確認していたロムと納品したロムを比べるとデータが変わっている。絞っていくとデータが消されていた。元に戻すと問題なく稼働。

　使っていないと思われていたデータが実は使われていた、というオチは割と多いのですがそういうものではない。

　プログラマも初心者ではないのでその程度の事は知っています。

　では何が起きたのか、という事を調べてみると。

　そのハードウェアのメモリは二つに分けられていて、それを繋げて大きなメモリとして使用していた。

　だがデータのサイズによってはその境界線にデータがかかってしまい、一つのデータが二つに割れてしまう。そのデータにアクセスしようとするとハングする。

　今までは幸いにもそういう事が起きていなかった。

　メモリマネージャの不具合と言えばそうなのですが、予測する事はまず不可能。

　しかしそれは関係ありません。

　残る事実はハングするロムを納品した、という事実だけ。原因は関係ない。

　そういう事もあるので、熟練者は完成したロムは何があっても触らないのです。