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

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

Возможно, вы уже кое-что знаете об Agile-разработке, поскольку она используется многими разработчиками игр и программного обеспечения по всему миру. Как и Метод, Agile-разработка была прогрессивной реакцией на идеи конвейерной сборки, воплощенные в каскадном подходе (водопад) к созданию программного обеспечения. Эта методология возникла благодаря другим процессам, таким как быстрая разработка приложений в 1970‑х и 1980‑х годах и рациональный унифицированный процесс в 1990‑х[86]. Agile-разработка – это подход к разработке программного обеспечения, при котором дизайн создаваемого программного обеспечения и решения о том, как его лучше всего создавать, развиваются с течением времени благодаря сотрудничеству между командой разработчиков и заинтересованными сторонами проекта.

Agile-разработка – это эффективный, творческий подход к разработке программного обеспечения. Он выступает за адаптивное планирование, эволюционное развитие, раннюю поставку и постоянное совершенствование, а также поощряет быстрое и гибкое реагирование на изменения[87]. Как резюмируется в «Манифесте гибкой разработки программного обеспечения», основные идеи данного подхода заключаются в следующем:


люди и взаимодействие важнее процессов и инструментов;

работающий продукт важнее исчерпывающей документации;

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

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

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

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

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

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

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

).

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

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

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

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

Перейти на страницу:

Похожие книги

Исторические информационные системы: теория и практика
Исторические информационные системы: теория и практика

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

Динара Амировна Гагарина , Надежда Георгиевна Поврозник , Сергей Иванович Корниенко

Зарубежная компьютерная, околокомпьютерная литература / Учебная и научная литература / Образование и наука