Файл: В начале был дизайнер.pdf

72
Разработчики ПО много думали над способами решения этой проблемы на протяжении последних сорока лет, и они таки придумали несколько полезных техник.
Краткая история индустрии ПО
Опасность – Водопад – Шаг Назад
В 1960-е, когда разработка ПО была относительно новой индустрией, еще рано было говорить о формальных процессах. Программисты просто старались угадать, сколько времени займет процесс, и начинали писать программы. Часто их предположения оказывались ошибочны и они катастрофически не вписывались в бюджет.
В 1970-е, с целью привнести немного порядка в эту непредсказуемую сферу, многие разработчики (обычно по распоряжению менеджеров, не имеющих отношения к технологиям) пытались принять “модель водопада” в разработке ПО, которая была упорядоченным алгоритмом создания ПО продукта, состоящим из семи шагов. Обычно эта модель выглядела как вот эта:
Рис. 7.1
И это на самом деле выглядит убедительно. Модель состоит из семи упорядоченных шагов, и когда вы выполняете один шаг, не остается больше ничего, кроме как приступить к следующему шагу – само название “водопад” не предусматривает повторения, потому что водопады обычно не текут вверх по течению.
Подобная модель все же имеет одно серьезное преимущество: она мотивирует разработчиков посвящать больше времени планированию и дизайну до того, как они

73 приступают непосредственно к кодингу. Но в остальном это полная ерунда, потому что подобный подход нарушает
Правило
Цикла.
Менеджеры находят модель привлекательной, но программисты знают, что это абсурд – в применении к таким сложным сферам как разработка ПО, подобные линейные процессы никогда не будут работать. Даже Винстон Ройс (Winston Royce), чья работа послужила фундаментом для создания всего этого, не признает эффективность модели водопада в ее общепринятом виде. Интересно, что в своей работе он сам писал о важности повторения и способности вернуться на несколько шагов назад, если ситуация того требует. Он даже никогда не использовал слово “водопад”! Но люди в университетах и корпорациях изучали именно этот линейный подход. Это можно объяснить лишь тем, что люди, которые никогда в жизни не имели дело с разработкой программных систем, принимали желаемое за действительное.
Барри Бим любит тебя
Позже, в 1986, Барри Бим представил другую модель, которая имела больше общего с реальным процессом разработки ПО. Обычно она выглядит как что-то наподобие диаграммы, в которой разработка начинается с середины и раскручивается по часовой стрелке, проходя через окружность снова и снова (рис. 7.2).
Его модель состоит из множества сложных деталей, но все они нам не нужны. В основном, здесь есть три замечательные идеи: оценка риска, прототипы и цикличность.
Согласно спиральной модели, вам нужно сделать следующее:
1 Определиться с основой дизайна.
2 Высчитать самые большие риски вашего дизайна.
3 Создать прототипы, которые уменьшат эти риски.
4 Протестировать прототипы.
5 Определиться с более детальным дизайном, основываясь на информации, которую вы получили.
6 Вернуться к пункту 2.
В целом, вы просто повторяете этот цикл, пока все не станет на свои места. При таком раскладе модель водопада сдается без боя, потому что в данном цикле все основывается на Правиле Петли. Также это позволяет нам ответить на вопросы, которые мы задавали ранее:
● Вопрос Цикла 1: Как сделать каждый цикл эффективным?
Ответ Спиральной Модели: Оцените ваши риски и уменьшите их.
● Вопрос Цикла 2: Как можно максимально ускорить циклы?
Ответ спиральной модели: Создавайте больше “черновых” прототипов.
Существует много ответвлений от спиральной модели, с которыми вы, возможно, захотите ознакомиться. Несмотря на то, что они разные, основой всех спиральных моделей является оценка рисков и создание прототипов.

74
Рис. 7.2
Спиральная модель разработки ПО
Оценка рисков и создание прототипов
Пример: “Заключенные Баблвилля”
Предположим, вы с вашей командой решили сделать игру о прыжках с парашютом в городскую местность. У вас уже есть краткое описание дизайна, основанное на элементной тетраде:
“Заключенные Баблвилля” — Краткое описание
История: Вы кот-парашютист по имени Смайли. Злой волшебник превратил дома жителей Баблвилля в тюрьмы и закрыл там их обитателей. Вам нужно найти способ победить волшебника, прыгая с парашютом в город и проникая в дома Баблвильцев через дымоходы, чтобы узнать у жителей города, как можно победить волшебника.
Механика: Спускаясь по направлению к городу, вы должны собирать волшебные пузыри, которые поднимаются в воздух. Они дают вам энергию, необходимую для того, чтобы стрелять по стервятникам, которые будут пытаться лопнуть пузыри и порвать ваш

75 парашют. Одновременно вы должны направлять персонажа к целевым зданиям, на которые нужно приземлиться.
Эстетика: Мультипликационная графика.
Технология: Мультиплатформенная консольная игра на трехмерном движке от стороннего разработчика.
Вы можете поступить следующим образом: просто начать делать игру. Начать писать код, разрабатывать детальный дизайн уровней, потом собрать все вместе и посмотреть, что игра будет из себя представлять. Но такой подход может быть чрезвычайно опасным. При условии, что вас проект рассчитан на 18 месяцев, вам понадобится минимум 6 месяцев на то, чтобы получить материал для первого play-теста.
А что, если после него вы поймете, что идея вашей игры не приносит фана? Или движок не подходит под ваши цели? У вас были бы большие проблемы. Вы потратили треть доступного времени, а ваша игра прошла только один цикл!
Правильнее в этом случае было бы собраться всей командой и провести анализ рисков. Это значит, что нужно составить список всех обстоятельств, которые могут поставить проект под угрозу. Список рисков для этой игры выглядит приблизительно так:
Заключенные Баблвилля – Список Рисков
Риск #1: Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется.
Риск #2: Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников.
Риск #3: Согласно нашему изначальному видению, для игры нам потребуется тридцать разных домов – создание большого количества различных интерьеров и анимированных персонажей может занять больше времени, чем мы предполагали.
Риск #4: Мы не уверены, что людям понравятся наши персонажи и история.
Риск #5: Вполне возможно, что выйдет какой-то фильм о парашютных трюках и издатель захочет, чтобы наша игра была на тему этого фильма.
В действительности, у вас, скорее всего, будет намного больше рисков, но ради нашего эксперимента, мы ограничимся только этими. Так что же делать с этими рисками? Мы могли бы скрестить пальцы и надеяться, что ничего из вышеперечисленного не произойдет, или применить умный подход: смягчение рисков. Идея состоит в том, чтобы уменьшать или предотвращать риски так быстро, как только возможно, часто за счет создания небольших прототипов. Давайте посмотрим, как можно смягчить каждый из этих рисков:
Заключенные Баблвилля – Смягчение рисков
Риск #1: Возможно, механика собирания пузырей и уничтожения стервятников будет не такой интересной, как нам кажется.
Игровую механику можно часто представить в упрощенной форме. Пусть программист сделает абстрактную версию вашей механики, например в 2D, с простыми геометрическими фигурами вместо анимированных персонажей. Вы вполне можете получить рабочую версию игры за неделю или две и сразу же понять, интересна ли ваша механика. Если нет — вы можете изменять упрощенный прототип столько, сколько нужно, пока он не станет достаточно интересным, и уже после этого приступить к разработке 3D-

76 версии. Вскоре вам придется проходить еще больше циклов, и если вы будете грамотно использовать Правило Цикла, то сможете получить различные преимущества. Вы можете не согласиться с этим подходом, потому что написание 2D кода для прототипа, который игрок никогда не увидит – это трата времени. Тем не менее, это позволит вам сохранить больше времени на последующих этапах, потому что вы сможете раньше приступить к написанию правильного варианта игры, а не бесконечно писать и переписывать неправильные варианты.
Риск #2: Возможно, движок не сможет поддержать одновременное отображение целого города и всех этих пузырей и стервятников.
Если будете ждать, пока художники закончат всю свою работу и смогут ответить на этот вопрос, вы можете попасть в весьма затруднительное положение. Если движок не справляется со своей задачей, вам нужно просить художников все переделать так, чтобы графика не перегружала движок или же просить программистов, чтобы те потратили еще больше времени на доработку движка (или, скорее всего, обе эти вещи). Чтобы смягчить риск, создайте приблизительный прототип, который может только показывать приблизительное количество графических элементов на экране, что позволит вам узнать, сможет ли движок их поддержать. В прототипе нет геймплея; он нужен исключительно для тестирования технологических лимитов. Если вы видите, что движок справится, то отлично. Если видите, что нет, то у вас есть возможность приступить к поиску решения проблемы до того, как вся графика уже готова. Опять же, это исключительно
“одноразовый” прототип.
Риск #3: Согласно нашему изначальному видению, для игры нам потребуется тридцать разных домов – создание большого количества различных интерьеров и анимированных персонажей может занять больше времени, чем мы предполагали.
Если половина разработки закончена, а вы вдруг понимаете, что у вас недостаточно художников для того, чтобы сделать всю работу, вы обречены. С самого начала попросите художника создать один дом и одного персонажа, чтобы у вас было представление о том, сколько времени это может занять. Если это занимает больше времени, чем вы можете себе позволить, сразу же меняйте дизайн – может быть, вам и не нужно так много домов, а некоторых персонажей и интерьеры можно использовать повторно.
Риск #4: Мы не уверены, что людям понравятся наши персонажи и история.
Если вас это действительно волнует, то нельзя ждать, пока персонажи проявят себя уже в готовой игре. Так какой же прототип мы создаем здесь? Художественный прототип – для этого можно обойтись и без компьютера – просто доска для объявлений.
Попросите художника сделать приблизительный концепт иллюстрации к игре или провести тест-рендер ваших персонажей и настроек. Попробуйте визуально воспроизвести последовательность событий в вашей игре, чтобы понять, как они будут развиваться. Когда закончите, покажите это все людям (желательно, чтобы это были представители вашей ЦА) и проследите за их реакцией. Вам нужно понять, что им понравилось, что не понравилось, и почему. Возможно, они в восторге от внешнего вида главного героя, но его поведение в игре им не по душе. Может быть, вы хорошо раскрыли образ злодея, а вот история получилась скучной. Это все можно легко узнать и

77 без самой игры. Каждый раз, когда вы это делаете, вы проходите очередной цикл, то есть делаете еще один шаг вперед к вашей идеальной игре.
Риск #5: Вполне возможно, что выйдет какой-то фильм о парашютных трюках, и издатель захочет, чтобы наша игра была на тему этого фильма.
Возможно, этот риск звучит абсурдно, но подобные вещи происходят постоянно.
Если это случается в середине проекта, это катастрофа. И подобные вещи нельзя игнорировать – нужно учитывать каждый риск, который может поставить ваш проект под угрозу. Поможет ли в этом случае прототип? Скорее всего, нет. Смягчить этот риск вам поможет либо эффективный менеджмент, либо специфический дизайн вашей игры, тематику которого можно легко изменять, если возникла такая необходимость. Можно даже включить в план создание двух разных игр - основная идея в том, чтобы моментально реагировать на риски и принимать меры по предотвращению угрозы для вашего проекта.
Оценка и смягчение рисков – это очень полезный подход, а также Линза #14.
Линза #14: Совет Смягчения Рисков
Чтобы использовать эту линзу, перестаньте надеяться на лучшее и начните серьезно обдумывать вещи, которые могут поставить вашу игру под угрозу. Спросите себя:
Что может не дать этой игре стать хитом?
Как мы можем это предотвратить?
Управление рисками – это трудная задача. Вы должны столкуться с проблемами, которых при иных обстоятельствах предпочли бы избежать, и решить их в максимально сжатые сроки. При достаточном уровне самодисциплины вы сможете пройти больше циклов, и с большим уровнем эффективности, что позволит вам получить на выходе игру более высокого качества. Порой очень тяжело отказаться от привычного игнорирования возможных проблем и работы над теми аспектами, в которых вы уверены. Но вы должны это преодолеть, и сосредоточиться на тех частях игры, которые могут поставить проект под угрозу.
Восемь советов для продуктивного прототипирования
Все знают, что своевременное создание прототипов – важное условие качественной разработки игр. Вот несколько советов, которые помогут вам создать самые лучшие и самые полезные опытные образцы вашей игры.
Совет для прототипирования #1: Ответьте на вопрос
Каждый прототип создается для того, чтобы получить ответ на вопрос или на несколько вопросов. Вы должны научиться формулировать вопрос четко. Если вы не умеете этого делать, вы рискуете потерять время из-за прототипа, а не сохранить его, как изначально планировали. Вот некоторые примеры вопросов, на которые может отвечать прототип:

78
● Сколько анимированных персонажей может поддержать ваша технология?
● Увлекателен ли основной геймплей? Как долго он может оставаться увлекательным?
● Насколько хорошо персонажи и окружающий мир сочетаются в эстетическом плане?
● Насколько большими должны быть уровни?
Не поддавайтесь соблазну создавать свой прототип заново и сосредоточьтесь на том, чтобы он отвечал на основные вопросы.
Совет для прототипирования #2: Забудьте о качестве
Геймдевы всех мастей имеют одну общую черту: они гордятся своим ремеслом. Поэтому большинство из них не могут даже думать о создании прототипа “на скорую руку”.
Художники потратят слишком много времени на одни только наброски сырого концепта, а программисты слишком долго будут делать из этого более-менее качественную игру.
Когда вы работаете над прототипом, все, что имеет значение – отвечает ли он на вопрос.
Чем быстрее он на него ответит, тем лучше – даже если он лишь наполовину рабочий и выглядит угловато. На деле, шлифование прототипа может даже ухудшить положение вещей. Плейтестеры (и коллеги) скорее укажут на недостатки опытного образца, который выглядит грубо, чем на проблемы того, который выглядит как готовая игра. Поскольку ваша цель – быстро находить проблемы и решать их на самом раннем этапе, отшлифованный прототип может вам в этом помешать, скрывая настоящие проблемы за привлекательной внешней оболочкой.
Здесь вам нужно забыть о Правиле Цикла. Чем быстрее вы сделаете прототип, который сможет ответить на ваш вопрос, тем лучше, и не важно, как плохо он выглядит.
Совет для прототипирования #3: Никаких привязанностей
В Mythical Man Month Фред Брукс впервые употребляет свое знаменитое выражение
“Отпускайте легко, так как это неизбежно”. Этим он хотел сказать, что нравится вам это или нет, но первая версия вашего проекта – это не конечный продукт, а прототип, от которого впоследствии придется отказаться, чтобы создать “правильно” работающую систему. Но по правде, “отпустить”, возможно, придется много прототипов. Для разработчиков с небольшим опытом это очень трудно – они воспринимают это как провал.
Создавая опытный образец, убедите себя в том, что прототип – это временная мера и ее жизненный цикл заканчивается в том самый момент, когда вы получаете ответ на свой вопрос. Смотрите на каждый прототип как на возможность чему-то научиться – потренироваться перед созданием “настоящей” системы. Конечно, отказываться от всего не нужно – собирайте работающие “кусочки”, чтобы впоследствии слепить из них что-то действительно стоящее. Иногда это больно. Дизайнер Николь Эппс сказала следующее:
“Это как зарезать собственное дитя, но этому нужно научиться”.
Совет для прототипирования #4: Разместите прототипы в порядке их важности