Дальше команда (художник, звукорежиссёр) тебя спрашивает, что чувствуешь, что видишь в этом. Какие-то одиночество, непоколебимость, пространство. Объясняешь, что тебе нужно. Например, говоришь звукорежиссёру, что нужна основная музыка, музыка в режиме паузы, в таком-то и таком-то стиле. Даёшь примеры. Буквально словами говоришь: «бдыж», «бдаамс». Или описываешь какую-то ситуацию, мол надо представить, как происходит вот это, с каким звуком бы это произошло.
Потом работа над ошибками, прослушивание-переслушивание — где-то высокие частоты убрать, где-то уйти в глубину басами. Попробуйте, в общем, поиграть с наушниками.
Death Mode
В режиме смерти на карте появляется намного больше объектов и они ведут себя иначе. У игрока есть 8 инструментов борьбы с ними. Например, оружие, которое позволяет очищать всю карту разом. Всё лопается, вжикает. Это вызывает приятные ощущения очищения, лёгкости, почти катарсиса. Залипательно. Помните, как в игре, где собираешь в ряд одинаковые шарики и они взрываются, и затем выкатываются новые? Это очень похоже.
Этот режим появился в самом конце разработки. Буквально за месяц до конца проекта. Он пришёл спонтанно, вместе с новым названием (до этого было выбрано название Shuttle). Я читал несколько книг о том, как правильно делать игры, и какие 100 правил стоит соблюдать при разработке, чтобы игра была годной.
Одно из правил — фан, или получение удовольствия. Если игрок не получает фан — игра скучная. Фан получать сложно, и должна быть какая-то изюминка. И здесь она в том, что сначала всё просто, а потом — всё плохо.
Child mode
Это требования моего ребёнка. Он хотел, чтобы некоторые вещи лишний раз его не уничтожали и не бесили. В целом детям нет дела до хитрого сюжета или графики. Больше сенсорного взаимодействия с игрой — это для них. Тыкать аномалий, чтобы они лопались, и имелись другие мелочи — придуманы, сделаны и протестированы. Подумал, что если ребёнок говорит про свои желания, то что-то в этом есть — надо пользоваться.
Возможность создания профайлов
Для каждого профайла создаётся своя таблица с результатами для разных уровней. Чтобы можно было, например, и самому поиграть и ребёнку дать. Каждый пользователь набирает очки и получает оценку общей эффективности в итоговой таблице, где его результаты сравниваются с его предыдущими результатами.
Кому игра может зайти
Я не занимался исследованием целевой аудитории и не играл в игры последние 7 лет. Нонсенс. По результату опросника IARC, знаю, что Buran-19 рассчитана на детей от трёх лет. И надеюсь, что она обладает достаточным уровнем эстетики, чтобы понравиться и взрослым.
Возможно, она придётся по нраву тем, кто любит игры, которыми я вдохновлялся:
Homeworld — тактическая космическая стратегия, в которой ведутся боевые действия. Я в неё, наверное, играл лет в 11. Она меня настолько впечатлила, что, можно сказать, «inspired me». Это было как раз то космические, что я никогда больше в жизни-то и не видел. Я до сих пор помню её!
Limbo — survival horror, где мальчик в мрачной атмосфере пытается найти сестру. Она меня поразила своей механикой и эстетикой, вдохновила меня тем, что использует просто движок Box2D, и на libGDX можно сделать более-менее то же самое.
DISTRANT — бродилка в жанре психологического хоррора, где ты решаешь пазлы. Всё сделано в пиксель-арте. Её создал один финн вместе со своей женой. Меня очень воодушевило, что у этой не самой сложной игры на libGDX (если я не ошибся) миллион скачиваний.
Этапы разработки
Есть два пути в разработке: «беру и делаю» и условно правильный. Сначала я пошёл по первому.
Мой опыт «беру и делаю»
Всё началось с того, что на учебном модуле по разработке игр на Android мой преподаватель предложил делать аркаду по типу арканоидов. Там в нижней части экрана кораблик, на него сверху летит космос, появляются враги и ты стреляешь в них пульками. На этом примере человек хотел показать, как изнутри устроены игры и познакомить нас с опенсорсным Java-фреймворком libGDX.
Тогда я только примерно понимал, как делаются игры. Знал, что есть программисты и художники. Есть мультипликация, сменяющиеся кадры. Из-за оптических обманов и несовершенства глаза мы воспринимаем более 24 кадров в минуту как интегральную величину и видим движение. Мне было интересно разобраться, как это всё программировать — курс оказался в нужное время и в нужном месте.
Только сам жанр арканоида мне не понравился. Возникла идея сделать свою игру, которая бы отличалась от других. Я по жизни хочу делать что-то своё. Поэтому решил, что у меня кораблик будет летать не влево-вправо, а куда хочет. А вместо стрельбы пульками будет собирать вещи и использовать предметы.
В классических арканоидах нужно выжить максимальное количество времени, ускоряясь и набирая очки. У моего же кораблика появилась дополнительная цель — помогать космонавтам, летающим в открытом космосе. Тогда это показалось мне чумовой идей. Я нашёл примерные спрайты в интернете: космонавтов, кораблик, аномалии. И начал писать. События развивались, и игра преобразовывалась. Забавно смотреть, какие изменения были в течение времени.
Писал и разбирался с фундаментальными вещами из модуля. Как работает asset-менеджер, система частиц, как передавать движения, как запускать игру в телефоне на различных разрешениях, как правильно работать с координатами OpenGL, мировыми координатами, матрицами перехода, детекцией коллизий, с объектами в игре. Самыми интересными моментами для меня оказались вещи описанные ниже.
Определение коллизий. Коллизия — столкновение предметов и производство результата столкновения. Там возможна факториальная сложность, потому что каждый объект может взаимодействовать с каждым. Классический пример, для понимания детекции коллизий — заставка на Windows с пузырями, которые меняют цвет от столкновений. Когда есть 1000 пузырей, которые могут взаимодействовать друг с другом, то, по сути, нужно каждый из них проверить на то, а нет ли сейчас взаимодействия с другими 999 пузырями. Для этого есть разные алгоритмы, с которыми мы не знакомились. Наш детектор коллизий — это бесконечный цикл fori по всем объектам :)
Asset-менеджеры. Есть целые классы, которые позволяют работать с ассетами: звуками, картинками, фонтами. В игре выходит, что всегда виртуально рисуется одна здоровенная картинка, обрезанная в нужных местах. Эту картинку — TextureAtlas, надо формировать из отдельных спрайтов. И тогда в графическом процессоре нет бесконечно переключения контекста, игра не тупит, ресурсы не тратятся. Как это организовать — задача интересная, особенно для 3D игр. В 2D достаточно соблюдать некоторые базовые принципы и их потом проверить в игровом режиме.
Эмиссия объектов. В тех же арканоидах, когда вылетает пулька и нужно стрельнуть следующей, можно пойти двумя путями. Первый — берёшь и каждый раз генерируешь новый объект. Но это машинное время на выделение ресурсов и ещё много чего, что происходит до того, как объект будет отправлен на рендеринг. Потом нужно ещё очистить эти ресурсы. Второй путь — ты создаёшь пулы объектов и заполняешь их, например, пока идёт полоса загрузки в самом начале, а потом в игре их просто используешь. Соответственно, у нас есть жадный и нежадный способ создания объектов. И здесь тоже появляются интересные задачи: как ты организуешь объектные пулы, эмиттеры, и то, как ты всё это дело абстрагируешь.
Обучаясь, я накидывал всё, что в голову взбредёт. Почувствовал на себе минусы разработки без фиксации фич:
Это бесконечный процесс. Появилась новая крутая идейка, её надо делать — вот и два месяца ушло. Также новая идея может затронуть текущую архитектуру программы и её приходится постоянно переделывать. От этого появляются новые баги, а если игра сложная, то их непросто отлавливать, дебажить и так далее.
Невозможно работать с командой. Новые фичи затрагивают всех участников проекта. Из-за новой идеи художнику порой приходится пересматривать всю концепцию графики. Например, новый ассет может затронуть его чувство прекрасного и он захочет переделать все толщины линий во всех спрайтах. Поэтому бывало такое, что мы стопали проект на квартал. И так пару раз, да-да.
Мой опыт «как правильно»
К правильному подходу я закономерно пришёл, когда появились другие участники проекта и разработка игры стала осознанной, нацеленной на создание продукта. Не сразу, но пришёл!
Как закончился модуль, я уже разрабатывал игру с коллегой из университета. Мы накидывали фичи, в телеге переписывались, мол было бы хорошо добавить ещё и ещё. Потом Саша в один момент сказал: «Cтоп, давай напишем доку».
Первая документация, когда игра ещё называлась Shuttle, заняла 29 страниц. Накидали за вечер: замечания, игра, игрок, монстры, препятствия, список фичей, дизайн, GUI.
Также мы с художником поняли, что без диздока общаемся на разных языках — я называю что-то «кругляшами», а он другим и правильным для него словом, и мы не понимаем друг-друга. Так за время разработки появилось более 20 диздоков. Сотни страниц документации, отдельная папка на гугл драйве.
Вместе с графикой появлялись конкретные юзкейсы. Мы составляли мудборды — то, как что-то в игре должно выглядеть, прорабатывали примеры, работали над ошибками.
Последний диздок, например — астронавты и баффы астронавтов. Что такое астронавт, что в нём должно быть? Их профессии, как они выглядят, что они делают, как взаимодействуют друг с другом, какая логика работы? Потом это всё рождает конкретные техзадания для программиста — допустим, таблицу, которую нужно в программе имплементировать в виде кода или некоторой логики.
Как сделаю в следующий раз
Если ещё столкнусь с подобным проектом, то сразу буду делать правильно. На мой взгляд, этапы разработки должны быть такие:
Анализ рынка и идея. Что первично, наверное, зависит от типа игры. Если это коммерческая движуха, то сначала маркетинговое исследование, а потом идея.
Анализ ресурсов. Теперь нужно обсудить плюсы, минусы, корнер-кейсы, сложности идеи и понять сроки реализации в зависимости от ресурсов. Проанализировать себя или команду. Готовы ли все, например, год по 5 часов в день хреначить. Если готовы — идём.
Написать документацию и зафиксировать план работ. Для игр — это высокоуровневый документ, где отражаются основные концептуальные вещи: количество уровней и графических элементов, модули и компоненты, как это будет изображено в виде окон, какие будут элементы управления, персонажи, как они будут с друг другом взаимодействовать, какие будут эффекты, когда они будут появляться. Это нужно, чтобы задачу потом декомпозировать и покрывать документацией каждую маленькую её часть. Без документации непонятно, что делать и с чего начинать.
Разделение на команды.
Реализация и тестирование.
Конечно, во время waterfall-а можно умереть, и не довести до конца даже дизайн. Но только так будет возможна работа в команде и достижение результата. Ведь в одиночку можно заниматься проектом хоть 6-8 часов в день, но внизу показать общий прогресс-бар, то он сдвинется всего на миллиметр. Команда делает гораздо больше.
Интересные (?) решения
Интересных решений немного, наверное, они больше интересны для меня, потому что я не знал, как это всё делается. В целом мне очень помогли общие подходы в программировании: что надо задачу декомпозировать, использовать шаблоны проектирования, шаблоны программирования, соображать, как работает Java.
Своя система частиц
Система частиц — инструмент, который позволяет делать эффекты. Например, взрыв интересной конфигурации, огонь, какие-то метаморфозы. Как это работает? У тебя в основании графики лежит частица — particle. И суть в том, что она рисуется бесконечное число раз и ты создаёшь законы, по которым её нужно рисовать.
Например, взрыв — одна частица, которой ты говоришь: «Нарисуйся в центре плотно, а потом отходи лучами или по уравнению кривых линий на рандомную величину отступа». Визуально это получается круто. И в итоге тебе в ассетах нужно иметь только одну частицу 16 на 16 пикселей. Либо несколько частиц. С помощью её бесконечного рисования получается красивый эффект.
Решения с эффектами
У меня есть отдельный пакет с эффектами — для работы со звуком, текстом, движением (объекты по-разному ведут себя). Есть утильный класс осцилляторов, которые моргают, меняют пропорцию или размеры. Есть классы, которые обходят ограничения фреймворка. Допустим, когда собираешь объекты, например, осколки от астероидов, то если берёшь сразу десяток, то получается неприятный звук — всё сливается воедино. Мне пришлось делать классы, которые отслеживают количество собранных объектов и вносят небольшую задержку, чтобы как-то гранулировать звук, который воспроизводит программа.
Использование MVC шаблона проектирования при разработке UI
Я использовал Model-View-Controller, который полностью соответствуют подходам в веб-разработке, при разработке почти всего GUI и для сохранения и работы с результатами и конфигурациями.
У меня все конфигурации и результаты хранятся в JSON, соответственно мои дата-классы работают с JSON сторонними библиотеками. Я использовал популярный Jackson.
Торможение кораблика по золотому сечению
Сначала я корпел над изображением ускорения корабля. Там есть специальный объект, ты нажимаешь, и он начинает дико разгоняться — из турбин валит пламя. Но ускорение — полбеды, ещё надо показать торможение. А как? Показать шлейф от кораблика в космосе.
Я долго думал, а потом вспомнил про принципы золотого сечения. Используя спрайты кораблика, которые блюрятся в различную степень, в зависимости от удаления от настоящего объекта корабля, сделал так, чтобы каждый след в шлейфе отставал от предыдущего на число пикселей, которое равно числу в ряде Фибоначчи.
Борьба с вибрацией
Недавно нашёл неприятную вещь. Когда играешь в Death mode и уничтожаешь более 30 объектов, то на каждое уничтожение телефон вибрирует. Вибрация и обращение libGDX к библиотеке, которая отвечает за вибрацию на телефоне, занимает время. Когда говоришь телефону «возьми в одну секунду повибрируй 30 раз 20 миллисекунд», моя Motorola уходит в раздумья. На 10 миллисекунд задерживает геймплей и сразу следующий кадр показывает. Графический процессор всё проиграл, но из буфера кадра ничего не предоставил на экран. Короче, артефакты возникают, когда появляется много объектов.
Сначала я думал отключить вообще всю вибрацию, но это не очень. Тыкаешь в экран, он не отзывается — неприятно. Я придумал, как обойти и в итоге сделал три режима вибрации в настройках: отключить всё, вибрация только UI объектов, вибрация всего.
Такие решения принимаются, когда чуть поиграл и понял, что что-то не нравится. Я предположил, что игрок должен иметь возможность сделать себе удобно сам. Есть телефоны, которые не реагируют на вызов вибрации ниже 30 миллисекунд. Просто вибратор внутри не может меньше чем 50 миллисекунд работать. И я тоже пытался усреднять эти значения.
Эти вещи невозможно понять без 10 телефонов и компании, что тестит игру. Так что я решил это по-своему.
Шейдеры
У меня целых два шейдера — это графическая постобработка. Шейдеры позволяют производить математические преобразования прямо над байтами, которые находятся в буфере кадра.
У меня есть шейдер, который делает экран серым во время паузы. Здесь всё просто — говоришь ему «возьми всё из буфера кадра и умножь на такие-то величины, чтобы цвет стал оттенком серого». При умножении любого цвета на коэффициент ты получаешь его в оттенках серого. Этот шейдер это и делает. Была ещё идея фон замылить — попробовали, получилось так себе.
Есть шейдер, который рисует чёрную дыру. Если в конфигурациях шейдеры отключить, то чёрная дыра — просто спрайт, спиралька с чёрным центром. Когда шейдеры включены, то спиралька не видна, но есть реальная имитация искажения пространства, линзирование. Аномалии, объекты, попадая в неё, искажаются, как в воде. Сначала Саша Фисунов сделал прототип, а потом мы добавили туда разноуровневый блюр и исправили ошибки.
Настройка игрового баланса
Игровой баланс — набор параметров, которые помогают игроку испытывать удовольствие. Игровой баланс обычно делается в виде таблицы с формулами, в зависимости от которых выставляются параметры в игре. И в идеале в таблице нужно менять одну цифру и она рассчитывает всё остальное. Баланс может быть статический — как у меня, и динамический — обычно используется в командных играх, сетевых.
У меня несколько статических классов. Есть пакет configs, в нём класс Rules.java и в нём 418 строчек, из них 326 — конфигурации. Есть ещё отдельные классы для конфигурации звуков, картинок, вибрации телефона, цветов, файлов, куда складываются профайлы и результаты.
Есть два класса — Buffs.java и DeathMode.java, которые меняют начальные конфигурации игры. Эти два класса с течением времени меняют начальное состояние игры. То есть скорость аномалий, их сила, их прожорливость меняется при наступлении определённых триггеров.
В балансе отражено всё: количество аномалий, время их респауна, максимальное количество, количество на старте. И всё это есть по всем типам генерируемых объектов. Есть описания игрока, его скорость, описание способностей подбирать лут, радиусы подбора, его максимальная скорость, скорость при ускорении, баффы по очкам здоровья, броне и лазерам.
Есть параметр, который регулирует визуализацию того, как быстро аномалия умирает, как она это делает, когда она останавливается. Конфигурации того, сколько очков получает игрок, как получение очков будет меняться от уровня игры, врага и так далее. Есть конфигурации астероидов, где написано, сколько их генерируется, с каких сторон, сколько их становится, когда они разрушаются и какими качествами они обладают. Короче, есть конфигурация всего лута и того, что он даёт.
Если брать именно конфигурации игры, звука, вибрации, картинок и изменения игры при переходе из одного режима в другой, то получается около 500 параметров.
Как я настраивал баланс
Чтобы не задерживать игрока слишком долго, я придумал искусственное ограничение — play session time. Это примерно 20 минут — стандартная поездка в метро. Исходя из этого я должен подавать игроку различное количество объектов, чтобы он успел поиграть за 20 минут от начала и до конца. Конечно, если не собирать космонавтов, то будешь играть и 100 минут, и 200, пока не умрёшь сам: будешь с астероидами сталкиваться, попадёшь в чёрную дыру, или тебя просто аномалии замочат. Можно играть долго, но я попытался сделать так, чтобы игроку стало понятно, что круто дойти до 19 уровня как можно скорее. И здесь скорее выбор за игроком: заниматься исследованием мира, или добиться результатов.
У меня есть формула, которая говорит, что каждый уровень игрок получает какое-то количество очков и ему нужно каждый уровень получать их всё больше, чтобы перейти на новый. Очки в основном даются за сбор космонавтов, но есть и другие способы. Я имею базовый уровень очков — в игре он может меняться динамически.
У меня предусмотрено три режима игры — low, middle, high. В зависимости от этого меняется разрешение экрана и «площадь космоса».
Если рассмотреть, например, вырожденный случай, то чтобы собрать 95 космонавтов в уровне low нужно пролететь 4 экрана вниз и 4 экрана вверх. На это потребуется 12 минут, потому что респаун космонавтов так настроен. Чтобы это время уменьшить я изменяю количество очков за одного космонавта — это раз, какой-то базовый набор пунктов в формуле — два, время респауна космонавтов — три.
Дальше я могу делать нормализацию: не будет же космонавт всегда появляться в самой крайней нижней точке, и в самой крайней верхней. У меня есть случайное распределение, и я примерно знаю, что космонавт появляется в одном из 16 участков космоса такое-то количество раз. Соответственно я в уме делю 20 минут на 4 (цифры сейчас беру из головы, всё немного сложнее) и понимаю, что в нормальных условиях игрок будет летать не 20 минут, а 5 минут. Это время до перехода в режим Death mode, где он играет примерно столько же, сколько в обычном режиме. Дальше игра его убивает.
Мой принцип балансировки такой — чтобы игрок быстро заработал очки и достиг наивысшего уровня, а потом я его перевожу в другой режим. Всё это должно уложиться максимум в 20 минут. Всё гораздо сложнее, но работает это примерно так.
В итоге у меня есть 2 цифры: play session time — это количество времени, которое игрок потратит, чтобы полностью закончить игру в двух режимах. А с другой стороны — базовый набор очков, которые ему даёт игра. Меняя эти 2 цифры, я могу полностью изменить ход игры. Конечно, надо руками всё остальные параметры подправить.
Плейтестинг
Тут просто надо смотреть, как играют другие люди. Я заметил, как писал выше, что детям заходит графика, сенсорика, без уклона в сюжет. Но взрослые уже настраивают геймплей под себя. Задают вопросы. Здесь важно посмотреть, есть ли удовольствие, трудно ли начать играть, трудно ли дойти до конца игры. И в этот момент ты видишь всякие баги. Баги, баги, баги. После плейтестинга я дописал порядка 300-400 строк кода, учёл некоторые пожелания игроков.
Я понял, что игрока надо учить играть, без этого никуда. Жалею, что не успел сделать адекватную обучалку — это может стать основной трудностью у игрока. С другой стороны, интерфейс игры позволяет ей наслаждаться и без знания нюансов. Поэтому здесь, скорее всего, будет поле для манёвров и задачи на будущие проекты.
Некоторые режимы игры были выбраны плейтестерами (мой друг, его жена, моя жена, и все наши дети) исходя из их предпочтений, и в них я лично не провёл должного тестирования. Там нашлись всякие мелочи. Взаимодействие с интерфейсом тоже пришлось немного изменить под конец проекта.
Вот некоторые примеры того, что пришлось исправить и доделать:
Написать звуки на «keep going» на каждый важный уровень.
Космос всё равно вылез на планшете — видимо, спрайт не цикличен.
Звук лазера не выключился в один из моментов игры.
Подтверждение при выходе — новое меню.
Эффективность n/100, но не непонятное число.
DeathMode в одну строчку, а не в две — не читабельно.
Изменить стратегию сохранения профиля: каждый символ — добавить описание.
Больше больших букв и поощрений.
Больше ракет.
Больше оружия, чтобы брать и больше мочить. Оружия игрок должен получить вдоволь.
Баг с джойстиком.
Баг с кругляшом очков.
Было ещё несколько пожеланий: различные сортировки, возможности быстро работать с инвентарём. Но это повлекло бы существенные изменения в коде, а на новые тесты времени уже не оставалось. И как я уже говорил, надо фиксировать фичи, и выпускать проект в релиз.
Buran-19 в цифрах
2 года 11 месяцев от идеи до релиза
20000 строчек кода
161 класс на Java
78 звуков — 5 полноценных треков, 9 звуковых атмосферных эффектов, 56 звуков игрового процесса, 10 звуков для UI
153 картинки/спрайта
От знакомства с теорией разработки игр до релиза прошло 3 года. За эти три года перерывов, когда ничего не делалось, было суммарно на год с небольшим. И наверное, ещё один год можно выделить на время, которое нужно было, чтобы чему-то учиться. Читать, разбираться, делать тесты, экспериментировать. То есть осознанная работа велась примерно год.
По загруженности — по-разному. Бывало, что все выходные пишу.
Планы
Доработать проект с оглядкой на отзывы. Уже сейчас хочется допилить визуальную составляющую, добавить эффектов, аддонов, пасхалок. Например, попал в чёрную дыру и перенёсся в другое место, а там куча барахла — собираешь и выпрыгиваешь назад.
Короче, разработать и даже зарелизить игру — дело не последнее.
Если буду делать следующий проект (идеи уже есть), то хочу:
Изучить движок Box2D. Движок — набор правил, которые описывают мир. Это следующий шаг к пониманию того, как происходят коллизии, как устроена физика, как люди описывают это. Например, можно задать вектор свободного падения, создав притяжение как в реальном мире. Всё будет падать сверху вниз, у объектов будет масса, описанные взаимодействия по форме и размеру. В моей игре нет никакого движка — вся физика и всё взаимодействие прописано руками. Настоящий enginless.
Изучить скелетную анимацию. Скелетная анимация — инструмент, который придаёт естественности движениям. Персонажи балансируют, двигают коленями, руками, пальцами. В общем, повторяют движения человека или настоящих объектов, чтобы максимально передать реальность. Со скелетной анимацией игры приобретают прямо-таки новые краски.
«Ну штош...»
Для меня самое важное, что разработка этой вещи доведена до конца. Это тест идеи, и, может, игра так себе и никому не будет нужна. Я уже давно это пережил, я не пребываю в иллюзиях. Знаю, вероятность добиться грандиозных успехов незначительна. Но чисто для себя я добился того, что мне хочется.
Буду благодарен за любую конструктивную обратную связь по игре.
