Почему прототипирование очень важно

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

Зацените кадры из игры. Можете ли вы сказать, что здесь происходит? (Вероятно, лучше включить HD режим и запустить в полноэкранном режиме для наглядности).

Вначале видео можно заметить двух заряженных (с огненным мечом) и двух незаряженных врагов. Но в один прекрасный момент один из заряженных врагов потратил весь свой колдовский огонь и «разрядился».

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

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

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

Кроме того, как показать анимацию «Колдовский огонь исчерпан» после последней заряженной атаки? Технически, враг тратит последние силы на атаку, так что после этого ничего не остаётся, и поэтому нет никакого основания или предпосылок для анимации. И нельзя предполагать, что игрок будет вести счёт того, сколько заряженных атак враг уже потратил и сколько зарядов осталось.

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

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

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

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

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

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

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

Если бы только Астронавты прислушались бы к опыту, которым дизайнеры Bungie поделились в своей презентации на GDC в 2002 о Halo AI

В fps Subtle означает Невидимый

В fps Subtle означает Невидимый

Обратите внимание, что даже если технически фича не случайна, она может казаться случайной игроку

Обратите внимание, что даже если технически фича не случайна, она может казаться случайной игроку

…они возможно смогли бы избежать этой проблемы уже на этапе проектирования. Но эй, урок усвоен.

Вопрос недели

Команда ещё не определилась с окончательным решением. На данный момент они совмещают полное риалтайм освещение вблизи с запечённым на расстоянии и красивым невидимым переходом между ними. UE4!