想定外の完成形

内部処理が実行速度に依存していると、最適化で進行まで速くなる場合がある。快適になったという評価とは別に、難しくなるまでの時間や対応の余裕を確認する。

最適化で動きが軽くなることと、調整した難しさを保てることは別問題になる。時間を惜しんで整えた数値でも、進行の基準が変われば効果が違ってくる。終盤ほど見落としにくくするため、速度改善が体験の別の部分へ伝わらないかという視点が要る。

開発用の機材と完成品では、動作条件が一致していない可能性がある。開発中の調整結果だけを根拠にせず、最後の実行環境でも時間の経過や挙動を確かめる。

携帯する製品でも、開発中は持ち運べない大きな基板で調整することがあったと語られる。作っている環境での確認を積み重ねても、完成品との違いが入り込む余地は残る。すべての問題を先に一覧へできるとは限らないという現場の難しさも示される。

製品版の違和感に明確な原因が出ない例も紹介される。断定を急がず観測された現象を扱い、広範囲の再調整が難しければ、対応可能な難易度設定などを検討する。

CPUの強さを全体から直すと、関連する多数のモードを調べ直す必要がある。そのため原因が曖昧なまま大変更するのではなく、実際に使える対応手段から負担を軽減している。更新で対処できることの価値と、想定外を残す残念さの両方が語られる。