Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Билд вертикального среза
Вертикальный срез предоставляется в виде билда (глава 5). К этому моменту вертикальный срез должен быть проверен на серьезные ошибки и другие технические проблемы: мы должны полировать вертикальный срез не только в рамках нашего дизайна, но и в плане стабильности игры. Вертикальный срез в любом случае не будет полностью избавлен от багов, но будет крайне неловко, если игра начнет ломаться во время ее презентации группе спонсоров или заинтересованных сторон. Нужно выкроить время в работе над вертикальным срезом, чтобы проверить работоспособность игры и кода. Это соответствует принципам концентрической разработки, которую мы только что обсудили.
Любые лишние ассеты, не используемые игрой, но присутствующие в проектной папке, должны быть исключены из билда, чтобы уменьшить его размер. Иногда это совсем не просто и может потребовать изучения новых технических аспектов игрового движка. Но этим стоит заняться к моменту появления вертикального среза, чтобы в дальнейшем ориентироваться на оптимизацию, без которой не обходится грамотный процесс создания игр. Особенно важно этому научиться ближе к концу проекта, когда будет очень важно уменьшить размер билда.
Подготовьте дополнительные материалы
Если вы создали свой вертикальный срез концентрически, его прохождение может не занять много времени, и это нормально. Качество важнее количества. Часто бывает трудно создать идеальный вертикальный срез, в котором есть все основные элементы игры, воспроизводимые и доработанные. Независимо от того, связано ли это с масштабом дизайна вашей игры или у вас просто не хватило времени, вы можете подготовить дополнительные материалы, которые презентуют игру вместе с вертикальным срезом. Это могут быть концепт-арт, видеоролики и документация. Представьте их в красивом оформлении, чтобы продемонстрировать то, что не было показано в вертикальном срезе. Это можно считать упражнением в профессионализме – вы хотите ясно представлять свой проект и производить хорошее впечатление.
Понимание скоупа через создание вертикального среза
Не стоит игнорировать то, что мы узнаем о нужном нам времени для создания чего-либо. Создание основ игры в условиях ограниченного количества времени (см. главу 11) позволяет серьезно взглянуть на содержание нашего проекта. Сколько контента мы планируем реализовать в целом? Реалистично ли это, основываясь на том, сколько итераций нам требуется, чтобы достичь желаемого уровня качества? Не пора ли уже убрать некоторые элементы из дизайна и сосредоточиться на основных элементах игры для реализации целей проекта новыми инновационными способами? В следующих нескольких главах мы рассмотрим, как составить реалистичный план игры, которую мы сможем создать за то время, которое выделено на продакшен.
Плейтест вертикального среза
Как только мы закончим вертикальный срез, его надо будет проверить плейтестами. Проведите плейтест по крайней мере с семью участниками, пользуясь рекомендациями и методами, которые я изложил в главе 12. Соберите всю возможную информацию из игрового теста, делая заметки на основе ваших наблюдений и беседуя с тестерами. Оцените обратную связь и проведите необходимые итерации.
Фокус-тест названия игры и ключевого арта
Конец этапа препродакшена – хорошее время, чтобы выяснить, как мы могли бы найти потенциальную аудиторию игры. Мы можем сделать это, просто проведя фокус-тест и выяснив, какое название лучше подойдет для игры и как пользователи отнесутся к первому ключевому арту[90]. (Ключевой арт, или сигнатурный арт, – это одно изображение, которое передает много информации о вашей игре.) Если вы захотите это сделать, то можете найти подробные инструкции на сайте этой книги.
* * *Отличная работа! Вы выпустили (или находитесь на пути к этому) вертикальный срез – одну из самых важных работ, благодаря которой мы можем определить дизайн игры. В следующей главе мы прервем наше обсуждение продакшена и поговорим о серьезной проблеме, с которой сталкивается большинство разработчиков игр в какой-то момент своей карьеры: кранче.
Глава 15
Борьба с кранчем
Кранч, как вы наверняка знаете, – это термин, которым разработчики называют период сверхурочной работы, необходимой для достижения майлстоуна или завершения проекта. Кранч обычно включает в себя работу по шесть или семь дней в неделю. Иногда команда готова войти в режим кранча всего на несколько недель, но в конечном счете застревает в нем на долгие месяцы или даже годы.
Я не горжусь этим, но за время работы в игровой индустрии мне пришлось пережить несколько кранчей, и я воочию убедился, какие потери он может принести. Затянувшийся кранч очень вреден для здоровья отдельных людей, команд и организаций, он может нанести ущерб как физическому, так и психическому здоровью разработчиков, а затем привести к тому, что члены команды теряют боевой дух, перестают общаться и в итоге расходятся. В долгосрочной перспективе это может привести к краху студий и компаний.
Не поймите меня неправильно: мне нравится усердно трудиться, и я считаю, что для превосходного результата обычно требуются дополнительные усилия. Но есть разница между здоровой продолжительностью периода переработки, когда для достижения цели или повышения качества приходится чуть больше и дольше трудиться, и неконтролируемым переутомлением, ставшим бичом игровой индустрии. Я уверен, что кранч – это симптом нерационализированного подхода к процессу разработки, и эта книга предназначена для того, чтобы помочь разработчикам игр свести к минимуму количество неконтролируемого переутомления и при этом максимально повысить качество игры.
Контроль скоупа проекта на всех этапах производственного процесса игры дает нам частичное решение проблемы кранча, а в следующих главах мы рассмотрим написание так называемого макродизайна игры для правильного планирования проекта. Еще одно
