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

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

Полная версия

Глава 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). Мы должны разобраться с этими элементами игры на этапе препродакшена, создав вертикальный срез с персонажем или персонажами игрока, их основными способностями и основными механиками игры.

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. – Прим. авт.
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35 
Рейтинг@Mail.ru