Какие движки наиболее популярны в 2021 году — да и вообще в последнее десятилетие? Очевидно, по всем параметрам лидирует Unity. Unreal, в свою очередь, — пожалуй, наиболее очевидный выбор для AAA. О таких выводах догадаться несложно, даже не имея на руках никаких численных данных. Но что, если все-таки попытаться их собрать?

Сайт gamedatacrunch.com максимально приблизился к реализации этой задачи, и его основатель Ларс Дусе на днях выкатил анализ движков paid-игр в Steam, выпущенных с 2010 года. В этой статье по нему мы тоже пройдемся, но и вспомним о том, какие еще движки сейчас в обиходе (и не только в Steam).


Итак, самый популярный движок не только в мобильной игровой разработке (где он занимает более 50% рынка), но и на Steam для ПК — Unity. Здесь никакой интриги нет, это видно и из диаграммы ниже, на которой показана популярность игровых движков в Steam по годам, начиная с 2010. Как мы видим, Unity действительно является доминирующим движком, начиная с 2016 года. Статистика эта все еще не безукоризненно точная (Unknown — игры, движки которых не удалось идентифицировать), но в определенной степени на нее можно полагаться.

Почти то же самое, но в виде круговой диаграммы:

Какие движки мы вообще здесь видим?

Unity (Unity Technologies). Впервые выпущенный в 2005 году как движок только для Mac OS X, теперь Unity поддерживается и Windows, и Linux, а также известен своей кроссплатформенностью на все мобильные, консольные, ПК-платформы и даже AR/VR. Отличается мощным комьюнити и обилием обучающих материалов, а также наличием огромной библиотеки ассетов и плагинов, с помощью которых можно значительно ускорить процесс игровой разработки. Это самый популярный движок среди разработчиков игр, причем как среди инди, так и более крупных студий. Движок сосредоточен на идее «доступности»: у него довольно низкий порог входа, его легко освоить, он бесплатен для независимых разработчиков (подписка же Unity Pro стоит $1,800/год). 

Из минусов? Да, движок довольно прост в освоении, но если вы хотите создавать что-то сложнее примитивных платформеров, то вам понадобится хорошее знание C# для написания скриптов и объектов и последующего внедрения их в игру. Также нужно понимать, что Unity — уже довольно старый движок, поэтому в нем есть свои особенности и артефакты, а вместе с тем — порядочная медлительность и необходимость допиливать некоторые инструменты своими силами. Например, игры, использующие uNet для работы в сети, вскоре должны будут поддерживать инфраструктуру самостоятельно, поскольку поддержка этого инструмента постепенно прекращается.

Примеры тайтлов:

  • Among Us

  • Cities: Skylines

  • Fall Guys: Ultimate Knockout

  • Phasmophobia

  • Hollow Knight

  • Escape from Tarkov

  • Ori and the Blind Forest

Unreal Engine (Epic Games). Названный в честь игры 1998 года, в которой он и был впервые использован, Unreal Engine с годами все больше снижал лицензионные сборы и требования к revenue, так что теперь доступен практически для каждого, кто хочет создавать на нем игры. Тем не менее, чаще он используется все-таки для AAA-проектов. 

В нем заложен практически тот же инструментарий, что и в Unity: работа с физикой, 3D-графикой и не только, — но существуют и некоторые другие решения, способные склонить разработчиков в его пользу. Впрочем, для всего этого уже требуется определенный уровень скиллов. Это мощный движок для создания высокореалистичных игр «из коробки», поддерживающий быстрое прототипирование и визуализированный кодинг, а также имеющий обширную кастомизацию. Его широко используют не только в ПК, консольной и мобильной игровой разработке, но и вне геймдева: например, в кино (один из наиболее ярких и свежих тому примеров — сериал «Мандалорец»), архитектуре и автомобильной промышленности.

Примеры тайтлов:

  • PlayerUnknown's Battlegrounds

  • Sea of Thieves

  • Fortnite

  • Final Fantasy VII Remake

  • Dead by Daylight

  • BioShock: Infinite

  • Star Wars Jedi: Fallen Order

GameMaker Studio (YoYo Games). Выпущенный в 1999 году, GameMaker ориентирован на начинающих разработчиков и обладает интуитивно понятным Drag & Drop: для его использования нет необходимости написания каких-либо скриптов и тонн кода, как и вообще знания языков программирования. Готовую игру можно сразу экспортировать в Steam. 

В нем нет таких возможностей для работы с 3D, как в Unity и Unreal: вместо этого он фокусируется на 2D-играх. Другой недостаток — высокая цена при работе с несколькими платформами. Но если вы готовы заплатить за покупку нескольких лицензий, то GameMaker Studio 2 может оказаться неплохим решением для кроссплатформенной игровой разработки.

Примеры тайтлов:

  • Hotline Miami

  • Katana Zero

  • Risk of Rain

  • Undertale

  • Spelunky

  • Hyper Light Drifter

Ren'Py (Tom "PyTom" Rothamel). Запущенный в 2004 году под лицензией Массачусетского технологического института (MIT), Ren'Py (от англ. Ren'ai (恋愛) — «романтическая любовь» по-японски, и Python, на котором он построен) — это кроссплатформенный бесплатный движок с открытым исходным кодом для создания визуальных новелл с более чем 450 играми в Steam и более 4800 в целом. Как конструктор типичного представителя жанра, движок интуитивно понятен для любого пользователя, но для создания более сложных игр требует уже знания Python. 

Примеры тайтлов:

  • Ladykiller in a Bind

  • Long Live the Queen

  • Analogue: A Hate Story

RPGMaker. Самый старый из этого списка, разработанный аж в 1992 году, RPG Maker представляет собой скорее серию связанных движков, ориентированных на создание JRPG (японских ролевых игр). У него было несколько издателей на протяжении многих лет в разных странах, включая неавторизованные локализации. Прост в освоении даже новичками, не требует знания языков программирования и в целом представляет собой скорее конструктор для создания игр определенного жанра, благодаря чему и пользуется особой популярностью.

Примеры тайтлов:

  • To The Moon

  • Corpse Party

  • Ao Oni

  • Rakuen

Adobe AIR (раньше Adobe, с 2020 года — Harman International). Adobe Integrated Runtime (AIR) вышел в 2008 году и позволил разработчикам Flash/ActionScript перенести на ПК написанные на различных языках программирования web-приложения, не требуя их запуска через браузер, так что многие из самых популярных игр Steam являются адаптациями браузерных игр на Flash. Это кроссплатформенная среда, позволяющая небольшими усилиями создавать билды для Windows, OS X, Linux, QNX и Android. 

Примеры тайтлов:

  • The Banner Saga

  • The Henry Stickmin Collection

  • Samorost 3

OGRE. Объектно-ориентированный графический движок с открытым исходным кодом, на котором базировался Roblox вплоть до 2014 года. Имеет неплохие возможности, такие как поддержка OpenGL и Direct3D, совместимость с платформами Windows, Linux, Mac OS X и iOS, программирование GPU и шейдеров на ассемблере и языках высокого уровня, и многое другое. Это не игровой движок как таковой — это графический движок для рендеринга трехмерной графики. В нем нет встроенной поддержки сети, звука и многих других функций, но есть портированные под движок библиотеки, расширяющие его функционал:  PhysX SDK, OpenGUI и другие.

Примеры тайтлов:

  • Rebel Galaxy

  • Rebel Galaxy Outlaw

  • Kenshi

  • Torchlight

XNA (Microsoft). XNA's Not Acronymed был выпущен в 2006 году как набор инструментов, позволяющий упростить игровую разработку под Windows и Xbox и освобождающий от написания повторяющихся шаблонных кодов. Эдакий DirectX на .NET. Впрочем, уже в 2013 году стало известно, что новые версии XNA более разрабатываться не будут.

Примеры тайтлов:

  • Celeste

  • Rogue Legacy

  • Stardew Valley

MonoGame. Не столько игровой движок, сколько реализация все того же фреймворка Microsoft XNA c открытым кодом, который широко используется инди-разработчиками для кросс-платформенной разработки. Включает в себя редактор среды, графический пользовательский интерфейс, систему частиц, физику и многое другое. Отличается большой гибкостью, так что часто выступает в качестве основы для других игровых движков.

Примеры тайтлов:

  • Axiom Verge

  • Bastion

  • Infinite Flight

KiriKiri (w.dee). Еще один «классический» японский движок-конструктор для создания визуальных новелл, JS-ориентированный и с встроенным Drag & Drop. С 2013 года реинкарнировал в KiriKiri Z.

Примеры тайтлов:

  • Fate Stay Night

  • Nekopara

И другие

CryEngine (Crytek). На самом деле, согласно другим данным по Steam, CryEngine тоже занимает на этой платформе далеко не последнее место. Как и Unreal Engine, CryEngine тоже нацелен на AAA-сегмент, но, в отличие от него, имеет меньше обучающих материалов, в целом сложнее для изучения, да и комьюнити не такое дружественное, как у соперников. Это кроссплатформенный движок, заточенный больше всего на создание фотореалистичных шутеров от первого лица: в комплекте с базовой версией движка даже идет GameSDK — полноценный шутер, который можно адаптировать под ваши нужды. Впрочем, мобильные платформы и портативные консоли в его кроссплатформенность не входят. 

Впоследствии лег в основу Amazon Lumberyard. С выпуском в 2016 году CryEngine V перешел на модель распространения «плати сколько хочешь».

Известные тайтлы:

  • Far Cry

  • Crysis

  • Prey

  • Kingdom Come: Deliverance

  • Sniper Ghost Warrior

  • Hunt: Showdown

Amazon Lumberyard (Amazon). Бесплатный кросс-платформенный движок класса AAA, разрабатываемый Amazon с 2016 года. В его основу легла архитектура CryEngine. Хороший выбор не только для AAA-сегмента, но и для старт-апов и инди-студий. Как минимум, о многом говорит то, что Star Citizen перешла именно на него. 

Тем не менее, страдает движок от тех же недостатков, что и CryEngine: небольшое комьюнити, мало материалов, меньший уровень надежности, чем у более популярных конкурентов.

Известные тайтлы: 

  • New World

  • Star Citizen

Godot (MIT). Довольно новое решение в экосистеме игровых движков, но имеющее ряд интересных особенностей. И пусть пока Godot не может похвастаться какими-то особыми игровыми хитами, он обладает всеми возможностями передовых движков — при этом он полностью бесплатный, с открытым исходным кодом и довольно легок в освоении. Тем более, вокруг него уже собралось крепкое комьюнити и существует довольно много полезных инструментов. 

Godot поддерживает несколько языков программирования: C#, C++, GDScript, основанный на Python, и язык визуального программирования. Все игровые ресурсы хранятся в папке проекта в виде обычных файлов, что во многом упрощает работу с системой управления версиями для разработчиков. Из минусов: пожалуй, можно отметить, что он даже слишком заточен на новичков.

Примеры тайтлов:

  • Cruelty Squad

  • Carol Reed Mysteries

  • 1000 Days To Escape


Здесь мы сосредоточились на игровых движках, наиболее популярных в Steam, но список существующих движков непрерывно растет. Многие крупные игроки на рынке геймдева пользуются собственными движками: Electronic Arts — Frostbite, CD Projekt RED — REDengine, Remedy Entertainment — Northlight. Одни движки уходят, на смену им набирают популярность другие, разрабатываемые как компаниями, так и независимыми разработчиками на коленке, на основе старых и с нуля.

Комментарии (27)


  1. Kenya-West
    10.09.2021 13:45
    +20

    Всё детство писал (а поначалу просто D&D'шил через встроенный инструмент FlowGraph) моды для Crysis вплоть до третьей части, и статья попадает в самую точку по движку CryEngine, судьба у которого была почти напрямую связана с Crysis. Как известно, авторитарная политика Цевата Йерли почти угробила игру, во второй части сделав ставку не на масштабные коридорные локации, а на сюжет (который страдал очень плохой "обратной совместимостью" между частями, в основном из-за найма андерграундного писаки, критикующего всё подряд и "нитакогокаквсе"­™, хотя это был его первый дебют в игровой индустрии) - что в итоге оказалось ошибкой, которую как-то пытались исправить в третьей части. Игнорирование многочисленных коммьюнити, которые просили не "глушить" инструменты модификации игры, тоже было ошибкой... Об этой ситуации ниже.

    В первой части игры и CryEngine 2 соответственно, нужно было NPC посадить в транспорт, и лишь затем можно этот транспорт заставить ехать. Да, оптимизации в этом плане было почти ноль, но дружественность к моддеру, логичность использования сущностей в движке, сумасшедшая поддержка Drag-n-Drop и восхитительный FlowGraph (хотя не он первый, и аналогичные инструменты чуть позже во всех популярных движках) сделали свое дело - во многих странах, начиная с 07-х гг., у движка выросли большие сообщества, изучавшие его и делавшие поделки разной степени безбашенности. А уж про ремейки Сталкёра на CryEngine 2 можно говорить часами — это были десятки, если не сотни попыток. Да, в основном там обещали "грабить корованы"©, но как же было весело! Так прошло мое детство, поделка за поделкой, от встроенного FlowGraph до DLL'ок на C#/C++ и интерфейсах Flash. Там даже лицевую анимацию можно было сгенерировать по звуковому файлу!

    Затем у Цевата Йерли начинается "звездная болезнь", а от притока бабла ему затмило разум... Ну, видимо, человек такой вот, "с гнильцой", так сказать. Лично мне он неприятен, как был неприятен и совету директоров, который пытался его сместить (и у них получилось). Ну, а на 2 части началось закручивание гаек. Руководитель студии весьма нелогично посчитал, что модификации для Крайзиса 2 части могут подождать, и поэтому выпустил SDK для этой части на полтора года позже. До этого файлы игры были шифрованные (пусть дешифратор и выпустили почти сразу), и не было нормальных инструментов для работы по ним. Фич в этом SDK было меньше, новых сущностей и подавно мало, часть функционала решили скрыть за пейволлом. Что за пейволл? Об этом ниже.

    И тут, во времена второй части и третьей версии движка (и немного до нее), CryTek решили не вполне правильным методом "причесать" сообщество моддеров, и они опубликовали свой сайт - CryDev.net, который и поныне напоминает перекати-поле. Для сравнения - в России было первое в мире по популярности и количеству юзеров сообщество - CryMod.net и еще парочка площадок помельче. Alex626, лидер сайта, пытался договориться либо о слиянии площадок, либо о федеративной сети моддеров и взаимной поддержке. У CryTek было свое видение сообщества разработчиков, которым давалось минимум документации и минимум фич в обрезанной третьей части в Free версии движка. Без ассетов сообщество мало что могло сварганить, и российская площадка первое время была лучше по популярности. Они просто кинули мододелов Крайзиса, которым не дали возможность автоматом привязать движок к игре и модифицировать его как вздумается? Впрочем, такую возможность дали, но поздною

    Затем, после провала третьей части, закономерного позднего релиза SDK (когда бабла состричь уже не удавалось) и странностей в виде судебных тяжб с разработчиками Star Citizen количество разработчиков на CryEngine уже версии 5 (CE 5) стало в разы меньше сообществ других популярных движков. А кому охота копаться в технологии с минимумом документации, очень маленьким количеством специалистов и еще и возможностью получить неадекватный иск от разработчика движка? Вот в этом и есть причины низкой популярности CE. Вдобавок, модифицировать файлы оригинальной третьей части игры стало сложнее - непонятно, почему они так сделали? Ведь начинающему моддеру надо дать легкий для освоения инструмент, а затем тот сможет ступенчато превратиться в полноценного разработчика! Вот тебе и новые кадры, и бОльший рыночек, и большое сообщество вокруг твоей технологии! К сожалению, HQ Крайтека было без разницы.

    Итог? Что имеем... Судьба игры и движка была сильно связана. Игнорирование геймплейных достоинств первой части игры, упор на почти никак не связанный с историей сюжет, игнорирование потребностей моддеров, создание оторванного от игры сообщества — это уже реальная крышка в гроб франшизы... Но движок-то они спасут, одумаются? Многие ведь одумались? Или они повторят судьбу Нокии, которая почти 1-в-1 с судьбой CryEgnine? Надеюсь, что всё будет отлично, и всё наладится. И я надеюсь, что вернусь когда-нибудь к любимому FlowGraph, и снова открою страницу любимого форума CryMod.net с тысячей непрочитанных сообщений.


    1. FrytechTV
      12.09.2021 03:20
      +3

      Тот случай, когда комментарий интересней статьи :)


    1. OpenMind4423
      16.09.2021 22:43

      Они вроде выпустили движёк как Open3DEngine. Посмотрим как оно пойдёт. Но есть подозрение что плохо.


  1. Greendq
    10.09.2021 23:53

    Насколько я помню, Star Citizen использовала особую версию движка, полностью 64-битную и в которой все координаты (включая графические) в doble, а не float, как в обычных движках. так что говорить о том, что они используют "стоковый" дижок не совсем корректно.


  1. Ons1aught
    11.09.2021 16:43
    +2

    Я не игровой разработчик, и опыт работы с движками у меня минимальный (тыкал блюпринты в UE), но кто имеет профессиональный опыт работы с UE и с Unity, объясните пожалуйста понятным языком, почему "UE для ААА, а Unity - для инди"? Дело в языке программирования, который сложен в освоении (С++), умении работать с рендером, чем-то ещё? Не так давно общался с разработчиком, имеющим большой опыт работы с Unity, он сказал что C# и С++ это почти одно и тоже, но в C# больше сахара, и потому на нём проще писать. Этот "сахар" - решающий фактов для инди? Предположим: я хочу изучить с нуля программирование и движок для инди-геймдева. Мне почти со 100% посоветуют Unity (или RPGMaker/Gotod), сказав что "там С#, и вообще всё легко и просто" (не смотря на то, что при запуски Unity после UE у меня сложилось прямо противоположное впечатление, по крайней мере по первому восприятию). Однако, находятся люди, которые наоборот топят за UE, и говорят что он намного лучше для инди, т.к. "там из коробки всё есть, и вообще там графика лучше". Очень часто вижу дисскусии, где люди (профессионалы или нет) весьма убедительно джанглируют аргументами в духе "У меня на UE все есть для работы, а тебе нужно доплачивать за плагины, лох, ЛООХ!1" или "UE - отстой, блюпринты для инвалидов" и тому подобное, и поэтому выяснить истину, прочитав статью/посмотрев видео для не-профессионала в этой сфере практически невозможно. Что определяет такую функцию как "возможность движка в 3D игры, или почему на Unity пишут в основном 2д-рогалики-платформеры"? Прошу знающего, адекватного человека (не-фаната определённого движка) пролить свет истины.


    1. iskateli
      11.09.2021 18:54

      Для красивой и производительной картинки, особенно в 3D, в Unity надо затратить намного больше сил чем в UE.
      Кстати почему-то не упомянут Unigine, это считай произвоидительность UE + на выбор C# или С++ (полноценный, а не обрезанный как в UE), сообщество только не очень большое.


      1. Ons1aught
        11.09.2021 22:01

        >Для красивой и производительной картинки, особенно в 3D, в Unity надо затратить намного больше сил чем в UE.

        Почему? С чем это связано? Я не понимаю. Всё дело в рендере или... или в чём? В каких-то "багах" самого двигла?


        1. Siberianice
          14.09.2021 12:50

          Unity с нуля делает "мультяшную" графику, Unreal с нуля ближе к фотореалистичности.


          1. Pank0
            14.09.2021 17:46

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


            1. Siberianice
              14.09.2021 20:11

              "Мультяшную", в смысле, что при одинаковых кубах в каждом редакторе, Unreal выдаст более реалистичный рендер сразу.


      1. Tanelxen
        12.09.2021 10:17

        В UE4 вполне полноценный C++, просто там очень много макросной "магии" в API движка. А так особых ограничений нет.


      1. SAWER
        17.09.2021 13:49

        Никакой разницы, всё зависит от моделей и шейдеров, особенностей отрисовки(кастомная в т.ч.). В производительности так же вопросы, т.к. не смотря на то, что лучшие/новые решения по графике чаще появляются раньше в Unreal, но с некоторым запозданием с теми же цифрами появляется и в Unity.

        Возможно!(и даже весьма сомнительно), что в Unreal проще работать с AAA графикой, дабы добиться лучшей производительности. Но от спецов по графике я слышал, что и то, и другое, так себе решения - надо делать рендер с 0 под конкретные нужды игры.


      1. Alexrook
        04.11.2021 22:46

        Unigine изначально был нацелен не на игры, а на симуляторы. Это они в последнее время проснулись и поняли, что игровой рынок может давать куда больше денег. Но их первоначальная нацеленность на симуляторы, а значит только на PC ставит их в очень невыгодное положение по отношению к именитым конкурентам. Смысл изучать движок без поддержки консолей и мобилок? Может эту поддержку и прикрутят со временем, а может уже прикрутили в каком-то виде (не слежу за развитием этого движка), но чтобы все это допилить до продакшн уровня пройдут годы. Тем более, как я понял, там разрабов - раз-два и обчелся. Навряд ли они смогут вытянуть свое детище на уровень Unity или UE, а разрыв в функционале все увеличивается, особенно если посмотреть на новые фичи UE5 - Nanite и Lumen.


    1. Fitch24
      12.09.2021 10:17
      +3

      Не имею профессионального опыта, скажу, как новичок, который пробовал Unity, Godot и UE4.

      1. Размер движка. UE4 просто огромный. Надо скачать 12гб (что довольно не быстро для клиента Ростелекома с ADSL), на диске он будет занимать чуть меньше 30гб. Собрать из исходников ещё сложнее (мне не хватило старого SSD на 90гб, который я заботливо для этого освободил).

      2. Поддержка IDE. В UE4 огромное количество макросов, подсказки по которым мне смог показать только Rider (но он хочет денег, даже от новичков и инди с нулевым бюджетом на разработку). VS Code и VS2019 с макросами вообще никак не помогали, с тем же успехом можно набирать код в блокноте. Для VS2019 есть Visual Assist, но он тоже не бесплатный :-(

      3. Сложный API. Что в первую очередь будет делать новичок? Лично я полез делать Character Controller. Вроде UE4 в этом плане лучше всех, из коробки есть ACharacter, который умеет ходить/плавать/летать/приседать, умеет взаимодействовать с физикой и даже мультиплеер уже поддерживает. Но вот возможности бегать (или ложиться, например) нет. Кажется, что недостающую возможность можно очень легко и быстро реализовать. Для этого надо расширить два класса UCharacterMovementComponent и ACharacter. Наследуемся от UCharacterMovementComponent и офигиваем: получившийся класс унаследовал целую кучу переменных и методов от всей иерархии наследования, в которых новичок просто утонет. Официального гайда по расширению функционала контроллера персонажа нет, но я, как новичок продвинутый, решил поглядеть исходники, чтобы добавить режим бега, по аналогии с режимом ходьбы (банальное увлечение maxWalkSpeed в рантайме триггерило античит и персонажа телепортировало назад в режиме мультиплеера). Открываем UCharacterMovementComponent.cpp и офигиваем второй раз: 12к строк кода и это если не открывать исходники базовых классов, которые выше по иерархии. Много ли новичков умеют читать чужой код, да ещё и в таком объеме? Я умею, но как добавить дополнительный режим передвижения (без костылей) быстро сообразить не смог, ибо режимы передвижения перечислены в enum и задачка расширять функционал этого класса явно не для новичка. В защиту UE скажу, что в Unity встроенный Character Controller просто ужасен и его лучше писать с нуля: с физикой никак не взаимодействует, коллбек OnControllerColliderHit выделяет память в куче при каждом вызове, на форуме самой Unity можно найти сообщения от разработчиков от 2015 года, что этот контроллер был временным решением и они делают новый (его можно найти на GitHub'е, но он заброшен с конца 2019). Также UE единственный (из троицы) использует полноценное наследование, в Godot наследование не настоящее, в Unity его вообще нет и мы пишем обертки (MonoBehaviour) над стандартными компонентами.

      4. Game Framework. Для новичка это именно минус. В Unity/Godot новичок создаёт пустую сцену, запускает и видит черный экран. Далее добавляет камеру, снова запускает и видит свою пустую сцену, а в Unity может ещё и подвигать камеру в scene view, пока сцена запущена, т.е. все логично и очевидно. UE в аналогичной ситуации магическим (для новичка) образом сам добавит дефолтный pawn (с летающей камерой) в сцену. Как новичок, я бы хотел видеть Game Framework в виде подключаемого плагина, но как не новичку мне очень не хватает подобного фреймворка в Unity/Godot, где производится изобретать собственные велосипеды.

      5. Размер билда. Как новичок и инди-разработчик я вряд-ли смогу запилить полноценный проект с качественными моделями/текстурами/анимациями/сюжетом, поэтому в качестве целевой платформы лучше всего подходят мобильные устройства, где можно обойтись простыми low poly style моделями и простым/отсутствующим сюжетом. Будут ли довольны пользователи размером в 100+ мб в игре, в которой нет ни навороченной графики, ни длинного сюжета с озвученными диалогами?

      Я не топлю за Unity или Godot, в обоих движках есть вещи, которые лично мне не нравятся. У Unity закрытые для простых смертных исходники, писать можно только на C# (подключить C++ либу можно, но вызывать её код можно только из C#). Unity использует форк Mono двухлетней давности, будут ли они переходить на dotnet6 неизвестно. Многие штуки, которые в UE бесплатны, надо покупать у сторонних разработчиков. Качество кода сторонних плагинов просто ужасно, спасибо сайтам, на которых можно скачать платные плагины и посмотреть за что просят несколько десятков баксов. Я не видел ни одного плагина для рантайма, у которого был бы оптимальный код, который приятно читать, многие не понимают разницы между полем и свойством и постоянно дёргают вычисляемый геттер вместо того, чтобы сохранить результат в локальную переменную (самое популярное Vector3.normalized, особо упоротые вызывают 3 раза по отдельности для x, y и z), не догадываются, что умножение на 0.5 быстрее деления на 2 и т.д. Да что там сторонние разработчики, если даже в самой Unity используется camelCase для public полей и свойств, а почти все обучающие материалы приучают не пользоваться инкапсуляцией, назначая сериализуемым полям модификатор public. Считаю, что в плохом качестве игр виноват не движок, а кодеры, которые C# только в Unity видели.

      Godot развивается странно и медленно. Мне непонятно, зачем надо пилить собственный физический движок вместо того, чтобы обновить bullet до актуальной версии и глубже его интегрировать(прикрутить многопоточность, например). Методы для физических запросов странные: есть понятный raycast, а есть странный cast_motion, который можно использовать с любым примитивом(sphere, box, capsule, convex), но который возвращает массив с двумя дистанциями (безопасная дистанция до столкновения и дистанция, на которой произойдет столкновение), хотя я бы хотел знать точку попадания, нормаль, объект, с которым произошло пересечение. Баги не исправляют годами: колеса (VehicleWheel) не крутятся и не поворачиваются, если находятся в воздухе (не касаются земли); строгая типизация в gdscript не работает(вываливается ошибка), если из скрипта_1 ссылаться на скрипт_2, а из скрипта_2 ссылаться на скрипт_1(в моем случае в скрипте_1 был метод, который принимает аргумент типа скрипт_2, а скрипт_2 пытался вызывать этот метод из скрипта_1, на GitHub баг висит с 2018 года, обещание пофиксить переносили от версии к версии, сейчас обращают исправить в 4.0). Писать на GDNative тот ещё квест, проще форкнуть движок и расширять движок модулями.

      Считаю, что UE4 лучший движок на рынке. Но им трудно пользоваться из-за его размеров. Будь бы у него такой же простой и безопасный API, как у Unity/Godot, то в сторону Unity я бы даже не смотрел.


      1. FloorZ
        12.09.2021 12:58
        +1

        Я бы еще добавил папу камней в сторону godot. На нем пишу уже несколько лет. Перешел с Unity и XNA.
        class_name - это по факту просто глобальный макрос делающий preload скрипта. И вся надежда на gdscript 2.0, в godot4. Либо юзать C#. Моно кстати туда можно любое прикрутить, если разобраться со scons.

        Но в защиту скажу, что его исходный код читается на одном дыхании.

        Реально читать исходник годота проще, чем какой нибудь xna и уж тем более ue4. С++14-20 без метамагии из макросов и минимум шаблонизации. Но минус. Нету своего GC или аллокатора с пулингом памяти. От сюда для движка операции instance или new очень дорогие и постоянно обращаются к куче. Обходить эти проблемы приходится самостоятельно, контролируя создание и уничтожение узлов в ручную, большими пулами.

        Добавлю что киллер фича движка в том, что анимируется и интерполируется - все. Буквально все. Ты из коробки можешь анимировать буквально любой объект и любое его поле. А встроенные инструменты позволяют делать анимации и скелеты в 2д, не хуже чем в Spine. В 3д страдает fbx формат, т.к. их фбикс экспортер саморисный и весит пару килобайт. А так тоже, экспортируй что угодно. А при грамотной игре с вьюпортами, можно хоть медиум делать с параллельными мирами.

        А написание чарактер-контроллера с нуля, с блэкджеком и физикой занимает при опыте 5 минут, буквально.

        Это опенсорс и у них мало аудиторов PR. Исправлений багов много, 1000+ не закрытых PR, но их все тупо изучить не успевают. Опенсорс все таки. Я сам лично два критичных бага закрыл в версии 3.х. И теперь время от времени, сам исправлюсь баги и шлю PR с исправлениями.

        Движок дает идеальный минимум фундаментального инструмента, из которого собрать можно что угодно. Хоть авиасимулятор, хоть ММОРПГ. Тот же сторонний физический движок легко можно интегрировать в движок игровой. Заходим в исходники modules/bullet и сразу видно, как реализована их физика. Оно юзает общую абстракцию PhysicsServer. (Аналог PhysicsSystem в ECS парадигмах). И по аналогии напиши хоть 10 разных физических движков, по сути реализуя абстрактное API и все.

        Но это пока что самый удобный движок, на котором я могу делать гиперказуалки, все возможные 2Д и простые 3Д лоу-поли игры, без геммора и десятков помошников. И вес билда в 9мб при определенных стараниях не может не радовать. Меньше чем у cocos2d-x


        1. Ons1aught
          12.09.2021 13:51

          Благодарю за отзыв о Godot. Всегда приятно почитать информацию от человека, работающего в какой-то среде больше двух дней).


      1. Ons1aught
        12.09.2021 13:52

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


      1. Heinhain
        12.09.2021 14:37

        банальное увлечение maxWalkSpeed в рантайме триггерило античит и персонажа телепортировало назад в режиме мультиплеера

        Нет, если делать это со стороны сервера, а не клиента. Собственно, именно так все и делают уже очень давно и эпики в том числе называют это оптимальным путем.


        1. Fitch24
          12.09.2021 15:29

          Хм... Значит я был очень близок к цели)

          Моё решение было задать maxWalkSpeed сразу равным скорости бега, а в рантайме при ходьбе уменьшать (при беге восстанавливать) эту скорость. Но мне показалось, что такое решение "плохо пахнет".


        1. FloorZ
          12.09.2021 17:35

          Павну задать два параметра. Хотьбы и бег. А контроллер должен только контролировать, а не увеличивать скорость. Сервер получает информацию об контроллерах. Будь то AI или игрок. Он должен вызывать методы, которые меняют скорость уже самого павна на те или иные параметры. Тем самым контроллер не должен менять параметры напрямую. Его лишь задача задать направление контролируемого павна и сообщить ему, что игрок нажал кнопку бега, тем самым переключая вектор ускорения с хотьбы на бег уже на стороне сервера, который уже задан в павне. А не пытаться модифицировать вектор ускорения напрямую.


  1. Goerging
    11.09.2021 18:05
    +2

    Интересно было бы посмотреть на статистику по движкам среди успешных или хорошо оцененных игр, т.к. на том же Unity полно проходных, а то и откровенно мусорных проектов.

    Это как раз из-за его распиаренности и кол-ва обучающих материалов. Многие просто пробуют себя именно на этом движке, попутно заливая свои проекты в стим.

    Думаю, что на том же Unreal таковых игр намного меньше, т.к. его в качестве движка для обучения берут заметно реже и качественных проектов в процентном соотношении получается больше, чем у Unity.


    1. Brightori
      12.09.2021 00:18
      +2

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


      1. Ons1aught
        12.09.2021 13:54

        Инди-разрабы часто пытаются уходить в чистые блюпринты, не используя С++? Или там по другим аспектам косяки идут в играх? И да, как много было "пиксельных-2d-платформеров" на движке UE на девгаме, который вы судили? Любопытно было бы узнать.


        1. FloorZ
          12.09.2021 14:26
          +1

          Очень много блупринтов. Чуть ли не 90% контента в UE4 маркете - это блупринты, кривые и косые. Когда нужен реально С++, по факту не так часто. Если это не ААА или АА проект.

          UE4 почти не имеет вменяемого инструмента для 2Д. По сути там псевдо-2д, которое работает в 3Д сцене и не имеет главных 2Д фишек. Слои отрисовки. Полигонные спрайты, а не чистые картинки. 2Д скелеты, 2Д физики, деформация спрайтов и т.д. и т.п.

          Познакомился с парой проектов на UE4 и в принципе, проекты дохнут из за отсутствия мотивации. Гейм-разработка, это кода 10-15% по факту. Очень. Даже не так. ОООООООЧЕНЬ мало людей знают игровые паттерны. Не говоря уже о том, что каждый третий пытается сделать убийцу сталкера, но не владеет даже базой в линейной алгебре. Вон парень выше писал, об сложности расширения контроллера для бега. Хотя подход изначально не верный. Контроллер - это контроллер. А движением должен заниматься Pawn, получающий команды от контроллера.
          Хотя UE4 учит лучше всего геймдезайниров оптимизации. Ибо если налепить в сцену в тупую 100500 мешей. Какой бы крутой движок не был, его никто не вывезет. Надо изучать лоды, спекать свет, использовать фейки и т.д.

          Юнитисты же наглухо забывают про геймдезайнерскую оптимизацию из за чего сцена с лесом и травой тупит как не в себя. Начинают присобачивать Burts и другие сложные штуки, которые по факту агрегируют логику игры и векторизуют ее. Хотя вся проблема, что нужно было асинхронный код писать, а они всю логику лепят в Update. А память алочат по мере надобности, а не блоками, для плавности. От чего реалок постоянно дергает ОС за добавкой или освобождением, напрягая GC либо пока оно не сожрет возможный максимум.


          1. SAWER
            17.09.2021 14:06

            По Unity. Вот насчёт DOTS(Burst) в целом соглашусь, работа ради работы, фактически попытка! сделать очень крутой велосипед. И это в тот момент, когда просто выкинули вполне рабочий инструмент для мультиплеера, когда не работают многие дополнительные инструменты в Unity, т.к. не поддерживаются или изначально с багами, хотя справка может говорить иное. Да даже инструментов для async они не стали делать. И чую, опять придётся ждать переезда на новый .Net(которым уже все остальные C# разработчики пользуются) лет 5. Большинству разработчиков хватило бы нормальной работы Update в виде async-ов. Даже в сильнонагруженных проектах мне этого бы хватило.
            А вот с памятью не соглашусь. Выделение памяти можно контролировать, но надо хорошо понимать язык C# и процессы. В норме, память выделяется только в момент загрузки/переходов.


        1. Brightori
          12.09.2021 20:39

          2д игр стало меньше в целом, платформеры были, но мало, на анриле может парочку припомню.

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


        1. rusbaron
          14.09.2021 11:07

          Тут недавно расстроило состояние ортографической проекции камеры(Свет и динамические тени не работают от слова совсем и по багтрекеру ясно, что это AS DESIGN), так что 2д и аля 2д не для анриала.