Ричард Лемаршан

Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение

Посвящается Нове

A Playful Production Process: For Game Designers (and Everyone) Richard Lemarchand

© 2021 Massachusetts Institute of Technology

The rights to the Russian-language edition obtained via Igor Korzhenevskiy of Alexander Korzhenevski Agency (Moscow)

© Райтман М.А., перевод на русский язык, 2024

© Оформление. ООО «Издательство «Эксмо», 2024

Предисловие

Я рада называть Ричарда одним из своих самых давних коллег и близких друзей.

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

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

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

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

Не менее важны, я думаю, и «гибкие навыки» (англ. soft skills) сотрудничества и общения, которые описывает Рич.

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

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

Щедрость – осознание того, что мы получаем лучший результат, если все включены в процесс дизайна, что наше ремесло по своей природе импровизационное и что мы приумножаем отличные идеи, говоря друг другу «да, и». Даже если конечный результат окажется неидеальным, куда лучше, если каждый приложил к нему руку.

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

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

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

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

Эми Хенниг,

президент подразделения New Media

Skydance Media

Вступление

Мы должны собраться с мыслями, ибо нас всегда подстерегает неожиданное.

Чарльз Бакстер, «Праздник любви»

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

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

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

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

Меня зовут Ричард Лемаршан, и я гейм-дизайнер. Я проработал в мейнстриме игровой индустрии более двадцати лет, начав карьеру в компании MicroProse в Великобритании, где стал младшим членом группы, основавшей в компании подразделение разработки под игровые консоли. Я переехал в Калифорнию в середине 1990‑х годов для работы в компании Crystal Dynamics, где я участвовал в создании серии игр Gex, Pandemonium! и Soul Reaver. Я по-прежнему страстно благодарен за все, чему меня научили мои наставники, товарищи по команде и друзья в MicroProse и Crystal. С 2004 по 2012 год я был гейм-дизайнером в компании Naughty Dog в Санта-Монике. Я помог закончить Jak 3, а затем стал ведущим гейм-дизайнером Jak X: Combat Racing. Позже я руководил или помогал руководить разработкой всех трех игр серии Uncharted для PlayStation 3. Uncharted 2: Among Thieves стала огромным успехом для Naughty Dog, выиграв десять наград от Академии интерактивных искусств и наук (AIAS), пять наград Game Developers Choice Awards, четыре премии BAFTA и более двухсот наград в номинации «Игра года». Проделанная нами работа в Naughty Dog – это пример мудрости, смелости и игрового подхода команд разработки.

В 2005 году я начал выступать с лекциями и обучать студентов в Университете Южной Калифорнии (англ. University of Southern California – USC). Этот опыт, наряду с ростом популярности инди-игр, побудил меня задуматься о том, как я мог бы рассматривать игры через призму искусства и культуры, исследований и критики, влияния и образования. Мне предложили должность в Школе кинематографических искусств USC, и я покинул Naughty Dog, чтобы присоединиться к USC в 2012 году. С тех пор я преподаю и создаю игры в команде талантливых преподавателей, сотрудников и студентов USC Games.

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

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

Рис. 0.1. Четыре этапа, майлстоуны и результаты процесса разработки игр. Авторы изображения: Габриэла Пурри Р. Гомес, Мэтти Розен и Ричард Лемаршан

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

Игровая индустрия всегда страдала от кранчей – неконтролируемых переработок, которые вредят отдельным людям, сообществам, организациям и самим играм. Эта книга поможет вам решить такую проблему или избежать ее. Внесу ясность: мне нравится тяжелая работа, и я считаю, что для создания совершенства иногда могут потребоваться дополнительные усилия. Но есть разница между тяжелой работой и кранчем. Тяжелую работу можно поддерживать длительное время, если контролировать себя и устраивать передышки между интервалами повышенной трудоемкости. Кранч нельзя поддерживать. Он вызывает выгорание, вынуждает пропускать важные события в жизни своей семьи и друзей, а многих разработчиков и вовсе подталкивает покинуть игровую индустрию, унеся с собой всю свою с трудом заработанную мудрость и опыт.

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

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

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

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

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

С помощью этой книги вы будете разрабатывать и создавать игры, пользуясь игроцентрическим подходом, применяемым в USC Games и описанным Трейси Фуллертон в книге Game Design Workshop: A Playcentric Approach to Creating Innovative Games[1] («Мастерская гейм-дизайна»). Вы будете разрабатывать итерационно, проходя через циклы принятия решений, реализации, плейтестов и пересмотра дизайна. Вы поймете, что значит определять и уточнять цели проекта в течение разработки.

Вы изучите методологию продакшена и дизайна, основанную на «Методе», используемом в таких студиях, как Naughty Dog и Insomniac. Этот Метод также включает в себя подходы и элементы Agile-разработки (от англ. agile development – «гибкая методология разработки»). Вы будете воплощать свои идеи, используя методы полета мыслей[2] и исследования. На определенном этапе вы создадите вертикальный срез, макродизайн игры и составите план. Вы узнаете, как и когда подогнать скоуп (от англ. scope – «масштаб», «объем») вашего проекта таким образом, чтобы надежно обеспечить высокий уровень качества. Вы проведете ваш проект через стадии альфы и беты и по итогу каждой подготовите соответствующую версию игры. В конечном счете вы узнаете, что требуется, чтобы закончить игру – или любой другой интерактивный проект.

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

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

Если вы уже провели некоторое время в игровой индустрии, то заметите, что сказанное мной на страницах книги представляет собой несколько идеализированный взгляд на процесс разработки игр. Меня это вполне устраивает. В разработке игр, как и в жизни, все несколько запутанно. Я прошел этап, когда мои идеалы разбились о реалии этого мира. Но я снова и снова встречал людей, которые соответствовали идеалам, казавшимся кому-то недостижимыми. При этом они создавали нечто новое и замечательное, о чем прежде никто и не задумывался. Идеализм ценен: это один из способов сделать мир лучше. Там, где идеализм встречается с опытом, рождается мудрость.

Первый этап: формирование идей – идеация

Глава 1

Как начать

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

В своей книге Game Design Workshop: A Playcentric Approach to Creating Innovative Games Трейси предлагает начать наш процесс проектирования с определения «целей опыта игрока». Она говорит:

Суть целей опыта игрока заключается в их же названии: это те цели, которые гейм-дизайнер устанавливает для того типа игрового опыта, который игрок получит во время игры. Это не особенности игры, а скорее описание интересных и уникальных ситуаций, к которым вы надеетесь привести игрока[3].

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

Некоторые проекты, над которыми я работал, были сиквелами, где мы уже примерно знали, какую игру собираемся сделать. Но что делать, если мы начинаем с нуля? Как нам преодолеть знаменитую проблему «чистого листа», когда мы парализованы огромным выбором, потому что мы могли бы сделать все что угодно, но не можем решиться начать хоть что-то?

Правильный способ решить проблему чистого листа – перестать думать об общей картине. Выбросьте образ готового проекта из головы – слишком рано беспокоиться об этом – и начните с одного из этих трех методов формирования идей:

• полет мысли (придумывание идей);

• исследование (поиск идей в книгах и интернете);

• прототипирование (сборка простых вещей, с которыми можно поиграть и оценить результат).

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

На этапе формирования идей мы определим одну, две или три вещи, которые сделают нашу игру уникальной и выделяющейся. Как только у нас появится какой-то креативный дирекшен, которым мы начнем руководствоваться в последующем процессе, мы будем готовы установить цели проекта и отметить окончание этапа идеации. Чтобы у нас был дирекшен, цели проекта будут конкретными, но они также останутся открытыми, чтобы дать нам пространство для маневра по мере разработки. Мы подробно рассмотрим это в главе 7 «Цели проекта».

Мы также ненадолго остановимся на изучении «Коммуникации как навыка гейм-дизайна» в главе 6. Общение – краеугольный камень для построения среды, в которой царит атмосфера уважения, доверия и согласия. Именно оно поможет стать лучше как сотрудникам, так и творческим руководителям.

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

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

Глава 2

Полет мысли

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

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

Мозговой штурм

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

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

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

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

• Назначьте организатора. Выберите ответственным одного члена группы. Поручите ему продвигать мозговой штурм вперед, вносить первые идеи и следить за тем, чтобы…

• Одновременно говорил только один человек. Тогда ваш полет мысли не будет терять темп и превращаться в нечто неподконтрольное, а другие члены команды смогут продемонстрировать уважение друг к другу и выработать доверие. Организатор должен также убедиться, что…

• У каждого есть возможность высказаться. Хорошие идеи могут исходить от каждого члена команды, но некоторые могут стесняться высказаться. Компетентный организатор заметит, когда кто-то хочет внести свой вклад, но испытывает трудности с вступлением в разговор, и поможет ему влиться в процесс обсуждения. Организатору или кому-то другому в команде следует поручить…

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

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

• Говорите «да, и» – объединяйте и улучшайте идеи. Это отличный способ продолжать двигаться вперед, особенно когда у вас в голове становится пусто. Используйте технику импровизационной комедии «да, и», часто применяемую в театре, взяв одну из предыдущих идей и дополнив или изменив ее.

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

Оценка результатов мозгового штурма

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

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

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

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

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

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

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

Ментальная карта

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

Рис. 2.1. Майнд-карта по теме «мороженое»

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

Автоматизм

В начале двадцатого века группа художников, известных как сюрреалисты, была очарована новой идеей бессознательного. Они стремились исследовать его в погоне за знаниями и свободой от ограничивающих социальных условностей. Они изобрели много методов для этого и многие из них описали как игры. Если вас интересует такой тип творческого мышления, я настоятельно рекомендую вам книгу Алестера Бротчи и Мела Гудинга A Book of Surrealist Games.

Одна из любимых техник сюрреалистов называлась автоматизмом (от слова «автоматический», то есть «сделанный спонтанно»). Этот метод предлагает вам просто сесть с листом бумаги и карандашом или за компьютер и установить таймер на период от четырех минут до часа. Запустите таймер, а затем начинайте писать (или рисовать, если хотите), пока не закончится отведенное время. Не делайте пауз и не мешкайте, пишите все, что приходит вам в голову. Следуйте за своим потоком сознания. Это будет довольно легко, если вы честно будете следовать предлагаемой методике. Не просматривайте и не анализируйте то, что вы записываете или рисуете.

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

Другие техники полета мысли

Это всего лишь небольшая подборка разновидностей полета мыслей. Есть множество других, например метод нарезки, который Трейси Фуллертон описывает в главе 6 своей книги Game Design Workshop[5]. Вы также можете завести журнал, сделать раскадровку, случайным образом открыть несколько статей на «Википедии»[6] или же применить вашу любимую технику гадания. Ведите записную книжку на протяжении всего проекта: в ней будут храниться ваши идеи, планы, эскизы и диаграммы, а также наброски и прочие мысли для дальнейшего размышления. Если вы поищете в интернете «методы формирования идей», вы найдете еще много советов по разнообразным техникам.

Дизайнеры, электронные таблицы и сила списка

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

Большая часть дизайн-документов, которыми мы пользовались во время моей работы в Naughty Dog, была представлена в виде электронных таблиц. Когда я впервые увидел электронную таблицу, то очень испугался! Это было похоже на что-то из лихорадочного сна бухгалтера, и я не мог понять, что с этим делать. Сегодня я люблю электронные таблицы, это отличный инструмент в работе гейм-дизайнера и лучший способ быстро и легко организовать информацию.

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

Фраза «сила списка» популярна среди интересующихся управлением проектами. У списков есть сила, потому что знание – сила. Списки, которые мы регулярно просматриваем, помогают нам удерживать все наши идеи в голове. Имея доступ к актуальному списку чего-либо, относящегося к вашей игре (например, список всех персонажей или всех собираемых предметов в игре), вы можете сделать эту составляющую игры превосходной и весьма эффективной. В команде со здоровыми отношениями такими списками принято делиться, поэтому всегда размещайте их там, где их смогут увидеть ваши коллеги. Поддерживайте список актуальным: это отличный показатель того, что вы ответственный дизайнер. Гораздо эффективнее вести список изо дня в день на протяжении всего проекта, чем обновлять его, когда внезапно требуется содержащаяся в нем информация.

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

* * *

Иногда люди думают о творчестве как о мистическом процессе, поддающемся только гениальным от рождения авторам. Я верю в моменты эврики!, те вспышки вдохновения, когда мы внезапно цепляемся за нечто новое и великое. Но я также верю в справедливость наставления Томаса Эдисона, что гений – это «один процент вдохновения и девяносто девять процентов пота». Вот почему нам нужны быстрые мозговые штурмы для генерации большого количества идей: чтобы проработать девяносто девять так себе идей и найти ту единственную, которую мы ищем.

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

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

Глава 3

Исследование

Исследование – один из моих любимых этапов формирования идеи и один из важнейших этапов при создании каждой игры Uncharted. Мы хотели, чтобы наши истории опирались на исторические и географические факты, потому что знали, что такое «заземление» добавит достоверности в глазах нашей аудитории. Мы хотели, чтобы игра проходила то, что директор Uncharted Эми Хенниг называет «Google-тест»: если бы вы искали в интернете какое-то историческое событие или место из игры, вы бы нашли цепочку фактов, ведущих вас в реальный мир. Мы думали, это поможет разжечь любопытство людей и, возможно, даже сделает наши игры слегка познавательными.

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

Исследования в интернете

До эры интернета нам приходилось ходить в библиотеку или покупать много книг, чтобы провести исследования для игры. Теперь, когда у нас есть «Википедия», Google и 366 миллионов зарегистрированных доменных имен в интернете, невероятное количество информации доступно всего за несколько кликов.

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

Поиск изображений

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

Как только вы соберете хороший урожай картинок, составьте мудборд (коллаж) или расположите их на отдельной странице вокруг определенной идеи или темы. Размещение двух, казалось бы, несвязанных картинок рядом друг с другом может вызвать совершенно новые идеи и чувства, как в знаменитом эффекте Кулешова[8]. Креативные индустрии, такие как кинопродакшен, маркетинг и гейм-дизайн, используют мудборды, чтобы быстро и эффективно передать концепцию и начать дискуссию о будущем направлении. Никогда не поздно начать собирать свои мудборды или монтажи, используя программы вроде Microsoft Paint, Adobe Illustrator или онлайн-сервиса Pinterest.

Не пренебрегайте библиотекой

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

Экскурсии

Некоторые из лучших исследований проводятся за пределами студии, дома или офиса. Студия Pixar славится своими исследовательскими поездками в необычные, отдаленные места – неземной мир Райского водопада в их фильме 2009 года «Вверх» был вдохновлен посещением столовых гор Тепуи в национальном парке Канайма в Венесуэле.

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

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

Интервью

Проведение интервью – отличный способ найти новые идеи и подогреть ваш творческий интерес. Позже мы рассмотрим, как важно ставить людей в центр вашего дизайн-процесса, используя плейтесты и другие методы. Трейси Фуллертон называет это игроцентрическим гейм-дизайном; это часть гуманистического дизайна, истоки которого можно найти в истории[9]. Гуманизм процветал в движении «Искусств и ремесел» девятнадцатого века, в работах архитекторов двадцатого века, таких как Фриденсрайх Хундертвассер и команда Аракавы и Мэдлин Гинс, а также в инновациях антропоцентрического дизайна креативного агентства IDEO Кремниевой долины, и это лишь некоторые из них.

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

Теневой повтор

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

Теневой повтор дает нам возможность глубже проникнуть в жизнь, интересы и предпочтения исследуемых. История этого метода берет начало в исследованиях 1950‑х годов в области менеджмента. Он был разработан в рамках ориентированного на человека дизайна фирмы IDEO. Теневой повтор предполагает сопровождение кого-либо в течение дня (с его разрешения). Мы наблюдаем за человеком, делаем заметки, аудио- и видеозаписи, а также собираем данные о том, где и как исследуемый проводит время. Незаметно и без вмешательства наблюдая за людьми, живущими своей жизнью, можно лучше понять их поведение, мнение и мотивы.

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

Исследовательские заметки

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

* * *

Исследования должны стать важной частью этапа формирования идей, и вы можете открыть для себя еще много техник и методов в инструментарии IDEO Method Cards, где представлена пятьдесят одна замечательная и полезная техника, как «сделать человека центром вашей работы»[10]. Прекрасная игра на воображение The Thing from the Future от компании Situation Lab, разработанная моим покойным коллегой из USC Games Джеффом Уотсоном и преподавателем Университета Карнеги – Меллона Стюартом Кэнди, – еще один отличный способ провести игровые и вдумчивые беседы о будущем, который подойдет дизайнерам и не только[11]. Карточная игра Мэри Флэнаган и Хелен Ниссенбаум Grow-a-Game поможет дизайнерам более тщательно подойти к тому, как они интегрируют человеческие ценности в свои игровые системы[12].

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

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

Глава 4

Прототипирование игры: обзор

Мозговой штурм и исследования – это хорошо, но жизненная сила идеи на самом деле таится не в придумывании, а в создании.

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

Это нужно четко понимать: вам следует начать с небольшого обсуждения идеи, возможно, с одного мозгового штурма, затем провести небольшое исследование, около двадцати минут, и после этого вы должны немедленно приступить к созданию своего первого прототипа. Если вы все делаете правильно, этот прототип будет первым из многих. Как отмечает сотрудник Autodesk и новатор в технологиях Том Вуйец в своем выступлении на TED «Построишь башню – создашь команду» (Build a Tower, Build a Team): «Дизайн – это контактный вид спорта»[13]. Пока мы не начнем создавать, мы не сможем обнаружить то, что может навредить или же помочь нашему проекту.

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

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

Ваши прототипы – это не демоверсии игры.

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

Но пока:

Каждый созданный прототип исследует одну или несколько идей вашей игры.

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

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

Игровая механика, глаголы и игровые активности

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

Иногда глаголы более «атомарные»: например, нажать кнопку для прыжка – это базовый глагол в определенных типах игр. Другие – более «молекулярные» и состоят из групп этих атомов. Например, исследование состоит из атомарных действий ходить, прыгать, лазить, ползать и перемещать игровую камеру. Точно так же как атом состоит из субатомных частиц, атомарное действие может разбиваться на более мелкие части: лазить может включать в себя такие субатомные составляющие, как «двигаться влево», «двигаться вправо», «спрыгнуть», «дайно джамп»[14] и так далее.

Термин «игровая активность» мы используем для описания того, как игрок пользуется определенными глаголами. Игровая активность может быть поиском выхода в игре от первого лица с использованием клавиш WASD, мыши и клавиши Shift. Это может быть попытка собрать три одинаковых предмета в линию в игре типа «Три в ряд» с помощью нажатий на сенсорный экран. Также это может быть прокликивание ссылок в игре на движке Twine в попытке повторно пройти историю и открыть другую концовку. Игровая активность – результат сочетания механики вашей игры, глаголов и повествования, а также восприятия, мыслей, действий и намерений игрока.

Как и многие гейм-дизайнеры, я склонен использовать эти термины взаимозаменяемо, но я считаю, что представление механики и глаголов как действий игрока на этапе создания прототипа напоминает нам о необходимости удерживать опыт и действия игрока в фокусе своего внимания. Игровые активности часто упорядочены в циклы, и мы подробнее рассмотрим кор луп (от англ. core loop – «основной игровой цикл») в главе 10. Углубившись в анализ игры, мы поговорим о паттернах в игровых активностях и заметим, что разные группы игроков используют одни и те же механики и глаголы для совершенно разных стилей игры. Наиболее известное описание паттернов игровых активностей представлено Ричардом Бартлом и включает в себя киллеров, ачиверов (от англ. achieve – «достигать»), социальщиков и исследователей[15].

Для каждого прототипа, который вы создаете, спросите себя:

• какую игровую активность я прототипирую?

• какие игровые глаголы я исследую?

• какой опыт дает эта активность?

• какой тон или настроение у игровой активности?

• что интересного в геймплее и сюжете я могу сразу реализовать с помощью этой активности?

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

• на какой вопрос я пытаюсь ответить этим прототипом?

Последний пункт очень важен. Дизайнер Хаим Гингольд, известный работой над играми Spore и Earth Primer, дает множество отличных советов по созданию прототипов в своем эссе Catastrophic Prototyping and Other Stories, которое он написал для уже упомянутой книги Трейси Фуллертон и которое вы также можете найти в интернете. Хаим советует разрабатывать каждый прототип, отвечая на поставленный вопрос. «Например, вы думаете о том, как взаимодействовать с косяком рыб компьютерной мышью. Ваш вопрос таков: как мне управлять этими рыбами с помощью мыши?» Хаим указывает на другие преимущества создания прототипов – например, как способ убедить ваших товарищей по команде, что идея сработает. Он также дает советы, как работать быстро и экономно, не пытаться сделать слишком много сразу и правильно использовать свое время. Эссе Хаима превосходно – обязательно с ним ознакомьтесь[16].

Три вида прототипирования

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

Игровое прототипирование

Прототип – это способ воплотить идею в жизнь, и именно это делает малыш, взяв в руки игрушечное животное и издавая рычащий звук. Процесс формирования идеи нужен, чтобы немного подуть в паруса вашего дизайна, и, по моему опыту, нет лучшего способа начать, чем взять игрушку или другой предмет и сказать: «Давайте представим…»

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

Когда малыши становятся старше, они начинают играть понарошку, отыгрывая роли и сценарии. Это тоже может быть частью игрового прототипирования. В Naughty Dog и Crystal Dynamics мы с коллегами часто проясняли наши дизайнерские идеи и решали проблемы подобным образом.

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

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

Физическое прототипирование

Одно из необыкновеннейших нововведений игроцентрического гейм-дизайна, которое Трейси Фуллертон описывает в книге Game Design Workshop, – использование физических прототипов. Физическое прототипирование включает в себя создание настольных игр, карточных игр и других видов нецифровой игровой активности, таких как спортивные состязания или уличные игры. Этот способ, несомненно, может привести к созданию отличных настольных, карточных и спортивных игр, но он также поможет и при создании цифровой игры. Например, превосходная стратегия в реальном времени с элементами платформера Killer Queen от команды разработчиков BumbleBear Games изначально создавалась как физическая командная игра[17].

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

Как создать физический прототип

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

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

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

Рис. 4.1. Физические прототипы игры Consume Me от Дженни Цзяо Ся, выставка видеоигр в музее Виктории и Альберта, Лондон

Изобретение – самое обычное дело в физическом прототипировании. Возможно, ваш опыт в дизайне настольных игр поможет вам легко найти параллели в игровых активностях, глаголах и механиках физических и цифровых игр. Если, как и у меня, у вас меньше опыта в разработке настольных игр, вы можете задержаться на этой технике прототипирования ненадолго. Ваши физические прототипы могут даже больше походить на игровые. Трейси Фуллертон напомнила мне: «Важно помнить, что прототипирование – это всегда поиск ответа на вопрос, поэтому, если у вас нет вопроса, на который ответит физический прототип, используйте другой формат!»

Рис. 4.2. Физический прототип цифровой игры Daunting Dollhouse Чао Чена, Кристофа Розенталя, Джорджа Ли и Джулиана Сейпека, созданный на занятиях по интерактивным медиа USC Games. Фото: Джордж Ли

Тестирование физического прототипа

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

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

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

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

Итерирование физического прототипа

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

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

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

Гейм-дизайнерам часто советуют «следовать за весельем» в плейтестах, и это отличный совет, если вы искали именно веселье. Я люблю веселиться в играх, мне нравится думать о том, что делает игру веселой, и я думаю, что почти каждый человек считает веселье главной составляющей своего счастья и благополучия. Но не все веселятся одинаково, и игры не обязательно должны быть веселыми в традиционном смысле; возможно, они вообще не должны быть веселыми. В некоторых моих любимых играх, таких как Problem Attic Лиз Райерсон, намеренно отказываются от традиционного приятного развлечения, которое мы получаем в других играх[18].

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

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

Физическое прототипирование на протяжении разработки

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

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

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

Цифровое прототипирование

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

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

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

Чтобы создать цифровой прототип, вам нужны некоторые навыки в разработке цифровых игр. Может, немного, но хоть какие-то. Обучение подобной разработке выходит за рамки данной книги, но я могу дать вам несколько советов о том, с чего начать изучение цифровой игровой разработки в главе 5.

Каждый разработчик игр тоже гейм-дизайнер

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

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

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

Я считаю, что каждый разработчик игр, будь то художник, саунд-дизайнер, аниматор или программист, – также и гейм-дизайнер, потому что сиюминутные решения, которые они принимают во время выполнения работы, оказывают фундаментальное влияние на дизайн игры. «Дьявол кроется в деталях» или «Бог в деталях» – зависит от того, сколько неприятностей эти детали вам доставляют. Дизайнеры Рэй и Чарльз Имз однажды сказали: «Детали – это не просто детали. Они создают продукт»[20].

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

* * *

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

Глава 5

Создание цифрового прототипа

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

Выбор игрового движка

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

Игровые движки, наиболее широко используемые в настоящее время как в игровой индустрии, так и в образовательных программах, – это Unity и Unreal Engine. Оба предоставляют бесплатные версии, которые вы можете скачать, оба снабжены полезными и постоянно обновляющимися обучающими материалами, и оба предлагают множество функций, дающих огромный потенциал для создания игр. Другие игровые движки можно легко отыскать в интернете. Можно начать со статьи в «Википедии» «Список игровых движков»[21]. Если вы не сильны в программировании, подумайте об использовании таких движков, как Twine, Bitsy и Emotica. Помните, что каждый игровой движок достоин уважения и хороший гейм-дизайн всегда связан с ограничениями и творческим подходом. Некоторые из моих любимых игр за последние десять лет были созданы на простых в использовании игровых движках.

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

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

Если вам трудно учиться самостоятельно, запишитесь на занятия или сходите на семинар, найдите группу разработчиков инди-игр в вашем регионе или друга, который вас научит. Создайте среду, где вы сможете регулярно встречаться с другими людьми, у которых больше навыков, чем у вас, готовыми делиться с вами опытом, – вы и не заметите, как скоро начнут расти ваши знания и навыки. Если вам нужна дополнительная помощь и вдохновение, я рекомендую отличную книгу Анны Антропи Rise of the Videogame Zinesters.

Выбор операционной системы и аппаратной платформы

Вам предстоит сделать еще один выбор: на какой аппаратной платформе и операционной системе будет работать ваш прототип? Вы можете сделать игру для ПК или Mac, используя Windows, macOS или Linux. Вы можете сделать игру для телефона или планшета с помощью Android или iOS или для игровой консоли, использующей собственную операционную систему. На некоторых игровых движках можно легко экспортировать вашу игру в несколько операционных систем и аппаратных платформ.

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

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

Создайте прототип как игрушку, а не как игру

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

Я понимаю этот порыв детально планировать игру с самого начала, но это равносильно тому, что ставить телегу впереди лошади. По своему опыту я знаю, что правильный путь – делать по одному шагу за раз, и в цифровом прототипировании это часто означает создание игрушки (от англ. toy).

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

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

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

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

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

Старайтесь, чтобы ваши прототипы были сосредоточены на изучении игровых активностей:

1) могут ли они вызвать эмоции и казаться интересными;

2) просты ли они для понимания и использования игроками;

3) пригодятся ли они в той игре, которую вы планируете.

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

Важность звукового сопровождения в цифровом прототипе

Некоторые склонны пренебрегать звуковым дизайном при создании прототипа. Это еще одна большая ошибка. Как у разработчиков игр, у нас в арсенале только три сенсорные модальности для общения с нашими игроками: зрение, слух и осязание[22]. Хотя не каждый может реализовать сенсорный «тактильный» дизайн вибрирующего игрового контроллера или мобильного устройства, большинство из нас могут добавить звук в цифровые прототипы, и сделать это стоит по ряду причин.

В книге Game Feel: A Game Designer’s Guide to Virtual Sensation Стив Суинк обсуждает важнейшую роль звука в формировании нашего восприятия виртуального пространства, так как звук обладает физическими свойствами. Суинк пишет: «Звуковой эффект может полностью изменить восприятие объекта в игре» – и приводит пример анимации двух кругов, движущихся навстречу, а затем удаляющихся друг от друга[23]. Без какого-либо звука круги выглядят так, будто просто проходят мимо друг друга. С добавлением в нужный момент звука «боньк!» они внезапно становятся похожи на отскакивающие друг от друга резиновые мячи.

Звуковой дизайн может подсказать вам, обут персонаж в кроссовки или металлические ботинки, отскочила ваша стрела от камня или льда, и он, безусловно, повлияет на то, какими вам будут казаться звуки интерфейса: приятными или раздражающими. Стив Суинк описывает, что нюансы звукового оформления могут передавать информацию не только об объектах или событии, но и о пространстве, в котором происходит это событие: «Если по земле бьет массивный молот и звук отдается эхом и отражается, игрок понимает, что столкновение произошло внутри гигантского склада или другого огромного пустого пространства. Если звук удара приглушен, игрок подумает, что это был удар о землю где-то снаружи»[24].

И это еще не все, на что способен звук. В своей превосходной статье Designing a Movie for Sound обладатель премии «Оскар» звукорежиссер Рэнди Том перечисляет тринадцать различных «талантов», которые звук привносит в кино и, как следствие, в игры и их цифровые прототипы:

«Музыка, диалоги и звуковые эффекты могут выполнять любую из следующих задач и многое другое:

• внушить настроение, вызвать чувство;

• установить темп;

• указать географическое положение;

• указать исторический период;

• прояснить сюжет;

• объяснить характер персонажа;

• соединить несвязанные идеи, персонажей, места, образы или моменты;

• повысить степень реализма или понизить ее;

• акцентировать или устранить двусмысленность ситуации;

• привлечь внимание к детали или отвлечь от нее;

• указать на изменения во времени;

• сгладить резкие переходы между кадрами или сценами;

• подчеркнуть переход для драматического эффекта;

• описать акустическое пространство;

• напугать или успокоить;

• преувеличить действие или опосредовать его»[25].

В книге Game Feel Стив Суинк отмечает еще одну любопытную деталь: звук не связан с реалистичностью так, как это обычно бывает с изображениями. Студенты, изучающие звуковое оформление фильмов, довольно рано знакомятся с тем фактом, что многие из известных нам знаковых звуковых эффектов не тесно связаны с реальностью, а лишь условно заимствованы. Вспомните звук хруста снега под ногами в каком-нибудь фильме: на самом деле кто-то просто сминает в руках мешочек с кукурузным крахмалом – такой искусственный шумовой эффект был давным-давно придуман изобретательным и малоизвестным звукорежиссером Джеком Фоли. Стив Суинк говорит:

Скретч-запись речей Короля Всего Космоса в Katamari Damacy или оркестровый удар при завершении специального движения в Tony Hawk 3 доказывают, что сопоставление неожиданного звукового эффекта с конкретным событием может привести к восхитительным результатам, пусть это не имеет ничего общего с реальностью изображаемого. Как и в мультфильме, нет необходимости ограничивать себя размышлениями о том, как применить звуковой эффект в имитации реальности. Вы можете передать физическое впечатление от происходящего с помощью звука, совсем не соответствующего издающему его объекту[26].

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

Еще одна немаловажная причина добавить звуковое сопровождение в цифровой прототип связана с эмоциями. Однажды в самом начале моей работы в Crystal Dynamics я услышал, как кто-то сказал, что «глаз связан с разумом, но ухо связано с сердцем». Я забыл, кто именно это сказал, но я навсегда запомнил эти слова. В фильмах и играх изображение и звук передают логическую и эмоциональную информацию, но изображение не так эмоционально заряжено само по себе, в то время как звуковой дизайн играет огромную роль в формировании эмоционального опыта. Для примера взгляните на минутный фильм Кристофера Рула «Страшная Мэри» (Scary Mary) – переделанный трейлер диснеевского фильма 1964 года «Мэри Поппинс» с новым звуковым оформлением, в котором детская история превращается в ужасающий триллер[27]. «Страшная Мэри» прекрасно иллюстрирует то, какую важную роль играет звуковой дизайн и как музыка передает информацию и вызывает эмоции.

Марк Черни недавно сказал мне, что он уделяет большое внимание технологиям 3D-звука в играх, а также улучшению позиционирования и эффекта присутствия, которые эти технологии приносят. 3D-аудиотехнологии имитируют то, как звуковые волны взаимодействуют с окружающей средой; позиционирование звука связано с возможностью восприятия положения объектов, производящих шум, в пространстве, а эффект присутствия – это психологическое ощущение присутствия в определенной среде. Как говорит Марк, «позиционирование действительно влияет на дизайн (вы точно знаете, где находится враг, которого вы не видите), а эффект присутствия влияет на ваши эмоциональные отношения с игрой».

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

Плейтесты и итерирование цифрового прототипа

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

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

Мы подробно рассмотрим, как получить максимальную отдачу от плейтестов игры в главе 12. Но сейчас, когда вы проводите плейтесты, помните следующее.

• Не объясняйте слишком много. Не объясняйте вообще ничего, если есть такая возможность.

• Вообще не помогайте своему плейтестеру и никак не вмешивайтесь в то, что он делает.

• Наблюдайте за игрой тестеров. Обращайте внимание на то, что они делают, и слушайте, что они говорят.

• Делайте заметки о том, что вы видите и слышите во время игры.

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

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

• Что следует улучшить, потому что это показало себя успешным?

• Что нужно исправить, потому что в конечном счете это может сработать?

• Что следует убрать, потому что это не работает и, вероятно, так и не будет работать?

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

В профессиональной среде «Friends and Family»-тестирования проводят каждую неделю или так часто, как только возможно. Если вы только учитесь гейм-дизайну, еженедельно проводите короткие сеансы тестирования, чтобы получить как можно больше отзывов о каждой игре или прототипе.

Сколько нужно сделать цифровых прототипов

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

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

Следовать ли за тем, куда ведет прототип

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

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

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

Результаты идеации: создание прототипа

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

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

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

Документы по сборке

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

Описание управления пригодится всем, кто попытается поиграть в прототип, особенно если в нем этому управлению не обучают.

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

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

С самого начала проекта ведите титры вашей игры. В титры надо занести всех, кто выполнил даже небольшой объем работы над проектом, за исключением особых и тщательно оговоренных случаев. Несправедливое исключение вклада некоторых людей в игры стало большой проблемой в игровой индустрии, и каждый ответственный гейм-дизайнер должен работать над ее решением. Международная ассоциация разработчиков игр подготовила стандарт Crediting Standards Guide, по которому вы можете ознакомиться с основными правилами оформления титров и включения в них участников разработки[29].

Синдром завышенных ожиданий

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

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

В попытке сделать людям «прививку» от этого синдрома я привожу цитату Айры Гласса из радиопередачи This American Life о «пропасти»:

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

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

Установите себе дедлайн, чтобы каждую неделю заканчивать одну историю. Только выполнив определенный объем работы, вы преодолеете эту пропасть, и ваша работа будет соответствовать вашим амбициям. И мне потребовалось больше времени, чтобы это понять, чем кому-либо, кого я встречал. Это займет некоторое время. И это абсолютно нормально. Вам только надо суметь преодолеть этот этап[30].

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

Эмоциональная составляющая плейтестов прототипов

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

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

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

* * *

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

Как недавно сказал мне Марк Черни: «Для God of War важно сделать каждый момент эпическим. Для Control главное – бюрократическая сюрреалистичность повествования, окружения и игровых механик»[31]. Прототипирование поможет вам определить креативный дирекшен, который найдет выражение в том, что я считаю самым важным артефактом этапа формирования идей, – целях проекта.

Глава 6

Коммуникация как навык гейм-дизайна

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

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

Коммуникация, сотрудничество, лидерство и конфликты

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

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

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

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

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

Сотрудничество заложено в основу обучения в USC Games как очень важный аспект создания игр. Монтажер, режиссер и звукорежиссер Уолтер Марч – выпускник Школы кинематографических искусств USC – подчеркнул важность сотрудничества, сказав: «Половина работы – это сама работа, а другая половина – поиск способов поладить с людьми и настроиться на деликатное общение»[32].

Интерпретировать «деликатное общение» Марча можно двояко: во‑первых, я думаю, он имеет в виду тонкости взаимоотношений между людьми, выполняющими совместную работу, а во‑вторых, он говорит о сложном балансе элементов в этой самой творческой работе. Сообщество сотрудничающих для создания творческой работы людей и сама работа глубоко взаимосвязаны. Если товарищи по команде не ладят – всегда недопонимают или борются друг с другом, – то творческая работа, которую они делают, вероятно, тоже не заладится.

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

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

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

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

Чтобы получить представление о разносторонних навыках гейм-директора, я рекомендую прочитать отличную книгу Брайана Альгайера Directing Video Games: 101 Tips for Creative Leaders. Те, кто стремится улучшить свои лидерские навыки в разработке игр, отыщут много полезного в разделах «Организационные улучшения» и «Командная культура» книги Клинтона Кита и Гранта Шонквилера Creative Agility Tools: 100+ Tools for Creative Innovation and Teamwork. Книга «Корпорация гениев. Как управлять командой творческих людей»[33] (Creativity, Inc.) Эда Кэтмелла и Эми Уоллес предлагает отличные советы по творческому лидерству наряду с практическими примерами и реальным пониманием того, как работают креативные команды.

Конфликт между членами команды разработчиков – важный аспект сотрудничества. Конечно, легко рассматривать конфликт как проблему, но на самом деле конфликт необходим и является неотъемлемой частью каждого коллективного творческого процесса. Нам просто нужно научиться справляться с ним, уважительно и продуктивно преодолевая разногласия. Мы также должны научиться не избегать и не игнорировать конфликты, потому что замалчивание проблем может привести к еще большим разборкам в будущем. Я рекомендую книгу Мэри Скэннелл The Big Book of Conflict Resolution Games в качестве отличного исследования на эту тему.

* * *

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

К счастью, существует множество хороших техник, помогающих нам говорить о разговоре, и многие из них похожи на игры. Мы рассмотрим некоторые из них в ходе этой книги.

Базовые коммуникативные навыки

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

Будьте ясны

Ясность – это суть хорошего общения. Если сообщение неясно, оно останется непонятым.

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

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

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

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

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

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

Будьте кратки

«Краткость – сестра таланта», – гласит старая пословица. Неважно, означает ли «талант» интеллект или чувство юмора, факты таковы, что эффективнее всего быстрые сообщения. Шутка звучит острее, а смысл – убедительнее. Чтобы общаться с кем-то, мы должны удерживать его внимание, а внимание у каждого ограничено. Так что переходите к делу и говорите то, что хотите сказать, как можно быстрее, сохраняя при этом ясность.

Здесь возникают сложности – иногда краткость и ясность конкурируют друг с другом. Вам придется подбирать слова так, чтобы быть достаточно кратким и в то же время достаточно понятным. И сведение сложной концепции к простой инкапсуляции требует усилий. Математик семнадцатого века Блез Паскаль сказал: «Я бы написал кратко, но у меня не было времени».

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

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

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

Активно слушайте

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

У активного слушания есть еще одно значение: это когда вы показываете кому-то, что следите за тем, что они говорят, глядя на них и время от времени кивая и говоря «угу» или «мм-хм». Многие из нас, играя роль слушателя, делают это естественно – своего рода «протокол рукопожатия», который компьютеры используют для установления и поддержания связи через интернет. Компьютер сообщает нам: «Да, мы все еще на связи – продолжайте». Таким же способом можно сигнализировать, когда собеседник затягивает со выступлением. «Ага», «да», «я понял» – такие слова говорят о том, что пришло время переходить к следующей теме.

Такое открытое проявление внимания, как это, не для всех естественно. Если вы не привыкли так проявлять ваше внимание в беседе, не волнуйтесь. Есть еще один способ подтвердить кому-то, что его поняли. Меня научили этой технике на моем пути к карьере гейм-дизайнера, и я нахожу ее чрезвычайно эффективной для устранения недоразумений и экономии времени. Эта техника называется отзеркаливанием, или отражением, и она очень проста. В конце сложного утверждения или вопроса, который вы выслушали, скажите: «Позвольте мне повторить то, что вы рассказали, чтобы убедиться, правильно ли я вас понял», а затем резюмируйте то, что вы услышали и запомнили. Скорее всего, ваш собеседник скажет: «Почти все так, но…», а затем прояснит некоторые мелкие детали, которые вы не совсем поняли или упустили из виду.

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

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

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

* * *

Ясность, краткость, активное слушание. Когда что-то идет не так в вашем общении – когда что-то становится запутанным или эмоциональным настолько, что мешает продуктивной работе, – возвращайтесь к этим трем друзьям, и они направят вас на верный путь.

Техника сэндвича

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

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

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

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

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

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

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

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

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

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

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

Третий принцип – критиковать работу, а не человека – я перенял у президента студии Naughty Dog Эвана Уэллса. Эван установил простое правило всегда критиковать то, что мы видим на экране, слышим через динамики и чувствуем через контроллер, стараясь никогда не критиковать человека, который проделал эту работу.

Если вы будете следовать этому правилу критиковать работу, а не человека, вы снизите вероятность расстроить или рассердить его и заставите всех сосредоточиться на улучшении качества игры. Удивительно, как легко перейти от слов «Эта игровая механика не очень хороша» к словам «Эта игровая механика, которую вы сделали, не очень хороша». Оставаясь сосредоточенными на работе и на том, что в ней можно улучшить, мы всегда можем разработать действенный план повышения качества, не настраивая против себя человека, выполняющего эту работу.

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

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

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

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

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

Чем больше ваши отношения в команде развиваются и укрепляются, тем меньше будет надобность в «сэндвичах». Хлеб со временем будет становиться все тоньше и тоньше, пока полностью не исчезнет, и вы сможете высказать кому-то конструктивную критику напрямую, и ее не воспримут в штыки. Стройте вашу командную культуру вокруг сотрудничества и взаимоуважения, что, в свою очередь, позволит вашей команде создавать действительно отличные игры.

Уважение, доверие и согласие

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

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

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

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

Глава 7

Цели проекта

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

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

Целевой опыт пользователя

Идея целевого опыта пользователя была впервые представлена в литературе по гейм-дизайну в 2008 году во втором издании книги Трейси Фуллертон Game Design Workshop[34]. Трейси сказала мне: «Я добавила [концепцию опыта пользователя], потому что пыталась прояснить процесс, который мы использовали [в лаборатории игровых инноваций USC], сильно отличающийся от того, как каким было принято считать процесс разработки игр в целом, – основанный на фичах и столпах».

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

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

Трейси Фуллертон, фреймворк МДЭ и Naughty Dog

Как я уже упоминал, я сосредоточился на опыте пользователя после работы Трейси Фуллертон. В Game Design Workshop в одном из эссе о работе над игрой Cloud с такими гейм-дизайнерами, как Дженова Чэнь, Келли Сантьяго и командой студентов лаборатории игровых инноваций USC, Трейси пишет:

Когда мы начали работать над Cloud, у нас была только одна инновационная цель: каким-то образом вызвать чувство расслабления и радости, когда вы ложитесь на траву в ясный солнечный день и смотрите на облака, плывущие по небу… Так или иначе, мы (все) мечтаем взлететь к облакам, сделать из них забавных существ, милые рожицы, леденцы на палочке или то, что придет вам на ум. Это казалось чем-то совершенно новым в играх. Это казалось рискованным и интересным. Поэтому мы решили попробовать[35].

Трейси называет это целевой инновацией: она еще не пришла к определению «целевой опыт пользователя», когда писала это эссе. Сейчас мы понимаем, что команда разработчиков Cloud ставила перед собой цель создать конкретный опыт пользователя. Поначалу они не знали, как собираются создать этот расслабляющий, радостный опыт. Они даже не знали, смогут ли. Но, сформулировав намерение и начав двигаться к цели, они сделали первый смелый шаг к новым рубежам в гейм-дизайне.

Рис. 7.1. Что такое Uncharted? (Naughty Dog, около 2006 года). Перевод этого текста доступен в приложении Б. Изображение предоставлено: UNCHARTED: Drake's Fortune™ © 2007 Sony Interactive Entertainment LLC. UNCHARTED: Drake's Fortune является торговой маркой Sony Interactive Entertainment LLC. Создано и разработано компанией Naughty Dog LLC

Этот шаг заложил философию дизайна, которая навсегда изменила игровую индустрию. Ядро команды Cloud затем основало компанию thatgamecompany и создало отмеченные наградами игры Flow, Flower и лучшую игру 2012 года Journey. Трейси использовала аналогичные методы постановки целей на протяжении всей своей практики, начиная с игры The Night Journey, которую она разработала вместе с известным художником Биллом Виолой, и заканчивая повсеместно признанной Walden: a game, дающей новый взгляд на работу и мир Генри Дэвида Торо. Трейси продолжает расширять границы возможностей игр, внедряя инновации как в процесс, так и в искусство.

Знаменитый фреймворк МДЭ (MDA) – механика, динамика и эстетика – также уделяет особое внимание игровому опыту. Фреймворк был предложен Робин Ханике, Марком Лебланом и Робертом Зубеком в их новаторской статье 2004 года MDA: A Formal Approach to Game Design and Game Research («МДЭ: формальный подход к гейм-дизайну и изучению игр»), его цель – помочь нам как разрабатывать, так и анализировать игры.

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

Формулирование целевого опыта пользователя (рис. 7.1) – это то, как наша команда в Naughty Dog разрабатывала мир Uncharted. Работая со старшим концепт-художником Шэдди Сафади и командой, гейм-директор Uncharted: Drake’s Fortune Эми Хенниг определила тот опыт, который мы хотели включить в игру, в кратком наборе правил, которые мы вывесили в общей зоне в студии. Эти правила помогли нам не сбиваться с курса на протяжении всей разработки серии. Я рассматриваю их как целевой опыт пользователя, определяющий пространство возможностей, которое помогало разработке игр серии Uncharted.

Виды опыта

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

Иметь опыт – значит ощущать свое «я», когда с этим «я» что-то происходит. Опыт может быть физическим, умственным, эмоциональным, духовным, социальным, субъективным и виртуальным. Интеллект и сознание порождают разные виды ментального опыта, такие как мышление, восприятие, память, эмоции, воля и воображение[36].

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

Мышление, память, воображение и воля

Размышление о чем-то, знание чего-то и воспоминания связаны с опытом, каково это – совершать то или иное действие. То же касается и воображения, которое дает нам способность строить планы, и воли, в смысле «силы воли» – способности принимать решения и действовать. Игры в значительной степени основываются на этих видах опыта. Я знаю, что если коснусь этих шипов, то ежик потеряет все свои кольца, и думаю, что в этот раз я попытаюсь отскочить от трех грибных человечков подряд[37].

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

Восприятие

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

Термоцепция и ноцицепция – восприятие температуры и боли соответственно – нечасто используются гейм-дизайнерами, хотя опытные дизайнеры тематических парков и виртуальной реальности часто применяют горячий и холодный воздух для усиления впечатления. Знаменитый интерактивный арт-объект Painstation, созданный Тилманом Райффом и Фолькером Мораве в 2001 году, подкрепляет проигрыш болью – храбрецы могут поиграть в эту Pong-подобную игру в Музее компьютерных игр Берлина (Computerspielemuseum).

Эмоции

Эмоции – это то, что вовлекает нас в игру и заставляет играть. В течение многих лет гейм-дизайнеры часто не задумывались о других эмоциях, что кроются за двумя базовыми, доминирующими первые пять тысяч лет в истории игр чувствами: радостью победы и разочарованием от поражения. Однако мы не должны недооценивать силу этих эмоций. Как указывает Джеспер Джуул в книге The Art of Failure: An Essay on the Pain of Playing Video Game, неудачи, которые мы испытываем в играх, не лишены своего рода удовольствия. Наряду с радостью и разочарованием часто присутствуют и другие эмоции: восторг от игры, любопытство, побуждающее к исследованию, и удовлетворение от прохождения.

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

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

Чтобы помочь людям повысить эмоциональную грамотность, я напоминаю им о Радости, Печали, Страхе, Гневе и Брезгливости, пяти персонажах мультфильма Pixar 2015 года «Головоломка». Эти персонажи были основаны на работе доктора Пола Экмана, психолога Калифорнийского университета в Сан-Франциско и первопроходца в изучении выражения эмоций на лице. Исследование Экмана выявило семь основных эмоций, которые люди из разных культур по всему миру проявляют на своих лицах: пять, в честь которых названы персонажи «Головоломки», а также удивление и презрение.

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

Рис. 7.2. «Колесо эмоций» доктора Роберта Плутчика. Изображение предоставлено: Machine Elf 1735, «Викисклад», открытый доступ

Для лучшего понимания эмоций обратитесь к работе доктора Роберта Плутчика, психолога Медицинского колледжа Альберта Эйнштейна, который предложил психоэволюционную классификацию эмоциональных реакций. Наряду с большинством базовых эмоций Экмана Плутчик добавил ожидание и доверие и показал разные уровни эмоциональной интенсивности в каждой группе. Его работы часто иллюстрируются «колесом эмоций», показанным на рис. 7.2. Хорошее упражнение по гейм-дизайну – случайным образом выбрать эмоцию из колеса Плутчика и попытаться создать небольшую игру, которая вызывает эту эмоцию.

Социальный и духовный опыт

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

Социальный опыт – ключевой фактор в разработке любой многопользовательской игры, от командного киберспорта до массовых многопользовательских игр. Тема духовного и религиозного опыта все больше интересует гейм-дизайнеров. Один из первых теоретиков игр Йохан Хейзинга рассматривал игровую площадку как священное место сродни месту религиозного поклонения, а историк религиозной литературы Джеймс Карс обсуждает духовный аспект игры в книге «Конечные и бесконечные игры»[38]. Трейси Фуллертон и Билл Виола исследовали этот рубеж в своей игре The Night Journey. Сегодня появляется все больше и больше гейм-дизайнеров, интересующихся медитацией, осознанностью, ритуалами и экстатическими религиозными состояниями.

Записывайте, какой опыт вы хотите видеть в вашей игре

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

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

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

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

Выбранный вами опыт должен учитываться в ваших прототипах

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

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

Цели дизайна

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

Если к концу этапа идеации вы на 100 % уверены, что хотите сделать со своей игрой нечто конкретное, запишите вашу концепцию в цели дизайна. Может оказаться, что ваши дизайнерские цели и опыт пользователя совпадают или наоборот – что они совершенно разные.

Вот некоторые общие категории целей дизайна.

Оборудование, на котором будет работать ваша игра. На какой платформе будет работать ваша игра? ПК или Mac? Телефоны? Игровая консоль? Фитнес-трекер, часы или наушники? Консоль автомобиля с автопилотом или холодильник? Цифровые технологии захватывают все больше окружающих нас объектов, и ваш выбор аппаратной платформы будет только расширяться. Вам не нужно привязывать выбранную платформу к целям проекта, но это поможет вам уверенно двигаться вперед и сэкономит позже время. Эта цель также связана с аудиторией и рынком: если вы хотите охватить определенную группу игроков, вам нужно учитывать, на каких платформах они играют в игры.

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

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

Специальное оборудование или программное обеспечение, которое вы хотите использовать. Вы можете решить использовать шлем виртуальной реальности, платформу дополненной реальности для мобильных устройств или «alt-контроллер» (специально разработанное устройство), подобный тем, которые каждый год можно увидеть на конференции разработчиков игр alt.ctrl.GDC.

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

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

Тема вашей игры. Это центральная тема, рассматриваемая в повествовании. У разных авторов разные мнения о том, когда следует задавать тему рассказа, который они пишут. Некоторые делают это в самом начале; другие находят свою тему по мере работы. На самом раннем этапе разработки Uncharted 2: Among Thieves мы решили, что наша игра будет посвящена доверию и предательству, и это помогло нам сформировать историю. Если вы можете определить тему игры в конце первого этапа разработки, убедитесь, что она соотносится с целями дизайна.

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

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

Цели воздействия вашей игры. Вы можете решить создать игру, которая окажет определенное влияние на мир – такие игры часто называют серьезными, функциональными, прикладными или трансформационными играми. Возможно, вы хотите, чтобы ваша игра была образовательной, положительно влияла на здоровье ваших игроков или поднимала политические темы. Книга Сабрины Кулибы The Transformational Framework: A Process Tool for the Development of Transformational Games – это бесценный ресурс для тех, кто стремится разрабатывать и анализировать игры, цель которых – повлиять на своих игроков.

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

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

Целевой опыт и цели дизайна образуют цели проекта

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

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

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

Репертуар и рост

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

У многих творческих групп есть репертуар: совокупность работ в определенном стиле, которые они мастерски создают и хорошо исполняют. Например, театр Chicago Shakespeare Company исполняет пьесы Уильяма Шекспира, но в современных декорациях и костюмах.

Гейм-дизайнер Гэри Пенн из продуктивной шотландской студии Denki сказал мне в 2010 году, что у гейм-дизайнеров и игровых студий тоже есть репертуар, просто мы не называем его таким термином. Например, репертуар Naughty Dog состоит из игр в жанре приключенческого боевика, а Crash Bandicoot, серию Jak, Uncharted и The Last of Us объединяют схожие игровые механики и повествовательные темы, хотя в других отношениях эти серии игр сильно отличаются друг от друга.

Репертуар важен, потому что создавать произведения искусства сложно, а видеоигры – исключительно сложно. В своем выступлении на GDC Microtalks в 2010 году Гэри Пенн сказал: «Не думайте об этом, не говорите, не пишите. Делайте. Разыгрывайте по ролям. Визуализируйте. Создавайте прототипы… Разработка – это зыбучие пески. Не стремитесь сделать все идеально с первого раза… Случай благоприятствует подготовленным. Предполагайте проблемы. Репетируйте. Исследуйте. Ищите новые углы обзора. Делайте осознанный выбор. Составляйте репертуар, как музыканты и актеры. Ваш репертуар – это ваши натренированные мышцы, развитые и многократно используемые»[39]. Профессиональная студия разработки игр будет использовать свои сильные стороны, работая со своим репертуаром – тем, что они уже умеют делать, – и при этом изучать в каждом проекте что-то новое, развиваясь в процессе. Хотя у Crash Bandicoot и The Last of Us Part II общая ДНК, Naughty Dog многому научились при создании каждой серии, и каждая из них ознаменовала эволюционный скачок вперед.

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

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

Учитывайте возможную аудиторию вашей игры

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

В этом вам поможет очень простое упражнение – вам достаточно написать всего несколько слов в конце целей вашего проекта в формулировке «Возможная аудитория нашей игры…»:

• «Возможная аудитория нашей игры – это любой, кто играет в игры на телефоне, стоя в метро, и кому нравятся смешные видео в социальных сетях».

• «Возможная аудитория нашей игры – это геймеры, любящие 3D-экшены жанра Souls-like и 2D-метроидвании, и им понравится сочетание жанров».

• «Возможная аудитория нашей игры – это любители судоку и романов Джейн Остин».

• «Возможная аудитория нашей игры – это любители садоводства в возрасте восьмидесяти лет и старше».

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

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

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

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

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

Вы можете узнать больше о возможной аудитории для вашей игры, используя демографики, психографики и то, что называют оценкой размера рынка. При представлении аудитории полезно учитывать сопоставимые показатели – «Это понравится людям, которым нравится (определенная игра, фильм, телешоу, книга или комикс)». Исследуя аудиторию своей будущей работы, многие творческие люди опираются на данные своих прошлых произведений.

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

Маркетинговой работе, которую необходимо выполнять параллельно разработке, посвящено несколько книг. Рекомендую вам ознакомиться с книгой Джоэла Дрескина A Practical Guide to Indie Game Marketing и учебным пособием Питера Закариассона и Миколая Дымека Video Game Marketing: A Student Textbook.

Разработка для специализированной игровой платформы

Если одна из ваших целей – создание игры для консоли от компаний уровня Sony, Microsoft или Nintendo или на мобильные платформы в экосистеме Apple, то вы должны подать заявку, чтобы стать разработчиком для этой платформы в начале процесса работы над игрой. Для консольной игры обычно требуется специальный набор для разработки – версия консольного оборудования, которая может быть подключена к компьютеру в целях разработки и отладки игры. Таким образом, отношения между разработчиком и владельцем платформы начинаются с заявки и получения необходимого «комплекта разработчика» (девкита).

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

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

Советы, как сформировать цели проекта

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

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

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

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

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

Глава 8

Конец этапа идеации

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

Как долго должен длиться этап идеации

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

Это давало нам возможность провести некоторые исследования и разработки (R&D, research and development) без особого давления. У работников всех отделов было время свободно поиграть с идеями, от которых они были в восторге, и именно тогда был отличный момент, чтобы попробовать новые подходы и методы. Во время разработки одной игры могут родиться отличные идеи, которые пригодятся затем в следующей. Директоры следующей игры могут разработать некоторые основные идеи и быстро привлечь к этой работе других людей из команды.

Разработка Uncharted 2 и Uncharted 3 длилась два года, и, по моим оценкам, около 15 процентов от их общих сроков реализации мы провели на этапе идеации – примерно столько же времени на формирование идеи уходит и у моих учеников в USC. Сколько вы будете обдумывать ваш проект, зависит от вас. Если у вас полно времени и не ограничены сроки, то, возможно, было бы все-таки неплохо обдумывать идеи подольше, особенно если вы пытаетесь сделать что-то действительно инновационное.

Тем не менее я бы не рекомендовал затягивать этот процесс. Установите себе фиксированное количество времени для обдумывания. Не позволяйте ему продолжаться вечно. Ограничение по времени поможет вам оставаться сосредоточенным и придаст импульс началу проекта. Я подробнее расскажу о таймбоксинге в главе 11.

Несколько заключительных советов по созданию прототипов

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

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

Краткое изложение артефактов этапа идеации

На рис. 8.1 кратко изложены основные процессы и те артефакты, которые нужно получить на данном этапе. Это должно помочь вам оставаться на верном пути.

Рис. 8.1. Основные процессы и артефакты этапа идеации

Второй этап: препродакшен – разработка дизайна через действия

Глава 9

Взятие контроля над процессом

«Действительное получение контроля над процессами дизайна обычно ощущается как потеря этого контроля».

Мэтью Фредерик, 101 Things I Learned in Architecture School

В разработке первой оригинальной игры, над которой я работал, Tinhead для Sega Genesis (или Sega Mega Drive, в зависимости от того, где вы живете), был только один этап проекта: продакшен. Честно говоря, я даже не уверен, что мы его так называли. Мы просто начали создавать игру и работали над ней, пока не закончили. Мы предполагали, что на создание игры у нас уйдет шесть месяцев – а в итоге разработка заняла восемнадцать месяцев, и нам пришлось войти в режим кранча, чтобы закончить ее, работая допоздна и по выходным. К сожалению, это был лишь первый из многих кранчей в моей карьере. Первым проектом, в котором было более одного этапа разработки, стала игра Soul Reaver, которая также ознаменовала первую из моих многочисленных совместных работ с гейм-директором и креативным директором Uncharted Эми Хенниг.

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

Конвейер и водопад

Опираясь на идеи Рэнсома Эли Олдса (основателя Oldsmobile), Генри Форд произвел революцию в промышленном производстве автомобилей, изобретя движущуюся конвейерную линию (иногда называемую производственной линией). Инженеры разрабатывали план автомобиля, который строился на конвейерной линии поэтапно, начиная с шасси, а затем дополняясь двигателем, топливным баком, колесами, кузовом и всем остальным, что требовалось для его полного завершения.

Со временем идея производственной линии нашла применение и в мире компьютерных систем в так называемой каскадной модели, или модели «Водопад», подходе к разработке программного обеспечения, который появился в середине 1950‑х годов (хотя сам термин waterfall появился только в 1970‑х годах). Идея водопада, по сути, та же, что и у конвейерной линии: дизайнеры и инженеры тщательно продумывают, а затем пишут обширную спецификацию для программного обеспечения. Затем они разрабатывают план реализации спецификации, и оба документа передаются команде инженеров-программистов, поэтапно создающих программу, тщательно следуя полученным инструкциям.

Начиная с конца 1980‑х годов каскадные модели, которые широко использовались в разработке программного обеспечения для бизнеса, привлекли внимание менеджеров игровых проектов – они отчаянно стремились взять свои проекты под контроль с точки зрения времени, человеческих ресурсов и денег. Разработчики-любители 1980‑х годов – создатели инди-игр того времени, – молодые и увлеченные своим искусством, работали свободно, интуитивно, но часто неэффективно, всеми силами пытаясь довести свои проекты до завершения, даже если это им стоило беспрестанной работы и месяцев без единого выходного. Иногда проекты выполнялись вовремя и качественно – но очень часто они сильно нарушали сроки и выходили за рамки бюджета или вообще не достигали завершения. Творцы на таких проектах часто «сгорали», подрывая психическое и физическое здоровье.

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

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

Создание чего-то нового

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

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

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

Планирование на этапе препродакшена

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

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

В книге 101 Things I Learned in Architecture School, любимой гейм-дизайнерами, автор и архитектор Мэтью Фредерик пишет:

Процесс разработки часто структурирован и методичен, но его нельзя назвать механическим. В механических процессах результат предопределен, но в творческом процессе каждый раз создается что-то новое. В творчестве вы никогда не знаете, куда идете, даже если вы руководите процессом. Здесь нужно нечто отличное от обычного контроля – что-то, что даст вам определенную свободу действий[40].

Это отличный совет! Он очень соответствует духу всей этой книги и очень информативен в контексте планирования. Планировать необходимо, но как гейм-дизайнеру найти баланс между чрезмерным и недостаточным планированием? Я получил ответ на этот вопрос в Naughty Dog от моего друга и наставника Марка Черни.

Марк Черни и Метод

Марк Черни – гейм-дизайнер, разработчик и исполнительный директор, который начал свою карьеру в начале 1980‑х, присоединившись к компании Atari в возрасте семнадцати лет. Вдохновленный мини-гольфом, гоночными играми и Маурицем Корнелисом Эшером, Марк разработал и частично спрограммировал невероятно инновационную аркадную игру Marble Madness. После он работал в компании Sega в Японии, создавая игры для Sega Master System и Sega Genesis, а затем вернулся в Соединенные Штаты, где основал подразделение компании Sega Technical Institute и стал руководителем проекта Sonic the Hedgehog 2. Позже он стал вице-президентом, а затем и президентом издателя игр Universal Interactive Studios.

В Universal Interactive Марк познакомился с двумя молодыми разработчиками игр по имени Джейсон Рубин и Энди Гэвин. Джейсон и Энди основали игровую студию еще в старшей школе – они назвали ее JAM Games (что расшифровывалось как Jason and Andy Magic), но совсем скоро они переименовали себя в Naughty Dog.

Марк признал талант Джейсона и Энди – они уже создали приличное количество успешных игр, в том числе Keef the Thief и Rings of Power. Naughty Dog начала свое сотрудничество с Марком с создания их первого международного хита Crash Bandicoot, опираясь на новые подходы к разработке игр, которые привнес Марк и которые привели к созданию высококачественных игр в сотрудничестве с Naughty Dog, Insomniac Games и многими другими командами.

Что довольно необычно для исполнительного директора, Марк по-прежнему принимал участие в разработке, помогая создавать уровни и механику для игр, а также руководя процессом их разработки, и он помог мне в большей части моей работы над серией Uncharted. Сейчас Марк – старший консультант Sony Interactive Entertainment и главный архитектор PlayStation 4 и PlayStation 5.

В 2002 году на саммите D.I.C.E. в Лас-Вегасе Марк Черни выступил с исторической речью, которая положила начало тихой революции в игровой индустрии. Его доклад, озаглавленный просто «Метод», – источник мудрости гейм-дизайна, хорошей практики, уместной критики и советов по планированию[41]. В нем четко изложено, как улучшить процесс создания игр. Каждый разработчик игр и студент, изучающий игровую индустрию, должен хотя бы раз посмотреть это выступление.

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

Занятно, что Марк выступил с докладом о Методе в 2002 году, всего через год после того, как компания Agile Alliance опубликовала свой «Манифест гибкой разработки программного обеспечения»[42]. Между Методом и манифестом можно провести много параллелей, поскольку они оба рекомендуют «свободный, но структурированный» подход к созданию программного обеспечения. И их легко объединить, как мы увидим в последующих главах.

Ценность этапа препродакшена

Я считаю, что препродакшен – наиболее важный этап проекта. В своем выступлении Марк Черни говорит, что, когда у проекта возникают проблемы, чаще всего это происходит из-за того, что подготовка к этапу продакшена сделана неправильно или вообще пропущена. «Я считаю, что 80 процентов – я не преувеличиваю – ошибок при разработке игры – это прямой результат того, что было сделано или не сделано на этапе препродакшена»[43]. Затем Марк говорит: «На этапе препродакшена вам нужна не большая команда, а команда лучших и, вероятно, высокооплачиваемых сотрудников. Эта ключевая команда определит направление вашей игры и, скорее всего, будет руководить дальнейшим этапом продакшена. Так что набирайте лучших людей, каких только сможете найти, и как можно раньше»[44].

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

Глава 10

Что такое вертикальный срез

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

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

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

Кор луп, или основной игровой цикл

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

Однако это не означает, что Halo или любая хорошо продуманная игра однообразна. В интервью блогу Engadget в 2011 году Джейми сказал:

Я говорил о том, чтобы взять эти 30 секунд веселья и сыграть их в разных локациях с разным оружием, разными транспортными средствами против разных врагов и их комбинаций, иногда против врагов, которые сражаются друг с другом. Ни один 30‑секундный отрезок Halo никогда не повторяется; миссии постоянно меняют свой контекст[45].

Рис. 10.1. Вертикальный срез

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

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

В зависимости от стиля игры этот основной цикл может включать действия «бегать/прыгать/карабкаться», как в экшене с фокусом на персонаже типа Uncharted, или «выберите тип объекта / выберите область / постройте» в градостроительном симуляторе. Или же основной цикл заключается в мгновенном контроле («переместите влево / вправо/поворот/падение» в Tetris) или более опосредованном управлении («выберите юнита / отдайте команду» в StarCraft).

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

Специальные локации

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

Простой пример: вертикальный срез для Crash Bandicoot (созданный задолго до того, как я присоединился к Naughty Dog) состоял из двух уровней (термин левел-дизайна, означающий локации). На одном уровне был продемонстрирован сайд-скроллер[46], где Крэш перепрыгивает через ямы, разбивает ящики, собирая Вампа-фрукты, и бьет врагов, а на другом – кусочек геймплея, который встречается на протяжении всей законченной игры, где Крэш в панике бежит навстречу камере от гигантского валуна.

Эти два игровых уровня, представленные в виде вертикального среза, показали Naughty Dog, их издателю Universal Interactive и всем инвесторам, чего стоит ожидать от полноценной игры.

Три C

Вертикальный срез помогает нам определить в нашем дизайне кое-что еще: три C – character, camera, control (персонаж, камера и управление).

Персонаж

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

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

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

Камера

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

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

• Вид от третьего лица. Более сложный случай – камера от третьего лица, которая расположена на расстоянии от игрового процесса, как в 2D-сайд-скроллерах, например NES Super Mario Bros., 2D-изометрических играх, таких как Bastion или оригинальной StarCraft, 3D- экшенах, таких как The Witcher 3: Wild Hunt, или 3D-играх о строительстве городов, таких как Cities: Skylines. Эта камера будет двигаться либо следуя за персонажем игрока, как в Super Mario Bros., Bastion или The Witcher 3, либо находясь под прямым контролем игрока, как в играх StarCraft и Cities: Skylines.

Оба эти варианта требуют тонкой работы. Например, сайд-скроллеры создают так называемую коробку (англ. dance box) для персонажа игрока – ограниченное поле свободного передвижения, где персонаж игрока может двигаться, не перемещая камеру. Лекция Итая Керена на конференции GDC 2015 года и статья Scroll Back: The Theory and Practice of Cameras in Side-Scrollers в издательстве Gamasutra отлично освещают различные подходы к поиску идеального положения камеры в 2D-экшенах[47].

Вид от третьего лица в 3D-играх, таких как The Witcher 3 и Uncharted, представляет особо сложный случай. Здесь камера расположена рядом с персонажем игрока, следуя за его передвижениями, как дрон. Камера обычно находится под непосредственным контролем игрока (например, управляется стиком контроллера), но также она иногда находится под контролем невидимых триггеров. Эти триггеры перемещают камеру на определенную высоту и угол наклона, чтобы показать наиболее важные, интересные или самые красивые части окружения, сохраняя при этом персонажа игрока на экране. Иногда они перемещают камеру в определенное положение с помощью кат-сцены.

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

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

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

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

Управление

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

Агентивность[48] игрока, когда он взаимодействует с элементами управления, – это часть другого цикла, который стоит учесть гейм-дизайнерам. Это цикл, включающий как игрока, так и аппаратное и программное обеспечение игры. Возьмем, к примеру, консольного игрока с геймпадом. Как и с любым циклом, мы могли бы изучить его, начиная с любого места, но давайте начнем с восприятия игроком изображений и звуков, которые игра воспроизводит через экран и динамики.

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

Игровая консоль получает эти входные данные и включает их в вычисления, которые постоянно выполняет игра. Она решает, что произошло за эту долю секунды, и отправляет новые выходные данные на экран и динамики, и таким образом цикл начинается снова (рис. 10.2).

Рис. 10.2. Цикл восприятия – познания – действия – ввода – вычислений – вывода данных

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

В книге Game Feel гейм-дизайнер Стив Суинк заходит в своем размышлении на эту тему чуть дальше, рассматривая поле восприятия – концепцию из мира психологии. Приписывая эту идею психологам Дональду Сниггу и Артуру Комбсу, Стив говорит:

Идея поля восприятия состоит в том, что восприятие осуществляется на фоне всего предыдущего опыта, включая наши установки, мысли, идеи, фантазии и даже неправильные представления. То есть мы не воспринимаем что-то отдельно от остального опыта. Мы пропускаем все через фильтр нашего личного видения мира[49].

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

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

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

Итак, три C: персонаж, камера и управление (character, camera, control). Мы должны разобраться с этими элементами игры на этапе препродакшена, создав вертикальный срез с персонажем или персонажами игрока, их основными способностями и основными механиками игры.

Тестовые уровни и блокмеш

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

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

При помощи блок-схемы мы составляли несколько диаграмм, как показано на рис. 10.4.

В моих ранних проектах мы тратили много часов на составление подробных архитектурных планов наших уровней на бумаге или в приложении Adobe Illustrator. По мере того как развивался наш навык дизайна уровней в Naughty Dog, мы стали тратить меньше времени на детальную работу с бумагой и быстро переходили от наших разрозненных эскизов к созданию блокмешей.

Блокмеш, также известный как блокаут, вайтбокс или грэйбокс, представляет собой уровень из примитивной трехмерной геометрии без лишних деталей. Выделяют два типа: визуализируемая (видимая) геометрия, которую можно увидеть, и невидимая геометрия, используемая для коллизий[50]. Используя эти два типа геометрии, дизайнеры могут быстро и легко создавать эскизы уровня в его самой простой форме. Лучше всего, когда дизайнер сотрудничает на этом этапе с художниками, программистами, аниматорами, дизайнерами звука и всеми остальными, кто внесет свой вклад в дизайн уровня.

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

Рис. 10.3. Блок-схема, описывающая геймплей и последовательность сюжета в начале Uncharted 2: Among Thieves. Изображение предоставлено: UNCHARTED 2: Among Thieves™ © 2009 Sony Interactive Entertainment LLC. UNCHARTED 2: Among Thieves является торговой маркой Sony Interactive Entertainment LLC. Создано и разработано компанией Naughty Dog LLC

Иногда блокмеш делают в цвете, чтобы показать важные элементы, например места, куда можно забраться, или воду. Если вас интересует этот процесс, обязательно пройдите по хештегу #blocktober в Твиттере (рис. 10.6), инициатива которого принадлежит гейм-дизайнеру Naughty Dog Майклу Барклаю, прославившему блокмеш в 2017 году: по словам Майкла, «блокауты уровней – это искусство»[51].

Существует аналогичный процесс дизайна уровней для 2D-игр, где мы набрасываем уровень в редакторе уровней, используя примитивные формы. То, как это будет сделано, зависит от стиля игры и движка, но основной принцип тот же: быстро набросать что-то играбельное и усовершенствовать результат путем итерации.

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

В дополнение к этим простым указаниям я рекомендую вам следующие ресурсы.

• Вы можете найти много хороших бесед о дизайне уровней, с которыми выступали на конференции GDC на сайте GDC Vault (gdcvault.com).

• Книга Кристофера У. Тоттена An Architectural Approach to Level Design всесторонне освещает эту тему.

• В книге Скотта Роджерса «Level up! Руководство по созданию классных видеоигр»[52] можно найти много замечательных отрывков о дизайне уровней.

• Книга 101 Things I Learned in Architecture School Мэтью Фредерика изобилует мудрыми советами для архитекторов, которые окажутся не менее ценными и для дизайнеров уровней.

• Обязательно прочтите статью Defining Environment Language for Video Games ведущего гейм-дизайнера Naughty Dog Эмилии Шатц[53]. Эмилия – чрезвычайно проницательный гейм-дизайнер, и ее превосходная статья объединяет размышления о дизайне уровней с более общей философией гейм-дизайна.

Рис. 10.4. Переход от блок-схемы к приблизительному плану уровня начала Uncharted 2: Among Thieves. Изображение предоставлено: © 2009 SIE LLC/ UNCHARTED 2: Among Thieves™. Создано и разработано компанией Naughty Dog LLC

Размер и качество уровней в вертикальном срезе

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

В разработке коммерческой игры мы должны максимально и полно отточить визуал, анимацию, дизайн, код, звуковое сопровождение и музыку вертикального среза, чтобы он полностью соответствовал уровню качества готовой игры и был продаваем[54]. Тем не менее для многих небольших команд, в том числе студенческих, зачастую невозможно разработать и «отполировать» хотя бы один уровень к концу препродакшена. Вот тут-то и появляется концепция бьюти-корнера.

(a) Разработчики создают блокмеш уровня и начинают совершенствовать его с помощью итеративного процесса плейтестов, анализа и изменений

(б) Художник или дизайнер рисует наброски частей уровня, чтобы визуализировать, как будет выглядеть уровень в готовой игре

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

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

(д) Художники по текстурам, художники по свету и художники по визуальным эффектам завершают уровень. 3D-художники, гейм-дизайнеры и другие продолжают исправлять недочеты и совершенствовать дизайн.

Рис. 10.5. Блокмеш (он же блокаут, вайтбокс или грэйбокс) – процесс дизайна и художественного оформления уровней[55]. Изображения предоставлены Эриком Пангилинаном и © 2009 SIE LLC/ UNCHARTED 2: Among Thieves™. Создано и разработано компанией Naughty Dog LLC

Бьюти-корнер

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

В 3D-игре мы можем направить камеру в угол пространства, где несколько стен пересекаются с полом и потолком. Усеченный угол обзора камеры – это клиновидная часть пространства, видимая с точки зрения камеры с учетом ее поля зрения, соотношения сторон и настроек глубины. Все, что мы видим в бьюти-корнере в поле зрения камеры, должно выглядеть великолепно. Это включает в себя не только фон, но и представленные на данном участке объекты. Мы должны красиво анимировать все, что будет двигаться в готовой игре, и все там должно звучать великолепно. Никогда не пренебрегайте звуковым оформлением – ни на одном из этапов разработки.

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

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

Рис. 10.6. Твит Майкла Барклая в Твиттере, запустивший хештег #blocktober

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

Рис. 10.7. Бьюти-корнер для визуализации того, как будет выглядеть завершенный игровой уровень

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

Сложности и польза вертикального среза

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

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

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

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

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

Глава 11

Создание вертикального среза

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

Неопытные разработчики могут подумать, что игры создаются следующим образом:

…словно на конвейерной линии с помощью метода водопада, который мы обсуждали в главе 9. Они не понимают: для того чтобы сделать игру великолепной, нужно создавать и переделывать ее снова и снова – и именно поэтому у разработчиков всегда не хватает времени.

Вот как на самом деле строится игра:

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

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

Работайте с прототипами

В своем выступлении о Методе на саммите D.I.C.E. 2002 года Марк Черни описывал «первую играбельную версию продового качества» (англ. publishable first playable), – его термин. Позже это станет известно как вертикальный срез. Марк говорил, что мы должны начать с того, с чего начинали на этапе идеации: с прототипов.

Мне ни к чему говорить вам, сколь многому вы учитесь, создавая прототипы. Команда создает огромное множество прототипов. Долго не ждите – возьмите те части, которые у вас есть, какими бы отрывочными они ни были, и улучшите все, что сможете. Прототипы учат вас… Они в конце концов становятся неотличимы от уровней игры. Каждый прототип несет в себе частичку художественного оформления, игровых механик и технологий, показывая то, какой может быть игра[57].

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

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

Покажите эпизод из начала игры – но не самое начало

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

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

Вы можете ознакомиться с философией, лежащей в основе такого решения, в разделе «В каком порядке собирать игру» в главе 22.

Итерируйте основные элементы вашей игры

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

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

Обратите внимание на тот акцент, который Марк Черни сделал на количестве прототипов в приведенной выше цитате. Это значит, что вам придется создавать, а затем отбрасывать то, что в итоге может войти в вертикальный срез, возможно, несколько раз подряд. В своем выступлении Марк отмечает, что нам, вероятно, придется отказаться от примерно четырех разных версий вертикального среза, прежде чем мы наконец будем довольны проделанной работой. Недавно он сказал мне: «Для Crash Bandicoot потребовалось пять вертикальных срезов, чтобы в конечном счете показать, какую игру готовит Naughty Dog; как только это было сделано, мы приступили к продакшену. Слава Энди [Гэвину] и Джейсону [Рубину] за терпение при такой частой переработке собственного дизайна».

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

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

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

Определитесь с игровым движком и аппаратной платформой

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

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

Наводите и поддерживайте порядок в проекте

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

Следите за проектной папкой следующим образом.

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

• Используйте вложенные папки, когда папка заполняется таким количеством элементов, что становится трудно быстро найти нужный файл (обычно десять файлов или около того).

Простую иерархию проектной папки можно найти на сайте этой книги, playfulproductionprocess.com, и использовать ее в качестве отправной точки.

Для поддержания в порядке вашего кода можно делать следующее.

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

• Выбирайте описательные, но не слишком длинные имена переменных.

• Используйте стиль camelCase, чтобы сделать имена переменных более удобочитаемыми.

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

Другие хорошие практики:

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

• используйте систему контроля версий для создания онлайн-хранилища кода и ассетов, чтобы поделиться с членами команды и при необходимости вернуться к предыдущей версии.

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

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

Начните добавлять функции отладки

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

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

Ошибайтесь рано, ошибайтесь быстро, ошибайтесь часто

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

Возможно, вы слышали поговорку «Ошибайтесь рано, ошибайтесь быстро, ошибайтесь часто» (fail early, fail fast, fail often), которая пришла из мира быстрого прототипирования, группы итеративных методов промышленного дизайна. Это кредо побуждает нас начинать создавать на ранних стадиях проекта и пытаться как можно быстрее выявлять основные препятствия на нашем пути. Благодаря этому у нас появляется больше времени на попытки создать продукт, у которого не будет серьезных проблем.

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

Работайте в одном физическом пространстве или вместе по сети

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

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

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

Сохраняйте и классифицируйте ваши дизайн-материалы

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

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

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

Руководствуйтесь целями проекта

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

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

Когда следует изменить цели вашего проекта

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

И вот тогда вам следует подумать об изменении целей вашего проекта, чтобы они соответствовали тому, что вы обнаружили. Трейси Фуллертон говорит: «Я называю это шлифовкой или оттачиванием целей – по мере того как вы лучше их понимаете, с помощью итерирования вы не столько меняете их, сколько оттачиваете, добираясь до самой сути. Я думаю, что на самом деле это довольно важная сторона “достижения” целей – отточить их до такой степени, чтобы они стали достижимы»[58].

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

Что мы делаем, создавая вертикальный срез

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

Разрабатываем дизайн через создание чего-либо

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

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

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

Создаем что-то, что доносит наши идеи

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

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

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

Знакомимся с нашими инструментами и технологиями

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

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

Собираем информацию о том, сколько времени нам нужно и кто понадобится в команде

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

Не стоит отслеживать, сколько времени вам нужно для создания каждого отдельного объекта в вертикальном срезе – избегайте подробностей. Вам надо только определить, как быстро вы работаете. Создание игр требует терпения и настойчивости: все в разработке занимает гораздо больше времени, чем кажется изначально. Трудноразрешимые проблемы могут внезапно возникнуть даже в тех видах работы, которые вы легко выполняли раньше. Как отметил креативный директор и сценарист Мел Маккубри в подкасте Макса и Ника Фолкманов Script Lock, в играх «у пожарного и креативщика голова болит одинаково»[59]. Вы несете ответственность за то, чтобы реалистично оценить скорость, с которой ваша команда может работать.

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

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

Препродакшен нельзя запланировать обычным образом

В своем выступлении на саммите D.I.C.E. 2002 года Марк Черни заявил, что идея о возможности «запланировать создание вашей игры» – миф, и получил в ответ град аплодисментов из зала[60].

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

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

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

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

Таймбоксинг

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

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

Хитрость таймбоксинга состоит в том, чтобы одним глазом следить за часами и понимать, когда пора заканчивать. Мы все могли бы вечно возиться с тем, что делаем, особенно если нам нравится это делать. Но наступает время, когда вы уже не улучшаете, а просто вносите больше изменений. Леонардо да Винчи приписывается хорошее изречение: «Произведение искусства нельзя закончить – только забросить». Каждый творческий человек должен решить, когда его работа достаточно хороша. Гейм-дизайнеры могут обратиться к своим плейтестерам, чтобы понять, доведена ли до ума конкретная задача, и с опытом вы научитесь сами определять степень готовности тех или иных вещей.

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

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

Вот один из способов подумать о содержании проекта. Хорошо известно, что чудаковатая комедия 1938 года «Воспитание крошки» оказала большое влияние на дизайн Uncharted: Drake’s Fortune. При написании персонажей Елены Фишер и Нейтана Дрейка гейм-директор Эми Хенниг черпала вдохновение в бесконечном подшучивании между Кэтрин Хепберн и Кэри Грантом. Режиссера фильма «Воспитание крошки» Говарда Хоукса однажды попросили определить, что сделало фильм отличным, на что он ответил: «Три замечательные сцены, ни одной плохой».

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

Распределяя время работы над вертикальным срезом, помните, что не все должно быть завершено к концу этапа препродакшена. Марк Черни говорит: «Вы не можете запланировать дату, когда вы решите все свои, казалось бы, неразрешимые проблемы»[61]. Сосредоточьтесь на сути своего дизайна и используйте навыки и опыт, чтобы понять, решение каких проблем вы можете отложить на этап продакшена (следующий после препродакшена).

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

* * *

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

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

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

* * *

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

Глава 12

Проведение плейтестов

Плейтесты лежат в основе производственного процесса игр. Я уже дал вам несколько простых рекомендаций по проведению плейтестов в главе 5. В этой главе мы рассмотрим здоровую практику тестирования, которой вы сможете пользоваться на протяжении всего проекта, и заложим основы «формальных» процессов плейтестинга, которые обсудим в главах 24 и 25.

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

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

Гейм-дизайнер Таня Шорт упоминает «читаемость» систем. Большинство игр представляют собой системы правил, ресурсов, процедур и отношений, и для понимания игровой системы они должны быть читаемыми: представлены таким образом, чтобы их смысл был ясен. «Читаемость позволяет игроку декодировать новый язык, которому игра пытается его научить»[62]. Читаемость игры – это еще один критерий, который мы проверяем при тестировании.

Модель дизайнера, образ системы и модель пользователя

В рамках беседы о читаемости и понятности игр я предпочитаю концепцию модели дизайнера, образа системы и модели пользователя. Все они взяты из очень важной книги юзабилити-дизайнера и психолога Дональда А. Нормана «Дизайн привычных вещей»[63]. Эта книга любима гейм-дизайнерами и UX-дизайнерами. Ведь она дает представление о том, как люди воспринимают системы и взаимодействуют с ними.

По мнению Дона Нормана, модель проектируемой системы – это то, как дизайнер видит игру (или любую другую интерактивную систему). Это «концептуальное представление разработки самим дизайнером». Образ системы – это то, как игра на самом деле представляется игроку. «Образ системы основывается на ее физической структуре (включая документацию)»[64]. Дизайнер надеется, что образ системы близок к его модели, но на самом деле это может быть совсем не так, особенно на ранней стадии разработки.

И, наконец, модель пользователя – это то, что происходит в голове играющего. «Ментальная модель пользователя создается в результате взаимодействия с продуктом и образом системы»[65]. Но при этом пользователь привносит собственный опыт, предубеждения и способность интерпретировать то, что ему дает образ системы (поле восприятия, про которое писал Стив Суинк в книге Game Feel[66]), что может привести к расхождениям между моделью пользователя и образом системы. И если образ системы не совсем соответствует модели дизайнера, то модель пользователя еще больше отдалится от модели дизайнера, как в игре в испорченный телефон, где сообщение с каждым ходом искажается все сильнее. Дон Норман пишет: «Дизайнер ожидает, что модель пользователя будет совпадать с его моделью, но поскольку дизайнер не общается с пользователем непосредственно – коммуникация осуществляется через образ системы»[67].

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

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

Аффордансы и сигнифаеры

Дон Норман описывает, как образ системы сообщается пользователю с помощью аффордансов и сигнифаеров. Концепция аффордансов пришла из работы психолога Джеймса Дж. Гибсона «Экологический подход к зрительному восприятию»[68] и обрисовывает то, как животные используют окружающую среду. Норман развил эту идею в теорию аффордансов, которые «определяют, как объект может быть использован», и сигнифаеров, которые «определяют, как люди обнаруживают эти аффордансы: с помощью знаков, воспринимаемых сигналов того, что можно сделать»[69].

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

Люди часто объединяют эти два понятия под термином «аффорданс», но их важно различать. В видеоигре может быть фича, при которой, если я стою неподвижно в определенном месте уровня более пяти секунд, меня автоматически и мгновенно перемещают в другое место. Эта фича – аффорданс: механизм, который приводит к определенному результату. Но если это место на уровне никак не обозначено, это довольно странная фича. Мы не можем найти место автоматического перемещения, разве что это выйдет случайно, но при этом можем без каких-либо объяснений случайно переместиться, если не туда встанем. Если я знаю, что такое место где-то есть, но я не знаю где, тогда, может быть, я смогу найти его путем утомительного метода проб и ошибок. И в таком случае это скорее баг, чем фича.

Однако мы можем разместить платформу в этом месте автоматического перемещения: у платформы будет светиться нижняя панель, которая тихо гудит, но начинает гудеть громче, когда я встаю на нее; на панели отсчитывается время «5, 4, 3…», персонажа игрока охватывает свечение, а само перемещение сопровождается звуковым эффектом, похожим на раскат грома, – вот мы разработали телепорт. Сама платформа, светящаяся панель, звуковые и визуальные эффекты, а также обратный отсчет – все это четко передает действие аффорданса. Сам аффорданс одинаков в обоих случаях, но сигнифаеры смогли превратить бесполезную игровую механику в особенность нашего гейм-дизайна.

Тестирование читаемости и игрового опыта

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

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

Лучшие практики плейтестов

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

Сведите к минимуму разговор с вашим плейтестером до и во время теста

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

Как плейтестер, так и дизайнер должны быть в наушниках

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

Приготовьте лист бумаги со схемой управления

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

Рис. 12.1. Подсказка со схемой управления

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

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

Рис. 12.2. Письменная подсказка

Предложите плейтестеру проговаривать вслух чувства и мысли

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

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

Добавьте предупреждение, если это необходимо

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

Будьте внимательны к игровому опыту вашего плейтестера

Внимательно следите за тестером, чтобы увидеть, что он делает в игре. Обратите внимание на его реакции и поведение. Что он, кажется, понимает в том, что можно и чего нельзя делать в игре? Чего он не понимает? Что он пытается сделать, а чего не пытается? Какие эмоции он проявляет?

Записывайте все, что ваш плейтестер делает и говорит

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

Не помогайте плейтестеру

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

Следите за временем

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

После плейтеста проведите заключительную беседу

Когда время тестирования подойдет к концу, проведите с вашим тестером заключительную беседу. Формат этого разговора выбирайте сами, но у меня есть несколько общих рекомендаций, которые вам помогут. Начните с открытого вопроса, чтобы сфокусировать внимание тестера на интересующем вас аспекте игры. Избегайте вопросов, на которые можно ответить просто «да» или «нет» или, например, числом. Проектный директор и художник Марк Таттерсолл составил список из пяти открытых вопросов, которые можно задать плейтестерам – этот список представила Алисса Макалун на сайте игрового издания Gamasutra[71].

• Какой момент или взаимодействие понравились вам больше всего?

• Какой момент или взаимодействие понравились вам меньше всего?

• В какой момент вы почувствовали себя наиболее сообразительным?

• Было ли что-то, что вы хотели сделать, но чего не позволила игра?

• Если бы у вас была волшебная палочка и вы могли изменить любой аспект игры или испытанный вами опыт, что вы поменяли бы в условиях неограниченного бюджета и времени?[72]

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

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

Небольшое замечание об особенностях тестирования игр для детей от гейм-дизайнера и продюсера Алана Данга: «Проводить тестирование с детьми довольно трудно: они, как правило, хотят угодить взрослым и не хотят, чтобы с ними ассоциировался негатив. Один из способов обойти это – спросить детей, как они описали бы эту игру своему другу или ровеснику и что, по их мнению, подумал бы об игре кто-то другой»[73].

Не объясняйте игру

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

Не отчаивайтесь

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

Хороший способ справиться с эмоциями – предвидеть их и быть готовыми бороться с ними любым удобным для вас способом. Вы можете напомнить себе, что игра – это не дизайнер, занять некоторую эмоциональную дистанцию. Никогда не стоит выражать сложные эмоции перед игроком, но и сдерживать их тоже плохая идея – лучше всего найти здоровый способ их выразить. Я призываю гейм-дизайнеров оказывать друг другу эмоциональную поддержку после игрового теста: жаловаться и даже ныть при необходимости, выражая разочарование или печаль от того, что тест прошел не так, как хотелось бы. Выплесните эмоции таким образом, чтобы это не было токсично – зло или гадко, и не было направлено на человека, – и позвольте им уйти в прошлое. Как только вы справитесь с переживаниями, просмотрите ваши заметки. Кропотливо все изучите, чтобы понять, что работает в вашей игре, а что нет. Будьте честны с собой и признавайте как свои успехи, так и неудачи. Начните составлять план решения проблем и верьте, что следующий тест пройдет лучше. Так бывает почти всегда. Следуйте совету, который дал Мэтью Фредерик в книге 101 Things I Learned in Architecture School:

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

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

Проведение регулярных плейтестов

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

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

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

Оценка обратной связи

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

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

1. Сломано: надо починить. Это проблемы дизайна или его реализации, которые мешают игроку получить тот опыт, который мы хотим, чтобы он получил. Достаточно внести необходимые коррективы в игру.

2. Сомнительные места: возможно, надо исправить. То, что не работает или, по крайней мере, работает не так, как предполагалось, – требует тщательной проверки. Эти проблемы могут крыться в самом дизайне (модели дизайнера), в игре (образе системы) или в понимании игры игроком (модели пользователя). Их надо внимательно изучить и найти возможное решение.

3. Предложения: новые идеи. Во время игровых тестов рождается множество идей: они могут либо стать золотой жилой для разработчика, либо вовсе не иметь отношения к тому, чего разработчик пытается достичь. Обсуждая выдвинутые предложения, принимая одни и отвергая другие, мы можем усовершенствовать дизайн нашей игры.

После того как вы просмотрели и отсортировали свои заметки, откройте документ, в котором у вас записаны цели проекта. Спросите себя: поможет ли тот или иной отзыв достичь целей проекта и, в частности, опыта пользователя? Особенно полезно задать себе этот вопрос, когда вы оцениваете заметки из категорий «сомнительные места» и «предложения». Чаще истинная природа проблем вскрывается, когда тестеру задают открытые вопросы в заключительном опросе.

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

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

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

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

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

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

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

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

Чек-лист действий для оценки обратной связи

✓ Смотрите и слушайте.

✓ Все записывайте.

✓ Отнеситесь к отзывам серьезно – не занимайте оборонительную позицию и не отвергайте их слишком быстро.

✓ Можно ли классифицировать отзывы как (1) надо починить, (2) возможно, надо исправить или (3) новая идея?

✓ Запланируйте исправление того, что надо починить.

✓ Оцените, насколько возможные исправления и новые идеи соотносятся с целями вашего проекта.

✓ Внимательно интерпретируйте то, что говорят игроки, руководствуясь тем, что вы видели, пока они играли.

✓ Обсудите обратную связь с соратником.

«Мне понравилось, мне бы хотелось, что, если?..»

«Мне понравилось, мне бы хотелось, что, если?..» (I Like, I Wish, What If?..) – это способ получить эффективную обратную связь, разработанный дизайнерской и консалтинговой фирмой IDEO. Во многом этот метод пересекается с техникой сэндвича, которую мы обсуждали в главе 6. Я научился этому методу у гейм-дизайнера и исследователя Денниса Рамиреса, и теперь это основной элемент программы в изучении гейм-дизайна в USC. Эта техника применима, когда дизайнеры тестируют работу друг друга, и она также отлично подойдет для эффективного общения практически по любой теме, включая обсуждение процесса разработки игр или отношений между членами команды.

Техника «Мне понравилось, мне бы хотелось, что, если?..» настолько проста, что едва ли нуждается в каких-либо объяснениях. Просмотрев какую-то творческую работу – возможно, протестировав игру или прочитав проектный документ, – мы формулируем наш отзыв словами: «Мне понравилось, мне бы хотелось, что, если?..» Например: «Мне нравится, как персонаж прыгает, – им удобно управлять в воздухе. Мне бы хотелось, чтобы он поднимался в воздух немного быстрее после нажатия кнопки прыжка. Что, если вы сократите или уберете начало анимации прыжка?»

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

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

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

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

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

Дизайнеры полагаются на личное общение и, в частности, на обратную связь во время проекта. Вы запрашиваете отзывы пользователей о вашем дизайне и отзывы коллег о разрабатываемых вами структурах. Вне самого проекта коллеги-дизайнеры должны сообщать о том, как они работают в команде. Лучше всего давать обратную связь от своего лица. Например, «Мне иногда кажется, что ты меня не слушаешь» вместо «Ты не слушаешь ни слова из того, что я говорю». В частности, хороший метод поощрить открытое обсуждение проекта – техника «Мне понравилось, мне бы хотелось, что, если?..»[75]

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

Тестирование игр для дизайнеров и художников

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

В искусстве существует подход: «Это моя работа: мне не нужно ее объяснять или оправдывать». Но современные художники, похоже, все больше интересуются тем, как их работы воздействуют на людей. Дизайн и искусство все чаще участвуют в социальной рекламе, политической активности и этике. В своей книге «Дизайн как отношение»[76] (Design as an Attitude) дизайн-критик Элис Росторн подчеркивает, что чистота – это «не подлежащий обсуждению компонент желаемого дизайна». Она говорит: «Если у нас есть какие-либо причины чувствовать себя неловко из-за этических или экологических последствий любого аспекта дизайн-проекта – от его разработки, тестирования и производства до распространения, продаж и маркетинга… такой дизайн вряд ли можно будет назвать желаемым»[77]. Помимо этого, у искусства есть возможность позитивно влиять на мир, выявляя несправедливость и продвигая равноправие.

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

Глава 13

Концентрическая разработка

Почему Вселенная организована иерархически – притча

Жили-были два часовщика по имени Хора и Темпус. Оба они делали прекрасные часы, и у обоих было много покупателей. Люди заходили в их магазины, и телефоны постоянно разрывались от звонков. Однако с годами Хора процветала, а Темпус становился все беднее и беднее. А все потому, что Хора открыла принцип иерархии…

У Хоры и Темпуса часы состояли из одинакового количества деталей – тысячи. Темпус собирал часы таким образом, что если он прерывался – ответить на телефонный звонок, например, – то они разваливались на части, и их приходилось собирать заново. Чем больше клиентов звонили Темпусу, тем меньше времени у него оставалось на сборку часов.

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

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

Что такое концентрическая разработка

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

• В каком порядке это все надо собрать?

• Действительно ли нам все это потребуется для создания замечательной игры?

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

• Что произойдет, если нам потребуется внести серьезные изменения по итогам тестирования или отзывов?

• Соберется ли игра в конце разработки? Если у нас закончится время, все ли части, которые у нас есть, соединятся в единое целое?

Впервые я услышал термин «концентрическая разработка» в 2002 году в разговоре с Джоном Спинэйлом, тогдашним руководителем студии Crystal Dynamics. Сегодня Джон известен тем, что он – управляющий партнер и соучредитель компании JAZZ Venture Partners с опытом работы в качестве инвестора и предпринимателя в области медиа и развлекательных технологий.

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

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

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

Рис. 13.1. Концентрическая структура замка

Сначала доведите до конца основные механики игры

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

Для игр с персонажем игрока, которым непосредственно управляет игрок, основные механики составят наши три C: персонаж, камера и управление. Вот только в этот раз рассматриваем только то управление, которое влияет на перемещение персонажа. Этими механиками могут стать:

• элементы управления движением и камерой в игре с видом от первого лица;

• алгоритмы перемещения персонажа игрока и камеры в сайд-скроллерах;

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

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

• механика перемещения камеры по карте и взаимодействие в один клик для стратегической игры в реальном времени;

• наиболее часто используемые механики взаимодействия в игре-головоломке;

• основы анализатора текста в текстовых приключенческих играх.

Вам, дизайнеру, решать, каковы основные механики вашей игры. Выберите то, что, по вашему мнению, обеспечит прочную основу для геймплея. Разобраться с основными механиками обычно не так уж сложно. Например, в Tetris основные механики – летящие вниз тетрамино и возможность перемещать их влево и вправо и вращать по часовой стрелке и против нее. В SimCity это возможность укладывать дорожную плитку, строить инфраструктуру или зонировать пространство. В Sims – возможность управлять конкретным персонажем и взаимодействовать с конкретным объектом. В Dance Dance Revolution основные игровые механики в то же время самые простые части геймплейного цикла: стрелки, бегущие по экрану, и возможность нажать на кнопку, как только стрелка доберется до нижней части экрана.

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

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

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

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

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

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

Внедрение второстепенных и третьестепенных механик

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

• прыжки и лазание в игре про перемещение;

• основные боевые действия в игре о сражениях;

• общение с другими персонажами в повествовательной игре.

Для игр без персонажа игрока это:

• выбор и создание зданий и юнитов в стратегической игре в реальном времени;

• механика, которая позволяет пройти уровень в игре-головоломке;

• расширенные возможности анализатора текста и изложения текста в текстовой приключенческой игре.

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

Эти третьестепенные механики составят «следующий слой» механики нашей игры. Они обычно так или иначе зависят от основных и второстепенных механик, конкретизируя дизайн игры. Список этих механик может быть обширен. Для игры с персонажем игрока они могут включать все, с чем может взаимодействовать игрок: персонажей, как вражеских, так и дружественных, инструменты и оружие, переключатели и двери, сокровища и ловушки. В зависимости от дизайна вашей игры вы можете подразделить игровые механики на четверостепенные, пятистепенные и так далее, где каждый новый уровень иерархии зависит от предыдущего.

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

Концентрическая разработка и параметры дизайна

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

В 2D- или 3D-платформерах решающее значение имеет размещение платформ, по которым может прыгать персонаж игрока. Стоит вам расположить их слишком далеко друг от друга, и игрок не сможет пройти уровень. Гейм-дизайнеры иногда тратят много времени на планировку уровней, а затем меняют свое мнение относительно длины прыжка игрока. Возможно, они захотели, чтобы персонаж игрока выглядел немного сильнее, и потому увеличили высоту и длину его прыжка – и внезапно игрок может легко перепрыгивать в места, которые ранее были недоступны, и даже пропускать целые разделы тщательно продуманного геймплея. И затем дизайнеру приходится заново начинать колоссальную работу по планировке уровня.

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

Тестовые уровни

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

В экшен-играх (например, в серии Uncharted) на тестовых уровнях проверяются механики лазания с помощью моделей разных коробок, пандусов, выступов и веревок. Эти элементы располагаются в виде сеток, показывающих возможные пространственные взаимосвязи, которые могут быть использованы в игре. Мы, например, размещали ящики на расстоянии 1,5 м, 2 м, 2,5 м, 3 м и так далее, чтобы проверить, возможно ли по ним прыгать. Вы можете представить себе тестовые уровни для других типов игровых механик и других жанров игр.

Такие тестовые уровни послужат лабораторией или тренажерным залом для точной настройки параметров дизайна во время работы над вертикальным срезом. Их также можно использовать, когда мы работаем над ощущением игры и сочностью механик (подробнее в главе 22). Они помогут нам определить степень интересности и сложности различных сочетаний элементов. Не менее важно и то, что они могут помочь обнаружить ошибки в коде, – если, например, без нашего ведома немного изменятся параметры дизайна и персонаж игрока сможет прыгать на расстояние 6,1 м вместо 6 м, ломая этим игру.

Полируйте игру по ходу разработки

В мире кино и театра производственная ценность, или продакшен вэлью (от англ. production value), – это качество продукта с точки зрения денег, потраченных на его постановку, декорации и внешний вид. (Я бы сказал, что на эти аспекты тратится больше внимания, чем денег.) Мы можем применить термин «продакшен вэлью» и к играм, когда речь идет о качестве графики и звукового оформления, визуальных эффектах и освещении, даже тактильном дизайне грохочущего, вибрирующего контроллера или телефона. При создании прототипа продакшен вэлью обычно не играет большой роли, чего нельзя сказать о вертикальном срезе. Быстрый способ добиться хорошего качества вертикального среза заключается в том, чтобы полировать игру по ходу ее разработки, работая концентрически, поэтапно завершая и дорабатывая все ее части, начиная с основных механик и постепенно переходя к второстепенным и так далее.

Легендарный баскетбольный тренер Калифорнийского университета в Лос-Анджелесе Джон Вуден сказал: «Если у вас нет времени сделать хорошо, когда у вас будет время переделать все сначала?»[79]

Не используйте то, что есть по умолчанию

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

Полировать не значит делать идеальной

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

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

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

Концентрическая разработка: модульность и системы

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

Я убежден, что вы не можете по-настоящему оценить цифровую игру или интерактивные медиа без реализации всех ее деталей, потому что именно они во многом определяют, будет игра работать или нет. Вспомните изречение дизайнеров Рэя и Чарльза Имз: «Детали – это не мелочь. Они создают дизайн»[80]. Подумайте обо всех мельчайших составляющих, влияющих на хорошее ощущение игры и ее сочность. Очевидно, что в гейм-дизайне, как и во всем дизайне, важна каждая деталь, воздействующая на понимание, восприятие и оценку аудитории. Даже одна незначительная деталь, оказывающая негативное влияние, может испортить все впечатление. В пример – яркий, но грубый – приведу одно высказывание: «Сколько мух вы готовы положить в свой суп?»

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

В своей книге Advanced Game Design: A Systems Approach гейм-дизайнер и профессор Майкл Селлерс дает нам дополнительный контекст для понимания важности модульности в гейм-дизайне. Он вводит понятие метастабильности, что означает «стабильный, но постоянно меняющийся». Он пишет: «Метастабильность – это состояние, когда нечто длительное время пребывает в стабильной форме во времени (как правило), тем не менее постоянно меняется на более низком уровне организации»[81]. Затем Майк продолжает:

Слово «синергия» означает «совместная работа». В употребление этот термин ввел Бакминстер Фуллер, который описывал синергию как «поведение всей системы, которое не может быть предсказано через наблюдения за поведением составных частей и подразделов этой системы» (Фуллер, 1975). Это еще один способ описания метастабильности, когда в результате сочетания деталей на более низком уровне организации возникает что-то новое, что часто приводит к свойствам, не присущим самим деталям…

Идея того, что системы являются метастабильными объектами с собственными свойствами и что они содержат другие метастабильные элементы более низкого уровня, – одно из ключевых понятий как системного мышления, так и гейм-дизайна[82].

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

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

Итерация, оценка и стабильность

Итерация важна, но часто бывает сложной. Легко заблудиться в итеративных циклах, если вы не будете двигаться медленно и осторожно. Джордж Кокорис считает, что «самое важное, что нужно сделать при тестировании и итерации, – это уменьшить количество движущихся частей в каждом исследуемом случае, чтобы лучше определить причинно-следственные связи»[83].

Когда мы разрабатываем модульным способом, следует регулярно отдыхать или делать перерывы на протяжении всего проекта, чтобы оценить, где именно находится проект. Кроме того, как напомнил мне гейм-дизайнер Марк Вильгельм, мы должны учитывать, что «в средних и особенно крупных командах… модульный подход также позволяет “функциональным командам” разделять обязанности и работать более целенаправленно и с менее пугающими результатами. Это может усилить чувство сопричастности и, следовательно, чувство приверженности и гордости за работу и вклад в проект».

Для того чтобы работать наиболее эффективно, необходимо, чтобы все в нашей игре было готово пройти оценку на каждом этапе проекта, будь то ежедневный тест в студии, формальный тест с аудиторией или презентация проекта заинтересованным сторонам и спонсорам. Чтобы мы могли оценить любой модуль нашей игры, каждый подмодуль должен быть стабильным и работать исправно. Это очень соответствует принципам Agile-разработки. Разработчик и продюсер Алан Данг сказал: «Имея возможность оценивать игру на каждом ее этапе, вы можете вносить необходимые изменения или менять приоритеты, чтобы сделать игру лучше и привести ее в соответствие с видением каждого»[84].

Концентрическая разработка помогает с менеджментом времени

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

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

Когда мы создаем игру концентрическим, модульным способом, мы можем раньше и яснее увидеть, когда конкретный модуль нашей игры не работает, тем самым поддерживая кредо быстрого прототипирования, о котором я упоминал в главе 11: «Ошибайтесь рано, ошибайтесь быстро, ошибайтесь часто». Если мы будем мыслить понятиями модулей, а не только взаимосвязанного целого, то с наибольшей вероятностью мы сможем вовремя отказаться от идей, что раз за разом терпят неудачу или кажутся уже не такими важными. Это согласуется с мыслью режиссера Pixar Эндрю Стэнтона («История игрушек», «Приключения Флика», «В поисках Немо»), которую Эд Кэтмелл и Эми Уоллес приводят в книге «Корпорация гениев».

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

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

Переход к концентрической разработке

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

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

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

Концентрическая разработка и вертикальный срез

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

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

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

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

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

Концентрическая разработка и Agile

Когда я беседовал с Джоном Спинэйлом в 2002 году, концентрическая разработка казалась чем-то радикальным в кругах разработчиков игр. Возможно, виной тому было влияние быстрого прототипирования – «делайте все быстро, прототип должен просто функционировать, оставьте его грубым и незаконченным!» (философия, ценная на этапе формирования идей). Понять ценность перехода к концентрической разработке на этапе препродакшена было довольно сложно.

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

Возможно, вы уже кое-что знаете об Agile-разработке, поскольку она используется многими разработчиками игр и программного обеспечения по всему миру. Как и Метод, Agile-разработка была прогрессивной реакцией на идеи конвейерной сборки, воплощенные в каскадном подходе (водопад) к созданию программного обеспечения. Эта методология возникла благодаря другим процессам, таким как быстрая разработка приложений в 1970‑х и 1980‑х годах и рациональный унифицированный процесс в 1990‑х[86]. Agile-разработка – это подход к разработке программного обеспечения, при котором дизайн создаваемого программного обеспечения и решения о том, как его лучше всего создавать, развиваются с течением времени благодаря сотрудничеству между командой разработчиков и заинтересованными сторонами проекта.

Agile-разработка – это эффективный, творческий подход к разработке программного обеспечения. Он выступает за адаптивное планирование, эволюционное развитие, раннюю поставку и постоянное совершенствование, а также поощряет быстрое и гибкое реагирование на изменения[87]. Как резюмируется в «Манифесте гибкой разработки программного обеспечения», основные идеи данного подхода заключаются в следующем:

люди и взаимодействие важнее процессов и инструментов;

работающий продукт важнее исчерпывающей документации;

сотрудничество с заказчиком важнее согласования условий контракта;

готовность к изменениям важнее следования первоначальному плану[88].

Эмпирическое правило Agile-разработки резюмируется высказыванием, которое значительно старше этого подхода: «Относитесь к переменам как к возможности, а не проблеме».

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

Максимизация несделанной работы

В рамках концентрической разработки мы постоянно обсуждаем то, что наиболее важно для дизайна игры на сегодня – это очень по Agile. Это не только помогает улучшить проект, но и сводит к минимуму количество сверхурочной работы, в противном случае неизбежной, и помогает управлять проектом без стресса. Как сказала моя коллега по программе USC Games, UX-дизайнер и преподаватель Маргарет Мозер: «Частый пересмотр приоритетов необходим для максимизации несделанной работы (мой любимый принцип Agile-разработки)»[89].

Слова Маргарет отсылают к одному из двенадцати принципов, лежащих в основе манифеста, а именно: «Простота как искусство не делать лишней работы очень важна». Эта концепция «лишней работы» не так проста: разве мы не хотим реализовать максимум в своем проекте? Здесь речь о том, что мы должны сосредоточиться на работе, которую нужно реализовать в соответствии с целями нашего проекта, в частности создать целевой опыт. И мы должны понимать, когда что-то никак не способствует достижению этих целей. Если какая-то идея не помогает нам, это лишняя работа. Можно обобщить этот принцип Agile-разработки как «работайте не усерднее, а рациональнее» (англ. work smarter, not harder).

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

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

Темпы концентрической разработки

Работая концентрически, вам приходится двигаться помедленнее, и поначалу это надоедает. Вы проделываете большую детальную работу над скучными основными механиками, в то время как хотите начать играть с увлекательными второстепенными механиками. Основные механики настолько просты – несомненно, они будут работать!

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

* * *

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

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

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

Глава 14

Артефакт препродакшена – вертикальный срез

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

Билд вертикального среза

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

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

Подготовьте дополнительные материалы

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

Понимание скоупа через создание вертикального среза

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

Плейтест вертикального среза

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

Фокус-тест названия игры и ключевого арта

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

* * *

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

Глава 15

Борьба с кранчем

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

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

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

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

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

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

Рис. 15.1. Чрезмерная загруженность разработчиков во многих игровых проектах

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

Вероятно, мы сможем продолжать в таком духе еще какое-то время. Но исследования показывают, что при сверхурочной работе наша производительность быстро падает, как описано в статье Боба Салливана для CNBC: «Производительность труда резко падает после 50‑часовой рабочей недели, а после 55 часов обрывается вовсе – настолько, что тот, кто работает по 70 часов, ничего не производит за эти дополнительные 15 часов»[91].

Недостаток сна усугубляет ситуацию. Уставшие сотрудники подвержены когнитивным нарушениям: они с трудом находят решения проблем, совершают ошибки, на исправление которых требуется время, и отвлекаются на детали, несущественные в общей картине проекта. В отличной статье для журнала Harvard Business Review Сара Грин Кармайкл цитирует исследования, в которых говорится: «Мы устаем гораздо быстрее, чем соглашаемся в этом себе признаться. Лишь от 1 до 3 % людей способны ограничиваться 5–6 часами сна без последствий для своей продуктивности. Более того, на каждые 100 человек, считающих себя членами этой бодрствующей элиты, приходится лишь пятеро действительно сверхпродуктивных»[92].

Рис. 15.2. Фактическая производительность разработчика во многих игровых проектах

Таким образом, хотя человек в кранче пытается усердно работать, довольно скоро его усилия идут прахом. В большинстве случаев продуктивность после краткого всплеска фактически опускается ниже того уровня, который был бы при обычном темпе работы (рис. 15.2).

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

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

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

Рис. 15.3. Лучший способ распределить работу проекта

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

Рис. 15.4. Вероятные усилия разработчиков по мере их приближения к основным майлстоунам производственного процесса

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

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

* * *

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

Кранч проявляется во многих формах, как правило, разрушительных. Одно из худших его проявлений – постоянный перенос даты окончания проекта. Такого рода стратегия управления проектами – предоставление большего времени на разработку, когда ясно, что не все еще сделано, – довольно естественная реакция, когда вы пытаетесь завершить проект. Проблема возникает из-за того, что члены команды просто не могут идти в ногу с графиком. Мы усердно работаем, чтобы достичь рубежа, который затем отодвигается все дальше, и приходится работать в попытках до него дойти. Если сроки снова сдвинутся, мы окажемся в ловушке истощения и переработки. Наша усталость приведет к тому, что мы будем совершать все больше ошибок и в конечном счете еще больше замедлим проект. Этот порочный круг лежит в основе многих проблем игровой индустрии.

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

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

Кранч присущ не только игровой индустрии: вы увидите его в индустрии технологий и индустрии развлечений, в других отраслях промышленности, в медицине и в правительстве. Возможно, лучший способ разрешить проблему кранча – это философски взглянуть на нашу жизнь. Чего мы хотим? Что делает нас счастливыми? Что делает нас здоровыми? Как мы можем принести пользу миру (и самим себе), не причиняя никому вреда?

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

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

Глава 16. Структура истории для гейм-дизайнеров

Повествование – это изучение изменений.

Ирвинг Белатех[93]

Я очарован взаимоотношениями игр и историй. В своей карьере я предпочитал в основном работать над сюжетными играми, такими как Uncharted и Soul Reaver. Я никогда не встречал форму повествования или пьесы, которая мне бы не понравилась, а когда я пришел в игровую индустрию в 1991 году, отчасти моя восторженность гейм-дизайном как новой формой искусства была вызвана возможностями и перспективами интерактивного повествования, от реальности The Secret of Monkey Island до фантастики голопалубы из Star Trek.

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

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

«Поэтика» Аристотеля

Греческий философ Аристотель жил с 384 по 322 год до нашей эры. Около 335 года до н. э. он написал трактат, посвященный теории драмы, под названием «Поэтика». Эта самая ранняя известная работа по теории драматургии была утеряна для западного мира более тысячи лет назад и вновь представлена в двенадцатом веке благодаря переводу испанского мусульманского философа Ибн Рушда.

В «Поэтике» Аристотель пишет, что история сначала излагает некую позицию, затем исследует ее и в конце приходит к выводу, чтобы создать «представление действия законченного и целого» с причинно-следственной связью между его частями. Проще говоря, «целое – то, что имеет начало, середину и конец»[94].

Для Аристотеля герои историй сталкиваются с какой-то проблемой, которую он характеризует как «узел». Он делит истории на две половины: завязка и развязка. На этапе завязки герой либо узнает о проблеме, либо наблюдает за ее появлением. В развязке герой пытается справиться с проблемой, что приводит к какому-то финальному результату.

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

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

Пирамида Фрейтага

В 1863 году немецкий драматург и писатель Густав Фрейтаг написал книгу под названием Die Technik des Dramas («Техника драмы»), в которой он изложил теорию драматической структуры из пяти частей. Диаграмма, сопровождающая его теорию, знакома студентам, изучающим драматургию и кино, и известна как пирамида Фрейтага (рис. 16.1).

Теория Фрейтага основана на трехчастной структуре Аристотеля, но немного дополняет ее. По Фрейтагу история состоит из пяти частей.

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

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

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

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

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

Рис. 16.1. Пирамида Фрейтага

Подобно «Поэтике» Аристотеля, пятиактная структура Фрейтага соответствует тому, как пишутся и рассказываются многие истории. Большинство пьес Шекспира разыгрываются в пяти действиях, а в своей книге Into the Woods: A Five-Act Journey into Story телевизионный продюсер и редактор сценария Джон Йорк утверждает, что пятиактное повествование полезно во всех драматических формах, включая игры.

Структура игры отражает структуру сюжета

Это внимание, которое и Аристотель, и Фрейтаг уделяют важности начала, середины и конца, послужит хорошей отправной точкой для обсуждения структуры сюжета через призму гейм-дизайна. Как отмечает Эллен Луптон в своей книге «Драматургия дизайна», все мы осознаем эту фундаментальную структуру в нашей собственной жизни, которая неизбежно имеет начало, середину и конец[95].

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

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

Истории и геймплей фрактальны

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

В своей книге Screenwriting: The Sequence Approach Пол Джозеф Гулино, ученик Франтишека Дэниела, пишет: «Типичный двухчасовой фильм состоит из эпизодов – 8–15-минутных сегментов с собственной внутренней структурой – по сути, коротких фильмов внутри крупного фильма. В значительной степени у каждого эпизода есть свой главный герой, конфликт, восходящее действие и развязка – как и у фильма в целом. Разница между эпизодом и отдельным пятнадцатиминутным фильмом заключается в том, что конфликты и проблемы, поднятые в эпизоде, разрешаются в нем лишь частично и по мере их разрешения часто открываются новые проблемы, которые, в свою очередь, становятся предметом следующих эпизодов»[96]. Трейси Фуллертон выразилась так: «Эпизод задает драматический вопрос и отвечает на него, но не обязательно его решает. Возьмет ли детектив это дело на себя? Найдет ли она какие-нибудь улики на месте преступления?»[97]

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

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

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

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

Поэтому истории фрактальны – это понятие пришло из математики и описывает структуры, части и составляющие которых самоподобны всей структуре. По мере того как действие нарастает и спадает в структуре целой истории, оно нарастает и спадает в каждом акте, эпизоде, сцене и бите (рис. 16.2). (Эта идея, вероятно, берет свое начало в модели структуры сюжета «Драматика», разработанной в 1990‑х годах Мелани Энн Филлипс и Крисом Хантли[98].)

Рис. 16.2. Фрактальная структура сюжета художественного фильма

Несложно заметить фрактальность самих игр. Мы только что пришли к выводу, что игровое задание имеет ту же структуру, что описана в пирамиде Фрейтага. Теперь вы, вероятно, можете представить себе ту же картину нарастающего и стихающего действия в каждом отдельном аспекте и части миссии: это наблюдение чем-то напоминает концепцию Джейми Гриземера о 30 секундах веселья в Halo, о которой мы говорили в главе 10.

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

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

Компоненты истории

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

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

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

Отношение конфликта к повествованию – больная тема. Писательница Урсула Ле Гуин говорила: «Модернистские руководства по писательскому мастерству часто сводят воедино историю и конфликт. Такой редукционизм в полной мере отражает культуру, которая раздувает агрессию и конкуренцию, одновременно культивируя незнание других вариантов поведения… Конфликт – это один из видов поведения. Есть и другие, не менее важные в любой человеческой жизни: отношения, приобретения, потеря, принятие, открытие, расставание, перемены»[99]. Этот список моделей поведения – подарок любому гейм-дизайнеру, стремящемуся исследовать новые границы геймплея.

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

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

В первой части истории главный герой обычно находится в статус-кво привычной обстановки обыденного мира. Затем происходит что-то, что подталкивает его к действиям, так называемый провоцирующий инцидент. Поначалу главный герой может сопротивляться, но в конце концов он отправляется в путешествие, где сталкивается с новыми или сложными ситуациями и персонажами, вступая с ними в различного рода отношения. Цель их путешествия – достичь своего желания, продиктованного внешней мотивацией. Однако по пути внутренняя мотивация будет неоднократно проверять и подстрекать личность героя, направляя путешествие в новые и интересные стороны. Рассказчик будет использовать такие приемы, как предзнаменование, чтобы подготовить нас к тому, что должно произойти, а также оставлять «ружья на стенах», чтобы вести нас по сюжету. Тут и там будут происходить поворотные события, чтобы удивить нас, и открытия, чтобы удовлетворить нас. Иногда нас будут пускать по ложному следу c помощью отвлекающих маневров или давать макгаффин, придавая сюжету импульс и целостность.

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

В этом кратком изложении структуры истории приведены термины из разных источников, и я в долгу перед моими коллегами Ирвингом Белатехом и Джеком Эппсом-младшим за многие из них. Существует много подходов к структуре истории, которые вы можете изучить и применить на практике. Пожалуй, самый известный из них – это «путь героя», представленный Джозефом Кэмпбеллом в книге «Тысячеликий герой»[100], а затем популяризированный писателем Кристофером Воглером в книге «Путешествие писателя. Мифологические структуры в литературе и кино»[101]. Путь героя – отличная сюжетная структура для начинающих гейм-дизайнеров, поскольку он легко вписывается в структуру многих наших игр, основанную на квестах. Имейте в виду, что неумелое использование пути героя может привести к шаблонным и избитым историям, изобилующим вопросами избранности и спасения мира. В умелых же руках путь героя может стать основой замечательного произведения искусства, такого как игра Journey от студии thatgamecompany.

Книга Блейка Снайдера «Спасите котика!»[102] станет хорошим руководством по структурированию историй для начинающих, а книга Джека Эппса Screenwriting Is Rewriting: The Art and Craft of Professional Revision научит вас итеративной природе хорошего письма. Вы можете и сами открыть для себя еще много отличных книг по структуре сюжета и писательскому мастерству. Чтобы ознакомиться с очень многими терминами, используемыми различными экспертами по структуре сюжета, обратитесь к книге Ингрид Сандберг Arch Plot Structure, которую вы можете найти в интернете и которая включает диаграмму, четко показывающую множество различных названий, используемых для обозначения элементов, которые я описал выше, вместе с их источниками[103].

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

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

Как улучшить историю в вашей игре

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

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

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

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

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

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

Если сомневаетесь…

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

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

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

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

* * *

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

Глава 17

Артефакт препродакшена – макродизайн игры

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

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

Разрабатываем карту полного продакшена

Я благоразумно начал с карты и подогнал под нее повествование. Метод «наоборот» чреват путаницей и ляпами…

Дж. Р. Р. Толкин, «Письма», с. 177

Толкин написал «Властелина колец», сначала разработав карту Средиземья, сеттинга своего эпического фэнтези, «тщательно выверяя расстояния»[105]. История возвращения Кольца Всевластья в Мордор во многом зависела от того, насколько быстро люди, животные, предметы и информация могут перемещаться. Продумав карту до того, как начать писать, Толкин мог быть точным в важнейшем аспекте своего рассказа – расстоянии, – что помогло ему создать сложную и высокоструктурированную историю.

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

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

Для чего нужен макродизайн

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

Концепция макродизайна игры была предложена Марком Черни в его выступлении на саммите D.I.C.E 2002 года о подходе к разработке цифровых игр, который он назвал Методом.

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

Макродизайн должен быть готов к концу этапа препродакшена. Микродизайн создается в процессе производства… Этот подход – результат одного из самых опасных заблуждений в разработке: «Чем четче вы определите свое изначальное видение игры, тем лучше»[106].

Марк критикует идею того, что нужно написать стостраничный дизайн-документ игры еще до начала непосредственной работы над ней. Он уверяет, что нам не нужен этот документ ни заранее, ни вообще. Это не более чем пустая трата ресурсов, которая заставляет нас думать, что мы знаем куда больше, чем есть на самом деле. Марк Черни говорит: «Как бы хорош ни был ваш документ, я вам гарантирую: он не понравится ни одному вашему игроку»[107].

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

Марк Черни сказал мне, что впервые идею макродизайна применили в разработке Crash Bandicoot 2: Cortex Strikes Back. Лично я познакомился с макродизайном игры, когда изучал один такой для игры Jak 3, проекта, над которым я работал до самого его конца. Затем, будучи ведущим дизайнером, я развил идею прописывать макродизайн игры для Jak X: Combat Racing и всех трех игр Uncharted, над которыми я работал. Я считаю, что качество игр от Naughty Dog, Insomniac Games и других студий, которые используют эту технику, ясно доказывает полезность макродизайна[108].

Макродизайн и цели проекта

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

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

Две части макродизайна

В своем выступлении на саммите D.I.C.E. Марк Черни делит макродизайн на две части. Первая часть представляет собой обзор гейм-дизайна, в котором кратко излагаются основные компоненты игры: основные элементы геймплея, наиболее важные особенности игры, механики и сюжет.

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

Обзор гейм-дизайна

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

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

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

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

Таблица макродизайна

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

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

В этой таблице мы должны описать (словами Марка Черни), «в каких местах какой геймплей». Мы также должны принять к сведению, что «в эту таблицу должна быть занесена каждая задуманная вами механика». Наша цель при создании макродизайна заключается в «познании планируемого разнообразия игры, ее скоупа и высокоуровневой структуры»[109].

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

В таблице макродизайна Uncharted 2: Among Thieves было порядка семидесяти строк, описывающих структуру игры, причем на момент выхода игры через полтора года таблица была по-прежнему актуальна с точностью до 5 или 10 %. Макродизайн куда конкретнее любого талмуда по дизайну, когда-либо написанного на этапе препродакшена. В нем закреплены самые важные детали, но с достаточным уровнем абстракции, чтобы вы не тратили время на разработку тех элементов, которые потом будут изменены.

Строки и столбцы в таблице макродизайна

Давайте подробнее разберем таблицу макродизайна. Начнем с примера, который приводит Марк Черни в своем выступлении на саммите D.I.C.E.

Каждая строка описывает один из уровней. Соответствующая информация меняется от игры к игре, но обычно это расположение уровня в мире игры, указание 3D или 2D этот уровень, какой «экзотичный» в нем геймплей, что игрок должен был собрать, чтобы попасть на уровень, и, наконец, какие предметы можно собрать на уровне[110].

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

• окружение этой части игры;

• объекты и персонажей в окружении;

• тип геймплея на данном участке игры;

• что игрок должен или может сделать.

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

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

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

Шаблон таблицы макродизайна

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

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

Рис. 17.1. Шаблон таблицы макродизайна

Локация / Название эпизода

Крайний левый столбец описывает то, где происходят события этой строки. Это может быть «на дне старого колодца» или «внутри воздушного шлюза». Я могу представить себе игру без локаций или где события геймплея строго не привязаны к локациям, поэтому я предложил альтернативное название столбца – «Название эпизода».

Время суток / Погода/Настроение

Рассвет, утро, полдень, сумерки или ночь? Прекрасная, душная или неспокойная? Каково настроение этой строки? Этот столбец полезен арт-директорам, создающим «цветовые сценарии» и планирующим цветовую палитру и передачу настроения в игре.

Краткое описание событий

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

Механики персонажа

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

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

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

Встречаемые персонажи (включая врагов)

С какими персонажами игрок столкнется в этой части игры? Помните: враги тоже персонажи! Может оказаться полезным (как это было для нас при разработке Uncharted) разделить дружественных или нейтральных неигровых персонажей и врагов на две или три разные колонки.

Встречаемые предметы

Какие предметы можно найти в этой части игры? Двери, которые можно отпереть? Ключи и переключатели? Бьющиеся банки с монетками внутри? Платформы для прыжков? Таинственные свитки? Телефоны, воспроизводящие голосовую почту? Головоломки, бонусы, оружие, броня – здесь должны быть перечислены зелья и безделушки, а также любые предметы, которые передают повествование, такие как письма, книги или аудиозаписи.

Прочие ассеты

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

Заметки по аудио

Часто гейм-дизайнеры задумываются о звуковом оформлении лишь в последнюю очередь. Это большая ошибка – звуковой дизайн надо разрабатывать с самого начала. Эта колонка подтолкнет вас к определению звуковых особенностей игры на ее макроуровне. Есть ли в игре музыка или просто окружающие звуки? Будет ли создание какого-либо из звуковых эффектов особенно сложным или трудоемким? Будет ли саундтрек адаптивным (меняться в зависимости от событий геймплея)?

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

Заметки по VFX

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

Цель игрока, цель дизайна и эмоциональный бит

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

Цель игрока

Когда кто-то играет в игру, он ставит перед собой цели, основываясь на том, что ему говорит игра, что он хочет сделать, что он понимает в том, как работает игра, и что он испытывал в других подобных играх. Этот процесс самостоятельной постановки целей описывается Михаем Чиксентмихайи как «автотелизм», и он связывает это с настойчивостью, любопытством, позитивностью, открытостью опыту и готовностью учиться[112]. (Чиксентмихайи – психолог, хорошо известный своей концепцией «потока», высокосфокусированного психического состояния, которое встречается как у спортсменов и хирургов, так и у любителей игр.)

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

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

Анна Антропи и Наоми Кларк дают нам отличный пример этого, когда обсуждают уровень «World 1–1» Super Mario Bros. в A Game Design Vocabulary: Exploring the Foundational Principles behind Good Game Design. Говоря о том, как хороший гейм-дизайн может научить игровой механике и элементам просто через игру, они заявляют:

Super Mario Bros. 1985 года не нуждался в обучении. В нем использовался дизайн, в основе которого лежала визуальная коммуникация с игроком: наблюдая за тем, как игроки играют в игру, дизайнеры ее меняли и снова проверяли – чтобы научить игрока основам игры. Самые первые уровни учат всему, что нужно знать: Марио начинает свой путь с левого конца экрана, лицом вправо. Парящие, светящиеся предметы обещают награду, а медленные, но угрожающие монстры, противостоящие Марио, движутся игроку навстречу, побуждая того прыгнуть[113].

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

Разработчики могут ставить четкие цели перед своими игроками, написав в текстовом пузырьке в начале уровня: «Соберите сто звезд и доберитесь до финиша до того, как истечет время!» Или же можно позволить игроку самому разобраться, что ему нужно сделать, чтобы пройти дальше. В этом случае нам надо решить, как (и в какой степени) мы объясним игроку цели игры.

Цель дизайна

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

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

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

Итак, в разделе «Цель дизайна» напишите, чего вы как дизайнер хотите достичь в этой части игры. Во время плейтестов вы можете отследить, насколько успешно вы справляетесь с поставленной задачей. Научили ли вы игрока новой механике, которую хотели ввести? Проникся ли игрок симпатией к дружелюбному NPC? Поставил ли он перед собой цель, которую вы от него ожидали?

Эмоциональный бит

Каждая отдельная часть игры порождает у игрока субъективный опыт. Вспомните, как мы ставили общую цель для нашей игры в конце этапа идеации. В главе 7 мы говорили об опыте в терминах мышления, памяти, воображения, воли, восприятия и эмоций, уделяя особое внимание эмоциям. Теперь же мы еще больше сосредоточимся на эмоциях в определении «эмоционального бита» каждой части нашей игры. Под эмоциональным битом можно понимать последовательность целевых опытов меньшего уровня.

Каждая часть игры формирует эмоциональный и интеллектуальный опыт игрока, пока он эту часть проходит. Обычно лучше всего сосредоточиться на эмоциях, вот почему эта колонка таблицы макродизайна называется «Эмоциональный бит». Для игр с сюжетом – или любым повествовательным элементом – эмоции игрока при прохождения критически важны. Каждый отдельный момент игры может заставить игрока чувствовать себя счастливым или взволнованным, одиноким или грустным, подойдет любое состояние, представленное на «колесе эмоций» доктора Роберта Плутчика (рис. 7.2).

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

Уметь встраивать последовательности эмоциональных переживаний – ключевой навык для любого рассказчика и гейм-дизайнеров. Во время создания Uncharted 2 группа из Naughty Dog посетила один из семинаров Мэттью Луна, писателя и бывшего сценариста Pixar, чтобы научиться лучше рассказывать истории. В своей книге The Best Story Wins: How to Leverage Hollywood Storytelling in Business and Beyond Мэттью описывает, как контрастные жизнерадостные эпизоды, продуцирующие дофамин, и спокойные события, высвобождающие окситоцин, смешиваются в мощный эмоциональный коктейль. Он приводит в пример начало «Вверх» Pixar, который трогает многих зрителей до слез в первые пять минут фильма. Мэттью показывает, что начало фильма настолько трогательно отчасти из-за стремительного чередования счастливых и грустных моментов. Он говорит: «Чередование таких грустных и счастливых моментов служит американскими горками для сердец и умов людей. Взлеты и падения, напряжение и успокоение – все это заставляет аудиторию с нетерпением следить за развитием истории»[114]. Точно так же подобные взлеты и падения геймплея удерживают внимание игрока.

Психология и личный опыт говорят нам, что самые сильные эмоциональные переживания накапливаются со временем. Подумайте о глубокой любви, которую мы испытываем к старым друзьям, родителям или давнему партнеру. Подумайте о том глубоком горе, которое мы бы испытали, потеряв одного из них. Жизнь без конца подбрасывает нам сильные эмоциональные переживания, но эмоциональный всплеск в конце отличного фильма или игры не происходит случайно: создатели фильма или дизайнеры вели нас к нему бит за битом. В главе 16 превосходной книги Джесси Шелла «Геймдизайн. Как создать игру, в которую будут играть все» описывается, как дизайнеры, художники и артисты могут использовать «кривые интереса», чтобы распланировать захватывающий опыт[115].

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

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

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

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

Пример взаимосвязи между целью игрока, целью дизайна и эмоциональным битом

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

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

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

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

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

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

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

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

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

Преимущества макродизайна игры

В написании макродизайна вместо длинного ГДД два главных преимущества: передать идеи гейм-дизайна и помочь распланировать продакшен проекта.

Макродизайн игры как коммуникация

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

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

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

Макродизайн можно сделать еще более ясным и понятным для чтения с помощью блок-схем, которые описаны директором и дизайнером студии Insomniac Games Брайаном Альгайером в книге Directing Video Games: 101 Tips for Creative Leaders[116]. В своем посте в блоге, озаглавленном Provide Structure: How Macro Documents Keep a Project on Course, Брайан использует примеры из дизайна игры Ratchet & Clank Future: A Crack in Time, чтобы проиллюстрировать методы, которые дополняют таблицы макродизайна. Он рассказывает, как можно использовать концепт-арт и скриншоты для разработки «визуального макродизайна» и как его можно использовать для создания цветного сценария, «изображения, используемого для отображения цветовых палитр, настроения и эмоций на протяжении всей истории»[117].

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

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

Представление информации о дизайне игры в макроформе облегчает понимание не только содержания, но и планируемой последовательности игры. Как говорит Марк Черни, макродизайн упрощает нам дальнейшее планирование:

Весь геймплей определенного типа сгруппирован в конце или в начале? Все ли способности и движения вводятся плавно и последовательно? Правильно ли распределены требования для перехода на следующие уровни?[118]

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

Макродизайн игры как вспомогательное средство при планировании

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

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

Макродизайн игры высечен в камне

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

Макродизайн игры – отличный способ борьбы со скоуп-крипом проекта, извечной проблемы индустрии игр, когда разработчики приходят в восторг от новых идей и добавляют их в дизайн игры прямо во время продакшена. Подобное разрастание проекта – и его разновидность фичекрип[119] – происходит неконтролируемым образом и иногда может помешать его завершению. Мы снова рассмотрим фичекрип в главе 28.

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

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

Как бы хорошо ни прошел препродакшен, вы все равно чему-то научитесь в самом продакшене. Определенные техники, расположение камер, игровые режимы могут работать лучше, чем другие. Таким образом, до тех пор, пока вы не нарушаете свой макродизайн, вы можете менять и совершенствовать состояние игры во время продакшена с уверенностью, что вы не нарушите непрерывность и последовательность создаваемого игрой опыта[120].

Хотя ничего не следует добавлять в макродизайн после окончания препродакшена, за исключением особых обстоятельств, вы можете что-то убирать или менять местами, не сильно при этом влияя на график производства. Просто изменив порядок элементов в вашей игре, вы можете найти творческие решения или способы улучшить историю. In medias res – эпизод с крушением поезда, открывающий Uncharted 2: Among Thieves, который хронологически происходит в середине событий игры, был перенесен в начало лишь спустя какое-то время после окончания этапа препродакшена[121].

Макродизайн – библия гейм-дизайна?

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

Кроме того, будьте осторожны, чтобы не перепутать макродизайн игры с «руководством для сценаристов» или «библией истории» (англ. story bible), которые используют в мире кино, телевидения, комиксов и художественной литературы. Это большие документы по построению мира, излагающие канон, лор и общий тон крупной вымышленной вселенной. Известный пример – Star Trek: The Next Generation Writers’ / Directors’ Guide («Звездный путь. Руководство для писателей/режиссеров следующего поколения»), которое написал Джин Родденберри, готовясь к созданию сериала[122].

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

* * *

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

Глава 18

Составляем таблицу макродизайна

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

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

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

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

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

Во-первых, мы показали таблицу ведущим специалистам направлений и членам команды Naughty Dog, чтобы получить их отзывы. Эти люди намеревались воплотить наш грандиозный план в жизнь, а потому было важно, чтобы они могли внести вклад и в разработку макродизайна. Затем, после ряда необходимых изменений, мы отправили таблицу нашим продюсерам и исполнительным продюсерам в Sony Interactive Entertainment (материнскую компанию Naughty Dog), в рамках майлстоуна «окончание препродакшена».

Рис. 18.1. Пробковая доска с карточками для составления макродизайна Uncharted 2: Among Thieves. Обратите внимание, что Хлою Фрейзер на этом этапе разработки звали Джейн. Права на изображение: © 2009 SIE LLC/UNCHARTED 2: Among Thieves™. Создано и разработано компанией Naughty Dog LLC

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

Гранулирование таблицы макродизайна

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

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

Например, каждая строка в таблице макродизайна для Uncharted 2 и Uncharted 3 представляет примерно десять – пятнадцать минут геймплея. Но на моих занятиях, где студенты создают десятиминутную игру, каждая строка таблицы представляет от тридцати секунд до одной минуты геймплея. Это упражнение по дизайну приучает студентов к чуть более точному планированию, чем нужно при разработке более крупной и длинной игры.

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

Делайте все возможное, чтобы таблица макродизайна была краткой. Брайан Альгайер советует следующее: «Макродизайн должен оставаться ознакомительным, более подробную информацию лучше оставить для сопроводительных документов, таких как сюжетные сценарии и дизайн-документы. Члены команды должны иметь возможность легко и быстро ориентироваться в макродизайне, понимая, как структурированы элементы игры»[123].

Упорядочивание таблицы макродизайна

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

Упорядочивание геймплея

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

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

Отличный пример сетапа – самое начало игры Super Mario Bros. World 1–1, показанное на рис. 18.3.

Рис. 18.2. Часть таблицы макродизайна для Uncharted 2: Among Thieves (см. приложение C). Права на изображение: © 2009 SITE LLC/UNCHARTED 2: Among Thieves™. Создано и разработано компанией Naughty Dog LLC

Такое расположение элементов геймплея создает игровую ситуацию, бросающую вызов без особой опасности. Как описывают Анна Антропи и Наоми Кларк в книге A Game Design Vocabulary, этот сетап Super Mario Bros. обучает игрока естественно, в свободной форме и весело[124].

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

Последовательными сетапами дизайнеры постепенно увеличивают или снижают сложность геймплея, создавая так называемую восходящую пилу сложности, регулярно используемую гейм-дизайнерами и описанную Эрнестом Адамсом в книге Fundamentals of Game Design. «Начинайте каждый уровень игры со сложностью несколько меньшей, чем та, на которой закончился предыдущий, и постепенно увеличивайте сложность в течение каждого уровня… Эта пилообразная форма придает игре хороший темп»[125].

Рис. 18.3. Сетап в начале Super Mario Bros. World 1–1. Права на изображение: Nintendo

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

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

Упорядочивание нарратива

Упорядочивание игры можно начать и с сюжета. В своем выступлении на саммите D.I.C.E. Марк Черни сказал о макродизайне следующее: «По его итогам вы должны получить довольно солидную историю, которую вы не станете менять»[126]. Идея, что макродизайн важен для планирования нарратива игры, приобрела в Naughty Dog особое значение, так как в наших играх истории становились все сложнее и эмоциональнее.

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

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

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

Нарратив в игре, в которой история подается наименее традиционным образом, во многом происходит с помощью описания геймплея. В таком случае чтение таблицы макродизайна будет сродни прочтению сюжета игры, так как он будет как бы подразумеваться в геймплее. Большая часть повествования игры будет содержаться в столбцах «Цель игрока», «Цель дизайна» и «Эмоциональный бит».

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

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

Нарративных дизайнеров, таких как я, часто спрашивают: «Что на первом месте: геймплей или история?» Что угодно из них может быть на первом месте, но важно, чтобы фрагменты истории хорошо сочетались с сопровождающим их геймплеем, и наоборот. Взаимосвязь геймплея и сюжета мне представляются двумя детьми, играющими в чехарду: первый перепрыгивает через второго, затем второй через первого, и так далее, и так далее.

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

Упорядочивание мест

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

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

Создание мест, в которых разворачиваются действия вашей игры, скорее всего, будет одной из самых трудоемких (и следовательно, дорогостоящих) работ, которые предстоят вашей команде. Таблица макродизайна поможет спланировать, какие локации вам потребуются в игре, и, следовательно, контролировать содержание проекта. Подумайте также о том, как вы можете повторно использовать одно и то же место для разных эпизодов игры, чтобы как можно эффективнее использовать столь дорогостоящие объекты окружения и прийти к наилучшему творческому решению. Как говорит Трейси Фуллертон, «сменить освещение в уже существующей локации в кульминационный момент на самом деле может оказаться куда более важным решением, чем создать совершенно новую территорию»[127].

Контраст и непрерывность

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

Следуйте принципу расслабленного исследования с некоторыми интенсивными действиями. Создайте симпатичного или забавного персонажа с драматическим прошлым. Перемежайте открытые пространства с лабиринтами узких проходов. Эти контрасты создают модуляцию опыта игрока, которая ощущается как путешествие, очень интересное и со смыслом. Схема «больше – меньше – больше», «спокойно – напряженно – спокойно», «активно – пассивно» – отличная основа для упорядочения событий игры. Идея контраста частично исходит от Брюса Блока в его книге The Visual Story («Визуальное повествование»), которую мы использовали для объединения геймплея и сюжета в серии игр Uncharted[128].

Завершение макродизайна

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

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

Микродизайн

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

Создание микродизайна обычно делается так: берется одна строка из макродизайна и расширяется подробными сведениями о планировке уровней, размещении объектов, описаниями врагов и их поведения, дизайном головоломок и повествовательными механизмами. В 1990‑х и 2000‑х годах в командах, где я работал, создавались подробные карты уровня на бумажном носителе или в Adobe Illustrator. Но сейчас обычно делается быстрый набросок уровня на доске, затем он строится в виде блокмеша (вайтбоксов/грэйбоксов/блокаутов) напрямую в инструментах с использованием плейсхолдеров для элементов геймплея. При необходимости можно сделать более подробную вспомогательную документацию, обычно в виде блок-схем и списков.

Микродизайн обычно создается «прямо на ходу» и только для того, над чем сейчас идет работа, чтобы не тратить время на разработку деталей, которые позже будут изменены. Что значит «прямо на ходу» для вашей команды, решать вам. Как правило, мы стараемся продвинуться достаточно далеко в нашем микродизайне, чтобы не препятствовать работе других частей нашей команды, особенно если работа с микродизайном по какой-то причине задерживается.

Нелинейные игры и макродизайн

Давайте обсудим составление таблицы макродизайна для нелинейной игры. Очевидно, что двумерное пространство электронной таблицы хорошо подходит для планирования линейных игр, которые протекают в односторонней последовательности от A до B, а затем от В до C. Однако макродизайн строится и для игр с разветвленной структурой, где действия могут идти в порядке от А до В или до С, или игр с открытым миром, которые могут развиваться в любом порядке, начиная с B, C или A.

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

Для игр с разветвленной сюжетной линией (где действия идут от A до B или C), проще всего перечислить различные сюжетные ветви одну под другой, указав, как они связаны друг с другом. Содержание каждой ветви можно описать так же, как и для линейной игры.

Для игры с открытым миром, где вы можете проходить уровни A, B, и C в любом порядке, задача по составлению таблицы макродизайна усложняется, но обычно все составляющие игры можно поделить на логические группы. Один из подходов состоит в том, чтобы разбить таблицу макродизайна на две части. Первая часть содержит список игровых механик и объектов, с которыми они взаимодействуют. Вторая часть содержит список мест и объектов, находящихся в этих местах. Сопоставление двух частей таблицы отразит то, как мир открывается игроку по мере того, как персонаж игрока приобретает определенные способности.

Планирование холистических игр

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

Написание таблицы макродизайна для холистической игры представляет собой серьезную проблему, потому что во время препродакшена куда больше внимания надо уделять макродизайну игры. Как говорит Марк Черни, «если построение более поздних уровней сильно зависит от навыков, полученных на более ранних уровнях, – например, вы изучаете механику скольжения или как использовать взрывчатые вещества, – разработчикам потребуется много информации, чтобы создать уровни или области, которые должным образом взаимосвязаны»[129].

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

Примеры макродизайна

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

* * *

Надеюсь, я продал вам идею макродизайна. Это не самая роскошная или невероятная концепция гейм-дизайна, но она практична и прагматична. Многие часто интересуются, в чем секрет Naughty Dog, отчего игры студии выходят такими хорошими. Одна из составляющих успеха не так уж и секретна: это всего лишь макродизайн.

Составление хорошего макродизайна требует размышлений, упорной работы и опыта. Ближе к концу моего пребывания в Naughty Dog часть команды, работающая над игрой The Last of Us, заперлась в конференц-зале практически на восемь месяцев и в конце концов вернулась с пробковой доской, полной карточек, как показано на рис. 18.4. Если вы знакомы с The Last of Us, вы увидите на этом изображении ее макроструктуру. У команды не было возможности представить каждую мельчайшую деталь, которая в итоге вошла в игру, но они смогли продумать последовательность эпизодов, которая сделала прохождение их игры настолько впечатляющим.

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

Рис. 18.4. Макроплан игры The Last of Us от Naughty Dog на выставке видеоигр в музее Виктории и Альберта, Лондон. Права на изображение: The Last of Us™ © 2013, 2014 Sony Interactive Entertainment LLC. The Last of Us является торговой маркой Sony Interactive Entertainment LLC. Создано и разработано компанией Naughty Dog LLC

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

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

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

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

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

Глава 19

Планирование

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

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

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

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

Простое планирование

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

Сколько у нас человеко-часов, чтобы создать игру

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

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

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

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

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

К = Количество членов команды

Ч = Человеко-часы, затраченные каждым членом команды в среднем в неделю

Н = Количество недель между окончанием препродакшена и окончанием продакшена

Чтобы рассчитать В (время), количество человеко-часов, которое доступно вашему проекту для работы с конца препродакшена до конца продакшена, используйте эту формулу:

В = К × Ч × Н

Итак, в команде из двух человек (К = 2), каждый из которых решает работать над проектом по десять часов в неделю (Ч = 10), со сроком в шесть недель между окончанием препродакшена и окончанием продакшена (Н = 6) мы получим:

В = 2 × 10 × 6 = 120 человеко-часов

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

В = (8 + 10) × 6 = 108 человеко-часов

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

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

Простейший план

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

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

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

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

Простой план для каждой задачи

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

Добавьте в электронную таблицу еще четыре столбца, как показано на рис. 19.1. Над списком задач добавьте заголовок «Задача». В соседнем столбце напишите «Приоритет». Рядом – «Расчетное время». А затем «Ответственные члены команды».

Приоритет

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

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

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

Многим гейм-дизайнерам очень трудно отнести какую-либо из своих задач не к приоритету первого уровня. Представление о будущей игре соединяется в нашем воображении с некой идеальной кристаллической целостностью – все ее части кажутся одинаково важными; ни одна из них не может существовать без других. Как мы можем присвоить какой-то задаче приоритет второго или третьего уровня?

Рис. 19.1. Начало простого плана

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

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

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

(Вы можете использовать функцию СУММЕСЛИ в электронной таблице, чтобы определить, сколько часов потребует каждая из задач в приоритетах. Обратитесь к инструкциям по работе с электронной таблицей, чтобы узнать, как это сделать. Вы можете с этим разобраться всего за несколько минут, а СУММЕСЛИ – простая и полезная функция для изучения.)

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

Расчетное время

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

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

Однако выручить может один простой и умный трюк: ограничьтесь в столбике с расчетным временем числами 1, 2, 4 и 8. Вы можете уделить заданию один час, два часа, четыре часа или восемь часов. Никаких полутора или семи часов. Только 1, 2, 4 или 8.

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

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

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

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

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

Ограничения в 1, 2, 4, 8 часов помогут точно определить расчетное время на каждое задание, а также сбалансируют детальность списка: группируя или разбивая задания таким методом, мы перечисляем не слишком много, не слишком мало задач.

Ответственные члены команды

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

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

Определяем скоуп проекта

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

Теперь мы можем использовать функцию СУММ в электронной таблице, чтобы суммировать все время в колонке «Расчетное время» и рассчитать, сколько работы нам предстоит выполнить на этапе продакшена. Давайте назовем это число Р (работа).

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

Если Р > В, мы выходим за сроки проекта!

Если Р <= В, содержание проекта под контролем.

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

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

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

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

Если вы планируете реализовать свой проект, работая дольше, имейте в виду, что количество недель подряд, в течение которых люди могут работать сверхурочно, очень ограниченно, и это быстро приводит к снижению производительности и выгоранию. Как говорит вооруженная исследованиями Сара Грин Кармайкл в своей статье для Harvard Business Review, которую я упоминал в главе 15, «Даже если вы любите свою работу и добровольно засиживаетесь допоздна, усталый человек все равно делает больше ошибок… Переусердствуете – упустите из виду основную картину. Исследования показали, что при выгорании человек начинает путаться в пустяках… Словом, повесть о переработке – это повесть о снижающейся отдаче: продолжайте пришпоривать себя, и будете все хуже выполнять все более простые задания»[130].

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

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

Отслеживание прогресса в простом плане

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

Рис. 19.2. Вычеркивание задач из списка

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

Но отслеживание вашего прогресса с помощью такого простого метода может быть рискованным. В какой-то момент все пойдет лучше, чем ожидалось, и вы будете опережать график. В другие недели все будет идти медленно, и вы будете отставать. Разве не было бы здорово, если бы у вас был инструмент, который помог бы определить, впереди вы или отстаете? Хорошая новость: такой инструмент есть, и он называется диаграммой сгорания задач (англ. Burndown Chart).

Диаграмма сгорания задач

Кен Швабер – разработчик программного обеспечения и продакт-менеджер, который участвовал в создании платформы Agile-разработки Scrum. Кен изобрел диаграмму сгорания задач в качестве инструмента планирования, помогающего командам Scrum прогнозировать ход проектов, и впервые описал ее на своем веб-сайте в 2000 году[131].

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

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

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

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

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

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

В диаграмме сгорания задач также настроена планируемая дата начала спринта. В примере на рис. 19.3 спринт должен начаться 20.07 (20 июля – вы можете увидеть эту дату в восьмой строке сверху). На этой диаграмме планируется двухнедельный спринт, с 20 июля по 2 августа.

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

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

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

Рис. 19.3. Пример электронной таблицы диаграммы сгорания задач. Авторы изображения: Джереми Гибсон Бонд, Ричард Лемаршан, Питер Бринсон и Аарон Чейни

Инфографика

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

Рис. 19.4. Пример инфографики диаграммы сгорания задач. Авторы изображения: Джереми Гибсон Бонд, Ричард Лемаршан, Питер Бринсон и Аарон Чейни

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

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

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

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

Рис. 19.5. Пример инфографики диаграммы сгорания задач с комментариями. Авторы изображения: Джереми Гибсон Бонд, Ричард Лемаршан, Питер Бринсон и Аарон Чейни

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

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

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

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

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

Рис. 19.6. Та же инфографика диаграммы сгорания задач через несколько дней. Авторы изображения: Джереми Гибсон Бонд, Ричард Лемаршан, Питер Бринсон и Аарон Чейни

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

Решаем, что можно убрать

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

Однако не каждую низкоприоритетную задачу можно запросто выкинуть. Одни задачи удалить будет куда проще, нежели другие. Некоторые относительно низкоприоритетные задачи на самом деле могут быть прочно закреплены в дизайне игры благодаря их взаимосвязи с другими ее частями. Марк Черни недавно напомнил мне: «Здесь важно знать, какие части можно удалить, а какие нельзя. Если какая-то локация необходима для развития повествования или персонажа, ее нельзя убрать… поэтому очень важно постоянно проверять содержание проекта и корректировать дизайн со знанием того, что необходимо сохранить. Таким образом, вы сможете вносить коррективы на поздних стадиях разработки, не вредя игре». У каждого типа игр есть свои критерии относительно того, что можно легко вырезать, а что должно остаться, и по мере развития ваших навыков в гейм-дизайне вы научитесь отличать одно от другого.

Изменение планов в диаграмме сгорания задач

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

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

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

Большое спасибо Джереми Гибсону Бонду, разработавшему оригинальную диаграмму сгорания задач, из которой взяты эти примеры, и научившему меня ею пользоваться. Вы можете найти более подробную информацию об использовании диаграмм сгорания задач в его превосходной книге «Unity и C#. Геймдев от идеи до реализации»[132]. (Кстати, я написал предисловие!)

Диаграммы сгорания задач создают атмосферу доверия и уважения

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

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

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

* * *

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

Как только вы освоите базу, описанную в этой главе, вам предстоит узнать еще больше о планировании проекта цифровой игры. Профессиональные продюсеры в больших командах часто используют сложные системы планирования, и вы, возможно, захотите узнать о диаграммах Ганта, которые используются для отслеживания зависимостей между задачами. Вы можете найти передовые идеи о планировании проектов в таких книгах, как Agile Game Development: Build, Play, Repeat Клинтона Кита и The Game Production Toolbox Хетер Максуэлл Чандлер.

Вы также можете ознакомиться с инструментами планирования, входящими в состав программных пакетов по управлению проектами, таких как Asana, Basecamp, HacknPlan, Jira Software, Monday и Trello. Мередит Холл обсуждает эти инструменты и многое другое в своей статье Choosing a Project Management Tool for Game Development[133] для Gamasutra. Вы также можете найти недорогие или бесплатные инструменты управления проектами в интернете, например Top 7 Open Source Project Management Tools for Agile Teams, перечисленные на opensource.com[134].

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

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

Глава 20

Обзор майлстоунов

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

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

Когда проводить обзор майлстоуна

В процессе разработки игр обзоры проводятся на следующих этапах:

• окончание препродакшена;

• майлстоун альфа-версии;

• майлстоун бета-версии.

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

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

Внутренние и внешние обзоры майлстоуна

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

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

Проведение обзора майлстоуна

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

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

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

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

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

1. Разработчики кратко представляют свою игру и подводят итог того, на каком этапе проекта они сейчас находятся.

2. Представляется демоверсия игры или ее плейтест перед обзорной группой.

3. Процесс комментирования начинает старший член обзорной группы.

4. Затем подключаются другие члены обзорной группы и делятся своими мнениями. Между ними может завязаться оживленная беседа.

5. Когда время, отведенное для обзора, истекает, разработчики игры благодарят группу за отзывы.

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

Давайте внимательнее рассмотрим этот процесс.

1. Разработчики кратко представляют свою игру и подводят итог того, на каком этапе проекта они сейчас находятся.

1. Команда, как правило, представляет свою игру в виде презентации.

2. Представьте проект под его текущим названием. Если это только рабочее название, сообщите об этом.

3. Члены команды описывают, кого они считают аудиторией игры. Можно использовать простое позиционирующее утверждение, с которым мы работали в главе 7: «Возможная аудитория нашей игры – это…»

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

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

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

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

2. Представляется демоверсия игры или ее плейтест перед обзорной группой.

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

2. Часто лучше демонстрировать игру, когда она находится в относительно раннем состоянии, с уже известными проблемами, о которые будут спотыкаться новые игроки. Также лучше продемонстрировать игру, когда есть уже много контента, с которым захочет ознакомиться обзорная группа.

3. Иногда в игре могут быть неожиданные повороты или финал, которые команда не захочет раскрывать, опасаясь «испортить» впечатление. В то время как конечная аудитория игроков должна быть защищена от спойлеров, обзорной группе нужно быть полностью в курсе структуры игры: они смогут помочь, проанализировав увиденное.

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

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

3. Процесс комментирования начинает старший член обзорной группы.

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

2. Это отличная возможность использовать технику сэндвича (глава 6) и «Мне понравилось, мне бы хотелось, что, если?..» (глава 12), чтобы установить доверительную атмосферу, полную уважения к работе дизайнеров, и приступить к коллегиальной конструктивной критике.

3. Комментарий старшего представителя обзорной группы должен быть относительно кратким и излагать основные проблемы игры. Цель состоит в том, чтобы как можно быстрее открыть тему обсуждения и подискутировать с другими членами обзорной группы.

4. Затем подключаются другие члены обзорной группы и делятся своими мнениями. Между ними может завязаться оживленная беседа.

1. Члены обзорной группы могут либо начать говорить спонтанно, либо поднять руку, чтобы их пригласила игровая команда или тот, кто ведет собрание.

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

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

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

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

5. Когда время, отведенное для обзора, истекает, разработчики игры благодарят группу за отзывы.

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

2. К тому же это станет хорошим заделом на дальнейшее сотрудничество с обзорной группой.

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

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

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

3. Количество времени, которое мы тратим на просмотр каждой игры, обычно увеличивается по мере продвижения разработки.

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

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

Мозговой трест Pixar

Этот процесс или его вариации хорошо подойдут для обсуждения большинства проектов. Отчасти он вдохновлен Мозговым трестом (англ. Braintrust), описанным Эдом Кэтмеллом и Эми Уоллес в книге «Корпорация гениев». Вариации этого метода можно найти в творческих сообществах по всему миру[135].

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

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

В «Корпорации гениев» говорится, что наиболее важная характеристика Мозгового треста – «способность анализировать эмоциональные биты фильма так, чтобы никто из участников сам не поддавался эмоциям и не занимал оборонительную позицию»[136].

Благодаря самой структуре Мозгового треста, боль от необходимости внесения изменений и найденных недостатков сведена к минимуму. Режиссеру ни к чему занимать оборонительную позицию, потому что никто на него не давит и не говорит ему, что делать. Не режиссер, а фильм находится под микроскопом. Вы – это не ваша идея, и если вы слишком тесно отождествляете себя со своими идеями, то вас будет обижать любое замечание. Чтобы создать здоровую систему обратной связи, исключите из уравнения борьбу за власть – другими словами, вы должны сосредоточиться на проблеме, а не на человеке[137].

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

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

Что делает замечание полезным

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

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

Прямота

Во-первых, замечание должно быть прямым. Оно должно честно давать полезную информацию. Техника сэндвича и «Мне понравилось, мне бы хотелось, что, если?..» – отличные приемы для того, чтобы сформулировать замечание в доброй и уважительной манере, но не ходите вокруг да около: говорите то, что должны сказать.

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

Я все еще хотел быть прямым – говорить свою правду, как я ее вижу, прямолинейно – и со временем нашел способы оставаться честным: тщательно подбирать слова, быть сострадательным ко всем участникам и выбирать подходящий момент. Иногда лучше поговорить с кем-то наедине, например на щекотливую тему. «Корпорация гениев» говорит об этом в терминах «искренности»[138].

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

Конструктивная и своевременная критика

Чтобы замечание было полезным, оно должно быть одновременно конструктивным и своевременным. В «Корпорации гениев» очень емко излагаются некоторые мысли по этому поводу:

В хорошем замечании говорится о том, что не так, чего не хватает, что непонятно, что не имеет смысла. Хорошее замечание предлагается своевременно – пока не слишком поздно устранить проблему. Хорошее замечание не предъявляет требований; оно даже не должно включать предполагаемое решение. Но если оно все же дается, оно предлагается только в качестве иллюстрации потенциального, а не обязательного решения. Но что самое важное, хорошее замечание должно обладать конкретикой. «Я чуть не помер от скуки» – плохое замечание[139].

В этом коротком абзаце заключено много мудрости. Давайте ее разложим по полочкам.

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

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

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

«Хорошее замечание не предъявляет требований; оно даже не должно включать предполагаемое решение. Но если оно все же дается, оно предлагается только в качестве иллюстрации потенциального, а не обязательного решения». Некоторые люди думают, что для того, чтобы критика была конструктивной, она должна предлагать решение проблемы. Но иногда достаточно ее просто определить. У обзорных групп Мозгового Треста Pixar нет полномочий указывать, что кому делать, и именно в этом «Корпорация гениев» видит его сильнейшую сторону. Творческим людям всех мастей куда полезнее понять, что, по мнению обзорной группы, не работает в их проекте. Это открывает пространство для поиска решения проблемы, в котором мы можем обсуждать возможные пути развития дизайна.

«Но что самое важное, хорошее замечание должно обладать конкретикой. “Я чуть не помер от скуки” – плохое замечание». Я знаю этот принцип со времен работы в Naughty Dog, где мы всегда старались, чтобы наши отзывы были сосредоточены на том, что мы видели на экране, слышали через динамики и чувствовали через контроллер в наших руках. Делать замечания конкретными и четкими, избегать абстракций или обобщений и всегда критиковать только дизайн игры, а не дизайнера – самый конструктивный способ продвинуть разговор о гейм-дизайне.

В «Корпорации гениев» подводят итог хорошим замечаниям и конструктивной критике, цитируя режиссера Эндрю Стэнтона:

Есть разница между критикой и конструктивной критикой. В последнем случае вы одновременно созидаете и критикуете. Вы строите, разрушая, создаете новые пути работы с тем, что вы только что разорвали на части. Это само по себе форма искусства. Мне всегда казалось, что замечания, которые вы даете, должны вдохновлять получателя – например: «Что я должен сделать, чтобы этот ребенок захотел переделать свою домашнюю работу?» Вы должны вести себя как учитель. Иногда вы думаете о проблеме пятьюдесятью различными способами, пока не найдете то единственное предложение, после которого тот, чья работа критикуется, вытаращит глаза и подумает: «О, я хочу это сделать»[140].

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

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

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

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

Представление проекта заинтересованным сторонам

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

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

У обзорного собрания инвесторов иная динамика, чем у обзора в стиле Мозгового треста. Руководство группы разработчиков может попросить объяснить или обосновать проектные решения, которые приняла команда. Определение четкой повестки обзора майлстоуна поможет провести собрание без неприятных сюрпризов, в частности, будет полезно обсудить предполагаемые вопросы от членов руководства с обеих сторон. Приведение эмпирических данных о положительных отзывах с плейтестов также поможет разработчикам показать свою игру в наилучшем свете.

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

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

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

Эмоциональные аспекты обзора майлстоуна

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

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

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

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

* * *

Обзоры майлстоунов приносят пользу, когда они основаны на доверии, уважении и сочувствии. Чем больше доверия возникает между разработчиками, чья работа обозревается, и группой, которая делает замечания, тем лучше. Некоторые обзоры бывают грубыми или даже жестокими. Я уверен, вы слышали о такой критике, которая доводила людей до слез. По моему опыту, такой процесс редко бывает конструктивным. Проводя обзор, мы должны стараться быть добрыми, уважительными и поддерживающими. Творчество – это нелегко, и мы должны представить нашу критику так, чтобы ее можно было услышать. Мне пришлось научиться излагать свои идеи, тщательно выбирая слова – а иногда и время, – чтобы моя обратная связь дошла до человека, который должен был ее услышать, не встретившись с защитной реакцией.

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

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

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

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

Глава 21

Трудности препродакшена

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

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

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

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

Приверженность дизайну

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

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

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

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

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

Отмена проекта, если препродакшен идет плохо

В своем выступлении на саммите D.I.C.E. Марк Черни затронул сложный, но важный аспект этапа препродакшена: отмена проекта, если подготовка к продакшену идет плохо. Согласно Методу, в конце этапа препродакшена заинтересованные стороны должны дать разработчикам «зеленый свет», если вертикальный срез и макродизайн показали себя с хорошей стороны, а затем профинансировать завершение проекта.

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

Создание вертикального среза обходится недешево. В 2002 году Марк Черни подсчитал, что препродакшен может обойтись в миллион долларов, а сегодня и того больше. Марк признает, что тратить большую сумму денег на препродакшен проекта, который рискует не получить добро, может показаться огромной тратой денег. Однако в конечном счете препродакшен, напротив, позволяет сэкономить.

Экономическая неэффективность во время этапа препродакшена на самом деле практичнее по сравнению с фактическим производством игры. Если у вас ничего не получится, вы всего лишь потратите миллион долларов. Иначе вы бы потеряли куда больше, уж поверьте[141].

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

Конечно, отмена проекта нелегко воспринимается разработчиками. Непросто вложить свое сердце и душу в проект только для того, чтобы его отвергли. Марк Черни дает несколько слов утешения командам, чей проект не получил зеленого света, развенчивая миф:

«Отмененный проект – признак плохого руководства или плохой команды». Нет, конечно же! Отмененный проект – это иногда повод гордиться. Какой бы талантливой ни была команда, провал первой играбельной версии [вертикального среза] дает понять, что проект лучше закрыть и двигаться дальше. Ребята, вы только что сэкономили несколько миллионов долларов и год жизни[142].

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

Вперед! К полному продакшену!

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

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

Список артефактов препродакшена

На рис. 21.1 показана краткая сводка артефактов, которые нужно получить на этапе препродакшена игрового проекта.

Рис. 21.1. Основные артефакты этапа препродакшена

Третий этап: полный продакшен – создаем и исследуем

Глава 22. Суть полного продакшена

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

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

Рис. 22.1. Этап продакшена и его майлстоуны. Авторы изображения: Габриэла Пурри Р. Гомес, Мэтти Розен и Ричард Лемаршан

Презентация вертикального среза и макродизайна

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

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

Работайте по списку задач

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

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

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

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

Переключение передач при переходе от препродакшена к полному продакшену

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

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

Однако не попадитесь в ловушку: не возитесь с таблицей макродизайна очень долго, особенно когда вам пора приступать к созданию остальной части игры. Возможно, вы знакомы с выражением: «Лучшее – враг хорошего». Чтобы стать успешной творческой личностью, нужно научиться понимать, когда вы уже достаточно поработали над задачей и пора перейти к чему-то другому.

Проверка целей проекта

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

В главе 11 упоминались слова Трейси Фуллертон о ценности оттачивания целей проекта, поскольку мы постепенно раскрываем дизайн нашей игры с помощью плейтестов и итераций. Трейси сказала мне, что, по ее мнению, «фиксировать [цели проекта] и больше не пересматривать их в свете получающейся игры… непременно помешает разработке… Рождаясь из вашей работы, игра нагляднее и яснее иллюстрирует саму суть первоначально поставленных целей. Как вы по несколько раз переписываете предложение или абзац, чтобы точнее понять идею, так же и оттачивание целей проекта поможет вам лучше сфокусироваться на производственном процессе».

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

Регулярные встречи – стендапы

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

Стендапы важны и повсеместно распространены в Agile-разработке, иногда их еще называют утренней перекличкой, ежедневным скрамом (англ. DSM, или Daily Scrum Meeting) или просто ежедневной встречей. Собрание иногда проводится стоя, чтобы встреча была короткой. Это умный ход, поскольку дискомфорт от стояния напоминает участникам встречи о том, что их комментарии должны быть краткими и по существу. В центре каждой встречи стоят три вопроса, на которые должен ответить каждый.

• Над чем вы работали с момента нашей последней встречи?

• Над чем вы планируете работать до нашей следующей встречи?

• Какие затруднения мешают вам продвигаться в вашей работе?

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

Третий вопрос – какие затруднения вам мешают? – можно назвать самым важным. Когда мы быстро и кратко обобщаем проблемы (иногда называемые затруднениями или блокерами), с которыми мы сталкиваемся при выполнении нашей работы, мы совершаем по крайней мере три действия.

1. Определяем, что есть проблема.

2. Немного проясняем точную природу проблемы, просто описывая ее кому-нибудь вслух.

3. Создаем возможность получить некоторую помощь в решении этой проблемы.

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

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

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

Майлстоуны полного продакшена

Итак, в процессе производства есть два майлстоуна: альфа и бета. Мы подробно рассмотрим их в следующих главах, но давайте немного их обсудим и здесь.

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

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

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

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

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

В каком порядке собирать игру

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

1. Акт первый, начало.

2. Первая половина второго акта, середина.

3. Вторая половина второго акта, середина.

4. Акт третий, конец.

А затем создавайте игру в следующем порядке (рис. 22.2).

1. Первая половина второго акта.

2. Акт первый.

3. Акт третий.

4. Вторая половина второго акта.

Рис. 22.2. Структура и порядок создания игры

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

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

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

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

Ощущение игры и сочность

Начало полного продакшена – хорошее время, чтобы оценить ощущение игры и сочность проекта. Ощущение игры – это «простое удовольствие от управления, ощущение растущего мастерства персонажа, а также тактильные ощущения от взаимодействия с виртуальными объектами»[144]. Этот важный аспект гейм-дизайна было непросто описать до появления новаторского труда Стива Суинка Game Feel, который я настоятельно рекомендую вам прочитать. Стив очень четко разбивает факторы, которые влияют на «плавность», «отзывчивость» или «свободность» игры, и называет элементы управления в режиме реального времени, моделируемого пространства и аудиовизуального представления, которые улучшают ощущение игры.

Сочность – это концепция, которая, насколько мне известно, была впервые придумана Кайлом Греем, Кайлом Гэблером, Шалин Шодан и Мэттом Кьюсиком, членами Experimental Gameplay Project в Центре развлекательных технологий Университета Карнеги – Меллона. Впервые она была представлена в их эссе 2005 года How to Prototype a Game in under 7 Days («Как сделать прототип игры меньше чем за 7 дней») для издательства Gamasutra. По мнению группы, сочность – это «постоянная и достаточная обратная связь с пользователями».

Сочный игровой элемент крутится и вертится, прыгает, качается и издает звуки, когда вы его касаетесь. Сочная игра кажется живой и реагирует на все, что вы делаете, – огромное количество действий на экране при минимальном пользовательском вводе. Это помогает игроку почувствовать себя могущественным повелителем и учит его правилам игры, при каждом взаимодействии показывая, как у него идут дела с освоением геймплея[145].

Проявляясь через анимацию, звуковое оформление, визуальные эффекты и дизайн взаимодействия, сочность создает богатый опыт для игрока и ощущение игры, придавая особое значение вводу, отзывчивости игры и поощряя дальнейшее взаимодействие. Принципы и практика сочности, а также ее применимость к гейм-дизайну прекрасно освещены Мартином Джонассоном и Петри Пурхо в их выступлении на независимом саммите GDC Europe 2012 под названием Juice It or Lose It[146].

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

Фокусируемся на полном продакшене

Как только начнется полный продакшен, хорошо бы сфокусировать свое внимание на том, что Таня Шорт называет читаемостью игры, которую мы обсуждали в главе 12[147]. Насколько легко люди понимают игру, просто с ней взаимодействуя? Могут ли они понять, как в нее играть, просто экспериментируя с элементами управления? Улавливают ли они важные концепции игры в плане как геймплея, так и сюжета? Этот подход поможет нам доработать многие аспекты дизайна игры: сделать такую игру, которая четко и по нескольким каналам доносит своей аудитории важную информацию точно так же, как это делает любой отличный элемент дизайна.

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

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

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

Когда идти на риск на этапе продакшена

Как я уже говорил ранее, иногда стоит отойти от вашего макродизайна, чтобы сделать игру еще лучше. Подобный случай был у нас при создании Uncharted: Drake’s Fortune, первой игры серии Uncharted. Наша механика прицеливания была не совсем удачной, и гейм-дизайнеру (ныне гейм-директору) Нилу Дракманну пришла в голову идея компромисса, который приблизил нашу систему автоматического прицеливания от третьего лица к более деликатной и точной системе прицеливания из шутеров от первого лица[148]. Производство уже вовсю шло, а до альфы оставалось всего несколько месяцев, когда мы создали прототип новой системы прицеливания, результатами которой мы были очень довольны.

Единственное изменение в дизайне игры повлияло на многое. Теперь столкновения с противниками в Uncharted: Drake’s Fortune «ожили»: они стали немного сложнее, но не чересчур, а также – что очень важно – они стали драматичнее, потому что для победы над врагом вы всегда должны были смотреть прямо на него. Бой внезапно стал более личным, один на один, а не один против всех.

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

Я слышал от других гейм-дизайнеров, что иногда дизайн их игры не совсем складывался до конца разработки и что действительно увлекательной игру, как правило, делало добавление, удаление или модификация одного основного элемента. Зак Гейдж рассказывал про похожий случай со стратегической игрой Tharsis[149] от Choice Provisions Inc., основанной на игре в кости. Райан Смит рассказывал, что то же самое произошло с механикой полета на паутине в игре Spider-Man для PlayStation 4[150]. Эти примеры могут послужить нам уроком, что при методичном выполнении нашего списка задач мы всегда должны учитывать возможности изменить дизайн нашей игры к лучшему.

Просто проявляйте осторожность. В случае с Uncharted: Drake’s Fortune это было единственное серьезное изменение, которое мы внесли в механику игры во время производства. Если бы мы разрешили себе вносить слишком много серьезных запоздалых изменений, подобных этому, наша игра почти наверняка не получилась бы. Пускай такие радикальные изменения будут вашим тузом в рукаве: придержите его для особого случая и не используйте слишком импульсивно.

* * *

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

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

Глава 23

Виды тестирования

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

• Неформальные плейтесты

✓ Неформальный самостоятельный плейтест

✓ Неформальный плейтест с товарищами по команде

✓ Неформальный плейтест с коллегами-дизайнерами

• Тестирование в процессе дизайна

✓ Формальный плейтест

✓ Пользовательский тест

✓ Фокус-тест

• QA-тестирование (обеспечение качества)

• Автоматизированное тестирование

• Публичное тестирование

Рассмотрим их по очереди.

Неформальные плейтесты

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

Неформальный самостоятельный плейтест

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

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

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

Неформальный плейтест с товарищами по команде

Когда вы работаете над игрой и вам нужен свежий взгляд на ваш дизайн, выбор логично падет на человека, сидящего рядом с вами. В большинстве игровых студий часть дня каждого сотрудника уходит на тестирование того, что сделали их товарищи по команде. Вы обсуждаете игру, пока играете, ведете диалог, который был бы неуместен во время официального плейтеста. Неформальное тестирование с товарищами по команде базируется на проговаривании вслух мыслей об игре. Обратная связь, подобная этой, также потребует базовых навыков общения с использованием техники сэндвича (глава 6) и «Мне понравилось, мне бы хотелось, что, если?..» (глава 12).

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

Неформальный плейтест с коллегами-дизайнерами

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

Тестирование в процессе дизайна

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

Формальный плейтест

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

Этот вид тестирования настолько объективен, насколько это возможно в рамках задействованных сложных человеческих факторов. Формальное тестирование часто используется в Naughty Dog, и я был тесно вовлечен в процесс проведения официальных плейтестов наших игр на протяжении большей части моих восьми лет в студии. Мы поговорим о формальном тестировании гораздо подробнее в главах 24 и 25.

Пользовательский тест

Это тип тестирования, который гейм-дизайнеры унаследовали из мира юзабилити и UX (пользовательский опыт). Пользовательское тестирование сосредоточено на разработке и использовании интерфейсов (хотя оно охватывает и гораздо больший объем). В разработке программного обеспечения «юзабилити – свойство системы, продукта или услуги, при наличии которого конкретный пользователь может эксплуатировать систему в определенных условиях для достижения установленных целей с необходимой результативностью, эффективностью и удовлетворенностью»[151].

С определенной точки зрения все в видеоигре представляет собой интерфейс. Не только меню и заголовки, но и дизайн персонажа, вид игрового мира и система управления – три C, – все это передает информацию, формирует режимы взаимодействия и создает опыт.

Поэтому неудивительно, что вы часто будете встречать термин «пользовательское тестирование» при описании формального тестирования, которое мы рассмотрим в главах 24 и 25. Процессы, связанные с формальными плейтестами, частично заимствованы из мира юзабилити и академической дисциплины взаимодействия человека и компьютера (HCI – human-computer interaction). Многие игровые студии нанимают людей с опытом работы в HCI для проведения своих формальных плейтестов, а во многих программах обучения гейм-дизайну есть курс или кафедра юзабилити. Заслуженный профессор гейм-дизайна USC Деннис Виксон помог создать то, что журнал Wired назвал «новой наукой игры» в Microsoft Game Studios[152]. Научная строгость и дизайнерский процесс, которые Деннис и его коллеги использовали для улучшения дизайна своих игр, послужили источником вдохновения для формального тестирования, которые мы проводили в Naughty Dog.

Однако я думаю, что ошибочно полностью смешивать пользовательское тестирование и формальное тестирование. Как мы увидим в следующей главе, формальное тестирование – это несколько субъективная практика, когда дизайнерам часто приходится принимать решения, основываясь на своей интуиции или художественном чутье. В отличие от этого, пользовательское тестирование – это очень строгая, тщательная научная практика, где мы можем быть уверены в достижении определенного дизайнерского результата с помощью эвристических методов и объективного измерения результатов.

Фокус-тест

Как ни странно, некоторые игровые студии называют свои формальные плейтесты или пользовательское тестирование фокус-тестированием. Но фокус-тестирование сильно от них отличается. Фокус-тест – это часть профессиональной и академической дисциплины маркетинга, бизнес-процесса создания отношений с клиентами и удовлетворения их потребностей.

Фокус-тест проводится путем формирования фокус-группы, члены которой отбираются из широкой публики на основе психографической и/или демографической информации, указывающей их как потенциальных пользователей тестируемого продукта, услуги, концепции или рекламы. Членам фокус-группы обычно платят за их время. Заседание фокус-группы проводит специально обученный исследователь, который задает участникам тщательно разработанные вопросы в контролируемых условиях. Ответы группы записываются, а разговор между членами группы поощряется. Они рассказывают о своем восприятии, мнении, убеждениях и отношении к тестируемому объекту. Результаты теста позже анализируются исследователями и обсуждаются заинтересованными сторонами проекта.

Фокус-тесты могут быть полезны на ранних стадиях разработки игры, когда мы хотим убедиться, что наши идеи будут хорошо восприняты возможной аудиторией. Они особенно ценны, если бюджет нашей игры очень велик и мы хотим убедиться, что инвестируем наши деньги с умом. UX-исследователь и гейм-дизайнер Кевин Кикер предлагает множество отличных советов по эффективному использованию фокус-тестов в своем эссе Getting the Most Out of Focus Groups («Получение максимальной отдачи от фокус-групп») в книге Трейси Фуллертон Game Design Workshop[153].

QA-тестирование (обеспечение качества)

Авангардом тестирования любой игровой студии является ее QA-отдел (или отдел обеспечения качества, иногда известный просто как отдел тестирования). QA – это одна из самых зрелых, высококвалифицированных профессиональных дисциплин в любой области разработки игр. Задача QA-тестировщика заключается, во‑первых, в поиске багов: технических ошибок и проблем с контентом, которые негативно влияют на опыт пользователя. Эти баги нелегко найти, потому что они случаются только тогда, когда в игре происходит какая-то редкая последовательность событий или когда используется какое-то необычное сочетание элементов. QA-тестировщики способны исследовать обширное пространство возможностей игры так, как отдельные разработчики просто не могут, помогая нам создавать прекрасные игры.

QA-отдел проверяет игру, следуя тест-плану, который описывает, как будет тестироваться игра и какие проблемы будут устранены. Когда QA обнаруживают проблемы, они заносят их в баг-репорт, которым делятся с другими разработчиками игры. QA-менеджер передает документ руководителям дисциплин (ведущему художнику, ведущему программисту и так далее) в зависимости от природы бага: возможно, это проблема с кодом, которую нужно будет исправить инженеру, или ошибка дизайна, которую нужно исправить гейм-дизайнеру, или же проблема с плохо отображенной текстурой, которую решит художник.

Затем руководители дисциплины передают ошибки отдельным разработчикам в своей группе, которые их исправляют, проверяют изменения в системе управления версиями и отмечают каждый баг как исправленный. (Если они не могут исправить и найти предполагаемую ошибку или не согласны с тем, что это баг, тогда они могут соответствующим образом пометить ее и передать для дальнейшей оценки.) В следующем билде баги, отмеченные как исправленные, возвращаются в QA-отдел для повторной проверки, чтобы убедиться, что проблема действительно устранена.

Баг-репорты в конечном счете становятся важной частью жизни каждого члена команды, и устранение проблем, о которых в них сообщается, займет большую часть рабочего дня отдельного разработчика. QA-тестировщики не просто специалисты по поиску багов и исправлению ошибок – они превосходный источник знаний в области гейм-дизайна и получают отличное представление об опыте, который игра дает своим игрокам. Люди, работающие в QA-отделах, обычно очень увлечены и хорошо разбираются в играх. Зачастую они обладают аналитическим мышлением и развитым пониманием гейм-дизайна и полны превосходных идей. Я всегда старался найти людей, работающих в отделе обеспечения качества, выразить им свое почтение, расспросить их об их работе и чему-нибудь у них научиться.

QA – это дисциплина, относящаяся к сфере разработки, и люди, которые работают в QA, – разработчики игр. В соответствии с философией этой книги, согласно которой каждый, кто вносит вклад в игру, считается одним из ее разработчиков (об этом говорилось в главе 4), мы должны помнить, что люди, работающие в QA-отделе, тоже разработчики. Мы должны приглашать отдел обеспечения качества на каждом этапе проекта, тесно и эффективно работая вместе, чтобы создавать лучшие игры, какие только можем.

Автоматизированное тестирование

Разработчики программного обеспечения создавали механизмы для автоматического тестирования написанного ими кода почти с того самого момента, с какого существует сама информатика. В автоматизированном тестировании используется специальное программное обеспечение, которое тестирует другое программное обеспечение, также оно может быстро и эффективно выполнять рутинную работу тестировщика или же проводить тесты, которые человек вовсе не смог бы провести.

Самые известные примеры автоматизированного тестирования – это модульное, интеграционное и нагрузочное тестирование сервера, где модули и группы кода и данных тестируются на предмет того, правильно ли они работают. Автоматизированные плейтесты могут имитировать ввод данных человеком в игру с помощью контроллера, клавиатуры, мыши или сенсорного экрана. Автоматизированный тест может использовать программный интерфейс, чтобы полностью обойти систему ввода и напрямую взаимодействовать с кодом и контентом.

Автоматизированное тестирование в настоящее время является общепринятой и важной частью инструментария разработчика. Пока я был в Naughty Dog, талантливая инженерная команда студии начала применять смоук-тесты (также известны как тестирование достоверности, сэнити-тесты и тестирование для проверки билда[154]), чтобы убедиться, что у наших новых билдов нет никаких проблем, связанных с памятью и загрузкой уровня. Это гарантировало, что у нашего QA-отдела каждое утро будет билд для проверки без каких-либо критических сбоев.

Учитывая, что разработка игр – это творческая человеко-ориентированная область, я думаю, что автоматическое тестирование вряд ли когда-нибудь полностью заменит тестирование человеком. Однако оно помогает быстрее и тщательнее проверить код на наличие определенных багов и ошибок, поскольку компьютеры хорошо справляются с детализированными, скучными, повторяющимися задачами с безупречной точностью. Я считаю, что машинное обучение поможет нам тестировать наши игры по-новому точно так же, как оно начало творить чудеса в таких областях нашей жизни, как распознавание речи и манипулирование изображениями.

Публичное тестирование

Публичное тестирование – это тот вид тестирования, который мы проводим, выпуская нашу игру для широкой публики до того, как она будет полностью завершена, возможно, в какой-то ограниченной форме. Публичное тестирование будет включать бета-тестирование, тестирование в раннем доступе и выпуск игры на небольшом тестовом рынке до ее глобального релиза.

При публичном бета-тестировании разработчик или издатель игры позволяет широкой публике установить и попробовать игру после майлстоуна бета-версии, но за несколько недель или месяцев до ее полного завершения. (В публичной бета-версии чаще всего выпускается не вся игра целиком, а только ее часть, возможно, демоуровень.)

Разработчики получают множество различных отзывов от публичного бета-тестирования. Они могут перепроверить результаты загрузки своих серверов, чтобы убедиться, что их серверы могут обрабатывать нагрузку в тысячи – или сотни тысяч – игроков, играющих одновременно. Разработчики также могут собрать данные о действиях игроков и при этом проверить, работает ли дизайн игры так, как задумано. Они могут найти проблемы с производительностью, связанные с частотой кадров и задержками, и проблемы с безопасностью. Пользователи ранних версий часто ищут лазейки в защите игры, чтобы посмотреть, смогут ли они ее взломать. Разработчики также могут получить прямую обратную связь от своих публичных бета-тестеров об их опыте точно так же, как мы сделали бы это при формальном тестировании, опрашивая тестеров.

При тестировании раннего доступа игра выпускается – и, возможно, даже продается – до того, как она завершена с точки зрения либо фичей, либо контента. Эта практика сейчас распространена в мире профессионального гейм-дизайна благодаря раннему доступу (Early Access) в Steam и таким платформам, как Itch.io, которые могут использовать разработчики, чтобы привлекать свою аудиторию к процессу создания и разработки раньше, проще и в большем масштабе, чем когда-либо прежде. Публичное тестирование также поможет создать игровое сообщество и пробудить интерес к игре.

* * *

Мы рассмотрели некоторые виды тестирования, и в следующих двух главах подробнее рассмотрим формальное тестирование, которое служит разработчикам ценным инструментом в работе над игрой.

Глава 24

Подготовка к формальным плейтестам

В начале нашего производственного процесса, на этапах формирования идей и препродакшена, мы подходим к дизайну и созданию нашей игры очень свободно и творчески – все структурировано в достаточной степени для принятия верного решения в нужный момент. На этапе продакшена мы не прекращаем работать интуитивно, но – следуя намеченному плану и таблице макродизайна – переходим к более рациональному способу работы.

Сейчас мы находимся на пути к созданию альфа-версии, когда наша игра будет завершена с точки зрения ее фичей (все основные механизмы игры будут уже представлены), и бета-версии, когда наша игра будет завершена в плане контента (все, что должно быть в игре, будет готово к полировке в процессе постпродакшена). Как мы можем удостовериться, что правильно переходим от субъективного к объективному, от интуитивного к рациональному? Формальное тестирование нам в этом поможет.

Формальные плейтесты в Naughty Dog

Я присоединился к Naughty Dog, страстно желая тестировать игры и радуясь совместной работе с Эваном Уэллсом и Марком Черни, которые уже внедрили в студию отличные практики формальных плейтестов. На протяжении большей части своей жизни Naughty Dog (и ее материнская компания Sony Interactive Entertainment) проводили формальные плейтесты, в ходе которых из широкой аудитории с помощью онлайн-рекламы набирались люди, и их приводили в студию поиграть за деньги в игру на стадии разработки. Эти тестировщики не знали заранее, в какую игру они будут играть или кто ее создает. Мы хотели избежать любых предубеждений, как положительных, так и отрицательных, которые повлияли бы на наших тестеров.

Пока я был в Naughty Dog, мы работали со сторонним агентом, который проверял данные откликнувшихся на рекламу и давал нам по десять тестеров на каждый формальный плейтест. Игровой опыт и демографическая информация отражали тип игроков, которым, по нашему мнению, понравилась бы наша игра, в зависимости от возраста, пола и игрового опыта. Как и многие разработчики, мы называли этих ребят «клинекс»-плейтестерами – как одноразовые бумажные салфетки. В формальном тестировании нужны люди, которые никогда раньше не играли в тестируемую игру, чтобы получить точное представление о ее состоянии.

Когда я присоединился к Naughty Dog, чтобы помочь закончить Jak 3, мы провели около четырех или пяти тестов за весь проект. При разработке Uncharted 3, последней игры, над которой я работал в Naughty Dog, мы провели двадцать один тест, начав примерно за шесть месяцев до окончания проекта – примерно по одному тесту в неделю. Мы проводили наши формальные тесты в специальной игровой комнате: вдоль одной стены располагался ряд из десяти игровых мест, оборудованных телевизорами, подключенными к сети PlayStation с тестируемым билдом игры, и парой наушников, подключенных к телевизору, чтобы каждый игрок слышал только то, что происходит в его прохождении. Сами разработчики сидели в другом конце комнаты, наблюдая за игрой тестировщиков. Сегодня у Naughty Dog есть специальная лаборатория для тестирования игр с односторонним зеркалом, отделяющим тестировщиков от дизайнеров, наблюдающих за ними по общим принципам пользовательских исследований.

При тестировании Uncharted 3 мы использовали сетевые цифровые видеорекордеры, которые делают запись экрана во время плейтеста. Позже мы могли просмотреть эти видео, чтобы поближе рассмотреть действия конкретного игрока или чтобы обнаружить какие-то проблемы в определенной части игры, где игроки надолго застревали. Важно отметить, что эти методологии были изобретены исследователями HCI (взаимодействия человека с компьютером) для пользовательского тестирования, а затем переняты игровой индустрией. Сегодня Naughty Dog также записывает лица, руки и общую позу игроков. Эти кадры можно запускать параллельно с видео прохождения для лучшего представления о том, что игрок делает и чувствует в каждый момент игры, а посмотреть эти записи может любой сотрудник.

Мы устанавливали экраны между игровыми местами, чтобы игроки не могли увидеть прогресс друг друга даже случайно. Если ваш сосед быстрее решает какую-то головоломку, по-новому использует какое-то оружие иди просто забрался куда-то, куда не забрались вы, это повлияет на ваше прохождение.

Мы также просили наших игроков не разговаривать во время плейтеста и, поскольку хотели как можно более объективных результатов, совершенно безжалостно отказывали тестерам в любой помощи. По мере того как тестеры играли, игра записывала определенную информацию и отправляла ее в базу данных нашей сети. Мы называли ее игровыми метриками, я расскажу о них в главе 26.

В конце игрового теста мы просили тестировщиков заполнить анкету об их опыте, а затем проводили заключительную беседу для дальнейшего изучения. Числовая информация (количественные данные), которую мы получали в результате опросов, помогала нам отслеживать изменения в восприятии игры пользователями от теста к тесту. Мы почти всегда видели медленное, постепенное улучшение, которое помогало нам оставаться в здравом уме и знать, что игра шаг за шагом становится лучше. Мы также знакомились с некоторыми интересными, хотя и менее объективными мнениями (качественными данными). Метрические данные предоставляли нам информацию о том, насколько играбелен наш проект.

В оставшейся части этой главы и в следующих двух главах я подробнее расскажу вам обо всех процессах, составляющих процесс формального тестирования игр, который поможет вам убедиться, что ваша игра настолько хороша, насколько это возможно.

Общая практика формальных плейтестов

В главе 5 мы изложили несколько рекомендаций по проведению плейтестов, которые затем расширили и уплотнили в главе 12, определив основные правила тестирования в течение всего проекта.

Достигая определенного момента в разработке игры, обычно непосредственно перед альфа-версией, мы должны перейти к еще более строгой форме плейтестов, чтобы собрать максимально четкую информацию о нашей игре. Для внесения необходимых окончательных корректив в разработку нам пригодятся как объективные факты об игре, так и субъективные точки зрения. Они помогут нам отследить изменения дизайна и убедиться, что последние внесенные изменения улучшили игру, а не ухудшили. Мы будем называть этот процесс формальными плейтестами, и мы прибегнем к его использованию, чтобы еще сильнее увериться, что наша игра приглянется нашим игрокам так, как мы этого хотим. Так мы сможем завершить наш переход от интуитивного создания к объективной оценке и подготовиться к релизу игры.

Регулярные формальные плейтесты становятся жизненно важной частью процесса разработки игр, позволяя нам методично решать небольшие дизайнерские проблемы и оставляя нам время для решения более важных вопросов. Марк Черни недавно сказал мне: «Как только в структуру продакшена вписываются регулярные плейтесты, диалог внутри и вне команды уже не звучит так: “Как вы думаете, игроки поймут XYZ?”, “Уместен ли здесь такой уровень сложности?” или “Можно ли интуитивно понять управление с удержанием L1 и нажатием круга?” Эти темы могут отнимать много времени, но поскольку мы знаем, что плейтесты быстро их разрешат, мы можем свободно заниматься более серьезными структурными проблемами игры (например, достаточно ли игрок сопереживает персонажу игрока), не тратя время на детали».

Итак, теперь пришло время добавить несколько дополнительных рекомендаций к процессу проведения плейтестов, описанному в главе 12. Новые правила выделены жирным шрифтом в приведенном ниже списке.

• Подготовьте для плейтеста проверенный билд без багов и серьезных проблем с геймплеем.

• Используйте формальный сценарий плейтеста.

• При желании проведите предварительный опрос.

• Как плейтестер, так и дизайнер должны быть в наушниках.

• При необходимости приготовьте подсказку с управлением и читами.

• Подготовьте письменную подсказку, чтобы помочь игрокам преодолеть функциональные сбои или ошибки геймплея.

• Предложите вашему тестеру вслух оценить свои чувства и мысли.

• Вставьте предупреждение, если это необходимо.

• Начните плейтест.

• Будьте внимательны к тому, что делает плейтестер.

• Записывайте все ваши наблюдения и размышления плейтестера.

• Не помогайте плейтестеру.

• При желании запишите аудио- и видеозапись как игры, так и плейтестера, проходящего ее (с согласия тестера).

• Используйте телеметрию для сбора метрических данных о сеансе игры.

• Следите за временем: вам понадобится время для опроса и заключительной беседы.

• После теста и перед началом разговора проведите опрос.

• После опроса задайте подготовленные для заключительной беседы вопросы.

• Запишите либо вручную, либо на аудио ответы тестера.

• Не объясняйте игру.

• Не отчаивайтесь.

Как видите, мы использовали формальные плейтесты на протяжении большей части разработки нашей игры! Это хорошо: значит, мы с самого начала придерживались строгого подхода к тестированию, и это заложило прочную основу для следующего этапа нашей работы. Давайте посмотрим на новые правила, в основе которых три новых инструмента: сценарий, опрос и подготовленные для заключительной беседы вопросы.

Подготовьте для тестирования проверенный билд, без багов и серьезных проблем с геймплеем

Задолго до начала тестирования – обычно не менее чем за три дня – мы должны подготовить работоспособный, проверенный билд игры без каких-либо проблем, которые могли бы помешать тестированию. Менее опытные разработчики, пренебрегающие этим этапом подготовки, частенько попадают впросак: им ужасно хочется вносить изменения в игру вплоть до плейтеста. Возникают проблемы, которые ломают игру, сводя на нет все время, деньги и усилия, затраченные на организацию теста. Поэтому крайне важно, чтобы сборка игры была достаточно стабильной и работоспособной, чтобы ее можно было запустить и проверить на наличие серьезных проблем перед тестированием. Если разработчики захотят внести небольшие изменения в игру в дни, предшествующие тестированию, то стабильный, исправный билд, который они ранее подготовили и проверили, станет запасным вариантом на случай, если внесенные изменения поломают игру.

Используйте формальный сценарий плейтеста

В формальном тестировании или пользовательском исследовании человек, проводящий тест, традиционно использует письменный сценарий, чтобы точно определить, что говорить каждому тестеру. Наличие сценария означает, что все тестировщики получают одну и ту же информацию. Вы можете подробнее прочитать об этом ниже.

При желании проведите предварительный опрос

При помощи предварительного опроса можно собрать информацию о тестере, чтобы сравнить с той информацией, которая будет у вас уже после тестирования. Например, можно спросить тестировщика, как он себя чувствует, чтобы сравнить его эмоциональное состояние до и после теста. Если вы используете предварительный опрос, внесите все, что будете говорить, в тестовый сценарий.

При желании запишите аудио- и видеозапись как игры, так и плейтестера, проходящего ее (с согласия тестера)

Существуют пакеты программ, которые записывают аудио и видео игры, а также аудио и видео плейтестеров во время прохождения. Видео с тестером может записываться либо с камеры, встроенной в ноутбук, либо с другого записывающего устройства. Получите согласие ваших тестеров на запись, чтобы избежать нарушения конфиденциальности. Если у вас есть ресурсы для подобной записи тестирования, я рекомендую к ним прибегнуть. Если же нет, не волнуйтесь – вы можете получить много полезной информации, просто наблюдая за тестерами и делая заметки.

Используйте телеметрию для сбора метрических данных о сеансе игры

Мы внедряем в игру код, который фиксирует информацию о том, что игрок делает по мере прохождения, сколько времени ему требуется, чтобы завершить каждую часть игры, и так далее. Мы подробнее обсудим это в главе 26.

Следите за временем: вам понадобится время для опроса и заключительной беседы

Мы говорили о необходимости следить за временем во время плейтеста в главе 12. Теперь у нас еще одна причина посматривать на часы: в формальном тестировании мы должны провести опрос и заключительную беседу после того, как тестер закончит играть, но до окончания тестирования.

После теста и перед началом разговора проведите опрос

Как только тестировщик закончит играть, но прежде чем мы начнем спрашивать его о полученном опыте, он должен пройти опрос. В этом опросе его будут спрашивать о полученном опыте, но в подконтрольном виде. Вопросы должны быть сформулированы с использованием методики, разработанной психологами, чтобы получить максимально объективные ответы.

После опроса задайте подготовленные для заключительной беседы вопросы

Мы проводили заключительные беседы на протяжении всего процесса проведения плейтестов, и в главе 12 я привел вам пять открытых вопросов Марка Таттерсолла в качестве отправной точки[155]. К моменту проведения формального плейтеста у нас обычно возникают вопросы, которые мы хотели бы обсудить в ходе заключительных бесед. Чтобы получить наилучшие результаты, мы должны заранее подготовить и проанализировать вопросы, а затем задать их каждому тестеру.

Запишите либо вручную, либо на аудио ответы тестера

Замечания плейтестеров часто наполнены мудростью и интересными дизайнерскими идеями, но наша память подвержена влиянию эмоций и ошибкам – вы запомните что-то из того, что скажет тестер, но часто только то, что радует или угнетает вас больше всего. Чтобы получить полное представление о том, как люди реагируют на наши игры, мы должны фиксировать все, что они говорят. Делайте заметки или аудио- или видеозапись заключительных бесед для последующего просмотра и, возможно, их транскрипции. (Транскрибировать аудио и видео в текст можно довольно просто при помощи автоматических сервисов.)

Мы разобрались с новыми правилами, осталось только узнать, как создать необходимые инструменты: тестовый сценарий, опрос и вопросы для заключительной беседы.

Подготовка сценария плейтеста

Тестовый сценарий точно определяет, что будет говорить человек, проводящий плейтест. Тестовый сценарий обычно включает следующее.

• Приветствие игроков. «Здравствуйте и добро пожаловать на наш плейтест! Спасибо, что пришли».

• Приглашение сесть. «Пожалуйста, сядьте сюда».

• Демонстрация подсказок с элементами управления, если вы их используете. «Вы можете использовать этот лист в качестве подсказки по управлению в игре».

• Уточнение, что вы тестируете игру, а не мастерство игроков. Как бы они ни играли, они играют правильно. (Напишите для этого и следующих пунктов свой сценарий.)

• Напоминание плейтестеру, что человек, проводящий плейтест, не сможет оказать никакой помощи.

• Любые предупреждения о контенте игры, которого плейтестеры, возможно, пожелают избежать[156].

• Медицинские предупреждения: например, предупреждение о вызываемых мерцающим светом или контрастными узорами припадках эпилепсии или предупреждение об укачивании в некоторых видах игр виртуальной реальности.

• Инструкция о том, как дать свое согласие на аудио- или видеозапись тестирования.

• Инструкция о том, как подготовиться к игре (например, надеть наушники и взять в руки контроллер).

• Команда начать играть, когда все будет готово.

• Сценарий должен включать то, что следует сказать, если тестировщик попросит о помощи: например, вежливо напомнить ему, что организаторы плейтеста не могут подсказывать.

• Исключением из этого правила являются случаи, когда для помощи игрокам используется письменная подсказка для решения уже известной проблемы. Команда разработчиков должна решить до начала тестирования, когда ее лучше предоставить игрокам: всякий раз, когда тестер достигает определенной части игры, только в том случае, если тестер сталкивается с проблемой, или когда игрок просит о помощи. Какой вариант подойдет вам, зависит от типа проблемы. Опишите в сценарии, что вы будете говорить, если понадобится подсказка.

• Сценарий не должен сообщать тестеру ничего другого о вашей игре.

• Когда игра подойдет к концу, по сценарию попросите игрока прекратить игру.

• Попросите тестера пройти опрос.

• Заключительная беседа обычно начинается четко по сценарию, но по мере обсуждения принимает более непринужденный характер. Мы обсудим это ниже.

• После заключительной беседы сценарий уже не так важен, но внесите в него все, что захотите сказать в конце теста, например, благодарность тестировщикам.

Написав сценарий, прочтите его вслух, чтобы убедиться, что все звучит плавно, а затем внесите соответствующие изменения.

Подготовка опроса

Сразу после теста и перед любым обсуждением мы даем тестерам опросник (иногда называемый анкетой). Я научился проводить опросы по итогам формальных плейтестов, когда был в Naughty Dog, пользуясь шаблоном, предоставленным мне моим другом Сэмом Томпсоном, отличным продюсером Sony Interactive Entertainment.

Именно Сэм познакомил меня с идеей опросов по шкале Лайкерта, названной в честь ее изобретателя, американского социального психолога Ренсиса Лайкерта (1903–1981). Опросы по шкале Лайкерта используются для оценки отношения и чувств людей к чему-то субъективному таким образом, чтобы обеспечить высокую степень объективности в понимании каждого вопроса разными людьми. Шкала Лайкерта обычно используется в социальных науках при проведении опросов по таким направлениям бизнеса, как маркетинг и оценка удовлетворенности клиентов, и в других исследовательских проектах, связанных с отношением к продукту. Мы задаем вопрос по шкале Лайкерта, сначала формулируя утверждение, например:

«Мне нравится КАЧЕСТВО ГРАФИКИ в этой игре».

Обратите внимание, что это очень простое утверждение. Наиболее важные части вопроса выделены заглавными буквами, так что они бросаются читателю в глаза. Совершенно очевидно, что этот вопрос сосредоточен на оценке КАЧЕСТВА ГРАФИКИ игры. Для ответа на него надо иметь некоторые специальные знания: читатель должен понимать, что подразумевается под «графикой», чтобы суметь оценить ее качество. Убедитесь, что вы используете концепции, которые хорошо понятны аудитории, тестирующей продукт.

Затем отвечающему на вопрос предоставляются варианты ответа, которые обычно сформулированы таким образом.

Отвечающий просто выбирает номер варианта, который в наибольшей степени соответствует его восприятию.

В самом начале опроса попросите каждого игрока назвать свое имя (или другой уникальный идентификатор, если тест по какой-либо причине должен быть анонимным), чтобы вы могли сопоставить результаты опроса с другой информацией об опыте этого игрока, которую вы соберете во время теста.

Вы также можете запросить у игрока другие демографические данные. Я думаю, что традиционные демографические данные, такие как возраст, пол и этническая принадлежность, не так полезны, как психографические данные о том, какие типы игр и средства массовой информации предпочитает игрок. Если вы запрашиваете у игрока демографическую и психографическую информацию, оставьте это на конец опроса. Это поможет вам избежать предвзятости, связанной с неявным стереотипом в отношении тестера[157].

В Naughty Dog мы обычно включали в подобный опрос от десяти до тридцати пунктов. Одно из преимуществ шкалы Лайкерта заключается в том, что заполнение опросника занимает совсем немного времени. Из-за того, как сформулированы вопросы (в виде утверждений, с которыми вы либо согласны, либо нет), респонденты, взглянув на строку, быстро выбирают наиболее подходящий вариант ответа.

Для составления опросника по результатам тестирования вам понадобится шаблон в качестве примера – подобный шаблон вы можете найти на следующих нескольких страницах. Переформулируйте вопросы под вашу игру, по возможности придерживаясь утвердительных предложений и выделяя ключевые слова заглавными буквами и жирным шрифтом.

Вы заметите, что вопрос 4 в примере опросника нарушает шаблон «Полностью не согласен» и «Полностью согласен», обычно применимый в шкале Лайкерта. Вместо этого в вопросе тестеру предлагается оценить сложность игры по шкале от «Слишком легко» до «Слишком сложно». В подобном опросе допустимо задавать вопросы, которые не соответствуют шаблону, если их не получается сформулировать иначе. Однако не злоупотребляйте этим, иначе вы рискуете собрать менее объективные данные.

Опрос может быть распечатан и заполнен участниками игры карандашом или ручкой, или же его можно представить в цифровом виде. Если вы поищете в интернете «онлайн-опросы по шкале Лайкерта», вы найдете множество инструментов, которые помогут вам опросить тестеров с помощью компьютера или мобильного устройства.

Подготовка к заключительной беседе

После того как каждый участник тестирования заполнит опрос, мы проведем заключительную беседу. В рамках процесса формального тестирования в Naughty Dog мы составляли список приоритетных вопросов, которые задавали каждому тестировщику (или в нашем случае каждой группе тестировщиков – подробнее об этом чуть позже).

Заключительная беседа – это не самая простая часть тестирования, поскольку иногда крайне сложно интерпретировать полученную обратную связь. Обычно мы надеемся услышать четкую информацию по проблемам дизайна, которые нам надо решить, но зачастую получаем далеко не ясные отзывы.

На формальных плейтестах Naughty Dog мы тестировали нашу игру на десяти людях одновременно. Поскольку в то время у нас не было ресурсов проводить беседы с каждым тестером по отдельности, мы проводили их в одной большой группе (или иногда в двух небольших). Это осложняло обратную связь из-за социальных и психологических факторов, присущих групповому обсуждению. Мы часто замечали, что группа склонна соглашаться с наиболее харизматичными, сильными и прямолинейными ее членами. Это естественно, и в этом кроется явление, известное как эффект социальной желательности, при котором люди, как правило, стремятся давать ответы, которые будут положительно восприняты другими[158].

Именно из-за этого эффекта лучше всего, чтобы заключительные беседы проводил кто-то не из вашей команды. Если вы, разработчик игры, будете напрямую говорить с тестерами и они будут знать (или подозревать), что вы создали игру, в которую они только что играли, они с меньшей вероятностью откровенно опишут свои мысли и чувства по поводу игры. Вот почему для проведения тестирования лучше привлечь профессионального UX-исследователя.

По возможности лучше проводить заключительные беседы индивидуально или в небольших группах до четырех человек, чтобы получить более четкое представление о том, как наша игра приглянулась каждому плейтестеру. По практическим соображениям члену команды разработчиков иногда приходится проводить тестирования и сеанс обратной связи по игре, которую он сам же создал. Мы должны иметь в виду, что при непосредственном общении плейтестера с разработчиком игры будет иметь место эффект социальной желательности, и мы должны придавать полученной информации меньший вес. Если мы можем избежать такой ситуации, лучше так и сделать. Например, на моих занятиях мы обмениваемся играми, так что я тестирую чужую игру, а один из моих студентов тестирует мою.

Рис. 24.1 (a – г)

Рис. 24.1 (a – г). (Продолжение)

При составлении списка вопросов для беседы мы должны решить, как мы будем записывать полученные ответы. Может быть, просто будем делать заметки в блокноте или на мобильном устройстве, если умеем достаточно быстро писать или печатать. В более профессиональной обстановке можно делать аудио- или видеозаписи устных ответов, если у нас есть возможность провести беседу в тихом месте. Конечно, аудио- или видеозапись потребует некоторой дополнительной подготовки перед тестированием для настройки записывающего оборудования. Опять же, не забудьте получить согласие ваших тестеров на запись.

Рис. 24.1 (a – г). (Продолжение)

Рис. 24.1 (a – г). (Продолжение)

Составляем вопросы для заключительной беседы

Чтобы успешно справиться со всеми трудностями заключительной беседы, мы должны быть к ней хорошо подготовленными и задавать хорошие вопросы. Пять открытых вопросов Марка Таттерсолла, которые я приводил в главе 12, обычно лучше всего работают на ранних стадиях разработки, когда дизайн нашей игры все еще формируется. К этапу альфа-версии мы уже должны быть вполне уверены в том, что знаем ответы на вопросы Марка, и перейти к более конкретным (но все еще открытым) вопросам о нашей игре, чтобы узнать, работает ли она так, как мы того ожидаем, и выявить любые проблемы, о которых мы либо знаем и хотим изучить получше, либо не знаем вовсе.

Помимо изобретения шкалы Лайкерта, Ренсис Лайкерт разработал в 1930‑х годах методику открытого интервью и метод воронки, при котором исследователь начинает с открытых общих вопросов, постепенно переходя к более узконаправленным[159]. Воронка – продвинутая техника интервьюирования, которая действительно поможет вам разобраться в деталях того, как тестер оценил игру.

Итак, к беседе надо подготовить список тщательно продуманных открытых вопросов, которые помогут вам шире и глубже изучить опыт, создаваемый вашей игрой. Помните, что открытый вопрос подразумевает развернутый ответ, а не просто «да» или «нет». Обычно я готовлю список из 5–10 вопросов или даже больше, в зависимости от того, сколько у нас времени на беседу. Мои вопросы сосредоточены на аспектах игры, в которых я не уверен или о которых хочу узнать больше, а последующие вопросы должны помочь более глубоко раскрыть конкретные области. Можно также составить несколько дополнительных вопросов, которые вы зададите только в том случае, если тестер дал конкретный ответ на предыдущий вопрос.

Я формулирую свои вопросы как можно более четко и конкретно – я стараюсь избегать двусмысленных и расплывчатых вопросов. Я резюмирую каждый вопрос в одном коротком предложении максимально ясно и кратко. Будет трудно интерпретировать ответ плейтестера, если он не совсем поймет мой вопрос. Каждый вопрос – это начало короткого разговора, и я задаю последующие вопросы по мере того, как плейтестер отвечает (возможно, вопросы, которые приходят мне в голову в данный момент), чтобы вести нашу беседу в полезном для меня направлении.

Вот несколько примерных вопросов для заключительной беседы, которые помогут вам начать составление вашего списка.

• Какие эмоции у вас вызвал (конкретный эпизод в игре)?

• Пожалуйста, опишите, как (выполнить какое-либо действие, например, отпереть дверь в игре).

• Пожалуйста, опишите, как работает (какая-то часть игры, например, система очков опыта).

• Расскажите о (персонажах игры): кто они и как вы к ним относитесь?

• Пожалуйста, расскажите о той части игры, где вы чувствовали себя сбитым с толку или потерянным.

Тестирование может оказаться интеллектуально и эмоционально непростым опытом для гейм-дизайнера. Творческий человек может легко впасть в ступор на любом этапе творческого процесса и особенно во время плейтеста, который идет совсем не так, как мы того ожидали. Задавая каждому тестеру общий набор вопросов, мы можем быть уверены, что тестирование принесет много полезной информации о волнующих нас аспектах игры.

Фокус-тестирование названия игры, ключевого арта и дизайна логотипа

Формальное тестирование в преддверии альфа-версии отлично подойдет для проверки названия нашей игры, ключевого арта и дизайна логотипа, которым мы занимались на протяжении всей разработки. Мы можем обсудить все три аспекта в заключительной беседе, используя методы, которые вы найдете на сайте этой книги.

Подготовка ко дню формального плейтеста

То, как именно вы проводите формальные плейтесты, зависит от контекста, в котором вы работаете: являетесь ли вы профессиональной командой разработчиков игр, создаете игры для развлечения или изучаете разработку игр в учебном заведении; знаете ли вы, где именно вы будете проводить тестирование; нужно ли вам специализированное оборудование для запуска вашей игры; сколько времени продлится тест.

Вам нужно будет продумать все практические детали, чтобы должным образом подготовиться ко дню тестирования и прибыть в нужное место в нужное время с готовой к запуску игрой и тестерами. Я рекомендую вам назначить кого-то из вашей команды ответственным за все детали формального плейтеста, чтобы ничего не упустить из виду.

Тот, кто проводит формальный плейтест, должен следить за часами, поэтому обязательно запаситесь устройством для проверки времени. Наблюдающие, отмечающие время происходящих событий, тоже должны иметь часы под рукой.

Чтобы подготовиться к плейтесту, убедитесь, что у вас есть все нужное из этого списка.

✓ Проверенный билд без багов и серьезных проблем с геймплеем.

✓ Компьютер или устройство для запуска игры с необходимым оборудованием (например, игровой контроллер или гарнитура виртуальной реальности).

✓ Чистящие салфетки для контроллеров и VR-шлемов.

✓ Достаточно большой экран, чтобы его видел как игрок, так и наблюдатель.

✓ Наушники для плейтестера.

✓ Способ прослушивания игры наблюдателем (например, наушники, разветвитель для наушников и удлинительный кабель).

✓ Все необходимое для записи ваших наблюдений во время теста (блокнот и ручка или цифровое устройство).

✓ При желании способ записи аудио и видео с экрана и/или лица и рук игрока.

✓ Печатная или цифровая копия тестового сценария.

Копии подсказок с элементами управления.

Копии письменной подсказки, которые помогут игрокам с известными функциональными сбоями или ошибками геймплея.

✓ Печатные или цифровые копии опроса.

✓ Ручки или карандаши для бумажных опросов.

✓ Печатные или цифровые копии вопросов для заключительной беседы.

✓ Все необходимое для записи ответов беседы.

✓ Часы.

Теперь, когда у нас есть все необходимое, мы готовы начать плейтест.

Глава 25

Проведение формального плейтеста

Формальный плейтест в неформальной обстановке

В идеальном мире мы проводили бы каждый формальный плейтест как юзабилити-тестирование: в специально оборудованной комнате, предназначенной для испытательных игровых сессий, с записью аудио- и видеопотока игрока и его экрана и параллельным сбором метрических данных, отправляющихся на центральный сервер.

Но имея в распоряжении только конференц-зал или классную комнату и проводя несколько сессий одновременно в одном физическом пространстве, мы все же можем передать дух формального плейтеста, несмотря на неформальную, многолюдную, шумную обстановку – и помогут в этом рекомендации, изложенные в главе 12 «Проведение плейтестов», главе 24 «Подготовка к формальным плейтестам» и в этой главе.

Проявляя осторожность в том, как мы взаимодействуем с нашими тестерами, и следя за тем, чтобы случайно не предоставить им то, что я называю «привилегированными» знаниями об игре (заблаговременная или закулисная информация), мы можем создать вокруг них «пузырь объективности». Тогда мы сможем получить четкие, высококачественные отзывы о нашей игре точно так же, как это бы было в научно контролируемой среде юзабилити-тестирования.

Поиск плейтестеров

Поиск плейтестеров для формального плейтеста может оказаться сложной задачей даже для игровой студии или программы, полной людей, желающих играть в игры и помогать дизайнерам. Верный способ найти тестировщиков для вашей команды будет зависеть от ваших обстоятельств. Если вы профессиональная компания или академический исследовательский проект с бюджетом и у вас есть ресурсы платить плейтестерам, выбирайте этот путь – я считаю, что люди должны получать компенсацию за свой труд, даже если этот труд доставляет удовольствие. Если у вас очень небольшой бюджет, может сработать оплата в натуральной форме – например, бесплатная копия игры, когда она выйдет, или еда в день плейтеста.

В программе обучения гейм-дизайну можно привести аргумент в пользу участия студентов в формальном плейтесте: каждый гейм-дизайнер должен развивать свои навыки мышления вслух в рамках своей профессиональной практики, а отказ дизайнера помочь вам преодолеть сложный или непонятный участок игры поможет вам в будущем, когда вы уже сами будете на месте дизайнера.

Я привлекал плейтестеров на наши учебные формальные плейтесты самыми разными способами: я развешивал плакаты и рассылал объявления, приглашая людей из университетского сообщества, я просил студентов, чьи игры будут тестироваться, пригласить несколько своих друзей. По моему опыту, люди более склонны прийти на плейтест, когда я прошу их зарегистрироваться с помощью онлайн-формы, а предоставление закусок до или после плейтеста скорее гарантирует, что подавшие заявки все-таки явятся. Когда студенты приводят друзей, я стараюсь, чтобы они не играли в игру, созданную их другом, – возможно, это их слегка расстроит, но зато снизит вероятность проявления эффекта социальной желательности.

Помните, что, если кто-либо из ваших плейтестеров несовершеннолетний, его родитель или опекун должен подписать согласие на его участие в плейтесте. Убедитесь, что вы должным образом изучили юридические требования по этому вопросу для вашей страны или региона и все заблаговременно предусмотрели.

Поиск места, организация времени и выбор координатора

Найдите место для проведения тестирования, отвечающее условиям вашей команды. Если вы профессиональная команда, вы можете воспользоваться конференц-залом или общей зоной на вашем рабочем месте. Если вы работаете в студенческой команде, вы можете подыскать классную комнату или общую гостиную. Если вы – член игрового клуба или коллектива, вам подойдет какое-нибудь офисное пространство, например коворкинги предлагают в аренду конференц-залы. Чтобы протестировать большинство типов цифровых игр, вам понадобятся столы и стулья. Убедитесь, что у вас достаточно стульев как для участников, так и для людей, проводящих плейтест, а также в том, что в выбранном месте есть доступ к питьевой воде и туалетам.

Выделите достаточно времени на проведение плейтеста: сколько времени вам понадобится, будет зависеть от продолжительности вашей игры, того времени, в течение которого вы хотите ее тестировать, количества доступных вам игровых мест (см. раздел «Подготовка места плейтеста» ниже) и количества плейтестеров. Цель формального плейтеста – дать по крайней мере семи, а предпочтительно десяти людям поиграть в игру и дать им достаточно времени, чтобы они успели пройти ее полностью (или почти полностью).

Решите, кто будет следить за процессом и говорить с плейтестерами. Назовем этого человека координатором. Лучше всего, если координатором будет человек не из команды разработчиков. Если такой возможности нет, эту роль может взять на себя член команды. Для крупных плейтестов может потребоваться несколько координаторов, которые разделят обязанности по управлению рассадкой и оборудованием, общению с тестерами, проведению наблюдений и возможному вмешательству.

* * *

Большинство формальных тестов проходят в семь этапов.

1. Подготовка места плейтеста.

2. Прибытие плейтестеров.

3. Рассадка игроков перед началом теста.

4. Игровая сессия.

5. Подведение итогов плейтеста.

6. Уборка после плейтеста.

7. Анализ результатов.

Подготовка места плейтеста

Договорившись с плейтестерами о времени и месте проведения тестирования, сами приезжайте на место пораньше, чтобы все подготовить. Используйте список из раздела «Подготовка ко дню формального плейтеста» в конце главы 24 и возьмите все необходимое.

Каждый компьютер или консоль, на которых запущена копия игры, называются игровым местом (или же станцией). У вас может быть как одно место, так и несколько, в зависимости от вашей ситуации и ресурсов. Например, если у вас однопользовательская или многопользовательская онлайн-игра и есть пять мест, вы можете провести пять плейтестов одновременно. Если ваша игра представляет собой локальную многопользовательскую игру для двух игроков, вам понадобятся десять плейтестеров для пяти игровых мест.

Если вы тестируете одну и ту же игру с несколькими плейтестерами одновременно, установите между ними разделители, чтобы они не могли видеть экраны своих соседей. Можно дешево и легко сделать разделительные экраны из картонных коробок или листов пенопласта.

Подготовьте игровые места и все проверьте. Это займет некоторое время, поэтому начинайте задолго до прибытия плейтестеров.

• Установите проверенную, работоспособную версию игры, которую вы планируете протестировать. Если в нее были внесены изменения, также установите запасной билд, который ранее должен быть проверен на наличие серьезных проблем.

• Убедитесь, что экран и динамики исправно работают.

• Убедитесь, что специальное оборудование (например, игровой контроллер или VR-шлем) исправно работает.

• Убедитесь, что игра запускается без проблем, и воспользуйтесь запасным билдом или сделайте другие соответствующие шаги, если обнаружатся проблемы.

• В главе 26 мы обсудим сбор метрических данных о действиях игрока в игре. Если вы используете систему сбора показателей, убедитесь, что она работает исправно.

• Если вы установили разделители между игроками, убедитесь, что за ними не видно экрана соседей.

• Проверьте оборудование для прослушивания звука игры.

• Убедитесь, что ваш метод ведения заметок удобен и работоспособен (что ваше цифровое устройство заряжено и включено или что в вашем бумажном блокноте есть несколько чистых страниц, а в ручке не закончились чернила!).

• Убедитесь, что оборудование или программное обеспечение для записи аудио и видео заряжено и работает.

• Убедитесь, что у вас готовы опрос и ручки с карандашами, если вы используете печатные опросы.

• Убедитесь, что вопросы для заключительной беседы находятся под рукой.

• Положите подсказку с элементами управления (см. главу 12) на стол перед тем местом, где будет сидеть каждый тестер.

• Если вы планируете использовать письменную подсказку из-за известной проблемы в игре (см. главу 12), поместите ее где-нибудь вне поля зрения, если игрок должен увидеть ее только в определенное время. В противном случае положите ее на стол перед тем местом, где будет сидеть каждый игрок.

• Убедитесь, что ваши часы показывают правильное время и к ним легко обратиться во время теста.

Прибытие плейтестеров

Когда прибудут тестеры, координатор должен использовать предтестовый сценарий, чтобы поприветствовать их и поблагодарить за участие. Предоставьте им удобные места для ожидания с доступом к питьевой воде и туалетам. Если вы собираетесь использовать предварительный опрос, сейчас самое подходящее время дать его заполнить.

Используйте предтестовый сценарий, чтобы предоставить тестировщикам любую информацию, которая важна для успешности плейтеста (предупреждения о контенте игры, медицинские предупреждения, инструкции о согласии на запись видео и так далее). Сведите к минимуму ваше взаимодействие с плейтестерами сверх того, что диктует сценарий, но будьте вежливы. Если вам все же нужно выйти за рамки сценария, сначала хорошо продумайте, что вы скажете, чтобы случайно не выдать информацию, которая сформирует предвзятое отношение.

Рассадка игроков перед началом теста

Координатор должен проводить каждого игрока к месту, за которым он будет играть. Продолжая следовать сценарию, окажите им любую необходимую помощь, чтобы подготовиться к игре. Покажите каждому плейтестеру подсказку с элементами управления, если вы ее используете. Попросите их озвучивать свои мысли, если они не против. Ничего не сообщайте плейтестерам об игре, если это не предусмотрено сценарием.

Старайтесь избегать того, чтобы кто-либо из игроков ждал начала игры дольше, чем остальные. Мы хотим, чтобы у каждого игрока сложилось одинаковое впечатление о нашей игре, в том числе о том, как долго он смотрит на титульный экран. Как только все будет готово, координатор просит плейтестеров начать играть, и тестирование начинается.

Игровая сессия

Первая часть формального теста известна как игровая сессия. Это та часть, где плейтестеры играют в игру. Координатор – и все остальные, кто наблюдает за плейтестом, – должны отметить время начала сеанса игры.

На время игровой сессии каждый игрок должен быть предоставлен самому себе и иметь возможность играть в игру по-своему. Согласно нашим рекомендациям по проведению плейтестов, координатор и любые другие наблюдатели должны смотреть (а) за тем, что каждый игрок делает в игре, и (б) за тем, что они говорят о том, что они думают и чувствуют. Даже если плейтест записывается с помощью аудио и видео, наблюдатели все равно должны фиксировать как можно больше информации, делая заметки.

Если я использую бумажный блокнот, я рисую звезды и круги на полях, чтобы обозначить «важные действия» и вынести на передний план вопросы для дальнейшего обсуждения. Если я заношу свои наблюдения в электронную таблицу или документ, с той же целью я использую жирный шрифт и курсив. В пакетах программного обеспечения для записи тестов обычно есть функция внесения заметок к отдельным кускам видео, благодаря чему можно легко и быстро работать с видеоматериалами. Во время формального плейтеста я становлюсь почти роботом, отмечая все, что вижу. Я пытаюсь сделать так, чтобы при дальнейшем изучении записей все проблемы, которые есть в игре, сразу же бросились мне в глаза.

Координатор вообще не должен помогать плейтестеру, даже если он просит помощи. Если игрок действительно попросит о помощи, координатор должен извиниться и, следуя сценарию, напомнить ему, что он не может вмешиваться. При необходимости следуйте сценарию, чтобы предоставить игрокам письменную подсказку, которую вы подготовили.

Координатор должен следить за временем. В конце должно быть достаточно времени для второй части теста – подведения итогов с использованием опроса и заключительной беседы. Это может означать завершение игровой сессии до того, как плейтестер полностью пройдет игру, и ответственность за это решение лежит на координаторе.

Иногда во время игровой сессии возникают трудности: аппаратное обеспечение может выйти из строя, или плейтестер может повести себя непредсказуемо. Чем лучше вы подготовитесь к тестированию, тем более гладко все пройдет, но не расстраивайтесь, если что-то выйдет из-под контроля. К формальному плейтесту надо во многом подходить как к театральному выступлению: когда что-то идет не так, нужно просто смириться с этим и сделать все возможное, чтобы спасти ситуацию. Вы всегда можете так или иначе извлечь максимум пользы из неудачной партии, и на самом деле такое отношение нужно сохранять на протяжении всего процесса разработки игры.

Подведение итогов плейтеста

После сеанса игры наступает время для подведения итогов, когда каждый тестер заполняет опрос и принимает участие в заключительной беседе.

Продолжая следовать сценарию, дайте каждому плейтестеру опрос в момент окончания игровой сессии и попросите сразу же его заполнить. Не разговаривайте с плейтестером до того, как он все заполнит, за исключением вежливой просьбы передать опросник. Наша цель – запечатлеть свежие первые впечатления от игры. Лучше всего, чтобы плейтестеры оставляли ответы так же, как и играли в игру, – открыто заявляя о своих мыслях и чувствах.

Если вы проводите фокус-тестирование названия вашей игры, ключевого арта, дизайна логотипа или чего-либо, сделайте это сразу после завершения опроса, но до заключительной беседы. Для успешного фокус-теста вам придется поговорить с плейтестером, но попытайтесь свести ваш разговор к минимуму: вы пытаетесь узнать их мнение, а не навязать свое, даже если это выйдет случайно.

Затем проводится заключительная беседа. Будет ли она проходить один на один, что предпочтительнее, или в группе, что иногда более практично, зависит от обстоятельств и ресурсов вашей команды. Иногда плейтестеров или группу плейтестеров на время заключительной беседы отводят в другое место, где тихо и установлено записывающее оборудование.

Задайте плейтестерам открытые вопросы, которые вы подготовили, послушайте, что они скажут, и запишите их ответы. Если у вас заготовлены последовательности вопросов, предназначенные для того, чтобы направить ваших игроков к интересующим вас темам, используйте их. Если плейтестеры начнут говорить о чем-то интересном, но неожиданном, задайте им дополнительные вопросы, чтобы развить беседу. Если некоторые плейтестеры не находят что ответить, попробуйте по-другому сформулировать вопрос или переходите к следующему. Не всем легко даются такие беседы, поэтому не давите на человека, которому нечего сказать.

В конце концов заключительная беседа будет завершена или у вас просто закончится время аренды помещения. Последний случай встречается чаще – интересные разговоры о наших играх могут продолжаться бесконечно! Пришло время поблагодарить каждого плейтестера и рассказать им, как они помогли улучшить дизайн игры. Подарите им подарки, которые вы приготовили, или заплатите им, если это было частью соглашения. Если работа плейтестеров оплачивается, возможно, придется заполнить некоторые документы, прежде чем вы их отпустите.

Уборка после плейтеста

После того как плейтестеры уйдут, нужно будет кое-что сделать, чтобы привести в порядок место проведения тестирования. Обязательно соберите опросы и положите их в безопасное место. Все, кто делал заметки, должны удостовериться, что их наблюдения находятся в надежном месте, также вы должны обеспечить сохранность любых других важных документов, таких как заполненные формы согласия. Если вы используете систему сбора данных (см. главу 26), убедитесь, что данные показателей собраны вместе и созданы резервные копии. Плейтесты дорого обходятся с точки зрения времени, денег и усилий, так что не теряйте результаты.

Если команда разработчиков присутствовала на плейтесте, лучше немного выпустить пар, поделившись мыслями и чувствами по поводу плейтеста, пока вы приводите место тестирования в порядок. Настроение сразу после плейтеста часто становится будто окрыляющим, как бывает за кулисами, когда опустится занавес. Команда может быть измотана, испытывая облегчение от того, что все закончилось, но довольна своим результатом. Некоторые могут быть в восторге, если все пошло хорошо. Некоторые, напротив, могут чувствовать себя подавленными, если они получили обратную связь, не соответствующую их ожиданиям. Беседуя друг с другом, мы постепенно вернемся на землю. Это шанс напомнить друг другу, что плохо себя чувствовать – это нормально, но мы не должны отчаиваться, ведь получая неприятные отзывы об игре, мы узнаем о том, что нам следует исправить.

Анализ результатов

Формальный плейтест оставляет после себя огромное количество данных для анализа – настолько, что бывает трудно понять, с чего начать. Теперь у нас есть:

• заполненные опросы;

• заметки о том, как проходила игровая сессия (и, возможно, видео);

• заметки после заключительной беседы;

• результаты фокус-теста;

• метрические данные, если мы их собирали.

Анализ опроса по результатам плейтеста

Первое, что я делаю после формального плейтеста, когда начинаю оценивать его результаты, – изучаю опросы. Ответы плейтестеров – это много информации о мыслях и чувствах по поводу нашей игры. Как мы можем проанализировать эти данные быстрым и эффективным способом, чтобы составить представление о том, какой отклик наша игра находит у людей? На самом деле это очень просто, если мы используем электронную таблицу.

Я начинаю с шаблона на рис. 25.1, который можно найти на сайте этой книги. В этом шаблоне есть место для данных опроса десяти плейтестеров с примерами вопросов, которые я приводил в главе 24. Вы увидите, что в этом шаблоне есть столбец для возраста – вы можете добавить столбцы для любой демографической или психографической информации, которую вы собирали.

Независимо от того, был ли опрос заполнен на бумаге или с помощью онлайн-формы, перенести данные в электронную таблицу не составит труда. Даже если работать медленно и осторожно, обычно это занимает всего десять минут или около того. Конечно, можно написать инструменты для автоматизации этого процесса, и вы можете найти платные программы в интернете, которые сэкономят вам некоторое время.

Вы можете увидеть таблицу с данными опроса тестирования, куда уже внесены ответы плейтестеров, на рис. 25.2.

Формулы в строках с надписями «СРЕДНЕЕ ЗНАЧЕНИЕ по ГРУППЕ» и «МЕДИАНА по ГРУППЕ» вычисляют средние и медианные значения для каждого вопроса, полученные из ответов всех участников плейтеста. Среднее значение – это сумма значений ответов всех игроков, деленная на количество игроков. Медианное значение – это число, которое отделяет верхнюю половину всех ответов игрока от нижней половины: иногда это дает лучшее представление о «среднем» ответе, чем среднее арифметическое. Когда все данные будут введены в электронную таблицу, мы поймем общее – групповое – мнение плейтестеров о нашей игре, просто взглянув на строки СРЕДНЕЕ ЗНАЧЕНИЕ по ГРУППЕ и МЕДИАНА по ГРУППЕ. Конечно, в большинстве случаев чем больше число у конкретного вопроса, тем больше игрокам понравился этот аспект игры.

Игры, которые были тщательно разработаны концентрическим методом и регулярно проверялись плейтестами, обычно набирают где-то от трех до пяти баллов за каждый вопрос при первом плейтесте. Если же нет, то серьезные проблемы, возможно, остались незамеченными или нерешенными в ходе разработки вплоть до этого момента. Если игра набирает низкие баллы по определенному вопросу, то дизайнеры должны спросить себя: есть ли у нас здесь реальная проблема? Аномальные ли это результаты? Или это сделано специально?

Рис. 25.1. Электронная таблица-шаблон

Рис. 25.2. Электронная таблица с внесенными ответами плейтестеров

Я могу представить себе игру, которая намеренно разработана, чтобы вызвать негативную реакцию у игроков. Если низкий балл соответствует намерениям дизайнеров, то мы можем смело игнорировать – или даже приветствовать – низкие баллы. В результатах плейтеста мы всегда ищем сюрпризы: как приятные сюрпризы – мы не думали, что им понравится наша странная механика или они поймут нашу историю, но они поняли! – так и неприятные – мы думали, что наш арт или звуковой дизайн блестящие, но плейтестеры посчитали их довольно посредственными.

Формальные плейтесты приносят максимум пользы, когда они проводятся в виде серии тестов в течение недель или месяцев. Для отслеживания изменений в восприятии игры тестерами в электронной таблице есть строки СРЕДНЕЕ ЗНАЧЕНИЕ по ГРУППЕ С ПРОШЛОГО ТЕСТА и МЕДИАНА по ГРУППЕ С ПРОШЛОГО ТЕСТА, куда вы можете внести результаты, полученные в предыдущем плейтесте. В строках, помеченных как ДЕЛЬТА СРЕДНЕГО ЗНАЧЕНИЯ С ПРОШЛОГО ТЕСТА и ДЕЛЬТА МЕДИАНЫ С ПРОШЛОГО ТЕСТА, формула вычитает ваши предыдущие результаты из ваших текущих результатов. Вы можете применить условное форматирование в электронной таблице и выделять цветом ячейки, чтобы указать, когда общий балл по конкретному вопросу вырос, снизился или остался прежним.

Конечно, мы хотим, чтобы наши показатели со временем росли. Работая над играми серии Uncharted, от плейтеста к плейтесту мы наблюдали небольшой рост в оценках геймплея, графики и звукового оформления по мере того, как мы завершали и полировали игру. Даже если средний балл вырастал всего с 4,3 до 4,4, мы могли бы быть уверены, что недавние изменения положительно повлияли на игру, а не повредили ей. Такого рода непрерывное проведение формальных плейтестов очень обнадеживает на фоне субъективного процесса создания произведений искусства, которым является гейм-дизайн.

Анализ наблюдений и видео игровой сессии

В главе 12 я дал вам довольно много советов по оценке обратной связи, которую мы получаем из наблюдений за самим плейтестом и из заключительной беседы. Все эти советы также применимы и к формальному плейтесту. В частности, подумайте, можно ли классифицировать сказанное как (1) надо починить, (2) возможно, надо исправить или (3) это новая идея, и составьте соответствующий список. К проведению формальных плейтестов мы уже не столько исследуем возможные направления нашей игры, сколько создаем ее, так что будьте осторожны, гоняясь за слишком большим количеством новых идей. Это не значит, что никаких открытий, которые изменят нашу игру в лучшую сторону, уже не будет, но сосредоточьтесь на поиске и устранении проблем.

Я считаю, что для многих видов игр простое наблюдение за тем, как кто-то играет, может рассказать почти все, что нам нужно знать о том, как улучшить игру. Довольно легко прочитать психическое состояние игрока по его действиям в игре, языку тела, а иногда и выражению лица. Вы можете определить, понимает ли игрок, что он может делать и что он должен делать, по действиям, которые он предпринимает в игре. Вы можете увидеть, объединяет ли он ранее изученные концепции новыми способами, которые он считает интересными. Вы легко можете определить, интересно ли игроку, скучно или весело, просто по тому, как он сидит, и его восклицаниям. Наши заметки с наблюдениями за игровой сессией и любые другие записи, которые мы делаем, содержат эту информацию.

В таком приключенческом боевике, как Uncharted, легко определить, когда игрок чего-то не замечает в игре или забывает о своей цели. Когда плейтестер неоднократно пробегает мимо объекта, с которым он должен взаимодействовать, это верный признак того, что игрок его не видит, – возможно, объект выглядит как часть фона. Если он подходит к объекту для решения какой-то головоломки, недолго его использует, но затем забывает про него, значит, игрок замечает этот объект, но не считает его важным.

Важно уделить время просмотру заметок, которые мы делали во время плейтестов, а также попробовать вспомнить, что мы видели. Воспоминания часто искажаются из-за эмоций, как мы уже не раз обсуждали, и незначительные вещи могут оказаться важными. Когда я просматриваю свои заметки после теста, я ищу повторяющиеся замечания, указывающие на серьезную проблему, которую следует решить: «Игрок не может найти дверь, ведущую с уровня» или «Игрок думает, что он уже нажал на все нужные переключатели». Я переношу свои заметки в списки (1) надо починить, (2) возможно, надо исправить или (3) новая идея, чтобы позднее обсудить их с командой.

Видеозаписи игровых сессий и метрические данные могут дать нам более глубокое представление о проблемах, с которыми сталкивались наши плейтестеры. С помощью видео мы можем точно увидеть, что делал конкретный человек, когда пытался пройти какую-то часть игры, если мы отметили, какой момент нам интересен (в противном случае найти интересующий фрагмент среди нескольких часов отснятого материала окажется проблематичным). Мы можем использовать метрические данные, чтобы получить представление о том, как в игру играли отдельные плейтестеры или целые группы плейтестеров – мы обсудим это в главе 26.

Анализ заключительных бесед

Далее я анализирую результаты заключительных бесед. Если я не присутствовал на некоторых или всех беседах, я стараюсь узнать, что люди говорили о нашей игре, из записей. Онлайн-сервисы для преобразования аудиозаписи в текст могут упростить знакомство с ними. Поскольку мы задавали одни и те же основные вопросы каждому игроку (даже если дополнительные вопросы расходились), мы можем сравнить то, что говорили разные плейтестеры, чтобы получить хорошее представление о том, как приглянулась наша игра разным игрокам.

Главный открытый вопрос может звучать так: «Что вы почувствовали, играя в игру?» Соответствуют ли ответы плейтестеров целевому опыту пользователя? Конечно, как дизайнеры мы хотим достичь целей нашего проекта, но не сбрасывайте со счетов то, что вы не ожидали услышать, особенно если плейтестеры высоко это оценили. Как сказал режиссер Спайк Ли, «очень часто вы получаете похвалу за то, что оказалось в вашем фильме непреднамеренно». То же самое относится и к играм, может быть, даже в большей степени из-за их интерактивности.

Оценка обратной связи – это субъективный процесс. Не все, что говорится в беседе, можно принимать за чистую монету: многое из услышанного надо верно интерпретировать и взвесить. Привлекайте к этому процессу других людей. Зачастую легче понять отзывы плейтестеров, когда вы работаете вместе с товарищем по команде, другом или кем-то, кто знает вашу игру и понимает ваши творческие цели.

Анализ результатов фокус-теста

Если вы включили фокус-тест названия игры, ключевого арта, дизайна логотипа или чего-либо еще в опрос или заключительную беседу, надеюсь, это подтвердило то, что вы уже знали: вы выбрали хорошее название, хорошо его воплотили в графическом дизайне логотипа и подобрали отличный ключевой арт. Если же вы получили другие результаты, пришло время еще поработать над тем, что плохо себя показало.

Как только вы подготовите альфа-версию игры, нельзя будет откладывать окончательную доработку названия игры. Вскоре вам предстоит общение со своей потенциальной аудиторией и создание аккаунтов в социальных сетях, а для этого вам потребуется название игры. Вашему проекту нужна сильная идентичность, которая будет частично понятна через название, ключевой арт и логотип, поэтому все три будут важны, когда вы представите свою игру публике. Мы вернемся к этой теме в главе 30.

Какие действия предпринимать на основе обратной связи по результату формального плейтеста

По каждому низкому баллу, полученному в ответ на конкретный вопрос, по каждому выводу, который мы делаем, наблюдая за игрой плейтестеров, и по каждому отзыву, полученному в ходе заключительных бесед, мы должны принять решение относительно наших дальнейших действий. Хотим ли мы работать над улучшением наших результатов в определенной категории опроса для следующего формального плейтеста? Будем ли мы работать над тем, чтобы что-то исправить или добавить что-то новое на основе наблюдений за сеансом игры или ответов на вопросы беседы? Сколько различных проблем мы уже разбираем? Сколько времени у нас есть, если учесть все, что нам осталось реализовать?

Для меня правильная оценка всей обратной связи формального плейтеста сводится к простому методу: просто составьте список всего того, что было определено как проблема, потенциальная проблема и новая идея. Расставьте акценты как очень важные, относительно важные и менее важные. При необходимости добавьте еще несколько уровней приоритезации – ваши списки могут оказаться довольно длинными.

Затем решите, чем вы собираетесь заняться в первую очередь. Поскольку я работаю концентрическим методом, обычно я решаю проблему с чем-то, что уже есть в игре, а потом уже добавляю что-то новое. Помните: игроки не знают о том хорошем, что могло бы быть в вашей игре, но они обязательно заметят то, что в ней работает плохо.

Отличной идеей будет дальнейшая классификация вашего списка. По моему опыту, большинство проблем, которые я выявляю во время плейтеста, попадают в одну из этих трех категорий.

• Баги – игра дает сбои, вылетает или делает что-то еще, чего делать не должна.

• Проблемы с контентом – возможно, игроки не замечают интерактивный объект из-за особенностей текстур или они не видят вход в коридор из-за слишком темного освещения.

• Проблемы с дизайном – дизайн игры не работает на создание опыта, который мы хотим дать нашим игрокам.

Очень часто эти три типа проблем пересекаются. Баг или проблема с контентом могут создать проблему с дизайном. Поэтому рекомендуется решать эти проблемы в указанном выше порядке. Сначала исправьте баги – практически невозможно оценить забагованную игру, и вы должны немедленно исправить все, что обнаружите. Затем устраните проблемы с контентом, особенно если они решаются быстро и легко. Изменить текстуру или освещение обычно довольно просто, а вот для новой сложной анимации потребуется больше времени и некоторое планирование. Когда баги и простые проблемы с контентом будут устранены, вы сможете гораздо вернее оценить проблемы с дизайном.

Иногда баг привносит нечто положительное в опыт игрока, как гласит старая шутка разработчиков: «Это не баг, а фича». Вам придется решить, что делать с этими счастливыми случайностями, по мере их возникновения. Если вы сомневаетесь, обратитесь к целевому опыту пользователя и таблице макродизайна.

Помните, что изменения, которые вы вносите, пытаясь исправить ситуацию на основе полученной обратной связи, могут – и, скорее всего, будут – иметь непредвиденные последствия, с которыми вам также придется иметь дело. Вот почему хорошо провести несколько раундов формальных плейтестов, чтобы ваша игра прошла проверку качества, и найти и устранить последние баги и проблемы с контентом, а также решить оставшиеся проблемы с дизайном.

Как справиться со сложной обратной связью

При любом плейтесте, как бы мы ни старались избегать оборонительной позиции, нам может быть сложно справиться с какой-то обратной связью. В таком случае лучше немного дистанцироваться от работы: взять выходной, позаниматься спортом, съесть что-нибудь вкусное, пораньше лечь спать или повеселиться с друзьями. Возвращайтесь к оценке неприятных отзывов с холодной головой и уверенностью, что вы талантливый и находчивый гейм-дизайнер. У вас все получится.

Обратная связь затрудняется, когда вы выявляете серьезную проблему, но понятия не имеете, как ее исправить. В подобной ситуации начните составлять списки плюсов и минусов. Если бы вы предприняли определенные шаги, как это помогло бы и чему это повредило бы? Привлеките другого человека, который поможет вам составить этот список. Он может найти решение, которое вы не рассматривали, или по-другому сформулировать плюсы и минусы.

Обратная связь затрудняется, когда вам кажется, что она ничего не привносит в вашу работу. Большинство творческих людей ценят конструктивную критику, но иногда все результаты формального плейтеста кажутся деструктивными. Мы не можем ожидать, что наши плейтестеры всегда будут оценивать игру конструктивно – сами они, вероятно, не гейм-дизайнеры. (Хотя мы можем и должны ожидать вежливости от плейтестеров. Не терпите оскорбительных ситуаций. Немедленно сворачивайте плейтест, если игрок оскорбляет вас или иным образом унижает вас и ваш труд.)

Получая неконструктивную, на ваш взгляд, обратную связь, вы, как разработчик игры, должны найти решение. Мыслите творчески, рассматривая проблему со многих точек зрения, и помните, что в сложной динамической системе игры небольшое изменение может привести к неожиданно хорошему результату.

Переходим к следующему раунду формальных плейтестов

Как только мы проанализируем отзывы, решим, что будем делать дальше, и внесем некоторые исправления и изменения в нашу игру, настанет время для еще одного формального плейтеста. В следующем плейтесте мы узнаем, улучшили мы игру, сделали ее хуже или же ничего не поменяли. Возможно, мы устранили одну проблему, но создали другую.

Опять же, формальные плейтесты лучше всего проводить сериями так часто, как только можно, начиная с альфа-версии и заканчивая непосредственно релиз-кандидатом. Наши первые формальные плейтесты будут живыми, непредсказуемыми и полными сюрпризов. А последние – если все пройдет хорошо – подтвердят, что наша игра получилась такой, как мы хотели.

* * *

Процесс проведения формальных плейтестов – это хлопотная, ориентированная на детали работа, но в то же время чрезвычайно увлекательная и приносящая удовлетворение. Если вы обнаружите, что вам нравится этот вид работы, разузнайте побольше о пользовательских исследованиях и взаимодействии с пользователем (UX-дизайн). Как пишет дизайнер Мун Лум в своей статье Is UX Design a Separate Practice from Game Design? («Является ли UX-дизайн отдельной практикой от гейм-дизайна?») для Prototypr.io, игровые студии все чаще нанимают в свои команды юзабилити-специалистов: «По мере внедрения в игры все более глубоких и сложных механик и систем появляются новые роли вроде UX-дизайнера. Можно сказать, создана новая должность: большинство UX-дизайнеров в игровой индустрии были когда-то гейм-дизайнерами или имели опыт разработки игр»[160].

Это отличный карьерный путь для людей, которым нравится заниматься предметным гейм-дизайном с объективно измеримыми результатами. Мы обсудим темы измерения и творчества в нашей следующей главе, где мы будем собирать количественную информацию о том, как играют наши игроки, и использовать ее для улучшения наших игр.

Глава 26

Игровые метрики

Телеметрия – это слово, которое означает «измерение на расстоянии», от греческих корней tele (далеко) и metron (измеряю). Этот термин используется в сфере разработки программного обеспечения для описания практики сбора данных о чем-то, что происходит где-то в другом месте[161]. Вы, вероятно, знаете, что большая часть используемого вами программного обеспечения собирает данные о том, что вы делаете и когда вы это делаете, а затем отправляет эти данные «домой» – разработчику программного обеспечения или кому-нибудь еще. Вопросы конфиденциальности и правомерности таких действий часто (и справедливо) становятся предметом жарких дебатов.

Специалисты по взаимодействию человека и компьютера (HCI) иногда называют телеметрию инструментарием, но разработчики игр чаще называют ее игровыми метриками или аналитикой. Использование игровых метрик выходит далеко за рамки простого сбора данных и превратилось в практику гейм-дизайна, в которой, интерпретируя полученные данные и тем самым понимая, как играют реальные игроки, разработчики улучшают геймплей. Теперь эта практика – важная часть игрового бизнеса.

Конечно, цифровые игры постоянно проводят измерения. Они записывают, какие кнопки нажимает игрок и когда. Они могут проверить внутренние часы, чтобы узнать, который сейчас час в реальном мире. Можно запросто написать код для сбора данных о событиях в игре, которые мы можем использовать для анализа гейм-дизайна. До сих пор мы рассматривали различные способы изучения реакции игроков на наши игры: путем наблюдения, с помощью опросов и заключительных бесед. Мы также можем использовать игровые метрики, чтобы получить подробную информацию о том, что делают плейтестеры в играх. А это, в свою очередь, даст нам более глубокое понимание получаемого ими опыта.

Вы услышите, как разработчики ссылаются на аналитику при обсуждении игровых метрик, необходимых для определения того, как игры зарабатывают деньги. Игровая аналитика обычно фокусируется на регулярности, с которой игроки возвращаются в игру, и на том, сколько денег они на нее тратят, но она может также подробно показать, что игроки делают внутри игры. Вы можете найти много книг и статей в интернете о бизнес-аналитике игр. Вместо того чтобы сосредоточиваться на бизнес-стороне телеметрии, в этой главе мы рассмотрим, как мы можем лучше изучить гейм-дизайн по поведению игроков, используя простые для понимания и реализации методы.

Игровые метрики в Naughty Dog

Когда я присоединился к Naughty Dog в 2004 году, использование игровых метрик уже давно стало частью культуры дизайна студии. Начиная с Crash Bandicoot, Naughty Dog собирали метрические данные, чтобы убедиться, что в их играх представлен идеальный уровень сложности для игроков – не слишком сложный и не слишком легкий.

В каждом формальном плейтесте, который проводился для однопользовательского режима игр Uncharted, мы собирали записи большого количества данных о прогрессе игроков: каждый раз, когда игрок достигал нового чекпоинта (контрольной точки автоматического сохранения), записывалось время, прошедшее с момента последней контрольной точки. Мы также записывали количество попыток плейтестера добраться до чекпоинта – по сути, сколько раз он умирал, пока до него шел.

В конце формального плейтеста мы экспортировали все эти данные в электронную таблицу (а позже в специально созданный инструмент) и начинали составлять таблицы и графики для быстрого просмотра данных. В основном мы выстраивали полученные данные таким образом, чтобы можно было просматривать информацию от всех десяти игроков одновременно, но мы также могли проверять данные по отдельным игрокам.

В частности, мы смотрели на среднее, медианное, минимальное и максимальное количество попыток для каждого чекпоинта, полученное из данных всех десяти плейтестеров. На рис. 26.1 вы можете увидеть таблицу попыток игроков добраться до контрольной точки, которую мы определили как потенциально проблемную из-за уровня сложности. Мы выделяли цветом числа, превышающие определенные пороговые значения. Например, то, что по среднему или медианному значению игрок добирался до чекпоинта только после шести попыток, служило тревожным звоночком, что в этой части геймплей очень усложнен. Мы устанавливали эти пороговые значения на основе того, насколько сложной мы хотели сделать игру в целом, но мы также назначали их и для конкретных контрольных точек, когда мы намеренно хотели, чтобы игрок потерпел много неудач за короткий промежуток времени и поволновался, а сложность этой части игры ему надолго запомнилась.

Рис. 26.1. Таблица, показывающая количество попыток пройти потенциально трудные места в Uncharted 3: Drake's Deception, построенная на основе метрических данных десяти игроков во время формального плейтеста. Изображение предоставлено: UNCHARTED 3: Drake's Deception™ © 2011 Sony Interactive Entertainment LLC. UNCHARTED 3: Drake's Deception является торговой маркой Sony Interactive Entertainment LLC. Создано и разработано компанией Naughty Dog LLC

Рис. 26.2. График, показывающий прогресс тестеров в Uncharted 3: Drake's Deception, составленный на основе метрических данных девяти игроков во время формального теста. Изображение предоставлено: UNCHARTED 3: Drake's Deception™/© SIE LLC. Создано и разработано компанией Naughty Dog LLC

Как только мы скомпилируем метрические данные в легко читаемый формат, мы поделимся ими с гейм-дизайнерами в команде, чтобы они смогли исследовать возможные проблемы и устранить их. Таким образом мы создадим призму, через которую можно посмотреть на то, как нашу игру проходят реальные люди – те же люди, которые позже могут купить нашу игру.

Не менее полезны и временные данные по каждому чекпоинту. На рисунке 26.2 показан график, который суммирует то, как девять тестеров прошли Uncharted 3 на одном из первых формальных плейтестов. На горизонтальной оси представлены названия контрольных точек, до которых должен добраться игрок, на вертикальной оси – общее количество времени, которое каждый игрок провел в игре до достижения каждой контрольной точки. (Помните, мы записывали время между контрольными точками, но в электронной таблице легко вычислить и промежуточный итог общего времени, затраченного на каждый чекпоинт.)

Вы можете легко увидеть, как быстро или медленно каждый игрок проходит игру. Там, где линия игрока становится круче, он продвигается медленнее, либо потому что игра стала сложнее, либо потому что он ищет скрытые сокровища, разбросанные по игре, либо, возможно, потому что он залюбовался видами. Можно узнать больше о том, что происходит, сравнив данные о времени прохождения с данными о количестве попыток добраться до чекпоинта.

Обратите внимание, что один игрок продвигается по игре намного быстрее, чем другие, а еще один игрок сразу отстает и позже покидает тестирование. Остальные игроки продвигаются примерно с одной скоростью, особенно в первой трети игры, которая была задумана как довольно легкая. По мере прохождения второй трети игры темпы увеличиваются. Пара игроков почти вплотную борются за второе место, а еще один постепенно отстает все сильнее и сильнее. Занятно то, что эту закономерность мы наблюдали почти в каждом формальном тестировании с самыми разными группами тестеров. В этом тесте только один игрок фактически дошел до конца игры, но в более поздних тестах мы убедились, что у всех хватало времени на полное прохождение.

Мы использовали метрические данные, чтобы получить представление о многих аспектах игр Uncharted. Как часто игроки брали новое оружие, недолго его использовали, а затем меняли на свое старое оружие? Это было легко узнать по метрическим данным. Как часто игроки пытались отбрасывать гранаты в механике отбрасывания, которую мы недавно внедрили? Метрические данные помогли нам точно настроить интерфейс и элементы управления этой новой механикой.

Метрические данные также помогли нам решить неприятную повторяющуюся проблему в играх Uncharted, которая преследовала нас с самого начала серии. Игровое окружение в серии Uncharted визуально очень насыщенное – благодаря блестящей работе художников на любом скриншоте из игры происходит сразу очень многое. И, как и в любой видеоигре, на фоне всей этой визуальной информации легко потерять что-то важное для геймплея. Мы обнаружили, что зачастую игроки с трудом определяют места, за которые можно зацепиться (элементы окружения, на которые наш персонаж игрока, Нейтан Дрейк, может запрыгнуть или где он может повиснуть). Мы считали это катастрофой для дизайна игры, потому что это мешало игроку перейти к следующей части истории. Проблема усугублялась тем фактом, что игроки отвлекались на то, что выглядит так, как будто туда можно залезть, но на самом деле нет.

Решение этой проблемы было довольно блестящим, и оно пришло от трех моих бывших коллег по Naughty Dog: Тигана Моррисона, Трэвиса Макинтоша и Ярослава Синецкого. Эти умные люди создали систему, которую мы использовали только на формальных тестах: эта система записывала координаты (x, y, z) в трехмерном пространстве игры каждый раз, когда плейтестер пытался запрыгнуть туда, куда не позволяла игра.

Эти координаты записывались в базу данных нашей сети, и по окончании плейтеста мы могли экспортировать все эти данные (по каждому плейтестеру) обратно в игру, запущенную в наших системах разработки. Стоило нам выбрать нужную опцию в меню отладки игры, как появлялись маленькие красные сферы, отмечающие места, где пытались запрыгнуть игроки. Вы можете увидеть пример на рис. 26.3.

Мы назвали это системой плохих прыжков, и мы сразу увидели, что плохие прыжки группировались под объектами, которые выглядели так, будто туда можно залезть, но куда Дрейк на самом деле не мог забраться. Скопления красных сфер ясно подсказали нам, что нужно исправить. В течение нескольких дней после каждого теста художники по окружению и ответственные за каждый уровень гейм-дизайнеры садились вместе и проходили уровни с включенными сферами. Они обсуждали изменения, которые можно было бы внести в художественное оформление или дизайн уровня, чтобы исправить ситуацию, когда наши тестеры ошибочно принимали фоновые текстуры за места, куда можно залезть.

Это не только помогло улучшить дизайн нашей игры, но и облегчило процесс сотрудничества между художниками и дизайнерами. Конечно, художникам и дизайнерам иногда бывает трудно прийти к согласию, если внешний вид игры вступает в противоречие с соображениями, продиктованными геймплеем. Система плохих прыжков предоставила нам очень объективную информацию о важности или незначительности выявленной проблемы, и это здорово повлияло на плодотворное сотрудничество художников и дизайнеров.

Рис. 26.3. Система плохих прыжков в Uncharted 3: Drake's Deception показывает, где игроки пытались забраться и потерпели неудачу. Изображение предоставлено: UNCHARTED 3: Drake's Deception™ © SIE LLC. Создано и разработано компанией Naughty Dog LLC

Эти примеры взяты из однопользовательского режима игры в жанре приключенческого боевика, но метрические данные могут положительно изменить дизайн многих типов игр, от соревновательных и спортивных, где мы хотим исследовать частоту использования определенных способностей, до интерактивных повествовательных, где мы хотим увидеть, как часто игроки выбирают определенный сюжетный путь. Я призываю вас выйти за рамки очевидного и найти новые оригинальные способы сбора данных, которые дадут вам основательные знания и новое понимание того, как именно ваши игроки на самом деле играют в игры.

Внедрение метрик в вашу игру

Для внедрения системы игровых метрик часто достаточно простого кода, хотя эта работа может потребовать от вас изучения некоторых новых вызовов функций. Есть много готовых программ, которые вы можете использовать и которые могут вообще не требовать от вас никакого кодирования. На момент написания книги движки Unity и Unreal уже предоставляют встроенные аналитические плагины, которые относительно просты в использовании.

Начните с определения того, какие данные вы хотите собрать. Если вы не занимались этим раньше, то хорошо бы начать только с одного или двух типов данных. Затем вы добавите и другие. Проведите мозговой штурм со своими товарищами по команде, чтобы определить, какие метрики вы хотите собирать и что нового вы сможете узнать из полученных данных.

• Обычно собираемый тип метрических данных фиксирует, сколько времени игрок проводит в каждой части игры.

• Если игрок проигрывает и начинает игру заново, можно подсчитать количество попыток, которые он делает для завершения каждого уровня.

• Вы можете записывать, когда и где игрок использует предоставленную вами механику.

• Вы можете отслеживать значения, связанные с ресурсами, такими как очки опыта, которые игрок зарабатывает по мере прохождения, или сколько игровых денег у него есть на данный момент.

Подумайте о степени детализации ваших данных: как часто вы к ним обращаетесь и, следовательно, какой объем данных вы собираете в целом. Не стоит жадничать: я встречал системы метрик, которые приводили к сбою самих игр, потому что данные фиксировали каждый кадр, и выходной файл становился огромным. Нужный уровень детализации собираемых данных будет зависеть от типа создаваемой вами игры и ее общей длительности.

Если вы хотите создать собственную систему данных, вам нужно написать скрипт, который будет активен на протяжении всей игры. Этот скрипт будет содержать функцию, которая будет вызываться всякий раз, когда вы хотите получить некоторые данные об игре, копировать одно или несколько значений переменных в строку с понятным для человека текстом, а затем добавлять эту строку в текстовый файл, записанный на жесткий диск компьютера. (Строка также может быть записана где-нибудь в базу данных.)

Вы можете вызывать функцию либо всякий раз, когда в игре происходит что-то конкретное, либо через регулярные промежутки времени. Например, всякий раз, когда игрок нажимает кнопку прыжка, система записывает текущее время в игре и копирует его в строку, которой предшествует текст: «Игрок прыгнул». Или раз в десять секунд система записывает текущее время в игре и уровень здоровья персонажа игрока, предоставляя вам относительно детальную информацию о том, как здоровье растет и падает с течением времени.

Вы можете найти ресурсы, необходимые для настройки системы данных для вашей игры на сайте этой книги.

Согласие на сбор метрических данных

Разрабатывая программное обеспечение для сбора информации об игроках, мы должны остановиться и подумать, насколько этично мы поступаем. Право на неприкосновенность частной жизни – ценность многих сообществ в мире, а в некоторых странах оно закреплено в конституции или законе. Как разработчики мы должны гарантировать соблюдение прав человека и запрашивать согласие наших игроков на сбор данных.

Согласие может быть необязательным для сбора данных о том, когда игрок прыгает или открывает дверь, но если вы запрашиваете личную информацию об игроке (например, связанную с его убеждениями или состоянием здоровья), то вы должны получить разрешение на запись этой информации в ваших метрических данных. Вы можете попросить ввести нужную вам информацию на загрузочном экране игры. Если игрок не дает согласия, то не записывайте его данные – ни в коем случае не пренебрегайте правами другого человека.

Тестирование систем метрических данных

Важно регулярно тестировать системы данных, чтобы убедиться, что они работают исправно. По моему опыту, эти системы – одни из самых хрупких составляющих игры, и, возможно, причина в том, что они работают бесшумно, а потому легко не заметить, что они сломались. Однажды в начале моей карьеры по окончании дорогостоящего формального плейтеста мы не получили вообще никаких метрических данных из-за простого сбоя системы, которого мы не заметили.

Протестировать эти системы довольно легко: просто сыграйте в игру в тех же условиях, что и плейтестеры, и убедитесь, что нужные вам данные успешно записываются. Следите за незначительными различиями между тем, как вы тестируете игру, и тем, как она будет тестироваться в условиях плейтеста. Например, распространенная проблема с метрическими данными заключается в том, что между плейтестами из игры не выходят и ее не перезапускают, что приводит к путанице в системе.

Визуализация метрических данных

После формального плейтеста нам нужно визуализировать метрические данные, чтобы их было легче понять. Информационный дизайн и визуализация данных – это перспективные области, достойные внимания гейм-дизайнеров. Книги Эдварда Р. Тафти Envisioning Information и Эллен Луптон «Драматургия дизайна» дают содержательные комментарии о методах, которые мы можем использовать для превращения чисел в нарратив, понятный людям.

Многие учатся представлять данные еще в школе, создавая линейные графики, гистограммы и круговые диаграммы, – и это отличные подходы к визуализации метрических данных. Каждая программа для работы с электронными таблицами включает в себя инструменты для создания графиков из таблиц данных. Их освоение может занять немного времени, но обычно они просты в использовании и эффективны. Не забудьте обозначить оси, включить легенду, чтобы четко описать представленные данные, и использовать выделение цветом. Таблицы с данными особенно эффективны, когда в них используется условное форматирование для выделения важных чисел, отчего те «выстреливают», как показано на рис. 26.1.

Другой популярный тип визуализации игровых метрик – тепловая карта, двух- или трехмерное представление мест на уровне, где в ходе игрового процесса произошло конкретное событие. Вы можете применить инструменты построения графиков в электронной таблице для создания этой карты или запрограммировать специальный инструмент внутри вашего игрового движка для точного отображения окружения игры. Поищите в интернете «тепловые карты игр», и найдете множество примеров из ваших любимых игр.

Старайтесь мыслить нестандартно и руководствоваться особенностями и возможностями дизайна выбранного типа игры. Как игровые метрики помогут вам стать более уверенными в том, что ваша игра развивается так, как вы намеревались? Что станет вашей «системой плохих прыжков» и как метрические данные помогут вам разрешить непростую проблему новаторским способом?

Чек-лист действий по внедрению систем данных

✓ Проведите мозговой штурм на предмет того, какие данные вам пригодятся для дальнейшего улучшения игры.

✓ Продумайте механизм записи этих данных (просто в текстовый файл или в базу данных).

✓ Получите согласие ваших плейтестеров на сбор метрических данных.

✓ Проверьте, работает ли система сбора данных, сыграв в игру в тех же условиях (или максимально приближенных к ним), в которых будет проходить формальный плейтест.

✓ Проверьте исправность систем сбора данных, просмотрев информацию, которая была выведена системой во время плейтеста.

✓ Используя тестовые данные, начните разрабатывать способы их визуализации для дальнейшей работы с ними.

✓ Протестируйте систему еще раз непосредственно перед формальным плейтестом.

✓ Используйте систему сбора данных в формальных плейтестах.

✓ Визуализируйте данные, которые получите во время плейтестов, и используйте то, что узнаете о поведении ваших плейтестеров, для улучшения дизайна игры.

Границы использования игровых метрик

Игровые метрики – это инструмент, и, как и любой инструмент, их можно использовать как во благо, так и во вред. Быть строгим в такой технической форме искусства, как наша, необходимо, и UX-исследователи ценят научный подход. Но я твердо верю, что вам не следует использовать эти техники больше, чем вам подсказывают инстинкты креативного дизайнера и художника.

Я использую метрики, чтобы убедиться, что моя игра дает игрокам тот опыт, который я хочу им дать. Я пытаюсь обнаружить наличие того, что может помешать моей игре достичь желаемого результата. Я сопротивляюсь искушению следовать за метрическими данными в том направлении, которое противоречит целям моего проекта или моим личностным ценностям. Вам придется решить для себя, в зависимости от того, кто вы, что вы цените и в каком контексте создаете игры – коммерческом, художественном или академическом, – в какой мере собираетесь использовать игровые метрики.

Мне нравится эта цитата, часто приписываемая Альберту Эйнштейну, но, скорее всего, принадлежащая социологу Уильяму Брюсу Кэмерону: «Не все, что можно сосчитать, считается, и не все, что считается, можно сосчитать»[162]. Вам решать, что считать, а что считается.

Глава 27

Альфа-фаза и отслеживание ошибок

В процессе создания игр на этапе продакшена есть два майлстоуна: альфа и бета (рис. 27.1). К альфе, в середине этапа продакшена, наша игра будет завершена с точки зрения фичей конкретных отрезков геймплея, так что мы сможем пройти ее полностью, пускай и с плейсхолдерами. К бете, в конце этапа продакшена, игра будет закончена в плане своего контента, а значит, все, что должно быть в игре, уже будет в ней, готовое к доработке.

Рис. 27.1. Этапы альфа- и бета-версий в процессе производства. Авторы изображения: Габриэла Пурри Р. Гомес, Мэтти Розен и Ричард Лемаршан

Но в этапе полного продакшена есть еще две фазы: разработка альфа-версии (альфа-фаза) и разработка бета-версии (бета-фаза). В главе 23 мы говорили об обеспечении качества: эксперты QA-отдела тщательно тестируют игру, выискивая возможные баги и помогая дизайнерам их устранить. В почти универсальном определении альфа-фазы значится, что этот этап начинается, когда проект попадает на QA-тестирование. Этап альфа-фазы заканчивается майлстоуном альфа-версии, а затем начинается бета-фаза, которая в итоге приведет нас к очередному майлстоуну. Даже если у вас нет специального QA-отдела, ваш проект все равно может надлежащим образом пройти этап альфа-фазы, если вы просто начнете отслеживать ошибки в игре. Сейчас мы рассмотрим методы отслеживания ошибок.

Когда какая-то часть программного обеспечения находится на стадии альфы, оно иногда глючит, нестабильно и по большей части неполно. Но в разработке игр глючное и нестабильное программное обеспечение крайне нежелательно. Нужно поддерживать нашу игру в играбельном состоянии на протяжении всего производства. Таким образом, каждый раз, когда мы добавляем новую механику или какой-то контент, мы должны проводить плейтест, чтобы оценить влияние нововведений на игру в целом. Вот почему мы разрабатываем концентрическим методом, который мы обсуждали в главе 13.

Однако по мере приближения к альфа-майлстоуну нам, вероятно, придется отойти от концентрической разработки, чтобы включить в игру все фичи и плейсхолдеры уровней, которые нам нужны для альфы. Нам снова надо будет переключить передачи, по возможности придерживаться концентрической разработки, но при этом принять некоторые новые методы, необходимые для эффективной работы. Мы рассмотрим эти изменения в главе 29.

Некоторые игровые платформы – большинство игровых консолей и некоторые мобильные устройства и VR-платформы – требуют прохождения сертификации до выпуска игры. Альфа-фаза проекта – подходящее время для детального изучения сертификационных требований в рамках подготовки к дополнительной работе, которую команде необходимо будет выполнить, чтобы им соответствовать. Подробнее об этом вы можете прочитать в главе 34.

Простой метод отслеживания ошибок

В каждой игре, большой или маленькой, важно в какой-то момент производства начать методично находить, перечислять и исправлять баги, прячущиеся внутри игры и портящие игровой опыт. Как только вы этим займетесь на этапе продакшена, можете считать, что вы вошли в альфа-фазу вашей игры.

Начните с разработки тест-плана. Тест-план обычно делает руководитель QA-отдела в сотрудничестве с креативными руководителями проекта, продюсерами и, возможно, руководителями отделов. Работая в небольшой команде, старайтесь привлекать к этой работе столько членов команды, сколько это практически осуществимо. Тест-план немного похож на рецепт блюда или план на выходные. У нас выписано то, что мы имеем представление о необходимых элементах и инструментах и проблемах, с которыми мы можем столкнуться. Мы составляем списки в соответствии с важностью проблем, которыми мы должны заняться в первую очередь. Мы можем также указать в плане, какие составляющие игры не будут проходить тестирование, чтобы QA-отдел и команда разработчиков могли установить некоторые границы в своей работе.

Составление тест-планов – это зрелая дисциплина, и вы можете найти много подробной информации о разработке хорошего тест-плана в интернете. Эшли Дэвис и Адам Сингл дают множество подробных и технических советов по созданию тест-плана игры в своей статье Testing for Game Development[163] («Тестирование в разработке игр») для Gamasutra.

Как только у вас есть план, вы готовы начать тестирование. Обычно прохождение билда игры в соответствии с тест-планом и учет обнаруженных ошибок занимают немало времени. (Лучше тестировать билд игры, а не запускать ее в редакторе, так как билд может вести себя по-другому.) Стоит отметить, что QA-тестеры обычно не просто играют в игру свободно и исследовательски, как это сделал бы обычный игрок. Они тщательно проверяют каждый тип возможного взаимодействия, высматривая то, что ведет себя не так, как следовало бы. Если вы работаете в небольшой команде, вам придется решить, как вы будете тестировать игру. Нанять кого-то, кто поможет вам с обеспечением качества, – это всегда хорошая инвестиция.

Даже если ваша команда настолько мала, что вы просто тестируете игру самостоятельно по мере ее разработки, вы все равно должны записывать обнаруженные ошибки. Профессиональные разработчики используют специальные базы данных, также известные как баг-трекеры, для ведения списка ошибок и информации, сопровождающей каждую из них. Среди некоторых популярных систем отслеживания ошибок на момент написания книги можно назвать Jira, Bugzilla и Mantis.

При разработке небольшого проекта можно отслеживать ошибки в электронной таблице. Дайте столбцам эти заголовки (или используйте шаблон с сайта этой книги):

• Номер бага;

• Дата и время обнаружения;

• Дата и время билда (или номер билда);

• Краткое описание;

• Класс;

• Приоритет;

• Категория;

• Описание;

• Локация в игре;

• Воспроизводимость;

• Шаги для воспроизведения ошибки;

• Задействованный скрипт;

• Ответственное лицо;

• Статус;

• Приложения;

• Примечания;

• Примечания к исправлению.

Давайте рассмотрим каждый из этих разделов и ту информацию, которую вы будете вносить в каждый столбец.

Номер бага

Каждая ошибка должна иметь уникальный номер, чтобы вы могли быстро и легко ее обозначить.

Дата и время обнаружения

При обнаружении бага надо записать дату и время его обнаружения. Многие электронные таблицы позволяют вводить дату и время с помощью сочетания клавиш.

Дата и время билда (или номер билда)

Вы должны обозначить билд игры, в котором впервые был обнаружен баг. Вы можете прочитать про билды и то, как их собирать, в главе 5.

Краткое описание

Этот столбец должен включать очень краткое описание ошибки – затем оно будет служить ее названием.

Класс

Баги бывают разных классов, каждый из которых описывает степень их серьезности. Точное определение каждого класса может варьироваться от студии к студии, но довольно часто можно встретить эту классификацию:

• Блокер (Showstopper)

☉ Ошибка, которая должна быть немедленно исправлена, поскольку она в какой-то момент препятствует прохождению игры – следовательно, и тестированию[164].

• Класс А

☉ Серьезная ошибка, которая существенно мешает функционированию игры и должна быть исправлена[165].

• Класс Б

☉ Ошибка, которая существенно влияет на функциональность или опыт, создаваемый игрой, и которая должна быть по возможности исправлена.

• Класс В

☉ Менее серьезная ошибка, которая не оказывает существенного влияния на функционирование или опыт, создаваемый игрой, но которая должна быть исправлена, если это возможно.

Комментарий

☉ Этот класс багов используется тестировщиками для отправки отзывов или идей разработчикам. Может стать ценным каналом связи между QA-отделом и разработчиками игры.

Приоритет

Внутри каждого класса можно также назначить приоритет. Баг «B1» нуждается в срочном исправлении, но не таком срочном, как баг «A3», в то время как баг «B3», вероятно, может подождать.

Категория

Если можно отнести баг к какой-то категории, то лучше отсортировать ошибки по отделам, которые смогут затем их устранить – это также поможет быстрее назначить ответственного за исправление. Можно сортировать по следующим категориям:

• Программирование;

• 2D-графика;

• 3D-графика;

• Гейм-дизайн;

• Тексты;

• Анимация;

• Аудио;

• Музыка;

• Визуальные эффекты;

• Тактильная отдача;

• Пользовательский интерфейс;

• Субтитры;

• Другое.

Описание

Здесь баг описывается подробнее, чем в кратком описании. Хорошее описание багов – само по себе искусство. Лучше всего использовать ясный, лаконичный язык, чтобы описать, что ожидал тестировщик и что произошло на самом деле. Не включайте информацию о том, где возникает ошибка, как часто или как ее воспроизвести – эта информация будет в других разделах.

Локация в игре

Тем, кто будет исправлять ошибку, не помешает точно знать, где в игре баг. Это особенно важно для ошибок, которые случаются только в одном конкретном месте в игре. Лучше всего записать 2D- или 3D-координаты места из игрового движка или сделать скриншоты.

Воспроизводимость

Некоторые ошибки возникают стабильно каждый раз, когда вы пытаетесь их воспроизвести, другие случаются только иногда, а некоторые можно увидеть только один раз. Вы можете использовать эти категории для описания воспроизводимости ошибки:

• всегда;

• иногда;

• редко;

• единожды.

Шаги для воспроизведения ошибки

Это подробное описание шагов, которые необходимо сделать, чтобы воспроизвести ошибку. Этот раздел также уменьшает объем раздела «Описание».

Задействованный скрипт[166]

Если тестировщики могут сказать, какой скрипт (или другой фрагмент кода) вызвал проблему, стоит это записать. Отладочные сообщения часто показывают, где в коде произошла ошибка.

Ответственное лицо

В этом разделе назначается ответственный за исправление бага.

Статус

Каждому багу при его первом обнаружении присваивается статус «Новый». Статус бага будет меняться в течение всего срока его существования по мере того, как он будет передаваться между QA-отделом и другими членами команды разработчиков, а также по мере починки.

• Новый

☉ Статус бага при его первом обнаружении.

• Известный

☉ Разработчик дает ему этот статус, когда получает баг, над исправлением которого он будет работать.

• Запрашивается информация

☉ Если человеку, который собирается исправить баг, требуется дополнительная информация для его исправления, он меняет его статус на этот, и ошибка передается обратно менеджеру QA-отдела или тому, кто обнаружил баг.

• Исправлен

☉ Когда разработчик думает, что исправил баг, он помечает его как «Исправлен» и передает обратно в QA-отдел для проверки, действительно ли баг устранен.

• Невозможно воспроизвести

☉ Если разработчик не может воспроизвести баг, он меняет его статус и передает обратно в QA-отдел для проверки. Отдел обеспечения качества проверяет, воспроизводится ли все еще этот баг.

• Дубликат

☉ Багу присваивается этот статус, если он уже есть в базе данных с другим номером.

• Не исправлен

☉ Если во время проверки баг, помеченный как «Исправлен», на самом деле не был устранен, он помечается как «Не исправлен» и возвращается разработчику, который над ним работал, или его руководителю.

• Подтвержден

☉ Если во время проверки баг, помеченный как «Исправлен», действительно оказывается устранен, он получает статус «Подтвержден» и отправляется на большое райское кладбище ошибок.

• Закрыт (нельзя исправить)

☉ Иногда баг по той или иной причине не может быть исправлен, и тогда он помечается таким образом. В большинстве команд только очень высокопоставленные члены команды могут закрывать баги.

• Закрыт (отклонен)

☉ Иногда члены команды решают, что баг по какой-то причине не надо исправлять – возможно, это займет слишком много времени, или он не такой уж серьезный, или это вообще не баг, а фича. В таком случае ошибка получает этот статус. Опять же, обычно это решение принимается только старшими членами команды.

• Повторно открыт

☉ Иногда баг, который был закрыт, снова открывается, и тогда он помечается таким образом.

Приложения

Зачастую к отчету стоит добавить скриншоты или видеоролики, иллюстрирующие баг.

Примечания

Раздел примечаний к багу – это хороший способ передавать информацию между QA-отделом и командой разработчиков. Например, когда запрашивается дополнительная информация о баге или когда баг помечен как «Не исправлен».

Примечания к исправлению

Если есть что-то особенное в том, как был исправлен баг, или если баг по какой-либо причине закрыт, надо написать об этом в этом разделе.

* * *

Как вы, вероятно, можете судить по этим заголовкам, жизненный цикл бага выглядит следующим образом.

• Баг обнаруживается QA-отделом или одним из разработчиков в команде.

• Баг назначается разработчику для исправления, тот подтверждает, что получил его, и приступает к работе.

• Разработчик пытается исправить баг.

• Когда разработчик думает, что исправил его, он делает пометку «Исправлен».

• Затем баг возвращается в QA-отдел для проверки, был ли он исправлен.

• В зависимости от результатов проверки баг помечается либо как «Подтвержден», либо как «Не исправлен».

• Если разработчику требуется дополнительная информация, он не может воспроизвести баг или обнаруживает, что это дубликат, он помечает его соответствующим образом и возвращает в QA-отдел.

• Если разработчик не может исправить баг, он сообщает об этом своему менеджеру или руководителю группы. Затем баг передается другому разработчику, который может его исправить, или же закрывается.

Этот простой метод отслеживания багов на основе электронных таблиц будет полезен для небольших проектов и даст вам знания, необходимые для работы со специальными системами баг-трекинга в более крупной команде. Однако вы быстро обнаружите, что отслеживать баги в электронной таблице неудобно, а потому я рекомендую вам найти и использовать инструмент управления проектами с функцией отслеживания багов. Мередит Холл дает хороший обзор таких функций в различных инструментах управления проектами, с которым вы можете ознакомиться в ее статье Choosing a Project Management Tool for Game Development[167] («Выбор инструмента управления проектами для разработки игр») для Gamasutra.

* * *

Теперь, когда вы знаете, как отслеживать ошибки, вы готовы приступить к работе над альфа-версией вашего проекта. Мы вернемся к теме исправления багов в главе 32. Вооружившись информацией об альфа-фазе, давайте подробно рассмотрим альфа-майлстоун и то, как мы будем его достигать.

Глава 28

Майлстоун альфа-версии

В предыдущей главе мы обсудили альфа-фазу нашего проекта и методы баг-трекинга. Теперь давайте посмотрим на майлстоун альфа-версии, который знаменует конец альфа-фазы. На этапе альфы все фичи уже присутствуют в игре, иначе говоря, в игре представлены все функциональные возможности. В этом цель альфа-фазы для большинства видов разработки программного обеспечения, от игр до бизнеса. Чтобы игра достигла альфа-майлстоуна, мы должны внедрить в нее все фичи и все уровни финальной игры – вскоре мы обсудим это подробнее.

Фичи и контент

Давайте подробнее рассмотрим само слово фича и что оно означает. Мы могли бы сказать, что в играх две составляющие: фичи и контент. Вообще говоря, фича – это элемент функциональности игры. Механизмы, благодаря которым игра работает. Если что-то в игре управляется логикой или реагирует на действие игрока, скорее всего, это фича.

Проиллюстрируем эту идею примерами.

• Фича, которая управляет персонажем игрока в ответ на вводимые игроком данные в экшен-игре.

• Фича, которая управляет неигровыми персонажами (NPC), когда те занимаются своими делами в игровой среде игры-симулятора.

• Фича, которая определяет, что происходит со зданием с течением времени, в симуляторе городского строительства.

Фичи более высокого порядка, подобные приведенным выше, обычно можно разбить на фичи более низкого порядка.

• Фича управления персонажем игрока может состоять из отдельных фич, которые управляют бегом и прыжками.

• Фича управления NPC может состоять из отдельных фич, которые управляют ходьбой, переносом предметов из одного места в другое и разговором с персонажем игрока.

• Фича, определяющая, что происходит со зданием с течением времени, может состоять из отдельных фич, определяющих, когда здание загрязняется, разрушается или загорается.

Мы могли бы продолжать разбивать эти фичи и дальше, пока не доберемся до конкретных функций в коде, которые воздействуют на структуры данных, представляющие эти игровые объекты.

А контент – это структуры данных и ассеты, составляющие игровые объекты, на которые воздействуют фичи игры: арт, анимация, звуковые эффекты, визуальные эффекты, музыка и диалоги, и это лишь часть набора данных. Конечно, у вас не может быть фичей без контента. Если вы запрограммировали систему для перемещения NPC по игровому миру, но не создали арт, анимацию и звуки этого NPC, этой фичи на самом деле в игре нет. Контент часто помогает функциям проявляться в игровом мире, и размытая грань между фичами и контентом иногда может привести разработчиков игр к неприятностям, как мы увидим позже.

Полнофункциональность

Когда все фичи игры реализованы и исправно работают, игру можно считать полнофункциональной (feature complete). Этого проще добиться, если разрабатывать игру концентрически, тестируя все новое и исправляя баги по ходу дела.

Когда игра полностью завершена с точки зрения фич, в ней должно присутствовать все, что будет в конечной игре, будь то разговоры между NPC и игроками, логические головоломки, боевая механика или алгоритмы поиска пути ИИ. Если вы хотите внедрить какой-то механизм, то он должен быть в игре к альфа-майлстоуну.

Однако по мере приближения к майлстоуну разработчики часто сталкиваются с непреодолимым масштабом задач, поскольку перед ними цель реализовать все «движущиеся части» игры. Вот тут разработчики могут воспользоваться размытостью границ между фичами и контентом, что может привести как к положительным результатам (если разумно их использовать), так и к весьма плачевным.

За время своей работы в игровой индустрии я узнал от коллег, что к альфе у вас должно быть хотя бы по одному элементу всего того, что вы хотите видеть в игре. Если NPC как-то себя ведет, его поведение должно быть прописано в игре, даже если у вас еще нет всех NPC, которые будут так себя вести. Искусство достижения майлстоуна альфы во многом заключается в умении выбирать для реализации тот контент, который демонстрирует все поведение, которое будет присутствовать в игре. Поведение тоже фича, а потому для создания отличной игры надо включить его в альфа-версию.

Если у нас полно времени для реализации фичей до майлстоуна, то мы должны разработать каждый объект в игре, который обладает уникальной комбинацией функций. Это связано с тем, что между фичами могут возникнуть непредвиденные взаимодействия, которые потребуют от нас дополнительной работы.

Если у нас мало времени до майлстоуна альфа-версии, тогда можно рассмотреть возможность внедрения меньшего количества объектов – при условии, что все вместе эти объекты демонстрируют все фичи игры. Этот путь гораздо более рискованный: хотя технически у нас будут все фичи, объединяя их в новые комбинации, мы, вероятно, столкнемся с необычным поведением игры.

Вы должны помнить о каждой функциональной составляющей вашей игры, когда перед вами встает вопрос, что же надо успеть к альфе. Например, если в игре будет представлена система достижений, либо внутриигровая, либо подключенная к системе достижений от издателя игры или платформы, то вам следует включить в альфу по крайней мере одно достижение.

Отчасти смысл альфа-версии заключается в попытке узнать все то, что будет представлять функциональные возможности игры. Мы хотим знать, как работает наша игра, имея в запасе достаточно времени, чтобы устранить любые проблемы – и это значит, что игра становится полнофункциональной. Майлстоун альфа-версии служит к тому же особенно важным инструментом для предотвращения фичекрипа.

Впервые я упомянул о фичекрипе проекта – разновидности скоуп-крипа – в главе 17. Разрастание непременно возникает, когда разработчикам приходят захватывающие идеи новых функций игры на этапе продакшена. Идеи, которые не были запланированы в макродизайне, но которые они все равно решают добавить, даже вопреки постулату, что макродизайн «высечен в камне». Иногда стоит добавить новую фичу, особенно если она проста в реализации и привносит в игру что-то особенное. Но фичекрип может оказаться и разрушительной, коварной проблемой.

Проблемы незаметно проникают в проект с каждой добавляемой нами новой фичей, поскольку трудно предсказать, как они повлияют на проект в целом. А при недостатке дисциплинированности «еще одна функция» станет целым потоком незапланированной работы. Внедрение новой фичи может и не занять много времени, но, вероятно, приведет к появлению новых проблем с дизайном и багам, устранение которых займет гораздо больше времени. Как я уже говорил в главе 17, проекты, которые становятся жертвами скоуп-крипа, иногда так и не доходят до финала. Они могут легко превратиться в неконтролируемую мешанину багов и непоследовательных, противоречивых направлений.

Именно в этом кроется опасность размытости границ между фичами и контентом. Некоторые разработчики игр пытаются внедрить новые фичи в игру уже после майлстоуна альфа-версии под видом «пачки контента». Иногда это срабатывает, но зачастую все идет катастрофически не так, приводя к новым ошибкам и проблемам, когда проект должен уже быть стабильным и с хорошим дизайном.

Как правило, чем опытнее разработчик – как в целом, так и в работе в определенном стиле или жанре игры, – тем больше вероятность того, что, даже рискуя на стадии альфы, он справится. Менее опытные разработчики подвергаются большему риску не добиться полной функциональности игры к майлстоуну, а новые группы функций, добавленные после майлстоуна, скорее всего, будут плохо работать в законченной игре просто потому, что на их доработку не хватило времени.

Добавление всех игровых последовательностей

Есть еще один чрезвычайно важный аспект альфы, который я вам изложу. Эту технику мы разработали в Naughty Dog под руководством президента студии Эвана Уэллса, и она произвела революцию в моем отношении к созданию игр. Работая над Uncharted 2: Among Thieves, мы решили, что к альфа-майлстоуну мы не только включим все фичи игры, но и добавим все игровые последовательности, создав все уровни, пускай и в грубой форме, с плейсхолдерами и в виде блокмеша (вайтбокса/грэйбокса/блокаута).

Многие уровни Uncharted 2 уже были почти готовы к майлстоуну альфа-версии. Некоторые уровни игры были реализованы частично, некоторые – едва начаты, а некоторые – еще не созданы. Эти последние уровни – едва начатые и пока не созданные – мы быстро набросали в виде низкополигонального блокмеша, чтобы иметь представление о приблизительных длине и размере уровня. Затем мы соединили все вместе, используя систему стриминга уровней и логику повествования игры, чтобы в нее можно было сыграть от начала до конца.

Имея возможность пройти игру от начала до конца в альфа-версии, пускай отдельные ее фрагменты были только в зачаточной форме, а само прохождение скорее напоминало быструю пробежку по основным местам, мы смогли основательно и быстро разобраться в общем темпе игры и сюжете. Мы могли видеть, когда темп игры замедляется или слишком ускоряется, и вносить нужные коррективы. Важно отметить, что мы также получили отличное представление о том, сколько работы нам еще предстоит сделать. Одно дело смотреть на список задач, которые надо выполнить, но совсем другое – пробежаться по практически пустому уровню, визуализируя, что нужно добавить, чтобы заполнить его игровыми событиями.

Когда вы решаете, что сократить или изменить, обязательно обновляйте таблицу макродизайна, чтобы отслеживать все принятые вами решения. Начиная с Uncharted 2, я стремился сделать все игровые последовательности на стадии альфа, и это не раз помогало разработчикам получить представление о реальном размере игры и понять, стоит ли масштабироваться дальше.

Кроме того, чтобы игровые последовательности считались завершенными в альфа-версии, весь интерфейс, меню и экраны интерфейса должны быть на месте хотя бы с плейсхолдерами изображений и аудиоконтента (включая экраны логотипа, титульный экран, экраны настроек, экраны паузы и экраны сохранения/загрузки). Все эти элементы должны быть соединены вместе так, чтобы игрок мог перемещаться от одной части игры к другой точно так же, как он мог бы это сделать в готовой игре. Стартовые логотипы должны вести к титульному экрану, который в свою очередь ведет к игре или экрану настроек, и так далее.

И, наконец, любые кат-сцены, видеоролики с актерами или другие линейные ассеты игры должны быть уже на месте, пускай и в виде плейсхолдеров или стабов (заглушек). (Мы поговорим о них подробнее в следующей главе.) Мы так легко увлекаемся созданием геймплея, что забываем обо всем остальном, что связано с игрой и ее функциональностью. Но стоит подумать, скажем, об экране с логотипом команды, как мы понимаем, сколько всего нам еще предстоит создать. Даже шуточный, нарисованный мышью логотип, пока заменяющий его красивую анимированную версию, которая будет в конечной игре, поможет вам лучше сориентироваться в содержании вашего проекта.

Хороший порядок онбординга

В жизни везде важно первое впечатление, и от плохого первого впечатления бывает трудно избавиться. Первые мгновения прохождения задают тон всей игре и формируют наши ожидания относительно того, какой она будет.

В начале видеоигр нас обычно обучают тому, как играть. Времена, когда мы с волнением читали инструкцию к игре по дороге домой из магазина, давно прошли. Сегодня мы загружаем игру и ныряем в нее, ожидая, что нас поприветствуют и расскажут все, что нужно знать.

Когда мы думаем о том, как ввести нового игрока в игру – процесс, известный как онбординг, – неразумно полагаться на то, что игроки уже знакомы с другими видеоиграми и схемами управления. Гейм-дизайнерам важно знать о схемах управления в играх, схожих с их проектом, но наши игроки могли в такое не играть, а мы хотим вовлечь людей в игру, а не оттолкнуть их.

Возможно, некоторые игроки будут знать, например, о WASD и мыши, но хороший дизайнер в первую очередь нацелится на тех, кто этого не знает. Суть в том, чтобы разработать схему управления, которая подходит как опытным игрокам, так и абсолютным новичкам, и которую можно легко освоить. Как нам научить игроков управлению, не утомляя их и не сбивая с толку?

В те времена, когда в играх было меньше элементов управления, чем сегодня, можно было просто показать «экран управления» в начале игры, где указано, что какие кнопки делают. Экраны управления нужны где-то в меню для справки, возможно, для игрока, который долгое время не возвращался в игру и которому нужно освежить в памяти, что за что отвечает. Но для большинства это не лучший способ обучения, разве что схема управления очень проста. Игры даже с умеренно сложными схемами управления требуют иного подхода к обучению игрока.

Более эффективный подход – ввести игрока в игру и представить элементы управления и механики одну за другой. По мере введения каждой новой механики мы предлагаем игроку использовать соответствующий элемент управления, а затем представляем ему ситуацию в игровом мире, которую он должен разрешить, используя новую механику. Таким образом, игрок учится на собственном опыте, пробуя что-то новое.

В 1990‑х и начале 2000‑х годов игроков часто учили на специальных обучающих уровнях. Но прыгать через обручи, которые придумал для вас гейм-дизайнер, вскоре становится утомительно. Дизайнеры вскоре поняли, что игроки не хотят делать что-то, что напоминает обязательную работу, прежде чем они смогут приступить к самой игре – они просто хотят начать играть. Сегодня в играх до сих пор есть обучение, но его не всегда удается распознать как таковое. Дизайнеры идут на многое, чтобы их обучение ощущалось как игра, сочетая интерактивность с чем-то приятным, интересным, забавным или драматичным. Отличное обучение позволяет игрокам свободно играть с самого начала и делать интересные открытия, в то же время изучая то, что хочет дизайнер.

Сетап в начале Super Mario Bros. World 1–1, который мы обсуждали в главе 18, делает это очень элегантно. Как и начальный эпизод с поездом в Uncharted 2: Among Thieves, о котором мы говорили в главе 17: мы обернули обучающий уровень в кинематографический боевик с драматичными и удивительными событиями, развивая при этом сочувствие к Нейтану Дрейку, персонажу игрока.

Почти каждая игра в любом стиле может представить игрокам механику так, чтобы ее было интересно осваивать. Этого проще добиться, если разработчики стараются развлечь и заинтересовать игрока одновременно. Сейчас самое время подумать об аффордансах и сигнифаерах, которые мы обсуждали в главе 12. Дает ли ваша игра подсказки о том, как с ней взаимодействовать, просто тем, как она выглядит и звучит? Что можно было бы добавить, чтобы эти подсказки было легче считать?

Не в каждую игру надо вводить игрока постепенно. На заре своего существования Minecraft было трудно освоить без помощи друга, который показал бы вам, как играть, однако это не помешало игре добиться огромного успеха. Сложное освоение игры может быть частью ее эстетики или культуры. Но будьте осторожны: не пренебрегайте обучением. Привлечь и удержать внимание нового игрока сложно, и это имеет решающее значение для игр, которые стремятся к коммерческому успеху.

Итак, альфа – подходящее время разобраться с онбордингом вашей игры. Будет еще лучше, если вы сможете закончить обучающие элементы вашей игры к майлстоуну альфы. Если вы разрешите все трудности, связанные с онбордингом, у вас останутся время и силы, чтобы сосредоточиться на всем остальном, о чем нужно позаботиться между альфа- и бета- версиями.

Роль альфа-майлстоуна

Мне нравится думать об альфе как о первом этапе финишной прямой. Подобно этапам идеации и препродакшена, на этапе альфа-версии мы должны принять некоторые важные решения о содержании игры, чтобы защититься как от фичекрипа, так и от скоуп-крипа в целом. А также нам пора оценить состояние игры.

Проверка скоупа на этапе альфы

В конце этапа идеации мы установили рамки нашей игры очень общим образом, сформулировав цели проекта. Затем в конце этапа препродакшена мы ограничили скоуп проекта чуть конкретнее: (а) разработав вертикальный срез, показавший, какой будет часть игры, и (б) представив план игры в виде макродизайна.

На этапе альфа-версии, примерно на половине или двух третях этапа продакшена, мы принимаем новые решения о скоупе проекта, создавая полнофункциональную версию игры со всеми игровыми последовательностями. Так мы демонстрируем как самим себе, так и всему миру, что теперь мы лучше понимаем, на что похожа наша игра и что она будет включать в себя в финальном виде.

Говоря о скоупе, мы имеем в виду как фичи, так и контент. На самом деле здесь рассматриваются два вида скоупа: (1) «пространство возможностей» игры, абстрактное пространство всего того, что может произойти в игре, и (2) «объем контента», количество контента в игре.

Помните, что в пространстве возможностей игры есть как хорошее, так и плохое: увлекательный геймплей, увлекательные ситуации и интересные стратегии, а также проблемы с дизайном, контентом и баги. Каждый раз, когда вы добавляете новую фичу, она приносит что-то хорошее и что-то плохое. Проводя черту на песке в альфа-версии, после которой мы больше не будем добавлять никаких функций, мы делаем следующий важный шаг к созданию игры без багов.

Альфа-версия также дает нам шанс защититься от разрастания контента, другого вида скоуп-крипа проекта. Может показаться, что после альфа-версии мы успеем разобраться с контентом игры, поскольку у нас еще есть время до беты. Но на самом деле альфа – это наш последний шанс. Если мы начнем уменьшать масштаб игры после альфа-версии, когда будем заняты контентом для игры, мы вполне рискуем тратить время на создание того, что в итоге придется вырезать.

Итак, внедрите все фичи и игровые последовательности в альфе, даже если некоторые части будут представлены в виде блокмеша или заглушек (как мы обсудим далее в следующей главе). Внимательно оцените результаты. Решите, что следует убрать. Если вы не можете решить, еще раз взгляните на цели проекта, которые вы поставили еще в конце этапа идеации – они помогут принять последние решения о содержании проекта. Даже если вы одержимы идеей представить какую-то фичу или контент, но они не соответствуют целям вашего проекта и у вас заканчивается время, их стоит вырезать.

Проверка состояния игры

На этапе альфа-версии важно проверить общее состояние игры. Сколько в ней багов и нерешенных проблем с дизайном? На стадии альфа также пора решать проблемы с производительностью. Достаточно ли высокая частота кадров? Не слишком ли долго идет загрузка?

Важно принять к сведению все эти вопросы – связанные с дизайном, багами или производительностью, – потому что все эти проблемы должны быть решены где-то между альфой и релиз-кандидатом. Многие из них должны быть решены к бета-версии, иначе мы рискуем потратить время, оставшееся у нас для внедрения контента. Составление списка нерешенных проблем альфы поможет нам принять разумные решения о том, нужно ли нам еще больше сокращать масштаб проекта. Чем скорее мы примем эти решения, тем лучше получится игра. Чем дольше мы думаем над скоупом, тем она будет хуже.

Выбор названия игры после альфы

Возможно, вы проводили фокус-тесты, чтобы получить обратную связь о названии вашей игры. После альфы пора принять окончательное решение. Как только вы выбрали название, создайте учетную запись вашей игры в социальных сетях на той платформе, которую считаете наиболее подходящей для вашей деятельности. Название само по себе может быть уже кем-то использовано, но, поместив перед названием слово «игра», вы создадите уникальное имя аккаунта в социальных сетях.

Основываясь на аудитории, которую вы считаете целевой, вы должны выбрать необходимую платформу, поскольку разные каналы и сети имеют разную аудиторию. Консультант по маркетингу и профессор USC Games Джим Хантли рекомендует остановиться на одной платформе и сделать ее своим домом в социальных сетях. Можно проводить кампанию в социальных сетях по нескольким каналам, но это будет утомительно для небольшой команды. (Джим отметил, что существуют бесплатные инструменты, которые помогут вам автоматически постить контент с одного канала на другой.)

Однако, даже создав учетную запись игры в социальных сетях, пока не размещайте в ней посты. В зависимости от продолжительности вашего проекта может быть еще слишком рано собирать аудиторию вокруг игры. Так долго подогревать интерес аудитории до релиза игры будет сложно. А пока убедитесь, что вы сохраняете и каталогизируете все, над чем работали при создании игры: ранние концепт-арты, которые остались неиспользованными, GIF-файлы с примерной или экспериментальной анимацией, дизайнерские идеи, которые не вошли в игру. Из всего этого получится отличный контент для социальных сетей, когда вы начнете взаимодействовать со своей аудиторией.

Подведение итогов альфы

• Подводя итог, к майлстоуну альфы игра должна быть:

☉ Полнофункциональна

☉ Должны присутствовать все функциональные возможности игры в той или иной форме.

☉ В сильной альфе должна присутствовать каждая уникальная или рискованная комбинация фич.

• Завершена с точки зрения игровых последовательностей

☉ Если в игре есть уровни, все они должны быть в игре, по крайней мере, с плейсхолдерами и коллайдерами в виде блокмеша – это даст нам представление о размере и содержании игры в целом.

☉ В игре должны быть фронтенд, меню и интерфейсы (включая стартовые логотипы, титульный экран, экраны настроек, паузы и сохранения/загрузки), пускай и с плейсхолдерами.

☉ Должны быть плейсхолдеры или стабы всех анимированных кат-сцен.

☉ Все должно быть логически связано, чтобы мы могли пройти всю игру от начала до конца.

Графика и звук в альфа-версии не обязаны быть финального качества, но мы уже должны создать несколько готовых артов и аудио в каждой из категорий того, что будет присутствовать в готовой игре: так мы убедимся, что нам по силам создать и сколько времени это у нас займет. Мы должны установить плейсхолдеры для каждого основного элемента игры, что даст нам основу для дальнейшей работы и поможет оценить производительность игры. Не пренебрегайте звуковыми и визуальными эффектами на этапе продакшена! Майлстоун альфа-версии отлично подходит для оценки вашего звукового дизайна и визуальных эффектов, а также для того, чтобы понять, есть ли у вас реалистичное понимание, сколько времени потребуется на доведение качества до высокого уровня.

Кроме того, мы должны спросить себя:

• Сколько в игре нерешенных проблем с дизайном?

• Много ли в ней багов?

• Насколько высока производительность нашей игры?

Разобравшись со всем вышеперечисленным, мы можем быть уверены, что грубый набросок игры уже готов. На пути через фазу беты к майлстоуну бета-версии мы доделаем все, что наметили.

На этапе альфы некоторые разработчики уже могут заглянуть вперед, за пределы текущего проекта. Если вы планируете перейти к другому проекту после завершения этого, самое время обсудить то, что вы намерены делать дальше.

Обзор майлстоуна альфа-версии

Майлстоун альфа-версии – отличное время для проведения обзора с участием сотрудников как внутри команды, так и за ее пределами и получения обратной связи о состоянии нашего проекта. В этом нам поможет процесс, описанный в главе 20.

Обзор майлстоуна на стадии альфы во многом похож на обзор в конце этапа препродакшена, за исключением того, что теперь объем игры стал гораздо больше. Для крупных проектов вам надо решить, как эффективнее представить игру. Возможно, обзорная встреча будет длиться несколько дней, чтобы можно было лучше ознакомиться с игрой и детальнее ее обсудить. Для небольших проектов, например коротких игр, разработанных в рамках курсовой программы, хватит всего двадцати – тридцати минут.

В своей короткой вступительной презентации руководство команды разработчиков должно представить следующее.

• Кого они считают аудиторией своей игры. Вероятно, они конкретизировали позиционирующее утверждение (см. главу 7), лучше узнав свою игру и то, как на нее реагируют игроки.

• Насколько альфа-версия игры отвечает требованиям майлстоуна. Например:

☉ альфа-версия полностью отвечает требованиям майлстоуна, проект уже на пути к бета-версии, стабы полностью отражают функциональные части игры;

☉ проект точно соответствует требованиям майлстоуна альфа-версии, стабы отражают функциональность игры;

☉ проект преодолел стадию альфа, но стабы не полностью отражают функционал игры;

☉ проект еще не достиг майлстоуна альфа-версии. Команда сообщает, чего им не хватает для альфы.

• Есть ли какие-то известные проблемы с проектом.

• По каким вопросам нужна обратная связь.

На обзоре альфа-версии нам нужны только своевременные замечания. Обзорная группа не должна – в большинстве случаев – давать советы, в которых рекомендуется добавить новые фичи, ведь игра уже укомлектована.

Помимо обзорной встречи с людьми «снаружи», команда также должна провести внутренний обзор альфа-версии. Он должен проводиться по дисциплинам: художники обозревают арт, инженеры – технические вопросы и так далее. Обзорная встреча может также иметь и междисциплинарный характер, где руководители каждой дисциплины вместе обсуждают альфа-версию игры.

Иногда на этапе альфа-версии становится очевидным, что добавление или изменение одной простой фичи окажет революционное и положительное влияние на игру. Вам нужно будет решить, как повлияет на вашу игру добавление новых фич: (а) будет ли это безопасное, разумное, позитивное изменение для вашей игры, или (б) вы станете жертвой расползания фич и нанесете ущерб целостности и качеству проекта, а также работоспособности и производительности вашей команды.

Воспользуйтесь всеми преимуществами обзорной встречи как, возможно, самого богатого источника своевременных и действенных замечаний. Контент игры еще требует доработки, и у нас есть прекрасная возможность довести ее до совершенства, если мы будем руководствоваться советами, которые мы получаем от наших тестеров, коллег и наставников.

* * *

Некоторые считают бета-версию самым важным этапом, когда уже можно сказать, собралась ли игра воедино, но я думаю, что альфа дает нам очень четкое представление о том, какой будет наша игра. Если мы поставим перед собой цель выйти к альфа-версии с хорошими показателями, то мы будем наращивать усилия в середине проекта, вместо того чтобы оставлять более тяжелую работу на конец.

Приступайте к альфа-версии с энтузиазмом и рвением, и вы сочтете ее одним из лучших инструментов для того, чтобы взять разработку игры под контроль, сохраняя при этом творческий подход к работе. Помните мою аналогию с «технической репетицией» из главы 22? Техническая репетиция может быть очень увлекательной – не так уж и важно, если актеры забывают свои реплики, если звук слишком громкий, а генератор дыма погрузил весь зрительный зал в туман. На технической репетиции вы можете почувствовать потенциал того произведения, которое появится на премьере. Полюбите вашу альфа-версию, сделайте ее своим другом и встречайте с восторгом. Насладитесь черновым вариантом готовой игры и следуйте тому, куда она вас ведет.

Глава 29

Стабы

Концепция установки заглушек для фичей и контента поможет нам достичь майлстоуна альфа-версии продуктивно и может быть полезна на протяжении всего процесса разработки игры. Когда мы добавляем в игру стабы, мы отходим от принципов концентрической разработки, используемых нами на протяжении всей этой книги, но придерживаемся функциональности и модульности, характерных для здоровой практики гейм-дизайна.

Что такое стаб

Стаб (от англ. stub – «заготовка») – это короткий фрагмент контента или кода, который заменяет что-то, что будет доработано позже. Многие из нас сталкиваются со стабами в «Википедии», когда видят надпись: «Это заготовка статьи. Вы можете помочь проекту, дополнив ее». Такая статья малосодержательна, «полноценной статьей такую заготовку признать еще нельзя из-за недостатка в ней важной информации», но теперь такие заготовки можно снабдить ссылками[168].

Программисты часто пишут функции и методы, сначала создавая стаб, один из них показан на рис. 29.1. У стабов то же название, что будет и у готовой функции, и его можно вызвать другими частями кода, но содержит он только простой плейсхолдер: например, комментарий, который с помощью «псевдокода» описывает, что в итоге будет делать функция, или функцию print, которая подтверждает в консоли отладки, что стаб был успешно вызван.

Стабы в видеоиграх

Концепция стабов применима и к видеоиграм, она облегчает жизнь разработчикам и повышает эффективность работы. Мы уже обсуждали один тип стабов в главе 10, когда говорили о блокмеше, также известном как вайтбокс, грэйбокс или блокаут. Блокмеш – это своего рода стаб: плейсхолдер, который служит нашим первым шагом на пути к созданию чего-то сложного – в нашем случае готового дизайна уровня и левел-арта. Блокмеш снабжает нас видимой низкополигональной геометрией, с которой могут сталкиваться сущности в игре и которую мы позднее превратим во что-то более детальное как функционально, так и эстетически.

Рис. 29.1. Стаб (также известный как функция-заглушка).

Помимо блокмеша, «заготовки» нового уровня, мы можем использовать стабы, чтобы создать любой новый объект или персонажа и создать отношения с новой сущностью. Изначально стальная дверь может выглядеть как серый ящик, а дерево – как большая зеленая сфера на вершине узкого коричневого цилиндра. Персонажи в игре могут начать жизнь как объекты в форме капсулы, даже если в итоге станут похожи на барсуков или василисков.

В виде заглушек могут быть представлены и другие типы сущностей. Текстовое описание объекта может начинаться с плейсхолдера lorem ipsum. В Naughty Dog мы использовали короткое видео в качестве стаба для неотрендеренных кат-сцен, используя его как плейсхолдер роликов, которые мы еще не сделали. Так мы могли сразу оценить время загрузки и упростить последующее добавление готовых кат-сцен. Стабы интерфейсов могут включать плейсхолдер арта и упрощенное взаимодействие, которое позволит выбрать параметры и войти в меню сохранения, но без утонченности финального варианта интерфейса.

Когда игра приближается к майлстоуну альфа-версии, такие важные сущности, как персонаж игрока и прочие ключевые персонажи, объекты и уровни в игре, вероятно, уже отполированы до хорошего уровня качества. Но к альфа-версии мы должны принять во внимание и все другие сущности, которые войдут в игру: переключатели и двери, столы и стулья, золотые монеты и секретные письма. Нам не обязательно дорабатывать все эти объекты до готового состояния к альфа-версии – для этого у нас есть бета-версия, где мы займемся доработкой контента. Что нам действительно нужно иметь в игре для альфа-версии, так это все фичи игры. Наша цель – полнофункциональность, и стабы помогут нам ее достичь.

Пример стаба объекта

Возьмем, к примеру, двери. Двери дают нам отличную возможность взглянуть на многие аспекты разработки игр. Они кажутся простыми, но на самом деле они очень сложны с точки зрения гейм-дизайна. Лиз Инглэнд – гейм-дизайнер, известная работой над такими играми, как Sunset Overdrive и Scribblenauts. В своем глубоком и веселом эссе The Door Problem[169] («Дверной вопрос») Лиз на примере дверей иллюстрирует сложности гейм-дизайна. Она задает следующие вопросы.

• Может ли игрок открывать и запирать двери?

• Как игрок поймет, какую дверь можно открыть, а какую – нет?

• Знает ли игрок, как отпереть дверь? Нужно найти ключ? Взломать консоль? Решить головоломку? Или дверь откроется после определенного сюжетного момента?

• Есть ли двери, которые могут открываться, но в которые игрок никогда не сможет войти?

• Откуда приходят враги? Через двери? После их появления двери опять закрываются?

Я настоятельно рекомендую вам прочитать The Door Problem. Каждому члену команды разработчиков есть что ответить о дверях в игре. И мы можем начать отвечать, соорудив стаб двери.

Надеюсь, что к альфа-версии нам удалось создать по крайней мере одну готовую дверь с окончательной графикой, анимацией, звуком и тактильной отдачей (вибрацией контроллера). Но давайте предположим, что нам нужен особый тип двери для особого дверного проема – опускная решетка в замке или дверь космического корабля, которая открывается крутым, но сложным образом. Мы должны добавить эту дверь к майлстоуну альфа-версии, если она достаточно сложна, чтобы ее можно было считать уникальной фичей. Но что, если наши художники слишком заняты другими важными ассетами для майлстоуна? Тут-то нам и поможет стаб.

При создании стаба мы должны руководствоваться несколькими соображениями. Первое заключается в следующем: насколько сложен этот объект? Чем больше стаб будет соответствовать размеру и форме готового объекта, тем лучше. Если вы делаете дверь, которая заполняет дверной проем определенного размера и формы, и если вам известны размер и форма дверного проема, то сделайте так, чтобы дверь точно ему соответствовала и была правильной высоты и ширины. Также тщательно выбирайте толщину двери – она тонкая и хрупкая или толстая и прочная?

Следующее соображение: как дверь будет анимироваться. Открывается ли она внутрь или наружу? Скользит к потолку или въезжает в стену? Это одинарная дверь или двойная? (См. рис. 29.2.) Или же это круглая механическая дверь, которая открывается как диафрагма?

Помимо анимации двери, вам следует подумать о том, как избежать столкновения двери с видимой вокруг нее геометрией. Этот термин, столкновение[170], пришел из мира компьютерной графики (CG). Говорят, что объекты CG сталкиваются с видимой геометрией, когда они проникают друг в друга так, как в реальном мире физически невозможно (рис. 29.3). Один из самых быстрых способов разрушить иллюзию реальности – показать, как объекты, которые должны быть твердыми, проваливаются друг в друга. Люди очень к этому чувствительны, и взгляд аудитории часто направлен прямо туда, где рука персонажа хоть немного провалилась внутрь поднимаемого объекта.

Рис. 29.2. Двери в видеоиграх бывают самых разных форм, размеров и моделей поведения

Рис. 29.3. Твердые на вид объекты сталкиваются (проникают друг в друга), быстро разрушая иллюзию прочности и реальности объектов. Авторы изображения: Мэтти Розен и Ричард Лемаршан

Чтобы стаб двери (и готовая дверь, в которую он превратится) не сталкивался с окружающим его артом, тщательно продумайте, как его анимировать. Если вы хотя бы немного владеете 3D-моделированием, вы, вероятно, сможете сделать простую анимацию. Выберите точку, вокруг которой вращается ваша дверь, прикинув, где находятся петли на дверях в реальной жизни, и заставьте дверь вращаться вокруг этой точки – она не позволит двери столкнуться с видимой геометрией. Вы можете увидеть пример на рисунке 29.4. Если вы примете это дизайнерское решение, как только внедрите стаб двери в игру, вы поможете тем, кто будет затем работать над графикой и анимацией уже готовой двери.

Рис. 29.4. Тщательно выбирайте опорную точку, вокруг которой вращается стаб, чтобы избежать столкновения

Продуманное создание стабов чем-то похоже на искусство. Каждый стаб подобен зародышу готового игрового объекта и способен сообщить о важных дизайнерских решениях. Рассмотрите возможность сопроводить объект коротким readme-файлом, где вы укажете, какие из принятых вами дизайнерских решений важны и должны быть сохранены в готовом объекте. Чем раньше мы сможем принять ключевое дизайнерское решение, тем плавнее и эффективнее все пройдет при создании игры, а вашим товарищам по команде всегда полезно знать, в каких аспектах они могут проявить свою творческую гибкость и свободу.

Выбирая имена для стабов, помните, что, как и заготовка статьи «Википедии» или функция-заглушка, каждый стаб не просто замещает какой-то объект, он и есть сам объект. Ссылки на объект будут сохранены в готовой игре, и вы не будете заменять весь стаб позже, только его содержимое. Никогда не называйте объект, который вы вводите в игру, временным файлом, сразу называйте его как следует.

Стабы и функциональность

Всегда возникает вопрос о том, какой функциональностью должен обладать стаб. Ответ таков: такой, какую вы сможете быстро обеспечить. Раз стабы похожи на эскизы объектов, то они также могут иметь некоторую встроенную функциональность.

Левел-дизайнеры часто используют условленные цвета при создании блокмеша. Если вы оговорите подобные цветовые условности для стабов объектов, вы сможете передать их форму и функции, даже если стабы еще мало что делают. Прочная стальная дверь может быть светло-серой, в то время как разбивающаяся каменная дверь – темно-серой. Низкие кусты, которые будут шелестеть, когда персонаж игрока проходит через них, могут быть представлены скоплениями зеленых сфер без назначенных коллизий. Панель управления, у которой в итоге будут детальная модель и мигающие индикаторы, пока может выглядеть как простая красная рамка.

Простое кодирование поможет вам добавить некоторое взаимодействие с объектами. Разбивающаяся каменная дверь, которая в финальной игре будет разлетаться на куски щебня, может быть запрограммирована так, что она просто исчезнет при нанесенном ей уроне.

Если вы можете сделать какую-нибудь простую анимацию, подойдет даже двухкадровая анимация открытых/закрытых или включенных/выключенных состояний объектов. Стабы также помогут установить приблизительные логические связи между переключателями, дверями и другими объектами в игре. Постарайтесь спроектировать свой контент и код модульным способом, чтобы вы могли легко вносить дополнения и изменения по мере продолжения работы над объектами и их функциональностью.

Стабы контента против концентрической разработки

Как я упоминал ранее, добавление стабов для полнофункциональности альфа-версии игры знаменует собой отход от концентрической разработки. Мы больше не полируем каждую часть игры до блеска, прежде чем переходить к следующей. Теперь мы быстро вводим объекты в игру, используя плейсхолдеры. Какие риски и выгоды это несет?

Концентрическая разработка наиболее полезна на ранних стадиях проекта. Помните, что мы используем концентрическую разработку, чтобы заложить основы игры. Концентрическая разработка позволяет нам получить четкое представление о самых основных, существенных и уникальных частях нашей игры. Однако в какой-то момент создания каждой игры мы знаем почти все, что нам нужно знать для ее завершения, и мы можем увереннее приступать к оставшейся работе.

Естественно, что на этапе продакшена мы постепенно отходим от концентрической разработки, ведь количество неизвестных в нашем проекте уменьшается по мере того, как мы работаем над альфа-версией. Мы вернемся к концентрической разработке на этапе бета-тестирования, когда игра будет практически завершена. Некая противоречивость, например напряженность между концентрической разработкой и стабами, – неотъемлемая часть любого искусства, а разработка игр, безусловно, является формой искусства. По мере того как вы экспериментируете со стабами объектов, необходимых вашей игре, и узнаете больше о том, как сделать стаб отличным, вы приобретаете уверенность и компетентность в этом аспекте нашего ремесла.

Глава 30

Привлечение аудитории к игре

Альфа-версия – отличное время оценить проделанную работу, которая в итоге приведет нас к началу общения с аудиторией. Мы начали это еще на этапе идеации, когда предполагали возможную аудиторию игры. Я призывал вас продолжать о ней думать и проводить фокус-тесты названия, ключевого арта и дизайна логотипа (на этапе препродакшена в главе 14 и когда вы начали формальный процесс тестирования в главе 24). В главе 28 мы говорили о доработке названия и необходимости завести учетные записи в социальных сетях с уже окончательно выбранным названием игры.

Приближаясь к майлстоуну альфа-версии, мы должны предпринять еще несколько шагов, чтобы найти аудиторию и поговорить с людьми в надежде, что они захотят поиграть в нашу игру. Исторически игровая индустрия делала это с помощью маркетинга, размещая рекламу игр в журналах, на телевидении и в интернете. Сегодня мы можем охватывать нашу аудиторию в социальных сетях.

Нам нужно составить конкретный план того, как мы создадим и будем развивать сообщество нашей игры, а затем привести его в действие. В начале мы рассмотрим, как анонсировать игру. Обычно об игре надо заявлять где-то между майлстоунами альфа- и бета-версий, одновременно с этим выпуская видеотрейлер к игре – хотя, как мы скоро увидим, тут нет жестких правил. К бета-версии у нас будет много оригинального геймплея и контента, название игры, оформление логотипа и ключевой арт, который представит визуал игры в одном изображении, – все это мы можем продемонстрировать нашей потенциальной аудитории.

Ходят споры о том, сколько времени должно пройти между анонсом игры и ее релизом, будь то демоверсия или уже готовая игра. В истории индустрии бывало и так, что рекламная кампания игры длилась год, а то и больше. Сегодня людям часто не терпится заполучить игру как можно скорее после того, как они услышали о ней. Как заявляет консультант по маркетингу и преподаватель USC Games Джим Хантли: «Вы не можете вечно подогревать интерес потребителей».

Так что, если вы не готовы анонсировать игру на этапе бета-тестирования, вы еще можете подождать. Рекламная кампания может развернуться очень быстро: Apex Legends от Respawn Entertainment разрабатывалась в тайне и была анонсирована только в день ее выхода. В дальнейшем игра имела огромный успех как по продажам, так и у критиков.

Вам нужно будет решить, как долго будет длиться рекламная кампания, когда объявить об игре и как взаимодействовать с вашей аудиторией до релиза. Правильные ответы будут зависеть от специфики вашей игры и аудитории, на которую вы нацелены, но у меня есть несколько рекомендаций, которые помогут установить контакт с теми, кто впоследствии будет в восторге от вашей игры.

Составьте маркетинговый план

Чтобы провести эффективную рекламную кампанию, вам нужен маркетинговый план. В книге Video Game Marketing: A Student Textbook Питер Закариассон и Миколай Дымек рекомендуют начать с «маркетингового микса» – вашей игры как продукта, цены, по которой вы планируете ее продавать, платформ, где вы планируете ее продавать, методов ее продвижения: «планируемой рекламы, продвижения товара и PR»[171]. Задавая вопросы «что, почему, когда, как, сколько и кому?» по каждому элементу этого микса, вы можете заложить основу того, что Питер и Миколай называют «самым коротким маркетинговым планом в мире»[172].

Подумайте об индивидуальности и тоне вашей игры, которые могут повлиять на то, кому она понравится, и определят, как вы будете ее продавать. Ваша игра серьезная или в ней можно валять дурака? Легкая она или напряженная? Обратитесь еще раз к опыту пользователя, который наметили в главе 7 и, возможно, со временем усовершенствовали. В книге A Practical Guide to Indie Game Marketing Джоэл Дрескин рекомендует задаться вопросом: чем моя игра выделяется? «Думая о возможных уникальных и привлекательных характеристиках вашей игры с самого начала ее создания, вы можете серьезно упростить процесс маркетинга. Определите, что сможет зацепить аудиторию: забавный новый подход к геймплею, которого нигде раньше не было, прорывные механики, демонстрирующие новое аппаратное устройство, или фичи, мощно стилизованные визуальные эффекты, которые захватят игроков, интересные главные персонажи, сюжетные линии и сеттинг»[173].

Маркетинговый план требует гораздо больше предложенного выше. Обратитесь к книгам, которые я упомянул выше, и поищите в интернете подробные советы, которые помогут вам составить маркетинговый план, подходящий для вашей игры.

Создайте веб-сайт и пресс-кит игры, а также свяжитесь с прессой

Вашей игре очень пригодится постоянный дом в интернете, где о ней смогут узнать люди. На главной странице вашего веб-сайта должен быть виден видеотрейлер игры, чтобы пользователи могли сразу увидеть ее в действии. В ролике должно быть указано название вашей игры, команда разработчиков, платформа и где ее можно купить или скачать. Тут вам также пригодятся ключевой арт и логотип, над которыми вы работали. Не забудьте сообщить на сайте дату выхода игры и дать ссылки на ваши страницы в социальных сетях, но не перегружайте посетителей слишком большим количеством информации. Разбейте сайт на различные подразделы, если будет такая необходимость.

Профессиональным командам также стоит создать для своей игры пресс-кит, то есть страницу с материалами для журналистов. Там должны быть информация как об игре, так и о команде, о том, где вы базируетесь, ваша история и контактные данные. На сайте могут быть неподвижные изображения и видео вашей игры, ключевой арт, логотип и фотографии команды. presskit() – это бесплатный инструмент для создания пресс-китов, созданный разработчиком игр Рами Исмаилом и группой соавторов[174].

Когда вы создадите веб-сайт и пресс-кит, можно начинать общение с прессой. Работа с прессой подпадает под категорию PR (связи с общественностью). Создайте и расширяйте список контактов для прессы в электронной таблице, где вы также можете отслеживать, с кем вы уже связались и кто ответил. Напишите краткое и дружественное сообщение, которое будет хорошо воспринято. Как пишет Эмили Морганти в одной из глав книги Джоэла Дрескина A Practical Guide to Indie Game Marketing, «говорите всегда четко и по существу, но все же говорите как с обычным человеком. Пытаться быть слишком официальным, использовать много модных словечек или быть слишком милым в попытке привлечь чье-то внимание – отличный способ оттолкнуть»[175]. (Глава Эмили полна отличных советов по работе с прессой для освещения игры.)

Обратитесь к людям с обзорными презентациями, крупными объявлениями или предварительными копиями игры. PR требует настойчивости, а отношения с прессой – времени. Работайте над тем, чтобы заслужить доверие прессы, и добрая молва о вашей игре распространится.

Запуск кампании в социальных сетях

Недостаточно просто начать кричать о своей игре в социальных сетях: вам должно быть что сказать. Вы должны рассказать какую-то историю своим присутствием в социальных сетях, и именно эта история вызовет интерес у людей, которые поиграют (и, возможно, вложат свои деньги) в вашу игру.

Когда я попросил Джима Хантли дать совет по проведению кампании в социальных сетях и рекламным кампаниям в целом, он сказал: «Контент правит бал: чем больше у вас есть того, что имеет отношение к вашему продукту или бренду, тем лучше. Когда у вас есть контент, реклама идет легко, чего не скажешь о ситуации, когда у вас его нет, поэтому сохраняйте и классифицируйте ваши дизайнерские материалы». То есть сохраняйте изображения, фильмы, документы, музыку и треки. Они станут активами вашей кампании в социальных сетях.

Истории нужны персонажи. Во внутриигровой истории это вымышленные герои. А вот в истории создания игры у нас есть выбор: это могут быть разработчики, комьюнити-менеджеры, актеры, исполняющие роли в игре, или кто угодно, кто может рассказать что-то интересное об игре, о том, как в нее играют и что потребовалось для ее создания.

По словам Джима Хантли, аудитория детей младшего возраста хорошо реагирует на внутриигровую историю. Взрослой аудитории это тоже будет интересно, но здесь также пригодятся увлекательные описания геймплея и история создания игры. Джим упомянул, что сначала должно быть содержание игры, а потом уже контент о том, как продукт создавался. По его мнению, с этим в маркетинге отлично справляется кинематографическая вселенная Marvel – они сначала показывают вам что-то новое, а потом то, как это придумывалось.

Методы взаимодействия с аудиторией в социальных сетях постоянно развиваются, варьируясь по всему миру. Вы можете найти еще несколько советов по ведению рекламной кампании в социальных сетях на сайте этой книги.

Джим Хантли сказал мне: «Не приступайте к рекламе слишком рано, если не уверены, что сможете поддерживать диалог. Бывает и так, что студия запускает кампанию поздно, но это иная ситуация. Общайтесь с вашей аудиторией – особенно с теми, кто с самого начала был в вашем сообществе. Дайте им что-нибудь, чем они смогут поделиться, или эксклюзивные материалы. Общайтесь со своими поклонниками как с друзьями. Пока вы с ними честны и даете им то, что приводит их в восторг, все будет идти просто прекрасно. И никогда ни при каких обстоятельствах не принимайте вашу аудиторию как должное».

Работа с инфлюенсерами в социальных медиа

Инфлюенсеры, в числе которых контент-мейкеры, стримеры или ютуберы, могут вам здорово помочь в продвижении игры. Инфлюенсеры, которые проходят на стримах игры, куда эффективнее поспособствуют в поиске аудитории.

Если вы сможете связаться с инфлюенсером или его менеджером, чтобы узнать, заинтересован ли он в вашей игре, то в конечном счете ютубер или стример покажет ее своей аудитории и порекомендует остальным. Поскольку у инфлюенсеров огромная аудитория – от тысяч до миллионов человек, – связаться с ними непросто. Ваше сообщение на почте или в директе может как попасть в их поле зрения, так и затеряться в потоке всего того, что они получают. Используйте свои навыки PR-специалиста, чтобы повысить шансы на ответ от инфлюенсера.

Будьте уважительны и дружелюбны в социальных сетях и общении, и вы заложите основу для того, чтобы инфлюенсер захотел обратить внимание на вашу игру, когда о ней узнает.

Интегрируйте в разработку специалистов по маркетингу

Если у вас есть возможность работать с профессиональными маркетологами, будь то маркетинговый отдел вашего издателя или наемная креативная маркетинговая компания, начните общаться с ней как можно раньше и делайте это чаще. По возможности начните общение, как только у вас появятся цели проекта, а затем оставайтесь на связи на протяжении всего процесса разработки. Покажите им игру и скажите, к чему, по вашему мнению, она ведет. Пригласите их в свой творческий процесс, попросив внести вклад. У них найдутся отличные идеи, а даже одна маленькая идея может кардинальным образом повлиять на успех вашей игры.

Джим Хантли сказал: «Мне нравится, когда разработчик спрашивает мое мнение до того, как “цемент схватится”, вовлекая меня в процесс разработки, чтобы узнать мое мнение. Как маркетологу мне нравится быть частью творческого процесса и чувствовать, что мое мнение ценится». Помните, что во всем, что вы делаете, при должном уважении к сотрудникам и доверительных отношениях вы получите куда больше, чем отдали.

* * *

В этой главе представлен лишь краткий обзор огромной и важной темы. Вы можете узнать больше о маркетинге в книгах Video Game Marketing: A Student Textbook Питера Закариассона и Миколая Дымека и A Practical Guide to Indie Game Marketing Джоэла Дрескина. Обратитесь за помощью к специалистам по маркетингу и PR, если вам это позволяют ваши ресурсы. Мы снова вернемся к этим темам в главе 35.

Я давно понял, что разработчики игр и специалисты по игровому маркетингу должны находить способы работать вместе. Мы все часть одной и той же творческой индустрии, стремящейся создавать отличные игры и передавать их в руки игроков, которые будут ими наслаждаться. Эми Хенниг однажды подчеркнула, что ответственность гейм-директора за впечатления игрока начинается ровно с того момента, когда игрок впервые узнает об игре: когда он видит изображения, читает какой-то текст или просматривает видео в рамках рекламной кампании или пресс-мероприятия. Поэтому так важно, чтобы команда разработки и их партнеры по маркетингу и продажам тесно и эффективно сотрудничали.

Что бы вы ни делали, чтобы охватить потенциальную аудиторию игры, оставайтесь сосредоточенными на мысли о том, что вы можете привнести подлинную ценность в жизнь людей и повлиять на них. Увлекайте идеей своей игры и проявляйте уважение, чтобы заслужить доверие аудитории. Какую бы игру вы ни создавали, будь то коммерческая, художественная, серьезная игра или академический проект, есть вероятность, что в мире найдутся миллионы людей, которые захотят с ней ознакомиться и которые ее оценят. Найдите творческий подход к тому, как с ними связаться, а затем проделайте всю необходимую работу, чтобы этот подход осуществить.

Глава 31

Майлстоун бета-версии

В процессе разработки игр майлстоун бета-версии знаменует собой окончание как разработки беты, так и всего этапа полного продакшена (рис. 31.1).

Достичь майлстоуна бета-версии зачастую непросто. На стадии беты мы должны принять последние, но крайне важные решения о содержании игры: что добавить, а что сократить. Но майлстоун беты все же крайне приятен, потому что мы наконец-то можем увидеть нашу игру в завершенном состоянии, хотя и с некоторыми шероховатостями.

Рис. 31.1. Майлстоуном бета-версии оканчивается как разработка беты, так и весь продакшен. Авторы изображения: Габриэла Пурри Р. Гомес, Мэтти Розен и Ричард Лемаршан

Что необходимо для майлстоуна бета-версии

На стадии альфы мы завершили игру с точки зрения функциональности и игрового процесса, а на стадии беты нам предстоит завершить ее еще и в плане контента. Поэтому майлстоун бета-версии гораздо легче описать, чем альфу, потому что на этапе бета-версии игра, по сути, должна быть закончена как по фичам, так и по контенту. У нас будет возможность отполировать, сбалансировать и исправить баги до майлстоуна релиз-кандидата, но все, что будет в готовой игре, уже должно быть реализовано в бета-версии.

Итак, в бета-версии все фичи и контент готовой игры уже должны быть на месте хотя бы в сносном качестве, включая весь арт, анимацию, звуковые эффекты, музыку, визуальные эффекты и тактильную отдачу (вибрацию контроллера). Все должно быть готово настолько, чтобы вы могли уже выпустить эту версию игры, будь такая необходимость, даже если вам и хотелось бы что-нибудь улучшить. Крайне важно подходить к бета-версии именно с таким настроем, потому что на этом этапе мы часто вводим что-то в игру так быстро и эффективно, как только можем, лишь бы все влезло в майлстоун. Имейте в виду, что, если по вашим срокам вы не можете выделить себе много времени на постпродакшен, готовая игра, скорее всего, будет такая же сырая, как и на стадии беты. Как правило, лучше сократить то, что можете, до завершения бета-версии, чтобы оставить себе время на полировку того, что точно попадет в игру.

На стадии беты должны быть готовы все уровни и финальный арт этих уровней и интерфейсных экранов и мы должны иметь возможность полностью пройти игру без каких-либо серьезных проблем. Обучающие уровни тоже должны быть завершены. Конец игры (если у игры есть конец) должен быть на месте и выполнять свое предназначение. Если у игры открытый финал, как в симуляторе или песочнице, у нас должна быть возможность играть в нее бесконечно, опять же без каких-либо серьезных проблем.

К бета-версии должны быть готовы иконки, используемые исполняемым файлом или приложением игры, во всех нужных размерах и текст, эти иконки сопровождающий. Если при запуске игры будет всплывать диалоговое окно лаунчера, текст и настройки лаунчера должны быть доработаны к бета-версии так же, как и экраны-заставки для запуска через лаунчер. Если игра будет распространяться через интернет-магазин, любые изображения, представляющие игру на сайте магазина, обычно создаются к бета-версии. Если в игре будет использоваться система достижений, либо внутриигровая, либо подключенная к системе достижений от издателя игры или платформы, то сама система и ее содержание должны быть готовы к бета-версии.

Если вы собираетесь добавить в игру «пасхальные яйца» (спрятанные сюрпризы для игрока[176]), их надо разработать к бета-версии, уведомив об этом руководство команды и QA-отдел. Игрокам всегда нравятся сюрпризы и секреты, но если вы что-то прячете в игре, то сначала сообщите об этом ответственным лицам, чтобы избежать неприятных ситуаций, связанных с нарушением авторских прав и обвинениями в оскорблении.

Если игра должна пройти процесс сертификации, чтобы выпуститься на игровой консоли таких издателей, как Sony, Microsoft или Nintendo, или на мобильном устройстве в экосистеме Apple, разработчики должны выполнить как можно больше сертификационных требований к бета-версии. Подробнее об этом вы можете прочитать в главе 34.

Похоже, нам надо еще много чего закончить, верно? Вас наверняка удивляет, что за такой короткий срок надо успеть так много сделать – вот почему так непросто достичь майлстоуна бета-версии. Остальная часть этой главы даст вам несколько советов, как все же в этом преуспеть.

Завершенность и майлстоун бета-версии

В книге Game Design Workshop Трейси Фуллертон рассказывает о необходимости тестирования, чтобы убедиться, что игра функциональна, завершена и сбалансирована[177]. Трейси обсуждает проверку «внутренней завершенности» игры в ее правилах и пространстве возможностей, а также рассказывает о поиске и устранении лазеек и тупиков. Конечно, мы должны заниматься этим на протяжении всего процесса разработки, но этот подход особенно важен на этапе бета-тестирования.

Лазейки, иногда известные как эксплойты, – это такие моменты в игре, когда сам ее дизайн облегчает игроку прохождение. Например, если на уровне с боссом есть случайное место, куда вы можете встать и где – из-за некоторых особенностей механик – босс не может нанести вам никакого урона, вы можете победить его без каких-либо усилий или риска, это эксплойт.

Иногда эксплойт привносит в игру нечто хорошее, а если для его использования нужны значительная сноровка и навыки, то эксплойты вовсе не вредят дизайну. Например, глитчи, которые позволяют игроку срезать путь через уровень, горячо любимы спидранерами. А неожиданное преимущество в киберспортивной игре, которое на первый взгляд кажется эксплойтом, может быть воспринято сообществом игроков как законная фича игры[178]. Возможно, вы создаете экспериментальную игру или игру, в которой сообщается о лазейках, и эксплойты в вашей игре преднамеренны. Однако для большинства типов игр, особенно тех, которые связаны с соревнованием против системы игры или против других игроков, от эксплойтов надо избавляться. Принятие решений по подобным вопросам – часть творческой работы гейм-дизайнера.

Тупик – это ситуация, когда игрок не может пройти дальше по игре из-за того, что он сделал что-то не так[179]. Вообразим игру, где есть ключ, который игрок может поднять и бросить где угодно, запертая дверь, которую открывает этот ключ, и колодец, который слишком глубок или слишком узок, чтобы в него спуститься. Игроку нужно отпереть дверь, чтобы перейти к следующей части игры, а ключ можно найти где-то поблизости. Но что, если игрок поднимет ключ и бросит его в колодец? Тогда он застрял. Он не может открыть дверь, он не может добраться до ключа, и он не может продолжить игру. Игроку нужно каким-то образом сбросить игровой мир, чтобы ключ вернулся в исходное положение.

Возможно, тут поможет смерть и перезапуск игры, но что, если объекты сохраняют свое положение после прохождения определенных контрольных точек? Возможно, перезагрузка игры с предыдущего сохранения вернет ключ в исходное положение (техника, известная как сэйв-скамминг[180]), но что делать, если в игре только один слот для сохранения и игра автоматически сохранилась сразу после того, как ключ упал в колодец? Тогда игрок действительно застрял, хотя он может даже не осознавать этого. Он может продолжать искать другой ключ, пока окончательно не заскучает или не разочаруется. Если он поймет, что произошло, и захочет продолжить играть, тогда ему придется проходить всю игру сначала. Скорее всего, игрок просто пойдет играть во что-то другое.

Эта ситуация может показаться странной, но во многих публикуемых играх невезучих игроков подстерегают такие сложности. Тупики представляют особую проблему для игр, где много системного, возникающего и процедурно генерируемого геймплея, хотя обычно существуют способы их устранения.

Тупики также могут быть приняты как неотъемлемая часть игрового процесса, особенно если игроку ясно, что он оказался в тупике. Огромные новые горизонты творческих возможностей открылись в этой области с появлением таких игр, как Spelunky, The Binding of Isaac и FTL: Faster Than Light, которые объединяют жанр roguelike с другими жанрами[181].

Не волнуйтесь, если вы не сможете обнаружить все эксплойты и тупики на этапе беты: иногда они прячутся прямо на виду, а иногда их очень нелегко найти. На поиск непростых, скрытых проблем у нас еще есть этап постпродакшена.

Стадия беты, концентрическая разработка и состояние игры

Готовясь к майлстоуну альфа-версии, мы прибегали к помощи стабов, теперь мы можем вновь обратиться к концентрическому методу, который я описал в главе 13, – но переключиться на концентрическую разработку может оказаться непросто. К сожалению, одна из традиций разработки игр заключается в том, что к майлстоуну бета-версии мы часто вводим контент в игру так быстро, как только можем, не заботясь о деталях так, как того рекомендует концентрический метод. Структурированность и дисциплина концентрического метода дают свободу творчеству, когда это действительно необходимо. В конце нам не придется сломя голову чинить все, что не работает, – у нас будет больше времени и сил, чтобы довести все до отличного качества. Если мы будем добавлять контент слишком быстро, то в итоге получим бета-версию с плохим ощущением игры, слишком сложную или слишком простую, глючную или сломанную игру. Поэтому я стараюсь работать в соответствии со старой пословицей: «Тише едешь – дальше будешь».

На стадии беты мы должны снова проверить состояние нашей игры точно так же, как делали это на стадии альфы. Сейчас крайне важно внимательно следить за техническими характеристиками игры. Если у нас низкая частота кадров, долгие загрузки, а освещение дает сбои, нужно устранить эти проблемы. Если у нас есть какие-либо серьезные проблемы с дизайном или особенно неприятные баги, за них тоже нужно немедленно браться. Вы не обязаны решить все эти проблемы к моменту достижения майлстоуна бета-версии, но у вас должен быть, по крайней мере, план их решения, чтобы вы могли приступить к нему сразу после майлстоуна. Игра с серьезными багами или низкой частотой кадров вряд ли добьется успеха.

Титры и атрибуции

Если вы последовали совету, который я дал вам в главе 5, вы постоянно вели список (а) атрибуций для любых найденных сторонних ассетов, которые использовали в своей игре, и (б) людей, которые работали над игрой, и что они сделали. Когда придет время создавать внутриигровые титры и атрибуции, вам будет значительно легче проделать эту работу. Если вы не вели такой список, вам, возможно, придется сильно напрячься, чтобы просмотреть весь контент игры, составляя списки тех, чью работу надо отметить. Некоторые приобретаемые пакеты ассетов не требуют атрибуции, поэтому внимательно проверьте информацию о лицензировании того, что вы приобрели.

При атрибуции сторонних ассетов остается открытым вопрос о том, должны ли вы перечислить используемые материалы или просто перечислить имена отдельных авторов, чьи работы вы использовали. Если в лицензии ассета указано, как оформляется атрибуция, внимательно соблюдайте указанные правила.

Вы должны включить в титры всех, кто внес свой вклад в создание игры, так что тщательно подумайте о том, кто работал над игрой, особенно на ранних стадиях разработки. Средства к существованию разработчиков игр во многом зависят от их резюме и портфолио – не создавайте коллегам лишних проблем, забывая добавить их в титры.

Испытание достижения майлстоуна беты

Гейм-дизайнерам обычно приходится принимать трудные решения, чтобы достичь майлстоуна бета-версии. Когда мы принимаем окончательные решения о масштабах нашей игры и ее контенте, увидеть лес за деревьями становится еще тяжелее. Тут может пригодиться некоторая сторонняя оценка, которая поможет нам определить приоритеты, – и такую оценку мы можем получить на обзоре майлстоуна, о котором мы совсем скоро поговорим.

Я должен быть честен с вами: несмотря на очень простое определение бета-версии – игра завершена! – границы беты, как и альфы, несколько размыты. Помимо тех уловок, которые разработчики игр могут использовать в альфа-версии (использование очень размытой разницы между фичами и контентом, как мы обсуждали в главе 28), есть уловки, к которым мы можем прибегнуть в бета-версии, чтобы представить руководству команды игру с законченным контентом. Самый известный способ – записать недостающий фрагмент контента как баг класса «А» в нашей базе данных багов.

Я был бы лжецом, если бы сказал, что не использовал этот трюк – было дело, но только с разрешения высшего руководства моей команды, при этом недостающий контент строго отслеживался в базе данных. Иногда такая уловка необходима, когда мы должны достичь майлстоуна бета-версии, но не успели ввести в игру весь необходимый контент. Добавление контента после бета-версии сопряжено с риском в той или иной степени. Если в итоге у вас будет более нескольких багов класса «А», которые на самом деле являются недостающими фрагментами контента, ваш проект может столкнуться с проблемами на этапе постпродакшена. Исправьте эти баги, добавив нужный контент, сразу после беты.

После этапа беты разработчики игр иногда вносят в свой контент настолько серьезные изменения, что с таким же успехом они могли бы добавлять новый контент. Это тоже рискованно: такие поздние изменения скорее создают проблемы, а не решают их. Как и в случае с фичами, каждый раз, когда мы добавляем новый контент, мы рискуем заполучить баги, проблемы с контентом и проблемы с дизайном. Чем больше времени у вас есть на этап постпродакшена, тем меньше риска сулят вам основные изменения, особенно если они сделаны на ранней стадии этого этапа.

Добавлять или менять контент, относящийся к системным или интерактивным частям игры, куда рискованнее, чем добавлять или менять статические ассеты, такие как фон титульного экрана, или линейные ассеты, такие как отрендеренные видеофайлы кат-сцен. Замена плейсхолдера кат-сцены ее окончательной, готовой версией не лишена риска – новый видеофайл может больше весить и, как следствие, привести к проблемам с памятью[182]. Но гораздо менее рискованно заменять одну часть статического или линейного контента на другую, чем возиться с системными и интерактивными частями игры, где вероятность возникновения серьезных проблем гораздо выше.

Подведение итогов майлстоуна бета-версии

Таким образом, к майлстоуну бета-версии в игре должно присутствовать следующее.

• Все фичи и контент игры в приличном качестве.

• Весь фронтенд, меню и элементы интерфейса в приличном качестве, включая следующие элементы:

☉ логотип команды разработчиков и/или игровой студии;

☉ логотип издателя или факультета;

☉ титульный экран (элемент интерфейса, где можно принять решение, как начать игру);

☉ титры;

☉ указание авторства (атрибуции) для любых использованных сторонних ассетов;

☉ экран «игра окончена», который объявляет об окончании раунда игры (если это применимо к вашей игре);

☉ экран опций или экраны, позволяющие игрокам настраивать опыт (если это применимо к вашей игре).

• Иконка игры со всеми требуемыми разрешениями для приложения или исполняемого файла и ее название.

• Изображение экрана-заставки для игры, которая запускается через лаунчер.

• Любые изображения и текст, необходимые для интернет-магазина.

• Контент системы достижений, как внутриигровой, так и подключенной к сервису издателя (если это применимо к вашей игре).

• Любые «пасхальные яйца» (скрытые сюрпризы для игрока), которые вы планируете поместить в игру.

• Если для выпуска игры потребуется пройти процесс сертификации, разработчики должны выполнить как можно больше сертификационных требований (подробнее в главе 34).

Кроме того, на этапе бета-версии мы должны разработать и начать реализовывать действенный план по решению:

• любых нерешенных проблем с дизайном;

• любых проблем с производительностью;

• серьезных багов.

Обзор майлстоуна бета-версии

Когда игра достигает стадии беты и завершена как по фичам, так и по контенту, у нас есть прекрасная возможность – а для коротких проектов, возможно, последний шанс – провести обзорную встречу и получить обратную связь от людей внутри и за пределами команды, которые направят наши усилия в нужное русло.

Как и обзор майлстоуна альфа-версии, обзор беты крупной профессиональной игры, вероятно, займет некоторое время, обзор менее масштабных проектов пройдет быстрее. Убедитесь, что вы эффективно используете время своей команды, но не упустите шанс получить откровенные, качественные отзывы от доверенных коллег и наставников и действительно лучше узнать свою игру. На стадии бета-версии обычно возникает много мелких проблем, которые необходимо выявить и обсудить, и игровой команде может быть трудно решить, какие из них важнее. Как я упоминал ранее, мнение со стороны – очень эффективное средство, когда мы не можем увидеть общую картину, потому что перегружены деталями.

В своей короткой вступительной презентации руководство команды разработчиков должно представить следующее.

• Кого они считают аудиторией своей игры. Позиционирующее утверждение (см. главу 7) должно быть максимально конкретным.

• Насколько успешно бета-версия игры отвечает требованиям майлстоуна. Например:

☉ бета-версия полностью отвечает требованиям майлстоуна, в игре представлен весь контент, баги устранены, в игре соблюден игровой баланс (мы поговорим о балансе в главе 32);

☉ проект соответствует требованиям в плане контента. необходимо еще отполировать некоторый контент, устранить баги и поработать над балансом игры;

☉ проект преодолел стадию беты, весь контент уже добавлен в игру, но большая его часть нуждается в доработке, в игре много багов, игра плохо сбалансирована;

☉ проект еще не достиг майлстоуна бета-версии. команда сообщает, чего им не хватает для беты.

• Есть ли какие-то известные проблемы с проектом.

• По каким вопросам нужна обратная связь.

На этом этапе члены обзорной группы должны очень осторожно соблюдать правило, которое мы обсуждали в разделе «Конструктивная и своевременная критика» в главе 20. Игра завершена, поэтому теперь проблемы (в большинстве случаев) нужно решать путем внесения незначительных изменений в игру. Некоторым устранение проблем без внесения серьезных изменений покажется невозможным, но опытные дизайнеры понимают, что даже в самых жестких ограничениях всегда есть место для маневра. Им останется только найти разумный, эффективный и нерискованный способ разобраться с этими проблемами.

Команда также должна провести внутренний обзор, чтобы дисциплинарные и междисциплинарные группы собрались вместе и обсудили бета- версию и то, что необходимо сделать во время этапа постпродакшена. (Подробнее о внутренних обзорах вы можете прочитать в главе 20.) Члены внутренних обзорных групп тоже должны следить за своевременностью своих замечаний, не забывая обсуждать риски, связанные с разрабатываемым ими планом действий.

* * *

Качество и работоспособность бета-версии игры могут многое рассказать о том, какой может получиться готовая игра, особенно если на постпродакшен выделено мало времени. Если игра не особенно хорошо зарекомендовала себя на бета-тестировании, команде будет непросто. Им может понадобиться некоторая эмоциональная поддержка со стороны их сообщества, руководства и друг друга.

Но даже если на стадии беты дела обстоят плохо, у вас все равно есть возможность довести релиз-кандидат до высокого уровня качества. Отложите в сторону контент игры – он остался на этапе бета-версии – и переходите к постпродакшену с настроем так улучшить игру, чтобы она действительно запела.

Четвертый этап: постпродакшен – исправляем и полируем

Глава 32

Этап постпродакшена

После завершения стадии беты в современной видеоигре еще многое предстоит сделать, прежде чем ее можно будет считать готовой к майлстоуну релиз-кандидата. Постпродакшен – то самое время, когда мы должны доделать все что нужно.

Название этого этапа отсылает к одноименному процессу кино- и телепроизводства, но имейте в виду, что постпродакшен в геймдеве сильно отличается от оного в кино и на телевидении. В кино и на телевидении постпродакшен относится ко всему, что происходит после съемки фильма или видео. На этапе постпродакшена фильмы и телепередачи вылепляют из сырой глины отснятого видео с помощью процесса редактирования, звукового дизайна, создания визуальных эффектов и цветокоррекции[183].

Но игра на этапе продакшена уже создана и завершена. Постпродакшен игр подобен самому концу постпродакшена фильмов и телепрограмм, когда готовы окончательный монтаж фильма, все звуковое оформление и визуальные эффекты[184]. Затем дорабатываются окончательный звуковой микс и любые другие элементы, нуждающиеся в улучшении. Игры нуждаются в микшировании звука и цветокоррекции на этапе постпродакшена, а также в других вещах, специфичных для игр.

Необходимость официального этапа постпродакшена возникла у нас, когда мы заканчивали работу над Uncharted 2: Among Thieves, проектом, который принес Naughty Dog большой успех, но при этом немало проблем. Одна из этих проблем заключалась в том, что у нас оставалось мало времени между бета-версией и майлстоуном релиз-кандидата на завершение всех работ. Сюда входили балансировка и выравнивание уровней звука интерактивной и фоновой музыки, настройка освещения, а также доработка цветокоррекции и постобработка изображения. Вся эта работа навалилась поверх баланса игры и исправления багов, которые тоже остались на конец проекта.

Мы почти все сделали в Uncharted 2, но на самом деле мы едва отвечали высоким стандартам, которые себе установили, и это означало много напряженной работы в конце проекта. Поэтому в работе над Uncharted 3: Drake's Deception мы выделили себе по-настоящему много времени на постпродакшен, оставив работу над контентом на стадии беты и принявшись за полировку.

Сколько времени должен занимать постпродакшен

На этот вопрос нет единого ответа, который подходил бы для каждого проекта, но мы можем прибегнуть к мудрости наших коллег. Tale of Tales – студия разработки видеоигр, основанная современными художниками Аурией Харви и Микаэлем Самином в 2003 году. В своем превосходном и вдохновляющем эссе 2013 года The Beautiful Art Program («Прекрасная программа») Аурия и Микаэль дают такое наставление: «После завершения проекта мы должны потратить столько же времени на то, чтобы сделать его лучше»[185].

Я думаю, что этот совет, который на первый взгляд может показаться парадоксальным, превосходен. Игры очень многое получают от времени, которое мы тратим на их улучшение. Я никогда не мог потратить на полировку игры столько же времени, сколько на саму ее разработку, но чем больше времени вы сможете посвятить этапу постпродакшена, тем лучше. Я рекомендую выделять на этот этап не менее 20 процентов от общего времени проекта.

Многие проекты как в индустрии, так и в академических кругах строго ограничены по времени, а дата сдачи майлстоуна релиз-кандидата строго фиксирована задолго до создания игры. Воспользуйтесь известной вам датой сдачи проекта, чтобы распланировать стадию беты и выделить достаточно времени на постпродакшен. Работая над проектом, где мы не ограничены во времени, мы можем выделить себе столько времени на постпродакшен, сколько захотим или сколько нам действительно нужно. Это крайне удобно, но будьте осторожны. Вам надо будет четко следить за тем, действительно ли вы продолжаете улучшать игру или просто без конца с ней возитесь, стремясь добиться невозможного.

В некоторых проектах могут перенести майлстоун релиз-кандидата, чтобы дать команде больше времени на постпродакшен. Это нормальная практика, пока она не перерастает в постоянный перенос даты окончания проекта, который мы обсуждали в главе 15. Для многих проектов окончательный срок сдачи проекта не может быть сдвинут после начала этапа постпродакшена просто потому, что проект близится к концу и все механизмы, которые поддерживают запуск коммерческой игры, уже запущены. В таком случае нам надо выяснить, как лучше всего потратить имеющееся у нас в распоряжении время.

Давайте посмотрим, что именно мы делаем с игрой на этапе постпродакшена. Три основных пункта общие для большинства типов игр: исправление багов, полировка и правки баланса игры.

Исправление багов

В главе 23 мы говорили о процессе поиска багов и последующего отслеживания багов. К тому времени, когда игра выходит из беты, у нас на руках длинный список багов, которые необходимо исправить, даже если мы исправили серьезные баги сразу после их возникновения. Новые баги появляются каждый раз, когда мы что-то добавляем в нашу игру, – и это нормально, особенно в суматохе, которая сопровождает майлстоун бета-версии, наш список багов обычно растет очень быстро. После беты большая часть усилий команды вполне может быть сосредоточена на исправлении багов. QA-отдел становится более важным для процесса разработки, чем когда-либо прежде, поскольку между командой и готовой игрой теперь стоят только базы данных багов.

Отдельные баги будут проверяться и обсуждаться, иногда энергично или даже горячо, но, надеюсь, всегда в атмосфере уважения и доверия. Каждому члену команды крайне важно помнить, что мы все работаем ради одной цели: прекрасной игры. Из-за того, что мы по-разному ценим разные дисциплины и отделы, может возникнуть конфликт: баг, который одному кажется незначительным, для другого может иметь колоссальное значение. Но мы должны руководствоваться не сиюминутными порывами и целями, а думать о том, что принесет наибольшую пользу игре и нашему сообществу игроков. И только работая вместе, мы сможем выяснить, как лучше всего решить каждую проблему за оставшееся у нас время.

Исправления, над которыми мы работаем, могут легко привнести в игру другие проблемы. Некоторые исправления более рискованны, чем другие: любое исправление бага, которое подразумевает внесение глобальных изменений в игру, куда рискованнее, чем то, которое затронет лишь малую часть игры. Конечно, тестирование должно выявить новые возникающие проблемы, но чем ближе мы к релизу, тем больше вероятность того, что новые проблемы останутся незамеченными.

В эпоху цифрового распространения мы можем выпускать обновления для устранения багов в уже изданной игре, но мы все равно должны быть очень осторожны во время этапа постпродакшена. Необнаруженные баги, появившиеся в игре из-за внесенных изменений, могут вызвать у нас большие проблемы. Вдруг очень серьезный баг попадет в билд, который мы отправляем инфлюенсеру или рецензенту, или окажется в уже изданной игре? Если у людей сложится негативное впечатление о нашей игре или они вообще не смогут в нее играть, это сильно ударит по нашей карьере. Вирусные видеоролики с впечатляюще ужасными багами могут легко убить интерес аудитории к игре.

Я не сторонник тотальной паранойи, что нужно успеть исправить все за этап постпродакшена – опытные гейм-дизайнеры учатся определять, насколько рискованно то или иное исправление бага. Но мы должны действовать осторожно, особенно ближе к концу этапа постпродакшена. Чем мы ближе к майлстоуну релиз-кандидата, тем продуманнее должны быть наши исправления – у нас попросту не хватит времени на устранение новых багов. Так что подходите к этому процессу с осторожностью хирурга. Повысьте приоритет более сложных и рискованных исправлений и займитесь ими в первую очередь.

Полировка

Как только игра будет завершена к бета-майлстоуну, вы сможете начать полировать контент, внося небольшие изменения, чтобы улучшить внешний вид, звучание и ощущение игры. В предыдущей главе мы говорили, что мы должны внедрять контент в таком качестве, чтобы при необходимости игру можно было уже опубликовать. Желательно, чтобы наши первые наброски контента были хорошо отполированы еще до того, как они попадут в игру, – как и в любом виде ремесла, чем опытнее мы становимся, тем более высокого качества будут даже самые черновые наши работы.

Чем больше времени у нас на постпродакшен и чем меньше у нас багов, тем больше времени мы можем посвятить полировке. И наоборот, если у нас не так много времени на постпродакшен и нужно исправить много багов, на полировку у нас остается совсем немного времени. Исправление ошибок обычно приоритетнее улучшения контента: выпускать игру с плохим звуковым сопровождением или визуалом никто не захочет, но у забагованной игры еще меньше шансов на успех.

Как и в случае с исправлением багов, любая работа, связанная с полировкой игры во время этапа постпродакшена, рискованна, поскольку она может привести к появлению новых ошибок и проблем с дизайном. Чем больше изменений требует полишинг, тем выше риск. Основная работа по полировке – особенно если она глобально меняет игру – должна быть сделана в самом начале этапа постпродакшена. Полировка должна быть закончена к его середине, чтобы у нас было время выявить и устранить все возникшие проблемы.

Правки баланса игры

В своей книге Challenges for Game Designers: Non-Digital Exercises for Video Game Designers Бренда Ромеро и Ян Шрайбер дают следующее определение игрового баланса:

Баланс: термин, используемый для описания состояния систем игры как «сбалансированных» или «несбалансированных». Когда игра не сбалансирована, она слишком легка, слишком сложна либо же подходит только определенной группе игроков. Когда игра сбалансирована, она предоставляет консистентный уровень испытаний для своей целевой аудитории. В соревновательных играх баланс подразумевает то, что нет какой-то единой стратегии, которая лучше прочих, и что нет эксплойтов, которые позволят игроку обойти предлагаемые игрой испытания. Мы также иногда называем отдельные игровые элементы «сбалансированными» друг с другом, что означает, что стоимость их получения пропорциональна производимому ими эффекту, как в случае с картами в ККИ или оружием в шутерах от первого лица и RPG[186].

Большинство гейм-дизайнеров пытаются сбалансировать дизайн своей игры на протяжении этапов препродакшена и продакшена, настраивая механизмы и механики для создания интересного, приятного опыта в игре, который будет не слишком легким, не слишком сложным. Тем не менее точно настроить игровой баланс к бета-версии может быть непросто. Этап постпродакшена дает нам последний шанс окончательно разобраться с балансом игры.

В своем блоге Game Balance Concepts («Принципы игрового баланса») Ян Шрайбер пишет:

Возможно, это слишком упростит определение, но мы можем сказать, что игровой баланс занимается расчетами чисел, которые используются в игре.

И тут же возникает вопрос: а что, если в игре нет никаких чисел и никакой математики? Например, в детской игре салочки нет чисел. Значит ли это, что понятие «игровой баланс» неприменимо к салочкам?

На самом деле числа в салочках есть: на какое расстояние и с какой скоростью может бежать каждый из игроков, как далеко друг от друга находятся игроки, размеры игровой площадки, как долго кто-либо из участников водит. Мы не отслеживаем все эти параметры, потому что салочки – не профессиональный спорт. Но если бы они им были, поверьте, у нас была бы куча карточек и сайтов со статистикой всех этих цифр!

Итак, в каждой игре есть свои числа (даже если они скрыты и неявны) и цель этих чисел – описать состояния игры[187].

К альфа-версии все механизмы нашей игры уже на месте: игра полнофункциональна. После бета-версии, когда мы переходим к постпродакшену, мы уже не можем сбалансировать игру, добавляя или изменяя ее механизмы. Все вычисления уже готовы и, надеюсь, рассчитаны так, что игра довольно хорошо сбалансирована. Все, что мы делаем с балансом на этапе постпродакшена, должно выполняться путем осторожной и тонкой настройки значений этих вычислений.

Конечно, есть некоторые значения, которые мы уже не сможем изменить. Как мы обсуждали в главе 13, если вы уменьшите высоту прыжка персонажа игрока даже на крошечную величину, персонаж может не дотянуться до выступов, на которые он должен залезть, и вся игра сломается.

Но некоторые значения можно изменить таким образом, чтобы это пошло на пользу игре. Например, небольшие изменения в числах, определяющих движение и боевые взаимодействия персонажей в экшен-игре, могут повлиять на уровень сложности игры, сделав ее чуть более сложной или легкой. Незначительные изменения в скорости накопления ресурсов могут оказать радикальное влияние на ход стратегической игры. Небольшие изменения скорости, с которой текст появляется в повествовательной игре, помогут игроку лучше ориентироваться в истории и верно расставить акценты на разворачивающихся событиях. Опять же, надеюсь, вы и так осторожно подбирали все эти числа на протяжении процесса разработки. Если вам необходимо внести серьезные изменения, вносите их на ранней стадии этапа постпродакшена. Так вы оставите себе время на выявление нежелательных последствий.

При правках баланса игры важно вносить только одно изменение за раз, а затем тщательно тестировать игру. Если вы измените два значения, а затем заметите, что что-то поменялось не в лучшую сторону, вы не сможете точно определить, в чем именно проблема. Как правило, это хорошая практика гейм-дизайна – менять что-то одно, а затем тестировать игру. Это не всегда возможно при создании игры на этапе продакшена, но крайне важно придерживаться такого подхода на этапе постпродакшена.

При правках баланса игры легко запутаться в деталях и в конечном счете начать ходить по кругу, внося крошечные изменения, а затем отменяя их. Попросите совета у ваших коллег, если вы столкнетесь с этой проблемой, – они обязательно направят вас в нужное русло. Возможно, вы никогда не найдете идеального баланса для игры, но если оставите себе хотя бы немного времени на его настройку во время этапа постпродакшена, то увеличите шансы приблизить игру к совершенству. Если хотите больше узнать об этой теме, Джесси Шелл предлагает множество отличных советов по игровому балансу в книге «Геймдизайн. Как создать игру, в которую будут играть все»[188].

Суть постпродакшена

Приступая к этапу постпродакшена, мы приближаемся к концу марафона. Мы можем быть измотаны, волоча ноги к финишной черте, чтобы поскорее со всем этим покончить. Но если мы придерживались здоровых методов работы, следили за содержанием проекта и за собой на протяжении всего процесса разработки, мы, может быть, и устали, но у нас все еще остается немного энергии. Мы должны делать все от нас зависящее, чтобы в итоге в наших батареях оставался хоть какой-то заряд, – нам предстоит принять верные решения на заключительных этапах проекта, чтобы наша игра добилась успеха.

Работа, которую мы выполняем во время этапа постпродакшена, чрезвычайно важна. Мне нравится аналогия этапа постпродакшена с карточным домиком: вот мы его уже построили и теперь осторожно кладем две последние карты на самый верх. Одна маленькая ошибка – и все рухнет. Если мы внесем изменения в дизайн, которые кажутся незначительными, но которые негативно повлияют на опыт игры, и если мы не заметим этого негативного влияния до релиза, у нас могут быть большие проблемы.

Даже люди, которые обычно осторожны и методичны, склонны совершать ошибки от усталости. Вот почему так важно заботиться о себе на протяжении всего проекта: высыпаться, заниматься спортом, общаться, правильно питаться и делать все то, что приносит нам радость. Можно сказать, что поддержание здорового образа жизни – тоже своего рода часть гейм-дизайна, поскольку это непосредственно влияет на то, насколько эффективно мы создаем игры.

Смена точки зрения

Смена точки зрения – это концепция, используемая теоретиками литературы и философами, которую я считаю полезной и для гейм-дизайна. Эта концепция может по-разному восприниматься, но в основном она связана с возможностью аудитории, художников, игроков и дизайнеров переключаться между различными точками зрения. Разные точки зрения продиктованы разными факторами, такими как приоритеты, ценности и способ мышления.

Когда я думаю о смене точки зрения как гейм-дизайнер, я думаю о:

• взгляде игрока на игру;

• макроскопическом взгляде дизайнера на всю игру или ее часть;

• микроскопическом взгляде дизайнера на некоторые детали игры;

• взгляде персонажа игрока на вымышленный мир, в котором происходит действие игры (или взглядах персонажей игрока, если их несколько);

• представлении об игровом мире других персонажей в игре;

• взгляде на игру, которого придерживается определенный отдел команды разработчиков; например, то, как программист или художник видит игру;

• мнении об игре других специалистов, которые будут работать над ней; например, маркетологов и комьюнити-менеджеров.

Мы могли бы продолжать этот список, изучая то, как самые разные люди видят игру, и то, как сами вымышленные персонажи внутри игры видят свой мир, самих себя, свои цели, свои ценности и свои действия. По моему опыту, разработчики игр, способные быстро переключаться между точками зрения, очень высокопрофессионально вносят творческий вклад, решают проблемы и сотрудничают. Смена точки зрения очень важна для такого рода междисциплинарного сотрудничества, необходимого для любой сложной, творческой и технической формы искусства.

Смена точки зрения особенно важна для гейм-директоров, которые должны постоянно рассматривать игру как макроскопически, так и микроскопически. Они должны видеть игру с точки зрения множества различных профессиональных специализаций, должны видеть игровой мир таким, каким его видят вымышленные персонажи, и всегда должны отстаивать опыт игрока. Если карьерный путь гейм-директора входит в число ваших целей, начните развивать вашу смену точки зрения.

Непредвзятость в некотором смысле схожа со сменой точки зрения, так что попробуйте развивать мышление так, чтобы оно было открыто самым разным и даже противоречивым взглядам. Я заметил, что чем больше я устаю, тем я менее восприимчив к новым идеям, иногда исключительно эмоционально. Я устал, и я просто хочу закончить свою работу! Зачем вы просите меня принимать во внимание еще другую точку зрения? – такова моя реакция, с которой мне часто приходилось бороться. Вот еще одна причина придерживаться здорового подхода к работе на протяжении всего проекта и никогда не работать до изнеможения.

Постпродакшен – это время, когда нам часто приходится очень быстро переключаться между различными взглядами на игру. Нам придется взглянуть на игру с дюжины разных точек зрения при исправлении одного-единственного бага: с точки зрения игрока, человека, в чьем коде этот баг нашелся, человека, который передал баг разработчикам, человека, который должен исправить этот баг, человека, которому нужна наша помощь с другим багом, который он считает более важным, ведущего продюсера, гейм-директора, продакт-менеджера, команды маркетинга и так далее. То же самое касается полировки и правок баланса.

Смена точки зрения поможет вам найти наилучшие решения и поспособствует сотрудничеству между членами команды и успеху самой игры.

Волны постпродакшена

Что интересно в постпродакшене, так это то, как мы прекращаем работу над игрой. В большой команде разные дисциплины будут заканчивать работу над проектом в разное время, постепенно завершая игру поэтапно или волнами. Конечно, если все в команде продолжают что-то вносить в игру до самого конца проекта, существует высокая вероятность того, что какая-то ошибка останется незамеченной до релиза. Мы должны выводить людей из проекта волнами, постепенно передавая работу все меньшей и меньшей группе.

В больших командах, где я работал, это происходило следующим образом. Во-первых, устанавливается майлстоун на «начало конца» постпродакшена. К этому моменту должны быть исправлены все баги, связанные с контентом. На этом этапе почти все художники, аниматоры, звукорежиссеры и художники по визуальным эффектам должны исправить или закрыть все свои баги и прекратить работу над игрой. Оставшиеся баги передаются руководителям этих дисциплин, которые исправят их так быстро, как только смогут.

Вскоре после этого устанавливается майлстоун для гейм-дизайнеров, которые должны закончить исправление багов, связанных со скриптованием игровых событий, невидимыми триггерами, сплайнами камеры или чем-то еще, имеющим отношение к жанру создаваемой игры. Опять же, гейм-дизайнеры должны исправить или закрыть свои баги к назначенному сроку и прекратить работу над игрой, при этом последние сложные баги передаются ведущим гейм-дизайнерам.

QA-отдел будет продолжать работать в течение всего этого времени, проверяя баги, которые исправили разработчики, и следя за появлением новых. Последний майлстоун остается за программистами, поскольку они исправляют или закрывают последние из своих ошибок. Как правило, завершают карточный домик – нашу игру – именно ведущие программисты, исправляя все, что осталось. Теперь игра становится релиз-кандидатом и готова к заключительному раунду тщательного тестирования, прежде чем ее можно будет опубликовать.

Зачастую тех, кто первым завершает работу над игрой, мучает эмоциональная борьба: мы находимся в подвешенном состоянии, с нетерпением ожидая, когда же все закончится, но без возможности самим как-то повлиять на завершение игры. Это очень похоже на ожидание каких-то новостей или результатов, которые нам крайне важны, например баллов за экзамен или рождения ребенка. Нас одолевает сильное чувство незавершенности, которое для многих очень волнительно.

С этим нервирующим чувством ничего не поделаешь, остается только его терпеть и помнить, что мы сделали все возможное, как бы все ни сложилось. Пока мы ждем, самое время удвоить наше внимание к своему здоровью и благополучию, правильно питаясь, занимаясь спортом и всячески поддерживая свой боевой дух. И не стоит забывать, что мы всегда можем обратиться к нашим друзьям и семье.

* * *

Надо оставаться в хорошем настроении на протяжении всего проекта, но это особенно важно во время этапа постпродакшена, тем более для людей, занимающих руководящие должности. Постпродакшен может оказаться трудным и напряженным этапом для всей команды, но плохое настроение и споры лишь затруднят и без того сложную работу.

Это не значит, что мы должны натягивать фальшивую улыбку и делать вид, что нас ничего не беспокоит. Это означает, что мы должны осознавать, как наше настроение влияет на других. Мы должны найти подходящее время и место, чтобы выплеснуть свои сложные эмоции, поговорив с членом семьи или другом не из команды. Даже несмотря на то что постпродакшен может быть очень трудным, поскольку мы изо всех сил пытаемся закончить игру и сделать ее превосходной, нам будет чуточку легче, если мы постараемся сохранить позитивный взгляд на вещи.

В следующих нескольких главах мы поговорим о последнем майлстоуне – майлстоуне релиз-кадидата – и обсудим, что происходит с релиз-кандидатом в процессе сертификации. Мы рассмотрим некоторые другие аспекты, которые могут потребовать нашего внимания во время этапа постпродакшена, и посмотрим, как будут развиваться события уже после завершения проекта.

Глава 33

Майлстоун релиз-кандидата

Майлстоун релиз-кандидата наступает, когда мы наконец собираем билд игры, который, по нашему мнению, готов к выпуску. Мы исправили все баги, которые смогли, завершили полировку, на которую нам хватило времени, и сбалансировали игру, насколько это было возможно. Мы тщательно протестировали игру, не обнаружив никаких серьезных проблем. Теперь мы готовы провести последний раунд тестирования, чтобы наконец дать добро на распространение игры. Когда игра достигает майлстоуна релиз-кандидата, иногда говорят, что она «ушла на серебро» – а за серебром, как известно, следует золото.

На протяжении всей этой книги я говорил вам, что релиз-кандидат – заключительная ступень цифровой игры. Но это не совсем так. Выпуск программного обеспечения – сложный процесс, и, как и в случае с поэтапностью процесса постпродакшена, в самом конце проекта скрывается еще один майлстоун. Как только мы тщательно протестируем релиз-кандидат, он алхимически переходит из серебра в золото, становясь финальной – золотой – версией, а мы получаем возможность нашу игру распространять.

Такая версия называется золотой, потому что в начале 90‑х некоторые диски CD-ROM были золотистого цвета из-за органических красителей или настоящего золота в составе записываемого слоя[189]. Физический золотой мастер-диск создавался в игровой студии или у издателя и отправлялся на завод-изготовитель для дублирования на картриджи, дискеты или компакт-диски, которые потом продавали в игровых магазинах. Сегодня мы можем отправлять эту информацию через интернет несколькими щелчками мыши и распространять ее онлайн.

Другими словами, на этапе релиз-кандидата программисты, режиссеры и продюсеры проекта готовы отступить и сказать: «Хорошо, кажется, игра закончена. Протестируйте ее еще раз, чтобы быть уверенными. И тогда у нас будет золотая версия, готовая к выпуску».

Что нужно для релиз-кандидата

С практической точки зрения релиз-кандидат – это версия игры, которая:

• завершена с точки зрения фичей и контента;

• прошла некоторую полировку как фичей, так и контента;

• была сбалансирована;

• достаточно часто тестировалась, чтобы мы были уверены, что обнаружили все существенные баги;

• прошла проверку на исправление всех критических багов и блокеров (при этом баги, которые мы решили не исправлять, закрыты).

Уточнение в последнем пункте, вероятно, покажется многим читателям странным или даже ужасным. Как можно выпускать игру с ошибками, о существовании которых мы знаем? Я сам долгое время восставал против этой идеи. Как гейм-дизайнера, который заботится о высоком качестве своей работы, меня мысль о релизе игры с багами приводила в ужас.

Но в конце концов мне пришлось принять это как реальность разработки программного обеспечения. Мы здесь говорим не о багах, которые вызовут проблемы у игрока – такие баги, конечно, стоит исправлять. Мы закрываем только те ошибки, наличие или отсутствие которых является скорее суждением о субъективном восприятии игры. Если ошибка не влияет на геймплей и большинство игроков ее не заметит, то мы можем ее закрыть, особенно если у нас мало времени на исправление куда худших багов.

К релиз-кандидату нам нужно сделать кое-что еще. Что-то из перечисленного может требоваться на ранней стадии этапа постпродакшена и, возможно, для достижения майлстоуна бета-версии:

• из билда должны быть удалены меню отладки и комбинации клавиш для быстрого перемещения. Разработчики часто встраивают такие функции, чтобы телепортироваться по игре, сделать персонажа игрока неуязвимым или предоставить ему неограниченные ресурсы, а также проанализировать технические системы игры;

• должны быть удалены любые отладочные показания на экране (например, показатель частоты кадров);

• должны быть созданы фичи и контент, которые потребуются для сертификации игры, если они еще не были созданы и доработаны. Мы обсудим это более подробно в главе 34.

Как только мы подготовим релиз-кандидат, мы готовы еще его потестировать.

От релиз-кандидата к золотой мастер-версии

Тестирование релиз-кандидата для перевода проекта в статус золотой мастер-версии как никогда строго. Нужен комплексный и всеобъемлющий тест-план, легион квалифицированных специалистов по обеспечению качества, а также несколько инженеров, продюсеров и других членов руководства команды. Могут также потребоваться художники, аниматоры, звукорежиссеры и гейм-дизайнеры.

Подобно детективам, расследующим сложное дело, QA-команда зорким орлиным глазом выискивает ошибки билда. Они охотятся за неприятными скрытыми багами, которые воспроизводятся очень редко или только тогда, когда игрок делает что-то необычное и неожиданное. Конечно, все это – регулярная практика обеспечения качества, но здесь, на заключительном этапе тестирования, она становится еще важнее.

QA проводит «тестирование утечек», оставляя игру запущенной, но бездействующей в течение нескольких дней подряд, чтобы убедиться, что она не выйдет из строя. Они проверяют каждую часть пространства возможностей игры в последний раз, чтобы убедиться, что все на месте и исправно работает. Они проверяют, соответствует ли игра сертификационным требованиям издателя или платформы – мы обсудим это в следующей главе.

Если обнаружатся какие-либо ошибки, с QA встретится руководство команды, чтобы выяснить, насколько серьезна проблема и не придется ли вносить изменения в релиз-кандидат. Как мы обсуждали в предыдущих главах, каждый раз, когда мы что-то меняем в игре, мы рискуем непреднамеренно создать новые проблемы. QA-отдел будет начинать весь процесс тестирования заново каждый раз, как в код вносится даже одно изменение.

Таким образом мы кропотливо продвигаемся к созданию золотой версии. Конечно, небольшим командам с ограниченными ресурсами этот этап проекта покажется сложным. Существуют QA-студии, которым команды передают это бремя на аутсорс, но командам с маленьким бюджетом придется проводить тестирование самостоятельно.

Профессиональные команды должны перейти к золотой версии игры так, чтобы это соответствовало ресурсам и финансам проекта. Остается открытым вопрос, должны ли проходить этот путь академические проекты или же игра может считаться завершенной на стадии релиз-кандидата. На мой взгляд, более короткие академические проекты продолжительностью до одного семестра можно считать завершенными после достижения майлстоуна релиз-кандидата, но годичные, завершающие или магистерские проекты должны проходить все этапы создания игры, поскольку опыт, полученный на самом последнем этапе процесса, крайне ценен для будущих специалистов. Конечно, студенческие команды, которые выпускают свои работы на коммерческой платформе в рамках курсовой работы, должны создавать золотые версии своих проектов и при необходимости проходить процесс сертификации.

Выпуск игры

Как только мы убедимся в рабочем состоянии релиз-кандидата, мы можем считать, что достигли золотой версии, и переходить к следующему этапу выпуска нашей игры. Если мы выпускаем игру на нашем собственном веб-сайте или каким-либо другим способом, который полностью под нашим контролем, то мы можем просто выпустить игру, сделав ее доступной для скачивания.

Если мы выпускаем игру на таком сервисе, как Steam или Google Play, нам надо будет пройти короткий процесс подачи заявки и утверждения, а также, возможно, внести плату. Владельцы платформы проверят игру и либо одобрят ее для распространения, либо откажут.

Даже если мы не выпускаем нашу игру на консоли, опубликовать ее куда сложнее, чем просто разместить в интернете. Нам нужно продвигать наш проект, если мы хотим, чтобы люди о нем узнали. Мы поговорим об этом подробнее в главе 35.

Глава 34

Процесс сертификации

Если мы создаем игру для игровой консоли на таких платформах, как Sony, Microsoft или Nintendo, или которая будет выпущена на мобильной платформе в экосистеме Apple, нам нужно будет пройти процесс сертификации перед релизом игры. Этот процесс включает в себя подачу заявки, проверку на соответствие требованиям платформы и саму сертификацию.

В главе 7 мы говорили о том, как стать разработчиком аппаратной платформы такого типа. Когда нас одобрят как разработчика выбранной платформы, мы получим список требований, которым должна соответствовать игра, прежде чем ее разрешат выпустить. К ним относятся:

• технические требования: то, как в игре используются аппаратные и программные библиотеки платформы, включая разрешение экрана и частоту обновления, скорость доступа к диску, а также то, как адресуются процессоры;

• контроль качества: насколько игра должны быть очищена от багов и удобна в использовании интерфейса;

• безопасность: наличие механизмов, которые защищают игру от копирования и сохраняют конфиденциальность пользователя;

• контент: разрешены ли определенные изображения, звуки и тематика, как игра работает на нескольких языках;

• соответствие игровых систем, например систем достижения, определенным стандартам и соглашениям;

• брендинг: как используются и изменяются логотипы компании и игровой системы, включая изображения, связанные с игровым контроллером;

• информация, необходимая для продажи игры в интернет-магазине платформы: текст, изображения, фильмы и иконки;

• возрастные рейтинги, которые мы обсудим ближе к концу этой главы;

• требования к локализации, в зависимости от того, в какой части мира выйдет игра;

• цена: стоимость игры.

Документ с сертификационными требованиями обычно включает в себя несколько сотен условий, которые должна выполнить игра, чтобы ее допустили к релизу. У каждой компании свой набор сертификационных требований и свое название для них. В Sony PlayStation они называются TRC (Technical Requirements Checklist) – «список технических требований». В Microsoft Xbox – TCR (Technical Certification Requirements) – «технические сертификационные требования». Система сертификации Nintendo известна как процесс LotCheck. В целом все эти термины схожи, но у них есть существенные различия в деталях – например, то, как они работают с данными игрока, многопользовательским режимом и системой достижений. Если вы разрабатываете игру для нескольких платформ одновременно, вы должны подробно изучить требования к сертификации и создавать свою игру с учетом этих различий.

Имейте в виду, что в большинстве компаний происходят два параллельных процесса: технический, связанный с разработкой игры, и процесс публикации, ориентированный на вывод вашей игры на рынок. Трейси Фуллертон напомнила мне: «Это совершенно разные вещи, для которых существуют две разные временные шкалы: маркетинговые мероприятия начинаются раньше, а согласование технических требований происходит ближе к концу. А уже в самом конце возвращается издатель, который и занимается работой с прессой перед релизом и осуществляет сам релиз». Так что имейте в виду, что вам, вероятно, придется взаимодействовать с двумя разными подразделениями компании платформодержателя: с одним по вопросам разработки, а с другим – по вопросам издания.

Последовательность процесса сертификации

Игровая студия получает список сертификационных требований, когда ее утверждают в качестве разработчика. Чтобы пройти сертификацию с первого раза – или вообще пройти, – команда должна изучать требования на протяжении всей разработки. Чем раньше она начнет это делать, тем лучше. Разработчик должен иметь хорошее общее представление о требованиях с самого начала проекта, начиная с этапа препродакшена. Продакшен – самое время детально изучить сертификационные требования, а стадия альфы – четко их понимать.

Когда разработчик уверен, что релиз-кандидат тщательно протестирован и никакие баги не помешают пройти процесс сертификации, он заполняет некоторые документы и отправляет их владельцу платформы. Затем уже компания владельца платформы запускает тестирование и оценивает, насколько игра соответствует требованиям.

Примерно в то же время, когда игра проходит техническую сертификацию, разработчик вместе с издательским отделом платформы готовит игру к рекламной кампании. Все сроки должны быть тщательно спланированы и учтены в графике выпуска игры, так как от них напрямую зависит начало кампании по привлечению потенциальной аудитории с помощью маркетинга и социальных сетей. Например, только после того как игра прошла сертификацию, можно создавать промокоды для прессы и рецензентов, чтобы создать шумиху вокруг игры.

Прохождение и провал процесса сертификации

Лучший результат – это когда владелец платформы не находит никаких проблем, которые мешают игре пройти сертификацию. Затем игра оценивается как соответствующая требованиям и действительно «уходит на золото». Она затем передается в релиз.

Если владелец платформы находит только одну серьезную проблему (или несколько небольших проблем), игру отклоняют. Тестирование прекратят, а игру исключат из процесса сертификации, отправив обратно разработчику с описанием проблемы. Если разработчик все же захочет выпустить свою игру на выбранной платформе, ему придется устранить неполадки, заново подать заявку и, возможно, заплатить (потенциально очень большую) сумму за то, чтобы его игра снова прошла процесс сертификации. Если в игре несколько серьезных проблем и ее исключают из процесса сертификации при обнаружении первой, у разработчика могут возникнуть проблемы, если он не обнаружит другие проблемы до повторного прохождения проверки.

Разработчики должны сделать все, что в их силах, чтобы пройти сертификацию. Этот процесс требует времени: не менее недели уходит на тщательное тестирование и оценку. А это значит, что если нам придется проходить сертификацию два или три раза, то мы сдвинем предполагаемую дату релиза на месяц – почти что вечность в условиях современного медиапотребления и внимания аудитории.

Обновления игры после сертификации

Разработчикам часто приходится выпускать патчи для игр. Патч – это замена и обновление либо какой-то части билда игры, либо всей игры. Патчи нужны для устранения проблем или обновления игры – например, добавления контента и фичей. Игры, которые работают как сервисы, а не как продукты для одноразовой продажи, должны постоянно исправляться и обновляться.

На большинстве платформ не каждый новый патч должен проходить сертификацию. Обычно существует процесс, отдельный от первого и основного процесса сертификации (но аналогичный ему), после прохождения которого разработчик сможет обновлять свою игру с определенной степенью свободы.

Возрастные рейтинги

В зависимости от того, где выйдет игра, она должна получить возрастной рейтинг. Рейтинг контента указывает на то, что игра подходит для определенных возрастных групп, он выдается рейтинговой комиссией для каждого региона. Если у вас есть физические копии цифровых игр, вы могли видеть рейтинги на коробке: они выдаются такими организациями, как ESRB в Канаде, Мексике и Соединенных Штатах, PEGI в Европе, и многими другими организациями по всему миру[190]. Однако большинство владельцев консольных платформ в настоящее время переходят на процесс классификации видеоигр, предложенный Международной коалицией возрастных рейтингов (IARC), в целях снижения затрат и упрощения оценки контента[191].

ПРИМЕР ТРЕБОВАНИЙ К СЕРТИФИКАЦИИ ВИДЕОИГР

Джесси Виджил, USC Games

1.1 Воспроизводимость на оборудовании потребителя

ТРЕБОВАНИЕ: игра может быть установлена и запущена на любом устройстве, которое соответствует заявленной разработчиком минимальной спецификации и целевой ОС.

ОБЪЯСНЕНИЕ

Игры, которые запускаются только на персональном оборудовании разработчика, не принимаются. Исполняемые файлы, веб-приложения или мобильные пакеты должны устанавливаться на устройствах, указанных издателем (инструкторами), перед отправкой. Должны соответствовать пункту 1.2.

1.2 Сторонние плагины и драйверы

ТРЕБОВАНИЕ: сторонние плагины должны быть интегрированы в исполняемый файл или объявлены издателю до майлстоуна бета-версии.

ОБЪЯСНЕНИЕ

Использование сторонних плагинов (для поддержки контроллера, внешних ссылок и т. д.) разрешено при условии, что для установки и воспроизведения игры на оборудовании потребителя не требуется специального установщика или дополнительных разрешений. Плагины, для которых конечный пользователь должен установить разрешения (включая специальные драйверы оборудования), должны быть одобрены издателем (инструкторами) не позднее этапа бета-тестирования.

1.3 Минимальные требования к фронтенду

ТРЕБОВАНИЕ: все игры должны содержать минимальные функции и контент фронтенда.

ОБЪЯСНЕНИЕ

Минимальные функции и контент фронтенда:

• заставка/логотип вашего издателя или академической программы;

• заставка/логотип компании, учреждения или подразделения, в сотрудничестве с которыми разрабатывалась игра;

• титульный экран/экран меню;

• внутриигровые титры.

(a)

Рис. 34.1. Сертификационные требования, разработанные Джесси Виджилом

1.4 Свободное перемещение по пользовательскому интерфейсу

ТРЕБОВАНИЕ: пользователи могут надлежащим образом перемещаться между экранами/режимами без необходимости перезапуска игры.

ОБЪЯСНЕНИЕ

Если при навигации по меню пользователь включает титры / настройки управления / другие разделы, он должен иметь возможность вернуться к экрану главного меню с помощью внутриигровой навигации. При завершении геймплея игра должна вернуть игрока на экран главного меню. Доступ или повторный доступ к любой опции в игре не должен требовать закрытия и перезапуска приложения.

1.5 Навигация по меню через устройство ввода

ТРЕБОВАНИЕ: устройство ввода, используемое для геймплея, также функционально для навигации по меню.

ОБЪЯСНЕНИЕ

Если геймпад используется / может использоваться в игровом процессе, с его помощью можно перемещаться по меню.

1.6 Все функции отладки удалены к сертификации

ТРЕБОВАНИЕ: любые чит-коды, ссылки или другие функции и инструменты отладки отключены/удалены/недоступны в конечной версии игры.

ОБЪЯСНЕНИЕ

Конечный пользователь не видит отладочные показатели на экране. Чит-команды разработчиков недоступны и не могут быть случайно вызваны конечными пользователями.

2.1 Стандартизированные требования к геймпаду

ТРЕБОВАНИЕ: игра, в которой используется геймпад, должна быть совместима со стандартным геймпадом Windows.

ОБЪЯСНЕНИЕ

Могут поддерживаться и другие геймпады, но игры ДОЛЖНЫ поддерживать стандартный геймпад Windows (контроллер Xbox). Драйверы этого устройства являются частью стандартных драйверов устройств на Windows и не требуют администраторских для установки, что упрощает соблюдение требований 1.1.

(б)

Рис. 34.1. (Продолжение)

Процесс получения возрастного рейтинга происходит отдельно от сертификации, но чем-то на него похож. Игра отправляется в рейтинговую комиссию того региона, где будет выпущена игра, иногда за отдельную плату. (Рейтинговые комиссии, как правило, связаны с правительством и региональной ассоциацией по продаже игр.) Затем игра изучается и ей присваивается рейтинг. Рейтинг может включать как возрастную категорию, так и некоторые описания контента. Если разработчик и/или издатель не согласны с присвоенным рейтингом, они могут внести изменения в игру и повторно отправить ее на оценку либо обжаловать решение комиссии.

Во многих странах возрастные рейтинги необязательны и не каждая игра, выпущенная онлайн, должна получать официальный рейтинг. Тем не менее большинство игр, выпущенных на игровых консолях, должны получить такой рейтинг в соответствии с сертификационными требованиями владельца платформы до того, как они будут переданы на сертификацию. Непросто справиться со всеми проблемами, связанными с различными рейтинговыми системами и процессом сертификации, и здесь издатели игр могут оказать большую помощь разработчикам.

Примеры сертификационных требований

Джесси Виджил – писатель, гейм-дизайнер, режиссер, предприниматель и преподаватель в программе USC Games. Он разработал набор примеров сертификационных требований по образцу тех, которые выдвигаются в игровой индустрии. Наши студенты должны соблюсти эти требования при создании игр на наших занятиях, чтобы ознакомиться с суровостью «ухода на золото» в профессиональной среде.

Сертификационные требования Джесси – ценный материал для каждого разработчика, и я привожу их на рис. 34.1 с его разрешения. Поскольку некоторые из них относятся к стадии беты, они должны быть переданы командам разработчиков не позднее альфа-версии. Джесси и я надеемся, что вы найдете их полезными.

* * *

Поскольку процесс сертификации – это ориентированное на детали занятие, разработчики игр, занимающиеся подготовкой игры к сертификации, должны быть точными и способными с кристальной ясностью сообщать о каждом аспекте процесса. Некоторые команды и издатели нанимают экспертов, а иногда и целые компании, которые хорошо знают требования сертификации и помогли многим играм пройти этот процесс. Прохождение сертификации – это обряд посвящения для каждого разработчика игр, и, хотя оно дается непросто, вы сможете многому обучиться. Удачи!

Но даже после сертификации мы еще не совсем закончили. Обычно в самом конце проекта гейм-дизайнеров подстерегает дополнительная работа. А какая именно – мы рассмотрим в следующей главе.

Глава 35

Неожиданный гейм-дизайн

Творческий путь гейм-дизайнера полон сюрпризов, некоторые из них приятны, например неожиданная синергия между элементами геймплея, а некоторые не очень, например трудно исправимые баги. Мы не перестаем узнавать что-то новое о нашей игре, ее особенностях, игроках и задачах на протяжении всего проекта, в том числе в самом конце. Обычно гейм-дизайнерам приходится выполнять непредвиденную работу как во время постпродакшена, так и после майлстоуна релиз-кандидата, иногда новые обязанности возникают словно из воздуха, требуя к себе внимания. Цель этой главы – предостеречь вас, чтобы вас не застали врасплох появляющиеся уже после окончания проекта неожиданные задачи.

После выхода нашей игры в свет нас могут поджидать совершенно разные задачи в зависимости от того, какую игру мы создали, в каком контексте (коммерческом, художественном, академическом или каком-либо другом), как именно вышла наша игра, а также от размера и характера потенциальной аудитории. Я приведу некоторые общие категории работы, которые вам, возможно, придется выполнить, но вы должны быть внимательны к происходящему вокруг вас. Культурный, коммерческий и медийный фон игр постоянно меняется – и меняется очень быстро. Не позволяйте застать себя врасплох, ради вас самих и ради созданной вами игры.

Виды неожиданного гейм-дизайна

Большая часть работы, которая застает гейм-дизайнеров врасплох, связана с релизом и продвижением игры. Мы хотим, чтобы люди скачивали, покупали или иным образом знакомились с нашей игрой, но для этого потребуются определенные усилия с нашей стороны и со стороны наших сотрудников.

Мы уже обсуждали это в главе 30, и, надеюсь, вы уже наметили план, как можно связаться с людьми, которым будет интересно то, что вы создали. Однако если вы новичок в выпуске и продвижении игр, часть работы, с которой вам придется столкнуться как гейм-дизайнеру и разработчику, может вас озадачить. К такой работе можно отнести следующее.

• Помощь в создании трейлера игры. Возможно, вам потребуется предоставить исходные кадры геймплея и сюжетного контента, а также ключевой арт. Возможно, вам даже придется сделать трейлер самостоятельно. А на создание хорошего трейлера требуется много времени.

• Помощь в получении возрастного рейтинга для игры. Даже когда этим процессом занимается третья сторона, разработчикам все равно приходится делать некоторую подготовительную работу.

• Сборка и тестирование демоверсий. Опубликовать демоверсию иногда ничуть не менее сложно, чем выпустить полноценную игру. Если ваша игра должна пройти сертификацию и получить возрастной рейтинг, возможно, то же самое потребуется и для демоверсии.

• Создание веб-сайта игры. Как и в случае с трейлером, вам, возможно, придется предоставить ресурсы и информацию для веб-сайта или же создать его самостоятельно.

• Медийное представление проекта. Общение с прессой и широкой аудиторией может занять очень много времени. Специалист по рекламе может взять на себя эту работу, но если у вас маленький бюджет и вы не можете нанять профессионала, то вам придется рекламировать игру самостоятельно, общаясь с прессой и инфлюенсерами и организуя публичные мероприятия.

• Управление аккаунтами в социальных сетях. Создание высококачественного контента для социальных сетей на удивление трудоемкое занятие. Вы также должны учитывать время, необходимое для разработки как краткосрочных, так и долгосрочных планов взаимодействия с вашей аудиторией в социальных сетях.

• Интервью с игровой прессой. Если вы привлечете внимание прессы, интервью о вашей игре могут сильно повлиять на прирост аудитории. Эти интервью могут проводиться по электронной почте или в личных сообщениях, или же они могут быть записаны в виде подкаста или видео. Но в любом случае для подготовки к интервью потребуется время.

• Подготовка презентации для прессы. Помимо написания или записи интервью, вам нужно подготовить тезисы, чтобы осветить все важные особенности игры. Вам также нужно подготовить скриншоты, видео и ключевой арт, чтобы их опубликовали вместе с интервью.

• Помощь в создании руководства для игры. Ко многим играм, особенно коммерческим, создаются руководства по стратегии (от англ. strategy guide), которые помогают игрокам разобраться в игре. Они могут либо продаваться в качестве дополнительного контента в печатном или электронном виде, либо бесплатно распространяться в интернете. Для их создания требуются время и немалый вклад как дизайнеров, так и разработчиков игры. Если вы будете сотрудничать с автором руководства, обязательно выделите в своем расписании время для обсуждения всех важных деталей.

• Создание документальных роликов о том, как создавалась игра, и бонусных материалов. Уже более десяти лет в игры добавляют бонусные материалы с историей о том, как разрабатывалась игра, и короткометражные документальные фильмы о создании игр набирают популярность. Вам понадобится время на подготовку и запись интервью с разработчиками, которые расскажут об игре, и еще больше времени на планирование, съемку, монтаж и доработку самих фильмов.

• Показ игры на выставках и проведение пресс-туров. Публичные игровые выставки – важное место для продвижения игр как для инди-разработчиков, так и для крупных компаний. Подготовка к выставке, поездка и сам показ затратны в плане как денег, так и времени, поэтому планируйте все заранее. Если у игры большой бюджет, вы тоже можете поехать в пресс-тур, где будете общаться с журналистами и, возможно, появитесь в СМИ, рассказывая о новой игре.

• Представление игры на фестивале. Много замечательных игровых фестивалей освещают огромное количество самых разнообразных игр. Помимо того, что представлять свою игру на фестивале – это удовольствие и честь, игровое событие еще и поможет вам установить контакт с потенциальной аудиторией и привлечь внимание к игре. Однако вы можете столкнуться с трудностями, подавая заявки на интересующие вас мероприятия, так как для этого надо собрать много материала за небольшой срок, и эта задача может помешать вам готовиться к завершению самой игры.

• Выступление с докладом об игре на конференции. Выступления на конференциях и представленные доклады, будь они в профессиональной среде или в академических кругах, – это скорее способ обменяться полученными знаниями, чем рекламировать игру. Однако, как и в случае с фестивалями, в зависимости от сроков предоставления материала для конференции, вы можете столкнуться с дополнительной работой, когда уже будете уверены, что со всем справились.

Вы можете подумать, что многое из перечисленного не имеет никакого отношения к гейм-дизайну – это больше маркетинг и PR. Строго говоря, так и есть, но, как вы можете судить по описанию возможной работы, очень часто пиарщикам и маркетологам требуется помощь команды разработчиков для участия в рекламе. А в небольшой команде с ограниченным бюджетом эту работу от и до могут выполнять сами разработчики.

В главе 30 я приводил слова Эми Хенниг (с которыми полностью согласен), что опыт игрока начинается с того момента, когда он впервые узнает об игре. Его опыт формируется той информацией и эмоциями, которые он получает из рекламных материалов или прессы. Так что такого рода работа на самом деле тоже аспект гейм-дизайна – часть создаваемого игрой опыта. Сама игра многое выигрывает от тесного сотрудничества увлеченных разработчиков с экспертами в области маркетинга и PR.

В конце вашего проекта вас могут поджидать другие неожиданные задачи. Возможно, у вас появится возможность работать с некоммерческими организациями и оказывать положительное влияние на общество. Или вас позовут выступить перед правительственным собранием. В мире развлечений, искусства и бизнеса возможно все. Если вы будете развивать умения гейм-дизайнера, свою личность, характер и ценности, вы справитесь со всем, что встретится на вашем пути.

* * *

В главе 2 я говорил о «силе списка». Гейм-дизайнеры, которые ведут списки и постоянно их обновляют, обладают своего рода сверхспособностью, и, когда возникает неожиданная задача, эта сверхспособность активируется. Вместо того чтобы тратить десятки часов на сбор вдруг запрошенной информации, вы просто передаете свой список.

Теперь, когда у нас есть релиз-кандидат, мы прошли сертификацию и разобрались с некоторой дополнительной работой, мы почти закончили с процессом производства игр. В следующей главе мы поговорим о том, что нас ждет после конца проекта, когда мы выпустим игру и будем готовы перейти к новым проектам.

Глава 36

После окончания проекта

Иногда, когда игра закончена, разработчики игры могут расслабиться, по крайней мере на некоторое время. В большинстве случаев законченная и уже вышедшая игра сразу же требует от своих создателей дополнительной работы. Бывает и так, что после одной игры сразу начинается разработка новой. В этой главе мы рассмотрим, что мы будем делать после окончания проекта.

Релиз игры

В первые несколько десятилетий профессионального гейм-дизайна было вполне вероятно, что каждый член команды может отдохнуть после релиза игры. Если разработчики завершали игру в кранче – как исторически бывало в большинстве случаев, – семьи могли снова увидеть супругов и родителей за обеденным столом, а отпуск можно было провести с пользой. Для тех, кто провел немало дней в кранче, отдых больше походил на долгий обморок от усталости.

Конечно, игра, которая выходит на всеобщее обозрение, нуждается в большой поддержке. Это верно независимо от того, вышла она на физическом носителе, в виде цифровой версии или лайв-сервиса. В крупных компаниях работа, связанная с выпуском игры, обычно ложится не на плечи ее разработчиков (за исключением неожиданной работы из главы 35) – этим займутся их коллеги по маркетингу, продажам и PR. В маленьких студиях разработчикам придется самим решать эти вопросы.

С появлением загружаемого контента (DLC) как важного способа продлить срок жизни игры на рынке, а также с растущей популярностью игр-сервисов – «игры как сервис»[192] – разработчики все чаще продолжают работать над своей игрой после ее релиза. Представьте, каково это для тех, кто работал в режиме кранча, чтобы выпустить игру. Вот вы ковыляете к финишной черте, измученные и истощенные, но вас опять заставляют бежать – такое состояние чревато серьезными проблемами с физическим и психическим здоровьем. Что еще раз подчеркивает исключительную важность здоровых рабочих привычек на протяжении всего жизненного цикла игры: избегайте кранча, чтобы вы были в состоянии поддерживать вашу игру после ее релиза.

Постпроектный обзор

В первую очередь после окончания проекта стоит провести постпроектный обзор. Обычно он проходит в виде собрания или, что более вероятно, серии встреч, где разработчики обсуждают проект, вынося из него полезные уроки. В небольшой команде в постпроектном обзоре могут принять участие все сотрудники. В более крупной команде на одном из многочисленных собраний право голоса предоставится каждому представителю каждой дисциплины. В ходе обзора будет сделано множество заметок, которые позже объединят в письменный отчет. Обычно для сбора информации и записи новых идей назначается ответственный, который затем представит отчет команде, студии и заинтересованным сторонам.

Эта практика распространена в мире игр и технологий и часто известна как постмортем. Постмортем – популярный жанр выступлений на конференциях разработчиков игр, поэтому поищите и посмотрите постмортемы ваших любимых игр, чтобы узнать больше о том, как они создавались.

Постпроектные обзоры обычно фокусируются на двух аспектах: что прошло хорошо, а что нет. С этой точки зрения можно оценить самые разные стороны игры: механику и повествование, процесс разработки и инструменты, управление проектами, коммуникацию, сотрудничество, разрешение конфликтов и руководство команды… нет предела тому, что мы можем обсудить в постпроектном обзоре, если мы будем оставаться вежливыми, конструктивными и понимающими.

В частности, разработчики ищут способы, как лучше работать в будущем. Возможно, будет полезно применить SWOT-анализ, выявив сильные и слабые стороны, возможности и угрозы в игре или в том, как она была сделана[193]. Это способствует разговору разработчиков о том, в чем они хороши и как они могли бы расширить свои возможности (см. «Репертуар и рост» в главе 7). В командах, где я работал, и на моих занятиях мы всегда заканчиваем каждый проект постпроектным обзором – одним из лучших способов совершенствоваться как гейм-дизайнер и разработчик, анализируя сам процесс создания игры.

Отдых после проекта

Постарайтесь взять тайм-аут между проектами. Некоторые студии предоставляют своим сотрудникам дополнительный отпуск в конце большого проекта, а иногда отдельные сотрудники берут оплачиваемые отгулы. Путешествуйте, проводите время с семьей и друзьями, читайте, смотрите фильмы, играйте в игры, сочиняйте музыку – в общем, делайте все то, что поможет вам зарядиться энергией и восстановиться, чтобы вновь чувствовать творческие порывы.

Некоторые студии или команды в конце проекта изо всех сил стараются вывести свой проект в онлайн или поддержать сервисную игру, из-за чего им недостает времени перевести дух. Возможно, им придется продолжать работать, чтобы прокормить себя и свои семьи. Если вы сможете помочь другим с работой и дать им немного отдохнуть в конце проекта, пожалуйста, не пренебрегайте такой возможностью. Время простоя – такая же часть творческого процесса, как и периоды высокой продуктивности.

Идеи, которые приходят к нам в мечтах наяву и бесцельном брожении, очень ценны. Они могут как просто позабавить нас, так и усилить любовь к нашему делу. Они могут навести нас на размышления, которые в дальнейшем помогут нам вырасти как профессионалам. В них может таиться идея игры, которая впоследствии станет легендарной. Так что узнавайте себя по мере того, как вы набираетесь опыта в разработке игр, и выясняйте, что лучше всего зарядит вас энергией в конце большого проекта.

Постпроектная хандра

Иногда отдохнуть в конце проекта не так-то просто. С началом отпуска некоторых охватывает чувство беспокойства и тревоги или даже опустошенность и депрессия. Внезапно то, что захватывало дух, требовало внимания и творческих усилий, то, что заполняло все наши дни, – просто исчезло. После окончания больших проектов я иногда чувствовал себя как Вайл И. Койот из мультика «Дорожный бегун», который завис в воздухе, только что сбежав с края обрыва, и смотрит сначала через экран на зрителей, а затем вниз, в пропасть.

Постпроектная хандра может отличаться по степени тяжести. Она может протекать легко, а может стать серьезной проблемой для жизни. С этим может столкнуться кто угодно, но чаще всего она связана с кранчем. Когда чья-то жизнь полностью поглощена работой и весь смысл и эмоциональная связь в жизни человека проистекают из нее, вместе с проектом заканчивается и этот смысл. Кранч и постпроектная хандра могут даже перетекать в разного рода зависимости, поскольку человек может изо всех сил пытаться заполнить пустоту, созданную неудовлетворенными эмоциональными потребностями, нездоровыми способами.

Я не специалист в области ментального здоровья. Если вы сталкиваетесь с такими проблемами, я надеюсь, вы идете за помощью к профессионалам. У меня не раз был замечательный опыт работы с психотерапевтами, и я всегда был рад, что обратился за помощью. Я признаю, что психотерапия больше доступна привилегированному и богатому населению, может быть и так, что психотерапия вовсе недоступна там, где вы живете. В качестве относительно недорогой замены психотерапии вы можете обратиться к групповой терапии и группам поддержки. Я был членом такой терапевтической группы более десяти лет, что оказало огромное положительное влияние на мою жизнь и самочувствие.

Если у вас постпроектная хандра, сообщите об этом другу. Мы часто стыдимся своей борьбы с психическими проблемами, но то, что мы прячем в темноте, только усугубляется и растет. Выносите свои переживания на свет дружбы и сострадания, и вам будет легче с ними разобраться.

Я надеюсь, что если мы будем придерживаться здоровых привычек на протяжении всего проекта, насколько нам это позволяет процесс разработки игр, то в конце мы будем относительно свежими и станем менее подвержены постпроектной хандре. Обратите внимание на собственное эмоциональное самочувствие в конце проекта и сделайте все необходимое, чтобы не запускать свои проблемы.

Следующий проект

Как только мы немного отдохнем и будем готовы приступить к новой игре, придет время перейти к следующему проекту. Один из способов сделать это – просто открыть первые страницы этой книги и снова начать наш процесс разработки игр с этапа идеации, подключив такие техники, как полет мысли, исследование и прототипирование.

Во многих командах, особенно крупных, работа набирает динамику, когда мы приступаем к следующему проекту. Стоит помнить, что различные дисциплины выходят из проекта поэтапно. А значит, что некоторые люди – потенциально очень многие – будут готовы начать работу над следующим проектом раньше, чем руководство команды. Это затишье между проектами может вызвать затруднения, поскольку те, кто готов продолжать, вполне разумно и естественно захотят получить какое-то направление для следующей игры до того, как гейм-директоры, продюсеры, руководители и дизайнеры вернутся из отпуска. Когда команда остается без руководства, могут появиться проблемы, но мы можем превратить потенциально плохую ситуацию в хорошую.

Исследования и разработки

Во время моего пребывания в Naughty Dog перерыв между проектами конструктивно отводился на исследования и разработки (R&D). Членам команды предлагалось провести некоторую самостоятельную работу, которая помогла бы им подготовиться к следующему проекту.

Команда могла оценить новый коммерчески доступный инструмент, который, по ее мнению, был бы полезен в следующем проекте. Или она могла поработать над созданием собственного инструмента или улучшением пайплайна. (Пайплайн – инструменты и процессы для создания частей игры, передачи их между другими отделами и инструментами для дальнейшей работы и интеграции в воспроизводимый билд.)

На этапе исследований и разработок члены команды могут создать прототип фичи или какого-либо контента, чтобы исследовать безумную, творческую, экспериментальную идею. Некоторые могут записаться на учебные программы, чтобы улучшить свои навыки в определенной области, или проводить время за исследованиями, читая специальную литературу и просматривая видео. Сотрудники могут исследовать все что угодно, от новых игровых технологий до новых подходов к арту, анимации и звуковому дизайну. Они могут изучать передовую теорию и практику как в гейм-дизайне, так и в дисциплинах, связанных с управлением проектами и развитием командной культуры.

Каждая студия должна думать об этапе исследований и разработки как о чем-то само собой разумеющемся, чтобы избежать застоя и поддерживать стремление команды изучать новое, а затишье между проектами – естественное для этого время. Для проведения исследований и разработки может потребоваться некоторое участие со стороны руководства команды, но сами члены команды могут вполне успешно заниматься этим самостоятельно. В конце концов, мастера знают свои инструменты и свое дело лучше, чем кто-либо, и они смогут найти способы их улучшить.

Выбор дирекшена

На плечи гейм-директора (или директоров) следующего проекта ложится важная задача определить с командой направление, в котором будет развиваться игра. У большинства гейм-директоров нескончаемый список проектных идей; то, что они хотят сделать или попробовать, что, по их мнению, будет жизнеспособным с художественной или коммерческой точки зрения и что, по их мнению, понравится их команде.

Лучше всего, когда гейм-директор задает направление как можно раньше, пускай оно еще размыто. Оно может быть похоже на очень ранний набросок целей проекта, который мы обсуждали в главе 7 – возможно, всего несколько предложений о типе опыта или практических ограничениях, с которыми столкнется проект (скажем, жанр игры или аппаратная платформа).

Отсутствие какого-либо направления вообще может привести к тому, что команда будет чувствовать себя потерянной и демотивированной. Даже приблизительное направление вдохнет в команду силы, и люди захотят внести вклад в развитие идеи. В самом начале проекта порой чем меньше направление, тем лучше, поскольку это даст людям большую свободу в исследовании. Боевой дух команды будет на высоте, если вы дадите им понять, что заботитесь о них и цените их работу, а чтобы это сделать, достаточно их направить. Давая первые указания, гейм-директора также должны объяснить, что хотят услышать идеи всех остальных. На этапе идеации крайне важно узнать мнение всех членов команды.

Работа гейм-директора – быть стратегом и планировать заранее, так что не пренебрегайте этим в своей команде. Начните думать о следующем проекте самое позднее на этапе альфа-версии предыдущего проекта и будьте готовы дать новому проекту направление для хорошего старта.

Когда лучше покинуть команду

Делать хорошие игры невероятно сложно, и большое значение здесь имеет командная культура: методы работы, общие знания и общие ценности команды. Командная культура – вещь хрупкая, она процветает и сохраняется только тогда, когда ее развивают медленно и целенаправленно с течением времени. Внезапные уходы и приходы отдельных членов команды могут привести к большим изменениям в командной культуре, что, в свою очередь, оказывает влияние на игру.

В частности, если кто-то покидает команду до завершения проекта, ситуация становится донельзя сложной. Если кто-то хочет покинуть команду, я считаю, что подходящее время для этого – в конце проекта, когда игра уже завершена, но не раньше. Жизнь такая, какая она есть, не всегда возможно заранее спланировать свой уход, но делайте все, что в ваших силах, чтобы довести до конца проекты, которые вы на себя взяли. Игровая индустрия – на удивление маленькое место, и лучше иметь репутацию человека, который доводит свои дела до конца.

Тем не менее вы не должны мириться с рабочей средой, в которой процветает абьюз, токсичность и злоба. Как бы я ни ценил готовность доводить проекты до конца, еще больше я ценю право человека оставить неблагоприятную для себя атмосферу. Я понимаю, что это привилегия – иметь возможность уволиться с работы и каждый человек должен справляться с токсичной рабочей средой так, как это подходит именно ему. Каждый должен стремиться создать рабочую атмосферу, свободную от токсичности и абьюза, и те, кто занимает руководящие посты, несут за это особую ответственность.

Вернемся к началу

Подобно мифическому уроборосу, кусающему себя за хвост, конец и начало игровых проектов тесно связаны. Однажды я слышал, как гейм-дизайнер Эрик Циммерман сказал, что наряду с отдельными играми, которые мы создаем, существует более масштабный проект, над которым мы работаем всю жизнь. Этот проект представляет собой всю нашу практику гейм-дизайна. Он начинается, когда мы создаем нашу первую игру, и заканчивается с последним игроком в последней, созданной нами игре.

Я считаю, что мне невероятно повезло, что я стал гейм-дизайнером. Гейм-дизайн – это бесконечно благодарное занятие, и он течет, как река самой жизни. Каждый наш опыт и каждые отношения, все, чему мы учимся, и все, что нам нравится, могут стать частью дизайна наших игр. Вернитесь к началу отдохнувшими и воодушевленными. Сосредоточьтесь на уважении, доверии и согласии. Следуйте своим интересам, совершенствуйте свое мастерство, и со временем вы поймете, как создавать превосходные игры в своем уникальном, здоровом и эффективном стиле.

Эпилог

Дизайн и разработка игр приносят огромное удовольствие. Мой друг и коллега Питер Бринсон, художник и гейм-дизайнер, даже проводит параллели между тем, как игры делают, и тем, как в них играют. На своих занятиях в USC он указывает, что, создавая игры, мы осваиваем новые навыки и используем их для решения проблем, точно так же как мы это делаем в игре. По мере того как мы продвигаемся вперед, проблемы становятся все сложнее, и нам приходится приобретать еще больше навыков. Мы приходим в состояние потока, где растущая сложность поставленной задачи компенсируется нашим растущим мастерством, и мы ныряем в этот поток полностью вовлеченные, исполненные интереса к процессу, с возросшей концентрацией и искаженным чувством времени, как это описывает Чиксентмихайи[194].

Но это означает, что создание игр – очень тяжелая работа. Необходимо принимать бесчисленное множество решений, имеющих далеко идущие последствия. И поскольку мы находимся в состоянии потока, мы довольно зависимы от того, что делаем. У нас есть склонность терять счет времени и блуждать в дебрях, рискуя вкладывать свои усилия в несущественные вещи как под действием гипноза. Если мы будем продолжать работать в том же духе и без всякого контроля, то в конце концов неизбежно выгорим. Создаваемая игра пострадает от этого с точки зрения качества, даты релиза, да и в других отношениях тоже. У нас не будет сил на еще одну игру после окончания этой, а наша практика гейм-дизайна станет словарным определением недолговечности.

Несмотря на то что творчество непредсказуемо, из-за чего нашу работу так сложно планировать, мы можем взять наш труд под контроль, приняв структурированный процесс, подобный тому, который описан в этой книге, – или любой его вариант, который подходит именно вам. Этот процесс должен помочь управлять ограниченным временем и ресурсами, которыми мы располагаем, не создавая при этом жесткие рамки и бюрократию. Тогда мы сможем взять масштаб нашего проекта под контроль, оставаясь при этом достаточно гибкими, чтобы совершать открытия в той области, в которой развиваемся.

Стоит воспитывать в себе гибкий подход и относиться к переменам как к возможности, а не проблеме[195]. Игра откроется вам по мере того, как вы будете ее создавать. Отбросьте свое эго, прислушайтесь к самому проекту и тому, как он хочет развиваться, и следуйте за ним. В этом красота творчества, и именно это делает разработку уникальным путешествием, в котором мы сможем узнать что-то новое о дизайнерском процессе.

Мы обладаем невероятной гибкостью формировать и совершенствовать дизайн наших игр на протяжении всего процесса производства и даже во время постпродакшена. В интервью 2013 года кинорежиссер Ава Дюверней сказала: «В монтажной я могу полностью переделать историю. Сценарий – это действительно руководство, и с его помощью я собираю все эти сцены и слова, но после того как я это сделаю, я могу превратить историю во все, что захочу»[196]. Ава может формировать сюжет фильма и его смысл прямо до самого конца творческого процесса. Такая пластичность цифровых медиа и исследовательский характер нашего ремесла верны и для игр, возможно, в еще большей степени.

Но мы должны научиться брать на себя ответственность. Раньше я часто боролся с прокрастинацией. Я из тех, кто больше думает, а значит, в прошлом я слишком много додумывал, когда пытался смотреть на вещи не просто с обеих сторон, но со всех сторон. Вдумчивость ценна, но она также может сдерживать нас, мешая нам принимать решения и приступать к действию.

В конце концов я научился распознавать тот момент, когда я достаточно о чем-то думал, и теперь пришло время действовать. Этот урок нелегко усвоить: некоторые из нас больше думают, некоторые – больше действуют, но большинство из нас находится где-то посередине, пытаясь понять, достаточно ли мы все обдумали, чтобы наконец сделать первый шаг. Так или иначе, вы научитесь понимать, когда пришло время принимать решения.

* * *

Если вам понравилось то, что вы прочитали в этой книге, подумайте о том, чтобы стать продюсером игр. Ниже приведен список некоторых книг, которые помогут вам побольше узнать о разработке игр, от самых новых до самых старых.

• Клинтон Кит, Agile Game Development: Build, Play, Repeat, 2‑е изд.

• Клинтон Кит и Грант Шонквилер, Creative Agility Tools: 100+ Tools for Creative Innovation and Teamwork.

• Хетер Максуэлл Чандлер, The Game Production Toolbox.

• Джон Хайт и Джинни Новак, Game Development Essentials: Game Project Management.

• Дэн Айриш, The Game Producer’s Handbook.

Игровая индустрия всегда выиграет от людей, которые понимают творческий процесс, помогают его организовывать, ответственно относятся ко времени и деньгам и умеют общаться с широким кругом лиц. Робин Ханике однажды сказала мне, что для нее роль продюсера заключается в том, чтобы помогать другим людям в команде выполнять свою работу настолько хорошо, насколько это возможно. Мы слишком часто испытываем искушение думать о продюсерах как о начальстве, а не как о посредниках и помощниках. Продюсеры должны быть умными и знающими: они должны понимать, что происходит в команде и с игрой с точки зрения как общей картины, так и мелких деталей. Они также должны обладать эмоциональным интеллектом и здравыми ценностями, чтобы уметь налаживать общение и справляться с трудными ситуациями по мере их возникновения.

Продюсер всегда должен смотреть в будущее и планировать, но также должен находить способы работать с командой так, чтобы каждый был услышан и сам слышал других. Продюсер должен оставаться оптимистичным и позитивным, чтобы помочь команде сплотиться в трудные времена. И что главное, хороший продюсер создает такую рабочую среду для своих коллег и сотрудников, в которой команда будет расти и постоянно совершенствовать свою командную культуру, в конечном счете создавая все лучшие и лучшие игры.

* * *

В последние несколько лет дизайнеры и художники всех мастей начали осознавать возможности и обязательства своей работы. Применение принципов дизайна для социальных изменений называется социальным дизайном и очень важно для гейм-дизайнеров, работающих над социальными играми, обучающими играми и играми для здоровья.

Тем не менее я считаю, что социальный дизайн актуален для каждой игровой команды. Как мы уже однажды обсуждали в этой книге, несмотря на серьезные улучшения в игровой индустрии, она все еще борется с проблемой кранча. Проектирование гейм-продакшена само по себе является процессом разработки игр на метауровне и заслуживает от нас такого же внимания, как механики и сюжеты игр. Мы должны очень пристально и внимательно относиться к социальному дизайну разработки игр, чтобы убедиться, что мы поддерживаем, а не причиняем вред сотрудникам в наших командах, а также людям, которые играют в наши игры.

Мы должны работать над улучшением процесса создания игр, чтобы он приветствовал и поддерживал всех людей из всех слоев общества. В своей книге «Дизайн как отношение» дизайн-критик New York Times Элис Росторн рассказывает об исторических проблемах, связанных с отсутствием равноправия в графическом дизайне, типографии и архитектуре. Она говорит: «Если вы верите, что дизайн играет важную роль в организации нашей жизни и в определении объектов, образов, технологий и пространств, которые ее заполняют, само собой разумеется, что нам нужны дизайнеры самого высокого уровня. Но мы этого добьемся, только если они будут приходить из всех слоев общества»[197].

Меня радует тот факт, что все больше людей в игровом сообществе по всему миру верят, что этническое и гендерное разнообразие в играх – которое действительно может исходить только от разнообразия в сообществах разработчиков игр – укрепляет сами игры, привнося в них новые идеи гейм-дизайна, новые подходы и аудиторию. Мы должны сделать сообщества наших игр и команд доступными и гостеприимными для всех.

В конечном счете уважение, доверие и согласие – главные источники хорошей разработки. Эти три элемента формируют основу любой коммуникации, сотрудничества, лидерства и сопутствуют разрешению конфликтов. Конечно, нам нужны навыки в гейм-дизайне и разработке. Но без уважения, доверия и согласия между дизайнером и игроком, а также между членами команды все наши навыки и способности, скорее всего, сойдут на нет. Чтобы этого избежать, мы должны придерживаться справедливой и равноправной командной культуры, в которой ко всем относятся одинаково, независимо от их личности или происхождения. Если мы это сделаем, то создадим условия для более квалифицированного, более инновационного и принципиально лучшего сообщества разработчиков игр.

Мы стоим в авангарде культуры с новой и яркой формой искусства – видеоиграми. У нас есть невероятная возможность показать всем художникам и дизайнерам, которые сталкиваются с трудностями и неконтролируемым переутомлением, что создавать искусство – это не всегда сложное и истощающее занятие.

Нет единственно правильного способа создавать игры. Есть только методики и инструменты, некоторые из которых лучше подходят для нас и нашей игры. Лучший способ научиться создавать игры – это создавать их, продолжать этим заниматься и в итоге становиться лучше. Эта книга дает вам отправную точку, как лучше подходить к процессу разработки игр, который, по моим наблюдениям, отлично работает в академическом гейм-дизайне и игровой индустрии для проектов всех видов. Пожалуйста, возьмите этот процесс на вооружение и следуйте за ним, куда бы он вас ни привел, а затем расскажите о вашем опыте.

Приложение А. Четыре этапа, майлстоуны и результаты производственного процесса игр

Приложение Б. Перевод текста с рис. 7.1

Что такое Uncharted: Drake’s Fortune?

1. Это остросюжетная и динамичная игра.

Мы никогда не замедляем действие, погружаясь в чрезмерно сложные головоломки или громоздкие механики… мы всегда стараемся держать быстрый и веселый темп.

2. Uncharted не воспринимает себя слишком серьезно.

Мы сочетаем элементы саспенса, тайны и драмы, но не забываем о веселом тоне «криминального экшена». Случайная шутка или забавная ситуация, чтобы снять напряжение, – вот что делает Uncharted уникальным.

3. Дрейк может ошибаться, как любой другой человек.

Дрейк – не Джеймс Бонд. Он никогда не контролирует ситуацию полностью, всегда пытается одержать верх, импровизируя или используя любые средства, имеющиеся в его распоряжении. Он не получает сверхсилы и не становится суперменом, но он всегда действует на пределе своих возможностей.

4. Мы исследуем затерянные и таинственные места.

Мы хотим, чтобы большая часть приключений была сосредоточена на изучении «неизведанных» мест, затерянных во времени. Дрейк в некотором роде детектив, пытающийся собрать все воедино.

5. В нашем мире есть правдоподобные сверхъестественные элементы.

В игре встречаются таинственные и, казалось бы, сверхъестественные элементы, но Дрейк всегда должен иметь возможность отнестись к этому со скепсисом. По сверхъественности Uncharted больше похожа на «Секретные материалы» или «28 дней спустя», чем на «Мумию» или «Охотников за привидениями».

6. Необычные события в привычной обстановке.

Все, от истории до окружения, должно создавать ощущение некой реальной исторической и визуальной правдоподобности. Как только этот фундамент правдоподобия будет прочно заложен, многослойный элемент «фантастического» окажет гораздо большее влияние.

Приложение В. Таблица макродизайна (детальная) для Uncharted 2: Among Thieves с рис. 18.2

(а)

(б)

Рис. В.1. Права на изображение: © 2009 SIRE LLC/ UNCHARTED 2: Among Thieves™. Создано и разработано компанией Naughty Dog LLC.

Благодарности

Моя неизмеримая любовь и искренняя благодарность моим родителям, Вин и Дереку, а также моему брату Джереми. Особая благодарность и любовь Нове Цзян, которая всегда вдохновляла и поддерживала меня. Огромная любовь Лиз, Ширан и Мии, Саре и ее семье, Росу, Питеру, Филу, Хелен, Полу и их детям, тете Шейле, Дункану, Терезе, Майклу и Эмме, а также дяде Дэвиду.

Я хочу выразить особую благодарность новатору в гейм-дизайне и педагогу Трейси Фуллертон, чья вдохновляющая работа изменила мир и мою жизнь. Трейси, твоя щедрая и обстоятельная помощь с этой книгой была незаменима, и я выражаю тебе свою глубочайшую благодарность. Дружба с тобой вдохновляет.

Искренняя благодарность несравненному Марку Черни, чье внимательное чтение и конструктивная критика сыграли решающую роль в доведении этого проекта до завершения, как и многих других. Марк, спасибо тебе за утверждение тех ценностей, что изложены в этой книге, и за то, что нашел время мне помочь. Ты всегда был для меня путеводной звездой.

Большое спасибо Эвану Уэллсу за его помощь с книгой и за то, что он предоставил мне столько замечательных возможностей. Фантастическая благодарность и любовь Эми Хенниг, которая взяла меня в увлекательнейшее путешествие по гейм-дизайну и сторителлингу, которое увенчалось самой бесценной наградой – нашей дружбой.

С глубоким восхищением благодарю Мэри Маккой, чья эрудиция вдохновляет и возвышает, а авторские советы – поддерживают. Особая благодарность Дэну Таршишу за прогулки и беседы, которые помогли придать книге форму. Огромная благодарность моим экспертам и идеальным читателям: Алану Дангу, Игану Хирвела, Джеффу Уотсону, Оуэну Харрису и Тимоти Ли. Огромная благодарность Мэтти Розен, чье неожиданное предложение помочь сильно повлияло на завершение книги. Большое спасибо всем, чей вклад и поддержка помогли в создании этой книги: Адаму Сульздорфу-Лишкевичу, Деннису Виксону, Элизабет Блайт, Гордону Кальеха, Джеку Эппсу и Джереми Гибсону Бонду. Спасибо Лорен Ходош за юридическую помощь, а также Максу и Нику Фолкманам, чей подкаст Script Lock вдохновлял меня на новые идеи. Я очень благодарен старшему редактору MIT Press Дагу Сери за его руководство и доверие, которое он оказал мне, редактору MIT Press Ною Дж. Спрингеру, чьи экспертные советы держали меня в курсе событий, а также моим анонимным рецензентам за их ценный вклад. Особая благодарность моему производственному редактору Хелен Уилер и моему превосходному редактору Лунее Уэзерстоун за их усердную работу и мудрые советы.

Большое спасибо всем, кто вдохновлял меня и помогал с книгой: Анико Имре, Анне Антропи, Аурии Харви, Бо Рубергу, Каре Эллисон, Чаду Топраку, Колину Маклину, Эрику Циммерману, Фрэнку Ланцу, Джеффри Лонгу, Гранту Шонквилеру, Ирвингу Белатеху, Джесперу Джуулу, Джону Шарпу, Крису Лигману, Мэри Фланаган, Мэри Суини, Майклу Джону, Мигелю Сикарту, Наоми Кларк, Натали Поцци, Рафу Костеру, Сэму Гослингу, Саманте Калман, Шэрон Грин, Стиву Гейнору, Таре Макферсон, Тобиасу Копка, Уильяму Хуберу и всем (невозможно всех перечислить, так их много), кто давал мне советы и подбадривал меня, когда я писал. Спасибо всем, кто еще не был упомянут и кто внес свой вклад в текст и рисунки: Габриэле Пурри Р. Гомес, Джорджу Кокорису, Джесси Виджилу, Джиму Хантли и Марку Вильгельму. Спасибо тем, кто дал мне разрешение использовать изображения, связанные с их работой: Аарону Чейни, Чао Чену, Кристофу Розенталю, Джорджу Ли, Дженни Цзяо Ся, Джулиану Сейпеку и Майкл Барклаю. Особая благодарность в этом деле Арне Мейер, Брайану Пардилле и Sony Interactive Entertainment.

Я в большом долгу перед всеми, с кем я работал в MicroProse, Crystal Dynamics, Naughty Dog и в Лаборатории игровых инноваций USC. Я так многому научился у всех вас, и мы замечательно провели время, вместе создавая игры. Мне не хватит места, чтобы поблагодарить вас всех по отдельности, но наше сотрудничество принесло мне огромное счастье и помогло понять те идеи, которые изложены в этой книге. Я особенно хотел бы поблагодарить Робин Ханике, Хирокадзу Ясухару, Селию Пирс, Сэма Робертса, Хизер Келли, Конни Бут, Энди Гэвина, Грейди Ханта, Сэма Томпсона, Эндрю Беннетта, Розауру Сандовал, Пола Райхе III, Джона Спинэйла, Стюарта Уайта, Энди Хайка и Пита Морленда за наставничество и дружбу, которые вы подарили мне на этом пути.

Огромное спасибо всем моим коллегам по программе USC Games, бывшим и нынешним, у которых я так многому научился и на чью поддержку я мог положиться. Особая благодарность Питеру Бринсону, который научил меня преподавать; Дэнни Билсону, чья страсть и великодушие вдохновляют меня; Марци Кампос, которая перезагрузила мою творческую практику; Джереми Гибсону Бонду и Маргарет Мозер, которые научили меня программировать и многому другому, Энди Нилену за то, что он открыл мне глаза на минимализм и системную динамику; Джейн Пинкард, чей пример заставляет меня всегда стремиться к лучшему; и Андреасу Кратки, Гордону Беллами, Кики Бензону, Лэрду Маламеду и Мариентине Гоцис за их мудрость и дружбу. Большое спасибо декану Элизабет М. Дейли, Акире Мидзуте Липпиту, Майклу Ренове и всем моим коллегам из Школы кинематографических искусств USC за то, что так тепло меня приняли. Особая благодарность всем моим ученикам как в программе USC Games, так и за ее пределами за всю их тяжелую работу, креативность и хорошее настроение. И главная благодарность моим выпускникам из групп CTIN‑532 и CTIN‑484/489, для которых изначально были написаны главы этой книги и которые дали мне дельные замечания. Учить вас было и остается удовольствием – спасибо вам за все то, чему я сам смог у вас научиться.

Большое уважение и искренняя благодарность Сэмми Ся Лин, вице-президенту компании Interactive Entertainment Group и декану Tencent Game Institute, а также Эрику Ма, президенту отдела кадров Tencent Games. Наше сотрудничество привело к крепким дружеским отношениям и помогло укрепить идеи, изложенные в этой книге. Спасибо Ли Мин, Ли Шен, Нео Лю, Кэти Ван, Элейн Ван, Инь Ву и всем, с кем мы работали на семинарах Tencent USC Games.

Я хочу выразить глубокую благодарность сообществам конференций, фестивалей и саммитов, в которых мне посчастливилось принимать участие, особенно сообществам Game Developers Conference и IndieCade. Большое спасибо моим друзьям в HEVGA, в Каледонском университете Глазго и в необъятном, удивительном мире академического гейм-дизайна. Благодарность всем моим учителям, прошлым и нынешним, которые сделали все возможное, чтобы мой мир продолжал наполняться новыми идеями. Глубокая и искренняя любовь всем друзьям, которых я приобрел в мире игр, искусства и преподавания, а также моим самым старым друзьям из Ньюента и Оксфорда. Вы поддерживали меня в самые трудные времена и были рядом в радостные мгновения. С глубокой благодарностью и уважением к работе Октавии Э. Батлер.

В память о миссис Кейт Кларк, которая научила меня думать; Майке Брантоне, который дал мне старт; моих бабушке и дедушке, заядлых игроках Дорин и Холден (в бридж и шахматы соответственно), и моей бабушке Джойс, которая подарила мне мое сердце; а также моем друге и коллеге докторе Джеффе Уотсоне, который вдохновлял всех вокруг на глубокие размышления и всегда был добрым. Отзывы и поддержка Джеффа были неоценимы при написании этой книги.

Библиография

Adams, Ernest. Fundamentals of Game Design. 3rd ed. Voices That Matter. Berkeley: New Riders, 2013.

Allgeier, Brian. Directing Video Games: 101 Tips for Creative Leaders. Los Angeles: Illusion Road, 2017.

Anthropy, Anna. Rise of the Videogame Zinesters: How Freaks, Normals, Amateurs, Artists, Dreamers, Dropouts, Queers, Housewives, and People like You Are Taking Back an Art Form. New York: Seven Stories, 2012.

Anthropy, Anna, and Naomi Clark. A Game Design Vocabulary: Exploring the Foundational Principles behind Good Game Design. Upper Saddle River, NJ: Addison-Wesley, 2014.

Block, Bruce. The Visual Story: Creating the Visual Structure of Film, TV and Digital Media. 3rd ed. London: Routledge, 2020.

Bogost, Ian. Play Anything: The Pleasure of Limits, the Uses of Boredom, and the Secret of Games. New York: Basic Books, 2016.

Brathwaite, Brenda, and Ian Schreiber. Challenges for Game Designers. Boston: Course Technology/Cengage Learning, 2009.

Brotchie, Alastair, and Mel Gooding, eds. A Book of Surrealist Games: Including the Little Surrealist Dictionary. Boston: Shambhala Redstone, 1995.

Chandler, Heather Maxwell. The Game Production Toolbox. Boca Raton, FL: CRC Press, 2020.

Childs, Peter. Modernism. 2nd ed. London: Routledge, 2008.

Culyba, Sabrina. The Transformational Framework: A Process Tool for the Development of Transformational Games. Pittsburgh: ETC Press: Signature, 2018.

Dreskin, Joel. A Practical Guide to Indie Game Marketing. Boca Raton, FL: Routledge, 2017.

Epps, Jack, Jr. Screenwriting Is Rewriting: The Art and Craft of Professional Revision. New York: Bloomsbury, 2016.

Frederick, Matthew. 101 Things I Learned in Architecture School. Cambridge, MA: MIT Press, 2007.

Freytag, Gustav. Freytag’s Technique of the Drama: An Exposition of Dramatic Composition and Art – Scholar’s Choice Edition. Sacramento, CA: Creative Media Partners, 2015.

Fuller, R. Buckminster, and E. J. Applewhite. Synergetics: Explorations in the Geometry of Thinking. New York: Macmillan, 1975.

Fullerton, Tracy. Game Design Workshop: A Playcentric Approach to Creating Innovative Games. 2nd ed. Boston: Elsevier Morgan Kaufmann, 2008.

Fullerton, Tracy. Game Design Workshop: A Playcentric Approach to Creating Innovative Games. 4th ed. Boca Raton, FL: Taylor & Francis, CRC Press, 2018.

Gulino, Paul Joseph. Screenwriting: The Sequence Approach. New York: Continuum, 2004.

Hight, John, and Jeannie Novak. Game Development Essentials: Game Project Management. Clifton Park, NY: Thomson Delmar Learning, 2008.

Hunicke, Robin, Marc LeBlanc, and Robert Zubek. «MDA: A Formal Approach to Game Design and Game Research». AAAI Workshop – Technical Report 1 (January 1, 2004).

IDEO Product Development, ed. IDEO Method Cards: 51 Ways to Inspire Design: Learn, Look, Ask, Try. San Francisco: William Stout, 2003.

Irish, Dan. The Game Producer’s Handbook. Boston: Thomson Course Technology, 2005.

Juul, Jesper. The Art of Failure: An Essay on the Pain of Playing Video Games. Cambridge, MA: MIT Press, 2016.

Keith, Clinton. Agile Game Development: Build, Play, Repeat. 2nd ed. Hoboken, NJ: Pearson Education, 2020.

Keith, Clinton, and Grant Shonkwiler. Creative Agility Tools: 100+ Tools for Creative Innovation and Teamwork. Clinton Keith, 2018.

Luhn, Matthew. The Best Story Wins: How to Leverage Hollywood Storytelling in Business and Beyond. New York: Morgan James, 2018.

Meadows, Donella H., and Diana Wright. Thinking in Systems: A Primer. White River Junction, VT: Chelsea Green, 2008.

Phillips, Melanie Anne, and Chris Huntley. Dramatica: A New Theory of Story. Glendale, CA: Screenplay Systems, 2004.

Scannell, Mary. The Big Book of Conflict Resolution Games: Quick, Effective Activities to Improve Communication, Trust, and Collaboration. New York: McGraw-Hill, 2010.

Sellers, Michael. Advanced Game Design: A Systems Approach. Boston: Addison-Wesley, 2017.

Swink, Steve. Game Feel: A Game Designer’s Guide to Virtual Sensation. Burlington, MA: Morgan Kaufmann/Elsevier, 2008.

Totten, Christopher W. An Architectural Approach to Level Design. 2nd ed. Boca Raton, FL: Taylor & Francis, CRC Press, 2019.

Tufte, Edward R. Envisioning Information. Cheshire, CT: Graphics Press, 2013.

Wohl, Michael. Editing Techniques with Final Cut Pro. Berkeley, CA: Peachpit Press, 2002.

Yorke, John. Into the Woods: A Five-Act Journey into Story. New York: Abrams, 2015.

Zackariasson, Peter, and Mikolaj Dymek. Video Game Marketing: A Student Textbook. London: Routledge, 2016.

Аристотель. Поэтика.

Бонд, Дж. Unity и C#. Геймдев от идеи до реализации. М.: Питер, 2022.

Воглер, К. Путешествие писателя. Мифологические структуры в литературе и кино. М.: Альпина нон-фикшн, 2015.

Гибсон, Дж. Экологический подход к зрительному восприятию. М.: RUGRAM, 2015 г.

Карс, Дж. Конечные и бесконечные игры. М.: Рипол-Классик, 2015.

Кэмпбелл, Дж. Тысячеликий герой. М.: Питер, 2018.

Кэтмелл, Уоллес. Корпорация гениев. Как управлять командой творческих людей. М.: Альпина Паблишер, 2015.

Ле Гуин, У. Парус для писателя от Урсулы Ле Гуин. Как управлять историей: от композиции до грамматики на примерах известных произведений. М.: Манн, Иванов и Фербер, 2022.

Луптон, Э. Драматургия дизайна. Как, используя приемы сторителлинга, удивлять графикой, продуктами, услугами. М.: Бомбора, 2022.

Норман, Д. Дизайн привычных вещей. М.: Манн, Иванов и Фербер, 2021.

Роджерс, С. Level up! Руководство по созданию классных видеоигр. М.: Бомбора, 2023.

Ростон, Э. Дизайн как отношение. М.: Музей современного искусства «Гараж», 2021.

Снайдер, Б. Спасите котика! Все, что нужно знать о сценарии. М.: Бомбора, 2022.

Толкин, Дж. Письма. М.: АСТ, 2022.

Чиксентмихайи, М. Поток. Психология оптимального переживания. М.: Альпина нон-фикшн, 2015.

Хейзинга, Й. Homo ludens. Человек играющий. СПб.: Азбука, 2022.

Шелл, Дж. Геймдизайн. Как создать игру, в которую будут играть все. М.: Альпина Паблишер, 2019.

Упомянутые игры

Apex Legends. Respawn Entertainment. Electronic Arts, 2019.

Bastion. Supergiant Games. Warner Bros. Interactive Entertainment, 2011.

The Binding of Isaac: Rebirth. Edmund McMillen and Nicalis. Nicalis, 2014.

Cities: Skylines. Colossal Order. Paradox Interactive, 2015.

Cloud. USC Game Innovation Lab. 2005.

Control. Remedy Entertainment. 505 Games, 2019.

Crash Bandicoot. Naughty Dog. Sony Interactive Entertainment, 1996.

Crash Bandicoot 2: Cortex Strikes Back. Naughty Dog. Sony Interactive Entertainment, 1997.

Dance Dance Revolution. Konami, 1998.

Dear Esther. The Chinese Room and Robert Briscoe. 2012.

Earth: A Primer. Chaim Gingold, Cliff Caruthers, Michelle M. Lee, Laura Kaltman, and Pete Demoreuille. 2015.

Flow. thatgamecompany. Sony Interactive Entertainment, 2006.

Flower. thatgamecompany. Sony Interactive Entertainment, 2009.

FTL: Faster Than Light. Subset Games, 2012.

Gex. Crystal Dynamics. BMG Interactive, 1995.

God of War. SIE Santa Monica Studio. Sony Interactive Entertainment, 2018.

Halo: Combat Evolved. Bungie. Microsoft Game Studios, 2001.

Jak 3. Naughty Dog. Sony Interactive Entertainment, 2004.

Jak and Daxter. Naughty Dog. Sony Interactive Entertainment, 2001.

Jak X: Combat Racing. Naughty Dog. Sony Interactive Entertainment, 2005.

Journey. thatgamecompany. Sony Interactive Entertainment, 2012.

Keef the Thief: A Boy and His Lockpick. Naughty Dog. Electronic Arts, 1989.

The Last of Us. Naughty Dog. Sony Interactive Entertainment, 2013.

Legacy of Kain: Soul Reaver. Crystal Dynamics. Eidos Interactive, 1999.

The Legend of Zelda: A Link to the Past. Nintendo, 1991.

Marble Madness. Mark Cerny and Atari Games. Atari Games, 1984.

Minecraft. Mojang Studios, 2009.

The Night Journey. Bill Viola, Tracy Fullerton, Todd Furmanski, Kurosh ValaNejad, and USC Game Innovation Lab. USC Games, 2018.

Painstation. Tilman Reiff and Volker Morawe, 2001.

Pandemonium! Toys for Bob. Crystal Dynamics, 1996.

Pong. Allan Alcorn. Atari, 1972.

Proteus. Twisted Tree Games and David Kanaga. 2013.

Ratchet & Clank Future: A Crack in Time. Insomniac Games. Sony Interactive Entertainment, 2009.

Rings of Power. Naughty Dog. Electronic Arts, 1991.

Scribblenauts. 5th Cell. Warner Bros. Interactive Entertainment, 2009.

The Secret of Monkey Island. Lucasfilm Games, 1990.

SimCity. Maxis, 1989.

The Sims. Maxis. Electronic Arts, 2000.

Sonic the Hedgehog 2. Sega Technical Institute. Sega, 1992.

Spelunky. Mossmouth, LLC, 2012.

Spider-Man.

Insomniac Games. Sony Interactive Entertainment, 2018.

Spore. Maxis. Electronic Arts, 2008.

StarCraft. Blizzard Entertainment, 1998.

Sunset Overdrive. Insomniac Games. Xbox Game Studios, 2014.

Super Mario Bros. Nintendo EAD. Nintendo, 1985.

Tetris. Alexey Pajitnov and Vadim Gerasimov. Electronika 60, 1984.

Tharsis. Choice Provisions, 2016.

Tinhead. MicroProse UK. Ballistic, 1993.

Uncharted: Drake’s Fortune. Naughty Dog. Sony Interactive Entertainment, 2007.

Uncharted 2: Among Thieves. Naughty Dog. Sony Interactive Entertainment, 2009.

Uncharted 3: Drake’s Deception. Naughty Dog. Sony Interactive Entertainment, 2011.

Walden, a game. Tracy Fullerton and USC Game Innovation Lab. USC Games, 2017.

The Witcher 3: Wild Hunt. CD Projekt Red. CD Projekt, 2015.

Примечания

1

Трейси Фуллертон, Game Design Workshop, 4 изд., с. 12. – Прим. авт.

2

От англ. blue sky thinking – вид брейншторма, при котором нет ограничений. – Прим. ред.

3

Трейси Фуллертон, Game Design Workshop, 4 изд., с. 12. – Прим. авт.

4

Частная беседа 25 мая 2020 г. – Прим. авт.

5

Трейси Фуллертон, Game Design Workshop, 4 изд., с. 179. – Прим. авт.

6

Подбор случайных статей на «Википедии»: https://en.wikipedia.org/wiki/Wikipedia: Random. – Прим. авт.

7

Дон Сэндлер, How to Avoid Surgical Errors («Как избежать хирургических ошибок»), OR Today, 1 июня 2016 г. https://ortoday.com/how-to-avoid-surgical-errors. – Прим. авт.

8

«Эффект Кулешова», статья «Википедии». https://ru.wikipedia.org/wiki/Эффект_Кулешова. – Прим. авт.

9

Трейси Фуллертон, Game Design Workshop, 4 изд., с. 16. – Прим. авт.

10

Техники IDEO Method Cards. – Прим. авт.

11

Джефф Уотсон и Стюарт Кэнди, игра The Thing from The Future, 2017 г., Situation Lab. http://situationlab.org/project/the-thing-from-the-future. – Прим. авт.

12

Мэри Флэнаган и Хелен Ниссенбаум, обзор игры Grow-A-Game. https://www.valuesatplay.org/grow-a-game-overview. – Прим. авт.

13

Том Вуйец, «Построишь башню – создашь команду», 2010 г. https://www.youtube.com/watch?v=H0_yKBitO8M. – Прим. авт.

14

Специальный термин в скалолазании. Означает прыжок с выступа на выступ. – Прим. ред.

15

Психотипы игроков по Бартлу, «Википедия». https://en.wikipedia.org/wiki/Bartle_taxonomy_of_player_types. – Прим. пер.

16

Хаим Гингольд, Catastrophic Prototyping and Other Stories, 20 января 2011 г. http://www.levitylab.com/blog/2011/01/catastrophic-prototyping-and-other-stories. – Прим. авт.

17

Игра Killer Queen на фестивале IndieCade в 2012 г. https://www.youtube.com/watch?v=9y3OI3KCdYk. – Прим. авт.

18

Лиз Райерсон, Problem Attic, 2013 г. https://lizryerson.itch.io/problem-attic. – Прим. авт.

19

Например, для людей с ограниченными возможностями. – Прим. ред.

20

Дэниел Острофф, The Details Are Not the Details, Eames Office, 8 сентября 2014 г. – Прим. авт.

21

«Список игровых движков», «Википедия». https://en.wikipedia.org/wiki/List_of_game_engines. – Прим. авт.

22

Гейм-дизайнеры, работающие в сфере LBE-развлечений (англ. location based entertainment – развлечения, основанные на местоположении, такие как игровые клубы и развлекательные центры), могут воздействовать и на обоняние играющих. Но существует гораздо больше сенсорных модальностей, чем пять чувств: зрение, слух, вкус, обоняние и осязание. Проприоцепция, наше ощущение того, где находится наше тело по отношению к самому себе, – важный фактор для дизайнеров виртуальной реальности. У людей есть около двадцати других чувств, которые разработчики игр могут использовать в своих проектах. Мы вернемся к чувствам в главе 7. Для дополнительной информации обратитесь к статье «Википедии». https://ru.wikipedia.org/wiki/Ощущение. – Прим. авт.

23

Стив Суинк, Game Feel, с. 159. – Прим. авт.

24

Стив Суинк, Game Feel, с. 160. – Прим. авт.

25

Рэнди Том, статья Designing a Movie for Sound, FilmSound.org, 1999 г. http://filmsound.org/articles/designing_for_sound.htm. – Прим. авт.

26

Стив Суинк, Game Feel, с. 161. – Прим. авт.

27

Кристофер Рул, THE ORIGINAL Scary ‘Mary Poppins’ Recut Trailer, 2006 г. https://www.youtube.com/watch?v=2T5_0AGdFic. – Прим. авт.

28

Остин Уинтори, конференция GDC Microtalks 2014: One Hour, Ten Speakers, a Panoply of Game Thinking! https://www.gdcvault.com/play/1020391/GDC – Microtalks‑2014-One-Hour. 31:45. – Прим. авт.

29

Комитет Международной ассоциации разработчиков игр, Crediting Standards Guide Ver 9.2 [EN/JP] [2014], IGDA.org, 15 августа 2014 г. https://igda.org/resources-archive/crediting-standards-guide-ver‑9–2‑en-jp‑2014. – Прим. авт.

30

Айра Гласс и Дэниел Сакс, THE GAP by Ira Glass, 2014 г. https://vimeo.com/ 85040589. – Прим. авт.

31

Частная беседа, 31 мая 2020 года. – Прим. авт.

32

Уолтер Марч, интервью Wohl, Editing Techniques with Final Cut Pro, с. 524. – Прим. авт.

33

Уоллес Кэтмелл. Корпорация гениев. Как управлять командой творческих людей. М.: Альпина Паблишер, 2015 г. – Прим. ред.

34

Трейси Фуллертон, Game Design Workshop, 2 изд., с. 10. – Прим. авт.

35

Трейси Фуллертон, Game Design Workshop, 4 изд., с. 252. – Прим. авт.

36

Статья «Википедии». https://ru.wikipedia.org/wiki/Опытное_знание. – Прим. авт.

37

Речь идет об играх про Соника и Марио. – Прим. ред.

38

Йохан Хейзинга. Homo ludens. Человек играющий. СПб.: Азбука, 2022 г.; Джеймс Карс. Конечные и бесконечные игры. М.: Рипол-Классик, 2015 г. – Прим. ред.

39

Гэри Пенн, конференция GDC Microtalks 2010: Ten Speakers, 200 Slides, Limitless Ideas! https://www.gdcvault.com/play/1012271/GDC-Microtalks‑2010-Ten-Speakers. 17:01. – Прим. авт.

40

Мэтью Фредерик, 101 Things I Learned in Architecture School, с. 81. – Прим. авт.

41

Марк Черни, «Саммит конференции D.I.C.E. 2002». https://www.youtube.com/watch?v=QOAW9ioWAvE. – Прим. авт.

42

Кен Швабер, «Манифест гибкой разработки программного обеспечения», 2001 г. https://agilemanifesto.org. – Прим. авт.

43

Марк Черни, «Саммит конференции D.I.C.E. 2002», 3:40. – Прим. авт.

44

Марк Черни, «Саммит конференции D.I.C.E. 2002», 6:26. – Прим. авт.

45

Людвиг Китцманн, Half-Minute Halo: An Interview with Jaime Griesemer («30 секунд Halo: интервью с Джейми Гриземером»), Engadget, 14 июля 2011 г. https://www.engadget.com/2011/07/14/half-minute-halo-an-interview-with-jaime-griesemer. – Прим. авт.

46

Сайд-скроллер (от англ. side-scroller) – термин для обозначения локации с видом сбоку или сверху, которая автоматически «прокручивается» с движением персонажа. – Прим. ред.

47

Итай Керен, Scroll Back: The Theory and Practice of Cameras in Side-Scrollers, Gamasutra, 11 мая 2015 г. https://www.gamedeveloper.com/design/scroll-back-the-theory-and-practice-of-cameras-in-side-scrollers. – Прим. авт.

48

Агентивность, агентность, субъектность – способность человека выступать в качестве самостоятельного агента/субъекта и делать осознанный и свободный выбор. – Прим. ред.

49

Стив Суинк, Game Feel, с. 50. – Прим. авт.

50

Физические реакции при соприкосновении с персонажем или другими объектами, например столкновение со стеной или накладывание эффектов и модификаторов скорости при пересечении глади воды. – Прим. ред.

51

Майкл Барклай, What’s Up Level Designers, Twitter, 1 октября 2017 г. https:// twitter.com/MotleyGrue/status/914571356888371201. – Прим. авт.

52

Скотт Роджерс. Level up! Руководство по созданию классных видеоигр. М.: Бомбора, 2023 г. – Прим. авт.

53

Эмилия Шатц, Defining Environment Language for Video Games, платформа 80 Level, 27 июня 2017 г. https://80.lv/articles/defining-environment-language-for-video-games. – Прим. авт.

54

Разработчики игр и другие творческие люди часто говорят о продаже (shipping) и «продовом качестве» (shippable). Первое означает выход продукта на коммерческий рынок и берет корни из времен, когда физические носители с игрой буквально необходимо было доставлять в другие страны. Сейчас этот термин применим и к выходу игры в цифровом магазине. Второе же означает, что продукт уже не зазорно показать целевой аудитории. – Прим. авт. и ред.

55

В современном продакшене должности и распределение работы могут отличаться. – Прим. ред.

56

Статья «Википедии». https://ru.wikipedia.org/wiki/Красный_угол. – Прим. авт.

57

Марк Черни, «Саммит конференции D.I.C.E. 2002», 7:21. – Прим. авт.

58

Частная беседа, 25 мая 2020 года. – Прим. авт.

59

Джон Пакетт и Мел Маккубри, Script Lock, эпизод 46, 18 февраля 2019 г. https://scriptlock.simplecast.com/episodes/ep‑46‑jon-paquette-mel-maccoubrey. – Прим. авт.

60

Марк Черни, «Саммит конференции D.I.C.E. 2002», 3:40. – Прим. авт.

61

Марк Черни, «Саммит конференции D.I.C.E. 2002», 5:23. – Прим. авт.

62

Таня Шорт, How and When to Make Your Procedurality Player-Legible, Game UX Summit 2018. https://www.youtube.com/watch?v=r6rTMGFXktI. – Прим. авт.

63

Дональд Норман. Дизайн привычных вещей. М.: Манн, Иванов и Фербер, 2021 г. – Прим. ред.

64

Дональд Норман, «Дизайн привычных вещей», с. 32. – Прим. авт.

65

Дональд Норман, «Дизайн привычных вещей», с. 32. – Прим. авт.

66

Стив Суинк, Game Feel, с. 50. – Прим. авт.

67

Дональд Норман, «Дизайн привычных вещей», с. 32. – Прим. авт.

68

Джеймс Гибсон. Экологический подход к зрительному восприятию. М.: RUGRAM, 2015 г. – Прим. ред.

69

Дональд Норман, «Дизайн привычных вещей». – Прим. авт.

70

В общем случае речь идет о наличии насилия и эротики или о том, что может вызвать приступ эпилепсии. – Прим. ред.

71

Сейчас Game Developer. – Прим. ред.

72

Алисса Макалун, 5 Questions You Should Be Asking Playtesters to Get Meaningful Feedback («Пять вопросов плейтестерам, благодаря которым вы получите содержательный отзыв»), Gamasutra, 10 октября 2016 г. https://www.gamedeveloper.com/design/5‑questions-you-should-be-asking-playtesters-to-get-meaningful-feedback. – Прим. авт.

73

Частная беседа, 10 мая 2020 года. – Прим. авт.

74

Мэтью Фредерик, 101 Things I Learned in Architecture School, с. 81. – Прим. авт.

75

Томас Боз и Дейв Баггероер, Design Thinking Bootcamp Bootleg. https://dschool.stanford.edu/resources/the-bootcamp-bootleg. – Прим. авт.

76

Элис Росторн. Дизайн как отношение. М.: Музей современного искусства «Гараж», 2021 г. – Прим. ред.

77

Элис Росторн, Design as an Attitude, с. 123. – Прим. авт.

78

Герберт Саймон, The Sciences of the Artificial, перефразировано Донеллой Медоуз в книге Thinking in Systems: A Primer и Ричардом Лемаршаном. Медоуз и Райт, Thinking in Systems, с. 83. – Прим. авт.

79

The Wizard’s Wisdom: Woodenisms (Мудрость волшебника: Вуденизмы), ESPN, 4 июня 2010 г. https://www.espn.com/mens-college-basketball/news/story?id=5249709. – Прим. авт.

80

Дэниел Острофф, The Details Are Not the Details, Eames Office, 8 сентября 2014 г. – Прим. авт.

81

Майкл Селлерс, Advanced Game Design, с. 42. – Прим. авт.

82

Майкл Селлерс, Advanced Game Design, с. 43, цитата Фуллер и Эплтон Synergetics. – Прим. авт.

83

Частная беседа. – Прим. авт.

84

Частная беседа. – Прим. авт.

85

Эд Кэтмелл и Эми Уоллес, «Корпорация гениев», с. 97. – Прим. авт.

86

Статья «Википедии». https://ru.wikipedia.org/wiki/RAD_(программирование). – Прим. авт.

87

Статья «Википедии». https://ru.wikipedia.org/wiki/Гибкая_методология_разработки. – Прим. авт.

88

Кен Швабер, «Манифест гибкой разработки программного обеспечения», 2001 г. https://agilemanifesto.org. – Прим. авт.

89

Частная беседа. – Прим. авт.

90

В русскоязычной разработке его часто называют кей-арт или ки-арт (от англ. key art). – Прим. ред.

91

Боб Салливан, Memo to Work Martyrs: Long Hours Make You Less Productive, CNBC, 26 января 2015 г. https://www.cnbc.com/2015/01/26/working-more-than‑50‑hours-makes-you-less-productive.html. – Прим. авт.

92

Сара Грин Кармайкл, «Почему перегрузка вредит и сотрудникам, и компаниям» (The Research Is Clear: Long Hours Backfire for People and for Companies), Harvard Business Review, 19 августа 2015 г. https://hbr-russia.ru/management/upravlenie-personalom/p16382/. – Прим. авт.

93

Ирвинг Белатех, лекция «Анализ сценария фильма “Назад в будущее”», John Wells Division of Writing for Screen & Television, Школа кинематографических искусств USC, Лос-Анджелес, 11 июня 2018 г. – Прим. авт.

94

Аристотель, «Поэтика», с. 26. – Прим. авт.

95

Эллен Луптон. Драматургия дизайна. Как, используя приемы сторителлинга, удивлять графикой, продуктами, услугами. М.: Бомбора, 2022 г., с. 21. – Прим. ред.

96

Пол Джозеф Гулино, Screenwriting: The Sequence Approach, с. 2. – Прим. авт.

97

Частная беседа, 25 мая 2020 года. – Прим. авт.

98

Мелани Энн Филлипс и Крис Хантли, Dramatica. – Прим. авт.

99

Урсула Ле Гуин. Парус для писателя от Урсулы Ле Гуин. Как управлять историей: от композиции до грамматики на примерах известных произведений. М.: Манн, Иванов и Фербер, 2022 г. – Прим. ред.

100

Джозеф Кэмпбелл. Тысячеликий герой. М.: Питер, 2018. – Прим. ред.

101

Кристофер Воглер. Путешествие писателя. Мифологические структуры в литературе и кино. М.: Альпина нон-фикшн, 2015. – Прим. ред.

102

Блейк Снайдер. Спасите котика! Все, что нужно знать о сценарии. М.: Бомбора, 2022 г. – Прим. ред.

103

Ингрид Сандберг, What Is Arch Plot and Classic Design?, 5 июня 2013 г. https://ingridsnotes.wordpress.com/2013/06/05/what-is-arch-plot-and-classic-design/#:~:text=Arch%20plot%20is%20a%20goal,(inner%2C%20personal%2C%20extra%2D. – Прим. авт.

104

Конь в форме лошади может казаться нам очевидным, но в английском языке эта фигура называется knight — «рыцарь», «всадник». – Прим. ред.

105

Джон Толкин. Письма. М.: АСТ, 2022 г. – Прим. авт.

106

Марк Черни, «Саммит конференции D.I.C.E. 2002», 28:51. – Прим. авт.

107

Марк Черни, «Саммит конференции D.I.C.E. 2002», 28:58. – Прим. авт.

108

Тед Прайс, Postmortem: Insomniac Games’ Ratchet & Clank, Gamasutra, 13 июня 2003 г. https://www.gamedeveloper.com/disciplines/postmortem-insomniac-games-i-ratchet-clank-i-. – Прим. авт.

109

Марк Черни, «Саммит конференции D.I.C.E. 2002», 31:54. – Прим. авт.

110

Марк Черни, «Саммит конференции D.I.C.E. 2002», 31:54. – Прим. авт.

111

Обычно этот термин используется для определения событийных границ музыкальных композиций. – Прим. ред.

112

Михай Чиксентмихайи. Поток. Психология оптимального переживания. М.: Альпина нон-фикшн, 2015 г., с. 67. – Прим. ред.

113

Анна Антропи и Наоми Кларк, A Game Design Vocabulary, с. 5. – Прим. авт.

114

Мэттью Лун, The Best Story Wins. – Прим. авт.

115

Джесси Шелл. Геймдизайн. Как создать игру, в которую будут играть все. М.: Альпина Паблишер, 2019 г. – Прим. ред.

116

Брайан Альгайер, Directing Video Games, #33. – Прим. авт.

117

Брайан Альгайер, Provide Structure: How Macro Documents Keep a Project on Course, блог Directing Video Games, 10 августа 2017 г. http://www.directingvideogames.com/2017/08/01/provide-structure. – Прим. авт.

118

Марк Черни, «Саммит конференции D.I.C.E. 2002», 32:53. – Прим. авт.

119

Фичекрип (от англ. feature creep) – термин, используемый для обозначения чрезмерного количества фичей в программном обеспечении. – Прим. ред.

120

Марк Черни, «Саммит конференции D.I.C.E. 2002», 35:55. – Прим. авт.

121

In medias res – термин традиционной поэтики, обозначающий начало действия или повествования с центрального эпизода фабулы (его завязки или даже одной из перипетий) без предварения его экспозицией и предысторией. https://ru.wikipedia.org/wiki/In_medias_res. – Прим. авт.

122

Джин Родденберри, Star Trek: The Next Generation Writers’/Directors’ Guide, 8 сентября 1987 г. https://www.roddenberry.com/media/vault/TNG-WritersDirectorsGuide.pdf. – Прим. авт.

123

Брайан Альгайер, Provide Structure: How Macro Documents Keep a Project on Course, блог Directing Video Games, 10 августа 2017 г. http://www.directingvideogames.com/2017/08/01/provide-structure. – Прим. авт.

124

Анна Антропи и Наоми Кларк, A Game Design Vocabulary, с. 17. – Прим. авт.

125

Эрнест Адамс, Fundamentals of Game Design, с. 424. – Прим. авт.

126

Марк Черни, «Саммит конференции D.I.C.E. 2002», 33:47. – Прим. авт.

127

Частная беседа, 25 мая 2020 года. – Прим. авт.

128

Брюс Блок, The Visual Story, с. 234. – Прим. авт.

129

Марк Черни, «Саммит конференции D.I.C.E. 2002», 34:55. – Прим. авт.

130

Сара Грин Кармайкл, «Почему перегрузка вредит и сотрудникам, и компаниям» (The Research Is Clear: Long Hours Backfire for People and for Companies), Harvard Business Review, 19 августа 2015 г. https://hbr-russia.ru/management/upravlenie-personalom/p16382/. – Прим. авт.

131

What Is a Burndown Chart? («Что такое график выгорания?»), Agile Alliance. https://www.agilealliance.org/glossary/burndown-chart/. – Прим. авт.

132

Джереми Гибсон Бонд. Unity и C#. Геймдев от идеи до реализации. М.: Питер, 2022 г., с. 227. – Прим. ред.

133

Мередит Холл, Choosing a Project Management Tool for Game Development, Gamasutra, 29 июня 2018 г. https://www.gamedeveloper.com/business/choosing-a-project-management-tool-for-game-development. – Прим. авт.

134

Top 7 Open Source Project Management Tools for Agile Teams, Opensource.com, 13 января 2020 г. https://opensource.com/article/18/2/agile-project-management-tools. – Прим. авт.

135

Эд Кэтмелл и Эми Уоллес, «Корпорация гениев», с. 86. – Прим. авт.

136

Эд Кэтмелл и Эми Уоллес, «Корпорация гениев», с. 70. – Прим. авт.

137

Эд Кэтмелл и Эми Уоллес, «Корпорация гениев», с. 93. – Прим. авт.

138

Эд Кэтмелл и Эми Уоллес, «Корпорация гениев», с. 86. – Прим. авт.

139

Эд Кэтмелл и Эми Уоллес, «Корпорация гениев», с. 103. – Прим. авт.

140

Эд Кэтмелл и Эми Уоллес, «Корпорация гениев», с. 103. – Прим. авт.

141

Марк Черни, «Саммит конференции D.I.C.E. 2002», 6:26. – Прим. авт.

142

Марк Черни, «Саммит конференции D.I.C.E. 2002», 26:48. – Прим. авт.

143

Стендап (от англ. stand-up meeting) – изначально так называли собрание, которое участники проводят стоя. Долго стоять становится неудобно, и это как бы гарантирует, что встреча не затянется. Сейчас стендапами называют короткие встречи, как правило, ежедневные или еженедельные, где каждый участник кратко рассказывает о сделанном за предыдущий период (день или неделю) и планах на следующий. Стоять на таких встречах уже давно необязательно. – Прим. ред.

144

Стив Суинк, Game Feel, с. 10. – Прим. авт.

145

Шалин Шодан, Мэтт Кьюсик, Кайл Грей, Кайл Гэблер, How to Prototype a Game in under 7 Days, Gamasutra, 26 октября 2005 г. https://www.gamedeveloper.com/disciplines/how-to-prototype-a-game-in-under‑7‑days. – Прим. авт.

146

Мартин Джонассон и Петри Пурхо, Juice It or Lose It, GDC Vault, 2012 г. https://www.gdcvault.com/play/1016487/Juice-It-or-Lose. – Прим. авт.

147

Таня Шорт, How and When to Make Your Procedurality Player-Legible, Game UX Summit 2018. https://www.youtube.com/watch?v=r6rTMGFXktI. – Прим. авт.

148

В итоге появилось свободное прицеливание с легкой опциональной доводкой. – Прим. ред.

149

The Spelunky Showlike, Episode 8: Designing Tharsis with Zach Gage («Эпизод 8: Создание Tharsis с Заком Гейджем»), 20 декабря 2018 г. https://thespelunkyshowlike.libsyn.com/08‑designing-tharsis-with-zach-gage. – Прим. авт.

150

Райан Смит, выступление на GDC Microtalks 2019, 28 октября 2019 г. – Прим. авт.

151

Статья «Википедии». https://ru.wikipedia.org/wiki/Юзабилити. – Прим. авт.

152

Клайв Томпсон, Halo 3: How Microsoft Labs Invented a New Science of Play, Wired, 21 августа 2007 г. https://www.wired.com/2007/08/ff-halo‑2. – Прим. авт.

153

Трейси Фуллертон, Game Design Workshop, 4 изд., с. 191. – Прим. авт.

154

Смоук-тесты и тесты для проверки билда – это разные проверки, первое подразумевает каскадную проверку всего подряд, в то время как второе проводится, как правило, по чек-листу. – Прим. ред.

155

Алисса Макалун, 5 Questions You Should Be Asking Playtesters to Get Meaningful Feedback, Gamasutra, 10 октября 2016 г. https://www.gamedeveloper.com/design/5‑questions-you-should-be-asking-playtesters-to-get-meaningful-feedback. – Прим. авт.

156

Насилие, курение, эротика, мат и т. д. – Прим. ред.

157

Статья «Википедии». https://en.wikipedia.org/wiki/Implicit_stereotype. – Прим. авт.

158

Статья «Википедии». https://ru.wikipedia.org/wiki/Эффект_социальной_желательности. – Прим. авт.

159

Статья «Википедии». https://en.wikipedia.org/wiki/Rensis_Likert. – Прим. авт.

160

Мун Лум, Is UX Design a Separate Practice from Game Design?, блог Prototypr.io, 23 августа 2019 г. – Прим. авт.

161

Статья «Википедии». https://ru.wikipedia.org/wiki/Телеметрия. – Прим. авт.

162

Not Everything That Counts Can Be Counted («Не все, что можно сосчитать, считается»), Quote Investigator, 26 мая 2010 г. https://quoteinvestigator.com/2010/05/26/everything-counts-einstein. – Прим. авт.

163

Эшли Дэвис и Адам Сингл, Testing for Game Development, Gamasutra, 26 июля 2016 г. https://www.gamedeveloper.com/programming/testing-for-game-development. – Прим. авт.

164

Эту ошибку часто называют критом, или критической ошибкой. – Прим. ред.

165

Бывают процессы, в которых блокер – это максимальный приоритет, а класс ниже уже назван критической ошибкой. – Прим. ред.

166

Этот раздел может также называться «проблемный класс/ассет». – Прим. ред.

167

Мередит Холл, Choosing a Project Management Tool for Game Development, Gamasutra, 29 июня 2018 г. https://www.gamedeveloper.com/business/choosing-a-project-management-tool-for-game-development. – Прим. авт.

168

https://ru.wikipedia.org/wiki/Википедия: Заготовка_статьи. – Прим. авт.

169

Лиз Инглэнд, The Door Problem, 21 апреля 2014 г. http://www.lizengland.com/blog/2014/04/the-door-problem. – Прим. авт.

170

В таких случаях сейчас чаще используют термин «коллизия» или «клиппинг». – Прим. ред.

171

Питер Закариассон и Миколай Дымек, Video Game Marketing, с. 35. – Прим. авт.

172

Питер Закариассон и Миколай Дымек, Video Game Marketing, с. 37. – Прим. авт.

173

Джоэл Дрескин, A Practical Guide to Indie Game Marketing, с. 37. – Прим. авт.

174

Рами Исмаил, Presskit(). https://dopresskit.com/. – Прим. авт.

175

Джоэл Дрескин, A Practical Guide to Indie Game Marketing, с. 75. – Прим. авт.

176

Отличие «пасхалки» в игре от обычного игрового секрета состоит в том, что ее содержание, как правило, не вписывается в общую концепцию, может выглядеть в контексте неправдоподобно, нелепо и зачастую является внешней отсылкой. – Прим. ред.

177

Трейси Фуллертон, Game Design Workshop, 4 изд., с. 311. – Прим. авт.

178

Или, по крайней мере, как осознанно заложенный разработчиками секрет. – Прим. ред.

179

Сейчас подобные проблемы чаще называют не тупиком, а софтлоком, что означает блокер прохождения, которого технически можно избежать. – Прим. ред.

180

В первую очередь сэйв-скамминг подразумевает создание неразумного количества сохранений и их использование при любых возникающих сложностях. – Прим. ред.

181

«Roguelike (на сленге “рогалик”) – жанр компьютерных игр. Характерными особенностями классического roguelike являются генерируемые случайным образом уровни, пошаговость и необратимость смерти персонажа – в случае его гибели игрок не может загрузить игру и должен начать ее заново». Статья «Википедии». https://ru.wikipedia.org/wiki/Roguelike. – Прим. авт.

182

Сейчас кат-сцены гораздо чаще делают не видеороликами, а инструментами движка, и рендерят их в реальном времени. – Прим. ред.

183

«Цветокоррекция – это процесс улучшения изображения… Улучшаются такие характеристики изображения, как контрастность, цвет, насыщенность, детализация, уровень черного и баланс белого», статья «Википедии». https://en.wikipedia.org/wiki/Color_grading. – Прим. авт.

184

Окончательный монтаж фильма в английском языке также называется термином picture lock. – Прим. пер.

185

Аурия Харви и Микаэль Самин, The Beautiful Art Program, Tale of Tales, 20 августа 2013 г. http://tale-of-tales.com/tales/BAP.html. – Прим. авт.

186

Бренда Ромеро и Ян Шрайбер, Challenges for Game Designers, с. 35. – Прим. авт.

187

Ян Шрайбер, Level 1: Intro to Game Balance («Уровень 1: Введение в игровой баланс»), Game Balance Concepts, 7 июля 2010 г. https://gamebalanceconcepts.wordpress.com/2010/07/07/level‑1‑intro-to-game-balance/. – Прим. авт.

188

Джесси Шелл, «Геймдизайн», с. 211. – Прим. авт.

189

Статья «Википедии». https://ru.wikipedia.org/wiki/CD-R. – Прим. ред.

190

Статья «Википедии». https://en.wikipedia.org/wiki/Video_game_content_rating_system. – Прим. авт.

191

Статья «Википедии». https://en.wikipedia.org/wiki/International_Age_Rating_Coalition. – Прим. авт.

192

Также их называют GaaS-игры (от англ. games-as-service). – Прим. ред.

193

Статья «Википедии». https://ru.wikipedia.org/wiki/SWOT-анализ. – Прим. авт.

194

Михай Чиксентмихайи, «Поток», с. 4. – Прим. авт.

195

Статья «Википедии». https://ru.wikipedia.org/wiki/Гибкая_методология_разработки. – Прим. авт.

196

Эмма Кармайкл, ‘I Have Stories I Want to Tell’: A Conversation with Filmmaker Ava DuVernay («Мне есть что рассказать: Беседа с режиссером Авой Дюверней»), The Hairpin, 2 июля 2013 г. https://www.thehairpin.com/2013/07/i-have-stories-i-want-to-tell-a-conversation-with-filmmaker-ava-duvernay. – Прим. авт.

197

Элис Росторн, «Дизайн как отношение», с. 68. – Прим. авт.

Content

Ричард Лемаршан
Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение

Предисловие

Вступление

Первый этап: формирование идей – идеация

Глава 1 Как начать

Глава 2 Полет мысли

Мозговой штурм

Автоматизм

Другие техники полета мысли

Дизайнеры, электронные таблицы и сила списка

Глава 3 Исследование

Исследования в интернете

Поиск изображений

Не пренебрегайте библиотекой

Экскурсии

Интервью

Теневой повтор

Исследовательские заметки

Глава 4 Прототипирование игры: обзор

Игровая механика, глаголы и игровые активности

Три вида прототипирования

Каждый разработчик игр тоже гейм-дизайнер

Глава 5 Создание цифрового прототипа

Выбор игрового движка

Выбор операционной системы и аппаратной платформы

Создайте прототип как игрушку, а не как игру

Важность звукового сопровождения в цифровом прототипе

Плейтесты и итерирование цифрового прототипа

Сколько нужно сделать цифровых прототипов

Следовать ли за тем, куда ведет прототип

Результаты идеации: создание прототипа

Синдром завышенных ожиданий

Эмоциональная составляющая плейтестов прототипов

Глава 6 Коммуникация как навык гейм-дизайна

Коммуникация, сотрудничество, лидерство и конфликты

Базовые коммуникативные навыки

Техника сэндвича

Уважение, доверие и согласие

Глава 7 Цели проекта

Целевой опыт пользователя

Записывайте, какой опыт вы хотите видеть в вашей игре

Целевой опыт и цели дизайна образуют цели проекта

Репертуар и рост

Учитывайте возможную аудиторию вашей игры

Разработка для специализированной игровой платформы

Советы, как сформировать цели проекта

Глава 8 Конец этапа идеации

Как долго должен длиться этап идеации

Несколько заключительных советов по созданию прототипов

Краткое изложение артефактов этапа идеации

Второй этап: препродакшен – разработка дизайна через действия

Глава 9 Взятие контроля над процессом

Конвейер и водопад

Создание чего-то нового

Планирование на этапе препродакшена

Марк Черни и Метод

Ценность этапа препродакшена

Глава 10 Что такое вертикальный срез

Кор луп, или основной игровой цикл

Три C

Тестовые уровни и блокмеш

Размер и качество уровней в вертикальном срезе

Бьюти-корнер

Сложности и польза вертикального среза

Глава 11 Создание вертикального среза

Работайте с прототипами

Покажите эпизод из начала игры – но не самое начало

Итерируйте основные элементы вашей игры

Определитесь с игровым движком и аппаратной платформой

Наводите и поддерживайте порядок в проекте

Начните добавлять функции отладки

Ошибайтесь рано, ошибайтесь быстро, ошибайтесь часто

Работайте в одном физическом пространстве или вместе по сети

Сохраняйте и классифицируйте ваши дизайн-материалы

Руководствуйтесь целями проекта

Когда следует изменить цели вашего проекта

Что мы делаем, создавая вертикальный срез

Препродакшен нельзя запланировать обычным образом

Таймбоксинг

Глава 12 Проведение плейтестов

Модель дизайнера, образ системы и модель пользователя

Аффордансы и сигнифаеры

Тестирование читаемости и игрового опыта

Лучшие практики плейтестов

Проведение регулярных плейтестов

Оценка обратной связи

«Мне понравилось, мне бы хотелось, что, если?..»

Тестирование игр для дизайнеров и художников

Глава 13 Концентрическая разработка

Почему Вселенная организована иерархически – притча

Что такое концентрическая разработка

Сначала доведите до конца основные механики игры

Внедрение второстепенных и третьестепенных механик

Концентрическая разработка и параметры дизайна

Тестовые уровни

Полируйте игру по ходу разработки

Не используйте то, что есть по умолчанию

Полировать не значит делать идеальной

Концентрическая разработка: модульность и системы

Итерация, оценка и стабильность

Концентрическая разработка помогает с менеджментом времени

Переход к концентрической разработке

Концентрическая разработка и вертикальный срез

Концентрическая разработка и Agile

Максимизация несделанной работы

Темпы концентрической разработки

Глава 14 Артефакт препродакшена – вертикальный срез

Билд вертикального среза

Подготовьте дополнительные материалы

Понимание скоупа через создание вертикального среза

Плейтест вертикального среза

Фокус-тест названия игры и ключевого арта

Глава 15 Борьба с кранчем

Глава 16. Структура истории для гейм-дизайнеров

«Поэтика» Аристотеля

Пирамида Фрейтага

Структура игры отражает структуру сюжета

Истории и геймплей фрактальны

Компоненты истории

Как улучшить историю в вашей игре

Если сомневаетесь…

Глава 17 Артефакт препродакшена – макродизайн игры

Разрабатываем карту полного продакшена

Для чего нужен макродизайн

Макродизайн и цели проекта

Две части макродизайна

Обзор гейм-дизайна

Таблица макродизайна

Строки и столбцы в таблице макродизайна

Шаблон таблицы макродизайна

Цель игрока, цель дизайна и эмоциональный бит

Пример взаимосвязи между целью игрока, целью дизайна и эмоциональным битом

Преимущества макродизайна игры

Макродизайн игры высечен в камне

Макродизайн – библия гейм-дизайна?

Глава 18 Составляем таблицу макродизайна

Гранулирование таблицы макродизайна

Упорядочивание таблицы макродизайна

Завершение макродизайна

Микродизайн

Нелинейные игры и макродизайн

Примеры макродизайна

Глава 19 Планирование

Простое планирование

Сколько у нас человеко-часов, чтобы создать игру

Простейший план

Простой план для каждой задачи

Определяем скоуп проекта

Отслеживание прогресса в простом плане

Диаграмма сгорания задач

Решаем, что можно убрать

Изменение планов в диаграмме сгорания задач

Диаграммы сгорания задач создают атмосферу доверия и уважения

Глава 20 Обзор майлстоунов

Когда проводить обзор майлстоуна

Внутренние и внешние обзоры майлстоуна

Проведение обзора майлстоуна

Мозговой трест Pixar

Что делает замечание полезным

Что должны делать разработчики, представляющие игру на обзоре майлстоуна

Представление проекта заинтересованным сторонам

Эмоциональные аспекты обзора майлстоуна

Глава 21 Трудности препродакшена

Приверженность дизайну

Отмена проекта, если препродакшен идет плохо

Вперед! К полному продакшену!

Список артефактов препродакшена

Третий этап: полный продакшен – создаем и исследуем

Глава 22. Суть полного продакшена

Презентация вертикального среза и макродизайна

Работайте по списку задач

Переключение передач при переходе от препродакшена к полному продакшену

Проверка целей проекта

Регулярные встречи – стендапы

Майлстоуны полного продакшена

В каком порядке собирать игру

Ощущение игры и сочность

Фокусируемся на полном продакшене

Когда идти на риск на этапе продакшена

Глава 23 Виды тестирования

Неформальные плейтесты

Тестирование в процессе дизайна

QA-тестирование (обеспечение качества)

Автоматизированное тестирование

Публичное тестирование

Глава 24 Подготовка к формальным плейтестам

Формальные плейтесты в Naughty Dog

Общая практика формальных плейтестов

Подготовка сценария плейтеста

Подготовка опроса

Подготовка к заключительной беседе

Составляем вопросы для заключительной беседы

Фокус-тестирование названия игры, ключевого арта и дизайна логотипа

Подготовка ко дню формального плейтеста

Глава 25 Проведение формального плейтеста

Формальный плейтест в неформальной обстановке

Поиск плейтестеров

Поиск места, организация времени и выбор координатора

Подготовка места плейтеста

Прибытие плейтестеров

Рассадка игроков перед началом теста

Игровая сессия

Подведение итогов плейтеста

Уборка после плейтеста

Анализ результатов

Какие действия предпринимать на основе обратной связи по результату формального плейтеста

Как справиться со сложной обратной связью

Переходим к следующему раунду формальных плейтестов

Глава 26 Игровые метрики

Игровые метрики в Naughty Dog

Внедрение метрик в вашу игру

Согласие на сбор метрических данных

Визуализация метрических данных

Чек-лист действий по внедрению систем данных

Границы использования игровых метрик

Глава 27 Альфа-фаза и отслеживание ошибок

Простой метод отслеживания ошибок

Глава 28 Майлстоун альфа-версии

Фичи и контент

Полнофункциональность

Добавление всех игровых последовательностей

Хороший порядок онбординга

Роль альфа-майлстоуна

Подведение итогов альфы

Обзор майлстоуна альфа-версии

Глава 29 Стабы

Что такое стаб

Стабы в видеоиграх

Пример стаба объекта

Стабы и функциональность

Стабы контента против концентрической разработки

Глава 30 Привлечение аудитории к игре

Составьте маркетинговый план

Создайте веб-сайт и пресс-кит игры, а также свяжитесь с прессой

Запуск кампании в социальных сетях

Работа с инфлюенсерами в социальных медиа

Интегрируйте в разработку специалистов по маркетингу

Глава 31 Майлстоун бета-версии

Что необходимо для майлстоуна бета-версии

Завершенность и майлстоун бета-версии

Стадия беты, концентрическая разработка и состояние игры

Титры и атрибуции

Испытание достижения майлстоуна беты

Подведение итогов майлстоуна бета-версии

Обзор майлстоуна бета-версии

Четвертый этап: постпродакшен – исправляем и полируем

Глава 32 Этап постпродакшена

Сколько времени должен занимать постпродакшен

Исправление багов

Полировка

Правки баланса игры

Суть постпродакшена

Смена точки зрения

Волны постпродакшена

Глава 33 Майлстоун релиз-кандидата

Что нужно для релиз-кандидата

От релиз-кандидата к золотой мастер-версии

Выпуск игры

Глава 34 Процесс сертификации

Последовательность процесса сертификации

Прохождение и провал процесса сертификации

Обновления игры после сертификации

Возрастные рейтинги

Глава 35 Неожиданный гейм-дизайн

Виды неожиданного гейм-дизайна

Глава 36 После окончания проекта

Релиз игры

Постпроектный обзор

Отдых после проекта

Постпроектная хандра

Следующий проект

Исследования и разработки

Выбор дирекшена

Когда лучше покинуть команду

Вернемся к началу

Эпилог

Приложение А. Четыре этапа, майлстоуны и результаты производственного процесса игр

Приложение Б. Перевод текста с рис. 7.1

Приложение В. Таблица макродизайна (детальная) для Uncharted 2: Among Thieves с рис. 18.2

Благодарности

Библиография

Примечания