くろめーの山小屋🐑

ゲーム中のちょっとした演出（花びらが舞うなど）を調整しただけなのに、敵の出現パターンまで変わってしまうことがよくありました。こうなると、同じ条件でテストしているつもりでも結果が再現せず、原因の特定に時間がかかります。 原因の一つが、演出とゲーム進行で同じ乱数生成器を使っていることです。擬似乱数のシード値が同じでも、途中で乱数を使う回数が変われば結果も変わってしまいます。 ご存じの方も多いと思いますが、簡単に説明すると、 例えば、乱数が次の順番で取り出されるとします。 0.12 → 0.85 → 0.33 本来は最初の「0.12」で敵の出現位置を決めるはずが、直前に花びらの向きを決める処理が1回追加されると、敵には次の「0.85」が使われます。 花びらを10枚増やし、それぞれの向きを乱数で決めれば、10回分ずれるわけです。 同じ乱数生成器をアイテムのドロップ抽選やマップ生成にも使っていれば、演出の変更が思わぬところまで影響します。 対策の一つは、演出用とゲーム進行用で乱数生成器を分けることです。Unityなら、System.Random のインスタンスを用途別に用意する方法もあります。 ちなみに、大昔の競馬ゲームで、似た仕組みを逆に利用したことがありました。 週末のレースで結果が思わしくなかった場合、リセットしてもう一度レースに臨んでも、結果が変わらないんですね。乱数の状態もセーブされていたのか、同じ結果が再現されます。 ところが、レース前に調教を1回挟むと結果が変わるんです。おそらく調教でも乱数が使われ、レースで使う乱数の順番がずれていたのでしょう。当時はそんな方法で結果を変えていました。 同じシード値でも、乱数を使う順番が変われば結果も変わる。 考えてみれば単純な話ですが、ゲーム進行には関係ないはずの演出が乱数を消費していると、なかなか気づけません。特に「致命的な不具合ではないが、ゲームバランスに影響する」程度の場合はなおさらです。 こういう、一見関係のなさそうな処理同士の依存関係は、意外と見落としやすいんですよね。 #エンジニア #ゲームプログラマー