Разработка изнутри. Часть 1

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

Общие положения

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

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

Было бы неправильно в общих положениях не указать маленькую, но очень важную деталь. Если в команде разработчиков несколько специалистов одного рода деятельности, то всех их объединяет один главный. Так, например, главный программист возглавляет работу всех программистов, отвечая за техническую реализацию, а для главного художника нет дела важнее, чем ваять дизайн, делить работу и просто руководить подчинёнными художниками и дизайнерами.

В таких случаях ключевыми в проекте являются вышеупомянутые главный программист, главный художник и главный гейм-дизайнер, которому подчиняются два перечисленных до него товарища. Главный гейм-дизайнер – почти всегда лидер проекта. В профессиональной игровой индустрии может также иметь подчинённых ему игровых дизайнеров (гейм-дизайнеров).

Но хватит общностей, переходим к делу. Первыми в списке стоят, конечно же...

Гейм-дизайнеры

Не зря именно эта профессия – самая желанная. Никто не хочет быть просто программистом или художником, все горят желанием руководить, именоваться Лидером, но вместе с тем мало кому известно практическое значение этого слова.

Как говорилось в прошлой вводной статье (см. «МБ» №44’2006), гейм-дизайнер прорабатывает игровую вселенную, концептуально обдумывает и конспектирует все свои идеи и «фичи». Всё это ложится в основу концепт-документа (очень редко концепция именуется «гейм-фокусом»). Сразу остановимся здесь, чтобы сделать важное замечание. Концепт-документ – это не дизайн-документ (диздок), и пишется он зачастую без согласования с другими членами команды. Цель написания концепт-дока – краткое, но ёмкое документирование всех идей и приведение их к какой-то единой структуре. На данном этапе гейм-дизайнер постоянно отказывается от одной идеи из-за противоречия с другой, формализует их и связывает друг с другом.

Дмитрий Ножнин, дизайнер миссий игр «Аллоды» ½, «Проклятые земли», «Демиурги» ½ и т.п., предлагает следующий список основных занятий гейм-дизайнера (я добавил к ним свои пояснениями). Итак, гейм-дизайнер (см. также иллюстрацию):

генерирует идеи. Для целостности мира и геймплея большую его часть придумывает один специалист;
оценивает идеи. Плох тот специалист, который не в состоянии объективно оценить собственный продукт; так и гейм-дизайнер – в его задачу входит не просто генерация идей, а отсеивание одних в угоду другим;
документирует идеи. Думаю, не стоит упоминать, что без диздока сделать сложный игровой проект невозможно; к тому же, на основе всех документированных положений игры и работают программисты и художники – никакой самодеятельности, всё на основе диздока;
учитывает взаимосвязи. Отсутствие взаимосвязей между разными элементами геймплея – одно из упущений в моём первом проекте; основная проблема в том, что многие начинающие игрострои нашпиговывают игру многочисленными прелестями, зачастую ненужными и не влияющими друг на друга;
формализует идеи. Однокоренное слово – «форма». То есть это этап, когда уже документированные идеи приобретают законченный вид в дизайн-документе;
«видит» игру. Очень важное умение гейм-дизайнера – способность «поиграть» ещё до того, как игра будет сделана. А для этого надо обладать как минимум хорошим воображением.

Роль гейм-дизайнера в проекте.

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

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

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

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

Программисты

Скажу сразу – я не тот программист, который делает игры. Фактически я веб‑программист, но это не означает, что мне неведома программная сторона девелопинга (чуть было не написал «тёмная сторона силы»). Программная реализация – такой же неотъемлемый элемент разработки, как и гейм-дизайн. Работа программистов не менее ответственна, и заключается она в точной материализации задумки гейм-дизайнера. Первое правило для программистов – минимум самодеятельности – максимум соответствия
поставленным в дизайн-документе техническим задачам (который, как сказано выше, вытекает из концепта в результате совместного «обмозговывания» гейм-дизайнером, программистом и художником).

Программисты пишут так называемый «движок» – у всех это слово на слуху, но никто толком не может дать точного определение... Точного, пожалуй, тут и не подобрать, но определить движок можно по задачам, которые он выполняет.

Движок (engine) – программа, занимающаяся управлением, взаимодействием и выводом контента. Как подвид – графический движок.
Графический движок (graphics engine) – выводит картинку на экран, то есть выполняет рендеринг (термин применим только к 3D-движкам и означает отрисовку).
Контент (content) – буквальный перевод – «содержимое». Фактически это наполнение игры: техническое (модели, текстуры, уровни (или карты)) или непосредственно игровое (персонажи, диалоги, квесты (они же задания)).

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

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

Не стоит забывать и об общих советах программистам (перечисляю самое основное, из-за чего сам неоднократно страдал).
1. Изобретение велосипеда – распространённая ошибка. Обычно программисты пытаются сварганить свой велосипед, полагая, что он будет лучше, быстрее,
«грузоподъёмней» и т.д. Но если нет навыков – не стесняйтесь подсмотреть, как та или иная функция реализована у других.
2. Будьте готовы к метаморфозам. Даже в самый подробный диздок после пре-альфа версии игры могут (и так всегда бывает) вноситься коррективы. Соответственно, придётся много раз что-то менять, переделывать, добавлять, убирать и даже восстанавливать ранее использовавшуюся деталь. Поэтому...
3. Протоколируйте действия и сохраняйте резервные копии всего, что меняете. Одно время у меня было по три и более промежуточных варианта одной и той же части движка – и не только его. Этот совет в равной степени относится ко всем специалистам геймдева.
4. Не уничтожайте ненужное и старое, пока не убедитесь в работоспособности нового. Как-то я удалил старый вариант боя с врагом, а новый, как выяснилось впоследствии, оказался неработоспособным, из-за чего в «SoSS: FW» (обзор игры см. «МБ» №45’2006) его и нет. Поэтому прежде чем удалить что-то старое, удостоверьтесь, что новое протестировано, отлажено и работоспособно.

Отладка (debug) – непрерывный от начала программирования до завершения проекта процесс «отлова» и искоренения багов. Продолжается и во время альфа- и бета-тестирований.
Баг (bug) – ошибка в программном коде, из-за которой нарушена правильная работоспособность чего-либо или работоспособность в целом. Синонимы – «глюк», «дыра» и т. п. (программистам виднее, как называются их ошибки). Кстати, bug переводится не только как «дефект», второе значение слова – «жук» (если быть более точным, то «жук» – это основное значение данного английского слова. Синонимом «ошибки в программе» слово «bug» стало в начала прошлого века. Как вы знаете, тогда компьютеры были очень большими (см. «МБ» №34’2005) и занимали целые подвалы. И вот в этих подвалах иногда водились самые обычные тараканы. Жуки, привлекаемые теплом ламп (а именно электронные лампы были основной вычислительных машин того времени), заползали во внутренности компьютеров и вызывали сбои в их работе. Отсюда и пошло выражение «Завёлся жук (bug)», впоследствии ставшее синонимом понятия «сбой в программе». – НП). Отсюда в простонародье пошло название ошибки – «таракан».

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

5. Программист занимается программированием. «Так это и так понятно!» – воскликнете вы. Понятно, но не всегда так. Гейм-дизайнер не должен перекладывать часть своих полномочий на плечи программиста – у того и своей работы много. Программисты мыслят алгоритмами, циклами и методами, а вот в гейм-дизайне совсем не разбираются – и вообще не должны!

Приведу пример. Недавно в диалоге с программистом я описывал принцип работы инвентаря: «На любое недопустимое действие предметов из инвентаря в окошке нижнего левого угла появится скромная запись – мол, низзя!» На что программист недоумённо ответил: «А я бы просто вызвал окошко, в котором было бы написано то же самое!» С точки зрения программирования такой вариант возможен, но вот с точки зрения гейм‑дизайна... Представьте: игрок решил попробовать «на вкус» все 10-15 предметов, но на каждое своё действие встречает предупредительное окошко... мне бы надоело. А вам?

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

Пожалуй, к сказанному о программистах в пределах этой статьи я не могу ничего добавить. Да и заглушка в виде букв «МБ» уже совсем близко... Поэтому хочу вас огорчить – продолжение статьи вы сможете прочитать одном из ближайших номеров.


Рекомендуем почитать: