Привет, Хабр!
Мы публикуем вторую часть материала о на тему эвристической архитектуры ИИ в видеоиграх с глубоким погружением.
Первая часть материала по этой ссылке, а продолжение перевода под катом, жмите кнопку!
Развитие Персонажа
Работая с аспектом Персонажа «Настроение», нужно всегда помнить, что оно меняется.
Причиной того, что в нашей системе появился компонент «Настроение», является то, что я не хотел получить статичную группу Данных для определения поведения Персонажа, так как в этом случае его настроение бы не менялось. Также я не хотел, чтобы Настроение было одинаковым у всех Персонажей, в связи с чем я наделил каждого Персонажа Настроением с различными характеристиками.
Смотрите. Некоторые люди, когда нервничают и попадают в стрессовую ситуацию, становятся более целеустремленными и мыслящими, в то время как другие не могут справиться с некоторыми видами эмоционального напряжения, долго терпят, пока не выходят из себя. Так же, многие люди могут стать более общительными, когда им грустно, некоторые предпочитают побыть в одиночестве до тех пор, пока не устранят причину своего беспокойства, а кто-то притворяется счастливым.
Эмоциональная реакция человека в конкретной ситуации также зависит от окружения. Кто-то, например, не может проявлять эмоции на публике или не хочет демонстрировать их противнику. Некоторые люди имеют ауру некой надежды и уверенности, которая действует на других, мотивируя их на борьбу. Для получения такого эффекта при расчете приоритета Задач кроме всего прочего используются Данные из компонента Взаимоотношения и из Групповых динамических объектов.
Но Настроение – это не единственный компонент Персонажа, который может изменяться. Иногда люди просто меняются, причем не на время, а навсегда, поэтому мы тоже хотим, чтобы Личность Персонажа менялась под воздействием каких-либо Событий. Так как система включает в себя социальную симуляцию, мы хотим менять отношение Персонажа к другим героям в зависимости от их поведения и от происходящего вокруг.
Настроения меняются. Личности меняются. Персонажи меняются. Взаимоотношения меняются. Люди меняются.
Изменения – это любовь. Изменения – это жизнь.
Вот к чему я пришел, когда пытался понять, как же объяснить эту систему в статье. Это, на мой взгляд, является еще более важным, чем сама система, о которой я так много говорил. И если бы я понял это раньше, мне бы не было так сложно создавать эту систему, все было бы гораздо проще. Разве мы не хотим решать сложные задачи простыми методами?
Да, Искусственный Интеллект и Искусственная Личность – это занятные вещи.
И да, важен любой шаг для получения Игровой Истории, которой, я надеюсь, является наша система.
Однако чуть ниже я расскажу самое главное, что и побудило меня написать вообще эту статью.
Я уже упоминал, что, создавая решение конкретной задачи (в предыдущей статье я говорил о системе «интеллектуального мира»), только по прошествии длительного времени я понял, что я делал что-то фундаментальное, что имеет гораздо больший потенциал, если мои наработки тщательно изучить. Так я достиг этого понимания, создавая ИИ для обеспечения эффекта полного присутствия, что моя работа применима не только в решении конкретной задачи, но и может использоваться для решения более широкого спектра задач.
Конкретное – это знания. Абстрактное – интеллект. Давайте поработаем с абстрактным:
Все Компоненты архитектуры – Личность, Настроение, Взаимоотношения… — это Данные, поэтому мы и используем этот термин.
Данные меняются.
Конечно, это довольно просто и очевидно. Для вас здесь нет ничего нового. Но так кажется только на первый взгляд.
В этом и проблема: поначалу я тоже не видел «новое». Когда я перестроил и подчистил систему, я стал переименовывать различные вещи и разделил понятие Задачи для Действий, которыми они являются, и для изменений Данных, которые появляются в результате выполнения Задач. Первоначально это все было включено в монолитную концепцию «Задача».
В процессе редизайна я отделил Действия от изменений Данных, которым теперь я присвоил название Последствия. Разделяя компоненты, я получил возможность реструктурировать всю систему.
Помните, я говорил, что «Персонажи» — это одно и то же как с технической, так и с литературной точки зрения? То же самое и здесь. То, что я называю Последствия – это просто изменения Данных.
Реакции, как мы определили ранее – это Действия, которые происходят в ответ на другие Действия.
Последствия, так я их называю, это изменения в Настроении, Взаимоотношениях и Личности. Когда Персонаж кого-то ударяет (ха! Насилие в видеоиграх!), их Настроение и Взаимоотношения меняются.
Сначала появление «Последствий» выглядело довольно неплохо в рамках того, что мое решение было создано для конкретной задачи проектирования – создать Игровую Историю. В итоге все оказалось еще лучше, так как это позволило повысить модульность и создавать большее количество комбинаций с меньшими усилиями с технической точки зрения. Мой ход мыслей был таким:
«У каждого Действия есть Реакции. Каждая Реакция – это Действие, которое вызывает следующую Реакцию. Да, вот такой была система в ее первоначальном виде. Хорошо, что она еще работает».
«Действия и Реакции образуют цепь. Действие – это так же Событие. Цепь Действий и Реакций – это так же цепь Событий. Цепь Событий – это История. У каждого Действия больше одной возможной Реакции. В написанной Истории Автор определяет конкретную Реакцию, а система определяет следующую Реакцию, в результате чего цепь Событий формируется естественным образом. Как и в Реальности. «Диалог», так называет это Крис Кроуфорд».
«Игровая История! Круто!»
«Ой, подождите. У каждого Действия есть Последствия. Конечно же! Если с Джоном случается что-то плохое, он становится грустным. Если Мэри делает Джону что-то плохое, Джон сердится на Мэри. Изначально это может ни на что не повлиять, зато в дальнейшем такие изменения обязательно окажут влияния на Действия. Последствия!»
«У каждого Действия есть множество возможных Реакций и Последствий».
«Ох, подождите-ка… Иногда Действие – это Реакция на Последствие, то есть косвенно является результатом каких-то других Действий. Если Мэри слишком нервничает в результате каких-то совершенных Действий, и при этом у нее проблемы с сердцем, то у нее может быть сердечный приступ. Как мне это назвать? Если это происходит в результате изменений, то, конечно, это Происшествие. Да: Происшествие».
«Отлично. Действия вызывают Реакции и Последствия. Действия могут быть вызваны другими Действиями и Происшествиями».
Не обращая внимания на Агента, Данные и систему Принятия решений, я нарисовал схему одного Действия (События) в самой простой форме, чтобы впоследствии использовать ее для создания огромного сложного перечня действий и их последствий, чтобы добавлять интерес в систему, создавая необходимый контент для каждой истории, которая есть в нашей «игре»:
Я подумал: «Действительно, проще быть не может».
Потом я собирался написать статью, в которой хотел рассказать о своих выводах. Я хотел найти какой-то классный пример с эмоциональной сценой из фильма или еще откуда-то, чтобы объяснить принцип работы этого решения после запуска в нашей системе. Я хотел переделать какой-то сюжет, создав «техническое демо». Также я хотел создать схему сцены из фильма или телесериала для демонстрации интересных Действий и Реакций, которые помогают развивать и изменять сюжет. Проводя аналогию с первой статьей (или это было в комментариях?): «полностью запланированный сюжет такой же скучный, как и карта. Вам нужно создать некоторые знаки-ориентиры для того, чтобы оживить пейзаж».
Паттерны
Я не помню, в какой момент, но я пришел к следующей схеме:
Могу поспорить, что вы думали, что шутка о «насилии в видеоиграх» была мной высказана просто так.
Наиболее важным в этом примере, обратите внимание, является полное отсутствие Искусственной Личности. Учитываются только следующие Данные: Здоровье и Патроны; Последствия: TakeDamage (Цель) и UseAmmo (Самостоятельно). Главное смоделированное Действие – это Shoot(), а единственной возможной Реакцией в этой небольшой Системе является Перезарядка (Самостоятельно), TakeCover (Цель) и ShootBack (Цель). Единственными Происшествиями могут произойти в случае (Здоровье==0) и (Патроны==0), с косвенными Последствиями StopShooting() и Die().
Помещая Игрока на место Агента и задавая желаемый Результат (Цель) в виде убийства Цели – заставляя его выполнить Действие Die() – в мозге человека это приведет к попытке использовать Действие Shoot(), так как оно доступно в игре. Игрок без знаний того, как работает Система, будет выполнять ряд действий, которые в какой-то момент приведут к желаемому результату прямо (через Действия-Реакции) либо косвенно (через Действия-Последствия-Происшествия-Реакции).
Глядя на это с точки зрения ИИ Видеоигры, составленного в виде карты, похоже, что результатов можно достигнуть с помощью Планировщика или, может, простенького алгоритма по поиску лучшего варианта решения проблемы, который есть в Системе («Я здесь, и я хочу попасть туда. Вот путь»). Рассуждая со стороны человека, Игрок играет в Систему, т.е. играет в Игру. С перспективы рассказчика Персонаж выполняет какие-то действия, которые, возможно, приведут его к желаемому результату.
Наверное, вы заметили, что я ссылался на Действия, Последствия и События системы, используя общий синтаксис программирования (). Это очень важно.
На этом этапе некоторые читатели, наверное, уже пришли к выводу, что эта схема – не что иное как моделирование с помощью языка UML (унифицированного языка программирования), UML уже существует, так что же здесь нового? В этом причина того, что для примера я выбран именно игру в стиле «шутер», а не что-то другое. Все выглядит как простая схема UML, и поэтому нет никаких сложностей для того, чтобы представить похожую систему в UML-форме.
Вот что я пытаюсь показать: в этой системе включено все то, что мы уже делали множество раз. Мы все это можем сделать достаточно просто, используя логику программирования. Здесь нет ничего нового, никаких секретов или черной магии. Мы занимаемся похожими делами уже много-много лет».
Теперь посмотрите:
Здесь не нужно лишних слов. Это очень простая и короткая История. Может быть, и плохая История.
Небольшая, потому что состоит всего лишь из двух непосредственно связанных Событий: одно Действие и прямая Реакция. Простая, потому что нет никаких Последствий, Данных и Решений. Это просто Shot()-ведущий_к-Die() – и все. Плохая, потому что ни один из «Персонажей» этой Истории, а именно Агент и Цель, не отвечает системным определениям Персонажа, которые я озвучил ранее, и потому что требования указанного определения (Личность, Настроение, Взаимоотношения и Знания) не могут быть интерпретированы Аудиторией. Нет никаких объяснений, почему Агент застрелил Цель, нет никаких предшествующих Действий, которые бы давали нам подсказку. Нет Настроения. Если бы было сказано, что Агент был в бешенстве, или что он хладнокровно сделал это, либо если бы Цель была напугана, или Цель бы смеялась – читатель смог бы воспользоваться своим воображением и представить ситуацию. В этом случае История бы однозначно была лучше, чем она есть сейчас.
Причина того, что эта История представлена в таком виде – это то, что такая простая Система использовалась в качестве примера. Расширенная Система создаст расширенные Истории, большее количество различных историй. А улучшенная Система создаст лучшие Истории.
Немного «ЧАЯ»: Запись TEA
Если вы читали предыдущую статью, возможно, вы заметили, что первоначально цель создания этой системы была в симуляции физического конфликта, вроде стрельбы, бега к укрытию, поиска комнаты, лазания, поиска аптечки. Очевидно, что эта система предназначена для имитации Действий и Реакций в буквальном смысле этих слов. Но я настолько был поглощен решением для создания «Игровой Истории», что я это пропустил и не находил связи, даже при том, что эта система была первоначально для этого предназначена.
Вспомнив это, я, наконец, заметил то, что было прямо передо мной, прямо в основе того, что я строил. Я понял, что система «Действия и Реакции» способна сделать множество вещей, которые мы уже до этого делали достаточно долго!
Вот, чтобы упростить все и получить возможность записывать свои идеи с помощью ручки и бумаги (например, если к вам приходит идея, когда вы в душе), я упростил понятия и сократил их до первых букв – Действия (означающие любые События) стали А (Actions); Последствия (означающие любые изменения Данных) – стали Е (Effect); а Происшествия стали Т (Trigger). Также для читабельности я поменял положения Действий и Происшествий и изменил модель на формат, больше типичный для Евклида. И вот результат:
Недавно (ха, в прошлом году) я писал в Твиттере о создании молекулы для Space Invaders. Вот какой был твит:
Тогда я выбрал не очень хорошие цвета… Синий, черный и красный подходят гораздо лучше.
Это не совсем точный способ представления Space Invaders через запись ТЕА, это было что-то вроде шутливого тизера к этой статье. Однако это «Плоская Карта» основы этой игры, в которой используются какие-никакие условные обозначения. Это представление всех возможностей, собранных вместе, которые Игрок будет иметь у себя в голове (для чего, возможно, он будет использовать ИИ Планировщик, это на усмотрение специалистов по ИИ, которым я не являюсь).
Идеальная исходная документация любой игровой системы с точки зрения записи ТЕА – это определенный по отдельности каждый «Атом» системы на каждом уровне работы с единственной прямой связью с Происшествиями, Последствиями, Действиями и Реакциями.
Я изначально использовал этот подход для документирования Действий, Реакций и Последствий для моей исходной системы. Разница лишь в том, что через упрощение и определение концепта как «понятия» я мог использовать его в других системах, связанных с Видеоигрой, даже если исходное программирование видеоигры не полностью отражает это понятие в форме компонентов. Другими словами UML-язык системы и запись ТЕА для системы не совсем одно и то же.
Тем не менее, на примере Space Invaders мы видим, что это лучшая презентация систем игры (исключая некоторые мелочи, которые я опустил для упрощения – например, реакции на ввод, основные движения игрока и набор очков):
Практических ситуаций применения ТЕА не так уж и много. Самыми интересными из них я считаю:
а) В форме Плоской Карты это помогает визуализировать Систему в целом. Возможно применение такой карты для оценки сбалансированности игры и обеспечения качества, оценки возможных улучшений и инструментов. Визуализация значений, зон активности, указателей направления… Все это могло бы найти какое-то полезное применение.
б) ТЕА могут использовать дизайнеры, которые не имеют знаний в области программирования, для документирования основных идей в понятной манере для программистов и других членов команды без углубления в технические аспекты системы. Конечно, некоторые подробности необходимо будет раскрыть через какие-то другие средства, например: с какой скоростью в космических захватчиков должны лететь пули и пр.
в) Видимые различия между Происшествиями, Последствиями и Действиями помогают сохранить четкую архитектуру программирования, которая отражает структуру игры, даже если в коде вызываются только методы, а не компоненты, или если в коде нет различий между компонентами Данных и Функций. Это понятие не только помогает внести различия, но так же классифицирует компоненты по их функциям в системе.
г) Модульные характеристики открывают путь к созданию решений по умолчанию для игровой механики, позволяя проектировщикам заново использовать паттерны для ускорения проектирования и фокусировки на важных и отличных характеристиках каждой игры. Кто знает, может, в будущем выполнять такие задачи станет гораздо проще.
д) Модульные характеристики также открывают путь к созданию технической реализации игровой механики по умолчанию, возможно, с точки зрения узловой архитектуры, конкретных или промежуточных движков или библиотеки Действий с открытым исходным кодом. Это помогло бы перенести в систему огромное количество контента, что означало бы появление огромного количества возможностей для Персонажей ИИ.
Возвращаясь к вопросу, который я сформулировал в самом начале этой статьи, сейчас самое главное – это то, что мы можем моделировать Системы, мы можем моделировать Игры, и мы можем моделировать Истории, используя все те же средства, которые у нас всегда были.
Мы можем моделировать материал в виде блок-схемы. Это не просто запись, это не упорядочивание элементов, хотя это помогает улучшить читабельность, не дружественное наименование ТЕА – это основной Атом, который формирует основу этой записи: Действия, Реакции, Происшествия и Последствия. Плюс «молекулы» сюжетных сцен, которые мы можем добавить.
Если после тестирования и использования различными людьми окажется, что мы можем смоделировать любые действия в виртуальной игровой системе, на что я надеюсь, это означает, что мы сможем практически все представлять в таком формате, мы сможем разрабатывать и выпускать практически любые игры. Если вы сможете представлять свои идеи в таком формате, вы сможете сделать игру из чего угодно.
Я до сих пор настаиваю, что да, если мы продолжим искать способ, то мы сможем создавать Игровые Истории. И не только: возможно, мы сможем сделать их полностью правдоподобными.
Спасибо, что дождались вторую часть этого материала. Подписывайтесь на наш блог и мы ждем всех вас нас на бета-тестировании VirCities!
ссылка на оригинал статьи http://habrahabr.ru/post/256751/
Добавить комментарий