bash.im ithappens.me zadolba.li

Игры

13486

Компьютер решил развеяться

6 ноября 2015, 08:00

Сижу на работе, скучаю, гоняю игрушки, никого не трогаю.

Звонок. Соседка по квартире.

— Привет, тут у тебя компьютер сам работает! Там на нём какая-то игра идёт, он сам в неё играет и шумит на всю квартиру! Что делать?!

А я ведь как игрушки гоняю? На рабочем компе по понятным причинам ставить ничего нельзя, поэтому я предварительно оставил домашний комп включённым и подключился к нему удалённо. Сижу, играю во второй фоллаут и даже не подозреваю, что колонки включены и в три часа ночи не дают людям спать.

Она прекрасно знала, что у меня ночная смена, я уходя попрощался. Она стучала в дверь, звала того, кто там играет, потом не выдержала и зашла в комнату.

Сижу теперь, думаю, хорошо хоть она не взяла инициативу в свои руки и не стала святой водой его окроплять.

13434

Совпадение? Не думаю!

19 августа 2015, 08:00

Вступлюсь за честь коллег из геймдева.

Во-первых, где вы видели, чтобы обычный рандом был с нормальным распределением? Спору нет, есть всякие мат. библиотеки, позволяющие привязать его к любой функции распределения, но кто же их будет специально искать и использовать, не зная, что это такое? Бывают глупые ошибки типа произведений рандома (или рандома от рандома).

Во-вторых, сессия для инициализации рандома используется в одиночных играх с целью борьбы с читерской магией load-save. Другого смысла постоянно дёргать seed просто нет.

В-третьих, игрокам вообще много что кажется, и они с радостью это интерпретируют как факты. Плюс — confirmation bias. Я помню случай, когда игроки были свято убеждены, что по случайному номеру в ссылке для предотвращения кеширования можно было определить успех ремонта предмета. И никого не смущало, что к скрипту шли десятки обращений в секунду и от момента генерации ссылки до последующего запроса рандом дёргался более тысячи раз.

Это же касается вообще любых якобы повторяющихся паттернов в рандоме. И «вычисления алгоритма работы». Чего его вычислять — всё есть в открытом доступе, почти всегда используется штатная функция выбранного языка разработки. Только никому это знание ничего не даёт.

Искренне порадовался аргументу про сокращение выборки. Ясное дело, что чем меньше выборка, тем более она неравномерна — это очевидно. Нетрудно получить «решку» в 8−10 случаях из 10, шанс на это чуть более 5%. А вот получить её в 80−100 случаях из 100 уже вряд ли удастся хотя бы раз за миллион попыток.

P.S. Ну, а парень из предыдущей истории просто не учёл, что по умолчанию большинство генераторов псевдослучайных чисел инициализируются от текущего времени с точностью до секунды. Так что, запустив одну и ту же программу на разных машинах, вторая из которых отстаёт примерно на пару секунд, можно получить полностью идентичные результаты.

13432

Fair dice roll

Великий корейский рандом, говорите? Всего лишь особенности работы генератора псевдослучайных чисел. Это очень хорошо, что вы только IP с его помощью формируете и ничего более, куда печальней дела обстоят в геймдеве, я вам скажу.

Уже более пятнадцати лет я наблюдаю пляски разработчиков игр вокруг рандомизаторов, и мне слегка несмешно временами, такое ощущение, что матчасть даже не пытались изучать:

  • if (rand(10000)==1) и прочие подобные глупости при использовании генератора с нормальным распределением.

  • Выбор по таблице добычи при помощи генератора с нормальным распределением. Если сюда добавить ещё разный шанс трофеям, то для некоторых позиций вырисовывается совсем запредельная схема.

  • Генерация энтропии на основе данных игрока/сессии/сервера. Обычно легко прослеживается и явно заметна.

  • Выборка случайного элемента из некоторой части списка для придания «большей случайности». За пределами добра и зла. В одной известной игрушке про убийство монстров это привело к тому, что можно было сутками пытаться выбить шмотку, которой просто не может выпасть в текущей сессии.

  • Скрытая манипуляция выборкой под видом случайного выбора.

  • ...и даже сочетание всего вышеперечисленного.

Самое смешное, что когда пользователи жалуются на симптомы подобных решений или вычисляют примерный алгоритм работы рандомизатора, начинается тотальное отрицание всего и вся. В крайнем случае, проверки алгоритма за пределами возможного матожидания, например: «Вот, смотрите, мы протестировали алгоритм на выборке из 300 выстрелов, всё чудесно». После этой фразы уже объяснять, что если сократить количество итераций до 30, картина меняется в корне, абсолютно бесполезно.

Очень хотелось бы обратиться ко всем коллегам: если вы пользуетесь радномизаторами в своих приложениях, прикиньте, как их поведение будет отражаться на ваших пользователях, разберитесь в алгоритме, подумайте тщательно. А то уже глаз дергается, ей богу.