Попробовав различные направления для игр с машинками вернулся к концепции исследовательского гоночного квеста и собрал демо на актуальной версии движка Годо. Игрок здесь управляет биомашинками - инджинами - которые могут доставлять грузы, телепортироваться из мира в мир, подбирать и использовать особые устройства.
Проект написан на движке Godot 4+ и имеет билды для windows и линукса:
мини-видеонарезка
В демо можно покататься на различных биомеханических инджинах (пять машинок), открывая их по ходу исследования. Специальные порталы переносят машинку в другие миры, если хватает заряда.
В мирах (два мира доступно), помимо разных странных штуковин, можно обнаружить грузы, за доставку которых полагается награда, а также особые устройства, которые машинка может таскать с собой.
Для улучшения картинки в настройках можно включить SDFGI-каскады (по дефолту выключено, как и блур), или поставить альтернативные варианты неба.
В Godot 4+ SDFGI имеет свойство "отваливаться", если решить сменить hdri карту освещённости на другую на ходу (включение через код в тот же момент - не решение), поэтому я принудительно убирал отметку с каскадов в настройках при смене неба, а со временем дописал автоматическое пост-включение SDFGI с некоторой задержкой после смены неба, если оно было включено. На это короткое время изменение настроек блокируется. Я думал, что в свежей версии движка 4.5+ что-то изменилось, но нет - если просто оставить SDFGI включённым и менять небо, то видно, что само освещение остаётся от предыдущего неба (что нам не подходит), поэтому механизм автовключения освещённости с задержкой не теряет своей актуальности.
Собственно - это не проблема движка, что есть такой нюанс, потому что для большинства игр стандартный сценарий подразумевает использование одного неба, которые мы не меняем, или разных, но загружаемых вместе с отдельным уровнем и своей отдельной камерой. Также, вероятно, SDFGI при смене hdri изменялось бы корректно через код, если внутри нажатия на опцию просто менять флаги, а обрабатывать последствия уже в process() или physics_process(), но я не проверял подобный сценарий.
Ещё у движка есть такая особенность - при включённом блуре билбордящиеся 3д спрайты/текст (который не 3д-текст, а двумерный, но в 3д) размываются при отключении буфера глубины, если оказываются на фоне неба. Связано это всё с определённым порядком проходов при отрисовке каждого кадра. Я данный момент фиксил добавлением второго спрайта/текста поверх первого - у первого, по дефолту, буфер глубины работает, а у второго выставлен флаг no depth test.
Более новые версии движка стали требовать более правильной работы с коллизиями - если менять размеры объекта содержащего коллайдер внутри, то он перестанет работать или будет срабатывать не правильно. Поворотов и перемещений это тоже касается, но в меньшей степени. То есть, стоит изменять размеры самого коллайдера. Кстати, у любой коллизии теперь должен быть выбран какой-то слой, даже в тех случаях, когда она лишь отслеживает/мониторит прочие объекты, а сама ими не должна регистроваться.
Что касается физики машин - на самом деле, "более честную" физику колёсного транспорта часто хочется бросить, и использовать вместо неё более простые штуки, вроде Kinematic Body или "бестелесного" Area-коллайдера с рейкастами. Потому что у тех более предсказуемое поведение, контролируемое движение, сцепление с поверхностью устойчивое и так далее. Проще выстроить геймплей под такую схему. Многие гоночные игры как раз используют какие-то упрощённые модели, которые удобнее управляются и лучше отзываются.
С другой стороны, физичность-из-коробки - это по своему интересно, и, всё таки, веселее чем более простые варианты. Плюс можно её поднастроить, чем я и решил заняться.
Для улучшения управляемости я добавил два основных механизма - привнесение доли нефизического поворота в физические повороты, а также банальная вещь типа "системы передач". Что неплохо так улучшило ситуацию. То есть, во время поворотов машинка теперь разворачивается не только силами (что часто слишком медленно, а при повышении силы повороты могут стать совсем резкими), а и немного простым поворачиванием в пространстве - доля этого "доворота" у всех машин разная, что позволяет придать им дополнительной индивидуальности. А "система передач" подразумевает для каждой машины определённый начальный порог скорости, до достижения которого машинка разгоняется с намного большей силой - это позволяет быстро набирать нормальную скорость с места, без длительного ожидания пока машинка разгонится, а также куда увереннее заезжать на различные горки.
Ещё один регулирующий механизм, опробованный в паре прочих прототипов - шкала импульса, который расходуется на прыжки и перекаты. Шкала постоянно регенерирует и содержит 3 деления - прыжок требует и расходует сразу 2, а перекаты - по 1. Таким образом, имеем вполне оптимальный органичитель, который не даёт развить совсем уж безумные скорости или "упрыгать" в небо и за пределы уровня.
Это полноценный мини-релиз, который можно пройти, собрав 3 фрактальных артефакта:
Расширенный ролик:
Данный проект возвращается к концепции первых Невангеров - аркадно-гоночный экшен-квест с элементами метроидвании, где игрок должен догадываться о том как использовать те или иные механики, а также, где применить способности определённой машинки. В NewOnGears у машинок пока нет уникальных свойств, но есть прикрепляемые устройства, со своими умениями и прочие переосмысления изначальной концепции (например, управляющая душа может покидать текущее средство передвижения в любой момент, чтобы "пересеть" в прочие доступные).
Первая игра была написана на движке Unity и её можно найти тут:
Информация о прочих проектах "невангерского" семейства, где используются биомашинки, собрана здесь:
Кроме того, есть и "вангероподобный" проект - Униванг 3/9:
