Использование языка скриптов в играх

Содержание

Введение
Снежный ком
Неприемлемые пути
COG
Модель выполнения
Контроль доступа
Трансляция
Золотая середина
Сборка всего вместе
Как Вы делали все это?
Список ссылок

Введение

Ок, я признаю это. Я - ленивый программист. Всякий раз, когда я могу избегать неприятностей изза этого, я люблю поручать делать мою работу другим людям. И как программисту, занимающимуся играбельностью и моделированием, жизнь подбрасывает мне все больше и больше проблем. Sound mixing, 3D rendering, обработка прерывания - становятся все проще и проще, моделирование поведения становится все тяжелее и тяжелее. Теперь, когда мы имеем DirectSound и DirectDraw, когда мы можем ожидать DirectGameplay?

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

Проблема состоит в том, что пользователи требуют большей интерактивности и непредсказуемости для их игр. Они не удовлетворены 10 типами оружия, когда ваш конкурент имеет 20. Перемещающихся платформ не достаточно, если какая-то другая игра имеет вращающиеся платформы. Так что-же делать ленивым программистам?

Язык скриптов был неотъемлемой частью игр много лет. Намного раньше чем экшен игры исчерпали биты, авторы квестов ощутили потребность в создании сценария, чтобы справиться с большим количеством возможных взаимодействий в их мирах. SCUMM (Story Creation Utility for Maniac Mansion), один из первоначальных языков квестов, остался фактически неизменным до сегодняшнего дня, и все еще используется для игр типа MONKEY ISLAND 3. Когда другие игровые жанры типа экшен, симуляторы, и стратегии становятся более сложным, они также включают в себя скрипт-системы для создания сценария.

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

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

Снежный ком

Более чем три года назад, группа, разработчиков DARK FORCES предприняла нетрадиционный шаг выполнения некоторых из важных готовых систем, использующих специальный анализируемый язык кодов операции по имени INF. INF использовался для простых задач типа перемещающихся секторов и подъемников вокруг, прослеживая цели задания, и генерируя новых врагов. INF не требовал синтаксического анализа, потому что формат был прост и понятен - эквивалент ассемблера. Одна из целей проекта в создании продолжения DARK FORCES должна была развернуть и расширить INF язык, делая его более мощным и дружественным.

Одна из основных жалоб от проектировщиков уровня в первоначальном проекте была та, что INF требовал использования большого количества специфических флажков и кодов операции, чтобы использовать различные свойства. Рядом с АРМ проектировщика была пачка страниц, известная как " Zen и искусство INF". Первый проект замены INF сохранил базисную структуру, но транслировал числовые коды и флажки в текст, так что эта "библия" больше не будет необходима.

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

Неприемлемые пути

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

Первую остановку сделали на каталоге свободных трансляторов в http://www.idiom.com/free-compilers/ Здесь, Вы можете найти десятки, если не сотни, существующих библиотек созданий сценария, которые могут быть связаны с вашей прикладной программой. Каждый из них имеет различные преимущества и недостатки. Некоторые очень просты, типа LISP или FORTH, в то время как другие совершенно сложны, типа JAVA, Tcl или LUA. Большинство этих языков полностью бесплатны, это программы университетских или правительственных научно-исследовательских лабораторий. Основной недостаток в использовании готового языка - эффективность. Многие из языков по крайней мере частично интерпретируются, и многие не обеспечивают исходный текст для рун-тайм библиотеки. Если время разработки, является первичным интересом, или если ваша прикладная программа меньше зависит от быстродействия, то там , возможно, найдется что-нибудь подходщее.

Так как быстродействие было первичным интересом, возможность расширения энжайна через динамические библиотеки (DLL's) вместо языка сценариев рассматривалась. Преимущество в быстродействии выполнения было ясно видно, но использование DLL будет трудным для дизайнеров. Даже при том, что мы чувствовали удобное введение их к ограниченному C синтаксису и структуре, мы не хотели делать дальнейший шаг введения их к сложностям трансляторов, среды разработки, линковке, и так далее.

Заключительная операция, та, которую мы в конечном счете и выполнили, должна была создать заказное ядро выполнения языка и синтаксический анализатор. Проблема быстродействия была решена, выполняя важные, критичные ко времени операции в коде и экспортируя функции поддержки системе языка как COG библиотечные функции. Эти библиотечные функции могли бы быть увеличены через DLL, что дало преимущество быстродействия код с легкостью к использованию заказного языка.

COG

Остальная часть этой статьи рассматривает проблеме и решения языка , котрые мы использовали в создании 3D игры JEDI KNIGHT: DARK FORCES 2

Язык JEDI KNIGHT, который дизайнеры окрестят COG, мы выбрали весьма похлжим на С. При использовании C как отправной точки, мы удалили большинство ненужных нам ключевых слов и конструкций и даже удалили некоторых довольно важные части языка, имеющие дело с функциональными объявлениями и инструкциями swith, потому что они были значительно более сложны, чтобы анализировать и выполниться чем остальная часть языка. Мы выбрали Язык C как отправную точку из-за множества книг, и учебников которые доступно обучают непрограммистов языку.

Точно как в C, синтаксис COG языка менее важен чем библиотека функций. COG библиотека обеспечивает около сотни различных функций автору, в пределах от команд манипулирования среды к информационным запросам. Автор использует эти функции, чтобы управлять готовой средой при использовании синтаксиса языка, чтобы обеспечить управление циклами и переходами.

Энжайн выполняет сценарий с помощью событийного программирования. Например, когда два объекта сталкиваются друг с другом в энжайне физики, любые сценарии COG, связанные с любым объектом получают событие "Touched". Это событие содержит параметры, которые позволяют сценарию идентифицировать, которые объекты включались в случае и тип события, которое произошло. Основанный на этой информации, сценарий может управлять готовым состоянием любым способом, которым пожелает, или может просто игнорировать событие. COG сценарии может также содержать связи, которые дают возможность им обмениваться сообщениями. Эти события составляют первичный интерфейс между энжайном и системой языка.

Имеются дополнительные сообщения, которые поставлены непосредственно сценарию COG через объекты, с которыми сценарий COG связан. Сообщение startup послано каждому сценарию COG в начале уровня, и respawn сообщение послано, когда локальный игрок умирает. Каждый готовый объект также имеет способность установить повторяющееся событие импульса или одноразовое событие таймера, которое будет поставлено в некоторой отметке в будущем. Это позволяет комбинацию управляемого событиями и планируемого выполнения.

Потому что мы удалили стандартный C синтаксис для функциональных объявлений из нашего языка, каждый сценарий организован подлобно большой инструкции switch. Точки входа в код для различных типов событий помечены, используя стандарт C, синтаксисом метки. Также, потому что COG развернул на стандарте C типы переменной с добавлением специфических переменных ресурса (сектор, вещь, звук, и так далее), переменные сценария объявлены в специальном верхнем колонтитуле. Редактор уровня также читает этот верхний колонтитул, так что это может отображать символы проектировщикам и позволять им рассматривать редактирование значения символа.

Каждый сценарий, который существует в уровне, связан с любом числом других объектов в том уровне: стенки, враги, двери, другие сценарии COG, и так далее. COG сценарии выполняются как отдельные виртуальные машины, каждая с собственными переменными, стеком, и указателем выполнения. Из-за этого, COG сценарии защищены от друг друга. Один COG сценарий может только воздействовать на себя и объекты, с которыми он связан. Каждый сценарий это отдельный ресурс, который загружен наряду с готовым уровнем. Одиночный сценарий может быть помещен в уровень много раз имея собственную изолированную среду.
Пример COG сценария показывается в Листинге1. Этот сценарий создает вспыхивающий неоновый знак, который (если поврежден) взорвется. Символы, не отмеченные локальными могут изменяться непосредственно в редакторе уровня. Desc= поле сообщает редактору, какую строку отображать, когда дизайнер редактирует эту переменную.

Listing1. Sample COG Script

Контроль доступа

Еще одно важное решение, реализованное в COG состояло в том, чтобы запретить прямой доступ к внутренним машинным переменным и структурам из сценариев. Если сценарий COG хочет получить или изменить эти внутренние переменные, он может сделать это только через обращения к библиотечной функции. Это - важный шаг в создание оказоустойчивого языка. Если сценарий COG будет непосредственно управлять переменными в энжайне, не будет никакой защиты от изменения старых сценариев и системы. Требуя использование функций доступа, любые проверки и сетевая синхронизации могут быть добавлено без того, чтобы непосредственно воздействовать на сценарии. Это требует немного дополнительной работы для программиста языка, так как большее количество функций должно быть написано, но это выгодно в плане стабильности кода.

Библиотечные функции COG - фактически это только указатели на функции C, которые являются видимыми в сценариях COG как глобальные функции. Когда ядро выполнения сталкивается с обращением к одной из этих функций, то переходит к коду C. Код C затем вызывает функции поддержки языка, чтобы получить параметры из стека и возвратить результаты обращения обратно в сценарий. Так как функции находятся в коде С, они выполняются значительно быстрее чем непосредственно язык сценариев. По этой причине, часто выполняемые задачи написаны на C и вызываются как библиотечные функции. Таблица 2 дает примеры типов функций, содержащихся в библиотеке функций COG.

Таблица 2. Пример библиотечных функций GOC

Трансляция

Что-бы код сценария, выполялся наиболее эффективно, он должен транслироваться из исходного текста до некоторого внутреннего представления, которое может быть выполнено наиболее быстро. Этот процесс называется, трансляция, и транслирует наш исходный текст в более упрощенную версию того, что делает нормальный компилятор, транслируя исходный текст в машинный код. Вместо того, чтобы производить машинные коды для Intel или PowerPC, мы производим наши собственные виртуальные машинные коды операций.

Виртуальная машина языка эмулирует CPU. Для COG, мы используем очень простую модель, называемую "стековая машина". Свое название стековая машина получила из того факта, что она выполняет все операции на одиночном стеке. Любой, кто использовал программируемый калькулятор, знаком с этой системой. Чтобы добавлять 5 и 10 на стековой машине, мы выполнили бы такие коды операций

Push 5
Push 10
Add

Стековая машина содержит немного кодов операции, выполняя их весьма просто и эффективно. Наша цель, чтобы быстро компилировать исходный текст, написанный дизайнером в наши коды операции стековой машины. Любая допустимая последовательность команд на языке COG может быть транслированна в эти базисные операции, точно так-же как код C может транслироваться в машинные коды вашего CPU.

Трансляция GOC проходит в два этапа. Сначала, код делится на релевантные части языка или лексемы. COG лексемы, точно так же как лексемы C, включают все ключевые слова языка (if, then, else) и операторы (+, *, &&). Эта стадия трансляции называется лексическим анализом.

Второй этап процесса трансляции включает получение лексем из "лексического анализатора" и трансляции их в синтаксис языка. Это - более сложный процесс основанный на формальной спецификации языка. Формальная спецификация языка определяет подробно каждое возможное выражение, которое может быть создано с языком в рекурсивном формате. Это кажется немного неуклюжим сначала, но становится понятным после некоторого анализа. Например, формальное определение операции сложения

(additionExpression) : (expression) + (expression)

Это определяет выражение сложения как два отдельных выражения, отделяемые лексемой "+". Так как выражение сложения - только одно из многих возможных определений более общего "выражения", Вы можете видеть, как обработка языка быстро становится рекурсивной проблемой. Самый низкий уровень спецификации - "атомы" языка - являются константами и переменными.

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

Возвращаясь к простому примеру сложения, наш синтаксический анализатор должен создать такое дерево синтаксического анализа для исходного текста а = 5 + 10.

Потому что синтаксический анализ языка выполняется рекурсивно, синтаксический анализ автоматически обрабатывает обычно сложные проблемы типа вложения и порядка операций автоматически. Когда код a=(5*2)+(a^2) анализируется, синтаксический анализатор распознает подвыражения 5*2 и a^2 первыми, и передаст завершенные деревья синтаксического анализа для этих подвыражений к коду, который создает дерево для выражения добавления, приводящего к одиночному дереву для всего выражения.

Наиболее сложные выражения, для анализа - это циклы и ветвление. Эти выражения требуют порождения кода, используя коды перехода, что означает, что синтаксический анализатор должен знать адрес, к которому нужно перейти. Например, чтобы генерировать такой код if <condition> then <expression>, синтаксический анализатор должен знать об адресе кода сразу после поддерева выражения, чтобы генерировать код операции GO FALSE, чтобы перейти к этому коду если условное выражение ложно.

При создании кода для этих ветвей код должен генерироваться в двух проходах. Первый проход, известный как "backpatching", не генерирует код, он просто считает число кодов операции, произведенных каждым узлом дерева синтаксического анализа. В течение первого прохода, поскольку с каждым узлом сталкиваются при пересечении дерева, адрес кода (индекс в массиве кодов операции) отмечен, до и после того как коды операции из узла добавлены. После первого прохода, каждый узел содержит адрес кода только до и только после кода собственного поддерева. На второй проход, ветви, которые были предварительно выражены в терминах end of node <expression>, можгут быть выражены как фактические адреса кода.

Это весьма сложная тема, которую мы исследовали только поверхностно. Для подробной информации относительно теории синтаксического анализа и использования деревьев синтаксического анализа, посмотрите - Compilers: Principles, Techniques, and Tools by Aho, Sethi, and Ullman

Золотая середина

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

Одна бесплатная программа, под названием LEX обычно используется, чтобы генерировать код C, выполняющий лексический анализатор, основанный на обеспеченной пользователем спецификации грамматики. С тех пор как COG следует за синтаксисом C, мы изменили существующий файл спецификации C для Lex, чтобы создать лексический анализатор для языка.

Точно так же другая бесплатная программа, называемый YACC (Yet Another Compiler Compiler) может использоваться, чтобы трансформировать формальную спецификацию языка в модуль C. Yacc и Lex разработаны, чтобы работать вместе, так что возникающие в результате модули исходного текста могут просто компилироваться и линковаться, чтобы создать полностью функциональный синтаксический анализатор. Для COG, тот же самый сайт Интернета выдал полную спецификацию грамматики C для Yacc, который был урезан до наших потребностей и использовался, чтобы создать модуль синтаксического анализатора.

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

И Lex и Yacc доступены во многих формах ; некоторый бесплатны, некоторый нет. И в то-же время как Lex и Yacc - наиболее общие инструментальные средства разработки компиляторов, имеется нескоторые другие, включая полномасштабные среды конструкции языка типа VisualParse++ by Sandstone Technologies. Какой-бы инструмент Вы не использовали, конечный результат тот же самый - поток кодов, которые могут быть выполнены быстро и эффективно вашей виртуальной машиной. Проверьте общедоступный каталог компиляторов, упомянутый ранее, для связей с этими и другими полезными инструментальными средствами.

Для более подробной информации относительно инструментальных средств Lex и Yacc, обратитесь к Lex & Yacc by Levine, Mason, and Brown in the O'Reilly & Associates UNIX Programming Series.

Сборка всего вместе

Законченный синтаксический анализатор, разработанный с использованием бесплатных инструментальных средств, упомянутых выше, невероятно быстр и гибок. В типичном уровне JEDI KNIGHT, имеются приблизительно 50 различных файлов сценария, которые должны анализироваться и компилироваться в наш формат кода. На типичной машине, все эти сценарии компилируются, приблизительно, за одну секунду. По этой причине, мы решили использовать не внешний компилятор, а загружать исходники непосредственно при загрузке уровня. Это уменьшает время на тестирование изменений в сценарии, так как дизайнер может быстро редактировать код сценария и перезагружать уровень, чтобы увидеть изменения.

Еще один аспект системы создания сценария, который был критичен для нашего проекта, это интеграция сценариев и редактора уровня. Редактор уровня не только позволяет дизайнеру помещать сценарии в уровень, но также и гарантирует, что различные связи в сценарие правильно назначены и остаются правильно связанными при изменении уровня. Когда дизайнер помещает ресурс сценария в уровень, редактор сканирует заголовок сценария, чтобы определить то что переменные могут быть инизиализированны из-вне и помещает графическое представление ресурса сценария в уровень. Эта иконка имеет пространственное расположение в уровне, хотя расположение не важно для сценария. Обычно, проектировщики помещают сценарии близко от объектов, с которыми они компонуются. Как только сценарий помещен, дизайнер может вызвать диалог значений для этого сценария и просматривать или изменять значения. Если сценарий содержит связи с другими обектами или поверхностями, они назначаются, нажимая на правильный тип предмета в уровне и нажимая кнопку линковки. Связи между сценариями COG и глобальными объектами показываются графически в редакторе, соединяя их линиями. Если сценарий содержит ресурсы типа звуков или битмапов, опускающееся меню отображает возможные выборы.

На что еще хотелось бы обратить Ваше внимание, так это на отладку. Здесь имеются две основные проблемы - отладка синтаксиса, которую обычно решают, добавляя сообщения об ошибках и код восстановления в синтаксический анализатор, и отладку времени выполнения, которая может быть весьм разнообразной. Один из возможных методов отладки времени выполнения состоит в том, чтобы позволить пользователю отслеживать (трассировать) выполнение скрипта. В JEDI KNIGHT, дизайнер может вводить команду с клавиатуры, чтобы запустить трассировку для специфического сценария, которая заставит этот сценарий выводить информацию об отладке, каждый раз когда он будет выполняется. Более полная система учла бы пошаговую отладку сценария. Реальный вызов, который еще не был адресован в COG, должен учесть отладку "исходного уровня", где пользователи могут наблюдать, как их переменные изменяются, и видеть следующий шаг сценария в исходном коде. Эта возможность может показаться ненужной работой, но это была главная просьба, сделанный нашими проектировщиками в конце проекта.

"Как Вы делали все это?"

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

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

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

Я, кстати, тоже не знаю. Я слишком ленив, чтобы выяснить.

By Robert Huebner
Published in Game Developer Magazine, September, 1997
Robert Huebner является старшим программистом на LucasArts Entertainment, специализирующемся в программировании моделирования и сети. До JEDI KNIGHT, он работал над DESCENT и другими играми Interplay Productions. После JEDI KNIGHT, он будет бездействовать в течение месяца. Его может достать в virtual@lucasarts.com

Список ссылок

Адрес автора