Основные ошибки начинающего геймдизайнера

Максим Вознюк
Геймдизайнер компании "МиСТ Ленд - ЮГ", где работает с 2004 года. Принимал участие в создании проектов "Власть Закона", "Власть Закона: Полицейские Истории", "АЛЬФА: Антитеррор".

Кто есть геймдизайнер для проекта, и что есть проект для геймдизайнера

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

Pre-production

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

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

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

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

Не стоит заниматься вещами, которые размывают ключевые фичи проекта. Фич не должно быть много, иначе, распыляя ресурсы, мы рискуем не сделать основное. Как пример приведу ключевые фичи проекта "Альфа антитеррор":

  • Игра про легендарное российское антитеррористическое подразделение "АЛЬФА"
  • Уникальный геймплей - игра, сочетающая пошаговую стратегию и тактический симулятор
  • Максимально реалистичная игра (более 10-ти операций, имеющих реальные исторические прототипы; реалистичная симуляция боевых действий; реально существующая техника, оружие и экипировка отрядов специального назначения)

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

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

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

К ошибкам, допущенным из-за отрыва от конкретных технологий, можно отнести желание дизайнеров добавить в проект "Альфа: Антитеррор" мирных жителей и животных. Для этого были сделаны все необходимые 3D-модели, но в игре вы их не увидите. Причина: у этих моделей нестандартный скелет, п потому для внедрения его в игру и для настройки физического движка ушло бы сликком много времени. Роль же мирных жителей и животных для геймплея данной игры была не так велика. Но то, что о проблеме внедрения нестандартного скелета своевременно не задумались, привело к лишней работе художников.

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

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

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

Production

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

Техническое задание
Основная проблема, с которой приходится сталкиваться на этапе production, это объяснение главным игроделам (программистам и художникам), что нужно делать, как это должно работать и как выглядеть. Для этих целей есть дизайн-документ, там должно быть все написано и рассказано, но для своевременного и более правильного выполнения поставленных задач необходимо писать техническое задание (ТЗ). Написание ТЗ также должно оградить вас от лишних вопросов.

ТЗ для художников
В ТЗ для художников необходимо точно описать то, что вы хотите увидеть (если есть возможность, приложите скетч). Если это реальный объект, то фотографии (чертеж очень облегчает работу моделлеров), так же информацию об этом объекте (габаритные размеры...) Например, для нашего текущего проекта Warfare пришлось потратить не один день на поиск и сбор информации по западной и нашей технике.

 


Чертежи и фотографии превращаются в игровую модель

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

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

ТЗ для программистов
Написание ТЗ для программистов - более сложная задача. Она требует точной, логически верной, постановки задачи, желательно на языке формул. Желательно всегда объяснять, для чего именно делается тот или иной таск. Так во-первых программистам будет легче понять, чего от них хотят, а во-вторых они смогут заметить какой-нибудь просчет в ваших рассуждениях. ТЗ типа "Вась, я хочу, чтобы персонажи кидали гранаты" не приведет ни к чему хорошему. Да, скорее всего персонажи действительно будут кидать гранаты, но вас очень сильно удивит то, как они будут это делать. Как удивило и меня: бойцы кидали гранаты со стопроцентной точностью независимо от параметров и по такой траектории, по какой ее не сможет запустить ни один атлет.

Создавая ТЗ, пишите на "языке программистов", используйте схемы. Например, для создания моделей поведения бойцов в "Альфе" все схемы реакций были созданы в Visio.

Записывайте все ваши комментарии и ценные указания. Не важно, что вы полтора часа объясняли программисту, как должен вести себя персонаж при событии "вижу врага" - через пять минут он все забудет и сделает по-своему, а потом скажет, что вы именно так и говорили.

Особенно неприятные проблемы у нас возникли с разработкой искусственного интеллекта для "Альфы". Пример неточной постановки задачи: "Если в персонажа стреляют, он должен прятаться". Точная постановка задачи: если в радиусе n (n - константа, вынесенная в специальную таблицу для последующей корректировки дизайнерами) метров от персонажа пролетают пули, и он это замечает, то срабатывает событие "под обстрелом". Реакция на это событие должна быть следующая:

 


Логическая схема в Visio: как в зависимости от личных характеристик и типа местности персонаж должен реагировать на стрельбу по нему

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

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

С оружием отдельная история. В игре его насчитывается более ста видов и из-за того, что в начале мы пытались наделить каждый реальными характеристиками, в арсенале появилось куча одинаковых "стволов". В жизни оно, конечно, отличается, но лишь теми параметрами, которые в игре реализовать либо невозможно, либо не нужно (удобство эксплуатации, отказоустойчивость...). Поэтому было принято решение "подгонять" характеристики, сделать так, чтобы однотипное оружие различалось в параметрах: одно точнее, другое убойнее, третье быстрее.

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

 

  
"АЛЬФА": инвентарь с бронежилетами и информация о бойце со списком характеристик

 

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

Есть и примеры отказа от привлекательных гемплейных элементов ради придания реализма. Так мы отказались от разрушаемости окружения. Стена не рушится при стрельбе в нее из пулемета, гранатой ее тоже не возьмешь, да и вообще, спецподразделение Альфа - не отряд разрушителей. Зато у нас есть честная баллистика, пробиваемость материалов (снайпер с В-94 легко может снять врага, прячущегося за не очень толстой кирпичной стеной).

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

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

 

  
"Власть Закона": лог событий и дневник

 

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

В проекте "Альфа: Антитеррор" для пояснения событий мы использовали звуковые сообщения, стилизованные под радиопереговоры (при выполнении промежуточных целей либо при срабатывании какой-либо нестандартной ситуации (расстрел заложников, приход подкрепления...)).

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

С управлением все ясно: необходимо делать так, чтобы игрок мог настраивать функциональные клавиши, чувствительность мыши, если нужно - клавиатуры, (например у нас в "Альфе" вынесено 4 варианта настроек для камеры, так как управление камерой очень сильно влияет на контролирование ситуации на уровне). И не стоит изобретать велосипед, если это шутер, то управление - WSAD и мышь, если стратегия, то - Сtrl+1,2... - выделение групп, qwe-команды и так далее.

Уровень сложности. В силу того, что игроки обладают разными навыками, желательно делать сложность игры настраиваемой. Это расширяет аудиторию.

Гемплейные элементы. Во "Власти Закона" настраиваемыми элементами геймплея были: отображение хексов, пути персонажей, их передвижение, стрельба, враги, мирные жители, союзники, нейтралы, техника; скорость анимации. Изменяя параметры, игрок мог настроить игру так, как удобно именно ему, а не дизайнеру.

 

  
"Власть Закона": настройки игры

 

Очень хороший пример настраиваемого гемйплея - игра "Ил-2". Ее опции позволяли из хардкорного симулятора сделать аркадную леталку.

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

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

Наш проект "Власть закона" представлял из себя нелинейную тактическую RPG. Вот основные проблемы, с которыми мы столкнулись в процессе реализации этой самой нелинейности:

  1. Для реализации нелинейного сюжета понадобилось создавать свой узкоспециализированный язык скриптования, на что ушло приличное количество ресурсов
  2. Нелинейность значительно увеличила объем игрового контента (сценарий, диалоги, уровни и тд)
  3. Сценарии миссий должны были быть универсальными для различного прохождения. В зависимости от того, кто в команде у игрока, должны были различаться диалоги и задания. Например, есть ключевой диалог, в котором могут участвовать от одного (главного героя), до 8 (максимальное количество в команде) человек, и в зависимости от того, кто в команде, в диалоге участвуют разные персонажи, но при этом основной смысл сохраняется.
  4. Создание (скриптование) и тестирование нелинейных сюжетов очень сложно и трудоемко, (например, на одном из уровней к главному герою подходит ничем не примечательный персонаж (проповедник), читает проповедь и уходит; но от того, убьет его игрок или нет, зависит, что с ним будет происходить через три уровня). И таких мелких деталей, которые влияют на сюжет, в игре множество. При написании скрипта необходимо помнить обо всех мелких составляющих и контролировать их правильную работу, как в отдельности, так и в комплексе. Просчитывать и реализовывать всевозможные повороты сюжета. Еще пример: у нас есть две противоборствующие силы, игроку надо выбрать одну из них и уничтожить другую, так вот найдутся кучи игроков, которые уничтожат всех, и этот случай тоже обязательно надо учесть.

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

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

www.dtf.ru