Наивная стратегия, к которой прибегают до сих пор, – склеить все воедино и надеяться на лучшее. Иногда это срабатывает. Но если нет, у вас большие проблемы. Вам придется либо отзывать неудавшуюся игру, либо вкладывать деньги в ее доработку до тех пор, пока она не оправдает ожиданий. Обычно на это уходит так много времени и ресурсов, что у проекта уже не остается шансов себя окупить.
По правде говоря, это проблема всех проектов по разработке ПО. Невозможно предсказать, сколько времени займет разработка подобного сложного проекта, с поиском и исправлением багов, которые непременно проявятся в процессе. Вдобавок к этому игры еще должны приносить удовольствие – разработчики игр должны позаботиться о нескольких дополнительных фильтрах, о которых создателям неигрового ПО волноваться не нужно.
Настоящая проблема здесь – это Правило цикла.
Правило цикла не является призмой, ведь это не проекция, а абсолютная истина. В Правиле цикла не может быть исключений. За свою карьеру вы не раз попытаетесь проигнорировать это правило и сказать себе нечто вроде «в этот раз дизайн настолько хорош, что мы можем обойтись без тестов и улучшений» или «у нас нет выбора – будем надеяться на лучшее», и будьте уверены, что каждый раз это будет вашей ошибкой. Проблема с разработкой компьютерных игр состоит в том, что они требуют намного больше расходов и времени на тестирование и доработку по сравнению с традиционными играми. Это значит, что у разработчика компьютерных игр нет другого выхода, кроме как повторять все по нескольку раз, а это – чрезвычайно рискованное предприятие.
Если вы, несмотря ни на что, решились взяться за игру, разработка которой потребует долгих циклов «тестирования и улучшений», то необходимо ответить на два вопроса.
• Вопрос цикла 1: Как сделать каждый цикл эффективным?
• Вопрос цикла 2: Как можно максимально ускорить циклы?
Разработчики ПО много думали над ответами на эти вопросы на протяжении последних сорока лет, и они таки придумали несколько полезных техник.
В 1960-е, когда разработка ПО была относительно новой индустрией, еще рано было говорить о формализации процесса. Программисты просто старались угадать, сколько времени займет процесс, и начинали писать программы. Часто их предположения оказывались ошибочны, и они катастрофически не вписывались в бюджет. В 1970-е с целью привнести немного порядка в эту непредсказуемую сферу, многие разработчики (обычно по распоряжению менеджеров, не имеющих отношения к технологиям) пытались внедрить в разработку ПО «модель водопада»: упорядоченный алгоритм создания ПО за семь шагов. Обычно эта модель выглядела вот так.
И это, конечно, выглядит привлекательно! Модель состоит из семи упорядоченных шагов: выполнив один из них, вы просто переходите к следующему. Само название «водопад» не предусматривает повторов, ведь водопады не текут вверх по течению.
У этой модели несомненно было одно хорошее качество: она мотивировала разработчиков посвящать больше времени планированию и дизайну до того, как они приступят непосредственно к написанию кода. Но в остальном это полная ерунда, подобный подход нарушает Правило цикла. Менеджеры нашли модель привлекательной, но программисты знали, что это абсурд: в применении к таким сложным сферам, как разработка ПО, подобные линейные процессы обречены на провал. Даже Винстон Ройс (Winston Royce), чья работа послужила фундаментом для создания этой модели, не признает ее эффективность в общепринятом виде. Интересно, что в своей работе он подчеркивает важность циклов в разработке и говорит о возможности возврата на несколько шагов назад, если ситуация того требует. И он никогда не использовал слово «водопад»! Но в университетах и корпорациях изучали именно этот линейный подход. Это можно объяснить лишь тем, что люди, которые никогда в жизни не имели дело с разработкой программного обеспечения, принимали желаемое за действительное.
Позже, в 1986-м, Барри Бим представил другую модель, имевшую гораздо больше общего с реальным процессом разработки ПО. Это несколько пугающая своим видом схема, в которой процесс разработки начинается с середины и раскручивается по часовой стрелке, проходя через окружность снова и снова (рис. 8.3).
Его модель состоит из множества сложных деталей, но все они нам не нужны. В основном здесь можно отметить три замечательные идеи: оценка рисков, прототипы и цикличность. Согласно спиральной модели, вам нужно сделать следующее.
1. Определиться с основой дизайна.
2. Высчитать самые большие риски вашего дизайна.
3. Создать прототипы, которые уменьшат эти риски.
4. Протестировать прототипы.
5. Определиться с более детальным дизайном, основываясь на информации, которую вы получили.
