Учим АИ колдовать

[iflamberg]

Будет тема во флейме, нет у нас отдельного раздела по алгоритмам, или по программированию компьютерных игр.

Представьте себе такую игру. Стоят друг напротив друга персонаж игрока и его оппонент, накапливают полоски маны, кидаются заклинаниями. Что-то типа японских рпг, final fantasy, что-то такое. Puzzle quest или galactix тоже в какой-то степени подходит под описание.

Вопрос в программировании АИ на использование этих самых заклинаний.

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

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

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

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

3) Дорогое заклинание требует много зеленой маны и чуть-чуть красной. Зеленая на нуле, зато красной полная полоска. Есть мелкое заклинание, которое требует только немного красной маны, но АИ в режиме накопления маны на дорогое заклинание.
Опять же решаемо. Если полоска маны заполнена, пусть мелкое заклинание приобретет дополнительный вес. АИ сбросится и использует его.

4) Заклинания, которые наносят урон, в зависимости от того, насколько заполнена полоска маны. У них обычно некое минимальное требование, типа минимум 15 маны, но при 40 маны они наносят значительно больше урона.
Вот это чуть более тяжелый случай. Можно перевести АИ в какой-то особенный режим наколения, который накапливает маны не на использования, а пока не достигнет какого-то порога.

В целом похоже, что такая система справиться с любой ситуацией, но я боюсь, что все это лишний геморой, и простой набор if'ов для каждого конкретного монстра справился бы лучше.
А еще беспокоит то, что множество действий будет произведено несколько раз. Каждый вызов calculateEffectiveness каждого заклинания независимо друг от друга будет проверять одно и тоже: сколько жизней у оппонентов, хватает ли маны, какие эффекты наложены и все такое. С другой стороны заклинаний-то ну шесть штук на АИ максимум, и проверка будет, ну максимум раз в пол секунды, чаще нет смысла.

Ну вот какие-то сумбурные разглагольствования, я прошу прощения, мне, наверное, просто нужно было привести мысли в порядок =))))

[Tails]

Я всегда ценил в играх интересный AI, пока по простоте игры и сложности AI для меня лидирует оригинальный Packman.

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

[NikolyA]

но и при написании данной сети все равно все моменты учесть просто невозможно

[AlexLucas]

Всё зависит от конкретного набора заклинаний и ресурсов (жизнь, мана).
У каждого заклинания может быть не только урон, но и, скажем, дальность/радиус (если по площади) действия.
В зависимости от этого будет меняться баланс, а значит придётся менять механику.

Можно ограничить частоту использования некоторых заклинаний (cooldown), чтобы вконец не запутаться в приоритетах и выделением маны под заклинания. Скажем если СуперПуперУдар восстановился, то АИ ждёт ману только на него. А так пуляет заклинаниями с более низким приоритетом, среди которых тоже может быть подобная иерархия.
Или убрать с некоторых заклинаний требования на ману, и просто повесить на них время восстановления.

Конкретику в студию А то так можно долго филосовствовать.

[caseyryan]

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

но я боюсь, что все это лишний геморой, и простой набор if'ов для каждого конкретного монстра справился бы лучше.

Еще когда читал первый пост, тоже пришел к такому же выводу )

[iflamberg]

Конкретику в студию

Конкретику? Ну это клон Puzzle Quest. В какой-то мере - это элементарная mach3 игра, на экране поле цветных шариков-кирпичиков, соседние можно менять местами, комбинации из 3 и больше одного цвета убираются с экрана. С другой стороны, игрок соревнуется с компьютером. "Убранные" шарики или пополняют полоски маны убравшему, или уменьшают полоски жизни оппоненту. Ману четырех разных цветов можно тратить на заклинания которые выполняют какие-то манипуляции с игровым полем, параметрами персонажей или меняют правила игры на время. Со временем игрок открывает новые комбинации заклинаний и меняются АИ-оппоненты так же с новыми наборами заклинаний.
Компьютер обучен составлять комбинации из шариков, с этим никаких проблем. Осталось только научить использовать заклинания. Собственно в этом и основной смак игры - придумывать комбинации эффективных заклинаний в противовес заклинаниям компьютерного оппонента.

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

Да тут понимаешь ли. На текущий момент порядка 20 придумано монстров у каждого свой набор заклинаний. А будет еще больше. И вот ты "научил" какого-нибудь монстра комбинировать три его заклинания. Написал пачку if-ов. А через час приходит гейм-дизайнер или тестер и говорит: нифига не работает, он меня все время убивает и вообще у "волка" такой же набор практически, это скучно. Говорит, давай вот "заморозку" ему уберем, "ядовитые когти" будет наносить урона пропорционально оставшимся жизням игрока, а вместо "заморозки" пусть будет как "паутина" у паука, только назовем "леденящий вой". Дурдом =) И поехали переписывать и перекомпилировать. Ну что мне делать? Внедрить lua и сказать: "пишите АИ сами"? Ну дык это моя работа. Хотя Lua - это мысль. По крайней мере перекомпилировать не надо будет.

А вот хотелось что-то универсальное, чтобы в xml-ке список заклинаний для текущего монстра подредактировал, в свойствах заклинания урон с 20 на 15 поменял, а АИ сам подстроился, без переписывания логики.

[GBee]

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

[Sync]

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

[dark256]

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

2 iflamberg:
изобрази графически все блоки данных для обработки. Компактно. С минимумом текста.
входные данные, что есть, что влияет, действие.
Чтобы развлечься, можно мою тулзу поюзать и наскриншотить.
https://vk.com/app1988560_43915359?ref=1


ТИпа: https://pp.vk.me/c924/u43915359/1238...z_03ccc7a0.jpg

[iNils]

Сообщение от iflamberg

Будет тема во флейме, нет у нас отдельного раздела по алгоритмам, или по программированию компьютерных игр.

Не будет, ибо, цитирую описание раздела Флейм:

Флейм
Раздел для болтовни и выпуска пара.
Алгоритмы и программирование обсуждаются в разделах AS 1/2, AS 3 и тп.