ладно Бин об бог под. В начале был дизайнер
 Скачать 4.02 Mb.
|
|
Глава 7 Итерация делает игру лучше Выбираем идею После продолжительных раздумий, перед вами лежит огромный список идей. Вот тут-то многие дизайнеры и спотыкаются. Им нравится так много идей, что они не знают, что им выбрать. Или же у них много средних идей, но ничего выдающегося, и опять, они не знают, что лучше выбрать. Идеи слишком долго витают в воздухе, а их авторы, пребывая в мутном тумане неопределенности, надеются, что “правильная идея” вдруг появится сама собой, а им нужно просто немного подождать. Но что-то по-настоящему волшебное происходит, когда вы берете идею и решаете воплотить ее в жизнь. Как написал Штайнбек в своей книге “О мышах и Людях” (Of Miceand Men), “План – это уже реальность”. Как только вы решите сами для себя “Да, я это сделаю” — то, что вы не могли понять до этого вдруг станет явным. Это похоже на подбрасывание монеты: чтобы принять решение, когда монета летит вниз, вы вдруг понимаете, что вам на самом деле нужно. Что-то внутри нас заставляет смотреть на вещи по-другому, когда мы еще не решились что-то делать и после того, как решение уже принято. Нужно научиться извлекать пользу из этой особенности человеческой натуры — моментально принимайте решения по поводу вашего дизайна, вбейте их себе в голову и сразу же приступайте к обдумыванию последствий решения, которое вы только что приняли. Но что, если с озарением, которое вдруг приходит вместе с принятием решения, вы понимаете, что сделали неправильный выбор? Ответ предельно прост: будьте готовы изменить свое решение, если поймете, что оно неверное. Для многих людей это сложно – если они приняли какое-то решение по своему дизайну, то уже не могут от него отказаться. Не позволяйте себе такую сентиментальность. Идеи – это не китайский фарфор, а одноразовая посуда – они дешевые в производстве, и если вы найдете в ней брак, просто возьмите другую тарелку. Некоторых людей сильно раздражает эта комбинация моментальных решений и такого же быстрого изменения своей точки зрения. Но только так вы быстрее всего научитесь принимать правильные решения, а в геймдизайне только то и нужно делать, что принимать решения – нужно в кратчайшие сроки искать самые лучшие варианты решения проблемы, и немного эксцентричности в поступках – как раз то, что вам нужно. Всегда лучше определиться с идеей раньше, чем позже – вы найдете хорошее решение гораздо быстрее, чем когда будете долго просиживать над каждым альтернативным вариантом. Лучше не влюбляться в собственные решения, потому что, вполне возможно, вам придется от них отказаться, если они не будут работать так, как вы хотите. Итак, как нужно выбирать? В некотором смысле, это можно делать наугад. Если подумать, то появляется много факторов, которые стоит учитывать, когда вы начинаете разрабатывать начальную идею. Иногда полезно понимать, что должно получиться с этой идеей еще до того, как вы начнете ее развивать. 68 Восемь фильтров В итоге ваш законченный дизайн должен будет пройти через восемь тестов, или фильтров. Только после окончания всех испытаний о вашем дизайне можно будет сказать “годен”. Если он провалит хотя бы один тест, вам нужно будет менять дизайн и заново пропускать его через все восемь “фильтров”, потому что изменение, которое может позволить ему пройти через один фильтр, может стать причиной провала во время прохождения другого. В известном смысле, процесс дизайна состоит, в основном, из постановки проблемы, появления начальной идеи и поисков пути, который позволит ей пройти через все восемь фильтров. Вот эти фильтры: Фильтр #1: Художественное чутье: Это самый персональный из всех фильтров. Вы, как дизайнер, просто спрашиваете самого себя, нравится ли вам игра, и если да — тест пройден. Если нет, то что-то необходимо изменить. Ваше внутреннее чутье является очень важным фактором. Оно не всегда правильное, но остальные фильтры расставят все по местам. Ключевой вопрос: “Мне нравится эта игра?” Фильтр #2: Демографические показатели: Вы должны делать игру для конкретной аудитории. Вы можете составить ее по возрастным группам, по половым признакам или по каким-то другим характеристикам (например, “любители гольфа”). Посмотрите, насколько ваш дизайн подходит вашей целевой аудитории. Целевую аудиторию мы рассмотрим подробнее в Главе 8. Ключевой вопрос: “Достаточно ли понравится эта игра моей целевой аудитории?” Фильтр #3: Создание опыта: Для применения этого фильтра возьмите во внимание все, что вы знаете о создании хорошего опыта, включая эстетику, кривые интереса, резонансные темы, игровой баланс и многое другое. Многие линзы в этой книге посвящены как раз созданию опыта – чтобы пройти через этот фильтр, вам нужно будет внимательно изучить много “линз”. Ключевой вопрос: “Насколько хорошим является дизайн игры?” Фильтр #4: Инновации: Если вы создаете новую игру, то в ней, по определению, должно быть что-то новое, что-то, чего игрок не видел до этого. Насколько ваша игра инновационная – это субъективный вопрос, но от того не менее важный. Ключевой вопрос: “Достаточно ли игра инновационная?” Фильтр #5: Бизнес и маркетинг: Игровой бизнес такой же бизнес, как и все остальные, и дизайнер, который хочет, чтобы его детище зарабатывало деньги, должен понимать реалии рынка и учитывать их в своем дизайне. Это включает в себя много вопросов. Тема и история достаточно хороши, чтобы привлечь внимание покупателей? Можно ли уместить понятное описание основных характеристик вашей игры в несколько 69 предложений? Что игроки могут ожидать от вашей игры, основываясь на ее жанре? Насколько ваша игра отличается от подобных игр, присутствующих на рынке? Не будет ли ваша игра убыточной из-за слишком высоких затрат на производство? Захотят ли торговцы продавать вашу игру? Ответы на эти и многие другие вопросы в значительной степени повлияют на ваш дизайн. Как ни странно, но дизайны с инновационными идеями, зачастую, не проходят через этот фильтр. Подробнее мы поговорим об этом в Главе 29. Ключевой вопрос: “За счет чего игра будет продаваться?” Фильтр #6: Разработка: Пока не воплощенная в жизнь, идея остается просто идеей, а идеи не ограничены рамками возможностей и практичности. Чтобы пройти через этот фильтр, вы должны ответить на вопрос “Как мы будем делать из этого игру?” Ответом может быть то, что воплощение вашей идеи в ее изначальном виде не является возможным по причине отсутствия необходимых технологий. Границы, в которые проект загоняют возможности доступных технологий, особенно расстраивают дизайнеров- новаторов. Однако “фильтр разработки” может направить разработку игры в новое русло, потому что в процессе применения фильтра вы можете понять, что новая технология открывает такие возможности для игры, которые вы сами упустили. Идеи, которые у вас появятся во время применения этого фильтра, могут нести исключительную ценность для вас, по крайней мере, потому, что они будут практичными. Больше о технологическом аспекте создания игры вы сможете узнать в Главе 26. Ключевой вопрос: “Является ли создание этой игры технически возможным?” Фильтр #7: Социал и сообщества: Иногда игре не достаточно просто быть веселой. Для некоторых дизайнерских целей необходима еще и сильная социальная составляющая, или формирование растущего сообщества на базе вашей игры. Дизайн вашей игры в значительной мере повлияет на эти вещи. Подробнее мы поговорим об этом в Главах 21 и 22. Ключевой вопрос: “Соответствует ли эта игра социальным целям моего дизайна?” Фильтр #8: Плейтест: Как только состояние вашей игры дойдет до играбельной стадии, нужно применять фильтр Плейтест, который, возможно, является самым важным из фильтров. Одно дело представлять себе то, как в конечном счете будет выглядеть игра, а совершенно другое – в нее поиграть, и еще более иное – посмотреть, как на нее отреагирует ваша целевая аудитория. Чем быстрее вы доведете игру до играбельного состояния, тем лучше, потому что когда вы увидите свою игру в действии, все важные изменения, которые должны быть сделаны, станут очевидными. Вдобавок к модификации самой игры, применение этого фильтра часто изменяет восприятие остальных фильтров, потому что вы узнаете все больше о механике вашей игры и психологии вашей целевой аудитории. Play-тест мы рассмотрим подробнее в Главе 25. Ключевой вопрос: “Достаточно ли игра нравится игрокам?” Иногда во время разработки приходится редактировать характеристики фильтров: предположим, что изначально у вас была одна целевая аудитория (скажем, мужчины 18- 35 лет), но в процессе разработки вы находите что-то, что лучше подходит другой ЦА 70 (скажем, женщины за 50). Нет ничего плохого в том, чтобы изменять фильтры, если ваш дизайн это позволяет. Самое главное, когда мы пересматриваете дизайн или фильтры, сделать так, чтобы игра прошла через все восемь. Вы будете использовать эти фильтры все время на протяжении всего процесса разработки игры. Когда вы выбираете идею, есть смысл подумать, какая идея имеет наибольшее количество шансов пройти через все фильтры после применения различных изменений. Посмотреть на игру с точки зрения восьми фильтров – очень полезный способ оценить ее, так что давайте приступим к Линзе #13. Линза #13: Линза Восьми Фильтров Чтобы использовать эту линзу, ваш дизайн должен соответствовать многим требованиям. Ваш дизайн можно будет назвать оконченным только тогда, когда он без изменений сможет пройти через все восемь фильтров. Спросите себя: ● Мне нравится эта игра? ● Достаточно ли понравится эта игра моей ЦА? ● Насколько хорошим является дизайн игры? ● Достаточно ли игра инновационная? ● За счет чего игра будет продаваться? ● Является ли создание этой игры технически возможным? ● Соответствует ли эта игра социальным целям моего дизайна? ● Достаточно ли игра нравится игрокам? В некоторых случаях фильтров может быть и больше; например, образовательные игры должны будут ответить на вопросы типа “Учит ли эта игра тому, чему она должна учить?” Если игра требует больше фильтров, не игнорируйте это. Правило цикла Становится немного не по себе, если подумать, что вся Глава 6 и часть этой главы являются просто развитием одного шага “1. Придумали идею”. Но с другой стороны, идеи – это то, с чего вырастает дизайн, а процесс их появления настолько таинственный, что его можно считать почти волшебным, так что, возможно, нас и вовсе не должен пугать тот факт, что об одном шаге можно говорить так долго. На этом этапе вы уже должны были обдумать много идей и выбрать самую лучшую из них, а значит, пришло время переходить к следующему шагу: “2. Сделали из нее игру”. Многие дизайнеры и разработчики делают примерно следующее – закрывают глаза и начинают делать свою игру. И если ваша игра простая – например, карточная, настольная или примитивная компьютерная игра – и у вас достаточно времени, чтобы раз за разом тестить и изменять ее, пока вас не будет все устраивать, вам, пожалуй, подойдет такой подход. 71 Но что, если вы не можете сделать рабочий прототип игры за час или два? Что, если ваше видение игры требует месяцев работы художников и программистов, до того как вы сможете хотя бы попробовать сделать саму игру? Если это ваш случай (а это случай многих современных видеоигр), этот шаг нужно преодолеть крайне внимательно. Процесс дизайна и разработки игры обязательно должен быть повторяющимся или цикличным. Вы не сможете точно спланировать, сколько циклов займет процесс, пока ваша игра не пройдет через все восемь фильтров и не станет “достаточно хорошей”. И это делает разработку игр невероятно рискованным делом – вы ставите на то, что ваша игра сможет пройти через все восемь фильтров с фиксированным бюджетом, когда на самом деле не можете быть в этом уверены. Наивная стратегия, к которой некоторые прибегают и до сих пор, — склеить все воедино и надеяться на лучшее. Иногда это срабатывает. Но если нет, то у вас большие проблемы. Вам придется либо отозвать игру, которую вы не находите достаточно хорошей, либо же продолжать тратить деньги на доработку, пока игра не станет такой, как вы хотите. Часто потерянного времени и дополнительных расходов достаточно, чтобы сделать проект полностью убыточным. На деле, это проблема всех проектов по разработке ПО. Сложность подобных проектов делает невозможным предсказать, сколько времени они займут, а также сколько времени нужно будет потратить на поиск и исправление багов, которые, в любом случае, появятся в процессе разработки. Вдобавок ко всему вышесказанному, игры еще должны приносить удовольствие – разработчики игр должны позаботиться о нескольких дополнительных фильтрах, о которых создателям неигрового ПО волноваться не нужно. Настоящая проблема здесь – это Правило Цикла. Правило Цикла: Чем больше раз вы улучшаете и испытываете ваш дизайн, тем качественнее игра у вас получается. Правило Цикла – это не линза, потому что это не проекция, а абсолютная истина. В Правиле Циклов не может быть исключений. На протяжении вашей карьеры вы еще не раз проигнорируете это правило и скажете самому себе “в этот раз дизайн настолько хорош, что мы можем обойтись без тестов и улучшений” или “у нас нет выбора – будем надеяться на лучшее”, и будьте уверены, что каждый раз это будет вашей ошибкой. Проблема с разработкой компьютерных игр состоит в том, что они требуют намного больше расходов и времени на тестирование и доработку по сравнению с традиционными играми. Это значит, что у разработчика компьютерных игр нет другого выхода, кроме как повторять все по нескольку раз, что может быть чрезвычайно рискованным предприятием. Если, вы несмотря ни на что, решились взяться за игру, разработка которой потребует долгих циклов “тестирования и улучшений”, то необходимо ответить на эти два вопроса: ● Вопрос Цикла 1: Как сделать каждый цикл эффективным? ● Вопрос Цикла 2: Как можно максимально ускорить циклы? 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: Разместите прототипы в порядке их важности 79 В процессе формирования списка рисков вы можете прийти к выводу, что для смягчения всех возможных рисков вам может понадобиться несколько прототипов. Правильнее будет разместить их в порядке важности, так, чтобы вы могли в первую очередь справляться с самыми большими рисками. Зависимость также стоит принимать во внимание — если результаты одного прототипа могут в перспективе нивелировать значение другого, то первый определенно является самым важным. Совет для прототипирования #5: Совмещайте прототипы эффективно Отличный способ задействовать больше циклов – делать по несколько штук одновременно. Пока программисты работают над прототипом, который должен ответить на вопросы по технологии, художники могут создавать графические прототипы, а геймдизайнеры – прототипы геймплея. Имея много различных прототипов, вы сможете получать ответы на большее количество вопросов в более сжатые сроки. Совет для прототипирования #6: Они не должны быть цифровыми Ваша цель – пройти максимальное количество циклов с максимальной эффективностью. Если с этим понятно, то почему бы нам на время не отказаться от использования ПО? Немного смекалки, и вы сможете создать настольную версию вашей видеоигры или, как ее еще называют, бумажный прототип. Почему это нужно? Потому что на настольную игру можно часто спроецировать основные черты геймплея, притом, что на ее создание вы потратите гораздо меньше времени. Это позволяет обнаруживать проблемы раньше – поиск, обнаружение и решение проблемы являются основными целями создания опытных образцов, поэтому бумажные прототипы вполне могут сэкономить вам много времени. Если ваша игра пошаговая, это значительно упрощает задачу. Прототипом пошаговой системы боя для Toontown Online стала простая настольная игра, которая позволила нам тщательно сбалансировать многие виды атак и комбо ударов. Мы могли следить за хит- поинтами на бумаге или на доске, и играть снова и снова, добавляя новые и убирая ненужные правила, пока игра не станет достаточно сбалансированной, чтобы можно было приступить к кодингу. Даже игры в реальном времени можно представить в виде бумажного прототипа. Иногда из них просто можно сделать пошаговые версии, которые все равно будут способны передать геймплей. В иных случаях, в них можно поиграть в реальном времени или как-то так. Чтобы у вас все получилось, лучше заручиться поддержкой других людей. Сейчас рассмотрим примеры, и вы все поймете. Tetris: Бумажный прототип Предположим, вы захотели сделать бумажный прототип Тетриса. Вырежьте из картона маленькие кусочки и сложите их в кучу. Попросите кого-то разложить их в случайном порядке, и постепенно опускать на “доску” (набросок, который вы сделали на листе бумаги), а вы в это время “перехватывайте” фигуры и поворачивайте их в нужном вам направлении. Чтобы заставить собранный ряд исчезнуть, используйте свое воображение, 80 или поставьте игру на паузу и отрежьте его ножницами. Это, может, и не идеальный тетрис, но даже подобной симуляции иногда достаточно, чтобы понять, правильные ли формы у ваших фигур и то, с какой скоростью они должны спускаться. Отличный результат, с учетом того, что вы потратите на все не больше 15 минут. Doom: Бумажный прототип Можно ли создать бумажный прототип шутера от первого лица? Конечно! Сначала найдите людей и разделите их на AI персонажей и других игроков. На большом листе клетчатой бумаги нарисуйте карту и расставьте по ней фишки, которые будут вашими игроками и монстрами. Каждым виртуальным персонажем должен управлять отдельный человек. Далее можно придумать некое подобие пошаговых правил для вашей игры или же просто взять метроном. Программу-метроном можно легко найти в интернете. Настройте частоту ударов метронома на 5 секунд и введите правило, согласно которому персонаж делает шаг вперед на одну клетку после каждого удара. Когда на прицеле появляется враг, вы можете в него выстрелить, но только с расчетом один выстрел на один удар метронома. Это даст вам возможность посмотреть на вашу игру в замедленном действии, что является определенным преимуществом, потому что это дает вам время подумать, что в вашей игре хорошо, а что плохо, не переставая при этом играть. Вы сможете понять, насколько большой должна быть ваша карта, какой должна быть форма комнат и коридоров, чтобы игроку было интереснее по ним бегать, какими свойствами должно обладать оружие, и многое другое – и для всего этого вам понадобится совсем немного времени. Совет для прототипирования #7: Выберите легко редактируемый игровой движок Традиционный метод разработки ПО чем-то напоминает выпекание хлеба: 1 Написание кода 2 Компиляция и компоновка 3 Запуск игры 4 Поиск в игре той части, которую нужно тестить 5 Тестинг 6 Назад к шагу 1 Если вам не понравился хлеб (результаты тестинга), все, что вы можете сделать – запустить процесс по новой. Это отнимет слишком много времени, особенно, если вы работаете над крупным проектом. Но если выбрать движок с правильной системой скриптов, вы сможете вносить изменения в код, когда игра все еще запущена. Это больше напоминает работу с глиной – вы можете все время что-то менять: 1 Запуск игры 2 Поиск в игре той части, которую нужно тестить 3 Тестинг 4 Написание кода 81 5 Назад к шагу 3 Если код можно менять, когда игра запущена, это ускоряет весь процесс и позволяет вам проходить больше циклов в день, что, в свою очередь, повышает качество вашей игры. Раньше я использовал Scheme, Smalltalk и Python (я большой фанат Panda3D:www.panda3d.com), но, в целом, подойдут все языки с поздним связыванием. Если вы боитесь, что эти языки программирования медленно запускаются, помните, что игры можно писать с использованием нескольких разных кодов: напишите второстепенный контент, который не нужно будет сильно изменять, на чем-то быстром, но статическом (Assembly, C++ и т.д.), а для написания более важного контента используйте медленный, но динамичный язык. Это может потребовать дополнительных усилий, но оно того стоит, так как у вас появляется возможность воспользоваться преимуществами Правила Цикла. Совет для прототипирования #8: Сначала делайте игрушку Никогда не задумывались, чем игры отличаются от игрушек? В игрушки весело играть просто потому, что они интересны сами по себе. В играх есть цель, и они позволяют пользователю испытать гораздо более глубокий опыт, основанный на процессе решения проблемы. Тем не менее, не стоит забывать, что многие игры были созданы на основе игрушек. Мяч – это игрушка, но бейсбол – это игра. Меленькая фигурка, которая бегает и прыгает – это игрушка, а Donkey Kong — игра. Вы должны убедиться, что с вашей игрушкой весело играть, до того как вы приступите к процессу создания игры вокруг нее. Может оказаться так, что, сделав игрушку, вы обнаружите неизвестные ранее черты, которые делают ее такой веселой, и вас появится большое количество новых идей, которые можно использовать в игре. Геймдизайнер Дэвид Джонс говорит, что для создания игры Lemmings его команда пользовалась именно этим методом. Они просто подумали, что будет интересно создать маленький мир с толпами маленьких созданий, которые ходят туда-сюда и занимаются своими делами. У них не было четкого видения игры, но идея такого мира звучала интересно, поэтому они взялись за ее воплощение. Как только у них появилась “игрушка”, начались серьезные обсуждения того, какую игру можно создать вокруг нее. Джонс говорит, что в случае с Grand Theft Auto все было также: “GTA не делали как GTA. GTA делали как средство. Это должен был быть живой, полноценный город, в котором было бы интересно играть”. Как только “средство” было разработано, и команда убедилась в том, что это действительно хорошая игрушка, им нужно было решить, какую игру из нее можно сделать. Им показалось, что город был похож на лабиринт, поэтому они решили взять механику лабиринта из источника, который они посчитали достаточно надежным. Джонс продолжает: “GTA произошла от Pac-Man. Точки – это маленькие люди. Вот я еду в своей маленькой желтой машинке. А привидения – это полицейские”. Если вы будете сначала делать игрушку, а уже потом приступать к созданию игры, вы сможете радикально изменить качество вашего проекта в лучшую сторону, потому что на выходе вы получите фан сразу по двум аспектам. Но если ваш геймплей создан на основе самых интересных частей игрушки, вы сможете добиться того, что два аспекта 82 будут дополнять друг друга в наивысшей степени. Геймдизайнеры часто забывают об этом ракурсе. Чтобы не повторять их ошибок, читайте Линаз #15. Линза #15: Линза Игрушки Чтобы воспользоваться этой линзой, думайте не о том, насколько интересно играть в вашу игру, а о том, насколько интересно играть с ней. Спросите себя: ● Если бы в моей игре не было цели, была бы она такой же интересной? Если нет, как я могу это изменить? ● Возникает ли у людей желание поиграть в мою игру еще до того, как они узнают, что им нужно будет делать? Если нет — как я могу это изменить? Есть два способа использовать Линзу Игрушки. Первый способ: использовать его вместе с уже существующей игрой, чтобы понять, можно ли придать ей больше “игрушечных” качеств – иными словами, как ее можно сделать более понятной и “приятной в обращении”. Но если быть достаточно смелым и пойти по второму пути, можно изобрести абсолютно новую игрушку еще до того, как вы решите, какую игру будете создавать вокруг нее. Это может быть рискованно, если вы работаете по графику, но если нет — линза может стать вашей собственной “волшебной лозой”, которая поможет вам отыскать чудесные идеи для ваших игр, к которым вы сами вряд ли когда-то пришли бы. Замыкание цикла Когда вы уже сделали все прототипы, остается только испытать их, а потом, основываясь на полученных результатах, начать весь процесс с самого начала. Освежите в памяти неформальный процесс, который мы обсуждали ранее: Неформальный Цикл: 1 Придумали идею 2 Сделали из нее игру 3 Редактировали и тестили игру, пока она не стала такой, как вы хотите Теперь этот процесс стал более формальным: Формальный Цикл: 1 Постановили проблему 2 Придумали несколько возможных решений 3 Выбрали одно решение 4 Составили список рисков, связанных с этим решением 5 Сделали прототипы, которые смягчают эти риски 6 Испытали прототипы. Если с ними все хорошо, закончили. 83 7 Постановили новую проблему, которую нужно решить, и вернулись к шагу 2. С каждым раундом создания прототипов вы будете замечать, что ваша постановка проблемы становится все более детальной. Для примера давайте представим, что вы получили задание сделать гоночный симулятор – но в нем должно быть что-то новое и интересное. Вот конспект того, как в этом случае можно применить несколько циклов. Цикл 1: “Новый гоночный симулятор” ● Постановка проблемы: Придумать новый гоночный симулятор ● Решение: Гонки на подводных лодках (с торпедами!) ● Риски: ○ Не понятно, как должна выглядеть подводная гоночная трасса ○ Возможно, игра не будет достаточно инновационной ○ Возможно, технология не сможет поддержать все водные эффекты ● Прототипы: ○ Художники рисуют наброски подводных трасс ○ Дизайнеры создают опытные образцы (используя бумажные прототипы или просматривая существующие игры) новых эффектов (подводные лодки, которые могут подниматься над поверхностью воды и летать, самонаводящиеся ракеты, изменение глубины, препятствия в виде минных полей) ○ Программисты тестируют упрощенные водные эффекты ● Результаты: ○ Подводные трассы в виде “светящихся дорожек” выглядят хорошо. Подводные тоннели – это круто! Круто будут выглядеть и летающие подводные лотки, которые периодически выныривают из воды! ○ Ранние прототипы выглядят достаточно интересно при условии, что субмарины будут очень быстрыми и маневренными. Нужно будет обязательно сделать из них “гонки на субмаринах”. Смесь плавания и полетов выглядит свежо. Скорость подводных лодок должна увеличиваться, когда они летят, поэтому нам нужно придумать, как можно ограничить время полета. Немного поиграв, мы поняли, что в игре должен быть мультиплеер. ○ Некоторые водные эффекты проще остальных. Всплески и пузыри под водой выглядят хорошо. Но от эффекта водных колебаний придется отказаться, поскольку он потребляет слишком много системных ресурсов и просто отвлекает игрока. 84 Цикл 2: Игра про “гонки на субмаринах” ● Новая постановка проблемы: Создать игру про “Гонки на Субмаринах”, в которой субмарины могут летать. ● Детальная постановка проблемы: ○ Непонятно, как должны выглядеть “гонки на субмаринах”. Нужно определиться с внешним видом, как субмарин, так и гоночной трассы. ○ Нужно найти способ сбалансировать игру так, чтобы подводные лодки проводили правильное количество времени под и над водой. ○ Нужно понять, как обеспечить поддержку режима мультиплеер. ● Риски: ○ Если гоночные субмарины будут выглядеть “слишком мультяшно”, это может отпугнуть игроков постарше. Если они будут выглядеть слишком реалистично, это будет выглядеть глупо на контрасте с таким геймплеем. ○ Пока мы не узнаем точное количество времени, которое подлодки будут проводить под водой и в полете, невозможно приступить к дизайну уровней или к рисованию ландшафтов. ○ Команда никогда ранее не делала игры с режимом мультиплеер. Мы не полностью уверены, получится ли в этот раз. ● Прототипы: ○ Художники создают эскизы различных типов субмарин, используя различные стили: мультяшный, реализм, гипер-реализм, подлодки, являющиеся живыми существами. Сначала команда проголосует за каждый из вариантов, а затем мы проведем неформальный опрос среди представителей нашей ЦА. ○ Программисты и дизайнеры работают над максимально простыми прототипами, которые позволят понять, сколько времени подлодка должна находиться под и над водой, а так же над различными механиками, которые могут помочь вам решить эту задачу. ○ Программисты пишут приблизительный фреймворк для игры по сети, который должен поддерживать все типы сообщений, необходимых для этой игры. ● Результаты: ○ Всем понравился дизайн “дино-лодки”. Члены команды вместе с представителями потенциальной аудитории сошлись на том, что “плавающие динозавры” лучше всего подходят для этой игры. 85 ○ После нескольких испытаний стало ясно, что на протяжении большинства уровней, 60% подлодка должна быть под водой, 20% — в воздухе, и еще 20% — ближе к поверхности воды, где игрок будет собирать необходимые пауер-апы, которые позволят ему набрать высоту, набрав при этом ускорение. ○ Первые испытания мультиплеера показали, что, в целом, этот режим не должен стать проблемой для нашего симулятора, но если мы сможем избежать использования скорострельных пулеметов, это значительно упростит задачу. Цикл 3: Игра про “летающих динозавров” ● Постановка проблемы: Создать игры про “летающих динозавров”, где рептилии состязаются в скорости под водой и над ее поверхностью. ● Детальная постановка проблемы: ○ Нужно понять, сколько нужно времени для анимации всех динозавров. ○ Нужно разработать “правильное” количество уровней. ○ Нужно определиться с пауер-апами, которые будут доступны в игре. ○ Нужно составить список оружия, которое будет доступно в этой игре (и избежать использования скорострельных пулеметов, потому что они усложняют разработку режима мультиплеер). Обратите внимание, как постановка проблемы постепенно развивалась и становилась более конкретной с каждым последующим циклом. А еще обратите внимание на то, как быстро на поверхности появились другие возможные проблемы: Что, если у команды не будет времени опробовать все варианты дизайна персонажей? Что, если три уровня уже полностью готовы, а вы только заметили, что игрок находится в воздухе больше или меньше, чем нужно? Что если программисты уже написали систему пулеметов, дизайнеры построили всю игровую механику вокруг нее, а вы вдруг понимаете, что все это не сочетается с кодом мультиплеера? Вы быстро узнаете об этих проблемах, благодаря большому количеству циклов, которые прошла ваша игра. На первый взгляд, то, что мы только что описали, выглядит как два полных цикла и начало третьего, но благодаря правильному совмещению отдельных задач, нам на самом деле удалось пройти шесть циклов. Также стоит отметить активное участие всей команды в процессе принятия важных решений по дизайну. Один только дизайнер никогда не смог бы с этим справиться – большая часть дизайна определилась технологией и эстетикой. Сколько будет достаточно? Вам, наверное, интересно, сколько понадобится циклов, чтобы закончить игру. На этот вопрос очень трудно ответить, потому что это именно то, что делает разработку таким сложным процессом для планирования. Согласно Правилу Цикла, каждый новый 86 цикл сделает вашу игру немного лучше. Так что, как говорится, работа есть всегда. Важно убедиться в том, что вы пройдете достаточно циклов, чтобы сделать хорошую игру, не выходя при этом за рамки бюджета. Итак, можно ли, находясь только в начале первого цикла, понять, в какой момент ваша игра станет достаточно качественной? Нет. Это просто невозможно. Чем опытнее дизайнер, тем больше вероятность, что он сможет понадеяться на свою интуицию, но большое количество игр, чьи качество и время создания не соответствуют первоначальным ожиданиям, являются доказательством того, что заранее знать, сколько потребуется времени, просто невозможно. Почему так? Потому что в начале первого цикла вы еще не знаете, какую именно игру будете делать! Но с каждым новым циклом вы формируете все более четкое представление о том, какой будет игра, и это позволяет делать все более точные предположения. Геймдизайнер Марк Церни (Mark Cerny) дал свое описание системе разработки игры и назвал его “Метод” (The Method). Неудивительно, что в ней он описывает вышеупомянутые системы повторения и смягчения рисков. Но в “Методе” Церни интересно разделяет то, что он сам назвал “пред-продакшн” и “продакшн” (термин взят из киноиндустрии). Он говорит, что вы будете находиться на стадии пред-продакшна до тех пор, пока у вас не будет двух оконных уровней вашей игры, которые уже можно издавать. Иными словами, если у вас нет двух готовых уровней, у вас все еще нет четкого дизайна игры. Как только вы достигаете волшебной отметки, вы переходите на стадию продакшна. Это значит, что у вас появляется четкое видение игры, и что вы можете безопасно планировать график ее дальнейшей разработки. Церни говорит, что обычно к этой отметке подходят, когда 30% от необходимого бюджета уже потрачено. То есть, если на то, чтобы достичь этой отметки, вам понадобился $ 1 миллион, вам, скорее всего, понадобится еще $ 2.3 миллиона на то, чтобы довести проект до конца. Этот приблизительный подсчет на деле является самым точным способом спланировать дату выхода игры. Недостаток этого подхода состоит лишь в том, что вы не сможете ничего планировать, пока не истратите 30% бюджета. По правде, этой проблемы нельзя избежать – “Метод” лишь показывает нам, как в кратчайшие сроки достичь точки прогнозируемости. Может показаться, что описанные здесь принципы повторения можно применять только в геймдизайне, но это не так. Постепенная поэтапная разработка важна для всех видов дизайна. Теперь, когда мы с вами обсудили, как нужно делать игры, давайте поговорим о том, для кого их нужно делать. |