Как спроектировать игровую математическую модель, забалансить её и не сдуреть. Разбор на практических кейсах.

Мы идём от общего к частному. Задаём системе вопросы на самом общем уровне и постепенно углубляемся в детализацию. Если на какой-то вопрос мы не смогли ответить, значит, скорее всего, мы пропустили какой-то более общий вопрос, от которого зависит рассматривая ступень детализации, в этом случае не стесняемся вернуться на один или несколько уровней абстракции назад.

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

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

В пример общих вопросов к боевой системе можно перечислить следующие:

*) Сколько должна длиться одна битва между двумя воинами? Минимальное время, максимальное, срединное

*) Какова вероятность победы для игрока? Для ии?

*) Насколько на исход влияет прокачка? Насколько скил? Насколько знание соперника?

*) С какой скоростью прокачивается игрок? Сколько дней, часов, минут или битв должно пройти перед тем, как игрок достигнет уровня n? Насколько быстрее прокачка вначале, насколько в конце (кривая развития)

*) Что меняется в битвах по мере прокачки или продвижения по контенту?

*) Насколько лёгкие битвы отличаются от сложных? Какие показатели в них меняются?

*) Сколько времени уходит на получение одной шмотки? Редкой шмотки? Легендарной шмотки?

*) Что вообще понимается под термином "сложность"? Винрейт? Требуемый объём внимания? Ещё что-то?

*) Насколько меняется сила героя от прокачки? Чем отличается герой уровня n от уровня n+1?

*) Насколько сложнее герою сражаться с монстрами более высокого уровня? Насколько легче сражаться с монстрами более низкого уровня?

*) Как меняется награда при сражении с монстрами различных уровней? Как меняется скорость развития персонажа или экономического развития при различных стратегиях поведения? При сражении с более слабыми монстрами? Более сильными?

*) Что в целом должно мотивировать игрока вступать в более сложные сражения вместо более простых? (если у игрока есть выбор). И должен ли игрок в целом быть на это мотивирован.

*) В целом за счёт чего достигается внешняя мотивация? За счёт чего внутренняя?

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

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

Пока что оставим скилозависимые механики в стороне, их балансить нужно с аналитикой. На этот раз мы сосредоточимся на том, что сможем определить здесь и сейчас без отвлечения внимания на аналитику.

Поговорим о балансе урона и брони. Казалось бы, тривиальная тема, основа основ, но и в ней есть подводные камни.

Итак, вначале нужно определиться со временем битвы. За сколько секунд два юнита могут друг друга убить. Или за сколько тычек, если скорость атаки одинаковая.

Если мы выберем быстротечные сражения, чтобы враги убивались за 1-2 тычки, то мы тем самым обесценим дебаффы и в некоторой степени тактические скилы. Зачем тратить ход на наложение проклятия или замедления на врага, если этот же ход мы можем потратить просто на его физическое устранение?

С другой стороны, если мы сделаем битвы слишком затянутыми, это может негативно отразиться на темпе и ритме геймплея. Может отразиться, а может и нет, зависит от разнообразия ситуаций внутри одной битвы. Если ход битвы идёт монотонно и однотипно, она надоест быстро. Если в рамках одной битвы постоянно меняются ситуации, бросающие вызов стратегическому мышлению, как это происходит, например, в Divinity: Original Sin 2 (на высокой сложности), то и надоесть она с высокой долей вероятности - не успеет.

Конечно же, на продолжительность битвы влияет не только количество совершённых тычек, но и всяческие абилки, увороты и прочее, но пока мы определимся в тычках.

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

Кто-то может подумать, что это шизофрения, сначала утверждать, что вопросы на общем уровне должны быть закрыты как можно раньше, чтобы не было переработок, а потом пренебрегать менеджерами с их прогнозами и призывать к многочисленным итерациям. Но внимательные читатели, возможно, заметили, что я не призывал закрывать общие вопросы как можно раньше. Я призывал их задавать в правильном порядке в нужные моменты времени.

Это нормальная ситуация, когда вопросы заданы, но они остаются без ответа. Само наличие подвешенных вопросов позволяет выстраивать правильную и гибкую архитектуру проекта, которая не раскрошится при будущих ребалансах (а они обязательно будут) или при вводе новых механик.

При проектировании новых систем будет понятно на какие общие вопросы они опираются, и при переосмыслении этих общих вопросов зависимые от них механики не останутся без внимания.

Например. Мы ранее задали себе вопрос за сколько битв герой улучшится с 59-го уровня до 60-го. Навскидку определили, что за 30 битв. А из других систем знаем, что за битву на 59-м уровне герой в среднем получает, к примеру, 1000 ед. опыта. Следовательно, мы установили, что для перехода от 59-го до 60-го уровня герою нужно накопить 30 000 ед. опыта.

А потом мы переосмыслили кривую развития и убедились, что 30 битв - это слишком быстро, и нужно сделать 100 битв для левелапа. Но так как системы с взаимосвязями у нас уже настроены, нам достаточно изменить кривую развития, а формулы автоматически пересчитают все зависимые внутриигровые числа. Или не автоматически, или в ручном режиме, как вам угодно, но главное, что это будут контролируемые процессы, и каждая новая итерация не вынудит полностью менять подход к балансу всего проекта.

Как видите, достаточно было вовремя задать нужные вопросы при проектировании системы. И даже если ответы на них несут временный характер или вовсе отсутствуют, это уже позволит выстроить целостное видение проекта и не бояться будущих правок.

Вернёмся к вопросу о продолжительности битвы. Мы столкнулись с ситуацией, что он (вопрос) зависит от других более общих вопросов. Насколько разноплановые будут сражения? Как часто относительно общего геймплейного времени игроку придётся сражаться? За счёт чего разнообразие сражения будет обеспечиваться? Будут ли абилки с дебаффами? Если да, то имеет смысл затянуть сражения, если нет - то стоит их делать более быстротечными.

Навскидку определим, что мы хотим разнообразить битвы тактикой и скилами с различными эффектами.

Также постановим, что тактическое разнообразие в игре будет расти по мере потребления контента и роста уровня героя. Следовательно имеет смысл привязать продолжительность битв к таймлайну развития.

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

Мы определили, что продолжительность сражений - не константа, а параметр, зависимый от уровня контента. Можем представить в виде графика на основе временных значений (просто чтобы лучше понимать сиcтему). Для удобства пока что поставим знак равенства между количеством тычек для победы и продолжительностью сражения.

Согласно графику, при сражении с мобом 1-го уровня мы его побеждаем за 5 тычек, а при сражении с мобом 10-го уровня (героем аналогичного уровня) - за 10 тычек. Наверняка этот график изменится и не раз, но на данном этапе важно сделать точку опоры, чтобы мы знали что в балансе от чего зависит.

Это означает, что на 1-м уровне некая «выживаемость» моба должна быть выше «вредоносности» героя в 5 раз.

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

*) очки здоровья

*) поглощение урона бронёй

*) вероятность уклониться от атаки (как свойство юнита)

*) вероятность уклониться от атаки (как скил среднестатистического игрока уровня n, полученный через аналитику)

и т. д.

Под вредоносностью понимается совокупность параметров, влияющих на мат. ожидание нанесённого урона. К таким параметрам может относиться:

*) базовый урон или базовый диапазон урона

*) шанс и множитель критического удара

*) вероятность попадания по цели (как свойство юнита)

*) вероятность попадания по цели (как скил среднестатистического игрока уровня n, полученный через аналитику)

Таким образом, из примера выше, совокупность здоровья, брони, шанса уклонения у моба должна превосходить совокупность базового урона, крит. шанса и вероятности попадания игрока в 5 раз при их 1-м уровне.

Допустимый вариант если у среднестатистического моба будет 60 ед. здоровья, 50% поглощения урона бронёй (что удваивает выживаемость), и ещё 50% шанс уклонения от удара (что ещё раз удваивает выживаемость), т. е. он будет обладать выживаемостью в 240 ед.

А герой тем временем будет обладать 40 ед. базового урона, и ещё 20% шанс нанести x2 урон, что означает 48 ожидаемого урона, или, если по терминологии статьи, 48 вредоносности.

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

Мы можем сначала определить график роста вредоносности, и под него подстроим график роста выживаемости.

Сталкиваемся с ещё одним общим вопросом. Как вообще должна расти выживаемость и вредоносность? Хотим ли мы, чтобы разница с каждым следующим уровнем значительно ощущалась, или мы хотим, чтобы разница между первым и последним уровнем была не так уж велика?

Если мы выберем динамичный рост по геометрической прогрессии, то мы обеспечим выброс эндорфинов на каждом полученном уровне, когда игрок будет видеть заветные «+20% к здоровью» относительно предыдущего уровня. Успешность этой математической модели доказали многочисленные айдлеры и кликеры. При этом числовые показатели могут достигать сначала многих миллионов и миллиардов, потом септиллионов, а потом и вовсе переходить на экспоненциальный формат отображения чисел а-ля 1e+86.

Но подобная модель подходит далеко не каждой игре. У неё есть ряд аспектов, которые могут противоречить другим игровым системам. Перечислим несколько из них.

1) К очевидным минусам можно отнести быстрое устаревание низкоуровневого контента. Чем выше рост силы между уровнями, тем меньшая область игрового мира будет населяться мобами, чья сила сопоставима с силой игрока. Если рост будет слишком большим, то это приведёт к ситуации, когда игрок будет вынужден сражаться лишь в регионе своего уровня n. Регионы уровня n-1 будут слишком слабыми, а регионы уровня n+1 слишком сильными.

2) Вдобавок, вслед за взрывным ростом мощности мобов по их уровню, придётся проработать взрывной рост наград за убиение этих монстров, что разгоняет инфляцию и приводит к быстрому устареванию приобретённого игрового контента. При определённых обстоятельствах это может вызывать раздражение у игроков и привести к общему обесцениванию вещей. Если вещи быстро устаревают, то и привязываться к ним нет смысла, а значит меньше искушения стараться для получения более качественной награды на текущем уровне. Какой смысл стараться получить в награду на 10% больше ценности, если через 2-3 уровня любая награда будет более ценна в десятки раз? Вместо взрывного роста наград можно было бы прибегнуть к системе штрафов при получении вознаграждения за прохождение контента более низкого уровня, но математически эффекты от этих решений будут сопоставимыми между собой.

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

Так, например, если у игрока есть 10 ед. энергии каждый день, и он может потратить 1 ед. энергии на прохождение любой миссии, то в этом случае рост наград от миссии к миссии можно сделать более медленным. Если игрок пройдёт 10 миссий 5-го уровня - он получит 50 ед. золота, а если пройдёт 10 миссий 6-го уровня - он получит 55 ед. золота. При этом разница в мощи противников между миссиями может быть хоть 40%, всё равно у игрока сохраняется мотивация играть на пределе своих возможностей, ведь из-за лимита по энергии он не может компенсировать качество боёв их количеством. Но такая система больше подходит мобильным автобатлерам. Однако если именно это и нужно, то подобная система снимает множество вопросов.

3) Если в игре планируется кооператив, то большая разница между уровнями друзей или соперников не даст им играть в сопоставимых условиях. Если разница между мощью двух уровней будет процентов в 40%, то для комфортной игры два друга обязательно должны быть одинакового уровня. Иначе один из них будет полностью бесполезным. Однако, и этот аспект можно сгладить, если динамично менять сопротивляемость моба по отношению к игроку более высокого уровня, чтобы они сражались примерно на равных. К играм, которые успешно использовали подобный подход, можно отнести Desteny 2. Но если неаккуратно его реализовать, то можно вызвать у игрока разочарование от системы прокачки, если он сочтёт, что прокачка не даёт преимуществ.

4) И, наконец, этот подход может негативно повлиять на иммерсивность игрового опыта. К примеру, это бы не подошло таким играм как «готика». Но с другой стороны и иммерсивность нужна далеко не каждому проекту.

*) Можете в комментариях дополнить список своими пунктами.

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

Так как у нас есть кривая вредоносности, и кривая продолжительности битвы, то сопоставив их мы получим кривую выживаемости.

Проверим данные на 20-м уровне. Согласно кривой продолжительности боя, моб должен погибать с 10-й тычки. На 20-м уровне моб имеет 2940 ед. выживаемости, а игрок 294 ед. вредоносности, т. е. в 10 раз меньше. Значит на данном этапе ошибки нет.

Но чем глубже мы будем погружаться - тем больше подводных камней начнём встречать.

Итак, мы определили, что средняя выживаемость моба будет иметь значения {240; 281; 319; 371; 427; 485; 561; 639; 731; 836; 942; 1082; 1238; 1394; 1583; 1789; 2033; 2309; 2590; 2940} для {1..20} уровней.

И мы помним, что выживаемость - это совокупность таким параметров как здоровье и поглощение урона бронёй.

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

Если здоровье расти не будет, или будет, но медленно, это приведёт к тому, что основная нагрузка на рост выживаемости падёт на рост статов экипировки по уровню. Обновление амуниции станет более приоритетной задачей, а пренебрежение к экономической составляющей геймплея станет сильнее наказываться. Если игрок не в состоянии купить предметы своего уровня, то он может не быть готовым встретить препятствие своего уровня, особенно если мощь мобов растёт экспоненциально. Это наказание может быть фатальным для геймплея, если в результате принятия решений в других системах мы не допустим игрока к перепрохождению контента более низкого уровня, чтобы он мог накопить необходимые ресурсы для обновления экипировки и перехода в более сложные зоны. Похожая проблема может случиться при совокупно несовместимых решениях автолевелинга в, например, The Elder Scrolls IV: Oblivion с возможностью прокачивать уровни персонажа через небоевые статы.

Как всегда - выбирайте тот путь, который наиболее подходит исходя из ранее заданных вопросов от вас системе. Ну а мы для примера предположим, что здоровье по уровню будет расти медленно, и основная нагрузка ляжет на рост эффективности брони. Просто потому, что вслед за этим решением вскроется несколько интересных кейсов, которые хотелось бы разобрать в рамках этой статьи.

Давайте рассмотрим на примере управляемого игроком героя, так как это нам позволит плавно перейти в экономику. Предположим, что рост здоровья у игрока и мобов будет линейным и небольшим. По 5 фиксированных единиц на уровень. На 1-м уровне это будет 60 ед. здоровья, на 20 - 155.

Механику уворотов оставим в стороне, притворимся, что её нет, сконцентрируемся на броне.

На каждом уровне броня должна поглощать ровно столько урона, чтобы итоговая выживаемость соответствовала ранее выявленной кривой выживаемости. Настройка этого параметра - не самая очевидная задача, и здесь допускают ошибки даже в крупных студиях. Поэтому теме влияния брони на выживаемость мы уделим особое внимание.

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

А если поменяем условие? У юнита броня поглощает 98% урона, как мы должны изменить это поглощение, чтобы он стал ещё в 2 раза живучее?

Ответ: в первом случае нам нужно изменить поглощение урона бронёй с 50% на 75%. Во втором случае нам нужно изменить поглощение бронёй с 98% до 99%.

Юнит с 75% поглощения выдержит вдвое больше ударов, чем аналогичный юнит с 50% поглощения.

Юнит с 99% поглощения выдержит вдвое большее количество ударов, чем юнит с 99% поглощения.

Чувствуете где собака зарыта? Нам нужно смотреть не на то, сколько урона поглощается, а на то, сколько урона остаётся.

При изменении брони с 50% на 75% мы меняем наносимый юниту урон с 50% до 25% (т. е. наносится вдвое меньше урона, а значит жить он будет вдвое дольше).

Аналогичный процесс происходит когда мы меняет броню с 98% до 99%, мы меняем наносимый юниту урон с 2% до 1%, т. е. вдвое уменьшаем наносимый урон, а значит вдвое увеличиваем его выживаемость.

Если мы знаем, что юнит имеет, предположим, 80% поглощения урона и 250 ед. здоровья, то мы можем рассчитать его выживаемость в бою с рукопашным уроном по следующей формуле:выживаемость = здоровье / (1-поглощение) = 250 / (1-0.8) = 250 / 0.2 = 1250 ед.Т. е. юнит сможет выдержать 1250 ед. физического урона перед своей гибелью.

Если нам известно здоровье юнита, например в 100 ед, и мы должны дать ему такую броню, чтобы его выживаемость возросла, к примеру, в 5 раз, то мы должны дать ему такую броню, которая будет поглощать =1-1/5 = 80% урона.

Теперь мы можем сопоставить кривую выживаемости с кривой здоровья и на каждом этапе определить поглощение урона, которое должна обеспечивать броня на каждом уровне. По формуле:

поглощение = 1 - 1 / (выживаемость / здоровье)

Таблица получилась правдивая, но для игрока, возможно, не интуитивная. Ему может показаться, что разница между поглощением в 75% и 80% не так уж велика (хотя это не будет соответствовать истине). Чтобы интуиция не обманывала игрока - есть смысл ввести понятие «рейтинг брони», который рос бы линейно, но под капотом преобразовывал рейтинг в необходимую степень поглощения.

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

Сделаем начальное здоровье на уровне начальной выживаемости, и будем прибавлять по 10 ед. здоровья на уровень. А остаток требуемой по уровню выживаемости будем компенсировать через поглощение бронёй. Таблица примет нижеприведённый вид. И из неё станет ясно, что на начальных уровнях наказание за слабую экипировку не столь сильное, как на более поздних уровнях. И прогрессия брони стала более ощутимой, так как её рост идёт не с 75%, а с 0%

В игре Warcraft 3 есть классная формула, которая определяет поглощение урона по показателю брони. Классная, так как ею удобно управляться с точки зрения баланса, но принцип её работы путает многих игроков, и даже многих профессионалов.

В сообществе ошибочно полагают, что рост эффективности брони идёт по убывающей полезности, но это не так.

Работает следующая формула:

поглощение = 1-1/(броня * 0.06+1)

Получается следующая таблица:

Неподготовленный пользователь вероятнее всего сочтёт, что на более высоких показателях брони прирост эффективности уже не столь существенен. Если на начальных значениях идёт прибавка по 5% поглощения, то ближе к 10 брони прибавка идёт уже по 2%. Но мы-то с вами уже подготовленные пользователи, так как разобрали кейсы выше из этой статьи.

На самом деле рост эффективности брони для выживаемости идёт линейно, и прибавляет по 6% на каждую единицу брони. Чтобы убедиться в этом - добавим новый столбец и преобразуем поглощение в рост выживаемости.

С одой стороны пользователю может показаться контринтуитивным принцип работы брони, когда поглощение определяется по рейтингу брони. Но с другой стороны подсознательно пользователь будет считать, что доспех, дающий +600 ед. брони в 2 раза круче, чем доспех, дающий +300 ед. брони, и с повышенной вероятностью сделает правильные выводы в оценке этих двух предметов, чем если бы на них было указано «поглощает 98% урона» и «поглощает 99% урона».

Да и стак элементов брони проще прогнозировать. Если игрок наденет кирасу с 5 ед. брони, шлем с 2 ед. брони и поножи с 3 ед. брони, то мы будем знать, что 10 ед. брони обеспечат персонажу 60% дополнительной выживаемости против физических атак.

Один из первых вопросов, которые разработчики могут себе задать, это рандомизировать урон, или делать его фиксированным.

Лично мне почти во всех ситуациях нравится его рандомизировать, и вот почему (как всегда, разберём на кейсе).

Если кратко - то для повышения ожидаемой полезности при каждом улучшении оружия.

Если вы не поняли что только что было сказано - не беда! Далее по тексту мысль будет раскрыта.

Представим, что в лесу обитают волки с 10 единицами здоровьяА оружие героя наносит 5 ед. урона.

Следовательно герою потребуется по 2 удара для убиения каждого волка.Что если мы хотим вознаградить героя более качественным мечём и дадим ему оружие с уроном в 6 ед?Эффекта не будет. По крайней мере при сражении с волками. Герой как прежде будет убивать волка с 2 ударов.Это касается и оружия с 7 ед, и 8 ед, и 9 ед. урона.Только оружие с 10 ед. урона даст эффект убиения волков 1 удара.

Большие скачки полезности прокачки могут быть проблемой для вашего баланса и для ощущения игры для игроков.

Теперь представим себе вторую ситуацию. Оружие имеет разброс урона.

В среднем такое оружие убьёт волка с 2.408 удара

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

В среднем - 2 удара.

В среднем - 1.8 ударов

..

В среднем - 1.2 удара

Как видим, ожидаемая полезность оружия возрастает при каждой единице урона. Ситуации, когда улучшение бесполезно встречается намного реже, чем в ситуации без разброса.Надо только следить за тем, чтобы разброс был достаточным для влияния на статистику.Так, если оружие имеет разброс 51-53, то оно всегда будет убивать моба с 100 ед. здоровья со второго удара. Так что правилом хорошего тона было бы настроить систему так, чтобы дисперсия ощущалась относительно базового значения.

При биномиальном распределении срединные значения выпадают значительно чаще крайних.

Самый частый пример - это бросок костей. Если бросить две 6-и гранние кости, то они в сумме дадут результат от 2 до 12. Но крайние значения будут выпадать реже. Например, чтобы в сумме кости показали 2, нужно чтобы и первая кость показала 1 (вероятность 1/6), и вторая кость показала 1 (вероятность 1/6). Вероятность того, что эти исходы случатся = 1/36.

Есть игры, и Warcraft 3 среди них, которые имитируют бросок костей, чтобы игрокам случайность реже казалась несправедливой. Если вы зайдёте в редактор объектов warcraft 3, то увидите, что урон и выпавшее золото с монстров определяется броском нескольких костей. Таким образом мобы редко наносят минимальный и максимальный урон, и из них редко выпадает минимальное и максимальное количество золота.

Дадим герою оружие, наносящее 2d4 ед. урона (2 кости по 4 грани),

такое оружие при каждой атаке, к примеру, с шансом в 6.25% нанесёт 2 ед. урона, и с шансом в 25% нанесёт 5. ед. урона. Ниже представлена таблица с распределением урона:

Рассмотрим дичь по-крупнее, например медведя с 20 ед. здоровья.С таким оружием понадобится от 3-х до 10 ударов на убийство медведя. Но скорее всего, с шансом в 51% понадобится 4 удара. В среднем на убийство каждого медведя будет требоваться 4.45 ударов.

Ниже показано распределение:

А теперь представим, что вместо 2d4 мы вооружились оружием 1+1d7, т. е. такое оружие тоже будет наносить от 2 до 8 ед. урона, т. е. такому оружию тоже понадобится на уничтожение медведя от 3-х до 10-и ударов. Но распределение будет уже другим, более размазанным:

Мы уменьшили число факторов, влияющих на результат, поэтому срединные результаты стали выпадать реже, а крайние чаще.

Последний пример на сегодня. Оружие c уроном 8d4 (8 дайсов по 4 грани у каждой) против противника с 100 ед. здоровья. Этот пример показывает, что несмотря на большое количество вариантов развития событий, всё-равно в конечном итоге с вероятностью в 99.5% медведь будет уничтожен либо 5, либо с 6 удара. Поэтому если вы не хотите, чтобы почти все битвы оканчивались одинаково несмотря на рандом, вам нужно находить баланс в количество влияющих на неё факторов.

Для статьи я составим калькулятор на LUA, можете им пользоваться:

(Из РФ без VPN могут быть проблемы с доступом к сервису. Если Вы не можете перейти по ссылке - напишите в комментариях, я скину код и подскажу как им воспользоваться)

Просто настройте вводные данные и нажмите RUN

Например, если у противника 18 ед. здоровья, а вы ему наносите 2d6+1 урона, то калькулятор покажет следующий результат:

Вызывается функция в конце программы следующим образом:

Опционально можно указать функцию, форматирующую выводимый результат, например так:

При желании можно задать своё распределение урона.

Например, если герой наносит от 2 до 3 ед. урона, но с шансом в 20% может нанести критический удар, утраивающий этот урон, то можно вызвать функцию следующим образом:

Если вы дочитали до этого момента (а не просто пролистнули), то вы мой Герой. Спасибо за это большое -)

Мы рассматриваем больше практических кейсов в нашем уютном VK сообществе. Присоединяйтесь к нему и не забудьте подключиться к одному из наших чатов ;-)