Форум Игромании
 
Регистрация
Справка

 
 
Опции темы
Старый 25.11.2007, 13:12   #1
Кандидат наук
 
Аватар для pokibor
 
Регистрация: 13.06.2005
Адрес: 0x00000000
Сообщений: 7,706
Репутация скрыта [+/-]
[Статья] Основы построения AI в играх

Я, Pokibor, в здравом уме и трезвой памяти, взял на себя смелость начать писать небольшую статейку про искуственный интеллект (AI) в компьютерных играх. Первый пост будет потихоньку дополняться новыми методами, обо всех допущенных ошибках просьба стучать в личку.

Основы программирования AI в играх
Когда начинающий программист делает свою первую игру, зачастую перед ним сразу встаёт вопрос о создании искусственного интеллекта в той или иной его форме. Конечно, определённый класс игр (особенно аркады) не подразумевает наличия соперника с иллюзией присутствия мозгов в голове, однако кому не интересно сделать не очередной клон тетриса, а свою простенькую стратегию, action (не обязательно 3D) или даже RPG? В любом из этих случаев уже не достаточно наличия соперника с абсолютно случайным или напрямую прописанным поведением. Противник (будь то монстр или враждебный генерал), а порой - и союзник (свой собственный солдат, лишенный высочайшего внимания) должен уметь оценивать ситуацию и реагировать на её изменение таким образом, чтобы игроку его действия казались в какой-то мере осмысленными и логичными.
Впервые столкнувшись с такой проблемой, начинающий программист, как правило, всерьёз задумывается. Если он вообще не знаком с основными методами программирования AI, то совершенно не представляет, в каком направлении нужно делать следующий шаг. Если знаком - то долго думает, какой же метод применить в данном случае, чтобы потом не переписывать код целиком из-за одной ошибки в начале. Эта небольшая статейка призвана дать основные понятия о некоторых методах программирования AI в играх и помочь определиться с выбором конкретного алгоритма для каждого случая. Сразу замечу, что общее число различных методов чрезвычайно велико и всё время увеличивается. Многие компании имеют свои собственные наработки на этот счёт и не спешат их афишировать.
Тем не менее, основные алгоритмы построения AI достаточно известны, ну а все остальные являются в той или иной мере их вариациями и результатами смешивания. Причём смешивать различные методы не просто можно, но и зачастую нужно, чтобы добиться вменяемого результата. Например, глобальные действия армии можно описать прецедентами или даже задать скриптово, а вот для каждого конкретных действий каждого солдата использовать нечёткую логику. Тогда, выполняя данный генералом приказ, одновременно боец сможет создавать иллюзию осмысленных действий - искать укрытия, прикрывать товарищей, а когда дело запахнет керосином - забыть про приказы и драпануть с поля боя. К слову, наглядный пример применения нечёткой логики для описания действий солдат можно найти в Half-Life, где подобные «мозги» встроены в головы действительно разумно кувыркающимся спецназовцам.
Итак, от общих слов перейдём к делу. Со временем я буду добавлять в данный пост заметки о методах AI, ответы на часто задаваемые вопросы и, возможно, примеры реализации того или иного алгоритма на практики.

Прежде чем писать AI
Первой проблемой, встающей перед начинающими программистами при написании AI, является, как ни странно, никак не связанная с алгоритмами построения этого самого AI проблема. А именно - как организовать ощущение мира игры компьютерным персонажем (в дальнейшем будем его для краткости называть ботом вне зависимости от жанра игры и исполняемой роли)? Ведь любому алгоритму нужны какие-то данные для обработки - сведения о местоположении игрока, своей базе и войсках, карте, на которой происходит битва... Разумеется, реализовывать это «честно» (т.е. вычисляя боту видимый им самим экран и распознавая образы) не хватит никакого времени и ресурсов компьютера. Поэтому приходится идти на упрощения и откровенно жульнические приёмы. Причём чем больше данных получает бот, тем труднее писать и/или обучать его AI. Кстати, отчасти по этой причине в стратегиях компьютер, как правило, игнорирует туман войны на карте и хорошо ещё если рассчитывает видимость себе войск игрока. Заставить AI честно проводить разведку местности довольно трудно, потому и приходится подобным образом жульничать.
Из примера выше должно быть понятно, что ощущение ботом мира игры должно производится сугубо внутренними средствами программы и внутренним же представлением этого самого мира. Бот не может видеть игрока как модель напротив себя - он может лишь взять его координаты из памяти, построить отрезок «я-игрок» и проверить, не пересекает ли этот отрезок стены и укладывается ли в угол зрения. Если проверка пройдена - бот говорит себе «я вижу игрока» и делает соответствующие выводы, в противном случае он считает, что не видит противника. Иными словами, по конструкции программы бот, очевидно, должен иметь доступ к полной модели игры без ограничений и самостоятельно регулировать свою честность. Казалось бы, простая истинна - и тем не менее на первых парах программист может забыть об этом, в результате чего бот видит сквозь стены и палит в них из всего арсенала.
Итак, если мы делаем action, боты в простейшем варианте могут брать направления на все значимые предметы (возможно, находящиеся в пределах некоторого расстояния) и проверять, а видят ли они эти предметы. Из такой модели расчеты вытекает, что бот не может заметить игрока, высунувшегося из-за угла менее чем наполовину. Представления игрока кругом и расчет видимости противоположных точек окружности, очевидно, снимет эту проблему. Впрочем, подобные алгоритмы можно улучшать разными способами, что-то описывать здесь бессмысленно. Нужно лишь помнить, что любое усложнение алгоритма одновременно увеличивает потребление ресурсов процессора, так что если у нас много ботов - даже добавление в уравнение лишней пары членов может вылиться в серьёзное замедление программы. Везде необходим баланс.
Если мы делаем стратегию или RPG, то область видимости юнита у нас, как правило, составляет круг, а карта - плоская. В таких условиях рассчитывать видимость намного проще, что компенсируется куда большим количеством юнитов на карте. И вот тут-то как раз какие-то усложнения алгоритма вряд ли уместны, разве что в случае тактической стратегии или RPG с упором на реалистичность/stealth-элементами.
Во-вторых, нужно всегда помнить одну из главных заповедей игрового AI: «Задача бота - не выиграть, а красиво проиграть». Бот всегда превосходит человека реакцией, данными об игровой ситуации и наличием бонусов. В таких условиях сделать AI, размазывающий игрока ещё на старте, не так сложно. Но кому нужен подобный бот? Да, игроки бывают разной степени хардкорности. Да, они постоянно обвиняют AI в тупости. Но стоит переборщить - и в игру просто-напросто никто не станет играть, а вместо обвинений в тупости пойдут обвинения в читерстве (и, кстати, вполне законные - как уже было сказано, сделать AI, получающий данные подобно человеку, крайне сложно и накладно). Поэтому в ориентированной на более-менее честное противостояние с ботом игре (в-основном, стратегии, в меньшей степени action, ну а к RPG это почти не относится) стоит сделать несколько уровней сложности именно искусственного интеллекта, а не занижения-завышения игровых параметров бота/игрока. Хотя второй путь, конечно, проще, и им также часто пользуются (см., например, Heroes of Might & Magic V).
На этой «оптимистичной» ноте закончу вводную и перейду к описанию конкретных методов построения AI.


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

Бот появляется на карте -> Респаун; Проверка видимости игрока

Проверка видимости игрока:
Игрок замечен -> Выстрелить; Проверка видимости игрока
Игрок не замечен -> Проверка получения повреждений

Проверка получения повреждений:
Повреждений не получено ->Проверка наличия цели движения
Повреждения некритические -> Повернуться в сторону источника повреждений; Проверка видимости игрока
Повреждений критические -> Гибель; Бот появляется на карте

Проверка наличия цели движения:
Цель движения есть -> Приблизиться к цели движения; Проверка видимости игрока
Цели движения нет -> Назначить цель движения; Проверка видимости игрока

Получается простейшая схема действий бота. Конечно, в реальности всё куда сложнее - если по этой схеме, например, бот при встрече игрока тупо останавливается и начинает в него стрелять, то в нормальном action’е такое недопустимо. В то же время сохраняется основной принцип - на каждое действие с учётом проверки условий приходится только один ответ, он же последующее действие.
Достоинством такого алгоритма, несомненно, являются простота реализации и быстродействие. Из всех вариантов AI скриптовый наиболее быстрый, потому он и используется в играх когда все доступные ресурсы кидаются на красоту картинки или реалистичность физики. Также данный алгоритм не требует мороки с обучением, при необходимости в конечный автомат элементарно вставляется новое состояние со всеми нужными условиями перехода.
В то же время для написания конечного автомата требуется именно программист, так как далёкие от программирования люди, как правило, мыслят более общими категориями и не способны толком написать скрипты, даже если им предоставить для этого средства. А «не видящий за деревьями леса» программист может недостаточно обще описать ситуации в целом, в результате чего AI будет не просто смотреться болванчиком - а, скорее, полным идиотом, в определённых ситуациях постоянно ведущим себя неверно. Собственно, наличие на одно действие с одним набором условий одного и только одного ответа и является наиболее бросающимся в глаза недостатком скриптов, за который их постоянно ругают. Приноровившись к такому AI, человек мысленно построит у себя в голове примерную схему его действий и уже способен будет предсказать реакцию бота на любое поведение. Результат - потеря интереса к игре, так как игрок отлично знает, что выкинет бот в данный момент.
Бросающееся в глаза улучшение алгоритма - придумать несколько вариантов ответов на одно и то же состояние и случайным образом выбирать один из них. Это, разумеется, будет выглядеть лучше - но искусственность AI всё равно будет бросаться в глаза. Скриптовый AI неспособен предпринимать неожиданных действий (а ведь порой глупые на первый взгляд действия человека благодаря эффекту неожиданности позволяют ему победить). Кстати, не стоит в данном случае тыкать пальцем в слово «победить» и напоминать автору про цель AI. Если бот нигде не будет побеждать, с ним будет не интересно играть. Да, постоянные глобальные победы AI над игроком недопустимы. И в то же время без локальных побед бота против него банально неинтересно играть.
Поэтому скриптовый AI - скорее, решение на крайний случай, когда иные варианты по тем или иным причинам считаются нецелесообразными. Скрипт не подведёт - но и не даст надолго заинтересовать игрока.
В то же время для небольших «крупинок» игры следует применять именно скрипты. Например, какая разница, насколько шаблонно ведёт себя отдельный пехотинец в армии из пяти десятков себе подобных, оставшись без приказов игрока? В таких случаях скриптовоть даже идёт в плюс - не замедляет излишне процессор и освобождает игрока от лишнего микроконтроля, так как он уверен в определённых действиях подчиненного, скажем, при внезапном нападении врага. Нереалистично? Зато дёшево, надёжно и практично.


Системы, основанные на правилах (Rule-based systems, далее RBS)
Тут я испытываю некоторые затруднения. С одной стороны, идея подобных систем достаточно близка к скриптам. С другой - назвать «скриптами» все программы на языке Prolog значит попасть под шквал заслуженной критики. И в то же время RBS представляет собой нечто вроде неоптимизированной версии достаточно объёмного скрипта. В общем, после некоторых раздумий я принял следующее решение: я не буду отдельно описывать системы, основанные на правилах. Следующим разделом идёт система с рассуждениями, основанными на прецедентах, из которой RBS получается некоторым упрощением. Там она, пожалуй, и будет рассмотрена. В противном случае кое-что придётся повторять дважды, а это бессмысленно.

Рассуждения, основанные на прецедентах (Case-based reasoning, далее CBR)
При написании этой части статьи использован диплом Connor’а, зарегистрированного на этом форуме как L’ombre.
CBR можно считать некоторым шагом вперёд по сравнению со скриптами и, соответственно, с упомянутой выше RBS. В основе CBR лежит идея использования предыдущего опыта решения определённых задач для последующих выводов. Такой подход примерно соответствует человеческому мышлению - принимая решения, мы постоянно основываемся на полученном за прожитые года опыте. В судебных системах некоторых стран (например, США, к России же это не относится) в законодательном порядке закреплено использование прежних судебных решений-прецедентов как основы для новых вердиктов. Таким образом, CBR-системы довольно естественны и, что важно, в отличие от скриптов и RBS способны к обучению. В них отсутствует необходимость строить на основе новых знаний какие-либо общие правила - при использовании CBR правила обобщаются автоматически, в процессе применения накопленного опыта к дальнейшим проблемам.
Центральным объектом любой CBR-системы является база знаний (более узкое название - база прецедентов). Именно в ней в форме некой структуры хранится накопленный системой опыт. Конкретный вид подобной структуры (прецедента) зависит от решаемой задачи, однако конкретный экземпляр всегда включает в себя сведения об исходной ситуации и принятом в этих условиях решении.
Собственно, построение подобной структуры - одна сложностей при создании CBR-системы. Она должна быть достаточно общей для описания всех возможных ситуаций, и в то же время достаточно простой для автоматического построения по ситуации соответствующего ей экземпляра структуры.
Например, для бота в шутере эта структура может быть следующей:
Описание ситуации:
- Текущее состояние здоровья (хиты, броня, бонусы - всё, что влияет на жизнеспособность).
- Текущее состояние оружейного арсенала (пушки, кол-во патронов, бонусы - всё, что влияет на способность к уничтожению противника).
- Некое обобщенное описание положения на уровне - допустим, удаленность от ближайших бонусов «оздоровительного» типа, «нападательного» типа, положение видимых противников. Всё это по обобщённ0ым категориям (допустим, справа-слева-прямо).
- Известные данные по противникам - их состояние здоровья и арсенал.
- Если есть союзники - похожие данные по ним.
Видно, что в подобной структуре можно в с достаточной степенью точности описать ситуацию для стандартных deathmatch’а и teamplay’а. В случае более сложных типов игр (например, захвата флага или того сложнее - стратегии) описание ситуации, разумеется, будет ещё сложнее. Однако главное - это некая общность, так как конкретики вроде записи в базу данных координат допускать ни в коем случае нельзя.
Описание принятого решения:
Здесь всё гораздо проще. Скорее всего, для шутера это будет обобщенный приказ юниту, например, «атаковать противника с наименьшим числом хитов», «сменить оружие на такое-то», «бежать к такому-то типу бонуса» и т.п. Для стратегии решение будет, наверное, более разветвлённым, возможно - содержащим несколько направлений развития и агрессии, на которых боту следует сосредоточиться. Исполнение таких приказов обычно прописывается более простой моделью искусственного интеллекта либо вообще забивается напрямую. Иными словами, в играх CBR довольно трудно применять «в чистом виде»; обычно прецеденты работают на глобальном уровне, тогда как на локальном данные системой приказы исполняются другими методами.
Если в системе предусмотрено обучение, описание принятого решения может включать в себя также некий коэффициент его «разумности», выведенный в процессе работы системы.

С базой знаний вроде разобрались. Теперь можно переходить к процессу принятия решений, обычно называемого «четыре ‘R’» по числу пунктов (Retrieve, Reuse, Revise, Retain). Итак:
- Retrieve или извлечение. На этом этапе просматривается вся база знаний и из неё выбираются прецеденты с условиями, похожими (подобными) на текущую ситуацию. Как правило, тут происходит не сравнение по принципу «похож-не похож», а используется некое значение похожести. Например, этот прецедент похож на текущую ситуацию на 50%, этот - аж на 90%, а тот - всего на 15%. Написание функции, сравнивающей два описания ситуации - вторая сложность при создании CBR-системы. Тут следует вводить для каждого поля структуры прецедента некие коэффициенты, которые потом можно было бы легко изменить, и впоследствии играть с ними, подбирая подходящую. Кстати, такая функция вполне может задавать характер компьютерного игрока. У агрессивного, например, относящиеся к нападению коэффициенты будут больше, а у бота защитного типа - наоборот, ниже.
В результате применения функции похожести каждому прецеденту из содержащихся в базе в соответствие поставлен некий коэффициент похожести. Далее большинство прецедентов с низкими коэффициентами отбрасываются (тут, очевидно, следует задать некую границу либо иной способ определения остающихся прецедентов). Оставшиеся же формируют так называемое конфликтное множество. На этом этап извлечения заканчивается.
- Reuse или повторное использование. Для каждого из находящихся в конфликтном множестве прецедентов берётся соответствующее ему решение и каким-то образом адаптируется к конкретной ситуации, если это нужно. Например, тут можно чётко определить тип бонуса, к которому, собственно, боту предстоит бежать, выбрать конкретного противника для атаки и т.п.
- Revise или пересмотр. Из конфликтного множества на основании некого критерия выбирается определённый прецедент, и программа пытается применить его адаптированное решение применяется к текущей ситуации. Возможно, это не удастся либо заведомо приведёт к неверной ситуации - тогда выбирается (возможно, на основании иного критерия) другой прецедент и попытка применения повторяется.
- Retain или сохранение. Выведенное только что решение сохраняется в базе знаний для будущего использования. Вот это - как раз обещанное обучение. Сохраняется могут как верные решения, так и неудачи, причём в случае, когда разумность решения видна не сразу, принятые прецеденты разумнее записывать в базу только в конце партии. Также возможно не сохранять новые решения, а модифицировать «коэффициенты разумности» уже существующим, тем, что были приняты в ходе партии, либо делать и то, и другое.
Разумеется, этап сохранения можно отделить от остальных - в таком случае некий эксперт записывает условие прецедента и его решение, после чего прецедент заносится в базу. Как уже было сказано, описание прецедента обладает определенной степенью общности - стало быть, экспертом может быть не только программист, но и, например, проектировщик игры - как раз та личность, что «не замечает деревьев в лесу».

Очевидным достоинством CBR-системы является её прозрачность и мощность. Всегда можно открыть базу знаний, модифицировать некие коэффициенты и, при необходимости, добавить новые прецеденты, равно как и организовать обучение в процессе игры с пользователем. Однако «глобальность» базы знаний, содержащей сотни (а то и тысячи) прецедентов требует хорошей организации поиска и сравнения условий друг с другом, уже не говоря о сложности написания структуры для хранения прецедента и функции вычисления похожести. Тем не менее, для решения глобальных задач вроде принятия решения о текущей стратегии развития/нападения/защиты CBR-системы потенциально мощны, так как позволяют отойти от шаблонов скриптов и правил, да ещё и приноравливаться к игроку в ходе игры с ним.
Теперь, как обещал, поговорю о системе, основанной на правилах. В ней также наличествует база знаний (точнее, база правил), построенная по принципу «условие-действие». Конфликтного множества как такового нет, как и функции вычисления похожести. Правила перебираются друг за другом и при полном совпадении условия с текущим выполняется соответствующее действие, после чего процесс уже применяется к результату. Об обучении речи не идёт, все правила изначально забиты в систему создателями и не изменяются. Таким образом, RBS можно считать «облегченной версией» CBR, когда нужно организовать что-то посложнее явно прописанного конечного автомата-скрипта, но не хочется разбираться с функциями похожести и организовывать обучение.
__________________
Товарищ, верь: пройдет она -
Эпоха лживых, злых понятий.
Весь мир очнется ото сна,
И на обломках "демократий"
Напишут наши имена!

Мы были волшебницами (оригинальное фентези)
Тень Войны (фанфик по ГП)

Последний раз редактировалось pokibor; 25.11.2007 в 19:27.
pokibor вне форума  
Отправить сообщение для pokibor с помощью ICQ
Старый 25.11.2007, 16:27   #2
Кандидат наук
 
Аватар для pokibor
 
Регистрация: 13.06.2005
Адрес: 0x00000000
Сообщений: 7,706
Репутация скрыта [+/-]
Добавил заметку про скриптовый AI.
__________________
Товарищ, верь: пройдет она -
Эпоха лживых, злых понятий.
Весь мир очнется ото сна,
И на обломках "демократий"
Напишут наши имена!

Мы были волшебницами (оригинальное фентези)
Тень Войны (фанфик по ГП)
pokibor вне форума  
Отправить сообщение для pokibor с помощью ICQ
Старый 25.11.2007, 16:44   #3
Игрок
 
Аватар для Ragobam
 
Регистрация: 24.02.2007
Адрес: Ижевск
Сообщений: 570
Репутация: 423 [+/-]
pokibor
Респект. Интересная, содержательная статья, узнал много нового.
Ragobam вне форума  
Отправить сообщение для Ragobam с помощью ICQ
Старый 25.11.2007, 19:16   #4
Кандидат наук
 
Аватар для pokibor
 
Регистрация: 13.06.2005
Адрес: 0x00000000
Сообщений: 7,706
Репутация скрыта [+/-]
Добавил разделы про RBS и CBR. Ragobam, [CCCP] Monster, ORTODOX - спасибо!
__________________
Товарищ, верь: пройдет она -
Эпоха лживых, злых понятий.
Весь мир очнется ото сна,
И на обломках "демократий"
Напишут наши имена!

Мы были волшебницами (оригинальное фентези)
Тень Войны (фанфик по ГП)

Последний раз редактировалось pokibor; 25.11.2007 в 19:25.
pokibor вне форума  
Отправить сообщение для pokibor с помощью ICQ
Старый 10.02.2008, 15:49   #5
Юзер
 
Аватар для BallWin
 
Регистрация: 09.06.2005
Сообщений: 331
Репутация: 56 [+/-]
Кое-какие соображения
Цитата:
Сообщение от pokibor Посмотреть сообщение
Обычно под скриптами понимают жёстко прописанные сценарии поведения бота, построенные по принципу конечного автомата.
В самом первом приближении на самом низком уровне понимания.
"AI" скриптовых сцен "для сюжета".
Цитата:
Сообщение от pokibor Посмотреть сообщение
Бросающееся в глаза улучшение алгоритма - придумать несколько вариантов ответов на одно и то же состояние и случайным образом выбирать один из них. Это, разумеется, будет выглядеть лучше - но искусственность AI всё равно будет бросаться в глаза. Скриптовый AI неспособен предпринимать неожиданных действий (а ведь порой глупые на первый взгляд действия человека благодаря эффекту неожиданности позволяют ему победить).
Но так и делается нормальный скриптовый AI. Уже много-много лет. Имеется несколько вариантов действий, которые выбираюся либо по вероятностям (чаще всего, часто, иногда, редко, исключительно редко), либо случайно (равновероятные события).
При этом чем больше вариантов, тем меньше бросается в глаза искусственность AI (боты ведут себя по-разному в одних и тех же ситуациях).
Цитата:
Сообщение от pokibor Посмотреть сообщение
Например, какая разница, насколько шаблонно ведёт себя отдельный пехотинец в армии из пяти десятков себе подобных, оставшись без приказов игрока?
Как это "какая разница"?!
Пример: в игре, которой уже 14 лет, со скриптовым AI, предоставленные сами себе бойца могут:
-- ситуация: игрок забыл про подчиненных
а) ловить рыбу
б) стрелять по инопланетным тушканчикам
в) курить "козьи ножки" (здоровенные самокрутки)
г) разбить бивак и греться у костра
д) пить энергетические напитки ("Rocket Fuel")
е) валятся в шезлонгах и читать газеты (как только игрок обращает на них внимание шезлонги немедленно прячутся, газеты выбрасываются)
-- ситуация: игрок переместился в другую часть экрана, или долго не обращает на них внимания
а) осматривать место, в котором игрок их покинул
б) перемещаться в ограниченной области туда-сюда
в) заглядывать за углы зданий
-- ситуация: бойцы только что выполнили приказ и находятся в поле зрения игрока
а) ждут приказов, стоят на месте, крутят головой во все стороны

Т.е. общий тип поведения зависит от времени, которое прошло с последнего приказа игрока. Но вариант выбирается вовсе не жестко.
И больше всего вариантов как раз в случае, когда игрок покинул пехотинцев надолго.
Это естественно, поскольку люди отличаются большОй вариантностью поведения именно тогда, когда их никто не видит. А одна из задач AI, о которой почему-то забывают, - иммитировать поведение человека (если боты человекообразны), либо иммитировать естественное поведение монстров (в соответствии с человеческими понятиями "естественности").

Добавлю, что в отделении бойцов от 3-х, до 4-х. И помимо "типов" имеются и существенные индивидуальные различия. К примеру - один из них может отстать, заглядевшись на прыгающих рыбок, а потом бросится в догонку. Они могут совершать ошибки, т.е. в одном шаге до флага (что означает захват сектора) попав под обстрел развернутся к стреляющему и вести ответный огонь (вместо того, чтобы наплевать на врага и сделать последний шаг). И т.д. А способность совершать ошибки -- тоже присуща человеку и является частью иммитации человеческого поведения.
Вот вам и "скрипты".

Цитата:
Сообщение от pokibor Посмотреть сообщение
CBR можно считать некоторым шагом вперёд по сравнению со скриптами и, соответственно, с упомянутой выше RBS. В основе CBR лежит идея использования предыдущего опыта решения определённых задач для последующих выводов.
Не стоит так считать, во всяком случае в играх. ИМХО
Самообучающаяся система (о ней ведь речь?) может найти применение в игре, безусловно. Но только где? Ранее активно обсуждалась модель игр "подстраиваемых под игрока". Т.е. AI на ходу оценивал уровень сидящего перед ним геймера и подстраивался так, чтобы (как верно было сказано) "красиво проиграть". Однако эти разговоры что-то заглохли. Такой AI получается неоправданно сложным.
Развитый скриптовый AI сегодня удовлетворяет любым требованиям, если сделан с умом. А если нет, то не скрипты виноваты, а с программистом что-то не так. ИМХО
BallWin вне форума  
Старый 10.02.2008, 17:57   #6
Новичок
 
Аватар для L'ombre
 
Регистрация: 07.03.2006
Адрес: !here();
Сообщений: 38
Репутация: 26 [+/-]
Цитата:
Сообщение от BallWin Посмотреть сообщение
Самообучающаяся система (о ней ведь речь?) может найти применение в игре, безусловно. Но только где?
речь не совсем о понятии "Самообучающаяся система". возможность (само)обучаться - только одно из свойств CBR. Его можно не использовать. Можно использовать на начальном этапе, при создании AI, например, чтобы создать несколько разных экземпляров базы знаний, свой экземпляр для каждого уровня сложности. (Причём, базу знаний можно спроектировать таким образом, чтобы её было легко редактировать вручную, это в данном случае проще, чем с нейронными сетями.)

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

p.s. вообще да, сейчас разработчики используют то, что работает, возможно, не хотят рисковать - и поэтому не (или мало) используют другие технологии.
__________________
Use the Darkness that you have inside
L'ombre вне форума  
Старый 10.02.2008, 20:51   #7
Юзер
 
Аватар для BallWin
 
Регистрация: 09.06.2005
Сообщений: 331
Репутация: 56 [+/-]
Цитата:
Сообщение от L'ombre Посмотреть сообщение
Можно использовать на начальном этапе, при создании AI, например, чтобы создать несколько разных экземпляров базы знаний, свой экземпляр для каждого уровня сложности. (Причём, базу знаний можно спроектировать таким образом, чтобы её было легко редактировать вручную, это в данном случае проще, чем с нейронными сетями.)
Кроме подстройки под игрока возможно ещё и обучение от игрока - бот не определяет, насколько игрок хорош, а просто перенимает у него некоторые приёмы.
Вопрос, какую выгоду получат разработчики, игроки, издатели? Если выгоды очевидны -- не вопрос, система будет использоваться. К примеру, подстройка под игрока автоматически расширяет целевую аудиторию. Теоретически удовольствие получит и хардкорщик, и нуб-неумеха (система будет играть с каждым из них на его уровне). Это сулит увеличение продаж и как-то компенсирует внедрение новой технологии. Описание же в статье практически обещает:
-- увеличение системных требований (вычислительный мощности у потребителя)
-- увеличение сроков разработки (новая технология, сложные алгоритмы)
-- увеличение количества ошибок (из-за возрастающей сложности)

Собственно можно процитировать саму статью: "Однако «глобальность» базы знаний, содержащей сотни (а то и тысячи) прецедентов требует хорошей организации поиска и сравнения условий друг с другом, уже не говоря о сложности написания структуры для хранения прецедента и функции вычисления похожести".

А в чем же видится плюс? Цитирую:
"CBR-системы потенциально мощны, так как позволяют отойти от шаблонов скриптов и правил, да ещё и приноравливаться к игроку в ходе игры с ним."
В том, что не "скрипты"? Сомнительная выгода. Обучение AI стилю игры от геймера? Опять же, куча вопросов:
-- что это даст игрокам, почему им станет лучше?
-- что будет, если игровым компьютером пользуется не один человек (AI будет учиться у всех)?
-- очевидно, что "обученная" предыдущим игроком система может оказаться новому геймеру не по зубам (т.е. будет нарушен принцип последовательного усложнения миссий -- от простого к сложному)
и т.д.

Цитата:
Сообщение от L'ombre Посмотреть сообщение
а где - я использовал CBR в пошаговой стратегии.
Это был общий вопрос Импелось в виду, в каком виде она может принести максимальную пользу.
Но я бы с удовольствием посмотрел игру. Тема мне интересна, и метод не безразличен (кинь линк в личку, если можно).

Цитата:
Сообщение от L'ombre Посмотреть сообщение
p.s. вообще да, сейчас разработчики используют то, что работает, возможно, не хотят рисковать - и поэтому не (или мало) используют другие технологии.
Скажу больше, все идет к тому, что разработчики в общей массе больше не будут делать собственные игровые движки. Не дадут. Это не мои умозаключения, это из разговоров с продюсерами наших издательств. Они (издатели) больше не желают платить деньги за интересное и увлекательное изобретение велосипедов. На сегодняшний день наличие у команды собственного игрового движка (если только он не побывал в деле и не доказал свою замечательность) не является преимуществом при заключении контракта. Если сам концепт и геймплейная демка заинтересует издателя, то практически наверняка разработчикам будет предложено выбросить свой движок и использовать другой, от компании А или Б.
Такие дела. Игровая индустрия становится всё жесче. Любые новые методы должны давать конкретные осязаемые выгоды. Иначе они никому не нужны. Поэтому очень желательно хорошенько подумать насчет плюсов и описать их таким образом, чтобы не возникало никаких сомнений
BallWin вне форума  
Старый 10.02.2008, 23:23   #8
Новичок
 
Регистрация: 13.06.2007
Адрес: Россия, Московская обл.
Сообщений: 37
Репутация: 9 [+/-]
Спасибо! Статья очень полезная и очень интересная.
2man вне форума  
Отправить сообщение для 2man с помощью ICQ
Старый 23.08.2009, 20:50   #9
Новичок
 
Регистрация: 23.08.2009
Сообщений: 1
Репутация: 0 [+/-]
Хорошая статья. Порадовала
Если уже про AI говорим то лучше представить себе его вид действия:
=================
3D - Шутер
Блоки:
=============
Блок N1
1. Полная проверка текущего состояния (Здоровье). Указать число равномерное полученным выводам 1,2,3. В случаи если здоровья 100% не выполнять пункт 2, а перйти у пункту 3
2. Взять из пункта /1 указательное число. Сравнить число. Выполнить действие 1 - продолжить действие дальше
3. Полная проверка на все преимущества, недостатки
==============
Блок N2 = Сбор сведений о местности в зоне видимости.
1. Осмотр всех сторон
2. Определение проходимых объектов местности. (Если проходимый то число 1, Если не проходимый 2)
3. Размер видимой местности.
4. Логический вывод действий, а также расписание действия бота по вышеуказанным данным.
=================
Блок N3
Вхождение в блок (1,2,3)
Вхождение в блок с значением 1 - отойти в другую зону ориентировавшись на блок N5
1. Нахождение предмета на карте
2. Обработка предмета (Узнает что за предмет)
3. Проверка на доступность предмета по местность.Выполнить действие N2 <*ЧИСЛО*>
4. Обработка <*ЧИСЛО*>, если 1 выполнить действие /5, если 2 выполнить действия /7
5. Вариант прохождения по местности N2, а также выполнить действие N4, а также с блока N4 пункта 2 получить число
6. Проверка пункта /5 по маске: 1 местность опасно, 2 местность не опасно.Записать полученный вывод в ячейку пункта /7
7. Ячейка 1
8. Обработка всех действий. Взять из ячейки 1 пункта 7 данные.Вывод число 1,2,3 в зависимости от полученного вывода(1 - местность не доступна, 2 - местность доступна, 3 - местность доступна, но содержит опасность, согласно ячейки /7)
9. Проверка обработки пункта /8. Если 1 - перейти в пункт /14 без продолжение, 2 - выполнить пункт 10, если 3 - перейти до пункта 11
10. Выполнить действие
11. Выполнить действие блока N4 только пункта 3го.
12. Анализировать действие 11 пункта с выводом числа 1,2
13. Выполнить действие в случаи если с пункта /12 число 2, если число 1 перейти до 14 пункта
14. Завершение


============


==========
Блок N4
1. Что подразумевается под опасными действиями? Под опасными действия подразумевается возможный урон или гибель бота
2. Проверка на опасность (Если опасность есть, то число 1. Если нет - то число 2) В любом случаи выполнять пункт/ 3 - не надо данной командой
3. Опасность во всех пониманиях
==========

==================
Блок N5

1. Что означает игрок? Враждебный игровой объект
2. Выполнять одновременно действия /3 и /4
3. Текущие расположение по координатом игрока
4. Текущие состояние игрока
5. Анализировать действия по блокам N1 N2 и N3. Если "командование"(управление) (Стоп, прекратить, остановить, отойти) не возьмет на себя какой либо из блоков, то выполнить дейстие /6(В смысле, что показатели будут такими что нет прерывание в других блоках в духе "стоп" или "все хватит отступай")
6. Атаковать
===================




=============
Блок N6
1. Осмотр оружия. Записать всю информацию о оружии
2. Выполнить действие N4
3. Сравнить N4 пункт 2
4. Сравнить полученный результат пункта /3 и перейти в пункт 3 блока N4 и сравнить оба показателя в пункте /5 текущего блока
5. Результат с выводом числа 1,2
6. Выполнить действие с просмотром числа из пункта /5, 1 - выполнить действие блока N3 с вхождением 1, 2 - продолжать
============

Действие игры:
Бот появился на карте

Действия бота:
1. Выполнить действие N1
2. Выполнить действие N2
3. Проверять все блоки, кроме N1 и N2
4. Проверять N1, N2

Алгоритм написаный мною более менее корректный и способен создать вид "умного AI". Но не буду говорить то что нужно все легко и очень просто. Во первых команды в духе: "Анализировать местность" не будет легкой. По тому что как вообще понять значения "Анализировать местность"? Плюс, системные требования будут нагруженными. Хорошо если игра похожа на Unreal Tornament 1 (1999) и там играет чисто один бот и один игрок на карту. А если таких ботов будет 2 и более? Нагрузка возрастер в разы не говоря уже о том что кроме AI есть еще графика и прочий контент
Думаю что через лет 5 игры возрастут в плане AI, хотя еще с 1999 года различия не во многих играх виднеется. Это не графика которую можно разглядеть
multijet вне форума  
 

Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Часовой пояс GMT +4, время: 10:28.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Rambler's Top100 Яндекс цитирования