Комментарии 33
Помнится среднее из трёх случайных чисел высмеивалось как пример г-нокода с комментариями вроде «true random». А тут даже его применение описано.
Хороший анализ, но вы верно подметили, что зачастую имеет место быть схожая проблема.
Как видим, в итоге ничего общего с вероятностью 1 к 10000, но для целей геймплея этого, возможно, было достаточно. Хотя больше похоже на ненамеренное сокрытие реальных вероятностей от самого разработчика, что может приводить к неправильным решениям в будущих доработках программы.
Ещё у меня есть предположение, что часть подобных генераторов случайных чисел имеют определённые уязвимости, которые можно использовать. К примеру если при промахах повышается вероятность, то возможны ситуации стрельбы со слабого оружия/способности для набивания промахов, чтобы потом попасть сильным оружием/способностью с повышенной вероятностью.
К примеру если при промахах повышается вероятность, то возможны ситуации стрельбы со слабого оружия/способности для набивания промахов, чтобы потом попасть сильным оружием/способностью с повышенной вероятностью.
Это, впрочем, может быть и самостоятельной игровой механикой.
Другое дело, что в мультиплеерных играх это плохое решение.
return(4); //chosen by fair dice roll
//guaranteed to be random
Скажите, пожалуйста, а почему не используют, скажем, медиану от 5-10 рандомных значений? Это должно быть крайне близко к истине. И не сложно.
Случайное число ведь генерируется в диапазоне 1..100 (или больший диапазон, если надо избавиться от ошибок малых чисел).
А при использовании медианы будет получена просто случайное число, которому «посчастливилось» выпасть больше 1 раза.
Может я неправильно Вас понял.
Попробовал набросать немного кода. После 20 минут понял что первый абзац в моем комментарии выше надо умножить еще на 10. Как минимум. :)
Потом начал думать что рандом не так уж и плохо. При шансе 60% попасть 1 раз из 10 можно. Кто знаком с теорией вероятностей понимает, что это нормально. Всякое бывает. Конечно, не уверен что для игры это хорошо.
Накидал просто скрипт на PHP. Поставил в конфиге 1000 подходов по 10 повторений, вероятность попасть 60%, результаты:
Array
(
[1] => 1
[2] => 13
[3] => 30
[9] => 45
[4] => 99
[8] => 121
[5] => 202
[7] => 231
[6] => 258
)
9
Указано: [попаданий из 10 раз] => количество событий (из 1000 подходов), в конце — это максимум попаданий подряд (т.е. был случай, или несколько, когда в подходе из 10 ударов при вероятности попасть 60% было 9 попаданий подряд).
В принципе, не все так плохо с чистым рандомом. Мы видим что диапазон 5-7 попаданий занимает: ((202 + 231 + 258) / 1000) * 100 = 69,1% всех случаев. 8 и 4 попаданий случаются примерно в 1 из 10 подходов по 10 ударов. Т.е. достаточно редко. Бывает и круто повезло (8), и не твой день (4). 9 раз удалось попасть лишь в 4,5% случаев. 10 раз ни разу. 2 раза — 1,3% и 1 раз попали в 1 из 1000 подходов по 10 ударов.
А вот то же самое для 15%:
Array
(
[5] => 3
[4] => 55
[3] => 134
[0] => 185
[2] => 286
[1] => 337
)
3
Больше 5 раз попасть не удалось, и то это случилось лишь в 3 из 1000 подходов. 95% лежат в пределах от 0 до 3 попаданий.
Конечно, математика математикой, но тут надо брать реальную игру и проводить плей тесты. Я вполне согласен с тем, что при вероятности попасть 60% игроки будут ожидать попасть 6 раз из 10 ударов. А это, судя по всему, красиво сделать можно только проводя коррекцию новых значений на основе данных от предыдущих попыток. Впрочем, и чистый рандом, когда игрок иногда может попасть очень много или очень мало, тоже выглядит весьма интересно. Как по мне.
Я бы реализовывал (в контексте «из 100») таким образом: вероятности генерируются заранее (последовательность рандома), как 60 «да» и 40 «нет», а дальше эта последовательность shuffle. Каждый следующий берёт элемент из этого пула. Спустя 100 ходов будет точно 60 «да» и точно 40 «нет». В принципе, для уменьшения предсказуемости, можно менять размер пула (100, 200, 300) случайным образом. Но всё время поддерживать рандомную справедливость на ограниченном окне бросков.
Только там вероятности событий нельзя напрямую в генераторе «подкрутить»…
И насколько мне известно в Warcraft 3 такой механики не было.
Вспомнил про округление до кратных 5, точно, спасибо, память подвела. Её не было при использовании скриптованных способностей, что логично. А в стандартных была.
Кстати та табличка из первой доты судя по англоязычному источнику, то есть это как раз вероятности из варкрафта, полагаю в доте 2 они перенесены без изменений.
Вообще идея хорошая и легкореализуемая, но я не согласен (с информацией из статей), что на практике сложно использовать знания о таком рандоме, особенно в случае защитной способности.
Предположим у нас вероятность попадания 40%. В начале мы генерируем число [0,100).
При каждой проверке при прибавляем к числу вероятность попадания. Если число больше 100, то мы попали, вычитаем 100. Число 100 взято для целочисленных процентов, если проценты дробные, то вы поняли. Можно и дробное [0,1) генерировать.
Пример:
0. начальное значение — 50.
1. 50+40 = 90 < 100 -> промах
2. 90+40=130 > 100 -> попадание -> число 30
3. 30+40 = 70 < 100 -> промах
4. 70+40=110 > 100 -> попадание -> число 10.
Таким образом у нас при вероятности в 40% никогда не будет 2 попаданий подряд, и при этом из 3 хотя бы 1 попадёт.
Таким образом у нас при вероятности в 40% никогда не будет 2 попаданий подряд
Очень многим будет казаться пресным и неестественным. Тут должна быть вся механика на это настроена.
Уклонение имеет преимущество, когда урон неравномерный и есть источники, блокировка которых полностью выгоднее, чем просто уменьшение урона(ну или там какой-то эффект, который не пройдёт, к примеру оглушение).
Защита даёт преимущество при хорошей регенерации или вампиризме, когда нет критического урона, который может убить, несмотря на защиту.
В общем случае они должны быть равны при прочих равных.
Но в общем случае защита более предсказуема, уклонение даёт вероятность победить там, где с защитой точно нельзя. Выбрать вариант с меньшей дисперсией(то есть защиту) вполне рациональное решение в большинстве случаев.
Речь не об определении числового % вероятности попасть. А о реализации алгоритма расчета самого события на основе этой вероятности. Или даже цепочки таких событий.
Так мило смотреть, как в сообществе разработчиков витает идея, которая вот-вот должна сформироваться в последовательную научную теорию :)
"Честную случайность" можно формализовать как квазислучайную последовательность. Такие последовательности могут проходить тесты на случайность, но заполняют область значений "более равномерно", что может быть полезно для эффективного численного интегрирования и прочих Монте-Карло штук.
Способы применения и искажения меткости в играх. Наглядные графики для сравнения