【マイレース開発記録(3)】ロジック設計の迷走　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

発想はきれい、ロジックはぐちゃぐちゃ

前回の記事では、

• 占星術を動きに変換する
• スピードとジャンプの二軸で表現する
• 状態をゾーンとして分類する

という設計思想を書きました。

ですが、正直に言うと——
思想はきれいでも、ロジックは最初ぐちゃぐちゃでした。

「速さ」は何を基準にするのか？

最初に詰まったのは、スピードの定義です。

私は最初、単純に考えていました。

• 天体の角度差が小さいほど良い
• 角度差が大きいほど悪い

しかし、実装してみると問題が起きました。

• 角度が 0° 近辺だけ極端に速くなる
• 180° 付近で急激に遅くなる
• 全体のバランスが崩れる

つまり、「それっぽい」数式を書いただけでは、
レースとして自然な動きにならなかったのです。

ここで初めて、

数式として正しくても、体験として自然とは限らない。
その違いに気づいたとき、設計の軸が変わりました。
ロジックは厳密に、見せ方は“評価”ではなく“状態”として表現すること

だと気づきました。

正規化の罠

次に試したのが、角度差を 0〜1 に正規化する方法でした。

1.0 + (…) * 0.4

この「0.4」という値は、実はかなり試行錯誤しています。

• 0.2 では差が出ない
• 0.8 では極端すぎる
• 0.4 でようやく自然に見える

ここで私は学びました。

モデルは数式で正しくても、
体験として自然とは限らない。

ゾーンが増えすぎた事件

次の迷走は「ゾーン設計」です。

最初は単純に、

• 速い／遅い
• 跳ねる／跳ねない

の4分類でした。

ところが私は途中で欲張りました。

• 超高速ゾーン
• 低空飛行ゾーン
• 反発ゾーン
• 逆流ゾーン

など、どんどん増やしてしまったのです。

結果どうなったか。

• 条件分岐が増える
• 説明文が複雑化する
• ユーザーが理解できない

完全に“設計の肥大化”でした。

そこで一度、全部削りました。

最終的に残したのは、たった4つ。

• 追い風
• 慎重
• 楽しさ重視
• 整える

減らすことで、構造が安定しました。

detect_zone 二重定義事件

Python

def detect_zone(...):

気づかないまま、下にもう一度同じ関数を定義していたのです。

Pythonは後から定義した方を有効にします。

つまり、
上で書いたロジックが無効化されていた。

挙動がおかしいのに原因が分からず、
かなり時間を失いました。

このとき痛感したのは、

設計が頭の中だけにあると、破綻に気づきにくい

ということです。

以降、ロジック変更時には必ず

• 何を消したか
• 何を置き換えたか
• 条件は重複していないか

をAIと一緒に確認するようになりました。

発達特性とロジック設計

私は発達特性の影響で、

• 細部に気を取られる
• 全体構造を見失う
• 途中で拡張しすぎる

という傾向があります。

今回もまさにそれが出ました。

しかし今回は違いました。

AIとの対話を通じて、

• 「この条件は本当に必要？」
• 「分類は増やすべき？」
• 「UIとして分かりやすい？」

と、逐一立ち止まることができました。

結果として、

迷走はしたけれど、破綻はしなかった。

これは私にとって大きな変化でした。

ロジック設計で得た学び

今回の迷走から得たのは、

1. 数式は体験設計とセットで考える
2. 分類は増やすより削る方が強い
3. 設計は必ず言語化して確認する

という基本でした。

当たり前のようで、
以前の私はそれを安定して実践できていませんでした。

次回予告

設計がようやく固まりかけた頃、
私は次の壁にぶつかります。

Swiss Ephemeris の導入。

天体計算ライブラリを入れた瞬間、
環境構築と時刻計算で完全に詰まりました。

次の記事では、

【マイレース開発記録④】Swiss Ephemeris導入で詰まる

を書いていきます。