Генерация программы поведения игрового персонажа по...

Клишин Арсений, 524

Гейм-дизайнер — человек, разрабатывающий правила игр. Слово «гейм-дизайнер» применяется в основном к компьютерным играм. Роль гейм-дизайнера аналогична роли постановщика задачи в обычном программировании и режиссёра в кино.

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

Изначально компьютерные игры писали один-двое; программист был одновременно разработчиком геймплея и, зачастую, главным художником. В частности, к таким гейм-дизайнерам относятся Джордан Мехнер и Алексей Пажитнов. Разработка геймплея как отдельная профессия впервые появилась в Coleco в 1970-е годы. Но в те времена это было редким исключением.

Выделить гейм-дизайн в отдельную профессию потребовалось в конце 1980-х годов, когда один игровой проект стал не под силу малочисленной группе людей.

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

Необходимо чтобы гейм-дизайнер был хорошо осведомлен о различных частях и этапах разработки.

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

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

Одной из типичных задач начинающих гейм-дизайнеров является описание содержания миссий, то есть создание:

1)Логики миссии (другими словами, условия успешного или неуспешного ее завершения, фиксирование процесса продвижения по ней, реализация сюжета и его ветвления)2)Описание поведения персонажей, участвующих в игровом процессе и их поведения.

У компании-работодателя возникает дилемма:

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

Нанимать специалистов 2-х типов – дизайнеров и программистов

Минусы:Набирать высокооплачиваемых специалистов,

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

- Высокая заработная плата сотрудников

Нанимать специалистов 2-х типов – дизайнеров и программистов

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

- Между дизайнером и программистом неизбежно непонимание

Создать программное средство, обеспечивающее автоматическое создание программного кода по словесному описанию пунктов 1) и 2) на языке, приближенном к естественному (то есть на естественном языке с некоторыми правилами оформления и некоторыми другими ограничениями).

Миссия - аналог главы в рамках игры. В начале каждой миссии игрока ставят в известность о задачах (целях миссии). Миссия заканчивается когда либо цели выполнены, либо провалены.

Карта - игровая локация, на которой происходит миссия(и).

Скриптовый язык (англ. scripting language, в русскоязычной литературе принято название язык сценариев) — язык программирования, разработанный для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере. Простые скриптовые языки раньше часто называли языками пакетной обработки (batch languages или job control languages). Сценарии обычно интерпретируются, а не компилируются (хотя всё чаще применяют компиляцию каждый раз перед запуском).

Архитектура AI:Архитектура AI представляет собой

конечный автомат(FSM) и состоит из следующих элементов:

BehaviorsStatesPatternsCommandsEvent Handlers

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

State представляет собой набор pattern’ов реализуя отдельное состояние конечного автомата. State представляет действия объединенные одной целью.

Pattern представляет собой набор Command. Pattern определяет отдельные фазы выполнения состояния.

Command представляет собой команду, которая выполняет реальную работу.

Event Handler представляет собой реакцию на событие. На рисунке на следующем слайде номерами показаны приоритеты обработчиков событий.

Таким образом обработчик ищется след. образом:

1)Поиск в текущем Pattern2)Поиск в текущем State3)Поиск в текущим Behavior

Кроме того: Для каждого конечного автомата

существуют 2 специальных state:1. State инициализации (init state)2. State начала работы (start state)

Advanced Behavior (наследование):Behavior позволяет отделить отдельное

поведение, но этого недостаточно когда в игре есть несколько персонажей которые на 90% схожи, но при этом один из них умеет делать A, а второй, например, никогда не сделает B. Для решения данной задачи есть несколько путей:

1. Сделать такой же behavior и добавить/убрать нужное.

2. В нужном месте сделать ветвление ( Если это персонаж 1, то не делаем A)

Advanced Behavior (наследование):Вариант 1 не приемлем из-за повторения

информации. Вариант 2 иногда более эффективен чем

какие-то другие, но если ветвлений много, то сложность(понимания) скрипта возрастает.

Рассмотрим вариант 3. В нем предлагается взять за основу уже созданный behavior и в нужных местах переопределить Pattern,State, Event_Handler.

В каждом состоянии будет находиться один паттерн pt_default, срабатывающий при входе в состояние.

Разрешается использовать только глобальные обработчики событий

1)Дизайнер вбивает описание желаемого поведения объекта на русском языке в следующем формате:“<Имя_шаблона>:<Имя_шаблона>.

<st_init>:Описание инициализируемых параметров;<st_start>:Описание действий. Описание действий. …;<st_name1>:Описание действий. Описание действий. …;<st_name2>:Описание действий. Описание действий. …;

<События>:Возможные события и реакция. Возможные события и реакция. … ;”

2)После нажатия на кнопку “Analyze” происходит проверка на корректность введенного текста. В нее входят в частности:

Проверка на удовлетворение вышеприведенному формату

Проверка на недопустимые символы внутри названий состояний и поведения

Проверка на уникальность названий состояний

3)После нажатия на кнопку “Draw” возникает новая “форма”, в которой будет отображаться диаграмма состояний в виде конечного автомата.

Для этого программа анализирует содержание описаний состояний.

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

Подробнее о библиотеках:Разные компании используют для

разработки разные скриптовые языкиПринцип их работы отличается

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

Для того, чтобы программа была гибкой, требуется подключать библиотеки

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

Подробнее о библиотеках:Первая библиотека содержит в себе информацию о

том, какие слова каким командам соответствуют.Например, слово “прогуливаться” в тексте

описания состояния может соответствовать активации команды на псевдоязыке, предположим “walk;”.

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

К неопределенной форме слова будут приводиться с помощью специальной программы. Планируется использовать парсер “mystem” от компании “Яндекс”.

Подробнее о библиотеках:

Пример работы mystem:

Подробнее о библиотеках:Вторая библиотека будет содержать в себе

информацию о соответствии команд на псевдоязыке командам на реальном скриптовом языке.

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

На диаграмме будут отражены все состояния и возможные переходы из одного состояния в другое.

Внутри блоков состояний через точку с запятой будут указаны команды, описывающие это состояние на псевдокоде

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

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