Главная » Документация » Использование языка скриптов в играх

RSS

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

Скрипты в играх
Ок, я признаю это. Я – ленивый программист. Всякий раз, когда я могу избегать неприятностей из за этого, я люблю поручать делать мою работу другим людям. И как программисту, занимающемуся играбельностью и моделированием, жизнь подбрасывает мне все больше и больше проблем. 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, что дало преимущество быстродействия код с легкостью к использованию заказного языка.

Страницы : 1 2 3 4

Таги: