Текст книги "Хочу в геймдев! Основы игровой разработки для начинающих"

Будет вполне логично, если ваша команда станет работать над геймплейным, художественным и техническим прототипом одновременно.

КОМУ ПОКАЗЫВАТЬ ПРОТОТИП

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

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

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

Совершенно иначе обстоит дело, если мы хотим показать прототип широким массам. Чтобы отзывы были честными, зачастую не имеет смысла указывать, что это наша первая игра, над которой мы год трудимся в одиночку в гараже и на «Дошираке». Да, придется столкнуться с непониманием того, что это всего лишь прототип, половина функций пока недоступна и, вообще, «в GTA-5 графика круче». Но если обозначить все известные проблемы и попросить не обращать на них внимания, получить адекватную комплексную оценку будет невозможно. Так что придется стиснуть зубы, спокойно принять все отзывы, предупредив, что сейчас вы демонстрируете именно прототип, не проверяете качество графики, а лишь, например, хотите узнать мнение о core-геймплее.

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

Прототипы очень редко показывают журналистам и стримерам. Первое впечатление очень трудно исправить, поэтому нужно четко осознавать, зачем показывается прототип. Но если игра построена на необычной идее и мы планируем привлечь за счет этого много органического трафика[52]52
  . Органический трафик – пользователи, пришедшие с помощью запросов в поисковых системах или по совету знакомых. Органическим его называют, так как он естественный, бесплатный.


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

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

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

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

Большинство прототипов не пригодятся вам в будущем. Следует относиться к ним как к получению опыта и знаний; это не конечный продукт, а лишь способ вовремя ответить на важные вопросы о проекте. Цель прототипа – не только проверить гипотезу, но и снять риски. Он помогает собрать все шишки, понять, как не надо делать и какие вещи вызывают наибольшие трудности, набраться опыта и наладить взаимодействие между членами команды, не затрачивая много времени и ресурсов.

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

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

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

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

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

Продакшен

Процессы этапа продакшен

На этом этапе нам предстоит создавать уже не прототипы, а полноценную игру. Как правило, этот этап самый длинный, поэтому важно правильно настроить все процессы.

КЛЮЧЕВЫЕ ЦЕЛИ ЭТАПА ПРОДАКШЕН

Вот что нас ждет:

• производство контента;

• вертикальный срез (от англ. vertical slice) – это один или два образцовых уровня вашей игры, которые можно демонстрировать заказчику/игроку. По сути этот этап находится ровно между препродакшен и продакшен. С одной стороны, по его итогам еще возможны значительные изменения, а произведенный контент может не использоваться в готовом продукте. С другой стороны, vertical slice создается уже с полноценными процессами, в хорошем качестве, по его образцу создаются остальные уровни;

• документация. Куда же без нее? Гейм-дизайн-документ (ГДД), маркетинговый план (во время релиза этим заниматься будет уже некогда);

• повседневное управление проектом и решение возникающих проблем;

• корректировка планов и прогнозов, составленных на прошлом этапе;

• результатом этапа продакшен должна стать готовая к демонстрации пользователям версия игры (бета-версия).

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

ПРОЕКТНОЕ УПРАВЛЕНИЕ НА ЭТАПЕ ПРОДАКШЕН

Процессы, построенные на предыдущем этапе, – это основа. Работа с процессами этапа продакшен – не про их построение, а про борьбу с текущими проблемами.

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

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

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

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

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

Работа над построением процессов ведется непрерывно, особенно при использовании Scrum. Все упирается в вопрос, что ждать от людей: если просить мало, скорее всего, и сделано будет мало, а если требовать много, команда будет нервничать, что не выполняются планы. Гибкие инструменты хороши, но всегда есть риск свалиться в хаос. Так что процесс по корректировке пайплайнов[53]53
  . Пайплайн – цепочка процессов разработки продукта.


[Закрыть] ведется постоянно.

АУТСОРС

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

На аутсорс часто отдают работы над артом. Если есть понятный пайплайн, нет смысла временно нанимать в штат много художников. Например, большая часть танков для World of Tanks создается именно аутсорсными сотрудниками. На Западе работу над музыкой и игровым сценарием также принято отдавать на аутсорс, чтобы сотрудники не простаивали. Если же удастся договориться с известным автором, его имя станет еще одним USP проекта, как было, например, с Крисом Авеллоном для Pathfinder: Kingmaker. Локализовать (перевести на разные языки) игру своими силами – тоже неоправданно сложное занятие, лучше обратиться к специализированным внешним компаниям. Если игровой проект предполагает изолированные уровни, даже работу над левел-дизайном можно переложить на внештатных исполнителей.

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

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

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

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

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

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

Другая частая ошибка работы с аутсорсом – непрозрачность процесса работы, отсутствие контроля над исполнителями. Это создает ряд проблем: либо мы можем получить не то, на что рассчитывали, либо, если мы не разбираемся в теме, переплатить. Работать с несколькими исполнителями – хорошая практика, так как мы можем сравнивать результаты и стоимость, чтобы сделать оптимальный выбор. Иногда студии предоставляют услуги даже дешевле, чем отдельные фрилансеры[54]54
  . Фрилансер – это вольнонаемный; человек, который сам берет отдельные заказы. Он не работает на кого-то постоянно, и у него нет фирмы, оказывающей постоянную услугу, но он выполняет работы для разных заказчиков.


[Закрыть]. Качество у них, как правило, выше, ведь все процессы налажены и есть некая взаимозаменяемость (если сотрудник заболел, его подменит коллега, и заказ все равно будет выполнен). Еще вариант: выложить задание на специальных ресурсах и договориться с человеком, предложившим оптимальные условия.

Игровые механики и правила игры

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

Игровые механики – не просто свод правил. Алгоритмы сами по себе, в отрыве от ожидаемых эмоций, не обеспечивают вовлечения. Вы должны позаботиться о том, чтобы игрок всегда мог ответить себе на три вопроса: «Что я должен делать в игре прямо сейчас?», «Как долго я буду в это играть и вернусь ли в игру, например, завтра?» и «Зачем я вообще играю в эту игру?» Это поможет гейм-дизайнеру обозначить краткосрочные, среднесрочные и долгосрочные цели.

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

Другая крайность, когда игроки видят, что игра «помогает» им победить, это вызывает не меньшее разочарование и агрессию. Игрок должен видеть причинно-следственную связь между своими действиями и результатом (не обязательно положительным). Значимость решения – вот что делает игру привлекательной и интересной.

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

Лучше предусмотреть, чтобы игрок понимал последствия своего выбора. Например, в легендарных «Героях Меча и Магии III», в отличие от последних частей, игрок без специального умения не видит силу отряда противников, на который может напасть. Если игрок по каким-то причинам еще не досконально изучил бестиарий игры, откуда ему знать, ждет ли его легкая победа или неминуемая гибель?

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

Не отдельные средства выразительности (диалоги, визуальный стиль, музыка, правила игр и пр.) определяют опыт игрока. Сама реакция игры, интерактивность становится средством выразительности.

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

ДОБАВЛЕНИЕ НОВЫХ ИГРОВЫХ МЕХАНИК

Почти всегда новые механики делают геймплей более комплексным, сложным. Механики могут развивать существующие правила, усиливая значение тех или иных взаимодействий. Например, получив больше бонусов на первом уровне, вы легче пройдете второй; эффективное распределение ресурсов в стратегии на первых этапах игры дает накопительный эффект и преимущества. Результат: проигрывающему игроку очень сложно догнать лидеров, поэтому игра становится более динамичной и быстрее заканчивается. Такое положение вещей может расстраивать группу игроков.

Когда отрыв непреодолим, такая обреченность на поражение или победу делает продолжение игры неинтересным и бессмысленным. Поэтому дизайнеры могут вводить механики, нарочно замедляющие игровое развитие лидера или помогающие отстающим. Например, при определенном количестве жизни шанс на критический урон многократно возрастает, что помогает догнать соперника. Или же в Mario Kart отстающим доступны самые мощные подбираемые бонусы, помогающие временно выбить из строя лидеров и догнать их. Такая возможность закрыть глаза на первоначальные ошибки позволяет сократить разрыв, и финальный этап игры или части игры становится более значимым.

И те, и другие механики кардинально влияют на ощущения от процесса. И снова, только сыграв, можно понять, пошли ли внесенные изменения игровых взаимодействий на пользу, способствуют ли они вовлечению, делают ли конкретную игру более глубокой и интересной. Когда в играх появились стрелочки, указывающие на карте путь до квестов, многие разработчики решили добавить эту механику в свои игры. Для больших игр, где много гринда[55]55
  . Гринд (от англ. grind, grinding – «молоть») – в компьютерных играх повторяющиеся и связанные с небольшим риском действия игроков, направленные на получение внутриигровой выгоды.


[Закрыть], это отличное решение; но для ряда проектов, где важную роль играли нарратив и исследование мира, такое нововведение просто убивало для части аудитории все удовольствие, ведь общение с персонажами и изучение локаций потеряли смысл.

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

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

Вы хотите ввести в своей игре возможность скрытного прохождения. Зачем? Разнообразить геймплей? Да, но это общие слова. А, например, дать возможность спрятаться от врагов и передохнуть, не выходя из приложения, – действительно аргумент в пользу введения этой механики. Часть игроков предпочитает именно такой геймплей, и стелс станет стимулом играть дальше. Или же появляется возможность перепрохождения за счет уникальных игровых ситуаций, доступных только в этом режиме, – вы должны четко обозначить, как изменения сделают игру лучше.