Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Можно свести всё к простому, если у стороны А бонус к обороне, то у стороны Б это просто минус к DPM (повреждений в минуту)
но бонус может быть огромным.
Гхм, выглядит интересно, но что случилось со старой доброй пошаговой эмуляцией смешанной с методом Монте-Карло?
… и повторяем это еще 100,000 раз, чтобы после построить график.
Вон у вас какие зубодробительные формулы получились
Это экспоненты, логарифмы, гиперболы или, может быть, полиномы? Никак не определите. А знание вида функций важно для интуитивного понимания изучаемой системы.
С такими затратными численными расчетами ваш бот просто не сможет работать в реальном времени.
Боюсь, вы мало имели дела с математикой, если вам формулы из статьи кажутся зубодробительными!
Так для этого же и существуют графики, разве нет?
Кроме того, все-таки обычно геймдизайнеры создают свою систему, а не изучают какую-то чужую
Но есть способы предварительно упростить вычисления. Например, заранее составляется таблица соотношений размена юнитов в боях друг с другом. Условно, сколько нужно юнитов А, чтобы уничтожить тысячу юнитов Б. Затем по ней быстро оценивается взаимная сила армий.
если представляете себе сведение всех условий (тип местности, броня, выучка и т.д.) к одному линейному коэффициенту k. Он в лучшем случае — степенной.
как вы все это будете учитывать?
Легко перепутать, например, экспоненту с гиперболой.
Вы же должны подставлять измеренные вами экспериментально параметры в какие-то формулы?
В том-то и смысл данной статьи и подобных ей исследований, что результаты будут верны для широкого круга систем
Степенной коэффициент k — это как? От чего он зависит по степенному закону? И почему именно степенному? Ведь подобные предположения надо обосновывать.
Не в один день Москва строилась. Мой подход идет от простого к сложному. Со временем, если будет вдохновение, буду усложнять модель.


Если есть такие опасения, то можно по графику воссоздать функцию.
Это легко автоматизируемый процесс. К примеру, редактор после изменения изменении параметров может проводить симуляции и составлять таблицу значений. После чего изменять, а в том числе и добавлять различные особенности и новые виды войск сможет кто угодно.
Условно, сколько нужно юнитов А, чтобы уничтожить тысячу юнитов Б. Затем по ней быстро оценивается взаимная сила армий.
А в вашем случае геймдизайнер обречен на постоянную борьбу с системой уравнений.
Ну нет игровых систем, основанных только на простейшем размене с плавным падением численности.
Везде транзакции, рандом, кучи коэффициентов, мер и контрмер. Иначе, какой интерес?
Работа модификаторов может зависеть от численности нелинейно.
Что происходит в других точках, где функция не вычислялась — вы не знаете. Как она ведет себя за пределами того интервала, в котором строился график — вы не знаете.
Я ответил, что вопрос «быстрой оценки взаимной силы армий» вы оставили без рассмотрения, а на него надо ответить. Каким образом, зная параметры вида «сколько нужно юнитов А чтобы уничтожить тысячу юнитов Б», вы быстро оцените взаимную силу армий?
Если итог всех этих транзакций, рандомов мер и контрмер можно выразить в простом виде — то это разве плохо?
Зачем бороться с системой уравнений, если я ее уже решил? В статье приведен ответ, выраженный в простых формулах (6), (7), (11). Геймдизайнеру что, сложнее вычислить квадратный корень, чем проводить полномасштабную детальную симуляцию?
Так какое мне дело до вида функции вне рассматриваемых рамок?
Так же, как и оценка по среднему, только берется сумма оценок взаимодействия каждого отряда с каждым.
А теперь представьте, что у вас не цилиндр, а штук сто сообщающихся сосудов… Как вы, вооруженные самым передовым знанием, что pV=NRT, сможете определить параметры системы на выходе?
При этом сделать тысячу замеров результата работы этой системы сможет даже лаборант.
Вы решили задачу об обмене уроном между всего лишь двумя отрядами без каких-либо особенностей. Для ГД это что-то уровня «Hello world!»
а «полноценная симуляция» в рамках решенной вами «задачи», это пять минут работы программиста-новичка.
Только вот если потребуется добавить особенностей — это будут все те же пять минут, а у вас сложность резко нарастает.
Ну, а про использование любимого метода всех ГД — разброса параметров с помощью всемогущего рандома — даже как-то уже упоминать неудобно.
Но никакого практического смысла он не имеет.
Для каждой комбинации значений параметров вам придется заново проводить затратные численные расчеты
А теперь, пожалуйста, выразите эту мысль на математическом языке, а то непонятно, куда надо подставлять параметры и как вычислять результат.
Это настолько затратно, что заставляет искать более оптимальные решения.
сможете ли вы при мне за 5 минут написать программу симуляции сражения в тех конфигурациях, что были рассмотрены в статье.
use strict;
for (my $pp = 0; $pp < 100000; $pp+=100) {
my $L1 = 100000;
my $L2 = $pp;
my $k = 0.01;
while ($L1 > 0 && $L2 > 0) {
my $LN1 = $L1 - $L2 * $k;
my $LN2 = $L2 - $L1 * $k;
$L1 = int($LN1);
$L2 = int($LN2);
}
print "$pp $L1\n";
}

Заодно покажете, каким именно образом в моем подходе резко нарастает сложность при добавлении особенностей.
Этот спор сродни тому, как если бы вы утверждали, что ни к чему учиться брать интегралы аналитически, так как всегда возможно посчитать их численно с любой требуемой точностью.
Почему же они затратные? Одна симуляция считается сотые доли секунды.
И множество симуляций нужно только если есть разброс параметров из-за рандома, в т.ч. ведущего к ветвлению, который ваша система вообще не может учитывать
Без проблем, но баш на баш — представьте сначала, скажем...
итоговую систему уравнений для размена при котором каждый отряд имеет всего пять параметров: очки здоровья (на юнит), урон (на юнит), броня отряда (вычитается из всего входящего урона за раунд), шанс крита (шанс нанести двойной урон в раунд, применяется до брони).
Почему вы считаете, что это затратно?
сможете ли вы при мне за 5 минут написать программу симуляции сражения в тех конфигурациях, что были рассмотрены в статье.А я это уже сделал, когда захотел проверить выводы насчет потерь.
Мне нетрудно добавить их в симуляцию и построить графики, включая трехмерные, по любым соотношениям любых параметров.
В задачах, где вычисление одной точки без оптимизации занимает дни, а порой месяцы — безусловно нужна аналитика. Но геймдизайн к таким не относится.
Вернемся снова к задаче написания бота для RTS. Шаг времени игры может составлять порядка 1/50с.
Я здесь не вижу принципиальных препятствий. Теорвер нам поможет.
Чего это вы ставите условия? Я все свои рассуждения подтвердил в статье математическими выкладками.
Начнем с простого. Пусть у нас только 2 параметра — очки здоровья (h1, h2) и урон (d1, d2). Тогда k2=d2/h1, k1=d1/h2. При этом считается, что частота атак равна 1.
Теперь учтем шанс крита
Поручить лаборантам провести тысячу измерений со сложной системой по-вашему не затратно?
Где метод Монте-Карло?
вы понимаете, что ваша симуляция является численным решением дифуров и принципиально от моего подхода ничем не отличается
Игровая индустрия всегда была областью, где требуется глубокая оптимизация кода и алгоритмов.
А я вижу принципиальное препятствие — нарастающую сложность и запутанность системы.
Вы подтвердили выкладками решение абстрактной задачи, не имеющей никакого отношения к играм. О чем я вам уже который раз говорю. Уберите упоминание об играх и у меня исчезнут все вопросы сразу же.
Поручить лаборантам провести тысячу измерений со сложной системой по-вашему не затратно?
Я полагаю, что проведение измерений обойдется в сотни, если не в тысячи раз дешевле попытки измерить и просчитать вышеупомянутый механизм.
Где метод Монте-Карло?
Так у вас же нет разброса урона и прочего рандома, который бы влиял нелинейно. А в играх он, обычно, есть.
Кроме одного момента, о котором я уже в который раз пишу. Мне добавить любое, пришедшее в голову ГД условие — дело пары минут…
Вам же придется каждый раз сталкиваться с трудностями и система уравнений будет разрастаться.
Отлично. В первом отряде один огр с 10000hp и уроном 3500 ед., во втором отряде тысяча пехотинцев с 13hp каждый
Как я понял оппонента — броня не разрушается вообще. Иначе не было бы оговорки про бесконечный бой.
тут лучше инструментально решать, а не ручками на бумажке
Тут и решение будет по разному считаться, нужно будет определять точки когда кто-то из групп войск (того или иного противника) погибнет, и дальше считать без него…
Лично я бы бутстрапил численно, а потом решал аналитически, перед продакшеном.
Что касается тервера, то зачем он? мы рандомим коэффициенты и получаем репрезентативный результат.
Но поверьте, есть люди, лучше вас разбирающиеся в математике
Простите, а вы кто?
Такое утверждение дает прекрасную характеристику вашей компетентности
Первый переход на личности.
Меня лишь одно еще интересует — вы и правда не поняли пример с огром
из колонны вести огонь могут только стоящие по периметру, а линия стреляет всяА вот ничего подобного :) Линяя не может стрелять вся — просто из-за нехватки дальности и точности.
Про штыковой бой само собой, но тогда и англичане перестраивались.Если успевали. Но, если вспомнить с чего началось обсуждение — то победа им не грозила и в этом случае, из-за малочисленности.
Исход боя не должен зависеть от того, смотрел на него игрок или нет
В подобных публикациях полезно показать историю создания моделей, которые Вы беретесь рассматривать. Имена Ланчестера, Колмогорова, Чепмена и многих других специалистов, их труды по этой теме избавили бы Вас от многих теоретических промахов и упреков в комментариях. Дилетантизм - современный подход авторов меня уже не удивляет, удивляет, что читатели об этом не говорят и не пишут.
«Большие батальоны» в непрерывном времени (симуляция сражений)