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

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

* * *

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

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

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

Глава 14

Артефакт препродакшена – вертикальный срез

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

Билд вертикального среза

Вертикальный срез предоставляется в виде билда (глава 5). К этому моменту вертикальный срез должен быть проверен на серьезные ошибки и другие технические проблемы: мы должны полировать вертикальный срез не только в рамках нашего дизайна, но и в плане стабильности игры. Вертикальный срез в любом случае не будет полностью избавлен от багов, но будет крайне неловко, если игра начнет ломаться во время ее презентации группе спонсоров или заинтересованных сторон. Нужно выкроить время в работе над вертикальным срезом, чтобы проверить работоспособность игры и кода. Это соответствует принципам концентрической разработки, которую мы только что обсудили.

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

Подготовьте дополнительные материалы