Книги: публикуем отрывок из книги Славы Гриса «Сделай видеоигру один и не свихнись»
В конце прошлого года издательство АСТ опубликовало книгу инди-разработчика Славы Гриса «Сделай видеоигру один и не свихнись». Нам так понравилась книга, что мы решили о ней написать, а заодно поделиться одной из ее глав на наших страницах.
Грис — автор трех камерных проектов, каждый из которых он сделал в одиночку: Fearmonium, Catmaze и Reflection of Mine. Сейчас, помимо разработки, он помогает сторонним инди-командам издавать свои проекты на Nintendo Switch, а также ведет YouTube-канал о создании видеоигр.
Его книгу вполне озаглавить и как «Психология для разработчика игр» и даже как «Самодисциплина для разработчика игр». В ней он разбирает вопросы мотивации, обучения, формирования привычек, рассказывает о работе мозга, а также делится собственным опытом.
Чуть ниже мы приводим 18 главу, которая посвящена основам дизайна видеоигр. В ней раскрываются такие понятия, как игровой цикл и ключевая механика, а также говорится о важности экономии в дизайне.
Глава 18. Основы дизайна видеоигр
Неплохим способом научиться дисциплине станет… игра в видеоигры. Мы способны проводить за играми десятки часов! Но если игры станут нашей работой, то эти десятки часов мы провели, значит, не за бездельем, а за самосовершенствованием. Такое понимание позволит куда проще воспринять необходимость следующие десять часов провести за просмотром уроков и тренировкой навыков, потому что мы уже будем знать, как много времени мы готовы посвятить тому, чтобы стать лучше.
Я могу сколь угодно долго рассказывать инопланетянину о том, как выглядит кошка, но куда эффективнее будет просто показать ему это прекрасное создание и обратить его внимание на ее отличительные особенности вроде мягких лапок, умилительной мордашки и хлопковых ушек. Так и вашим лучшим учителем в освоении искусства игрового дизайна станут не книги, видеоролики или наставники, а чужие игры и личные впечатления от них.
В вашей наблюдательности кроется залог успешного освоения такой на самом деле абстрактной и изменчивой науки, как «дизайн видеоигр».
Разрабатывая независимый продукт, мы находимся в чрезвычайно выгодном положении, которое позволяет нам игнорировать «общие тренды» и формулы удержания игроков. Оставим это ААА-студиям. Нашей миссией должна стать разработка игры, которая нравится в первую очередь нам самим. Это — наш единственный путь. Если делать то, чего мы не понимаем и чем мы не умеем наслаждаться, то работа не завершится успехом: она лишь приведет нас к упадку сил и загонит в тупик.
Вам придется попрощаться с привычным процессом игры в проекты того жанра, в котором вы собрались работать. Вы не просто должны бегать по уровням и получать удовольствие. Вам нужно выяснить, что делает изучаемый вами продукт хорошим или, напротив, плохим представителем жанра. Прислушивайтесь к собственным эмоциям — какие моменты в этой игре вас раздражают, а какие, наоборот, вызывают восторг и почему.
Сосредотачивайтесь на том, что побудило вас принять то или иное решение в игре. Почему, например, вы пошли именно в «эту» сторону? Быть может, дело в том, что разработчик очень умело расставил свет и вы выбрали более освещенный путь?
Оперирование понятием «игровой цикл» поможет вам лучше понять происходящее на экране. Любая видеоигра представляет собой на самом деле повторение одних и тех же действий. У линейных платформеров игровой цикл, например, представляет собой «дойди от точки А в точку Б» — и так столько раз, сколько в игре уровней. В метроидваниях же игровой цикл заключается в следующем:
— найти босса;
— победить босса;
— приобрести новую способность;
— обнаружить области применения новой способности.
После этого мы снова находим босса и повторяем все по кругу. Игровой цикл в рогаликах сводится к изучению процедурно сгенерированной области с целью найти усиливающие вашего персонажа предметы и способности, чтобы в определенный момент убиться об очередного босса и начать все по новой.
Безусловно, я чудовищно утрирую определение игрового цикла в рамках различных жанров, но для образовательной цели нам необходимо сначала научиться мыслить общими образами, а затем уже сосредотачиваться на частностях.
Сформулируйте в блокнотике, в чем заключается игровой цикл игр, которые вам симпатичны и хорошо знакомы. Просто записывайте действия, которые вы совершаете в этой игре, и указывайте причины, побудившие вас их выполнить. Пишите до тех пор, пока не определите, где же в этом проекте начинается новая петля.
Внутри цикла спрятана «ключевая механика», которая обрастает «дополнительными активностями». «Ключевая механика» — это то, во что уже можно поиграть и получить удовольствие. Вспомните мой пример с Ori and the Blind Forest: даже без графики, эффектов и дополнительных механик игра увлекает.
Но стоит иметь в виду, что отнюдь не во все хорошие игры будет приятно играть в том случае, если с них срезать все детали. Я наблюдаю в разработке видеоигр два подхода: первый заключается в том, чтобы впечатлить игрока размахом, деталями и вложениями, закрыв все «дыры» вашей игры деньгами и человеческими ресурсами. Ярким примером такого подхода становятся открытые миры в современных ААА-играх, поражающие воображение игроков сумасшедшим объемом разношерстных декораций. Создание такого мира в одиночку заняло бы у разработчика целую декаду лет.
Противоположный метод заключается в «изящной экономии». В этом случае отсутствие ресурсов и возможностей выставляется так, словно автор добровольно установил себе какие-либо ограничения, обращая их в свой стиль. Самым выразительным примером служит оригинальная Silent Hill, выходившая в свое время на PS1. Ресурсов этой консоли не хватало для отрисовки открытых пространств, оттого разработчики прибегли к хитрому трюку: они замостили улицы в Silent Hill густым туманом. Как вы знаете, туман в дальнейшем стал отличительной особенностью серии.
Почти все рисунки в визуальной новелле Tiny Bunny выполнены в черно-белой палитре. Мало того, что выбор стилистики выделяет ее визуальный ряд среди других новелл и подчеркивает мрачность описываемых в ней событий, так еще и рисовать, используя лишь градации серого, гораздо проще, чем составлять сложную цветовую схему.
В Call of Duty: Black Ops — Cold War многие игроки были впечатлены тем, что к NPC можно подойти с любой стороны и начать беседу: у каждого NPC была своя анимация поворота к игроку, а сидячие NPC, к которым игрок подходил сзади, поднимались со своих мест, разворачивались и иной раз даже ворчали на игрока. Это — потрясающая деталь, но создание анимаций является очень трудоемким процессом, и соло-разработчику нерационально тратить свои ресурсы на реализацию подобной механики. Но и отнимать у игрока возможность взаимодействия с NPC только по той причине, что игрок подошел к нему сзади, тоже является весьма неуклюжим решением.
В способах выхода из сложившейся ситуации и заключается метод «изящной экономии». Если поставить NPC спиной к стене — то у игрока просто не будет возможности подойти к нему сзади, а значит, и не возникнет необходимости дорисовывать анимацию разворота. Идея взаимодействия с NPC через закрытую дверь в Bloodborne — гениальна. Разработчики не моделировали персонажа, не занимались лицевой анимацией, не сталкивались с проблемой позиционирования при взаимодействии, они просто сделали так, что NPC не открывал нам дверь в свой дом и оставался невидимым. Изящная экономия во плоти!
Наблюдать различные способы экономии можно и в кино. Особо заметные примеры мы можем увидеть почти в любом фильме, где есть сцена перевоплощения человека в какое-нибудь страшное существо вроде оборотня. Эти сцены — очень дорогие в производстве, оттого режиссеры уже чего только ни придумали, чтобы и зрителя не разочаровать, и ресурсы сэкономить. Частенько сцена перевоплощения прерывается кадрами с изумленными лицами свидетелей сего действия; иной раз все разворачивается за спиной главного героя, и монстр находится «не в фокусе», что позволяет сделать анимацию менее детализированной; а способ показывать только тень человека, превращающего в оборотня, абсолютно великолепен — аниматор в этом случае работает только с контурами, а звуковые эффекты и воображение зрителя уже дорисуют все остальное, сохранив нужный пугающий эффект.
Подглядывайте, как экономят разработчики тех игр, в которые вы играете, и тех фильмов, которые вы смотрите. Без внимательного анализа большинство решений останется незамеченным, потому что так и должно быть — игрок не должен знать, что вы решили увести экран в затемнение на драматичной сцене лишь для того, чтобы не рисовать «одноразовые» анимации.
Любой дорогой в производстве элемент может быть использован несколько раз. Игры-рогалики являются живым примером того, сколько различных игровых ситуаций можно создать с одинаковыми игровыми элементами, но в то же время некоторые проекты вроде Devil May Cry 4 могут разочаровать игрока тем, что разработчик вынуждает его снова пробежаться по уже пройденным уровням в строго обязательном порядке.
Учитывать ограниченность ресурсов нужно еще на стадии написания сюжета. Не стоит придумывать сцены, декорации для которых будут использоваться единожды. Нет никакого смысла показывать какого-нибудь босса сидящим в своих покоях, а потом отправлять его на встречу с игроком на специальной арене. Стройте сюжет так, чтобы использовать как можно меньше локаций и объяснить, почему босс или уже был на арене в момент нашего прибытия или же почему мы попали в его покои и решили драться там.
Мы не можем себе позволить такое расточительство, как разработчики Anthem, где детально прорисованные джунгли с горами, водопадами и десятком видов деревьев нужны лишь для того, чтобы мелькать под ногами игрока, пока он летит на реактивном ранце. Если вы добавляете в игру объект или локацию — у этого должен быть какой-либо смысл, кроме как «впечатлим игрока детализацией».
Большинство начинающих разработчиков спотыкаются об амбициозность своих проектов. В одиночку можно, разумеется, сделать что угодно — это всегда вопрос, в первую очередь, времени. На создание JRPG в открытом мире у вас может уйти больше лет, чем вам отведено на этом свете, и браться за такую игру попросту нерационально.
Качество выпускаемых вами игр будет зависеть не столько от количества потраченного на них времени, денег и сил, а сколько от используемого в них опыта. Чем скорее вы доведете игру до выпуска, тем больше опыта вы сможете вложить в следующий проект. Хватаясь за разработку игры сумасшедших масштабов, вы рискуете потоптаться на месте, потерять несколько лет жизни и выгореть. Игра, разумеется, так и не будет выпущена.
Всегда определяйтесь с ключевой механикой, вокруг которой строится ваша игра, и в первую очередь реализовывайте те вещи, без которых ваша идея не может существовать в принципе. Я замечал, что, когда я или мои коллеги рассказываем о новом, едва начатом проекте, нам обязательно задают вопрос: а будут ли в игре «пасхалки»? «Пасхалками», или «пасхальными яйцами», называют шутливые упоминания и отсылки к другим проектам. В этом нелепом вопросе меня сильнее всего мучает мысль, а какого черта я должен думать о таких мелочах в самом начале разработки? Я еще не до конца отполировал ключевую механику, о «пасхалках» я подумаю через год.
Одним из основных критериев ключевой механики является ее «понятность». Если вы зайдете в Steam, найдете там игру, которую вы любите и хорошо знаете, и начнете читать негативные отзывы, то обнаружите парочку отзывов, которые написаны словно о другой игре. Авторы этих отзывов попросту не поняли, как играть в этот проект, и остались им недовольны. Это абсолютно нормальная ситуация, потому что игры запускают люди с абсолютно разным игровым опытом. Если вы делаете стратегию, то будьте готовы к появлению игроков, которые в стратегии никогда в жизни не играли и понятия не имеют, что такое «юнит». Ваша задача — сделать игру понятной для людей с любым игровым опытом.
Перед тем как наращивать на «ключевую механику» всю остальную игру, вам стоит убедиться в том, что эта механика понятна игрокам. Единственно верным способом такой проверки станут шоукейсы: показывайте свою игру другим игрокам на сходках разработчиков, фестивалях, просто зовите друзей к себе домой и внимательно наблюдайте за тем, как люди играют в то, что вы сделали. Шоукейс представляет собой возможность дать кому угодно попробовать поиграть в ваш проект, пока вы сами стоите рядом и общаетесь с игроком напрямую. Ни в коем случае не комментируйте и ничего не подсказывайте игрокам. Просто запоминайте, в каких местах игроки не поняли, что им надо делать, а в каких местах им было очень сложно.
Настоящая критика — это не хвалебные отзывы или остроумные замечания. Настоящая критика — это действия ваших игроков. Если игрок говорит, что игра замечательная, но уделяет ей минуту времени, он лжет. Если игрок ругает ваш проект, но не может оторваться от контроллера уже несколько часов — он лжет. Следите за действиями ваших игроков, а не за их языком.
Когда «ключевая механика» будет готова — время приступать к реализации «дополнительных активностей». Под ними я подразумеваю все, без чего игра, возможно, будет хуже, но все еще может существовать и в нее все еще можно будет играть. Чаще всего это количественный показатель: размеры уровней, численность боссов, наличие локализации на разные языки, какие-то эффекты, мини-игры и сложные элементы интерфейса. Такой порядок действий поможет вам сохранить уйму времени, потому что, поверьте, одна переделка всегда несет за собой уйму других переделок.
Однажды игрок предложил мне внести «незначительное» изменение в Fearmonium, которое позволило бы главной героине атаковать на ходу, как это было реализовано в Catmaze. Я же шел по пути игр серии Castlevania, и атака приковывала персонажа к месту, делая бои более тактичными и вынуждая игрока с умом подходить к атаке, а не просто без остановки долбить по кнопке удара. Если бы я внес такое изменение, то мне пришлось бы править баланс, двигаясь в сторону «усложнения», потому что битвы с врагами стали бы в десятки раз проще и игрок мог бы всех убивать, просто двигаясь туда-сюда и без остановки махая молотом. Я редко использовал какие-то наводящиеся снаряды, и вся защита всегда строилась на том, чтобы двигаться. Игрок становился уязвимым, лишь когда стоял на месте. А стоять на месте он вынужден был, чтобы атаковать.
Для правки баланса мне бы пришлось пересмотреть поведения 60 монстров и 14 боссов. Честно — мне проще сделать новую игру, чем переделывать одну из ключевых механик, ибо за годы разработки вокруг этой механики выстроилось неимоверное количество «побочных элементов». Когда дом построен — поздно переделывать фундамент. А если фундамент построен плохо, то и дом в скором времени развалится, вне зависимости от того, как красиво вы облицевали стены.
Не стесняйтесь демонстрировать сырые сборки вашей игры. Чем раньше вы заметите свои ошибки в ходе наблюдения за игроками, тем меньше работы вам придется проделать по их исправлению.
