ЧТО ХОЧЕТ ОТДЕЛ ГЕЙМДИЗАЙНА ОТ ПРОГРАММИСТА? ОТДЕЛУ НУЖНО, ЧТОБЫ ПРОГРАММИСТ РЕАЛИЗОВАЛ ЛОГИКУ ИГРЫ КАК МОЖНО БЛИЖЕ К ОРИГИНАЛЬНОЙ ИДЕЕ. РАЗРАБОТКА ИГРЫ ВО МНОГОМ ЯВЛЯЕТСЯ ИТЕРАТИВНЫМ ПРОЦЕССОМ — НЕДОЧЕТЫ ОБНАРУЖИВАЮТСЯ НЕИЗБЕЖНО И В ЗАДУМКЕ ГЕЙМДИЗАЙНЕРА, И В ЕЕ РЕАЛИЗАЦИИ ПРОГРАММИСТОМ
Некоторые стадии процесса, такие как балансировка игры, сложно проводить до того, как появится возможность «пощупать» реализацию. Неизбежное следствие — необходимость малоэффективного итеративного взаимодействия: геймдизайнер объясняет программисту, что нужно изменить в игровом процессе, программист меняет, дизайнер обнаруживает, что хотел нечто совершенно другое, и идет объяснять заново. Чтобы повысить эффективность работы, геймдизайнеру нужен инструмент, при помощи которого он самостоятельно сможет влиять на то, что происходит в игровом мире.
Какой язык выбрать
Если бы программист сам занимался геймдизайном или геймдизайнер был квалифицированным программистом, проблем бы не было. Казалось бы, самый мощный инструмент для реализации игровой логики — C++. Однако, к сожалению (скорее, к счастью), в современной игровой индустрии существует разделение труда. Следовательно, здесь работают в основном специалисты узкой квалификации. Редко встретишь хорошего геймдизайнера и квалифицированного программиста в одном лице.
Итак, нужен такой инструмент, который (при гибкости, достаточной для эффективной реализации игровой логики) был бы достаточно простым и не требовал для своего использования развитых навыков в программировании. Подобным инструментом может стать скриптовый язык программирования, подключенный к движку игры. Даже если ты и программист, и геймдизайнер в одном лице, имеет смысл вынести высокоуровневую логику в скрипты — так ты значительно облегчишь свою жизнь.
Скриптовый язык — язык расширения функциональности движка игры. «Скриптовыми» языками в подобном контексте обычно называют интерпретируемые языки программирования, обладающие динамической типизацией. В то же время скриптовым языком может считаться и, например, язык описания конфигурационных файлов игры.
Интерпретируемость языка, при наличии достаточно удобного API к интерпретатору, значительно облегчает его интеграцию в движок и ускоряет разработку, позволяя изменять код, написанный на скрипте, «на лету» без длительной перекомпиляции и, возможно, даже непосредственно во время выполнения программы.
Однако одним из важнейших преимуществ должна быть сравнительная простота языка, чтобы была обеспечена доступность для понимания и непрограммисту, и геймдизайнеру, которые занимаются высокоуровневым программированием и наладкой/балансировкой логики. В идеале, код, написанный на скриптовом языке, должен быть как можно ближе к тексту, написанному пусть и формальным, но человеческим языком. Использовать хитроумные синтаксические конструкции, которые повышают эффективность работы профессионального программиста, в данном случае вредно — понимание кода затруднено даже для обычного человека.
Написать язык самостоятельно?
Часто естественное желание программиста — написать решение любой проблемы с нуля самостоятельно. Скриптовые системы в играх — не исключение. Если ты не занимаешься самообразованием, конечно, с таким желанием нужно бороться всеми силами
.Выбирая готовую скриптовую систему, ты сможешь использовать опыт множества пользователей, которые уже наступили на основные грабли до тебя. Даже если твои требования уникальны, придется обходить только те подводные камни, которые относятся к уникальным местам твоего проекта, а не к скриптовой системе в целом.
Для готовых скриптовых языков обычно уже реализованы удобные среды разработки, отладчики, профайлеры и прочий инструментарий, который пришлось бы писать с нуля. Языки программирования собственного изготовления обычно грешат отсутствием подобных удобств, вплоть до того, что нет вменяемых сообщений об ошибках — на такие вещи просто не хватает времени.
Кроме того, если геймдизайнер не знаком с выбранным готовым скриптовым языком, его изучение повысит квалификацию в общем, а не станет дополнительным грузом бесполезных сведений, пригодных для использования в одном-единственном проекте. Если же геймдизайнер уже знаком с языком — еще лучше, время на изучение нового инструмента будет сэкокомлено.
Не обязательно писать вручную
Геймдизайнер не обязан обладать квалификацией программиста для того, чтобы иметь возможность задавать логику игры (хотя так он создал бы хорошее подспорье для себя). Часто целесообразнее написать инструментарий для «визуального программирования» логики игры, особенно тогда, когда часть логики представляется в графическом виде более наглядно. Например, удобно делать визуальным редактирование диалогов, карт переходов между локациями и т.п.
Следи за тем, чтобы твой визуальный редактор логики не превратился в неудобную замену «Блокноту». Если нужна гибкость, сравнимая с непосредственным написанием текста программы, позволь дизайнеру писать код в виде текста. Если нужно, просто введи жесткую валидацию вводимого кода — необязательно поддерживать все возможности выбранного языка, достаточно того, что требуется для комфортной реализации нужной части функциональности игры.
Оптимальный вариант — тот, при котором визуальный редактор служит ширмой для генератора кода на готовом скриптовом языке. Реализация генератора кода обычно оказывается проще, чем реализация собственного интерпретатора логики. Это также пригодится, если функциональность визуального редактора окажется недостаточной — под рукой будешь иметь всю мощь полноценного скриптового языка.
Если дизайнеру необходима возможность управлять логикой игры посредством редактирования некоторого набора данных, особенно представимых в табличном виде, рассмотри возможность использовать Microsoft Excel в качестве визуального редактора. Этот достаточно мощный инструмент предоставляет богатые возможности по расширению функциональности благодаря диалекту Visual Basic. Обычно геймдизайнеры знакомы с Excel и нередко считают его такой же родной средой для выполнения собственной работы, как программисты — Visual Studio. Excel поддерживает экспорт данных в простой текстовый формат таблиц CSV. К тому же на Visual Basic'е достаточно легко можно написать скрипт для генерации кода на скриптовом языке твоей игры.
Полезные советы
Для всех случаев очень важна полноценная валидация скриптового кода и выдача подробных и исчерпывающих сообщений об ошибках. На стадии активной разработки, даже когда от кода требуется игнорирование ошибки и продолжение работы, обычно лучше обеспечивать вывод отладочного сообщения в лог. Не забывай, что геймдизайнеры, пишущие скрипты, обычно не имеют развитых навыков отладки. Если поведение игры просто отличается от того, которое они ожидают, если не выдаются какие-либо предупредительные сообщения (и даже если «виноват» их собственный код), часто геймдизайнеры, не разбираясь, обвиняют программиста: «А ты глючный движок написал»
.Выводы
РАЗРАБОТКА ИГРЫ НЕЭФФЕКТИВНА, КОГДА ГЕЙМДИЗАЙНЕРУ НУЖНЫ УСЛУГИ ПРОГРАММИСТА, ЧТОБЫ ВНЕСТИ ИЗМЕНЕНИЯ В ИГРОВОЙ ПРОЦЕСС.
ГЕЙМДИЗАЙНЕРУ НЕОБХОДИМ ИНСТРУМЕНТАРИЙ ДЛЯ РЕАЛИЗАЦИИ ВЫСОКОУРОВНЕВОЙ ЛОГИКИ ИГРЫ И БАЛАНСИРОВКИ ГЕЙМПЛЕЯ.
РЕШИТЬ ПРОБЛЕМУ МОЖЕТ НЕСЛОЖНЫЙ СКРИПТОВЫЙ ЯЗЫК, ПОДКЛЮЧЕННЫЙ К ДВИЖКУ ИГРЫ.
КАК ПРАВИЛО, ВЫГОДНЕЕ ИСПОЛЬЗОВАТЬ ГОТОВЫЙ И ОТЛАЖЕННЫЙ СКРИПТОВЫЙ ЯЗЫК, А НЕ ПИСАТЬ СОБСТВЕННЫЙ С НУЛЯ.
В НЕКОТОРЫХ СЛУЧАЯХ УДОБНЕЕ ПРОГРАММИРОВАТЬ СПЕЦИФИЧЕСКИЕ ЧАСТИ ИГРОВОЙ ЛОГИКИ В ГРАФИЧЕСКОМ, А НЕ ТЕКСТОВОМ ПРЕДСТАВЛЕНИИ. В ТАКИХ СЛУЧАЯХ МОЖЕТ ПОМОЧЬ ВИЗУАЛЬНЫЙ РЕДАКТОР, РЕАЛИЗОВАННЫЙ КАК ШИРМА ДЛЯ ГЕНЕРАТОРА КОДА НА ВЫБРАННОМ СКРИПТОВОМ ЯЗЫКЕ.
Популярные открытые скриптовые системы
Готовых скриптовых систем множество, но в играх прижились единицы. Причина? В основном из-за специфических требований, предъявляемых играми к скриптам. К примеру, необходимость в высокой производительности интерпретатора.
Python
(http://www.python.org) Open Source
Автор: Гвидо ван Россум (Guido van Rossum);
http://www.python.org/~guido
Год создания: 1990
Текущая версия: 2.4.2, выпущена 28 сентября 2005 г.
Достоинства:
БОГАТЕЙШАЯ ПО ФУНКЦИОНАЛЬНОСТИ БИБЛИОТЕКА;
БОЛЬШОЙ ОБЪЕМ ДОСТУПНОЙ ДОКУМЕНТАЦИИ И ОБШИРНОЕ КОММЬЮНИТИ;
ПРОСТОЙ СИНТАКСИС;
УДОБСТВО ДЛЯ НАПИСАНИЯ МЕЛКИХ УТИЛИТ;
ПОДДЕРЖКА ЮНИКОДА.
Недостатки:
ДОСТАТОЧНО ТРЕБОВАТЕЛЕН К ОБЪЕМУ ПАМЯТИ.
ПРОИЗВОДИТЕЛЬНОСТЬ НЕВЫСОКАЯ.
ОРИЕНТИРОВАН, СКОРЕЕ, НЕ НА РАСШИРЕНИЕ ФУНКЦИОНАЛЬНОСТИ ПРОГРАММ, А НА РАСШИРЕНИЕ СОБСТВЕННОЙ ФУНКЦИОНАЛЬНОСТИ ЗА СЧЕТ ВНЕШНИХ МОДУЛЕЙ.
ОФИЦИАЛЬНАЯ ИДЕОЛОГИЯ ДИКТУЕТ ЕДИНСТВЕННЫЙ МЕТОД РЕШЕНИЯ КАЖДОЙ ПРОБЛЕМЫ.
НЕТ ВОЗМОЖНОСТИ ЗАПУСКАТЬ СКРИПТЫ «В ПЕСОЧНИЦЕ», БЕЗ ДОСТУПА К ОПЕРАЦИОННОЙ СИСТЕМЕ.
ЧУВСТВИТЕЛЕН К КОЛИЧЕСТВУ ПРОБЕЛОВ В НАЧАЛЕ СТРОКИ, КОТОРОЕ ОПРЕДЕЛЯЕТ УРОВЕНЬ ВЛОЖЕННОСТИ КОНСТРУКЦИИ (ВМЕСТО, НАПРИМЕР, ФИГУРНЫХ СКОБОК В C/C++). ВПРОЧЕМ, К ЭТОМУ МОЖНО ПРИВЫКНУТЬ.
В БУДУЩЕЙ ВЕРСИИ, PYTHON 3000, ПЛАНИРУЕТСЯ СЕРЬЕЗНО НАРУШИТЬ ОБРАТНУЮ СОВМЕСТИМОСТЬ СО СТАРЫМ КОДОМ НА PYTHON 2.X.
Ruby
(http://www.ruby-lang.org) Open Source
Автор: Юкихиро Мацумото (Yukihiro Matsumoto);
en.wikipedia.org/wiki/Yukihiro_Matsumoto
Год создания: 1995
Текущая версия: 1.8.4, выпущена 12 декабря 2005 г.
Достоинства:
СИНТАКСИС УДОБНЫЙ.
ДОКУМЕНТАЦИЯ БОЛЕЕ-МЕНЕЕ ВМЕНЯЕМАЯ, КОММЬЮНИТИ ДОСТАТОЧНО РАЗВИТОЕ.
ОЧЕНЬ УДОБЕН В СОЗДАНИИ СПЕЦИАЛИЗИРОВАННЫХ ЯЗЫКОВ ДЕКЛАРАТИВНОГО ХАРАКТЕРА.
НА БУДУЩУЮ ВЕРСИЮ 2.0 ЗАПЛАНИРОВАНЫ РАБОТЫ ПО УСТРАНЕНИЮ ОСНОВНЫХ НЕДОСТАТКОВ ЯЗЫКА.
Недостатки:
СЛАБОЕ API ДЛЯ ВСТРАИВАНИЯ. НЕТ ПРОДВИНУТЫХ ОБЕРТОК, ПОДОБНЫХ BOOST.PYTHON И LUABIND.
НЕВЫСОКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ.
ТЕКУЩАЯ ВЕРСИЯ НЕ ПОДДЕРЖИВАЕТ ЮНИКОД.
ОРИЕНТИРОВАН, СКОРЕЕ, НЕ НА РАСШИРЕНИЕ ФУНКЦИОНАЛЬНОСТИ ПРОГРАММ, А НА РАСШИРЕНИЕ СОБСТВЕННОЙ ФУНКЦИОНАЛЬНОСТИ ЗА СЧЕТ ВНЕШНИХ МОДУЛЕЙ.
Lua
(http://www.lua.org) MIT (Open Source)
Авторы: Роберто Иерусалимский (Roberto Ierusalimschy), Луиш Энрике де Фигуиредо (Luiz Henrique de Figueiredo), Вальдемар Челеш (Waldemar Celes)
Год создания: 1993
Текущая версия: 5.0.2, выпущена 17 марта 2004 г.
Достоинства:
ПРОСТОЙ И ДОСТАТОЧНО УДОБНЫЙ СИНТАКСИС, БЛИЗКИЙ К КЛАССИЧЕСКОМУ.
ХОРОШИЙ API ДЛЯ ПОДКЛЮЧЕНИЯ.
ДОКУМЕНТАЦИЯ ХОРОШАЯ, КОММЬЮНИТИ ДОСТАТОЧНО РАЗВИТОЕ.
СПЕЦИАЛЬНО РАЗРАБАТЫВАЛСЯ КАК ЯЗЫК ДЛЯ РАСШИРЕНИЯ ФУНКЦИОНАЛЬНОСТИ (EXTENSIBILITY LANGUAGE).
МАЛЕНЬКИЙ И ЛЕГКИЙ (ВСЕГО 150 КБ) ИНТЕРПРЕТАТОР, ОСНОВАННЫЙ НА РЕГИСТРОВОЙ ВИРТУАЛЬНОЙ МАШИНЕ (REGISTER-BASED VIRTUAL MACHINE). ИНТЕРПРЕТАТОР LUA — ОДИН ИЗ САМЫХ БЫСТРЫХ СРЕДИ ИНТЕРПРЕТАТОРОВ СКРИПТОВЫХ ЯЗЫКОВ.
ПОДДЕРЖКА ГИБКОГО, МУЛЬТИПАРАДИГМЕННОГО СТИЛЯ ПРОГРАММИРОВАНИЯ.
УДОБНО ИСПОЛЬЗОВАТЬ КАК ОСНОВУ ДЛЯ СОЗДАНИЯ СПЕЦИАЛИЗИРОВАННЫХ ЯЗЫКОВ (DOMAIN SPECIFIC LANGUAGES).
УДОБНО ОПИСЫВАТЬ ДАННЫЕ, ИНТЕРПРЕТАТОР ЭФФЕКТИВНО РАБОТАЕТ С БОЛЬШИМИ ОБЪЕМАМИ КОДА.
ЭТОТ СКРИПТОВЫЙ ЯЗЫК ИСПОЛЬЗУЕТСЯ В ИГРОВОЙ ИНДУСТРИИ ЧАЩЕ ВСЕГО.
Недостатки:
НЕ ПОДДЕРЖИВАЕТ ЮНИКОД ЯВНЫМ ОБРАЗОМ, ОДНАКО ПОДДЕРЖКА НУЛЕВЫХ СИМВОЛОВ В СЕРЕДИНЕ СТРОК ПОЗВОЛЯЕТ ПРОЗРАЧНО ИСПОЛЬЗОВАТЬ UTF-8.
ОТСУТСТВИЕ НЕПОСРЕДСТВЕННОЙ ПОДДЕРЖКИ ОБЪЕКТНО ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ. КОМПЕНСИРУЕТСЯ БОЛЬШОЙ ГИБКОСТЬЮ ЯЗЫКА И НАЛИЧИЕМ СПЕЦИАЛЬНОГО «СИНТАКСИЧЕСКОГО САХАРА». ТАКЖЕ ОБЪЕКТНАЯ СИСТЕМА ПРЕДОСТАВЛЯЕТСЯ НЕКОТОРЫМИ БИБЛИОТЕКАМИ-ОБЕРТКАМИ, НАПРИМЕР LU-ABIND (luabind.sf.net).
ГЛОБАЛЬНАЯ ОБЛАСТЬ ВИДИМОСТИ ПЕРЕМЕННЫХ, ПРИНЯТАЯ ПО УМОЛЧАНИЮ, ЧРЕВАТА ОШИБКАМИ.
Из опыта
Опыт подсказывает, что Lua — самое удобное средство, которое можно использовать в качестве скриптового языка в игре. Python, благодаря развитым библиотекам, очень удобен как язык для написания утилит. Например, именно на нем реализована довольно удачная система управления сборкой проектов Scons (http://www.scons.org) Также стоит время от времени посматривать на Ruby — этот язык имеет хороший потенциал, который, может быть, раскроется после выхода версии 2.0
АЛЕКСАНДР ГЛАДЫШ, ВЕДУЩИЙ ПРОГРАММИСТ КОМПАНИИ STEP CREATIVE GROUP;