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

Со временем идея производственной линии нашла применение и в мире компьютерных систем в так называемой каскадной модели, или модели «Водопад», подходе к разработке программного обеспечения, который появился в середине 1950‑х годов (хотя сам термин waterfall появился только в 1970‑х годах). Идея водопада, по сути, та же, что и у конвейерной линии: дизайнеры и инженеры тщательно продумывают, а затем пишут обширную спецификацию для программного обеспечения. Затем они разрабатывают план реализации спецификации, и оба документа передаются команде инженеров-программистов, поэтапно создающих программу, тщательно следуя полученным инструкциям.

Начиная с конца 1980‑х годов каскадные модели, которые широко использовались в разработке программного обеспечения для бизнеса, привлекли внимание менеджеров игровых проектов – они отчаянно стремились взять свои проекты под контроль с точки зрения времени, человеческих ресурсов и денег. Разработчики-любители 1980‑х годов – создатели инди-игр того времени, – молодые и увлеченные своим искусством, работали свободно, интуитивно, но часто неэффективно, всеми силами пытаясь довести свои проекты до завершения, даже если это им стоило беспрестанной работы и месяцев без единого выходного. Иногда проекты выполнялись вовремя и качественно – но очень часто они сильно нарушали сроки и выходили за рамки бюджета или вообще не достигали завершения. Творцы на таких проектах часто «сгорали», подрывая психическое и физическое здоровье.

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

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

Создание чего-то нового

Если вы создаете игру по проверенному шаблону, с хорошо отлаженной игровой механикой, которая, как вы уже знаете, будет работать, то каскадная модель вам подойдет. Но что делать, если вы пытаетесь создать что-то новое? Что-то, в чем вы еще не уверены: как все части игры будут сочетаться друг с другом, что покажет себя с лучшей стороны, что нужно будет усилить, а что – доработать или вовсе убрать из игры?

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

Мы уже рассмотрели, как проводить исследования и «рисовать эскизы» в разделе, посвященном идеации. Теперь пришло время взглянуть на процесс разработки, выходящий за рамки эскизов и набросков, и приступить к масляной краске – итеративной разработке на этапе препродакшена.

Планирование на этапе препродакшена

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

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

В книге 101 Things I Learned in Architecture School, любимой гейм-дизайнерами, автор и архитектор Мэтью Фредерик пишет: