В ситуации сжатых временных рамок на что только не идут разработчики, чтобы выпустить игру вовремя. Специалисты из игровой студии Skill Rush собрали самые неудачные программные решения в геймдеве, которые очень не советуют повторять.
У каждой студии бывает такой период, когда сроки поджимают, специалисты устали работать, а проблемы сыплются как снег на голову - настает время принятия нестандартных решений. Когда нужно любой ценой закончить проект, на кону стоят все вложенные деньги, то фантазия начинает работать превосходно. Мы вместе со специалистами из игровой студии Skill Rush решили изучить несколько потрясающих примеров таких решений. Компании, которые их делали, могут не гордиться своими исправлениями, но, по нашему мнению, такой работой вполне можно хвастаться: они смогли выпустить хорошую игру, сделали это в срок, ничего не испортили, а пользователи даже ничего не заметили. Давайте насладимся их изобретательностью и конечно же поучимся на чужих ошибках. Наше самое основное пожелание — это чтобы все разработчики выпускали полностью готовые, работающие игры – ровно в срок!
Проект Super Time Force и его севшая внезапно батарейка
Может быть это совершенно незаметно на первый взгляд, но проект Super Time Force ели поместился в пределы памяти Xbox 360. Из-за наличия функции перемотки времени необходимо было хранить всю информацию про каждый активный объект уровня в течение всей длительности процесса перематывания шкалы времени. Любой новый игрок, любой враг, любой взрыв или даже просто куча мусора влияли на память перемотки и вся эта проблема очень усложняла процесс разработки.
Когда команда уже дошла до последнего этапа сертификации после того, как отладила идеальный баланс каждого уровня, буфер перемотки, то именно в этот момент получила от отдела контроля отчет по новой ошибке: «Попробуйте начать любой уровень. Как можно быстрее понажимайте все кнопки на контроллерах в течение двух минут. Повторите это 20 раз с перемоткой назад и память будет исчерпана». То есть быстрое нажатие кнопок съедало памяти перемотки намного быстрее чем это ожидалось от ввода игрока. Вместо того чтобы вернуться в самое начало и полностью изменить баланс файлов уровня и размер буфера, было решено остановиться на более простом варианте: сделать так, чтобы система распознавала несколько длинных интервалов неразумно быстрого нажатия кнопки и после этого самоуничтожала пользователя, перебросив его обратно на начало уровня. То есть разработчики притворились, что игрок при яростном нажатии на кнопки случайно включал функцию перемотки, таким образом баг стал фичей. Через несколько дней команда получила еще один отчет об ошибке.
Отдел качества прислал следующее сообщение: «начните 199Х уровень 2, пройдите его до конца при этом взрывая все подряд и оставляя после себя как можно больше обломков, при этом не забывайте непрерывно стрелять из пулемета пока ваше время не закончится. Перемотайте назад и повторить так еще 20 раз – память будет исчерпана». Предел памяти перемотки мог быть достигнут только в очень редком случае во время появления на этом конкретном уровне определенного количества пуль, взрывов, которые создают обломки. Чтобы не менять баланс файлов в уровне решено было опять прибегнуть к самой простой идее: когда проект начинает приближаться к пределам памяти перемотки, он автоматически становится на паузу и на экран выводится значок: «низкий заряд батареи» и игрок обратно отправляется в меню выбора уровня. На самом деле ничего у контроллера не разрядилось. Разработчики никому ничего не объяснили, но отдел контроля качества решил принять это исправление и осуществить сертификацию проекта.
Проблема с бе́лками
Самый неудачный трюк в проекте Titan Quest – это управление скриптингами событий. В игре технология квестов, событий обладала серьезными проблемами – после того как срабатывали действия не было совершенно никаких способов его отложить. Поэтому если пользователь хотел, чтобы что-то произошло через 5 секунд после того, как его игрок побежал, то эта задержка не могла быть установлена. Действие всегда было максимально мгновенным. Когда наступил конец разработки уже было достаточно сложно внести какие-то дополнительные функции, разработчики и так пытались изо всех сил успеть сдать проект в срок. Решение проблемы зашло в тупик, команда обратилась в отдел по работе над качеством, и эти специалисты стали помогать над скриптингом. Оказалось, что можно использовать один из способов отложенного срабатывания событий при помощи изменения длительности анимации.
Для работы взяли белок, они в игре были существами окружающей среды, и их стали использовать в качестве таймера анимации – животные были механизмом расчета таймингов по умолчанию. При помощи такого творческого подхода вся проблема была решена.
Фобия рекламы
В последней версии одного из проектов, не будем называть его, появилась новая функция, которая давала игрокам внутриигровую валюту за то, что они смотрят видео рекламу, что также повышало доходы разработчиков. После выпуска игры мы сразу обнаружили что видеореклама запрашивается неправильно, из-за чего за игровую сессию может воспроизвестись только одно видео, что стало причиной некоторых неприятностей. В игре использовалась инфраструктура на стороне сервера для выполнения действий в разных случаях, и она позволила немного расширить функционал после выпуска. Система проверяла правила: если эти правила выполнялись, то запускала заданные действия.
Сами правила не оценивались по рефлексии. Например, при правиле:
VideoAds.IsVideoAvailable = true при помощи рефлексии вызывалось именно это свойство и конкретное действия выполнялось под него, если свойство имело значение true. К большому счастью разработчиков, такую систему довольно просто взломать, поэтому они добавили новое правило: VideoAds.RefreshVideos = true и оно никогда не было равно true – поэтому оно и не выполнялось, но вызывало код, который обновлял видео, что позволяло заставить систему использовать достаточно простой механизм исполнения удаленного кода. Проблема была решена.
Дальше с этим же проектом случилась еще одна проблема, когда началась работа над обновлением для игры под Андроид. За две недели до его выхода отдел качества присылает свой отзыв. В нем было написано, что на некоторых случайных устройствах после воспроизведения катсцены начинается сбой. Разработчики потратили целую неделю чтобы изолировать ошибку или выяснить вообще причину ее появления: спойлер причину так и не нашли. Но было обнаружено что при нажатии кнопки назад, чтобы пропустить видео - сбой не происходит. Небольшой трюк состоял в том, чтобы поставить в катсцену таймер за несколько секунд до завершения сцены симулировать нажатие кнопки назад. Первоначально это использовалось как временное решение проблемы, но как мы понимаем нет ничего более постоянного, чем временное. Прошло пол года с момента решения этой проблемы и до сих пор код изменен таким образом.
Проблема неба в черном льде
Во время работы над проектом Black Ice его разработчики хотели создать небо, которое выглядело бы как бесконечная комната, но если расположить несколько сотен объектов, то это значительно сказывалось на производительности, поэтому было принято решение реализовывать идею при помощи частиц. Сначала все выглядело довольно просто: необходимо было нарисовать скрипт, чтобы расположить его в мире, но именно в этот момент возникла проблема – частицы начинали исчезать, когда игрок отворачивался от точки начала координат мира. Необходимо было потратить еще несколько дней на то, чтобы понять, что специальная система в Unity отключала все частицы, когда невидимый эмиттер частиц находился за пределами обзора камеры. Проблема была решена: эмиттер был присоединен к лицу игрока, но где-то на шесть дюймов ниже. Таким образом у игрока не было возможности отвернуться от эмиттера в какую сторону он бы не смотрел. Нужно было изменить испускание частиц опираясь на положение в мире и постоянно обновлять их при движении игрока, но такая идея все равно сработала.
Либо решение, либо увольнение
Во время работы в студии Backbone Entertainment случилась довольно напряженная ситуация, когда команда разработчиков работала над проектом по переносу аркадных игр Midway на PSN. Это было только начало эпохи PS3. Студия раньше выпустила игры в XBox Live Arcade, но разработаны были они были не очень, поэтому проект нужно было буквально за пару дней свернуть. Специалисты приняли решение реализовать Direct X на PS3 и последние несколько недель работы над проектом потратить на сокрытие следов. Клиент очень боялся за сохранность своей разработки, поэтому передал некоторое количество DLL только для целевых консольных платформ, таким образом библиотека оказалась настоящим черным ящиков Пандоры. Никто не хотел давать никаких библиотек для ПК, как бы специалисты не просили о них. Весь фронтэнд игры выполнялся на PC, в самом коде была только заготовка для движка, которой бы хватило, чтобы запустить геймплей. Проблема заключалась в том, что невозможно было протестировать работу настоящей игры на PC и многих такое положение вещей не устраивало.
Таким образом был пройден весь цикл разработки для PS3/X360. Потом для следующей интеграции перешли на Xbox One и PS4, получив для них обновленную версию библиотек движка, но по-прежнему никто не дал версию для PC, что значительно усложняло работу, особенно для PS4. Но случилось уникальное явление, библиотека для Xbox One на самом деле оказалась довольно рабочим 64-битным кодом для PC и ее можно было довольно просто подключить к исполняемому файлу Windows. Для этого нужно было всего лишь обладать ПК с новым ЦП, который содержит те же расширения наборов инструкций, что и ЦП на Xbox. Разработчики безумно стали радоваться, так как систему удалось наконец-то заставить работать. Но на следующем цикле, когда делали версию для Steam, клиенты смогли предоставить настоящий библиотеку для ПК, поэтому все выдумки оказались бесполезными.
Звук все решает
Работая над проектом Mega Man Legacy Collection для 3DS, была обнаружена настоящая проблема со звуком, которую невозможно было отследить. Любой звук, который воспроизводился первым либо искажался, либо проигрывался в корне неверно. Слой воспроизведения звука команда разработчиков писала самостоятельно, он был основан на звуковом API Nintendo для 3DS. Система воспроизведения должна была поддерживать постоянное потоковое проигрывание таких вещей как фоновая музыка, эмуляция звука и небольших единоразовых звуков для определенных действий. Каждый из звуковых каналов передавал собой определенную структуру данных, в которых содержались разные флаги информации для отслеживания текущего состояния. Одним из флагов был определяющий элемент, который показывал, является ли канал активным или воспроизводящимcя. В официальных документах было описано что флаг имеет значение true, если канал что-либо воспроизводит и false в противном случае.
Вот именно с этим моментом возникло несколько проблем, причины которых не удавалось найти из-за отсутствия времени у разработчиков. В девяти из 10 случаев при запуске игры мелодия, которая сопровождала логотип студии, искажалась совершенно по-разному – ее либо заедало, либо вообще не воспроизводило. Это был самый первый звук в игре, и мы поняли, что ошибка находится именно в нем, так как все последующие звуки играли без каких-либо проблем. Когда мы начали разбираться и копаться глубоко, то выяснили, что в некоторых случаях этот флаг «воспроизведения» имел значение true даже тогда, когда ничего не проигрывалась. Было совершенно очевидно, что проект в таком виде выпускать нельзя, а все уже идеи и энтузиазм закончился. Так каким образом решилась проблема? При загрузке игры перед тем как воспроизвести эту мелодию проигрывали секунду тишины и вот именно в таком состоянии был выпущен проект.
Мы привели несколько самых разнообразных решений, к которым прибегали разработчики в ситуации нехватки времени. Используйте свою фантазию, если вам необходимо незамедлительно убрать баг в проекте.