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

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

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

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

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

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

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

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

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

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

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

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