Ошибки разработчиков видеоигр. От идеи до провала

Грис Слава

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

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

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

Самозванцы

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

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

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

Модули

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

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

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

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

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

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

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

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

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

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

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

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