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

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

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

Предыстория

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

После долгого исследования плагина и кода поведения мобов я нашел проблемное место. Это была одна безобидная строчка в проекте с больше чем 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. Каскадное изменение поведения там, где это не нужно, но где используется статическая зависимость.

Но ведь 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.