Перестаньте использовать UnityEngine.Random

Как часто вы используете конструкцию Random.valueили Random.Range(float min, float max) ? А как много эту конструкцию использовали разработчики фреймворков или плагинов, которые вы встроили в проект?

В данной статье мы обсудим как сомнительное архитектурное решение от Unity может одной строкой изменить все случайное поведение, сделав него не случайным.

Выжимка для тех, кто спешит

UnityEngine.Random – static класс, который использует реализацию ГПСЧ написанную разработчиком движка Unity на C++.

Если в проекте мы захотим задавать seed, то этот seed применится ко всему объекту Random. В итоге, когда мы ожидаем «случайного» числа или последовательности чисел, они будут не случайны.

Все дело в том, что класс статический, поля и методы статичны. Если мы единожды зададим seed через Random.InitValue(int seed), то его значение будет справедливо для всего класса Random и для всего проекта автоматически.

Решение:

Каждый раз, когда нужно получить число с использованием ГПСЧ, нужно создавать новый экземпляр класса, предоставляющим функционал ГПСЧ .

Ссылка на github

Предыстория

Все началось с того, что я заметил, как в игре, в которой уровни генерировались процедурно, противники начали вести себя одинаково каждый раз при восстановлении старого уровня (вышел из игры, при повторном заходе, тебе предложили продолжить). Когда уровень начинался заново у противников была одна и та же комбинация поведений: сначала налево, потом стреляют, потом от игрока и опять стреляют.

После долгого исследования плагина и кода поведения мобов я нашел проблемное место. Это была одна безобидная строчка в проекте с больше чем 100 сборками и больше чем 60000 строк кода.

Эта строка выглядела так:

UnityEngine.Random.InitState(seed);

По факту эта строка просто позволяла загрузить ранее сгенерированный уровень. Но неявно, так же, она проставляла один единственный seed для всего класса Random

Как такое произошло?

Все дело в том, что UnityEngine.Random является классом, который целиком и полностью состоит из статических методов и полей. Замечательное свойство статических членов (полей, свойств, методов, классов) в том, что мы можем получить к ним доступ без создания экземпляра данного класса. В Unity статические члены инициализируются самыми первыми (как и в .NET в целом). Под них выделяется отдельное место в памяти, в котором они хранятся с момента создания приложения до момента пока приложение не будет выгружено из памяти (закрыто).

Что все это значит?

Это значит, что единожды проставив значение seed’a в класс UnityEngine.Random, этот seed будет использоваться в этом классе до момента, пока мы не закроем приложение или пока не изменим его.

Попробую описать на реальном примере:

• Вы написали генератор лабиринта, конфигурацию которого можно повторить если задать seed,

• Вы используете механику стрельбы и разброса пуль. В итоге, все пули будут разлетаться в четком порядке для заданного seed’a,

• Вы понимаете, что и генератор лабиринта, и механика разброса используют UnityEngine.Random.

Почему это очень плохо?

Как минимум — игроки заметят и в дело вступит эффект отмены.

Как максимум, придется изобретать костыль, чтобы вернуть seed в предыдущее состояние после вызова метода InitState(). Если вернуть значение нельзя, потому что «случайные» значения постоянно используются, то придется перед каждым использование Random принудительно проставлять seed.

var prevSeed = UnityEngine.Random.seed; // с учетом того что в 2019 Random.seed obsolete. UnityEngine.Random.InitState(seed: DateTime.UtcNow.GetHashCode()); var value = UnityEngine.Random.value; UnityEngine.Random.InitState(prevSeed);

Это замечательный пример того, как неправильное использование статических классов. В результате мы получим:

1. Жесткую связность. Неявная завязка на реализацию одного конкретного класса. Он не передается через конструктор, не инжектится через свойство, а мы просто пишем Random.value

2. Каскадное изменение поведения там, где это не нужно, но где используется статическая зависимость.

Рубрика: «А что если»

OrderBy в пространстве имен LINQ постоянно бы мешал коллекции, используя данные из предыдущего обращения к данному методу?

Но ведь Unity заботится об объеме используемой ОЗУ

Нет, не заботится. Это пример плохого архитектурного решения, когда решили использовать ГПСЧ внутри реализации самого движка и одновременно предоставить доступ из C#. Объект загрузится и на протяжении жизни приложения будет всего один экземпляр в памяти. Это параллельно привносит новое неочевидное поведение и обязывает нас использовать один экземпляр Random на весь проект.

Невозможно заранее предсказать какое именно поведение потребуется пользователям. Но дать им право выбора надо.

Вот еще список потенциальных проблем, с которыми можно столкнуться:

• Если внутри движка используется UnityEngine.Random то, мы получим неожиданное поведение компонентов, предоставляемые Unity,

• Скомпилированный в *.dll плагин устанавливает seed. И каждый раз перед вызовом придется проставлять seed. Решить это можно только через декомпиляцию (если финальная библиотека не обфусцирована).

Решение

Использовать System.Random

Пункт сразу отпадает, так как:

• Все реализации полезных методов, которые предоставляет UnityEngine.Random, придется писать самому.

• System.Random аллоцирует 280 байт (248 на массив из 56 элементов, 12 байт на класс и 20 байт на переменные внутри класса). 5 экземпляров — 1кб памяти.

• По производительности System.Random чуть хуже чем UnityEngine.Random.

Собственная реализация

Лучшим решением будет сделать что-то простое, что занимает мало памяти и очень быстро работает.

В результате всех исследований и проведенных опытов, самым простым и быстрым вариантом стал — конгруэнтный мультипликативный алгоритм с модулем от числа 2^31.

Ссылка на исходный код

Я не стал помещать класс в пространство имен, потому что считаю что то, что ниже — проблема архитектора, а не моя.

using Random = UnityEngine.Random; // или using Random = System.Random;

Генерацию seedá я сделал в нескольких вариациях:

• Time — использует структуру System.DateTime и предоставляет достаточно надежное значение seedá, но аллоцирует 208 байт. Потому что DateTime (сюрприз) неуправляемая структура.

• Guid — использует структуру System.Guid и System.Environment.TicksCount. Guid в отличии от System.DateTime работает медленнее, но аллоцирует всего 16 байт и является управляемой структурой (т.е. размещается на стеке и не копируется в кучу).

• Crypto — использует System.Security.Cryptography.RandomNumberGenerator и аллоцирует 4 байта. По скорости сравним с Guid, но данный метод не тестировался на разных платформах. Так же, пара простых строчек, может прибавить к размеру билда, если пространство имен System.Security.Cryptography раньше не входило в ваш билд.

Ссылка на скрипт RandomSeed

Тестирование производительности

Код примитивного бенчмарка

Кол-во аллокаций неуправляемых объектов проверялся таким образом:

var start = GC.GetTotalMemory(true); var rnd = new System.Random(); var stop = GC.GetTotalMemory(true); Console.WriteLine(stop - start); // 280 для Random - соответственно

Значения в таблице — среднее время затраченное на заполнение двумерного массива размерностью NxN:

Тестировалось на ноутбуке ASUS Zephyrus G15 в редакторе. Под разные платформы не компилировалось.

Как установить

Если версия Unity выше чем 2019.3 в файл Packages/manifest.json добавить:

"fastrandom": "https://github.com/vangogih/Dont-Use-UnityEngine.Random.git",

Или просто скачать .unitypackage из раздел Releases

Как дополнить

Предлагайте улучшение через Issue или через Pull Request.