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

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

3.1.9. Альфа

Цель альфа-версии – полнота контента. Это означает, что на уровне должно быть реализовано все, что было задумано. В понятие контента входит, например, размещение противников и патрулей, айдл-анимации, подсвечивание важных точек, точки обзора, укрытия, художественные ассеты, геймплейные фичи (хотя бы в виде временных кат-сцен) и элементы повествования. Альтернативные пути, второстепенные цели, более серьезные краевые случаи и, особенно, известные способы сломать прохождение – все это теперь должно быть учтено. По сути, уровень должен быть готов к внешнему тестированию.^[22]

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

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

Имеет смысл провести первые тесты производительности, так как все основные требующие затрат производительности компоненты к этому времени должны быть внедрены.

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

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

3.1.10. Бета

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

Чтобы завершить этот этап, игра проходит через несколько итераций на основе отзывов об альфа-версии. Отзывы эти поступают из различных внутренних, а иногда и внешних источников, а также от плейтестеров. Объем тестирования и исправлений постоянно увеличивается, чтобы устранить как можно больше ошибок, особенно связанных с прохождением. Особое внимание уделяется всему, что могло бы дать игре и уровням более низкий рейтинг или вызвать негативные отзывы. Дорабатывается и отлаживается все больше элементов контента и функций. Дополнительное внимание уделяется балансу, потому что после альфа-версии все компоненты находятся на своих местах, и с этого момента в идеале не должно быть масштабных изменений. К сожалению, нередко приходится вносить более значительные локальные изменения, потому что целиком оценить игру можно только после альфа-версии. Крупные ААА-продукты настолько сложны, что определенная обратная связь возможна только после того, как вы увидите общую картину.^[23]

Еще один важный аспект бета-версии – производительность и соответствие требованиям внешних разработчиков. Например, бета-версия должна работать стабильно на всех платформах, с заданной частотой кадров, с выделенной для нее памятью, без вылетов и без долгих загрузок уровней. Соответствие требованиям третьих сторон, таких как Microsoft, Sony или Nintendo, требует от игр соблюдения определенных стандартов, таких как максимальное время загрузки уровней, минимальная частота кадров или качество онлайн-соединения. В этой книге мы не будем вдаваться в такие подробности, потому что это больше относится к продакшену, технологиям, контролю качества и менеджменту. Но левел-дизайнеры должны знать о возможных последствиях. Требования для конкретных платформ и их поколений меняются, так что важно оставаться в курсе событий.

На этапе подготовки к бета-версии удаление каких-то функций или больших сегментов уровней может привести к серьезным проблемам в продакшене. Часто бывает так, что исправить последствия удаления определенного элемента уже хорошо проработанной целостной игры труднее, чем оставить и, возможно, как-то замаскировать этот элемент, чтобы он не слишком выделялся. Другими словами, задумывайтесь о фичекате как можно раньше.^[24]

3.1.11. Завершение^[25]

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

Любое предложение, особенно со стороны директоров, должно быть одобрено производственным отделом с оценкой риска со стороны технических специалистов.

Для левел-дизайнеров это значит, что у них становится все меньше задач, тогда как количество обнаруженных багов для исправления увеличивается из-за усиленного тестирования. Переход к этому этапу обычно осуществляется плавно, и в разных компаниях к нему относятся по-разному, но он необходим. Завершение может восприниматься болезненно, особенно если до сих пор появляются кое-какие замечательные идеи. Поэтому большинству креативных директоров важно постепенно отстраниться от проекта еще до его окончания. Отход от проекта со стороны большинства разработчиков ближе к бета-версии – это нормальное явление, и до конца его доводят лишь самые надежные и технически ориентированные коллеги, сосредоточенные исключительно на исправлении ошибок, чтобы не создавать новых проблем.^[26]

3.1.12. Период до «золота»

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

Поэтому обычно на этом этапе над уровнями работают только старшие левел-дизайнеры или технические левел-дизайнеры. Разумеется, основное внимание уделяется только багам, причем в зависимости от их количества и степени риска, даже не мелким. Процесс нарастает, пока у вас не закончится время. Ближе к концу исправляются только самые критические ошибки; главное – перестать суетиться и сосредоточиться на выходе игры. Часто многие разработчики вместе с этим уже параллельно работают над патчем первого дня.^[27]

3.1.13. Заключительные слова

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

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

3.2. Темп работы и усилий

3.2.1. Введение

Создание игры – дело не одного года или, по крайней мере, не одного месяца, и поэтому очень важно соблюдать определенный темп. Разработка игр – это своего рода марафон (или даже несколько марафонов), а не спринт.

ИЛЛЮСТРАЦИЯ 3.1. Размер и продолжительность стадий показаны не в реальном масштабе! Схема призвана лишь дать представление о том, какие этапы следуют друг за другом и как они связаны между собой^[28]

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

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

3.2.2. Когда следует напрягаться и когда не следует

3.2.2.1. Предпосылки

Одно из ключевых различий между опытным и младшим разработчиком заключается в том, что опытный разработчик, как правило, лучше знает, когда стоит напрягаться, а когда нет. Опытные разработчики обычно понимают, когда дополнительные усилия будут напрасными, а когда окупятся, потому что они уже прошли через несколько производственных циклов. Чтобы было понятно, я не имею в виду длительные периоды переработок, или «кранча» (подробнее об этом написано ниже). Я имею в виду те случаи, когда приходится вкладывать дополнительные силы, концентрироваться, посвящать себя работе, сокращать перерывы и, возможно, задерживаться чуть дольше, чтобы закончить текущую задачу.^[29]