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

сотрудничество с заказчиком важнее согласования условий контракта;

готовность к изменениям важнее следования первоначальному плану[88].

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

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

Максимизация несделанной работы

В рамках концентрической разработки мы постоянно обсуждаем то, что наиболее важно для дизайна игры на сегодня – это очень по Agile. Это не только помогает улучшить проект, но и сводит к минимуму количество сверхурочной работы, в противном случае неизбежной, и помогает управлять проектом без стресса. Как сказала моя коллега по программе USC Games, UX-дизайнер и преподаватель Маргарет Мозер: «Частый пересмотр приоритетов необходим для максимизации несделанной работы (мой любимый принцип Agile-разработки)»[89].

Слова Маргарет отсылают к одному из двенадцати принципов, лежащих в основе манифеста, а именно: «Простота как искусство не делать лишней работы очень важна». Эта концепция «лишней работы» не так проста: разве мы не хотим реализовать максимум в своем проекте? Здесь речь о том, что мы должны сосредоточиться на работе, которую нужно реализовать в соответствии с целями нашего проекта, в частности создать целевой опыт. И мы должны понимать, когда что-то никак не способствует достижению этих целей. Если какая-то идея не помогает нам, это лишняя работа. Можно обобщить этот принцип Agile-разработки как «работайте не усерднее, а рациональнее» (англ. work smarter, not harder).

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

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

Темпы концентрической разработки

Работая концентрически, вам приходится двигаться помедленнее, и поначалу это надоедает. Вы проделываете большую детальную работу над скучными основными механиками, в то время как хотите начать играть с увлекательными второстепенными механиками. Основные механики настолько просты – несомненно, они будут работать!

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

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

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

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

Глава 14

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

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