Я закончил последнюю миссию в Extreme Landings на мобильном телефоне. C чувством глубокого удовлетворения отложил мобилу, выдохнул и закрыл глаза. Адреналин последней успешной посадки с сильным боковым ветром и сломанным рулём направления давал о себе знать. Захотелось чего-то более медитативного. В голове смутно нарисовалась изометрическая проекция реки, по которой плывёт судно. Возможно даже под парусом. Оно пристаёт к берегу, а затем делает красивый разворот в русле реки… Вот прям тут мне вдруг захотелось сделать быстренько и простенько прототип, где можно было бы (вы будете смеяться) красиво разворачиваться по дуге. Ну простая физика, без учёта сопротивления среды, задействованы только скорость, ускорение и разворот. Игродел из меня никакой, познаний в игровых движках никаких. Опыт в игроделании — есть, но не совсем тот, что нужен. Был опыт работы в уже запущенном проекте, а не написание чего-нибудь с нуля. Значит, париться с движками не будем. Мне вполне подойдёт браузер и JavaScript, а рисовать буду в Canvas — он ведь как раз для этого предназначен. Чтобы вы понимали уровень притязаний на тот момент — мне хотелось чего-то такого: Тут я понял, что корабль из квадрата так себе: не видно направления движения. Надо рисовать примитивный для пользователя какой-то интерфейс, указывающий направление, а ещё лучше — добавить спрайты. Ведь раньше нормальные люди делали всё на спрайтах, даже в DOOM II были спрайты и игралось просто огонь.    В процессе поиска в интернете наткнулся на сайт с собранными из игр и скомпонованными спрайт-листами. И, о божечки, посмотрите! Спрайты из Eliminator Boat Duel! Те самые лодки, можно вставлять хоть в изометрическую проекцию, хоть в вид сверху. Красота. На самом деле отсюда мне нужен набор спрайтов для катера. Причём одного.  Почему бы не построить прототип, сразу заодно научившись на хорошем спрайт-листе расставлять нужные спрайты?  Теперь нужно внимательно посмотреть на набор спрайтов, прикинуть, сколько их нужно на полный оборот и посчитать углы направлений для каждого из них. На картинке выше видно довольно детальный набор для поворота от 0 до 180 градусов, а вот от 180 до 360 будем отражать зеркально. Дальше грубая сила в виде проставления координат и размеров для каждого спрайта (загоняем их под номерами в конфиг спрайт-листа), немного чистой арифметики для углов поворота и отдельный метод с кучей if-else if, который получает угол текущего направления игрока и берёт соответствующее изображение. Выглядит топорно. Вот эти «волшебные номера» (11.25, 22.5, 33.75, 45...) — это угол поворота, при котором рисуем конкретный спрайт. Например, при направлении 45 ± 5.625 градуса показываем спрайт под номером 4. При смене спрайтов почти наверняка придётся волшебные номера пересчитывать, но сейчас это точно работает.  Хм, точно работает? Проверяю: Да! И-де-аль-но! А следующим на глаза попался спрайт-лист, где был красивый лабиринт из травы / камышей, с водной поверхностью. Причём обалденно структурированный, с пояснениями прям на картинке. То, что надо.  Но для начала я взял просто один кустик травы и один тайл с изображением водной поверхности. За пару-тройку дней интенсивного чтения интернетов и клацанья по кнопкам — смастерил на коленке уровень со слоем рендера и со слоем препятствий.  Банально забил два двумерных массива: один — для расчёта коллизий со значениями 1 и 0, второй — для отрисовки в Сanvas, где каждое число может соответствовать определённому тайлу. То есть я решаю что 0 — это нет коллизии, 1 — это препятствие. А для красивого отображения на препятствии рисую камыши, на проходе — воду или изредка кувшинки. Написал обработчик коллизий, который в некоторых случаях позволял застрять в текстуре. Всё как у настоящих гейм-девелоперов! Даже сделал «камеру», которая отображает только видимый кусок уровня и скроллит отображаемую зону при движении игрока. Это был уже небольшой, простенький игровой движок, с реализацией прототипа игры. Теперь это выглядело примерно так: Смотрите какая красота: всего 3 тайла для уровня и кораблик, а как сразу выглядит. С одной стороны — я был готов фигачить уровни. А с другой — представил, что это будет не мой тестовый квадратик в 20 на 20 тайлов, а более-менее серьёзный уровень, скажем, 200x200. Перспектива пугала, примерно так же, как могло бы пугать переписывание всего написанного кода в машинный код ручками. Один уровень — ну ладно. А захочу другой — опять упарываться и расставлять это всё? Эй, в конце концов, я хоть не настоящий разработчик игр, но всё же программист — не хочется делать руками. Значит нужно генерировать! В этих размышлениях я плавал туда-сюда по карте и начал замечать, что вот тут прорисовка не такая плавная, как хотелось бы. А вот здесь неудачно перерисовываются стыкующиеся тайлы при скролле — становится видно полоску с белым фоном, которая сразу же скрывается тайлами. В общем — я похоже собирал те грабли, которые уже были собраны ранее всеми, кто писал игры и игровые движки.  Раз уж собрался что-то делать с генерацией уровня, то надо сделать что-то ещё и с отрисовкой. А ещё кода в игре стало заметно больше. Теперь меня уже начало раздражать, что я не всегда помню, какие свойства есть у объекта, прилетающего в метод, который правлю. IDE старалась, помогала изо всех сил, но не всегда это у неё получалось. Нужна типизация — и логичным образом на ум пришёл TypeScript, в котором можно всё красиво уложить в классы, типизировать свойства объектов и всё, что попадётся под руку.   Дальше последовала неделя, в течении которой я скачал игровой движок Phaser 3. Разбирался в устройстве, в терминологии, читал документацию, разбирал код примеров, думал, как прикрутить TypeScript вместо JavaScript, как это всё завести, как переписать уже работающий прототип на работающий прототип в Phaser… Сугубо рутинная работа. Основные рассматриваемые механики движения были две: движение карты навстречу игроку — сверху вниз по экрану, примерно как в игре SpyHunter. Второй вариант — генерировать отдельный уровень целиком и ставить игрока на него. Остановился на втором варианте, посчитав, что это больше похоже на то, что хочу видеть: движение в произвольном направлении, исследование карты. Значит будем гонять на катере по лабиринту и собирать звёзды. Вообще это должны были быть спасательные круги, но подходящих картинок не нашлось, поэтому – звёздочки из ассетов с уроками движка. На всю следующую неделю моим любимым чтивом стали: Википедия, redblobgames.com и переводы на Хабре от @PatientZero про всякие игроделательные штуки. Я читал, думал, надо оно мне или нет, рисовал что-то на бумажке, перечитывал, рисовал, считал и так много раз. В конце концов для реализации остановился на методе Basic BSP Dungeon generation. В принципе, несмотря на то, что это метод уже весьма старый, его хватает, чтобы собрать работающий генератор лабиринтов. Идея проста: есть исходное пустое пространство карты. Делим его на две равные или примерно равные половины. Потом каждую половинку делим ещё раз и повторяем до тех пор, пока полученные зоны не станут слишком маленькими для дальнейшего деления. Например, у нас есть карта 100x100, делить будем в пределах от 40% до 60% размера и по очереди — сначала по вертикали, потом по горизонтали. Считаем, что зоны, где оба размера меньше 20, нам не интересны. В процессе сохраняем результат деления в дерево — это нам понадобится, когда начнём соединять комнаты коридорами.   После того как всё разделено, генерируем в последних зонах комнаты. Поднимаемся по сохранённому дереву выше от листьев к корню, генерируем комнаты, соединяем коридором с ранее сгенерированными комнатами. Повторяем, пока не дойдём до корня. На выходе получаем готовый лабиринт, в котором все комнаты наверняка соединены. Метод требует поиграться параметрами в процессе генерации, но результат хороший. Для Roguelike игр — то, что нужно. Выглядит это так:   Поскольку прямоугольные заводи — дело не самое частое в дикой природе, начал думать, как можно генерировать не просто квадратные комнаты, а что-то более интересное.  Изучая материалы по генерации уровней и лабиринтов, наткнулся на Хабре на статью «Генерация подземелий и пещер для моей игры». Понял, что теперь нужно использовать клеточный автомат, который из нагенерированных прямоугольных комнат и коридоров сделает формы, напоминающее отдельные заводи в лабиринте из камышей (если это каменные стены — то будет выглядеть как пещеры). Как он это делает? Весьма интересно: Принимаем, что у нас каждая клетка может находиться в одном из четырёх состояний: мёртвая (М), живая (Ж), условно мёртвая (МУ) и условно живая (ЖУ). Мёртвая — прохода нет, и клетка не изменит своё состояние на следующих итерациях. Живая — это проход, которые не изменяет состояние на последующих итерациях. Условные клетки — это клетки в суперпозиции и в каждой итерации они для расчёта имеют состояние живая / мёртвая, но на последующей итерации могут изменить состояние по определённым условиям. Сразу помечаем весь периметр уровня клетками М, а также границы между поделёнными зонами. Так в процессе работы клеточного автомата эти комнаты не сольются и между ними всегда будет граница. Одного ряда хватит.   Сгенерированные комнаты и коридоры заливаем клетками Ж. Они ни не должны меняться. Клетка МУ на каждой итерации проверяет соседей: если имеет 4 и более соседа в состояниях М и МУ — на следующей итерации будет в состоянии МУ. Клетка ЖУ — превратится в МУ, только если количество соседей М и МУ будет равно 5 и больше. Вроде это все необходимые ограничения, на которых можно строить клеточный автомат.   Здесь показана проверка, как генерируются разные варианты лабиринта, а потом несколько итераций клеточного автомата поверх. На сам клеточный автомат я потратил несколько часов. Потом ещё полчаса на то, чтобы он принимал на вход размеры лабиринта, а на выходе отдавал сгенерированный лабиринт в нужном виде для игры. Проверил рендер, корректность обработки коллизий.  Ну и пару-тройку часов ушло на расстановку полноценного набора спрайтов окружения: нужно учитывать, что генератор создаёт по факту карту коллизий, из которой вторым слоем (он рендерится в спрайты) нужно сгенерировать карту тайлов. Например камыши — это стенка, но есть отдельные тайлы для камышей у воды, камышей в центре стены, камышей на повороте.   А по водной глади для интереса нужно раскидать кувшинки, которые не преграждают путь, но смотрятся красиво. Положение кувшинок также генерируется случайно. Просто при расстановке тайлов типа «проход» с каким-то шансом генерим не воду, а кувшинку на воде. Чтобы хорошо смотрелось — пришлось подбирать коэффициенты.   Всё. Уровень сгенерирован и готов!   Следующая мысль спустя какое-то время плавания: «Скучно плывём». Что можно добавить для скорости? NITRO — ЗАКИСЬ АЗОТА! Здесь всё довольно просто: с одной стороны это должно быть явное ускорение, но с другой стороны — после окончания действия обычная скорость не должна вызывать ощущение черепашьего шага. Количество NITRO и время действия должно быть ограничено, а для интереса — их на карте должно быть несколько штук, чтобы игрок мог собрать.   Ну вот сейчас точно всё. Прототип готов. При старте уровня под капотом запускается генерация лабиринта, в полученный лабиринт расставляем игрока, звёзды, NITRO. Всё это отрисовываем и можно плыть! Исходный код тутПоиграться в результат можно здесь  Разработчик. PHP, JS, TypeScript.