Развлекательная функция игр – вещь абстрактная. И чтобы создавать игровые миры, в которые пользователю захочется погружаться с головой снова и снова, придется очень многое продумать. Сара Сантиллан, Lead Designer в Boomzap Entertainment, рассказывает о требованиях к созданию игрового функционала. Что понадобится, а что – нет в этом творческом процессе?
Быстрый вопрос: если вы делаете игры, принадлежите ли вы к индустрии программного обеспечения?
Краткий ответ – нет. Более развернутый – отчасти да, но в целом нет. Если быть точнее, геймдев относится к индустрии развлечений, а значит ваша задача как разработчика игр – развлекать людей. Поднимать им настроение и придавать уверенности в себе. Создавать красочные, захватывающие игровые миры, куда им захочется погрузиться с головой. За выполнение игровых задач игроки могут получить реальные награды (развитие сюжета, красивый арт, классные кат-сцены).
В то же время, любой текстовый редактор наподобие Microsoft Word предлагает множество функций, с помощью которых можно набрать что-то вроде отзыва о книге. Помимо этого, вы можете сохранить набранный текст или передать данные на устройство вывода, например, принтер.
Суть разработки программного обеспечения заключается в создании продукта, который служит определенной цели. Вам не нужно создавать данные для ПО кроме тех случаев, когда речь идет о справочных документах. Конечный пользователь сам создает эти данные – отзывы о книгах, ведомости, инвойсы, учетные записи, цифровой арт и т.д.
Это все к тому, что развлекательная функция игр – вещь очень абстрактная. И чтобы исполнить это неоднозначное человеческое желание, нам приходится разрабатывать ПО в качестве инструментария для последующего производства игрового контента.
1. Вам нужен инструментарий (ПО) для создания интерактивного геймплея.
2. Вам нужны данные – классы игроков, враги, сюжет, – с которыми игроку будет интересно взаимодействовать.
3. Вам нужно убедиться, что данные и соответствующее ПО оптимизированы для удобства игроков.
В этой статье речь пойдет о требованиях к игровому функционалу. На первый взгляд может показаться, что реализовать список функций в соответствии с определенными критериями проще простого. Но все может запутаться очень быстро.
Создание игр – это сущий бардак
Требования к функционалу постоянно меняются. Стоит вам приступить к работе над чем-то одним, скажем, функционалом боя, как вскоре вы обнаружите, что для него нужно создать систему предметов, динамическое окружение, которое вдобавок может влиять на способности определенного класса персонажа, и пошло-поехало.
Чтобы не быть голословной, в данной статье я буду приводить примеры из проекта, над которым работаю, – это мобильная игра с акцентом на PvP-сражениях Monster Roller. Ниже приведены три макета одной и той же системы боя, демонстрирующие, как сильно игра может отличаться от первоначальной задумки.
Ранняя версия игры показана на скриншоте слева, а конечная версия – на скриншоте справа. Текущую версию сделали максимально доступной для понимания: если выбрать режим действия (режимы обозначены цифрами 2-1-1 рядом с аватарками монстров), монстр совершит соответствующее действие после вращения барабана слот-машины. 1 – режим атаки, 2 – режим использования способности, зависящей от роли конкретного монстра.
Первое, что приходит в голову при виде игры с RPG-подобной системой боя, это система предметов, бонусов, магазин и т.д.
«Почему вы не додумались, что вам все это понадобится?»
«Почему вы не додумались, что вам все это НЕ понадобится?»
Создание игр – это бардак, потому что настоящее новаторство – всегда бардак. С другой стороны, инновации могут быть «итеративными», когда создание чего-то нового происходит на базе уже известных формул. В разработке игр в той или иной степени используются оба подхода. И хотя разработчики могут быть привязаны к определенным формулам (так, гоночная игра подразумевает своеобразные треки, бонусы и т.д.), в конечном счете, у вас не получится приготовить точно такой же коктейль как у других представителей индустрии, где многие трудятся по восемь часов в день совершенно бесплатно, лишь бы найти Святой Грааль развлечений.
Создание игр – это поучительный опыт. В начале вы абсолютно уверены в том, какой будет игра.
Но эта башня вечно находится на грани падения. Может оказаться, что ваша игра совсем неоригинальна, или механики настолько разные, что их не стоило использовать вместе, или она классная, но в ней тяжело разобраться. Определенный уровень опыта, конечно, помогает сгладить углы – старожилу индустрии будет легче обойти подводные камни, чем новичку. Но в любом творческом процессе случаются… неожиданности. В этом и заключается идея свежего, новаторского подхода.
Эволюция требований к функционалу
Мы начинаем с расстановки приоритетов на основе того, насколько важной для игры является отдельная фича. Затем мы создаем прототипы того, что хотим заложить в игру, используя выборочные данные. В этом разделе статьи мы рассмотрим компоненты системы боя.
В самом начале у нашей команды Monster Roller было несколько идей, которые мы хотели реализовать в игре:
• Геймплей во многом должен был напоминать RPG, но также включал бы в себя элементы баланса карточных игр;
• Разумеется, мы хотели добавить барабан слот-машины…
• …который бы выдавал бонусы на базе джек-потов (тогда еще 4 в ряд);
• Мы рассматривали коэффициенты ставок;
• «Удержание» – функция, которая не дает слоту вращаться (само собой, за определенную плату);
• Возможность переключаться между монстрами во время хода;
• Применение предметов на монстров (очевидно, не правда ли?).
И это далеко не полный список, а так, наброски. Требования к функционалу могут включать в себя, помимо прочего, подробное описание того, что в них войдет (собственно, данные), как они будут отображаться (интерфейс), а также показатели эффективности, демонстрирующие, работает ли функционал так, как задумано.
Для примера рассмотрим систему предметов:
1. Какими будут особенности предмета? Будет ли он использоваться на команду игрока, команду противника, или на обе? Будет ли у него срок действия? На какие переменные могут влиять предметы? Уровень здоровья? Сила атаки? Показатель регенерации? В процентах или целых числах?
2. Можно ли использовать предметы после боя или они расходуются в бою?
3. Есть ли стоимость использования предмета? Как реализуется эта стоимость? Будет ли это число ходов в бою (стоимость времени) или что-то другое? Нужно ли будет покупать предметы в магазине? Если да, то за твердую или мягкую валюту?
4. Как они будут выглядеть?
И так далее. Документ, содержащий ответы на эти вопросы, называется списком требований к функционалу.
Теперь давайте рассмотрим сам бой в свете эволюции всех этих систем и функций.
Макет слева был создан вашей покорной почти полгода назад. Макет справа разработал настоящий художник, и именно так выглядит бой сейчас.
Следующие скриншоты демонстрируют, как изменились требования к функционалу.
Старая верхняя панель:
Новая верхняя панель:
И там и там есть индикатор золота и кнопка настроек. Кнопка автоигры, которую можно увидеть на прототипе, в последней версии переместилась на нижнюю панель (см. ниже).
Самая большая перемена – это появление таймера и огоньков вокруг рамки, реагирующих на то, что происходит в игре. Мы добавили таймер, поскольку имеем дело с PVP-игрой – ждать, пока ваш противник на другом конце мира бесконечно долго решает, как ему атаковать, было бы совсем печально.
Старый экран боя:
Новый экран боя:
Как вы можете заметить, на старом макете не было индикаторов выбора (стрелочек вверху левого скриншота новой версии), равно как и индикаторов положительных/отрицательных эффектов (обратите внимание на крохотного монстрика). Кроме того, изменилось отображение монстров в бою. Еще одно важное решение, к которому мы пришли, – сократить количество монстров с четырех до трех. Таким образом мы повысили скорость боя и увеличили шансы получить джек-пот.
Барабаны и аватары, старые и новые:
Тут мы много чего поменяли. Сначала взглянем на символ вишенки. По задумке игрок зарабатывал вишни за каждый раунд боя, и они постепенно накапливались. Кроме того, их можно было получить в качестве приза, сыграв на слот-машине. Подобно мане или энергии в карточных играх, вишни можно было потратить на использование предметов или переключение монстров. Тем не менее, впоследствии мы отказались как от системы предметов, так и от вишен.
Мы добавили вишенки не потому, что так делают все. Мы добавили их, чтобы сократить фактор везения и поставить акцент на важности выбора того или иного действия игроком. Буду ли я использовать ЭТОТ предмет или переключу вот ЭТОГО монстра? То есть у нас были веские причины, чтобы добавить в игру предметы и стоимость их использования.
Так почему же эту систему забраковали?
Взглянув на переменные, характерные для игры с битвами монстров, вы увидите много факторов, которые можно контролировать без добавления еще одной системы.
1. Выбор цели: использовать авто-атаки или сосредоточиться на одном противнике?
2. Способности: атака, баффы/дебаффы, защита, регенерация, сильные и слабые стороны стихий.
3. Комбо: джек-поты «3 в ряд», монстры, способные повышать атрибуты напарников.
4. Состав отряда: влияет на шанс выпадения комбо.
5. Время на ход: ограниченное количество времени на принятие решения.
Бывает очень заманчиво добавить фичу на ранней стадии разработки. Так происходит потому, что на этом этапе еще сложно представить, как разные фичи взаимодействуют между собой и влияют на геймплей. А вот поддаться мысли «нужно больше функций», наоборот, легко, поскольку контента как такового еще нет. Создание прототипов здорово помогает преодолеть соблазн раздувания функционала. Систему предметов пришлось бы балансировать со всеми вышеупомянутыми переменными, причем не только разработчикам, но и самим игрокам. Суть в том, чтобы каждая переменная могла повлиять на исход битвы, а не чтобы их просто было побольше.
Как ни странно, в этой секции интерфейса есть еще две переменные, о которых можно говорить очень долго. Это принцип вращения барабанов и нанесенные на них символы (Есть ли у слот-машины функция удержания? Как она выдает выигрышную комбинацию? Как слот-машина отреагирует на оглушение монстра? По какому принципу формируются сочетания символов? Все ли слоты дают игроку шанс получить джек-пот? И так далее). Но пока что простого упоминания этих переменных будет достаточно, чтобы понять, как менялся этот функционал.
Последнее, что мы изменили в этом сегменте, это кнопка Let’s Roll. Хотя изначально нам казалось, что вращать барабан движением пальца по экрану будет весело, многие плей-тестеры (плей-тест – отличный способ определить требования к функционалу) высказались в пользу отдельной кнопки. Вот мы и добавили ее, чтобы сделать игру более интуитивно понятной. Хотите кнопку – пожалуйста!
Старое нижнее меню
Новое нижнее меню
Итак, мы добрались до последнего элемента – нижнего меню. На скриншоте из старой версии отображается стоимость предметов и переключения, но в итоге мы оставили только кнопку автоигры и переключатель. Еще одним поводом для тщательного упрощения системы, учитывая всякую всячину, которую пользователь должен держать в голове, является эффективное использование экранного пространства. В игре Monster Roller и так полным-полно иконок, джек-потов, элементов и целей. Если бы мы добавили еще один набор визуальных элементов, игроку пришлось бы запомнить еще больше.
Уф, это была длинная статья.
Итак, выделим основные моменты:
1. Разработка игр находится на пересечении индустрий разработки программного обеспечения и развлечений. Для того, чтобы ответить на вопрос «что значит весело?» нужно использовать знания из нескольких областей.
2. Не привязывайтесь к устоявшимся требованиям к функционалу. Элементы игры меняются в процессе разработки, и зачастую самым удивительным образом.
3. Любая игра сочетает в себе спонтанные и итеративные инновации.
4. Требования к функционалу нельзя вместить в один список. Подумайте, как фича будет взаимодействовать с другими элементами игры, а затем перечислите все возможные способы ее реализации.
5. Создайте прототип функционала на базе требований и изменяйте его по мере необходимости.
6. Продолжайте, пока не поймете, что это оно.
Поздравляю, вы дошли до конца. Вот вам яишенка с беконом.
Автор: Plarium
