Демо-версии Невангеров для Unigine и Godot

    Альтернативные прототипы с биомашинками (и не только био-), которые собрал за время знакомства с игровыми движками Unigine 2 и Godot 3.



    Unigine engine


    Начнём с версии для Unigine. Используется версия 2.11, вышедшая этой весной, начиная с которой в движке появилась бесплатная лицензия. На данный момент вышла 2.12 и скоро ожидается 2.13.

    Что в общем стоит знать про Unigine — это томский игровой движок, часто используемый для бенчмарков и симуляций. На нём в разные годы вышли такие игры как Oil Rush, Cradle, и вот, например, относительно недавняя ммо Dual Universe.

    Внутри применяется довольно много интересных и перспективных решений, рендерит достаточно красивую картинку и может довольно сильно приглянуться художникам, особенно если те моделят в отдельном 3д-пакете, а не средствами самого движка.

    Террейн тут есть из коробки, как и вода, облака, волюметрики, проекторы и прочие полезные вещи. Поверх террейна накладываются различные маски для детализации и прочего — очень классный инструмент для создания ландшафтов, хотя, в плане юзабилити есть куда его улучшать.

    В качестве инструмента для игрового разработчика — здесь в принципе применим опыт использования C# в Unity, хотя в Unigine нет такого же многообразия готовых компонентных решений. Тем не менее, какие-то базовые вещи реализованы, а документация поможет написать остальное. С++ тоже никуда не делся.

    Для мобильной платформы движок пока не подойдёт, как и для разработки без программирования (хотя планируется развивать его и в этих направлениях). Требования к железу на уровне запросов Unreal, минимальный вес файла приложения довольно большой. Зато красиво и неплохо оптимизировано.

    Но вернёмся к игровому прототипу. В версии для Unigine основные сложности были связаны с визуальным конструированием физики для машинки, потому как в документации предлагается делать всё это вслепую, через код, к тому же всевозможные физические настройки разбросаны по разным местам редактора и сам пайплайн визуальной сборки не описан. То есть не было банального готового примера, который можно было бы модифицировать, не погружаясь во все нюансы. В 2.12 вроде появилось демо с копающим землю трактором, но, возможно, он опять собирается кодом, не смотрел этот момент.

    Как бы то ни было, машинку я более менее собрал, ориентируясь на документацию. О чём ранее писал соответствующую статью: Как я собирал физику колёс в Unigine.

    Что касается геймплея, в Unigine, в отличие от Unity и Godot, например, оказалось довольно просто переключать физику машинки на лету, не только визуал, но и расположение/размер колёс. Без придумывания дополнительных трюков для того, чтобы не провалиться сквозь пол, и без пересоздания модели. Хотя, существует некоторый шанс провалиться в текстуры, но совершенно в иных ситуациях, а не в момент смены машинки.

    К этому всему хорошо подходит концепция о едином средстве передвижения, которое просто меняет свои формы, трансформируется, адаптируется, видит происходящее в других измерениях и так далее. По крайней мере вокруг подобных переключений можно было бы построить основной игровой процесс, хотя и не обязательно.

    С чем в движке печально, так это со сборкой UI из редактора — как-то всё громоздко, с развешиванием отдельных скриптов на каждый интерактивный элемент. Хотя тут я лишь редактировал ту реализацию, что была в примерах, сильно не разбирался, к тому же сходу не сориентировался как отобразить слой gui, чтобы увидеть визуальное представление в редакторе.
    С другой стороны, если подразумевается игра более консольной направленности, про геймплей завязанный на небольшое количество кнопок, с минимальным использованием интерфейса и с минимумом интерфейсных элементов, то это перестаёт быть заметной проблемой.

    Другая удручающая вещь, простые анимации, записанные на внутренний инструмент — трекер. Да, он по-своему мощный, но какой-то слишком квадратно-гнездовой в использовании. Мало этого — проиграть записанную таким образом анимацию можно только используя устаревший язык UnigineScript. Это в то время как в Unity или Godot можно заанимировать буквально всё вокруг по периметру. Да, можно импортировать анимацию костей, но это немного другое (к тому же пока не пробовал этот способ и не знаю как оно).

    Если, опять же, взглянуть на это с другой стороны, то движок всё-таки больше ориентирован на физические симуляци и взаимодействия, так почему бы этим не воспользоваться вместо запекания каких-то там предустановленных анимаций — то есть делать какие-то эмиттеры, переключатели, взаимодействующие конструкции, применять силы, использовать гравитацию и так далее. Так что без внутреннего аниматора можно обойтись, но если бы он был нормально реализован, то это тоже большое дело хотя бы даже в плане режиссуры — в несколько кликов записать пролёт камеры по сцене со всякими интерактивными элементами, и вот тебе уже готовый фильм. Тем более, при таких возможностях для кинематографичной картинки.

    Что касается своего проекта — на данный момент после нескольких итераций я наконец собрал и выложил более менее цельную демку, которую можно тестировать.


    Архив для Win64 можно скачать здесь (вес 687Мб): DROPBOX
    или на страничке itch.io: NEWANGERS
    в распакованном виде занимает 3Gb

    Что тут есть:

    • В билде три основных режима отображения — «дневной» и «ночной» (с пресетами высоких графических настроек), и режим «а ля комикс» (с более низкими настройками графики).
    • Для переключения между режимами нужно нажать Esc, чтобы показался курсор мыши, и выбрать нужную опцию в менюшке слева сверху.
    • На уровнях есть интерактивные объекты — синие звездообразные порталы, проезжая в которые машинка переносится в другие миры и можно возвращаться обратно, проехав в портал с той стороны.
    • Многие объекты уровня проницаемы, но у некоторых есть коллайдеры и сами уровни более менее окружены блокирующими стенками.
    • Машинка, в основном, управляется кнопками WASD. Также можно стрейфиться по Q и E. Прыгать на пробел, или, наоборот, сильнее устремляться к земле нажимая R. По Tab машинку можно крутить, чтобы, например, перевернуться и встать на колёса.
    • Стрейфам и прыжкам не установлены лимиты, то есть во время прыжка можно прыгать дальше и так далее.
    • Кнопки 1,2,3,4,5,6,7 — переключают разные машинки. Колесом мыши можно слегка зумить камеру.
    • По левой кнопке мыши можно заваливать всё вокруг небольшими блоками, а по правой кнопке мыши создаются светящиеся «магические» сферы.
    • PgUp включает альтернативный режим колёс, поворачивая оси в другое положение. PgDown — возвращает их в обычное состояние.
    • P — выход из игры, L — перезагрузка с откатом на стартовый уровень.


    Есть ещё секретная кнопка K, если её нажать, то на некоторых уровнях происходит нечто странное. Для возврата к нормальному состоянию нужно нажать M.

    Более ранние исходники этого прототипа знакомый выложил на своей страничке вместе с некоторыми правками физики колёс первоначальной версии: GITLAB.

    Godot engine


    Переходим к следующему движку в нашем списке. Опенсурсное компактное решение с огромными возможностями (Blender от мира игровых движков), но, опять же, пока уступающий тому же Unity в плане многообразия готовых компонентов. Хотя, различных неофициальных решений, а также примеров с исходниками для Годо уже написано довольно много и благодаря относительной простоте/быстроте имплементации нового функционала, не сказать, чтобы это было какой-то проблемой на данный момент.

    У Годо больше репутация 2д-движка, благодаря многообразию проработанных инструментов именно для 2д, но они являются дополнительным плюсом для 3д — куда проще делать игровой UI. Ещё проще чем в Unity, как по мне. На текущий момент Годо в своём развитии дошёл до стабильной 3.2.3 версии (но все ждут 4 из за вулкана, оптимизаций и так далее. шаткие сборки четвёрки, кстати, уже можно пробовать — хотя бы оценить картинку).

    Движок не требует мощного железа для 3д-графики и выдаёт вполне приличную картинку. Готовых трёхмерных инструментов не огромное количество, но реализованы как раз одни из самых нужных, полезных и универсальных. Примерно то же касается и оптимизаций. Например, в движке реализован обычный frustrum culling, отсекающий геометрию вне зоны видимости камеры. Occlusion culling (чтобы не считать закрытые стенами объекты) реализацию придётся придумывать самостоятельно (что не так уж сложно, особенно в каких-то точечных местах, да и не в каждой игре нужно). Также из коробки в движке нет батчинга геометрии (правда для gles2 частично есть) и террейна, но это не такая уж проблема, просто потребуется что-то оптимизировать вручную — сшивать какие-то меши вместе, бить геометрию на мелкие части или использовать чанки и так далее. Можно подыскать какую-то реализацию в местном небольшом сторе, например, добавить в свой проект готовое решение для террейна.

    Интерфейс движка, кстати, довольно продуманный и кастомизируемый (хотя есть некоторые негибкие элементы). Пользоваться им в целом удобно. Поддерживаемых языков достаточно, для разного уровня погружения. Тут и C++ и C# и довольно удобный внутренний GDScript, который запускается прямо внутри редактора, не требуя запуска отдельной среды. Визуальный скриптинг тоже присутствует, так что без знания программирования в Годо тоже вполне можно жить — какую-то минимальную логику сконструировать, что-то заанимировать (в Godot есть простой и классный инструмент для записи анимаций).

    Малый вес приложения, мультиплатформенность, быстрота разработки, простота имплементации различных сторонних решений — тоже немаловажные плюсы движка. Есть два варианта рендера — gles2 и gles3, оба поддерживают 3д, но в первом оно попроще и в целом он больше подходит для 2д и мобилок. Gles3 даёт более продвинутый уровень графики, какая-то часть мобильных устройств его тоже поддерживает.

    Перейдём к игровому прототипу на этом движке. В Godot простая физическая модель транспортного средства идёт практически «из коробки», поэтому перенести сюда свои машинки было довольно просто.

    С чем возникли некоторые проблемы — в запущенный физический объект не так просто вмешаться, чтобы, допустим, телепортировать его из одной точки в другую или на лету поменять расположение колёса машинки. Поэтому здесь такой трюк как в Unigine не работает и, как я понял, в Годо проще пересоздать объект, чем поменять ему на лету конфигурацию физики или что-то подобное. Но на самом деле это всё особо-то и не нужно, и в этом прототипе я просто вернулся к стандартной идее геймплея, когда катаешься за разные машинки, пересаживаясь из одной в другую где-то в специальных отдельных местах.

    В Годо есть интересные инструменты, вроде CGS-объектов и мультимеша. Подробнее про особенности их использования я писал в статье: Godot, 1000 мелочей

    Прототип Невангеров на этом движке получил отдельное название — Wild Engines. В целом у меня получается как бы семейство сходных проектов, объединённых концепцией странных машинок путешествующих по странным мирам. И в качестве рабочего собирательного названия я их привык именовать Невангерами, пока не придумается более конкретное наименование. У Godot прототипа теперь появилось своё название, у приостановленной на версии 0.9 Unity версии (с которой всё и началось) тоже появилось другое название, но до этого дойдёт дело потом, если появится время к ней вернуться.

    Особого видения о том, что хотелось бы реализовать в демке Wild Engines поначалу как-то не складывалось, просто делал наброски уровней, пытаясь понять как следует лучше реализовать террейн и какие вобще возможности хотелось бы видеть. Затем я пришёл к тому, чтобы сделать камеру двигающуюся за мышью и стало возможным реализовать более контролируемое прицеливание оружия, чем в прочих версиях. Таким образом данный прототип станет, вероятно, больше ориентирован на использование стрельбы.

    Попутно стал собирать уровень из платформ, состоящих из маленьких блоков, пробуя различные подходы к оптимизации и замеряя производительность. Оптимизации оптимизациями, но в какой-то момент я уже настолько заполнил видимую на камеру область геометрией, что редактор перестал тянуть всю запущенную сцену, вываливась с ошибками. Что исправилось включением большего количества памяти в настройках. Тогда я сильнее увёл генерацию платформ в код, оставив на сцене только упрощённые габаритные блоки с идентификаторами, которые сами подгружали в себя нужную платформу при старте игры. После чего откатил количество используемой памяти к меньшему значению и уже без проблем увеличил уровень ещё в несколько раз. К тому же при такой реализации всегда остаётся вариант переиспользования уже подгруженных платформ, перемещая их в другие места уровня, когда машинка направляется в ту сторону, чтобы иметь возможность рисовать ими пространство уровня практически до бесконечности при тех же ресурсах и без переходов.

    Примерно похожим образом я потом собрал наброски похожего уровня в Unigine, только там редактор сразу тянет всю сцену без надобности подгружать платформы в блоки через код (но для Unigine и компьютер используется куда более мощный).

    В итоге в демо версии Wild Engines есть 4 машинки, одну из которых нужно выбрать для старта, и два небольших уровня (Level A и Level B). Пара ранних карт тоже осталась (Levels 0 и 1), но они ещё более тестовые и ландшафт там неоптимизирован.


    В меню можно включить/выключить полноэкранный режим и тени.

    Кнопки 1, 2 и 3 меняют позицию камеры. Мышь нацеливает и поворачивает камеру, тем сильнее, чем дальше курсор от центра.

    WASD — перемещение. PgDown — прыжок. Q — случайный импульс.

    Левая кнопка мыши — выстрел.

    По Enter появляется подсказка об управлении и кнопка возврата в основное меню, где можно поменять машинку/уровень.

    Win64 версия (42 Mb): DROPBOX wildengines_x64

    Linux версия (44 Mb): DROPBOX wildengines_linux

    Бонус


    А вот один из недавно появившихся новых мехосов, Некромант:


    На нём можно покататься в версии для Unigine.

    Другой новый мехос, розовый с синей подсветкой, Дебаг, есть и там и там.

    Ещё тут завалялся один старый картридж… как по вашему, клоны каких восьмибитных игр могли скрываться под таким названием на китайском картридже, будь Вангеры всемирно известной франшизой в те далёкие времена?

    Комментарии 13

      +2
      Чем то напомнило мне старенькую игру infestation 2000-го года.
      image
      image
        0
        Игра, кстати, классная. Играл на PsOne. И музыку помню до сих пор.
        0
        Может когда-нибудь попробуете сделать на NeoAxis Engine :)
          +1
          Ну, редактор у NeoAxis довольно страшноват, если честно. Документации всего ничего, развивается всё как-то очень тихо и медленно. Pbr вроде и заявлен, но на скриншотах оно так не выглядит. Что ещё. Разработка только под Windows. Как бы и опенсурс, но лицензия с требованием упоминания в титрах. Просто не увидел каких-то преимуществ, кроме некоторого количества готового полезного инструментария. Есть наверное какие-то скрытые плюсы, но тут всё упирается в наличие желания рассматривать данный вариант.
          Просто с тем же Godot на поле опенсурс движков конкурировать почти нереально, а это ещё не вышла 4-ка.
          Скорее я посмотрел бы на Stride, где C# в качестве основного языка, инструментария немного, но как-то целостно и приятно всё выглядит. Или на вот буквально на днях вышедший Cocos Creator 3D, который тоже развивается и кажется перспективным. Правда у двух последних пока не наработана база примеров/исходников и туториалов.
            0
            :) Ну спору нет, PBR в таких зарослях сложно заметить) Если из сорцов собирать, демки докачиваются через ассет стор.

            image

            image
              +1
              Просто когда у движка на официальном канале последнее видео годовой давности, а прочие аж 7-летней, то это как-то не очень способствует популяризации. Тем более, что какие-то новые версии они выкатывали не 7 лет назад и как раз есть повод поснимать каких-то новых видео/туториалов и всякого подобного.
                +1
                Со стороны видео значит выглядит малообновляемым, спасибо. Пока есть только сторонние обзоры, типа такого:
                  0
                  Как мне кажется, повышению интереса к движку способствуют разрабатываемые на нём проекты, в том числе силами самих разработчиков движка. Может даже чисто демонстрационные. Чтобы наглядно показать пайплайны, инструментарий. Опять же — лишние инфоповоды, вроде новостей из дневников разработки, но не касаемо самого движка, а каких-то прототипов на его основе.
                  Лучше всего даже каких-то супер-простых, от которых новоприходящим разработчикам проще моддить свои проекты. Даже в том же Unity не сразу к этому пришли — относительно недавно (хотя на сайт к ним давно не заглядывал) на сайте появились официальные мини-проекты с разбором отдельных элементов, вроде простой гонки, шутера и так далее.
                  Я просто вспоминаю, как начал делать игры на том же Flash именно после того как нашёл где-то на Kongregate пошаговое руководство по написанию простой леталки. В итоге около десятка игр на эту платформу написал. Хотя, конечно, сам интерес к разработке на Flash изначально появился не от наличия туториала, а по иным причинам, но без существования этой точки старта я в то время, наверное, продолжал бы использовать Blitz3d или ушёл в какие-то другие среды разработки.
                  В случае со входом в Blitz3d тоже попалась некоторая обучалка возможностям и примеры сборки чего-то простого. А на Unity можно было относительно просто вкатиться благодаря сторонним мини-прототипам в асстет-сторе, пока не было расписанных пошаговых официальных.
          0
          Насколько я понимаю, Unreal и Unity сейчас самые популярные движки с большим отрывом. Т.е. ресурсов по ним больше всего, опыт по ним самый востребованный. Оба бесплатные (по крайней мере на начальном уровне).
          Какой практический смысл делать прототипы в чём то другом?
          • НЛО прилетело и опубликовало эту надпись здесь
              +4
              Не всем и не всегда нужен гигантский движок с уймой лишних фич, особенно если есть чёткое понимание какой именно функционал движка будет необходим. Не всегда удобны предоставляемые инструменты и парадигмы разработки (скажем, подход со сценами в Unity, подход в префабами, система ресурсов, и т. д.). Также, многие встроенные функции движков не дотягивают до уровня, который можно получить используя сторонний middleware или просто написав свою имплементацию (например, меня не устраивают UI любых существующих движков поэтому я предпочитаю NoesisGUI (библиотека векторного UI), а для high-level сетевого слоя в последнем проекте понадобилось совершенно кастомное решение с глубокой интеграцией непосредственно в выбранную UDP библиотеку — с большим успехом в итоге, и просто гигантский контраст с тем, что по крайней мере на тот момент предлагали как Unity так и Unreal Engine (Unity HLAPI был годами набит багами, надеюсь они нашли людей доработать это недоразумение; в Unreal просто требовалась уйма сравнительно очень страшного кода на макросах в C++ для их magic репликации).
              У меня есть многолетний опыт трудной работы с Unity, который просто доводил нашу студию до отчаяния в эпоху версии Unity 5 — была уйма критических багов, которые не фиксились месяцами (багрепорты часто месяцами игнорировались). А когда фиксились одни, то регрессились другие и долгое время не было доступно действительно полностью стабильной версии для релиза игры (дело дошло даже до постов с извинениями в их блоге и рассказом как они меняют свой подход к QA). Из-за того, что это проприетарный движок, я не мог залезть в его исходники и поправить какую-нибудь критическую мелочь самостоятельно (только на особых «договорных» энтерпрайз лицензиях тогда это было доступно, сейчас стало чуть проще — при условии что у вас много лишних денег). Но нужно понимать, что код движка там C/C++, а не C#, и всё наверняка будет совсем не просто в плане билда.
              С тех пор я заработал огромный опыт написания собственного движка и работы с MonoGame.

              Если бы я сейчас делал прототип игры, я бы вряд ли воспользовался Unity. Но новичкам в программировании (и тем более людям далёким от программирования) я его рекомендую — он достаточно логичный, зрелый, имеет массу качественных обучающих материалов. Unreal Engine тоже (во многом за счёт визуального скриптинга на Blueprints; рекомендовать новичкам в программировании работать с С++ API я бы не стал). В обоих движках есть удобный редактор сцены и 99% нужных фич по крайней мере для сборки прототипа большинства игр. Asset Store данных движков также может быть очень полезным (там немало бесплатных ассетов и расширений).
              В случае наличия чёткого видения проекта и отсутствия потребности в лишних фичах (а так же просто опытным C# программистам) я порекомендую Stride (бывший Xenko) для 3D проектов (и/или когда нужен редактор сцены) и MonoGame для 2D (но там придётся писать свой редактор или ограничиваться сторонним решениями для работы с тайловыми картами, например). Для меня Unreal просто гигантский и медленный, с совершенно другими парадигмами разработки и без ориентации на глубокую интеграцию с C#, что оказалось принципиально важным моментом для выживания нашей студии с 2013 года (речь не только об унификации клиент-серверного кода для игр — на C# пишется вся инфраструктура включая сайты, бэкенд, тулзы, автоматизация облачных серверов и т. д. — всё это здорово ускоряет разработку и обслуживание).

              Добавлю, что существует ещё один немаловажный нюанс — ограниченный инструментарий часто заставляет искать другой подход к разработке, который не может не привести к совершенно другому результату, чем если бы использовался полный движок с уймой готовых функций — они не могут быть лучшим выбором во всех случаях и навязывают определённые подходы к разработке. Нередко мы видим действительно уникальные проекты с необычным геймплеем или графикой именно от разработчиков избравших минималистичный путь написания своих движков, что с одной стороны ограничивает, с другой стороны полностью развязывает руки (попробуйте изменить какой-нибудь популярный движок, чтобы он полностью поддерживал live reloading всего и вся в игре, включая C# код — а у меня получилось ещё несколько лет назад на своём движке и это здорово экономило время при дальнейшей разработке — в сравнении с Unity, где приходилось ждать по несколько минут перекомпиляцию прошлого крупного проекта несмотря на его разделение на отдельные библиотеки). До середины 2000-ых это было вполне стандартным подходом, и мы были свидетелями огромного числа действительно уникальных проектов. Сейчас же рынок просто перегружен однообразными играми сделанными на двух наиболее популярных движках… кстати, где-то была статистика по движкам игр в Стиме среди наиболее популярных (worldwide top seller) проектов — и более трети игр имели кастомные движки. Сейчас такой информации не могу найти, но есть статистика по наиболее рейтинговым (исходя из оценки игроков) играм в Steam в 2019 (там в основном инди-игры получились, уж так пошло в Стиме, что они собирают наиболее позитивные отзывы).
                +1
                Ёмко.
                Кстати, соглашусь с важной ролью ограничений, благодаря которым появляются специфические геймплеи или способы реализации чего-то внутри игры, организации пространств и так далее. Собственно, в статье и описаны различные подходы к устройству прототипа, которые выросли в процессе разработки из специфики того или иного движка. Да и в целом сама полигональная графика и её пайплайны тоже выросли из ограничений, потому как считать реалтайм 3д через «честные» воксели — драматически непроизводительно. Или вот такой особый «переходный» поджанр, как 3d игры с фиксированной камерой и пререндеренными задниками. Да даже в эпоху 2д тоже хватало своих «нечестных» трюков и ухищрений, чтобы обходить ограничения и добиваться адекватной производительности.
                Тоже в качестве C# движка рассматриваю Stride как один из интересных вариантов. Потому как в Unity на шарпе замечательно всё писалось и хотелось бы чего-то подобного. Вот почему и взялся за Unigine, в котором эта возможность тоже есть, хотя пока в основном описано невизуальное использование скриптового языка. Но опыт Unity туда хорошо переносится. В Godot, напротив, выбрал всё-таки внутренний GDScript, потому как из нескольких скриптовых языков в движке я лучше возьму тот, который лучше проработан и интегрирован. Тем более отличия от шарпа не такие большие, чтобы это было какой-то прям проблемой — пишешь себе логику и пишешь.
              0
              Очевидно что это не игра, демо-версия чего, как вы сами бы охарактеризовали?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое