Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Эндрю любит повторять, что людям следует совершать ошибки как можно быстрее. Если в ходе битвы вы оказываетесь перед двумя холмами и не знаете, какой из них атаковать, – говорит он, – правильным будет выбрать любой холм как можно быстрее. Если вы поймете, что ошиблись, развернитесь и атакуйте другой. В этом сценарии единственный неприемлемый вариант – это пробежать между холмами[85].
Даже если мы «выберем не тот холм» и в итоге нам придется отказаться от какой-то части работы, концентрическая разработка гарантирует, что наш неверный выбор раскроет нам факты о проекте и мы не потратим время зря.
Переход к концентрической разработке
На этапе идеации мы обычно работаем грубо, быстро и грязно, создавая прототипы, чтобы проверить рабочие идеи для нашей игры. Помните, я подчеркивал, что на первом этапе у нас нет цели сделать демоверсию игры: мы просто тестируем отдельные концепции.
Однако в процессе разработки игр, описанном в этой книге, – при завершении формирования идей и в начале препродакшена – мы переходим к концентрической разработке, и этот переход может показаться непростым. Ведь, по сути, мы меняем наше мышление и наш практический подход к игре почти в одночасье.
Чтобы облегчить переход, можно сделать следующее: ближе к концу этапа идеации попробуйте отполировать ваши последние прототипы. Один из прототипов наверняка будет успешнее прочих, и его доработка (и, возможно, включение элементов из других успешных прототипов) поможет вам плавно перейти к концентрической разработке вертикального среза.
Концентрическая разработка и вертикальный срез
Я надеюсь, что теперь вы сами понимаете, как концентрическая разработка поддерживает наш общий прогресс к концу этапа препродакшена, когда должен быть готов вертикальный срез. Если мы будем работать таким образом, у нас всегда будет игра, состоящая из законченных (или почти законченных) фичей, которую всегда можно запустить, которая великолепно звучит и выглядит и которую мы можем легко протестировать.
Если к дате, когда мы планировали завершить вертикальный срез, все наши механики собраны лишь наполовину и не завершены с точки зрения внешнего вида и звука, придется пропустить майлстоун и пытаться впопыхах слепить что-то хорошее из имеющегося беспорядка. Если мы будем работать концентрически, к дате представления вертикального среза все, что нам удалось сделать, будет хорошо работать и даст нам прочную основу для дальнейшей разработки на этапе продакшена.
Это очень похоже на то, как мы создали первые три игры Uncharted. Мы начали создавать вертикальный срез со списка фич, которые мы хотели реализовать. Некоторые из них получились быстро, некоторые заняли больше времени, чем мы ожидали. В конце этапа препродакшена нам пришлось отложить некоторые наши идеи из-за нехватки времени. Но поскольку мы работали концентрически, все, что мы создали, сошлось воедино, дав нам основу для хорошей игры. Идеи, которые мы не использовали, отправлялись на полку для реализации в следующих проектах.
Таким образом, концентрическая разработка избавляет нас от необходимости переживать напряженный процесс объединения всего вместе в самом конце. Меньше стресса – лучше физическое и психическое здоровье разработчиков нашей команды, а значит, и наша игра с гораздо большей вероятностью будет отличного качества.
Концентрическая разработка полезна не только во время препродакшена, этот подход ценен на протяжении всего процесса продакшена – следующего этапа проекта – и будет поддерживать нас по мере продвижения к этапу альфа-версии, когда игра «завершена с точки зрения фичей» (англ. feature complete), и этапу бета-версии, когда она «завершена с точки зрения контента» (англ. content complete). Об этом мы подробнее поговорим в следующих главах.
Концентрическая разработка и Agile
Когда я беседовал с Джоном Спинэйлом в 2002 году, концентрическая разработка казалась чем-то радикальным в кругах разработчиков игр. Возможно, виной тому было влияние быстрого прототипирования – «делайте все быстро, прототип должен просто функционировать, оставьте его грубым и незаконченным!» (философия, ценная на этапе формирования идей). Понять ценность перехода к концентрической разработке на этапе препродакшена было довольно сложно.
Однако, хотя этот подход не всегда называется концентрической разработкой (многие работают таким методом, никак его не называя), его использует все больше разработчиков, и он получил гораздо более широкое распространение с появлением таких подходов к разработке, как Метод Марка Черни и Agile-разработка (также известная как гибкая методология разработки).
Возможно, вы уже кое-что знаете об Agile-разработке, поскольку она используется многими разработчиками игр и программного обеспечения по всему миру. Как и Метод, Agile-разработка была прогрессивной реакцией на идеи конвейерной сборки, воплощенные в каскадном подходе (водопад) к созданию программного обеспечения. Эта методология возникла благодаря другим процессам, таким как быстрая разработка приложений в 1970‑х и 1980‑х годах и рациональный унифицированный процесс в 1990‑х[86]. Agile-разработка – это подход к разработке программного обеспечения, при котором дизайн создаваемого программного обеспечения и решения о том, как его лучше всего создавать, развиваются с течением времени благодаря сотрудничеству между командой разработчиков и заинтересованными сторонами проекта.
Agile-разработка – это эффективный, творческий подход к разработке программного обеспечения. Он выступает за адаптивное планирование, эволюционное развитие, раннюю поставку и постоянное совершенствование, а также поощряет быстрое и гибкое реагирование на изменения[87]. Как резюмируется в «Манифесте гибкой разработки программного обеспечения», основные идеи данного подхода заключаются в следующем:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт
