ゲーム開発ログ ＃110　Unity：拡張に伴い構造が複雑化したので影響範囲の小さい回避策を選んだ話

Unityでカジュアルゲームを作っています。

今回は、
機能拡張を進める中で既存システムとの相性問題が発生し、最終的に影響範囲の小さい回避策を選んだ話です。
忘れないように自分用メモとして残しておきます。

直面した問題

• 新しい機能を追加したかった

• 既存システムと干渉し、思い通りの結果にならなかった

• 原因の特定はできた

• ただし中心部分を修正すると、デバッグのやり直しや他機能への影響確認が広範囲に及ぶため、修正コストが大きくなる

やりたかったこと

• 新規機能は実装したい

• 既存システムへの影響は最小限にしたい

• できるだけ安全に対応したい

調べてわかったこと

ログを追った結果、原因の特定はできた。

処理そのものが間違っていたわけではなく、既存システムには複数の成功パターンが存在していた。

成功ルートA（入口が近いケース）
成功ルートB（入口が遠いケース）

拡張前は問題なかったが、新機能の追加に伴い、既存システムの一部成功パターンと干渉が発生した。

原因を特定し、解消する方向性は見えていたが、そのためには既存システムの根本的な見直しが必要だった。

最終的な対処

今回は既存コードへ大きな修正を加えず、最終結果の判定部分に専用の管理クラスを追加することにした。
イメージ：

・既存システム（独立）
　　　　　　　　　　　　}　管理クラス（新規）　→　正しい結果
・拡張機能（独立）

という形で、最終的な結果だけを調整する構成にした。

👉これにより既存システムと拡張機能を大きく変更せずに対応できた。
※根本修正も検討したが、影響範囲と確認コストを考えると、現段階では回避策の方が現実的と判断した。

気づき（自分用メモ）

• 原因が分かっても、必ずしも根本修正が正解とは限らない

• 開発が進んだシステムほど影響範囲の見極めが重要

• 拡張機能と既存システムの相性問題は意外と起こる

• 将来的な見直し候補として記録を残しておくことも大切

まとめ

・根本修正のコストとリスクが大きかったため、影響範囲の小さい回避策を選択した
・開発状況によっては理想的な構造よりも、既存システムの安定性と安全性を優先する判断も重要
・ただ、この判断は原因を特定できていたから選べた対応でもある

次にやること

• 拡張機能の検討及び実装

• 体感としての違和感の修正

• 他システムとの整合性確認

引き続き、チェック作業と開発を進めていきます。