Kitobni o'qish: «Ошибки разработчиков видеоигр. От идеи до провала», sahifa 3

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

Расширение проекта

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

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

Интеграция новых элементов в ходе масштабирования проекта будет проходить всё медленнее и медленнее. Это необходимо учитывать во время планирования. Разработчики не просто так шутят, что после выполнения проекта на 99 % остается сделать еще 99 %.

Самопрезентация

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

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

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

Но что более важно: эту глупую фразу чуть не написало моё эго.

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

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

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

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

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

Планирование никогда не должно быть частью самопрезентации.

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

Ошибка 4
Браться за непосильную ношу

RPG в открытом мире

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

Разумеется, действительность показывает, что крошечные игры весьма редко становятся успешными у массового пользователя. Столь грустное наблюдение лишь подталкивает к тому, чтобы бросить все силы на воплощение чего-то массивного. Но игры, подобные A Short Hike или Gris, которые можно пройти за два часа и в которых не наблюдается обилия и многообразия механик, вполне имеют право на существование и могут найти своего игрока. Как бы вам ни хотелось занять нишу рядом с Red Dead Redemption, стартовать с середины марафона – не лучшая идея. Покорение таких вершин почти невозможно без предварительной подготовки.

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

Каждый из нас явно встает на путь разработчика видеоигр из любви к этому виду искусства. Разработчики вырастают из игроков, а статистика показывает, что большинство игроков уделяют внимание крупным и высокобюджетным проектам: Dota 2, Fortnite или, например, The Last of Us. Любовь к играм такого масштаба подталкивает к стремлению занять нишу рядом с ними. Под вдохновением от пятой части GTA вы едва ли будете ощущать причастность к горячо любимой вами индустрии видеоигр, разрабатывая линейный платформер или визуальную новеллу. Я настойчиво рекомендую вам попытаться проникнуться небольшими и нишевыми играми: в их великолепном многообразии наверняка притаился рубин, ограненный специально под ваш вкус. Испытав теплые чувства по отношению к небольшому проекту, вы с большей легкостью сможете примириться с тем, что на протяжении первых лет в индустрии разработки видеоигр вам предстоит создавать лишь нечто подобное. Вам нужно осознать, что быть частью даже этой стороны индустрии не так уж и плохо. Возможно, вам, как и мне, даже захочется на этой стороне остаться.

Прячущая рука

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

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

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

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

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

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

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

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

Самозванцы

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

При работе над Reflection of Mine я преодолел препятствия, скрытые от меня «прячущей рукой», и вошел в 22 % счастливчиков именно из-за этого синдрома: я понятия не имел о том, что мне было по силам, и принял за тупиковую ситуацию самый обычный рабочий момент.

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

Модули

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

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

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

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

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

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

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

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

Вовлеченность

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

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

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

Рис. 3. Часть исходного кода к игре VVVVV. Terry Cavanagh, 2010

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

Создание игры 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, я стараюсь не стыдиться своих ошибок: я вижу все огрехи в игровом дизайне, все ошибки в анимациях, и это ви́дение делает меня… счастливым. В тот момент, когда я создавал тот или иной «сломанный» элемент, я не обладал достаточными компетенциями, чтобы сделать всё правильно. Однако сейчас, спустя несколько лет, я вижу места, где ошибался. Это означает, что я вырос как специалист. Нахождение каждой новой ошибки – это очередная ступень, которая позволяет мне подняться выше. Я люблю находить свои ошибки и рекомендую вам проникнуться этой же страстью, отбросив предубеждения о том, что ошибаться – стыдно.