Читаем Ошибки разработчиков видеоигр. От идеи до провала полностью

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

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

Смерть – далеко не единственное, что выдергивает игрока из потока путем остановки времени. Долгие загрузки между экранами или утомительные однообразные анимации оказывают такой же эффект. Оптимизация проектов – обычно не самая сильная сторона независимых разработчиков, пришедших в нашу индустрию из отраслей, не связанных с программированием. Иной раз независимый проект вынуждает вспомнить эпоху PlayStation 2, когда времени между загрузками локаций хватало, чтобы сходить в туалет, налить чаю или кому-нибудь позвонить. В играх, плотно работающих с состоянием потока, загрузок практически нет: Journey создает впечатление путешествия по бесшовному миру, а не по разбитой на отдельные секции игры. Нет видимых переходов между локациями и в Gris – игре, которая тоже прекрасно удерживает игроков в потоке.

В играх, умело удерживающих игрока в потоке, иной раз интерфейс отсутствует целиком: никакой статичной информации не отображается ни в Journey, ни в Gris. Многие разработчики экспериментируют с интеграцией интерфейсов на саму сцену с персонажем. В Dead Space индикатор уровня здоровья расположен на спине главного героя, а в старенькой игре Boogerman у игрока при получении урона менялся цвет плаща. Некоторые ужастики экспериментируют с демонстрацией уровня здоровья через анимации протагониста, но этот метод требует огромного количества ресурсов и, будем честны, не всегда работает: естественно, состояние, когда персонаж уже при смерти, читается игроком на ура – герой сгибается, хромает и истекает кровью, а вот доходчиво продемонстрировать таким образом «легкое ранение» не так уж и просто.

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

Бесконечные загрузки

Если загрузки становятся для вас проблемой при разработке, то способы ее устранения я рекомендую подсмотреть в играх той эпохи, когда оперативная память игровых систем и скорость чтения дисков не позволяли прогружать массивные объемы данных. В ужастике Fatal Frame (известном на Западе как Project Zero) перемещение между разными помещениями было оформлено следующим образом: главная героиня подходила к двери, и, когда игрок нажимал на кнопку «Открыть», камера приближалась к героине – таким образом скрывалось исчезновение выгружаемых из памяти текстур и объектов в комнате. После этого героиня лишь слегка приоткрывала дверь (что отлично работало на атмосферу ужасов) и робко топталась перед ней до тех пор, пока не прогружалась следующая локация. Конечно, смотреть на одну и ту же анимацию каждый раз может быть утомительно, но в контексте Fatal Frame, когда постоянно казалось, что из-за приоткрытой двери на нас вот-вот выпрыгнет уродливая нечисть, этот трюк работал. Более того, иногда действительно кто-то выпрыгивал.

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT