Помоги проекту - поделись книгой:
«Прячущая рука» забросила меня в то положение, в котором я был вынужден приобрести полезные знания, проявить креативность и, чтобы двигаться дальше, освоить новые навыки. Всё это сопровождалось отчаянием, стрессом и паникой, но в любом другом случае я бы так и не узнал всех тонкостей своего движка, которые я учитываю в проектах и по сей день.
С другой стороны, ситуация могла бы оказаться безвыходной и решения могло бы не найтись: при худшем раскладе я был бы вынужден избавиться от части плагинов, реализовать задуманное какими-то иными способами или, почувствовав себя в совсем уж глухом тупике, попросту бросить проект. Тогда «прячущая рука» привела бы меня не к улучшению навыков, а к провалу.
Для того чтобы выяснить, является ли «прячущая рука» когнитивным искажением, способным положительно сказаться на результатах нашей деятельности, или же, напротив, ее влияние всегда негативно, было введено разделение этого явления на «благотворную прячущую руку» и «тлетворную прячущую руку». Психологи провели исследование на двух тысячах проектов, пытаясь выяснить, с какой вероятностью незнание сложностей ведет к положительным результатам и росту компетенцией, а с какой – приводит к провалу и ошибкам.
Результаты, увы, оказались неутешительными: мой случай, когда тупиковая, казалось бы, ситуация сделала меня умнее, вошел лишь в 22 % проанализированных проектов. В остальных 78 % «прячущая рука» оказывала тлетворное влияние и приводила если не к провалу, то к серьезному откату назад и задержкам в исполнении.
Что же получается? С одной стороны, незнание всех нюансов вашей задачи способно создать наиболее подходящую среду для развития навыков и проявления креативности. Неправильная оценка задачи – это лучший способ задействовать все творческие ресурсы и раскрыть свой потенциал. С другой – исследования показывают, что в подавляющем большинстве случаев «прячущая рука» приводит к крайне плачевным последствиям, скрывая от нас преграду, которую мы не способны преодолеть. И как тут быть?
Подобное когнитивное искажение получится обойти двумя способами. Во-первых, возможно компенсировать его другим искажением, ибо минус на минус может дать плюс. Я говорю о так называемом синдроме самозванца, который сопровождается недооценкой собственных сил. Люди с синдромом самозванца обычно крайне не уверены в своих компетенциях. Все свои достижения они списывают или на удачу, или на других людей. Им кажется, что всё, чего они добились, досталось им незаслуженно. Вне зависимости от имеющихся знаний и навыков эти люди не чувствуют себя специалистами в своей области и недооценивают свои силы.
При работе над Reflection of Mine я преодолел препятствия, скрытые от меня «прячущей рукой», и вошел в 22 % счастливчиков именно из-за этого синдрома: я понятия не имел о том, что мне было по силам, и принял за тупиковую ситуацию самый обычный рабочий момент.
Если вам свойственно ошибаться в расчете собственных сил в пользу недооценивания своих способностей, то «принцип прячущей руки» не столь страшен. Ваша слабость окажется преимуществом тогда, когда раскроются невидимые ранее подводные камни. Люди с синдромом самозванца редко берутся за выполнение задач, если они не сталкивались ни с чем подобным ранее или если они не способны просчитать все риски. Только «принцип прячущей руки» позволяет им оказаться в условиях, необходимых для получения новых знаний и проявления креативности.
Но далеко не все мы чувствуем себя самозванцами: подобное когнитивное искажение распространено не так уж сильно, и иной раз люди, напротив, склонны переоценивать свои достижения. Если вы ни разу не наблюдали за собой поведения, свойственного человеку с синдромом самозванца, и не испытываете леденящего душу ужаса, хватаясь за работу, с которой раньше не сталкивались, то от зловещих последствий «прячущей руки» вас спасет второй предлагаемый мной путь – модульная разработка.
Любой элемент в любом продукте стоит разбивать на отдельные модули, и чем меньше они будут связаны друг с другом, тем лучше. Под модулем я подразумеваю какую-то составляющую проекта, без которой игра если и станет хуже, то, по крайней мере, не перестанет существовать вовсе. Например, сюжет игры можно разбить на почти независимые друг от друга «главы», где важнейшими будут только две – первая и последняя. Без остальных же сюжет вполне сможет существовать. Тогда в случае, если у вас не хватит сил, знаний, денег, опыта или других ресурсов на реализацию чего-то из середины игры, вы вполне сможете вычеркнуть эту главу и, добавив несколько незначительных изменений в другую, продолжить повествование.
Такой подход можно спроецировать, например, и на способности, которыми обладает ваш главный герой: при добавлении нового способа атаки лучше делать так, чтобы та часть кода, которая за него отвечает, минимально перекликалась со всем остальным массивом умений и могла быть безболезненно вычеркнута и так же безболезненно введена обратно. Чем меньше у вас будет взаимосвязей между потенциально независимыми элементами, тем меньше трудностей у вас возникнет, когда «прячущая рука» откроет перед вами завесу непреодолимых преград.
Вместо того чтобы неделями биться как рыба об лед о проблему, существование которой было невозможно предусмотреть, вы сможете просто пройти мимо нее, вычеркнув этот элемент из своей игры. Оттого и совет о том, что после продумывания основных механик и концепции стоит сразу реализовывать концовку вашей игры, является лучшим из всех, что я слышал и что я могу дать. Такой подход во многом увеличит ваши шансы довести игру до ума. У вас будет начало и конец, а с серединой вы сможете делать всё, что захотите.
В моей игре Fearmonium главной героине открыто весьма обширное количество способов передвигаться: можно как просто бегать, так и ехать на самокате, скользить по наклонным поверхностям, надышаться гелия и лететь, подобно воздушному шару, и т. д. Каждый раз, когда игрок менял способ передвижения с бега на самокат, вся часть кода, отвечающая за бег, попросту переставала работать – я отключал ее полностью.
В относительно популярной игре The Vagrant долгое время присутствовал баг, завязанный на хитром использовании способности «рывок», позволяющей игроку с высокой скоростью переместиться по заданной траектории. При использовании рывка в воздухе на одном уровне с платформой персонаж мог коснуться земли до того, как закончится ускорение от рывка. При выполнении такого хитрого приземления персонаж переходил-таки в состояние бега, но сохранял удвоенную скорость, свойственную рывку. Разогнавшись, он мог перейти в состояние прыжка и, так как скорость движения сохранялась, преодолеть немыслимое расстояние, сломав игру совсем.
Подобные баги выдают хаос, который творится у разработчиков в коде, где все состояния персонажа переплетены друг с другом и учтены не все сценарии перехода от рывка к бегу. Сломать игру The Vagrant было бы труднее, если бы способности героя располагались в независимых друг от друга модулях, при активации которых сбрасываются все особенности, сопутствующие предыдущему состоянию.
Другой показательный пример можно почерпнуть из заметок разработчиков третьей части «Ведьмака»: при выполнении одного из дополнительных заданий перед Ведьмаком закрываются все двери – по условиям миссии и сценарию ему нельзя заходить в помещения. По мере выполнения задания двери снова открываются. Но вот недочет: открывались вообще все двери в игровом мире, что приводило к немыслимому количеству багов. Состояние дверей учитывалось только в одном модуле, и, судя по всему, при его написании никто и не догадывался, что появятся миссии, где этот модуль не должен будет работать.
Как мы видим, подобную ошибку допускают не только новички, но и старожилы игровой индустрии, ибо прибегнуть к модульному стилю разработки может помешать еще одно когнитивное искажение – «наращивание вовлеченности».
Когда Терри Кавано, автор популярной в свое время игры VVVVV, опубликовал ее исходный код, пользователи были поражены количеству case в его работе (рис. 3). Лишних взаимосвязей в игре оказалось настолько много, что даже публикация исходного кода не дала проекту второй жизни в виде появления пользовательских модов и дополнений: разобраться в столь громоздком «макаронном монстре» и что-то туда добавить было не так-то просто.
Понятие case определяет, в каком состоянии находится игра: меню ли перед игроком, игровая сцена или финальные титры. Обычно их группируют вместе, но разработчик VVVVV, очевидно, не догадывался о том, сколько разных событий у него будет в игре, и под каждое состояние создавал свой case. В итоге «кейсов» у него вышло 4099. Тем не менее VVVVV – замечательная игра, заслужившая свой успех, и я ни в коем случае не пытаюсь обесценить талант Терри Кавано и высмеять его решения. Идеального кода не существует, каждый из нас лепит в свои проекты бессмысленный мусор. Я просто призываю к тому, чтобы заранее подумать хотя бы о том, сколько состояний будет у вашей игры, иначе вам придется страдать за свой продукт так же, как страдал Терри: он сам отзывался о своем коде как о держащемся «на слюнях и молитве» и выпившем у него немало крови. Игра работает, а значит, эти ужасные костыли не столь важны для конечного пользователя, но вот эмоциональному состоянию автора точно не позавидуешь.
Рис. 3. Часть исходного кода к игре VVVVV.
Какое-то время у разработчиков получается решать проблемы, возникающие на кривом фундаменте, но рано или поздно недоработок становится настолько много, что рациональнее становится переписать всё с нуля или же попросту начать отказываться от новых идей, чтобы не развалились старые. Ужас плохой архитектуры заключается в том, что работать-то проект на ней всё еще способен, а вот быть пластичным – нет.
Создание игры Yandere Simulator – симулятора школьницы-убийцы – ведется с 2012 года. Разработчик регулярно добавляет огромное количество абсолютно сумасшедших мелочей. Например, игрок может убить кого-нибудь ножом и тут же прижечь свежую рану жертвы горелкой – таким образом, когда он будет тащить труп по полу, тот не оставит кровавого следа. У каждого школьника есть свое расписание и даже своя обувь, которую он меняет при входе в здание образовательного учреждения.
Вся игра состоит из таких любопытных деталей, но вот уже больше десяти лет она никак не может перерасти в нечто большее. Разработчик-одиночка, стоящий за Yandere Simulator, уже прибегал к помощи издательства, но, когда к нему присоединился сторонний специалист, оказалось, что довести игру до ума почти невозможно: автор абсолютно все события, определяющие поведение сотни школьников в густонаселенном мире Yandere Simulator, выразил через простейшую и грубую связку операторов …if …else. В итоге имплементация каких-то глобальных новых механик оказалась невозможной, а сама игра, демоверсия которой тормозит так, словно запущенный на компьютере двадцатилетней давности Red Dead Redemption 2, всё еще не вышла в свет.
В Reflection of Mine по причине своей некомпетентности я абсолютно сумасшедшим образом реализовал меню паузы: в состоянии паузы скорость движения каждого игрового объекта умножалась на ноль шестьдесят раз в секунду. Объекты останавливались? Да. Но добавление любого движущегося элемента вынуждало меня возвращаться в «кейс» паузы и вписывать туда дополнительные условия. В итоге я подсознательно отговаривал себя от добавления новых подвижных игровых объектов во избежание необходимости тормошить этот собранный из костылей ворох, где малейшая опечатка ломала игру.
Ситуация, в которой изначально неправильные и неуклюжие решения дают-таки положительный результат, наращивают ту самую вовлеченность. Это когнитивное искажение заключается в том, что, даже столкнувшись с негативными последствиями наших действий и решений, мы всё равно продолжаем двигаться в том же направлении и из раза в раз делать одно и то же. Это только усугубляет ситуацию, и «макароны» в какой-то момент начинают уже лезть из кода в виде ужасных багов и зависаний.
Принимая иррациональное решение продолжать работать на фундаменте кривого кода, мы учитываем количество усилий, уже затраченных на его реализацию, тестирование и вылавливание глюков и багов. В определенный момент цель доделать очередную механику, ломающую все предыдущие, просто перестает стоить тех средств и времени, которые мы на нее тратим.
Сокрушительная ошибка, допущенная мной при разработке Catmaze, заключалась в том, что весь текст (а его у меня, к слову, набралось двадцать тысяч строк) я вставлял прямо в код. Когда игру перевели на пять дополнительных языков и прислали мне огромную таблицу с переводом, мне пришлось сто тысяч раз нажать crtl+c и сто тысяч раз нажать ctrl+v. Чудовищная архитектура моего проекта не позволяла мне даже автоматизировать этот процесс, потому что некоторые строки приходилось вставлять «по-особому».
В самом начале этой утомительной работы я догадывался, что потрачу куда меньше времени и сил, если внедрю в игру адекватную диалоговую систему и автоматизирую появление текста на разных языках. Но, во-первых, мой синдром самозванца нашептал мне на ушко, что я не справлюсь с этой работой, ибо я же не программист (и плевать, что ровно месяц назад я сделал хорошую и удобную диалоговую систему для Fearmonium – мне же якобы просто повезло, что она работает, второй раз я такого сделать не смогу), а во-вторых, уровень моей вовлеченности в ужасную архитектуру Catmaze был уже слишком высок: я же уже нажал сорок тысяч раз на ctrl+c и столько же раз на ctrl+v, когда добавлял в игру английский и русский. Я что, зря тогда мучился?
По причине наращивания вовлеченности появление более правильного и изящного решения для интеграции новых языков казалось чем-то, что сводит на нет все мои предыдущие труды. «Если я сейчас исправлю архитектуру, – думал я, – то получается, что я напрасно страдал и работал столько дней!» Можно ли назвать это мышление иррациональным? Конечно, да.
Но в определенные моменты что разработки, что жизни вообще мы все поддаемся наращиванию вовлеченности: кому-то трудно разорвать болезненные отношения, на алтарь которых они уже положили слишком многое; кто-то излишне долго тянет с увольнением с бесперспективной работы, на которой он и без того провел слишком много лет; кто-то усердно, сквозь уныние и грусть, выбивает все достижения в игре, которая ему толком не нравится, но в которую он уже успел наиграть десятки часов перед тем, как это осознать; кто-то досматривает сериалы, на середине которых сценаристы уже потеряли рассудок и повернули повествование в сторону банальностей или полного абсурда…
Лучше всего об этом когнитивном искажении известно маркетологам, предлагающим накопительные карты со скидками или бесконечные кредиты, а также мошенникам, которые затягивают вас в долгую беседу с расчетом на то, что, потратив немало времени на разговор с ними, вы с большей охотой уделите им еще несколько своих драгоценных минут.
Поэтому маленькие команды годами тянут разработку своей «RPG в открытом мире», попусту растрачивая силы и ресурсы, а в итоге сворачивают проект и берутся за создание небольшого уютного квеста. Поэтому Терри Кавано, превозмогая хаос в коде своего проекта, продолжал громоздить условие на условии и чудом довел игру до выхода в свет. Потому и я нажал сто тысяч раз ctrl+v.
И мне очень хотелось бы остановить на этом перечисление искажений, которые провоцируют начинающих разработчиков браться за непосильную ношу, проваливаться и выгорать, но я перечислил еще не все подводные камни, способные столкнуть нас в омут громоздких проектов. Исследования давно доказали существование «эффекта Ирвина», который заключается в том, что мы склонны переоценивать вероятность позитивного исхода вне зависимости от степени нашей оптимистичности. Возможность ошибиться и провалиться в том или ином начинании воспринимается нами как очень маловероятная.
Связано это явление с эвристикой доступности: события, которые с большей легкостью приходят нам на ум, считаются нами наиболее вероятными. Так, например, многие люди боятся летать на самолетах. Репортажи о крушении летательных средств всегда эмоциональны, драматичны и, разумеется, откладываются в нашей памяти как что-то из ряда вон выходящее.
Мы легко запоминаем редкие и необычные вещи. Нечто рутинное и повседневное откладывается в нашей памяти куда хуже. Именно поэтому мы с большей легкостью вспоминаем что-то необычное и используем это в своих суждениях, принимая такое явление за нечто куда более ординарное, чем есть на самом деле.
Я не стремлюсь обесценить такую катастрофу, как крушение самолета, но человек, впадающий в панику во время полета и при этом доехавший до аэропорта на такси, мыслит определенно иррационально: по данным исследований, проведенных в США, вероятность умереть в авиакатастрофе составила 1 к 355 тысячам, а в ДТП – 1 к 18 тысячам. В 2018 году в России в результате крушения самолетов погибло 80 человек, в то время как число жертв ДТП за тот же год достигло 18 тысяч. Число пострадавших в ДТП превысило 200 тысяч.
Кстати, вероятность быть убитым акулой вдвое меньше, чем вероятность быть убитым коровой. Тем не менее нас пугает фильм «Челюсти», а не «Копыта», а людей, испытывающих страх перед полетами, куда больше, чем людей, страшащихся поездок на машине.
Причиной тому служит как раз «эвристика доступности»: при формировании суждений мы используем самые доступные воспоминания. То, что имеет яркую эмоциональную окраску, с большей вероятностью станет основой для принятия наших решений.
Как это связано с тем, что мы переоцениваем вероятность наступления положительного результата? Дело кроется отнюдь не в такой личностной черте, как оптимизм. Согласно эффекту Ирвина, эмоционально-положительное событие проще и быстрее попадает в кратковременную память, в то время как негативные события блокируются нашим мозгом как нечто травмирующее. Исследования показали, что люди оценивают вероятность появления хороших событий в своей жизни на 15 % выше, чем у других людей, а плохих событий – на 20 % ниже.
Формируя суждение о том, будет ли их игра доделана и станет ли она успешной, разработчики прибегают к тому, что лежит на самой поверхности их памяти, и делают наивный и ошибочный вывод о непременном успехе. Всё же в памяти у нас гораздо больше историй о разработчиках, добившихся высот, и играх, разошедшихся миллионными тиражами. Истории провалов отнюдь не так популярны. Попробуйте вспомнить хоть одну книгу об игре, которая так и не вышла, а потом гляньте на полки с литературой, заваленные информацией об успехах Doom, Silent Hill или Minecraft. А располагаете ли вы достаточно исчерпывающей информацией о тех, за чьими плечами – лишь одни неудачи? Сможете вспомнить хоть одно имя, кроме моего?
Я надеюсь, что вам уже не хочется делать RPG в открытом мире, и вы согласитесь, что стоит остановится на более скромных и оригинальных идеях.
Разумеется, это может деморализовать. Вы садитесь делать игру, которая заведомо не будет лучшей на свете, а если и приложите все усилия, то обязательно найдете того, кто умудрился сделать грандиозный хит с помощью идей, схожих с вашими, в то время как вы довольствуетесь весьма скромным успехом.
Важно понимать, что вокруг всегда будут проекты лучше вашего. Однако каждый ваш проект должен выполнять свою конкретную цель, и двигаться вы должны именно к ней. Рисуя, я не ставлю себе цели приблизиться к таланту Джеральда Брома. Моя цель – сделать выразительные анимированные спрайты читаемых и интересных персонажей. Несмотря на то что существуют на свете рисунки лучше, я остаюсь доволен, если моя работа достигает моей конкретно поставленной цели.
Выпутаться из омута ошибок поможет избавление от нравственной установки, которую многим из нас когда-то буквально вдолбили в голову фразами вроде «Не умеешь – не берись» или «Сделать нужно или хорошо, или никак». Ошибки начинают казаться чем-то постыдным, порочащим, и это вредно настолько, что мне тут даже не подобрать достаточно выразительной метафоры.
Когда я смотрю очередную трансляцию по Fearmonium, я стараюсь не стыдиться своих ошибок: я вижу все огрехи в игровом дизайне, все ошибки в анимациях, и это ви́дение делает меня… счастливым. В тот момент, когда я создавал тот или иной «сломанный» элемент, я не обладал достаточными компетенциями, чтобы сделать всё правильно. Однако сейчас, спустя несколько лет, я вижу места, где ошибался. Это означает, что я вырос как специалист. Нахождение каждой новой ошибки – это очередная ступень, которая позволяет мне подняться выше. Я люблю находить свои ошибки и рекомендую вам проникнуться этой же страстью, отбросив предубеждения о том, что ошибаться – стыдно.
Учитывайте при планировании ваши личностные качества: склонны ли вы к синдрому самозванца? Если да, то эффект «прячущей руки» вам не так страшен, а если же нет – тогда в обязательном порядке используйте модульную разработку, в ходе которой игра разделяется на независимые друг от друга элементы. Не поддавайтесь эвристике доступности, воспринимая неординарные вещи как нечто обыденное: количество историй успеха, с которыми знакомы лично вы, никоим образом не отражает действительности. При прогнозировании положительного результата учитывайте, что такие планы вполне могли быть надиктованы вам «эффектом Ирвина», и тщательно взвешивайте причины, которые позволили вам сделать вывод об обязательном успехе своего начинания.
Ошибка 5
Переоценивать игровой опыт
Какую бы игру вы ни делали, едва ли вы сядете за ее создание с целью получить несколько сотен сугубо отрицательных отзывов, прослыть чудовищной бездарностью и удивиться тому, что количество возвратов вашего продукта окажется сопоставимо с количеством проданных копий. Даже если вы разрабатываете игры только ради прибыли, а не ради самовыражения, столкнуться с негативом и грязью вам захочется в последнюю очередь: между хорошими продажами и положительными отзывами есть очевидная связь. Чтобы хорошо продаваться, ваш проект должен нравиться игрокам.
Я не представляю ситуации, в которой у разработчика нет мотивации сделать хороший продукт, порадовать покупателей и зарекомендовать себя как опытного специалиста среди коллег. Минимизация количества негативных отзывов – это очевидная цель для каждого из нас. Негативные отзывы – наш враг. А врага нужно знать в лицо.
Я настойчиво рекомендую заняться на досуге чтением негативных обзоров к другим играм в Steam, чтобы осознать, за что вы сами можете получить по шапке. Не стоит выбирать продукты, добившиеся ошеломительного успеха и имеющие 3–5 % отрицательных обзоров среди массива восхваляющих их гениальность текстов. Вчитываясь в негатив, направленный в сторону какой-нибудь Signalis, у которой на момент написания этой книги было 96 % положительных обзоров из шести тысяч, вы просто совершите «ошибку выжившего» (это понятие было сформировано во время Второй мировой войны, когда вернувшимся на базу самолетам укрепляли лишь поврежденные части, в то время как укреплять нужно было места, куда вражеские снаряды как раз не попали: ведь те самолеты, которые получили урон именно в этих местах, вообще на базу не вернулись).
Читайте отзывы к играм, которые или не стали популярными (т. е. имеют меньше тысячи обзоров в целом), или вовсе с треском провалились. Содержимое отрицательных отзывов можно условно разделить на несколько категорий, но в текущей главе мы поговорим только об одной из них.
Нас сейчас не интересуют обзоры, в которых игроки шутят, ругаются на баги или просто сходят с ума. Мы поговорим про тот тип игроков, которые остались недовольны продуктом, потому что не поняли, как в него играть. Разумеется, прямым текстом «я ничего не понял» никто не напишет, потому что оставивший негативный обзор игрок обыкновенно твердо убежден, что играл в ваш продукт так, как задумывалось.
Чтобы вы поняли мой посыл, давайте отвлечемся и поговорим про шахматы.
Шахматы – это гениальная игра, предоставляющая нашему мышлению огромный простор для поиска оригинальных решений и для развития находчивости. Легко можно представить себе людей, которые получают удовольствие от шахмат. Я и сам очень люблю и уважаю эту игру.
Но попробуйте поиграть в шахматы с кем-нибудь, кто не знает правил. Он не понимает, почему ему нельзя подвинуть пешку на четыре клетки по диагонали или перепрыгнуть ладьей через ферзя. Он будет удивлен окончанию партии, в которой его короля обступили вражеские фигуры, ибо он понятия не имеет, что такое мат и почему его короля не могут просто съесть.
Получит ли человек, не наученный правилам игры в шахматы, удовольствие от процесса, в котором он испытывает только недоумение и преодолевает фрустрацию? Конечно, нет. Так же дела обстоят и с видеоиграми: никто из нас не делает абсурдно плохих проектов нарочно, но игроки вполне могут пытаться преодолеть выставленные вами препятствия абсолютно не тем способом, которым планировалось. Тогда они не испытают ничего, кроме раздражения от своих провалов и неудач.
Обратите внимание на стримеров в момент, когда они решают завязать с прохождением той или иной игры: чаще всего на экране будет лежать мертвый персонаж и гореть надпись Game over. Многие отзывы написаны игроками в ярости и раздражении после того, как сотни попыток пройти особо злополучное место не привели к положительным результатам. Сколько мы видели видеороликов, в которых разгневанные игроки бросают контроллеры в мониторы, разбивают свои консоли или просто истошно орут на экран? Получают ли они удовольствие от игры в этот момент? Едва ли. У них абсолютно не выходит играть так, как задумывал автор, но поверьте: в большинстве случаев в этом нет их вины.
Чтобы объяснить ситуацию, в которой одной из причин негативных обзоров является неспособность игроков разобраться в игровом процессе, но при этом и не заклеймить их дураками, я приведу несколько примеров. Они необходимы для того, чтобы у вас не возникло желания свалить всю вину за нервные срывы некоторых стримеров лишь на их собственную глупость. Всё обстоит как раз-таки наоборот: в злости и провалах игрока чаще всего виноват разработчик.
Игроки, которые не поняли, как играть в вашу игру, – не тупые. Запомните этот тезис и не вздумайте трактовать мои слова так, будто я пытаюсь оскорбить аудиторию, которая нас тут всех кормит или будет кормить в будущем.
Существует такая игра, как Pascal’s Wager, – на мой взгляд, весьма неплохой продукт, вдохновленный, по словам разработчиков, игрой Bloodborne, но привнесший в нее линейный сюжет со срежиссированными кат-сценами, диалогами и несколькими играбельными персонажами, среди которых есть весьма уникальная героиня-монахиня. Один из отзывов гласит: «Есть монашка и она… ДА она расходует хп при атаках – мне надо говорить НАСКОЛЬКО это *безумно*?!» (авторская пунктуация и орфография сохранены).
Действительно, если при игре за монахиню в Pascal’s Wager начать бездумно размахивать оружием, то ее уровень здоровья быстро начнет стремиться к нулю. Это раздосадовало далеко не одного игрока, и многие явно испытали трудности с прохождением игровых уровней за героя с такой своеобразной особенностью.
Но были бы они так расстроены, если бы углубились в чтение о способностях монахини и наткнулись бы там на описание навыка, позволяющего ей восстанавливать здоровье с помощью специальной последовательности ударов? Лично я прошел всю игру, выбрав именно монахиню в качестве основного героя, ибо освоение этого умения сделало ее почти бессмертной. Любой пропущенный удар с лихвой компенсировался удачной комбинацией, восстанавливающей шкалу HP.
Кто же виноват в сложившейся ситуации? Игрок, который не полез читать описание способностей, или игра, которая никоим образом его туда не направила и даже не попыталась объяснить, что навыки монахини отличаются от навыков других персонажей?
К очень непопулярному продукту под названием Exorcist Fairy (рис. 4) один из игроков оставил лаконичный обзор с пальцем вниз и написал следующее: «У персонажа не хватает маны, чтобы открыть ворота». Я увидел его обзор до того, как пройти эту замечательную игрушку, и, когда я сам добрался до этих ворот, я сопоставил время в игре и точно понял, про какое место он говорит. Персонаж в Exorcist Fairy способен выпускать молнии, которые заряжают рычаги, поднимающие ворота. Чем дольше мы удерживаем кнопку, тем больше молний выпускаем и тем сильнее заряжается рычаг. Но молнии расходуют ману, и в некоторых ситуациях она успевает кончиться до того, как рычаг зарядится достаточно, чтобы открыть проход в следующую локацию.
В чем игрок не прав? Казалось бы, ситуация, в которой для открытия двери не хватает маны, в игре действительно присутствует, и выглядит это как недоработка. Но дело в том, что жанр Exorcist Fairy – это метроидвания, подразумевающая исследование большой и запутанной карты в поисках усилений для своего персонажа. Увеличение запаса маны, позволяющее выпустить достаточное количество молний, – как раз одно из таких усилений. Чтобы открыть эту злосчастную дверь, игроку нужно было вернуться на несколько локаций назад, в отмеченном на карте месте применить одну из своих способностей и подобрать предмет, увеличивающий количество маны. Тогда проблема с рычагом исчезнет, и мы сможем выпустить достаточное количество молний, чтобы открыть желанную дверь.
Но объяснила ли это игра? Нет. Как и в примере с Pascal’s Wager, авторы Exorcist Fairy не удосужились разжевывать механику, подразумевающую необходимость собирать усиления.
Если вы сели играть в шахматы с человеком, который не знает правил, именно вы будете виноваты в том, что он в итоге окажется рассержен и расстроен. Это вы не объяснили ему, как надо играть, или, что более вероятно, переоценили его игровой опыт, посчитав, что он и без вас знает обо всех правилах этой чудесной игры.
Рис. 4. Exorcist fairy.
Человек, игравший во все части Dark Souls, хорошо осведомлен о том, что огромная часть информации о правилах игры и об игровом мире зарыта во всяких меню и в описаниях предметов. Отталкиваясь от такого базового правила соулс-игр, разработчики Pascal’s Wager не сочли нужным прямым текстом объяснять все особенности управления монахиней. Их собственный игровой опыт подсказывал им, что игрок первым делом самостоятельно полезет читать описания всей экипировки и всех ее способностей. Игровой же опыт человека, не разобравшегося со способностью восстанавливать здоровье своему персонажу и оставившего негативный отзыв, явно отличался от опыта разработчиков. С таким относительно базовым правилом игры в продукты подобного жанра он был не знаком. И в этом определенно нет его вины.
Точно такая же ситуация сложилась и с Exorcist Fairy: поиск усилений, которые необходимо применить в ранее посещенных местах, – это ключевой элемент любой метроидвании. Тупики на карте в играх подобного жанра – дело самое обыкновенное, и, чтобы такой тупик преодолеть, всегда необходимо побегать по уровням в поисках новых предметов экипировки, улучшений и способностей. Автор того злосчастного обзора был лишен подобного игрового опыта и оттого счел ситуацию с воротами патовой. Разработчики же, будучи знакомыми с канонами жанра, не удосужились эти каноны лишний раз объяснить.
Таких примеров можно привести еще великое множество. Игра Rez, представляющая собой рельсовый шутер, в котором мы, двигаясь по прямой линии, отстреливаем полчища врагов, получила негативный обзор от человека, пожаловавшегося на необходимость абсурдно часто и быстро нажимать на кнопку выстрела. Однако большинство игр подобного, ныне уже устаревшего, жанра подразумевало, что игрок зажмет кнопку, выделит до десяти врагов и отпустит ее – тогда персонаж выстрелит десять раз и все выстрелы распределятся по выделенным целям. Молотить по кнопке абсолютно не обязательно: это сделает Rez очень сложным и скучным проектом, а игрока оставит недовольным.
Я играл во множество небольших независимых игр с itch.io, сделанных новичками «на коленке», и участвовал в качестве жюри в огромном количестве игровых джемов, где мне приходилось разбирать проекты, созданные людьми без опыта за неделю, а иногда и за три дня. Я люблю оригинальность и находчивость в этих играх, а также то, что от меня как игрока требуется недюжинное усилие, чтобы в них разобраться. Мозг иной раз скрипит и болит в попытке понять правила очередного непопулярного продукта. Но мало того что сами правила игрового процесса иногда превращаются в головоломку, решение которой мне приносит удовольствие, – я еще и набираюсь опыта, позволяющего мне делать уже собственные игры чуть более дружелюбными.
Основной критерий, по которому эти крошечные игры можно отнести к разряду «отвратительных» и «непроходимых», почти всегда заключается в степени их «понятности». Подход к объяснению механик у новичков очень неуклюж. Если при игре в «Ведьмака 3» трудно не разобраться, какие кнопки нажимать для бега, атаки или взаимодействия (ибо назначения этих кнопок постоянно находятся в нижнем правом углу экрана), то в играх, сделанных на джем, иной раз приходится методично простукивать по всей клавиатуре, чтобы найти задействованные в игровом процессе клавиши, а потом долго разбираться, в какой момент эти действия нужно применять.
Как же так получается, что разработчики создают нечто, что будет непонятно многим игрокам? Мы же с вами сами когда-то учились играть в игры. Самостоятельно нарабатывали игровой опыт, запоминали моменты в других проектах, вынуждавшие нас искать прохождение в интернете, иной раз злились, сидя за компьютером или игровой приставкой. Но теперь мы сами порождаем игры, которым предстоит мучить игроков, вместо того чтобы радовать их. И, что самое удивительное, мы-то сами прекрасно понимаем, как в нашу игру нужно играть, чтобы получить от нее удовольствие. Оттого вплоть до самого выхода проекта в свет мы можем не осознавать, что создали нечто, в чем невозможно разобраться.
Чтобы успеть выяснить, что ваша игра является крайне малопонятным произведением, не обязательно тянуть до выпуска: можно понять это еще на стадии зарождения первого играбельного прототипа. Но многие разработчики упускают эту возможность, демонстрируя свою игру не так, как это следует делать.
Когда у вас на руках появляется первый прототип, не стоит сразу скидывать его друзьям в переписке и ждать от них ответа. Ответ-то будет, вот только сколько бы абзацев текста ни написал ваш товарищ, он не предоставит вам и одной десятой доли информации, которую продемонстрирует запись его игрового процесса. Чтобы верно оценить критику, нужно сначала понять, КАК именно ваш друг вел себя в вашей игре.
Лучшим способом, разумеется, будет даже не видеозапись, а ваше непосредственное присутствие рядом в тот момент, когда он играет первый раз. Ни в коем случае не давайте никаких пояснительных комментариев и регулярно спрашивайте, по какой именно причине ваш товарищ принял решение действовать тем или иным способом. Поверьте, это позволит вам лучше понять ваших будущих игроков. Сбрасывание ссылки на сборку игры в каком-нибудь чате и ожидание ответной реакции к таким умопомрачительным результатам не приведет.
Разумеется, есть еще более действенный способ осознать свои недоработки – и это шоукейсы. Шоукейсы являются частью многих мероприятий – косплей-фестивалей, сходок разработчиков, различных развлекательных мероприятий. Присутствие в кругу вашего общения других разработчиков поможет вам собрать больше информации о том, где в вашем городе можно выставить игру на всеобщее обозрение. Нет никакого смысла нести туда сборку, лишенную обучения. Я не сомневаюсь, что вы сможете доходчиво объяснить любому случайному прохожему, что именно нужно делать в вашей игре, но это не имеет значения – важно, чтобы игра сама была способна донести до игрока свои правила в понятном всем виде без присутствия разработчика рядом.
При демонстрации своего продукта за ноутбуком стоит придерживаться нескольких принципов. Во-первых, ни в коем случае не говорите игроку, что ему нужно делать. Внимательно следите за ситуациями, в которых он впадает в ступор и не может найти нужного решения. Полученный опыт используйте для того, чтобы откорректировать проблемные места.
Во-вторых, поведение игрока и время его нахождения в игре гораздо важнее его слов. Однажды игрок провел в Reflection of Mine полтора часа, изучив каждый уголок моей демоверсии, но в итоге сказал, что моя игра из рук вон плоха. Другой же поиграл пять минут и высказал восторженное мнение, что Reflection of Mine – это шедевр. Разумеется, оба этих игрока меня обманули.
Поделиться книгой: