Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #64, МАРТ 2006 г.

комфортное программирование игр

АЛЕКСАНДР ГЛАДЫШ

Спецвыпуск: Хакер, номер #064, стр. 064-036-2


написать язык самостоятельно?

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

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

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

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

не обязательно писать вручную

Геймдизайнер не обязан обладать квалификацией программиста для того, чтобы иметь возможность задавать логику игры (хотя так он создал бы хорошее подспорье для себя). Часто целесообразнее написать инструментарий для «визуального программирования» логики игры, особенно тогда, когда часть логики представляется в графическом виде более наглядно. Например, удобно делать визуальным редактирование диалогов, карт переходов между локациями и т.п.

Следи за тем, чтобы твой визуальный редактор логики не превратился в неудобную замену «Блокноту». Если нужна гибкость, сравнимая с непосредственным написанием текста программы, позволь дизайнеру писать код в виде текста. Если нужно, просто введи жесткую валидацию вводимого кода — необязательно поддерживать все возможности выбранного языка, достаточно того, что требуется для комфортной реализации нужной части функциональности игры.

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

Если дизайнеру необходима возможность управлять логикой игры посредством редактирования некоторого набора данных, особенно представимых в табличном виде, рассмотри возможность использовать Microsoft Excel в качестве визуального редактора. Этот достаточно мощный инструмент предоставляет богатые возможности по расширению функциональности благодаря диалекту Visual Basic. Обычно геймдизайнеры знакомы с Excel и нередко считают его такой же родной средой для выполнения собственной работы, как программисты — Visual Studio. Excel поддерживает экспорт данных в простой текстовый формат таблиц CSV. К тому же на Visual Basic'е достаточно легко можно написать скрипт для генерации кода на скриптовом языке твоей игры.

Назад на стр. 064-036-1  Содержание  Вперед на стр. 064-036-3