Комментарии 26
По-моему, самым первым пунктом должно стоять "Прочитайте EULA" или что-то подобное и разберитесь в лицензировании игр на движке.
А толку, если всё равно задним числом эту еулу менять могут?
Юнити тоже ведь изначально лишнего не просила.
Никогда не стоит доверять крупным корпорациям, но, скорее всего, не обманет
Я не понимаю что за прикол с блюпринтами. Буквально каждый человек, который что-то рассказывает про анрил обязательно упоминает какие же это прекрасно, что в этом мире существуют блюпринты. Это какой-то локальный мем? Какой-то то аналог рикроллинга среди анрильщиков? Код, хранящийся в бинарных файлах, это же просто черная дыра из мерж конфликтов.
Скорее попытка Unity сделать Bolt, и гораздо более успешная сторонняя библиотека CanvasFlow являются аналогами блюпринтов. Я делал одну игру с активным использованием этой штуки и хочу сказать, что если вы чётко понимаете зачем она вам, это прям хорошо и удобно. Главное не пытаться сделать с её помощью вообще всё, и расширять её кастомными нодами и макросами.
Прикол в том что это визуальная среда программирования развиваемая эпиками годами, начиная с 3го анрила. Она максимально глубоко интегрирована, она постоянно поддерживается и развивается.
Просто тысячи проектов могут быть реализованы на блупринтах в чистом виде без какой-либо реальной необходимости касаться С++.
Unreal сложна в освоении чем Unity - кардинально другой подход в проектировании и использовании инструментария.
Одна сборка под платформу чего стоит. Ради теста попытался собрать шаблонный проект под windows - ушло более 20 часов и это при тестовой 3d сцене, которая предлагается для начала проекта. По характеристикам видеокарта на 4 Гб и оперативка на 8 Гб. Использовался Unreal Engine 5.2.
По мне видно, это не то же самое что собрать проект на Unity, особенно для разработки игр под мобильник. Если проект большой и у вас мощные ПК, то конечно Unreal в остальном случае нужно что-то облегчённое Godot, Panda3d, Construcrtor, Defold, Pygame, Game Maker, NeoAxis, Castle Game и т.д.
Про то что у Unreal билд пустого проекта без плагинов имеет неадекватный размер никто никогда не упоминает
Лучше переходите на Stride. Будете наконец-то нормально программировать и иметь все исходники. И даже шейдеры ООП!
А не проприетарный движок с возюканьем мышкой
Unity именно и привлек много кого своей простотой и возюканьем мышью. Всякие инди часто инициатива художника (условно, или просто далеко от ит человека), а не программиста).
Сейчас ООП это, скорее, минус, а не плюс для разработки игр. 2000-е давно прошли.
И наступили тёмные 2020е? В чем минус-то?
В 2020-х процессоры становятся всё больше SIMD, и им гораздо эффективнее обрабатывать вектора координат (скоростей, стамины, и т.п.) всех объектов сцены, чем выковыривать те же самые данные из середины каждого объекта. Ну и если перекладывать расчёты на видеокарты, их ЯП не дружат с ООП.
Так для ГПУ скомпилируется в не ООП. Под ЦПУ же никто уже не пишет на ассемблере, а так то ЦПУ тоже ООП не понимают.
Если хочется обрабатывать сразу "всех объектов сцены", то можно реализовать ECS. Ну а уж про SIMD стоит вспоминать только если какая-то стратегия на десятки тысяч юнитов делается, ну и NET должен через 1-2 версии реализовать SIMD нативно (а не через отдельный компилятор и особый рантайм как в юнити). Но опять же: это действительно нужно очень редко. В большинстве игр производительность страдает из-за кривых ассетов, а не из-за логики. Потому что логика в большинстве игр процессора научились вывозить ещё 10-20 лет назад причем тогда в играх даже физики было сильно больше.
А, например, в том же юнити напридумывали костылей типа IL2CPP и Burst потому что зачем-то сделали внутренности движка на плюсах и взаимодействие с ними порой через объекты в куче, ну и в качестве райнтайма выбрали Mono, который сам по себе медленнее, чем NET и даже медленнее чем Net Framework. Если использовать ровные руки, не делать лишних аллокаций и не делать лишних вызовов в другой рантайм, то для хороший производительности большинству проектов реально хватит даже NET Framework 4 без всяких SIMD.
А так игровую логику даже на всяких языках и рантаймах с большим оверхедом, типа Java, JS, Phyton и Lua
il2cpp нужен, чтобы пройти требования Apple и выйти на iOS. Там запрещено иметь в приложении jit или интерпретаторы (кроме js-движка safari). Наверное, боятся, что приложение после модерации скачает код из сети и сменит функциональность. Или кто-то напишет свой магазин приложений, запуская любой скачанный код из своего приложения. Поэтому только компиляция в нативный код на этапе сборки приложения. А mono — потому что когда это было выпущено, MS ещё не взял курс на опен-сорс .net и на других платформах не быти реализации от MS.
Вообще-то il2cpp не нужен. Поскольку в apple appstore всегда пропускались приложения на Xamarin. Более того в apple appstore есть даже IDE для NET (Continuous .NET C# and F# IDE), которая прям на устройстве запускает свеженаписанный код.
Вообще именно промежуточная компиляция в плюсы лишняя поскольку тот же Xamarin mono AOT компилируется в LLVM (который точно разрешен аполом) минуя всякие плюсы и экономя кучу времени.
А net framework вообще умеет компилироваться прям в машинный код (а не просто в LLVM) с помощью ngen. Net внутри UWP умеет компилироваться прям в машинный код с помощью Net Native. И наконец современный NET умеет компилироваться с помощью Native AOT.
Итак, вы решили перейти с Unity на Unreal Engine