Комментарии 168
Любой движок станет out of control, если дать волю художникам. Поэтому нужно постоянно бенчмаркать и постоянно микро-оптимизировать. Чтоб не проснуться, а у вас ночной билд 15fps на тир-1 таргете.
А как из того что DOTS сырой следует вывод о том что Unity не подойдет для простых игр?
"Классическая" архитектура с монобехами никуда не девается, а для большого числа игр этого с головой достаточно. Это же и есть альтернативный архитектурный подход, отсутсвие которого ставится в претензию в конце статьи.
Проблема большого числа проектов на юнити вообще не на стороне движка, а чисто на стороне проектирования того кода, который с движком работает
А как из того что DOTS сырой следует вывод о том что Unity не подойдет для простых игр?
Никак не следует. В статье же написано, что Unity больше подходит простым играм.
"Классическая" архитектура с монобехами никуда не девается, а для большого числа игр этого с головой достаточно.
Все ведёт к тому, что о монобехах просто забудут, как о старом решении, а на их место придёт Project Tiny. Как минимум, все пакеты сейчас нацелены именно на DOTS
Это же и есть альтернативный архитектурный подход, отсутсвие которого ставится в претензию в конце статьи.
Не ставиться, я просто декларировал архитектурные проблемы монобеха для больших игр, ибо он для них не сделан. Я не предъявлял претензии о отсутствии другой архитектуры для больших игр, это же полностью бы противоречило статье. Возможно, я вас не правильно понял.
Проблема большого числа проектов на юнити вообще не на стороне движка, а чисто на стороне проектирования того кода, который с движком работает.
Полностью согласен.
Я сейчас занят, буду отвечать вечером.
Все ведёт к тому, что о монобехах просто забудут, как о старом решении, а на их место придёт Project Tiny. Как минимум, все пакеты сейчас нацелены именно на DOTSProject Tiny создавался совсем не для этого.
А для чего же? Раз не для казуальных игр, как написанно в документации которую я приводил в статье. Мне действительно интересно узнать.
Все ведёт к тому, что о монобехах просто забудут, как о старом решенииКазуалки лишь часть игр на Unity. Монобехи никуда не уйдут, т. к. Project Tiny не подойдёт для многих типов игр.
для рекламы и GooglePlay Instant
для игр которые будут весить до 10 MB
А MonoBeh если и уйдут в историю году эдак в 2030 то к тому времени DOTS станет таким же удобным как сейчас MonoBeh
Я понимаю что эта статься это крик души и именно по этому многие тезисы недостаточно аргументированы. Просто субъективное часто неверное мнение автора :)
То что юнити раз за разом пытаются ввести какую-то фичу тысячелетия, не справляются и дальше делают вид что ничего не было, это известный, и немножко печальный факт.
В остальном или вкусизм, или недостатки которые перекрываются недостатками в других движках (идеального же нет). Да, юнити подвисает после каждого изменения в коде. А анриал выдает ворох предупреждений после каждой передвинутой лампочки. Да, юнити не может в интерфейс, но в анриал, как по мне, достаточно мрачная работа с объектами, и т.д.
Так что в принципе, для любой игры кроме "АА симулятора ходьбы со светом из коробки" юниту подойдет как минимум не хуже.
Хотя вот с DOTS, ECS и Bolt прям совсем грустно что-то, да.
Уже не совсем техническая, но огромная проблема Unity прошлого, настоящего и будущего. Unity старается быть универсальным, но игровой движок по природе своей не может быть универсальным.UE сейчас: «Ну да, ну да, пошёл я нахер». Каждая компания пытается расширить ЦА своего продукта.
Godot. Сам не пробовал, по ощущениям Unity v2, но опенсоурс и не будет требовать от вас деньги и ставить свой логотип в начале.Но будет требовать кучу времени на допилку и написание компонентов, которые вам нужны.
GameMaker: Studio. Создан для 2д игр, на нем сделали Undertale. Без подписки минимум за 10$ делать ничего не хочет.Это как сказать человеку, который хочет купить быструю машину, чтоб он взял мотоцикл, ведь тот дешевле, да и по лесу может ездить.
Вместо Unity лучше рекомендовать UE или Unigine, если без конкретики.
Такое решение довольно простое в понимании и не требует вообще никаких навыков у программиста, у вас все под рукой. Для больших проектов это, естественно, никуда не годиться. Тут нет какой-то внятной архитектуры, у вас логика приложения находиться сразу же в структуре с данными (компоненте). MonoBehaviour почти не предоставляет никаких абстракций, не дает инструмента для управления зависимостями, методы для поиска объектов с MonoBehvaiour на сцене де факто антипаттерн из-за производительности, методы для вызова Message-методов у других MonoBehaviour ещё больше антипаттерн из-за еще худшей производительности.Тут я совсем потерялся.
- Вам ничто не мешает логику отделить от монобехов. К примеру, тот же AI можно вообще не на них делать.
- Ну да, нет готового чего-то, как в том же LibGDX и его Scene2d (или как их там), но что мешает самим написать?
- Искать по сцене ничего и не надо, это на уровне зависимости настраивается. Тот же Zenject.
- Общение можно организовать через свой простенький менеджер сообщений, чтобы не обращаться напрямую, а просто события кидать. Кому надо, тот на них подписывается.
С Editor и UI тоже не всё однозначно. Во-первых, они (вроде при выходе 5) довольно неплохо улучшили UI.
Во-вторых, многим наоборот нравится, что работа с UI происходит с дефолтными компонентами.
Для игр они сделали какой-то хлам с Canvas-ом и перетаскиванием панелей по иерархии сцены, а для редактора они предоставили что-то невообразимо ужасное с IMGUI на C# и рефлексией.Но ведь в html/css точно такое же перетаскивание и дерево DOM-элементов.
Перезагрузка всех ресурсов с надписью «Hold on» после каждой правки кода. Команда Unity клянется что ничего не могут с этим сделать, но это нетерпимо.
Но ведь Assembly definitions частично улучшили ситуацию 🤔
В Unity до сих пор нет поддержки C# 9, я просто напомню, что последняя версия уже C# 10.
А чего именно из C# 10 вам так не хватает?
Самое забавное - в юнити 2021 есть поддержка С#9.
Поддержка C# 9 In progress уже как минимум пол года и не релизнута. Не верите мне, повертье роадмапу самого Unity.
Unity 2021.2 уже с октября в релизе, там есть поддержка
Но ведь там большие проблемы с зависимостью от нового рантайма, они для этого сейчас и начали свой форк CoreCLR и будут переходить на csproj со своих asmdef. На демонтаж старой инфраструктуры может уйти много времени
И это круто?
UE сейчас: «Ну да, ну да, пошёл я нахер». Каждая компания пытается расширить ЦА своего продукта.
UE не пытается быть универсальным, но ЦА расширяет, к примеру с Мандалорцем вышло здорово, видны перспективы.
На телефоне не увидел весь комментарий. Допишу ответ.
Вам ничто не мешает логику отделить от монобехов. К примеру, тот же AI можно вообще не на них делать.
Ничего, кроме того, что монобехами подразумевается, что вся логика пишется в них с Await(), Start(), Update() и т.д
Ну да, нет готового чего-то, как в том же LibGDX и его Scene2d (или как их там), но что мешает самим написать?
Не знаю к чему это отнесенно, и что такое LibGDX.
Искать по сцене ничего и не надо, это на уровне зависимости настраивается. Тот же Zenject.
Началось. И почему это искать обьекты на сцене не надо? У Valve в Source есть и поиск сущеностей на сцене, и поиск сущеностей в радиусе, и поиск сущеностей в aabb и т.д, и работает он быстро. Почему базовый функционал движка не работает как следует и я не могу его использовать, а должен писать новое решение. Конкретно DI контейнер мне тут не поможет.
Общение можно организовать через свой простенький менеджер сообщений, чтобы не обращаться напрямую, а просто события кидать. Кому надо, тот на них подписывается.
Тоже самое что и выше. Почему функционал движка медленный и я не должен его использовать, а должен в очередной раз писать свое решение для штатного функционала ради которого я и выбрал готовый движок.
Я вообще описывал это в статье, под заголовком "Декларируемая универсальность" и в абзаце "Так и живут разработчики под Unity с гайдлайнами по оптимизации, в которых рекоммендуют не использовать половину функций движка."
Но ведь в html/css точно такое же перетаскивание и дерево DOM-элементов.
В каком мире буквальное перетаскивание руками компонентов с обьектами по иерархии сцены и написание лейаута со стилями тоже самое?
Но ведь Assembly definitions частично улучшили ситуацию 🤔
Или раньше было ещё хуже, но это не помогло. У меня весь код поделен на множество asmdef, для Network'а, для UI, для рендера, в каждом пакете причем по 3 штуки: Runtime, Editor и Tests. Но все равно Hold on по 2 минуты.
А чего именно из C# 10 вам так не хватает?
Это шутка :D? Я не отказался хотя бы от record, override возвращаемых типов и сокращенного new из C# 9.
Началось. И почему это искать обьекты на сцене не надо? У Valve в Source есть и поиск сущеностей на сцене, и поиск сущеностей в радиусе, и поиск сущеностей в aabb и т.д, и работает он быстро. Почему базовый функционал движка не работает как следует и я не могу его использовать, а должен писать новое решение. Конкретно DI контейнер мне тут не поможет.
Мы из коробки имеем немплохой контролль.
Что мешает написать в пару строк "SearchableObjectManager" и спокойно в него забивать только те обьекты, которые можно искать. По ХП, по радиусу и т.п. Просто искать конкретную сущность по всей сцене - это не правильно в любом движке априори.
Должно быть события или причина, что бы один обьект взаимодействовал с другим. Например что бы НПЦ взял в инвентарь интерактивный обьект, который видит. Ему не надо этот обьект искать по сей сцене. Этот обьект должен попасть в поле зрение НПЦ, т.е. тут отработает физика, когда меш обьекта попадает в поле радиуса. С этого момента НПЦ известно об существовании этого обьекта и он запишет его RID/ID/Ссылку на него куда то в память. И когда наступит триггер - он обратится к памяти и попытается взаимодействовать с этим обьектом.
а если у тебя появляется необходимость на сцене ИСКАТЬ другие обьекты, для взаимодействия - то что-то изначально в построении игры не правильно, даже в рамках ECS. Один компонент одной сущности взаимодействует с другим компонентом другой сущности. Но никогда не должны взаимодействовать с сущностью напрямую.
В каком мире буквальное перетаскивание руками компонентов с обьектами по иерархии сцены и написание лейаута со стилями тоже самое?
Qt например?
Я считаю, что игровые интерфейсы построенные на xml, js и т.п. - не лучшее решение. Интерфейсы - это не всегда плоская веб-картинка на плоском мониторе. Интерфейс может быть обьемным, трехмерным, иметь более сложную логику, а не быть строго квадратной абстракцией загноновй в xml/js параметры.
на сегодня мне нравится решение godot. Интерфейсы имеют стили, они легко анимируются. Но при этом ui - это все обьекты, а не веб-магия. И мне не надо обучать дизайнера, который рисует кнопочки, рисует мне персонажей, травку, муравку и т.д. - эти кнопочки кодить в xml. Он легко может драг-н-дроп глянуть, как на игровой сцене его супер-кнопка смотрится прям сейчас.
JS движки не смотрели? Есть уже что-то годное?
Преимущества DOTS то вполне понятны. Это реализация data oriented подхода, который критичен для производительности любого кода на современных процессорах. Очевидно, что сделать это простым сложно. Особенно для дизайнеров. Даже для программистов подход не очень-то стандартный.
Зачем они это сделали кажется рассказали на SIGGRAPH 2021 REAC: Unity Rendering Architecture. Они как раз таки хотят освободиться от стереотипа, что юнити это двиг для инди и мобильного треша. Их идея сделать архитектуру, которая скейлится от мобилок, до хайэнд пека и рендер ферм. И подход DOTS здесь понятен. Чтобы скейлиться нужно уметь параллелить код. Желательно автоматически, подстраиваясь под конкретную железку. M:N модель многопоточности, реализацией которой Job системы и являются, это позволяют и я уже неоднократно видел доклады про них в современных играх. Собственно, не только игры любят этот подход.
И дальше будет только хуже, потому что ноги здесь растут из проблем в масштабировании железа. В индустрии огромная проблема с дизбалансом вычислительной мощности и скорости памяти, которая ощущается от мобилок вплоть до HPC и облаков. Кэши кое как эту проблему скрывают, а data oriented подход призван эти кэши наиболее эффективно использовать. Так что Unity тут не более чем подстраивается под современные реалии.
А сейчас вон вышел UE5, на фоне него все эти DOTS'ы и ECS'ы Юнитишные вообще игрушкой кажутся, учитывая, что они всё ещё не доделаны.
Я здесь чисто мимо проходило, любопытно чего в геймдеве творится, но в чем проблема конкретная? Сам подход для меня очевиден. По-другому они на рынке не выживут. Эта проблема не 2 и не 3 года уже существует и становитсят только хуже. Да, сложно и отлаживать его можно долго, но чего поделаешь. Процессоры, которым не нужны кэши, наше поколение вряд ли застанет.
Часто покупают какое-то решение и убивают. Вон купили Bolt, хотели аналог Блюпринтов из UE сделать, но забили на этого в итоге и заморозили Bolt 2.
Сейчас вон UE5 вышел, Godot 4.0 готовится к выходу. Если Unity так и дальше продолжит тупить, то грустно…
Ну тут их тоже можно понять. Они видимо гонятся за анрилом, который подмял под себя уже и кинематограф. Другое дело, что анрил вроде бы не ставит перед собой задачу быть удобным для всех, от инди до кино. И смотря на то, что они творят в 5 версии в плане рендера, смотреть на юнити конечно печально.
Godot 4.0
Им кто-то реально пользуется?
А что с годотом не так?
Не знаю, но значимых проектов на нем я не вижу. Анрил - полно. Юнити - полно. Да даже ниже упомянутый monogame - там вижу celeste и street fighter.
Так молодой, еще будут.
какой молодой, если создан в 2007?
Так «в народ» вышел только c 2014. Game Maker появился вообще в ~2000, а из «значимых» игр до сих пор чуть ли не только Undertale.
А так, из недавнего — Sonic Colors Ultimate сделан на форке Godot.
Чего на юнити полно? 99.9% это мобильные донатные помоечки. Поробуй сравнить просто список игр на UE и Unity. А Godot это офигенный движок, но все ждут четвертой версии с улучшенным рендером.
То, что единственное его реально преимущество - это опенсорсность и бесплатность. Ну и UI-билиотека неплохая.
В остальном же, читая что в "а в Unity вот така фича тормозная/неудобная/глючная", почти всегда оказывается, что в Godot подобной фичи вообще нет. То есть там надо под себе с нуля писать почти всё.
И вот тут на сцену выходит AssetsStore, в котором "почти всё" есть. А у Godot в asset library нет. Понятно, что большая часть это шлак, но в Godot asset library 1096 пакетов, а в Unity AssetsStore 2963 страницы.
Вообще, по моим впечатлениям, это примерно как Gimp после Фотошопа. Формально вроде бы большая часть фич присутствуют, но как только выходишь за рамки туториалов, и начинаешь делать реальные задачи, то почему-то оказывается, что на работу уходит в 2-3 раза больше времени.
В целом, это нормальный движок для супер-мелких проектов, которые можно в одно лицо запрограмить в пределах 1-2 месяцев. Если больше, вы уже закопаетесь в написании собственной "стандартной библиотеки".
А в Unreal Engine фич много?
И что эти 2963 страниц? Большинство это просто мусорные пакеты с одной текстурой или моделькой. да ещё и стоит всё дофига. А когда доходит до реальных задач проектирование на годоте может быть даже быстрее чем на юнити. Как пример могу привести банальный шейдер воды, который бы работал в VR. В юнити нашёл только платные системы по 100 баксов. А для годота написано куча готовых решений.
три года назад, известно было об одном только проекте в бете, в стиме мне, на godot 2.x еще.
Cейчас уже к версии godot 3.4, игры начали плодится как грибы. За последние два года, игр стало существенно больше на мобилке. 2022 год, должен заполнится релизами игр, которые начали делать в 2018-2019ых годах.
Тут всё очевидно, двигать 50 тысяч снарядов в каком-то шутере быстрее в 32х потоках одновременно.
Ну вообще-то не очевидно. Вдруг мы в память уперлись.
Изначально в статье об этом было написано, но нигде не нашел источник с которого можно было бы подтвердить информацию. Раньше в документации Entities писалось, что данные хранятся эффективно в памяти процессора, и из-за этого меньше миссов. Но это куда-то пропало после какой-то минорного обновления Entities, или я не смог найти.
годиться находитьсяточно из песочницы )
Amethyst. Движок на Rust, пока без своего редактора, естественно опенсоурс.
Наткнулся недавно на эту штуку. Выглядит интересно, но смущает, что они уже давно переходят (?) на новую ECS библиотеку и статус перехода со стороны не понятен. Тем более, что по докам старая выглядит удобнее.
Я честно стараюсь поменьше без приглашений врываться и евангелировать за раст)
Но, если уж на то пошло, Amethyst как движок давно уже не сильно живой был, а недавно совсем помер. Я бы из претендующих на масштабность чисто растовых движков советовал смотреть на Bevy или rg3d - только сразу предупреждаю, что это все еще штуки в первую очередь для энтузиастов, слишком все сырое.
С одной стороны огорчает поддержка VR в движках на расте. А с другой стороны это возможность поделать свой движок и изучить что-то новое :)
Можно предложить врываться в wasm + WebVR.
Хочется нативное решение для Квеста сделать, поэтому wasm не подходит. Сейчас использую связку из OpenXR и ash. Для тестирования собираю "плосскую" версию с winit. Поглядываю на Vulkano как на безопасную альтернативу ash. На прошлой неделе в wgpu добавили поддержку Multiview, что то очень радует, но с наскока "ворваться" не вышло: не понял как подружить wgpu с OpenXR.
Тоже хотел написать движок на расте для VR в открытом мире, читал учебник по вулкану перед тем как статью начал писать ;)
Godot. Сам не пробовал, по ощущениям Unity v2, но опенсоурс и не будет требовать от вас деньги и ставить свой логотип в начале.
Дальше можно не читать, и забыть что перед этим прочитал в этой статье.
Microsoft XNA. Не движок, но фреймворк для создания игр на C#, больше не поддерживается. Но на нем создают довольно много разных инди игр и по сей день, одна из самых популярных это Stardew Valley.
На самом деле фреймворк XNA получил свое развитие в виде https://www.monogame.net/ - последний релиз был год назад, а последний PR был смержен 27 октября, т.е. пока еще живой.
Ради таких комментариев и стоит писать на хабр, спасибо!
А также есть второй форк XNA - FNA https://github.com/FNA-XNA/FNA с последним релизом 4 дня назад. Так что дело XNA живет по сей день
А поддержку встраивания в VS он имеет?
Такой паттерн хорошо подходит сложным играм, в которых есть очень много сущностей которые надо очень часто перебирать. ... ECS плохо подходит играм, в которых мало сущностей и их не надо часто перебирать (например 99% мобильного рынка).
Позволю себе не согласиться с таким утверждением. ECS в первую очередь подход к проектированию кода, а не паттерн для быстрого итерирования по тысячам сущностей. Главные достоинства ECS - слабая связность логики(а следовательно хорошая модульность, тестируемость) и комбинаторика свойств(проще сочетать в сущностях различные элементы логики). Благодаря этим достоинства ECS хорошо подходит как простым играм(99% мобильного рынка), так и сложным, особенно где много вариаций сущностей. И очень хорош для какого-нибудь гиперкэжа, где можно реюзать большую часть кода между проектами(при грамотном проектировании, ессесно).
PS Есличто речь именно про ECS, а не DOTS
GameMaker: Studio. Создан для 2д игр, на нем сделали Undertale. Без подписки минимум за 10$ делать ничего не хочет.
Как это ничего не хочет? Там же платная подписка только для экспорта?
Вот если совсем кратко, то мне кажется, что нынешних компьютеров с головой хватает для нужд инди-разработчиков. Иными словами, MonoBehavior, C#, сборка мусора и прочие тормоза -- ну и ладно, сгодится. Бывает, появляется что-то жрущее процессор типа хитрых шейдеров или какой-то умной физики, чтобы волосы там или юбочка развевались красиво, но на этом всё. Поэтому разговоры про миллионы юнитов и летящих пуль и прочую голливудскую красоту -- это всё не для простых смертных. Могу ошибаться, конечно, но так мне видится.
Соответственно, затронутые автором проблемы -- это про AAA проекты фирм типа EA или UbiSoft, где как раз миллионы юнитов, графика как в блокбастере, вылизанный мир и т.д. и т.п. Ну так и пусть со всей этой радостью, гм, имеют дело, за такие-то деньги. Выдавим скупую слезу по их тяжёлой участи.
AAA проекты фирм типа EA или UbiSoft, где как раз миллионы юнитов, графика как в блокбастере, вылизанный мир и т.д. и т.п.У них в основном свои движки.
Целевой платформой может быть не только ПК. В шлемах VR проблема с производительностью проявляется в полный рост и без миллионов юнитов и пуль. Лично мне поэтому не хочется использовать Unity, а хочется сделать движок, оптимизированный под мою конкретную задачу. Хотя на самом деле это только одна из причин. Другая в том, что хочется изобрести свой велосипед и получить в процессе опыт и удовольствие :)
При всем уважении к автору, статья достаточно спорная. Не совсем понятно, как долго он работает с Unity, и работает ли вообще.
Они решили, что лучший способ сделать сишарп таким же быстрым как и плюсы, это сделать из сишарпа плюсы! занавес, бурные овации, публика в шоке
Команда разработчиков МS уже сделала это, вы просто не в курсе. Уже анонсирован ввод классов и методов для работы с неуправляемой памятью, которые фактически из C# делают C++. Просто юнитеки сделали это раньше.
Mono потому что на C#, раньше ещё был, к примеру, JSBehaviour, но все языки кроме C# в Unity бесславно умерли, так и остался один единственный MonoBehaviour.
Я "наблюдаю" за его развитием с 2014 года, и еще помню те времена, когда Unity поддерживал Boo. Все это так или иначе транслировалось в IL, поэтому сожалеть особо не о чем. Хотя Boo был чертовски хорош.. да.
За 16 лет они не смогли создать пакет для адекватного интерфейса с xml/css/js и имплементировать редактор своего движка на нем. Для игр они сделали какой-то хлам с Canvas-ом и перетаскиванием панелей по иерархии сцены, а для редактора они предоставили что-то невообразимо ужасное с IMGUI на C# и рефлексией.
А надо было? IMGUI существует в Unity с независимых времен, пока емнип в 4.6 не появился Convas, который был реальным прорывом. Почему его не выпилили окончательно? Наверно потому, что собственные плагины для Editor UI пишут три с половиной калеки, а для 99% пользователей этот функционал не является решающим. Подобие WPF нужно далеко не всем, а те кто в нем реально нуждается, вполне могут собрать его самостоятельно.
Далее автор втирает о появлении стилей в подобии CSS, и жалуется на отсутствие поддержки скрипта. Что я могу сказать, JS-фанбой палится. Скрипт обьективно там не нужен.
У меня нет претензий к Unity кроме сильно затянутых сроков внедрения DOTS. Единственное, что меня напрягает, так это
Фактически упраздненная система голосования за фидбеки на сайте
Абсолютно убогая система создания бандлов, тегов и тд
Отсутствие нормальной поддержки и инструментов для создания текстурных атласов. Существующие атласы, это же позор какой-то.
Невозможность ограничить количество уровней MipMaps, из-за чего приходится предусматривать в атласах нереальной толщины padding'и
Невозможность добраться до некоторых свойств редактора, кроме как через System.Reflection
Поддержу про интерфейс как человек который из веба перекатился в геймдев на Юнити. Работать с ЮИ (на проекте много формочек, панелек, окошек открываемых друг из друга) на юнити после JS+HTML+CSS сплошное удовольствие. Настраивается все очень легко, якоря, предпросмотр, доступ по дереву к нужным компонентам, скейлинг в зависимости от разрешения, контейнеры со списками которые умеют в выравнивание из коробки.
После мрака стилей которые надо вслепую верстать внахлест и проверять проходя до нужного компонента в интерфейсе прям кайфуешь.
Уже анонсирован ввод классов и методов для работы с неуправляемой памятью, которые фактически из C# делают C++.
Можно по подробнее? Может какими-то ссылками поделитесь или скажите где про это читали? Мне как шарписту очень уж интересно почитать об этом. Заранее спасибо.
Я ни разу не из game dev, но вот это зацепило:
Для того, что бы проитерировать 3 компонента c помощью IJobChunk, вам надо 43 строки кода
Собственно, если бы мне на бэке нужно было бы что-то асинхронно выполнить, у меня был бы ± точно такой же код по объёму и смысла.
Так что претензии не понимаю.
У Юнити всё плохо, но в перспективе всё хорошо.
Не было DOTS - плохо, но ввели и в будущем станет хорошо. То что есть уже сейчас можно использовать. И это прилично ускоряет.
Количество готовых крутых решений (платных и встроенных) увеличивается, приближается к количеству таких в Unreal.
Таким образом скоро ААА-проекты на Юнити догонят ААА-проекты Анриала.
Мне кажется перспективы хорошие у Юнити, как у движка так и у компании.
Статья не понравилась абсолютно. Очень однобоко получилось и не аргументированно вообще.
Я уже лет 15 наверное плотно работаю с 3D графикой и на чистом C++ (OpenSceneGraph например), так и на Unreal/Unity. Вот работы - https://www.youtube.com/channel/UC6w7MxEoE2tgWjqi5PqlFAg.
Так вот точно могу сказать, что ерунду можно устроить и там и там, порог входа везде достаточно низкий и можно кашу из BluePrint'ов заварить быстро и не разберется потом никто.
Мне оба инструмента абсолютно утраивают и я их кстати никогда и не сравниваю.
Они решили, что лучший способ сделать сишарп таким же быстрым как и плюсы, это сделать из сишарпа плюсы!Какие же это плюсы, в С++ не нужно использовать голые указатели и функции работы с памятью (кроме очень ограниченных участков внутри имплементации, например, кастомного контейнера). А здесь получился чистый Си.
Я тоже частенько ворчу на Unity и с завистью поглядываю на новые фичи UE, однако не считаю правильным драматизировать ситуацию. Да, я согласен с критикой того, что новые направления развития Unity оказались чересчур масштабными, разносторонними и увязли в производстве. Но никаких серьезных проблем с проектированием на MonoBehaviour в юнити я не вижу даже для больших проектов, стремящихся к ААА-уровню. Все критичные для производительности места можно расшить. Удобство работы плюс-минус сравнимо с UE, а где-то и лучше за счёт расширений. Фундаментальных проблем препятствующих качественной разработке нет. Есть лишь временные трудности у авторов ассетов на сторе, так как при столь радикальных изменениях которые вносятся в связи с переходом на SRP и DOTS им трудно добиваться стабильности. Но эта проблема осознана, критика услышана. Весь этот год заметно, как движок стабилизируется. Очевидно, конечно, что Unity проигрывает UE в темпах внедрения инноваций и отчаянно пытается сравняться в темпах захвата новых ниш, но это не катастрофа. Будем надеяться что переход на DOTS состоится и у команды найдутся силы вернуться к развитию менее фундаментальных функций и пекеджей, таких как мультиплеер, граф анимаций, альтернативы enlighten realtime gi и пр.
серьезных проблем с проектированием на MonoBehaviour в юнити я не вижу даже для больших проектов, стремящихся к ААА-уровню
Довольно странно, можете привести примеры игр стремящихся к ААА уровню, которые не испытывают проблем с MonoBehaviour? Я думал что к этому вообще притензий не будет.
Да, я согласен с критикой того, что новые направления развития Unity оказались чересчур масштабными, разносторонними и увязли в производстве.
У меня были ещё вопросы к тому, почему они делают это на C#. Могли бы написать биндинги к Rust и на них уже делать ECS, и Burst бы не нужен был кстати.
А так я тоже надеюсь что они как-то пофиксят всё. Я не ярый ненавистник Unity, каким меня тут воображают, просто статьи о минусах Unity не было.
Если рассматривать MonoBehaviour как инструмент, который нужно использовать с умом, то проблем с производительностью действительно можно избежать (ну или хотя бы свести их к минимуму). Разумеется, если завязывать большой проект на компонентной системе юнити (т.е. каждый модуль каждого объекта - отдельный MB со всеми существующими эвент функциями) то проблем с вычислениями на проце можно хапнуть с горой, хотя опять же в контексте игростроя код не так часто бывает камнем преткновения по производительности, ну, если мы не делаем какой-то масс баттлер или что-то уж совсем криминальное. Чаще же намного это графика и модификация объектов на сцене, но это уже отдельная тема для топика.
Я для себя выбрал подход, в котором MB это точка входа сцены, фасадные классы и инсталлеры (чтобы не компилить код по новой при каждом изменении параметров объекта). В этом плане мне юнити и нравится: это просто инструмент для связи моего кода и сцены. Я тут программист, и я хочу решать, как будет происходить управление зависимостями на сцене и между сценами, как будет простраиваться архитектура (благо, решений как готовых так и готовых к написанию бесконечное множество), и я уже точно могу быть уверен, что если я и встречаю какие-то проблемы расширяемости/масштабируемости моего проекта, то я и есть виновник этих проблем.
Разрабатывал на Юнити много чего 3+ года подряд, да и сейчас иногда возвращаюсь (хотя свичнулся в бэкенд).
На самом деле в нем шикарная работа с разработкой внутриигрового UI сейчас. Я бы с огромным удовольствием верстал и страницы для веба в таком редакторе - перетаскивая объекты, настраивая background image, якоря и так далее.
А основные проблемы на мой взгляд - юнити гонится вообще в разные стороны и не доводит ничего до конца. Множество багов, которые не фиксятся годами. И каждая версия приносит их еще больше. 3-5 лет назад движок был куда стабильнее.
Согласен, огромная проблема юнити, что в мажорных релизах они не выбрасывают старый мусор а многие вещи не развиваются вообще:
UNet можно было развивать и улучшать
Меши - нету стримминга, приходиться пилить костыли
Скиннинг через через шейдеры отсуцвует как понятие, приходиться пилить костыли. ( да в юнити скиннинг через CPU и копию меша )...
Меш Коллайдеры - нет стримминга, зависят от мешей (которые ориентированны на рендер), хотя должен быть свой класс...
Анимация - не стримминга, стремный аниматор, с кучей проблем и слабым UI
Звуки - просто ужас, нету нормального стриминга, есть проблемы с ФПС, проблемы с памятью ...
Текстуры - стримминг есть, но кривой и косой.
Стриминг как таковой отсуувует в понимании доступ к единице ресурса, или его части. Взять тот же Roblox, при входе в игру видно как все постепенно выкачивается с сервера. Юнити просто не готов так работать, из-за это:
Нет нормальной работы в веб среде, где нужен доступ к единице ресурса, и доступ к разным типам текстур pvrtc or etc or .... По этому нет мобил ...
Нет окклюжн кулинга для динамичных сцен, только запеченная статика.
Нету возможности в редакторе запустить несколько игр сразу ( для теста сетевого кода ), приходится использовать хард линки и несколько редакторов...
То, как редактор работает с ресурсами, это вообще кошмар, не дай бог надо сделать re import all...
Нету доступна к текстуре глубины в стандартном рендере, как будто это что-то страшное, приходиться 2 раза рендерить сцену в форварде.
И еще вагон с тележкой мелочей, которые на вскидку не скидку не вспомню ....
Тем не менее, я благодарен юнити, и желаю им развития и успехов!
На счёт стриминга не понял - а как же addressables? Мы вполне хорошо стримили уровни для мобильной AR игры. Что еще удобно - не нужно делать новый билд и заливать всё на стор, просто обновляем addressables с правками уровней или префабов. За счёт базы универсальных компонентов удавалось даже новые режимы игры создавать без перекомпиляции.
Маленько офтопный вопрос — почему вы везде пишете две м в слове стриминг? Их нет даже в оригинале — streaming.
Про аниматор - не удобная работа с спрайт листами. Создавать несколько анимаций, вручную перетаскивать каждый спрайт для каждого имеющего спрайт-листа это куда менее удобно, чем setSpriteRect(frameSize.X*frameID,frameSize.Y*animID,frameSize.X,frameSize.Y)
Вот представим 200врагов и ты для 200врагов делаешь 4 анимации, заполняешь её 4 спрайтами. И делаешь 200одинаковых аниматоров....ладно, с этим разобрались и тут решили 4 фреймовую анимаширить до 8фреймовой.
Имхо, Amethyst пока не альтернатива Unity, потыкаться для развлечения можно, но что они там наворотили... Чего только стоят имплементация загрузки ресурсов и несобирающаяся документация на docs.rs. И вроде бы разобраться можно в этом всем, да только скудные возможности отбивают всякую мотивацию. Так что пока надеемся и ждем.
Для Rust еще есть ggez
Не смотрел, но вообще, разные движки на Rust'е можно посмотреть тут.
Анонс мнимого продолжения "У Unity всё плохо. Часть 2, или Что у кого болит..."
В этом выпуске мы пожалуемся на:
• Scriptable Rendering Pipelines и какого хрена Unity Technologies постоянно всё ломает;
• пакеты Input System и Animation Rigging и почему они не станут панацеей от болезней систем ввода и анимации;
• замороженную разработку пакета Kinematica, реализующего технологию Motion Matching;
• новый сетевой стек Netcode for GameObjects, который в плане эффективности устарел ещё до релиза;
• отсутствие нативной поддержки Terrain Details в HDRP.
Надо продавать права на экранизацию
И, в итоге, получится многосерийный арт-хаус "не для всех", потому что типичный workflow 90+% пользователей Unity не включает в себя практически ничего из вышеперечисленного. Обычно всё как-то так:
1. Сэкономил денег, купил доступный Low-Poly пак от Synty с модельками замков, хижин и персонажей, расставил на сцене - красиво!
2. Почитал про программирование логики игры в C#. Блин, как же сложно.
3. Попробовал бесплатный Visual Scripting, тоже не осилил, снова начал экономить.
4. Купил какой-то Builder, поменял модельки, стало ха-ра-шо. Уже можно грабить корованы, собирать лут и раздевать принцессу.
5. Захотелось добавить воду, снова начал экономить, купил ассет воды. Вода почему-то пропадает, если я удаляю скрипт Water System, надо впаять 1 звезду, пожаловаться разработчику (это не стёб! пруф) и запросить рефанд.
6. Рефанд отклонили, надо копить на новый ассет воды...
и так до бесконечности, а вы тут DOTS, ECS, Burst...
Что там с кооперативным редактированием Unity проекта в 2021 году? Что происходит если два человека поправили одну и ту же сцену?
Не видел движков, у которых этой проблемы проблемы в том или ином виде нет. Вот в Unreal вообще все ассеты бинарные и если конфликтуют то делай что хочешь.
Используем UnityYAMLMerge, но от большой переделки иерархии это все равно не спасет, придется править конфликты руками (со временем и в этом можно руку набить)
Раз уж затронута тема UE и C# - кто нибудь пробовал вот это?
https://github.com/nxrighthere/UnrealCLR
Заявляется полная интеграция .NET 5.0 внутрь UE с доступом ко всему API UE.
Если убрать из статьи воду (что ни говори, ругать UI редактора движка, на котором написана половина игр как-то странно, видимо люди справляются), то в статье противопоставляются Unity, в котором для тяжёлой графики плюсообразный C#, а для лёгких игр обычный C# и UE, в котором для чего-то сложного плюсы, а для простого блюпринты. Выбор из этих 2х совсем неочевиден. В статье явно не хватает ответа на вопрос о совместимости DOTS с простым юнити кодом. Если уперевшись в производительность классического Unity-кода на C# можно переписать одну подсистему на DOTS и получить высокую производительность это одно, а если нужно будет переписывать всё, то как бы совсем другое.
>в юнити старый c#, магические месаджи, издевательства над языком
Используйте Stride3d это самый идейно дотнетовый и при этом кросплатформенных движок.
>UIElements (UIToolkit), с xml и css, но без js
А зачем js в не вебпомойке? Вы возмущаетесь, что c# делают like cpp, но при этом зачем-то хотите в юнити like веб с js.
А по хорошему там и CSS не нужен. Это же очередная вебошибка - использовать для стилей аж ещё один язык.
Надо как в WPF: xaml+cs.
Хотя на самом деле любой язык разметки отличный от языка логики - лишнее.
Удобнее всего писать всё на одном языке - не запоминая лишний синтаксис
Для xml/css/js уже есть разработчики, материалы для обучения, опыт, методики, бест практис и т.д. Не зря же они и начали разрабатывать UIElements, а js к тому же просто удобный, можно и попробовать и без него обойтись.
Да, для xml (xaml) есть уже материалы и коммунити: WPF, Avalonia, Xamarin, UWP.
Js вообще не нужен, особенно в своей неродной среднее - не браузере. А особенно, когда уже всё на дотнете, а именно c# сделано. А вы хотите прикручивать сбоку лишний стремный язык и дублировать на нем код.
Если нужен js в десктопе (мисье знает толк) можете рассмотреть такие кривые поделки, как Facebook spark ar, snapchat lens studio.
Но не надо тащить ваш отсталый веб в десктоп. В этом абсолютно нет смысла: тут уже давно есть удобные, производительные, современные, кроссплатформенные языки и решения.
UIElements это очень круто, так как у тебя условно визуальный, настраиваемый редактор для визуального интерфейса, который можно прям на месте покрутить потыкать. После 5+ лет в вебе (благо я был фулстаком и фронт верстал не очень много) я надеюсь что мрака из стилей и верстки больше не коснусь никогда.
Это вообще что такое, когда вам нужно для того, чтобы сделать интерфейс, отдельный язык со стилями, отдельный язык с разметкой, отдельный язык для логики, все это друг в друга имплементируется, сверху для "простоты" накручивается фреймворк и пара библиотек.
А еще вы это верстаете вслепую, сначала поменяете стиль, допишете функцию которая разворачивает стор в набор элементов, а потом у вас верстка поплывет потому что 3 стиля применяют свойство в странном порядке.
Спасибо, сами в этом варитесь, пожалуйста оставьте визуальный редактор юнити интерфейса там где он был.
Удобнее всего писать всё на одном языке — не запоминая лишний синтаксисТочно-точно. И язык такой давно придуман – лисп называется. Там и гомоиконичность, и лишнего синтаксиса запоминать точно не придется, его всего ничего.
И лисп из того же века, что и js. Наверняка и удобность та же. В общем прах к праху
Я хотел лишь ненавязчиво подчеркнуть излишнюю категоричность утверждения формально подходящим, но очень специфическим примером.
Замечу, что не могу припомнить такого странного критерия как век создания, для оценки языка программирования, упомянутого не в качестве шутки. Равно как и применение его в качестве оценки удобства.
Поскольку критерием критики в исходном комментарии являлась необходимость учить новый синтаксис, дополнительная ирония состоит в том, что синтаксис лиспа можно описать семью строчками (и он подойдет и для данных, и для логики); что, впрочем ничего не говорит о простоте использования (особенно, человеком неподготовленным).
Статья про минусы, это хорошо, но однополярно, надо бы такую же, но про плюсы. Например то, что Unity позволяет построить архитектуру вообще исключив MonoBehaviour (оставив, его только для запуска всей логики Awake или Start). Бизнес-логика вообще не требует MonoBehaviour. Например, есть возможность строить все на ScriptableObject, который почему-то все игнорируют или юзают для создания Asset'ов данных.
В целом Unity это такой механизм, который позволяет творить многое, если что-то не устраивает. Для меня лично единственный минус движка - это его однопоточность. Т.е. можно было бы не юзать MonoBehavoiur вовсе, но ты не можешь получить доступ к UnityObject вне основного потока, точнее доступ получишь, но ничего сделать с этим объектом не можешь и это проблема конечно, из которой вытекают проблемы с UI, Input'ом и т.п.
Благо что бизнес-логику все таки можно спокойно распаралелливать и выносить вообще туда, куда тебе надо, а проблемы View оставить на Unity.
Спасибо за статью, согласен с тем, что однобоко написано..
Amethyst разработку своего движка прекратили 3 октября
https://amethyst.rs/posts/amethyst--starting-fresh
Перефразируя классика, "игровые движки делятся на два типа — те, которые все ругают, и те, которыми никто не пользуется" :)
Системы создаются не под «каждую пулю», а под каждый тип взамиодействия. Вне геймдева такую логику обычно называют менеджерами. Например, можно сделать систему для изменения координат всех пуль на основе их скорости и прочих свойств.
По поводу «объект под каждую пулю» — это сильно зависит от конкретного движка и желаемой игровой логики. Если, например. каждую пулю надо честно рисовать и поведение каждой пули зависит от физики, то отдельный объект будет удобнее. Если это не требуется, то возможны варианты.
Не под каждую систему, просто разные системы могут итерировать выбранные ими компоненты у пули (сущности), сущностей на сцене много, соответственно и системы итерируют нужные себе компоненты всех пуль на сцене. Технически, сущность в Entities это структура с двумя int32 полями, так что это честный обьект, если вы про это. Сборки мусора GC сущности как и компоненты не подлежат, они аллоцируются кастомным аллоктором Unity, если, опять же, вы про это.
Технически, сущность в Entities это структура с двумя int32 полями, так что это честный обьект, если вы про это. Сборки мусора GC сущности как и компоненты не подлежат, они аллоцируются кастомным аллоктором Unity, если, опять же, вы про это.
Да про это, просто в моём понимании алокации и уборки — вещи затратные, но, видимо, в своём алокаторе unity соптимизировали эти моменты)
Amethyst уже RIP. И все силы брошены на его преемника Bevy.
Я не из game dev, поэтому задам такой наивный вопрос: а что это за шутеры такие, что у вас одновременно 50К снарядов летят? Это типа на сцене 10 тысяч персонажей и все одновременно стреляют или как такое вообще возможно?
Это же пример ;D
Пример чего?
Пример работы ECS
Я вон, ниже, ссылку на видео давал. Игра на Unity + DOTS. Куда уж реалистичнее
Какой-нибудь Total War like геймплей думаю вполне может покрыть 50к снарядов. Ну и по мелочи всякие разрушения с физикой обломков тоже довольно многочисленными бывают.
Total War явно не шутер. И нет там никаких 50К снарядов, с точки зрения физики выстрел хоть тысячи арбалетчиков - это один выстрел, у него есть одна своя траектория и один условный эллипс поражения.
Supreme Commander. Там на столько всё физично, что выстрелы дальнобойной артиллерии могут сбить случайно пролетающий мимо самолёт. А юнитов там по 2000 на каждого игрока, а игроков - 8-16 и юнит может до десятка снарядов за залп выдать. Вот и считайте. В реале (виртуале?) до 50к вряд-ли доходит (игра просто захлебнётся), но пару тысяч снарядов на всей карте (а там можно вполне себе обозревать всю карту за раз) в генеральном сражении - вполне себе обычное дело.
Возможно
Я бы поспорил у утверждением, что Unity для простых игр. Смотря что считать "простым": Pillars of Eternity написаны на Untiy.
Так же не соглашусь, что Unity "не для программистом": в отличие от Unreal Engine в Unity нет нативного визуального программирования, в отличие от GameMaker есть полноценный .Net со всеми возможностями "попрогать": от многопоточки до реактивного программирования.
А еще не соглашусь, что ECS в Untiy это только DOTS. На мой взгляд, DOTS - мертвый продукт, он еще не вырос, но уже выглядит противно. Я дико рекомендую LeoEcs как пример хорошего ECS фреймворка: он приятный, более функциональный и лучше интегрируется с системами Unity. Конечно, бесплатной векторизации мы не получим, но получим "бесплатные" оптимизации кеш миссов (для чего и нужен Data Oriented Programming). А SIMD можно и нативно использовать в тех местах, где он нужен: для массового pathfinding, обработки повреждений в больших сражениях и проч.
Так же не соглашусь, что Unity «не для программистом»: в отличие от Unreal Engine в Unity нет нативного визуального программирования, в отличие от GameMaker есть полноценный .Net со всеми возможностями «попрогать»: от многопоточки до реактивного программирования.Ну… есть Bolt 😅
А вот Bolt 2, правда, пока заморозила…
Мне кажется Unity как гугл - любят забивать на проекты
Болт, трудно отлаживаемое гавно, молча глотающее эксепшены. Мы хотели его использовать для левелдизайна, за три недели замучались, перешли нафиг на FlowCanvas и бед не знаем. Всем советую вместо болта.
Например во FlowCanvas каждый экземпляр ноды — это экземпляр класса, распатитесь аллокацией за удобство написания и отладки. А в болте ребята попытались выползти на принципе что любая нода это статический метод, а все переменные составляют часть Flow. Из-за этого и Flow раздуло и отлаживать это — убиться проще, и output.Do(new Flow()) нельзя сделать. Если уж взялись соревноваться за 0 аллокаций надо же было соотвествующими инструментами обложиться со всех сторон. Короче слишком на многое позарились и не вывезли. Как только вам надо их стандартный набор нод расширить — всё туши свет.
Ну и повторюсь, идея скрывать эксепшены чтобы не пугать криворуких пользователей это просто шедевр мысли.
Т.е. по вашему сейчас многомиллионная индустрия успешно продаваемых Unity игр в Steam и android app store должна закрыться?
C++ это прошлый век. Даже пользователи UE4 стараются писать всё на блюпринтах, и не лезть в C++ грязь. Вот только писать на C# так же приятно как на блюпринтах, только быстрее. А код C# компилится в нативный С++ и затем со всеми оптимизациями компилится в исполняемый код.
В UE архитектура предполагает использование только под шутеры со своим бредом ввиде жесткой связки APlayerController -> APawn, нельзя просто разместить 3д объекты, направить на них камеру и получать визуализацию 3д мира, нужно городить кучу бессмысленных классов, что умножается на 2 в случае C++ из-за .h файлов.
Unity это не только игры но и визуализация и обучающие программы.
Сейчас есть много новых движков на C#.
Короче статья - писк умирающего С++ динозавра.
Т.е. по вашему сейчас многомиллионная индустрия успешно продаваемых Unity игр в Steam и android app store должна закрыться?
Нет, я просто написал статью о минусах Unity. Я вообще ничего не говорил о том, что C# хуже чем С++ или вообще хоть как-то их сравнивал. Ощущение, что вы читали статью по диагонали.
Короче статья - писк умирающего С++ динозавра.
Я на С++ писал полторы программы после того как прочитал по нему книгу, мне не понравилось нагромождение принципов и стандартов, я перестал на нем писать. Та и по возрасту я не могу быть С++ динозавром, он же меня старше почти в 2.5 раза.
Как должно быть прекрасно жить в мире розовых пони и радуг. А в реальности даже С++ не всегда может достаточно оптимизировать код( приходится идти и тюнить код, чтобы генератор нармально отработал ) , что уж говрить про поделие с трансляцией динамического языка с GC на C++
нужно городить кучу бессмысленных классов, что умножается на 2 в случае C++ из-за .h файлов.
Право дело. Что же это за движок, раз нельзя всё разместить в `public static void main`
C++ это прошлый век. Даже пользователи UE4 стараются писать всё на блюпринтах, и не лезть в C++
Прошлый, прошлый. Только вот беда, что одни и те же несложные алгоритмы на С++ даже без особых танцев с бубном и оптимизации на SSE/AVX и то выполняются порой в разы быстрее, чем на C#. SciMark вам в помощь для осознания сего факта.
А C# я тоже очень люблю в офисных и даже в инженерных поделках. Один только LINQ to Object экономит массу времени в написании рутинного перемалывания данных.
Но все же не место этой удобной мэнеджет погремушке в высокопроизводительном коде. И напрасно Unity на радость школоте его как скрипт прикрутили. UE на этом паровозе им не догнать.
все высоконагруженные алгоритмы связанные с рендерингом встроены в движок. В юнити есть даже DOTS. Тебе даже с BSP деревьями не надо иметь дел. Юзеру остаётся управлять только логикой. Если ты изобретаешь велосипеды на avx, скорее всего ты не используешь движок по назначению. Более того, если твоя игра жрёт проц, значит архитектура твоей игры убогая, и тебе надо отправляться на перестажировку, как это стало с Battlefield 2042, которая жрёт 80% проца i7-9700K при этом количество объектов в мире можно сосчитать на пальцах, и С++ его не спас, наоборот критические баги фиксятся неделями, потому что очевидно что игра компилится долго , и хотфиксы не залить. В итоге 80% юзер базы уже отвалилось. Это всё что надо знать про написание ААА игр на С++ в 2021.
Если бы С++ был отличен, то UE пользователи на нем бы и писали , но они предпочитают blueprints.
Если 20 лет назад тебе надо было писать сырой код OpenGL то сейчас надо управлять лишь логикой игры, и С++ для этих целей не подходит.
Вот еще пара относительно новых движков, которые так же используют C# - Xenko и FLAX.
все высоконагруженные алгоритмы связанные с рендерингом встроены в движок...Юзеру остаётся управлять только логикой.
И все эти алгоритмы написаны на С++. А ты вообще-то не юзер, а девелопер.
Шаг влево, шаг вправо - ой а мне вдруг нужно какой-нибудь свой алгоритм на матрицах просчитать. И что? Будешь ждать пока взрослые, умные дяденьки для тебя этот алгоритм запилят или довольствоваться пока в 2-е 3-е меньшей производительностью?
Да и вообще профессиональному девелоперу в этой индустрии не знать С++ уже странно. Другое дело, что Unity изначально и нацеливался не на профессионалов индустрии, а на дизайнеров одиночек и на мелкие т.н. инди-команды, где вместо программистов с дипломом зачастую один-два школьника на подхвате.
Я не игродел. Но в силу своей специфики прекрасно знаю насколько хреново оптимизируется конечный код c MSIL в сравнении с C++, не говоря даже про объективные тормоза сборщика мусора и т.п. А вот в конторе с которой периодически моя фирма сотрудничает есть два парня работающих с UE. Они там делают очень специфические вещи по интерактивной визуализации некоторых физических процессов. И там чистой счетной матетематики, а не просто логики хоть отбавляй. А значит если нужно считать это быстро, то без хорошей оптимизации на C++ не обойтись. И кстати один из них тоже рассказывал, что начинал в студенчестве с Unity, но позже переполз на UE.
Да и мне-то все равно, на чем вы там свои поделки делаете. Но говорить о том что С++ это прошлый век, когда у вас даже сам Unity-движок безальтернативно на этом С++ и написан - это какие-то детские глупости про розовые пони.
Ещё до появления dots я делал отдельный класс, который хранил в себе ссылки на компоненты разных объектов и в параллельном цикле бегал по ним. Все новые механики, связанные с большим числом компонентов, писались через вот такие вот системы. Лично мне казалось, что ввести подобную фичу в сам движок это как раз способ усидеть на двух стульях, так как у нас и производительность вырастает, и многопоточность легко реализуется, и простота сохраняется, так как по сути вместо FixedUpdate мы просто имплементируем другой метод, а всё остальное делается за нас.
Microsoft XNA. Не движок, но фреймворк для создания игр на C#, больше не поддерживается. Но на нем создают довольно много разных инди игр и по сей день, одна из самых популярных это Stardew Valley.
Всё благодаря проекту FNA, который его возродил из пепла. Теперь даже Terraria, некогда созданная с помощью XNA, теперь сидит на FNA, и даже имеет нативную сборку под Linux (установил игру из Steam и увидел в файлах факт использования FNA).
Думаю, можно и про O3DE написать, хотя оно сравнительно молодое - первая стабильная версия вышла несколько дней назад. Вкратце - это 100% open-source продолжение Lumberyard от Amazon (видимо, очищенное от несвободного кода), переданное под контроль Linux Foundation. Пробовал, выглядит более-менее неплохо, хотя документации пока очень не хватает.
И на какие только извращения не идут любители офисных мэнэджет-песочниц, чтобы не учить C++ :D
Так, почему у меня ощущение, что автор использует MonoBehaivor как-то не так? Ощущение, что он его использует как скрипт объекта, а не независимый компонент
У Unity всё плохо