Читаем Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение полностью

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

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

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

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

Добавление всех игровых последовательностей

Есть еще один чрезвычайно важный аспект альфы, который я вам изложу. Эту технику мы разработали в Naughty Dog под руководством президента студии Эвана Уэллса, и она произвела революцию в моем отношении к созданию игр. Работая над Uncharted 2: Among Thieves, мы решили, что к альфа-майлстоуну мы не только включим все фичи игры, но и добавим все игровые последовательности, создав все уровни, пускай и в грубой форме, с плейсхолдерами и в виде блокмеша (вайтбокса/грэйбокса/блокаута).

Многие уровни Uncharted 2 уже были почти готовы к майлстоуну альфа-версии. Некоторые уровни игры были реализованы частично, некоторые – едва начаты, а некоторые – еще не созданы. Эти последние уровни – едва начатые и пока не созданные – мы быстро набросали в виде низкополигонального блокмеша, чтобы иметь представление о приблизительных длине и размере уровня. Затем мы соединили все вместе, используя систему стриминга уровней и логику повествования игры, чтобы в нее можно было сыграть от начала до конца.

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

Когда вы решаете, что сократить или изменить, обязательно обновляйте таблицу макродизайна, чтобы отслеживать все принятые вами решения. Начиная с Uncharted 2, я стремился сделать все игровые последовательности на стадии альфа, и это не раз помогало разработчикам получить представление о реальном размере игры и понять, стоит ли масштабироваться дальше.

Кроме того, чтобы игровые последовательности считались завершенными в альфа-версии, весь интерфейс, меню и экраны интерфейса должны быть на месте хотя бы с плейсхолдерами изображений и аудиоконтента (включая экраны логотипа, титульный экран, экраны настроек, экраны паузы и экраны сохранения/загрузки). Все эти элементы должны быть соединены вместе так, чтобы игрок мог перемещаться от одной части игры к другой точно так же, как он мог бы это сделать в готовой игре. Стартовые логотипы должны вести к титульному экрану, который в свою очередь ведет к игре или экрану настроек, и так далее.

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

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

Исторические информационные системы: теория и практика
Исторические информационные системы: теория и практика

Исторические, или историко-ориентированные, информационные системы – значимый элемент информационной среды гуманитарных наук. Его выделение связано с развитием исторической информатики и историко-ориентированного подхода, формированием информационной среды, практикой создания исторических ресурсов.Книга содержит результаты исследования теоретических и прикладных проблем создания и внедрения историко-ориентированных информационных систем. Это первое комплексное исследование по данной тематике. Одни проблемы в книге рассматриваются впервые, другие – хотя и находили ранее отражение в литературе, но не изучались специально.Издание адресовано историкам, специалистам в области цифровой истории и цифровых гуманитарных наук, а также разработчикам цифровых ресурсов, содержащих исторический контент или ориентированных на использование в исторических исследованиях и образовании.В формате PDF A4 сохранен издательский макет.

Динара Амировна Гагарина , Надежда Георгиевна Поврозник , Сергей Иванович Корниенко

Зарубежная компьютерная, околокомпьютерная литература / Учебная и научная литература / Образование и наука