Введение
Добрый день! Меня зовут Владимир Титарчук, я Game Design Guild Lead проекта «Мир кораблей» в компании «Леста Игры». Наша гильдия объединяет геймдизайнеров из разных отделов разработки продукта, чтобы делиться знаниями, помогать товарищам в разработке, проверять и улучшать дизайны друг друга.
Я много лет занимаюсь разработкой видеоигр, работал с командами разного размера, видел успешные проекты и провалы. Наблюдал как идеи, превращавшиеся за несколько месяцев в полноценные игры, так и почти готовые проекты, которые так и не были доведены до конца. За это время я успел убедиться в одной довольно неприятной вещи: сделать классную игру недостаточно, чтобы её высоко оценили. Особенно это становится заметно в условиях жёстких ограничений по времени — например, на геймджемах.
Геймджем — классный способ быстро найти новые идеи и проверить необычные концепции. Ну и команда, участвующая в нём, тратит больше времени на разработку, а не на синки и коллы. Есть и другие форматы: хакатоны, студенческие конкурсы, соревнования прототипов, внутренние джемы в компаниях. Названия могут быть разными, но суть одна: времени и ресурсов мало, а результат нужно показать быстро.
Проблема в том, что вы можете потратить двое суток на создание игры, а у жюри будет всего две минуты, чтобы оценить её. Именно поэтому сегодня я хочу поговорить о сложности и балансе не применительно к тому, насколько трудно играть в вашу игру, а к тому, насколько трудно правильно её оценить — к демонстрационной готовности игры.
Небольшой дисклеймер
Статья, в первую очередь, предназначается для молодых разработчиков, которые участвуют в командных соревнованиях по разработке игр.
Геймджем — искусство не делать лишнего
А что вообще такое геймджем? Это соревнование, участники которого должны создать игру за ограниченное время: несколько часов, двое суток или неделю.
Как правило, у геймджемов есть тема: «Цикл», «Только один шанс», «Меньше — значит больше» и т.д. После её оглашения начинается работа. Командам из нескольких человек — или даже одного участника — нужно:
придумать концепцию;
написать код и обернуть его в графику;
собрать уровни и интерфейс;
написать музыку и звуки;
протестировать результат;
упаковать всё это в готовый продукт и успеть до дедлайна.
В общем, задач у команд действительно много, но в том и заключается ценность быстрой разработки. Обычно при создании игры можно провести исследование, сделать прототип, посмотреть, что получилось, и переделать неудачные решения.
Однако на геймджеме времени на всё это нет. Решения нужно принимать быстро, а ещё быстрее — отбрасывать те из них, что принимать не нужно вообще. Этому навыку сложно научиться в теории или на словах.
Часто разработчики попадают в ловушку собственного энтузиазма: «умею создавать противников — добавлю их побольше», «классно собираю инвентарь — он будет в игре», «освоил систему прокачки — конечно, она нужна». Потом ещё хочется реализовать катсцену, второй режим, уникальные механики… Стоп! Хватит. Ваше время не бесконечно.
Геймджем быстро учит: делать всё, что вы придумали — не нужно. Но обязательно сделать всё, чтобы игра работала. Грань между этими категориями вы особенно чётко определите ближе к дедлайну. Именно в этот момент вы задумаетесь о том, что игру-то нужно не только сделать, а ещё и презентовать.
Человек, который ничего о вас не знает
Ситуация: осталось полчаса до презентации игры жюри. Меню готово не до конца, игра периодически падает, некоторые уровни не заканчиваются… Но команда смотрит на часы и говорит:
Ещё есть время. Давайте босса добавим!
Знакомо? А бывает и наоборот:
Вроде работает. Архивируем и сдаём.
Тут появляется ещё одна грань — между «игра работает» и «игра готова». Нужно помнить, что собрать игру мало, её нужно настроить.
Сколько бы ни оставалось у вас времени, оставьте его часть на баланс и подготовку к демонстрации. Это время может оказаться самым полезным на джеме.
Почему? Потому что жюри не знает, сколько бессонных ночей вы потратили на проект, или какую невероятную механику вы хотели добавить, но не успели. Как не знает жюри и о том, что баг в игре нашли всего за пять минут до дедлайна. Им всё это неинтересно.
Жюри просто запускает ваш проект и играет. Для них есть только тот опыт, который происходит на экране. Тут уже баланс — вопрос не геймплея, а восприятия игры.
Сложность игры vs. сложность её оценки
Эксперт из жюри может провести с вашей игрой на джеме всего 5-10 — а максимум 15 — минут, если очень повезёт. За это время ему нужно:
понять, что вы хотели сделать;
разобраться в управлении;
освоить базовую механику;
немного поиграть;
увидеть интересные решения;
составить какое-то мнение о результате;
бонусная возможность: получить удовольствие от процесса игры.
Как вы понимаете, даже 15 минут тут не хватит. В этом и сложность геймджемов — в том, как подготовить свою игру к оцениванию со стороны.
До лучшего места в игре эксперт из жюри может просто не дойти. Или он может так быстро пройти весь доступный контент, что просто не увидит той глубины, которую вы вложили в игру.
Парадокс геймджема в том, что слишком сложная игра скроет свои достоинства за стеной непонимания. При этом слишком простой проект не успеет показать свои достоинства вообще.
В условиях быстрой разработки баланс, в том числе, про управление временем и уровнем того, насколько глубоко участники жюри изучат вашу игру. Получается, сложные игры не нужно делать вообще?
Здесь удивятся те, кто под «сложной» игрой понимают Dark Souls и Darkest Dungeon. Сложная игра не обязана быть жестокой.
Тот факт, что игрок умирает каждые 10 секунд, не делает игру хорошей. Сложной может быть даже та игра, в которой пользователь вообще никогда не проигрывает, но при этом постоянно принимает значимые решения.
Количество и качество тех решений, которые игрокам предстоит принимать по ходу игры — одно из важнейших мерил её сложности. Тут и проявляется полезнейший принцип гейм-дизайна: Easy to Learn, Hard to Master или «Легко научиться, сложно стать мастером».
Базовые правила игрок должен понять быстро, а овладеть ими в совершенстве ему должно быть сложно. Это отличное сочетание. Особенно для игры, которую кто-то должен оценить за несколько минут.
Чит-код — хорошо, а девкит — плохо: как обмануть сложность
Если можете, дайте игроку самому выбрать уровень сложности. Классический набор «Легко, Нормально, Сложно» подойдёт, но создавать три полноценных режима игры не нужно.
Иногда, чтобы определить сложность, достаточно одного параметра — им может быть здоровье, скорости реакции врагов, угол восприятия и т.д. В общем, не заставляйте игрока адаптироваться к вашим настройкам, если вы можете позволить настройкам адаптироваться к игроку.
О том, как конкретно можно адаптироваться в зависимости от жанра вашей игры, поговорим позже. Сейчас разберём самый важный инструмент, который начинающие разработчики почему-то часто считают жульничеством — чит-код.
Для игр на геймджемах чит-коды могут быть очень полезны. Представьте: ваш лучший уровень — десятый. Чтобы до него добраться, член жюри должен пройти первые девять. На это ему нужно минимум 20 минут.
Да, в обычном релизе это просто часть опыта игрока. Однако когда перед вами жюри, у каждого из участников которого всего 10 минут на то, чтобы познакомиться со всей игрой, ситуация меняется.
Ваша задача: дать игроку сразу увидеть главное, определив сначала для себя, что это — «главное». Дайте жюри пройти игру в ускоренном режиме, пропустить уровень, пробежать игру с неуязвимостью от врагов. В общем, предоставьте им любой понятный способ быстро дойти до интересного контента. Это не читерство — это демонстрация.
Главное здесь — не уйти в крайности. Да, да, я про девкит. Почему его нельзя давать жюри? Если чит-код позволяет человеку увидеть подготовленный игровой контент, то девкит заставляет его разбираться во внутренностях вашей разработки.
Не заставляйте жюри открывать консоль, искать нужную комбинацию кнопок, вводить команды и думать, как именно вы назвали внутренний идентификатор босса. Жюри нужен доступ к вашей игре, а не к «кухне».
О настройках сложности — немного hidden gems
Поговорим о том, как адаптировать сложность в зависимости от жанра игры. Если вы создаёте файтинг, шутер или аркаду, нужно помнить про возможность настраивать хитбоксы и хёртбоксы.
Хитбокс — область того, что наносит удар при попадании: это может быть конечность, которая совершает удар, или летящий снаряд. Хёртбокс — зона, в которую нужно попасть, чтобы удар или попадание в персонажа, противников и т.д. считалось совершившимся.
В динамичной игре сложно понять, произошло ли столкновение одного визуала с другим. Если на уровне сложности «Легко» «почти попал» будет играться как «попал», а на уровне «Cложно» — как «промазал», это даст нужный результат. Такой недооценённый инструмент на джеме становится настоящим hidden gem’ом: иногда введение подобной настройки даст больше пользы, чем часы изменения визуала.
Другой классный способ изменить сложность — подвязать её уровень на время реакции игровых объектов и сущностей на появление игрока. Чем оно больше (до определённой величины), тем проще играть, и наоборот.
Однако самый простой и популярный способ — это Hit Points персонажа. Универсальный параметр, меняя который мы фактически изменим относительную силу сразу всех источников урона. Упомянутая выше неуязвимость — крайняя степень такого изменения.
Но и тут есть свой hidden gem — изменение отображения шкалы здоровья! Относится оно, правда, не столько к сложности, сколько к восприятию игры, но ведь мы о нём и говорим.
Как это работает? Шкалу HP можно сделать нелинейной: часть «высоких» значений — от 100% до 50%, например — будет шире, чем часть от 50% до 0%. Тогда игрок будет чаще видеть, что рискует жизнью персонажа, чем на самом деле, и ощущать вау-эффект «выживания с малой долей здоровья». Конечно, это не очень честно, а порой может и запутать игрока — ему может показаться, что противники стали бить слабее —, но адреналина точно добавит.
А как настроить сложность в других жанрах? Вот какие параметры мы можем изменить в разных играх:
в стратегиях: количество ресурсов, скорость их получения, стоимость действий, силу противников, количество ходов, стартовые запасы;
в головоломках: количество элементов, время, количество подсказок, сложность комбинаций;
в survival: скорость расхода ресурсов, частоту угроз, доступность безопасных зон;
в гонках: скорость соперников, длину трассы, время круга, штрафы за ошибки;
в карточных играх: стартовую руку, доступные карты, вероятность событий, силу противника.
В общем, почти в любом жанре можно найти параметры, которые позволяют изменить сложность, не ломая саму игру. Главное — научиться их видеть и правильно ими управлять.
Как правильно управлять сложностью
А что вообще значит «правильно управлять»? Давайте разберёмся:
У вас должна быть возможность быстро и легко получить доступ к тем параметрам, которые вы почти наверняка захотите менять.
Лучше менять меньше параметров в больших интервалах, чем много настроек в небольших интервалах.
Не стоит намертво зашивать в код здоровье игрока, урон, скорость, тайминги и даже количество врагов. Гораздо лучше сделать конфигурацию, таблицу, настройки или хотя бы вынести значения в отдельные переменные.
Рано или поздно вы окажетесь в ситуации, когда «нужно будет уменьшить урон в два раза». Гораздо приятнее такую задачу будет решать, изменив лишь одно число, а не отыскав перед этим несколько чисел в пяти разных местах кода.
О том, что игра сложная, можно узнать за 5 минут тестирования. Дальше у вас будут два пути:
Нужный для изменения сложности параметр всего один. Он у вас «под рукой», а поменять его легко. Уложимся в 5 минут, чтобы поправить сложность игры.
Нужных для изменения сложности параметров несколько, а находятся они в разных местах. 5 минут тратим на поиски, ещё 10 на исправление, а ещё 20 — на проверку, что вы ничего не сломали, поменяв несколько параметров в разных блоках кода. В условиях геймджема это недопустимая роскошь.
Что важно сделать, работая над балансом?
Перед командой разработки должны стоять следующие задачи:
Определить способы балансировки.
Создать инструменты для их настройки.
Избежать искушения добавлять фичи.
Подготовить игру к демонстрации.
Для выполнения четвёртой задачи важно научиться смотреть на игру глазами человека, который её не знает — глазами игрока. Представьте, что вы запускаете ваш проект впервые.
Понимаете ли вы, что нужно делать? Интуитивны ли элементы управления? В какой момент вы впервые сталкиваетесь со сложностями? Когда случается первый успех? Когда вы узнаёте о новой механике?
Обратите внимание и на свои эмоции. Есть ли момент, когда вы восклицаете «О, прикольно!», а когда спрашиваете «А что вообще происходит?»
Вот этот путь и есть флоу игрока. Именно его и стоит проверять в последние часы. Если на этом пути перед игроком не встаёт непроходимых препятствий, значит вы выполнили четвёртую задачу.
Если нельзя, но очень хочется…
Так что, в последние полчаса до презентации проекта в него ничего нельзя добавить? Можно! Но с умом и не в ущерб балансу и демонстрационной готовности, о которой мы говорили выше.
А что тогда можно добавить? Можно добавить что-то, что оставляет у игрока впечатление полноценной и законченной игры, причём зачастую это гораздо дешевле, чем кажется. Что это может быть? Вот несколько вариантов:
Интро
Причём это необязательно катсцена. Для короткого вступления достаточно и одного экрана «Вы — последний пилот космического корабля» и кнопки «Начать». Всё, игрок уже получил контекст — теперь он не просто оказался перед набором механик, а вошёл в игру.
Тултипы и подсказки
Это один из самых дешёвых способов улучшить восприятия игры. Не заставляйте человека угадывать управление, а просто напишите: «WASD — движение, ЛКМ — атака, SPACE — рывок».
На уровне закиньте подсказку: «Соберите три кристалла, чтобы открыть портал». Даже две строки текста могут подарить человеку пять минут геймплея, а на геймджеме — это практически вечность.
Кстати, если у вас нет времени и на это, то хотя бы readme.txt файл приложите к игре. Помните, что найти его должны и без вашей помощи, а открыться он должен в любом редакторе. Удивительно, но многие и этого не делают, а зря.
Экраны загрузки
Если между уровнями есть пауза, превратите её в часть игрового опыта. Там может быть название следующего уровня, совет, описание механики, небольшая история или красивая иллюстрация — то, что вы сможете добавить быстро и без особых усилий.
Задача такого экрана, опять же, не показать, насколько ваша команда крутая, а сделать так, чтобы техническая пауза таковой не воспринималась. Так что показывать что-то сложное необязательно.
Победа и поражение
Очень многие джемовые игры заканчиваются примерно так: «You Win!» И всё.
А ведь победа — это тоже часть игрового цикла. Пусть игрок увидит:
ПОБЕДА!
Счёт: ...
Время: ...
Количество побеждённых противников: ...
[Играть ещё раз]
То же самое с поражением. Нужно оставить не просто «Game Over», а:
Вы проиграли.
Остался один враг.
[Попробовать снова?]
Вроде бы мелочь, но теперь это уже выглядит как законченная игра.
Музыка и звук
Музыка — один из самых мощных инструментов восприятия. Один и тот же игровой процесс в тишине и с хорошей музыкой ощущается совершенно по-разному, причём проекту для джема совершенно не обязательно иметь длиннющий саундтрек.
Иногда один хороший трек может быть полезнее пяти случайных. Да и в условиях джема музыку можно и с ИИ-инструментами создать, а это точно быстрее и проще.
Такая же история и со звуками. Звучать должно попадание и получение предметов, победа и поражение. Это же не просто украшение, а канал обратной связи, с помощью которого игрок начинает глубже чувствовать игру.
Главное правило последних минут
У быстрой разработки есть один особенно неприятный закон: лучшее — враг хорошего. В начале джема можно мечтать, в середине — экспериментировать, но ближе к дедлайну режим работы должен измениться.
Здесь ваша задача не в том, чтобы улучшить идею, а в том, чтобы довести игру до состояния, в котором её можно показать другому человеку. Это совершенно другой тип работы.
Игра уже работает? Не добавляйте новую механику. Уровень уже интересный? Не стройте новый. Интерфейс понятный? Не переделывайте его только потому, что у вас осталось двадцать минут. Потратьте это время на то, что игрок действительно увидит:
баланс;
исправление очевидных ошибок;
обучение, тултипы, подсказки;
обратную связь;
музыку;
экраны победы и поражения;
настройки сложности.
Да, эти вещи могут показаться менее впечатляющими, чем новая фича, но именно они и отделяют игру от прототипа. С ними, кстати, тоже работает правило «лучшее — враг хорошего». Лучше сделать достаточно хорошо пару-тройку пунктов из списка выше, чем всё внимание уделить доведению до идеала одного.
К тому же золотое правило «80/20» (80% работы занимает 20% времени, оставшиеся 20% работы занимают 80% времени) никто не отменял! Поэтому улучшайте в этих доработках только то, что с первого раза не работает.
Подводя итоги
Геймджем — это гонка, но не за количеством реализованных механик. Здесь важно за ограниченное время создать понятный, интересный и законченный игровой опыт.
Так что не бойтесь делать меньше и упрощать! Дайте игроку больше здоровья, сделайте первый уровень лёгким, введите в игру чит-код механику, уберите половину задуманного контента вообще.
А что обязательно нужно оставить? Время самому себе на баланс! Именно на этой стадии идея начнёт превращаться в игру. Ну и помните три главных правила: Easy to Learn, Hard to Master, лучшее – враг хорошего и «80/20».
Игрок должен быстро понять, что от него хотят, но у него должна быть возможность прокачаться. А вы как разработчик должны в условиях геймджема дать игроку эту возможность настолько быстро, насколько позволяет время.
Да, у вас может быть два дня на создание игры. Но у игрока будет всего две минуты, чтобы решить, нравится она ему или нет.
Спасибо, что дочитали статью! Не забудьте поставить плюсик в карму и поделиться материалом с друзьями.
В комментариях расскажите о вашем опыте участия в геймджемах. Участвовали ли вы в них? Побеждали ли? С какими проектами? А какие лайфхаки вы для себя открыли? Пишите — обсудим!
