На просторах интернета, и в частности хабра, очень трудно встретить статьи с критикой игрового движка Unity. Я решил это исправить, и приготовил вам текст о переходе на DOTS, насилию над C#, знаменитых UI пакетах, MonoBehaviour, универсальности и о многом другом.
Статья не требует от вас знаний о создании игр на Unity, я ее писал с учетом того, что ее будет читать обычный программист, который сравнивает плюсы и минусы разных движков, чтоб выбрать подходящий для своего проекта. В конце концов, может вам будет просто интересно узнать, что же это за движок такой, для которого курсы рекламируются на каждом шагу.
DOTS
В данный момент Unity активно переходит на новый стек технологий под названием DOTS. Транзит сопровождается лозунгом "Производительность по умолчанию" и идеей того, что С# может быть таким же быстрым как C++ у UnrealEngine и других движков. Главные фронтмены данного действа это Entities, Jobs и Burst.
Теория
Если вы уже знаете, что из себя представляет пакет DOTS, тогда можете смело переходить к пункту Имплементация.
Entities представляет из себя реализацию популярного в игровой индустрии паттерна ECS. ECS это паттерн, где код делится на сущности к которым добавляются компоненты с данными, состоянием компонентов у сущностей управляют системы, которые эффективно перебирают сущности с нужными им компонентами и изменяют данные компонентов по надобности.
К примеру, у вас игра - шутер, в которой снаряд это сущность с компонентом Bullet в котором хранятся данные о расположении снаряда. Есть система движения снарядов, которая перебирает все сущности с компонентом Bullet и двигает их вперед, а есть система рендера снарядов, которая перебирает все сущности со снарядом Bullet и рендерит их.
Реализаций ECS есть великое множество, но в основном, используют следующие способы оптимизации перебора сущностей:
Хранение компонентов эффективно в памяти в соответствии с архетипом существа к которому они привязаны. Архетип это уникальное сочетание компонентов у существа. В случае Unity, компоненты хранятся в чанках по 16кб в соответствии с архетипом. Выходит, что чанки с компонентами хранятся друг за другом в памяти.
Распараллеливание обработки существ системой. Тут всё очевидно, двигать 50 тысяч снарядов в каком-то шутере быстрее в 32х потоках одновременно. От программиста не требуется особых телодвижений для управления многопоточностью, потенциально ECS может эффективно управлять потоками самостоятельно. В Unity роль управления потоками делегирована фреймворку Jobs.
Такой паттерн хорошо подходит сложным играм, в которых есть очень много сущностей которые надо очень часто перебирать (к примеру ММО). Вдобавок, ECS управляет зависимостями, позволяя игре становиться все больше и больше без последствий.Но есть и обратная сторона медали, ECS плохо подходит играм, в которых мало сущностей и их не надо часто перебирать (например 99% мобильного рынка).
Jobs это реализация безопасной мультипоточности путем создания экземпляра "работы". Работу можно запланировать, получить ее обработчик и выполнить ее. Также работу можно запланировать после другой работы, или вместе с другими работами. Таким образом создаются целые цепи последовательных задач. Сами задачи выполняются сразу в нескольких потоках. Например, вам надо умножить все числа массива А с вместительностью в 100 элементов и положить их в массив B. Это можно сделать в десяти потоках, в каждом из них задача будет обрабатывать по 10 элементов.
Burst это компилятор, который транслирует IL байткод в оптимизированный нативный код с помощью LLVM. В основном, используется для компиляции работ с Jobs.
Имплементация
Теперь, когда вы понимаете что из себя представляет новый стек технологий теоретически, можно поговорить об имплементации. А она, как всегда, не выдержала столкновения с реальностью.
Начнем с того, как же команда Unity хочет сделать C# таким же быстрым, как C++, а именно:
Создали новый компилятор для Работ с векторизацией и intrinsics (разве что без блекджека)
Создали нессылочные альтернативы массиву, списку, очереди и т.д которые дружат с Burst'ом. Особенность в том, что эти контейнеры надо аллоцировать и после их жизненного цикла освобождать, иначе утечка. Причем, аллоцировать надо не абы как, а с правильными лейблами (Persistent/Temp/TempJob).
Ввели в использование указатели на списки и указатели на функции. Также вам может понадобиться использовать Malloc, MemMove, MemCpy и подобные
brand-newфункции.
Я думаю, вы уже поняли к чему я клоню. Они решили, что лучший способ сделать сишарп таким же быстрым как и плюсы, это сделать из сишарпа плюсы! *занавес, бурные овации, публика в шоке*
Ладно указатели, ладно Dispose у контейнеров, но когда вы начали писать новый компилятор для языка, можно же было что-то заподозрить! Пытаться уже третий год реализовать стек технологий на языке, который не подходит вашему стеку, и при этом переделывать* язык, это же сумасшествие!
Ещё один пример несовместимости DOTS и C# это Jobs с Работой IJobChunk и производными. Для того, что бы проитерировать 3 компонента c помощью IJobChunk, вам надо 43 строки кода. Ситуацию могли бы спасти макросы, но они в C# предательски отсутствуют!
Следующая проблема нового стека Unity это недостаток многих функций, которые, иногда, могут вам пригодиться в создании игры, например:
Звук. Версия пакета для звука 0.1.0-preview17 и за 3 года он так и не обновлялся.
Интерфейс. Тут всё проще, пакета для интерфейса с поддержкой Entities просто нет.
2д. Существует com.unity.2d.entities, но он создан для Project Tiny и работает в общем-то только с ним, о Project Tiny тоже позже.
Анимации. Пакет тоже существует, версия 0.9.0-preview.6, в теории использование возможно, на практике не очень.
Всё элементы движка, которые не требуют очевидного отдельного пакета. Свет, камера, партиклы и т.д, всеми ими нельзя управлять через Entities, что угодно делайте. Можете создавать псевдо-сущность с компонентом, к примеру, камеры, и отдельной системой в главном потоке синхронизировать поля между MonoBehaviour камерой и вашей псевдо-камерой, можете другие костыли городить. За 3 года решения от Unity так и нет.
*под переделыванием языка я подразумеваю минимизирование использования ссылочных объектов и, как следствие, кучи путем создания кастомных аллокаторов, компиляторов которые не поддерживают кучу и т.п.
Проблемы
Предположим, что отсутствующие пакеты можно дописать, а текущую имплементацию можно ещё починить (в конце концов, можно переписать Roslyn!). Но проблемы самой DOTS как концепции, быстро решить не выйдет.
DOTS по умолчанию сложен. ECS требует полного понимания, как он работает, программисту надо знать на что влияет Read/Write доступ к компонентам, что такое Sync point и как сократить их количество, зачем нужен ECB, WriteGroup, гибридные компоненты и многое, многое другое. Также есть Jobs со своими контейнерами на указателях и такой же морокой с Read/Write доступом, Burst с миллиардом приспособлений для оптимизиации и примерами в документации из ассемблера.
Такая сложность явно не идёт на руку движку, одна из основных преимуществ которого простота. Unity занял свое место на рынке как "движок для дизайнеров, а не программистов", на нём делают Cuphead, Ori, Hollow Knight и другие игры которые не Factorio по сложности исполнения и требуемой оптимизации. У Unity занят рынок мобильных игр, маленьких кросс-платформенных инди игр, игр уровня "мы с парнями другие движки не знали, пришлось на этом пилить" (таким образом получаются Rust и Tarkov), в общем, идиллия. ААА игры не будут делать на Unity даже с полностью реализованным DOTS, ведь для них уже пишут отдельные движки на основе опенсоурса (UE) или вообще с нуля, а сложные инди игры делают энтузиасты на своих микро-движках, фреймворках или на том же UE.
В общем, плюсы от перехода на DOTS неочевидны, а минусы из-за нехватки ресурсов компании на поддержку и развития старых решений из уже уходящей эры MonoBehaviour присутствуют.
Project Tiny
В дополнение к выше написанному, хочу упомянуть Project Tiny. Это этакий набор мини-фреймворков для DOTS, которые должны помочь в разработке "Instant games" или, если выражаться русским языком, сделанные за 2 недели Егором из 9Б гипер казуальные игры типа тривряд. Также для Project Tiny команда Unity написала новую среду выполнения DOTS Runtime, вот вам документация (кстати в гугл доках, такого я не видел). Опять пересказывать то, что они пытаются переделать C#, смысла я не вижу, просто обозначу, что факт существования данного набора пакетов подтверждает то, что они хотят именно переделать движок с новым стеком DOTS, что в свою очередь, делает проблемы, описанные выше, ещё более значимыми.
Unity, но без DOTS
Под данным заголовком я хочу описать проблемы как старого архитектурного решения Unity, так и самого Unity как движка.
MonoBehaviour
Начнем с основного старого архитектурного решения - MonoBehaviour. Mono потому что на C#, раньше ещё был, к примеру, JSBehaviour, но все языки кроме C# в Unity бесславно умерли, так и остался один единственный MonoBehaviour.
Если кратко излагаться, MonoBehaviour представляет из себя базовый класс для скриптов в Unity, унаследованные от него классы можно добавить на любой объект в сцене как компоненты, а публичные поля таких классов красивенько отображаются в редакторе. Код пишется в методах со спец. именем, которые ядро движка на С++ вызывает самостоятельно, такие методы называются Messages, их у MonoBehaviour целая куча, от обычных Start и Update до OnCollisionEnter и OnApplicationQuit.
Такое решение довольно простое в понимании и не требует вообще никаких навыков у программиста, у вас все под рукой. Для больших проектов это, естественно, никуда не годится. Тут нет какой-то внятной архитектуры, у вас логика приложения находится сразу же в структуре с данными (компоненте). MonoBehaviour почти не предоставляет никаких абстракций, не дает инструмента для управления зависимостями, методы для поиска объектов с MonoBehvaiour на сцене де факто антипаттерн из-за производительности, методы для вызова Message-методов у других MonoBehaviour ещё больше антипаттерн из-за ещё худшей производительности.
В принципе создание чего-то сложнее тривряд с активным использованием MonoBehaviour не рекомендуется, а поскольку модульность в старом Unity отсутствует как понятие, просто убрать пакет с MonoBehaviour и написать что-то свое вы, конечно, не можете. Так и живут разработчики под Unity с гайдлайнами по оптимизации, в которых рекомендуют не использовать половину функций движка.
Команда Unity давным давно забила на попытки хоть как-то развить эту систему и пофиксить проблемы с производительностью.
Editor и UI
Разработчики Unity не умеют в UI. За 16 лет они не смогли создать пакет для адекватного интерфейса с xml/css/js и имплементировать редактор своего движка на нем. Для игр они сделали какой-то хлам с Canvas-ом и перетаскиванием панелей по иерархии сцены, а для редактора они предоставили что-то невообразимо ужасное с IMGUI на C# и рефлексией.
Спустя 16 лет они поняли, что шутки про использование штатного пакета для интерфейса Unity на форумах больше не смешные, и решили сделать новый пакет для интерфейса - UIElements (UIToolkit), с xml и css, но без js. Новый пакет для интерфейса непригоден для работы из-за отсутствия функционала у стилей. В нем нет анимаций, нет масок, нет полей для настроек выставления фона (только background-color и background-image), нет настроек шрифта и теней. Можете сравнить набор свойств у обычного CSS, и USS Unity.
Можно было бы сказать, что реализовать полный набор функций CSS движка довольно сложно, но вот Valve создали свой фреймворк Panorama с JS'ом, анимациями, масками, фоном, партиклами, сценами и многим другим. Благодаря ему, у игр Valve одни из самых лучших интерфейсов в индустрии. Понятно, что сравнивать Valve с Unity не совсем корректно, но это пример успешной реализации xml/css/js интерфейса в движке.
Декларируемая универсальность
Уже не совсем техническая, но огромная проблема Unity прошлого, настоящего и будущего. Unity старается быть универсальным, но игровой движок по природе своей не может быть универсальным. Нельзя сделать движок, который одинаково подходил бы сандбокс игре с процедурной генерацией мира, кооперативному FPS шутеру и мобильному кликеру. У разных игр разные требования к архитектуре движка, и если ваш движок это не каркас для плагинов как vim, то сделать его одинаково подходящим для всех не выйдет.
В случае с Unity это выливается в то, что ни одно отдельно взятое общее решение движка просто не подходит вашей конкретной проблеме. Как итог, вы постепенно отказываетесь от предоставленных движком решений и пишете свои, от чего попросту теряете время.
Этой проблеме, по сравнению с остальными, выделено не так много места в статье, но она фундаментальна. Именно эта проблема, скорее всего, потратит тонну вашего времени и похоронит проект, или уже похоронила. Если разработчики Unity сразу бы решили, для каких игр они делают свой движок, этой статьи бы не было.
Другое
Руководствуясь больше долгом о написании всех недочетов Unity, чем здравым смыслом, хочу отметить ещё немного мелких проблем которые не заслуживают отдельного параграфа, но заслуживают упоминание:
Стилистика кода у биндингов Unity с префиксами
m_, чрезмерным использованием internal и бесполезными комментариями наподобие "x - Left coordinate, y - Top coordinate". Пример.Существование авто-сериалайзера Unity который работает хуже чем любой другой из существующих в мире, я думаю что сериалайзер на конвейерах в Factorio работал бы лучше, и как минимум, поддерживал бы сериализацию словаря.
Перезагрузка всех ресурсов с надписью "Hold on" после каждой правки кода. Команда Unity клянется что ничего не могут с этим сделать, но это нетерпимо.
В Unity до сих пор нет поддержки C# 9, я просто напомню, что последняя версия уже C# 10.Поддержку #9 давно добавили.Асинхронные юнит тесты обещали, но конечно, не сделали. Приходиться создавать костыли.
Конец
Статья вышла немного больше, чем я думал и наверняка я где-то допустил ошибку, так что прошу в комментарии. А если вы тот самый человек из начала статьи, который ищет движок для своего проекта, можете ознакомиться со следующим списком:
Для небольших игр с простой 3д или 2д графикой
Unity. Не смотря на все минусы перечисленные выше, скорее всего для простых игр он вам подойдет.
Godot. Сам не пробовал, по ощущениям Unity v2, но опенсоурс и не будет требовать от вас деньги и ставить свой логотип в начале.
GameMaker: Studio. Создан для 2д игр, на нем сделали Undertale. Без подписки минимум за 10$ делать ничего не хочет.
Microsoft XNA. Не движок, но фреймворк для создания игр на C#, больше не поддерживается (но есть форки). На нем создают довольно много разных инди игр и по сей день, одна из самых популярных это Stardew Valley.
Для средних или больших игр с 3д графикой
UnrealEngine. Больше мне советовать нечего, скорее всего он вам подойдет. Писать код на C++ это сжигание тонны времени, но блюпринты могут вас спасти.
Другое
Amethyst. Движок на Rust, пока без своего редактора, естественно опенсоурс.Разработка движка прекращена.Bevy. Конкурент предыдущего движка, можете попробовать оба.
Комментарии (161)
Caritas
05.12.2021 14:06+10А как из того что DOTS сырой следует вывод о том что Unity не подойдет для простых игр?
"Классическая" архитектура с монобехами никуда не девается, а для большого числа игр этого с головой достаточно. Это же и есть альтернативный архитектурный подход, отсутсвие которого ставится в претензию в конце статьи.
Проблема большого числа проектов на юнити вообще не на стороне движка, а чисто на стороне проектирования того кода, который с движком работает
HelpOrMe Автор
05.12.2021 14:46+8А как из того что DOTS сырой следует вывод о том что Unity не подойдет для простых игр?
Никак не следует. В статье же написано, что Unity больше подходит простым играм.
"Классическая" архитектура с монобехами никуда не девается, а для большого числа игр этого с головой достаточно.
Все ведёт к тому, что о монобехах просто забудут, как о старом решении, а на их место придёт Project Tiny. Как минимум, все пакеты сейчас нацелены именно на DOTS
Это же и есть альтернативный архитектурный подход, отсутсвие которого ставится в претензию в конце статьи.
Не ставиться, я просто декларировал архитектурные проблемы монобеха для больших игр, ибо он для них не сделан. Я не предъявлял претензии о отсутствии другой архитектуры для больших игр, это же полностью бы противоречило статье. Возможно, я вас не правильно понял.
Проблема большого числа проектов на юнити вообще не на стороне движка, а чисто на стороне проектирования того кода, который с движком работает.
Полностью согласен.
Я сейчас занят, буду отвечать вечером.
Suvitruf
05.12.2021 14:47+1Все ведёт к тому, что о монобехах просто забудут, как о старом решении, а на их место придёт Project Tiny. Как минимум, все пакеты сейчас нацелены именно на DOTS
Project Tiny создавался совсем не для этого.HelpOrMe Автор
05.12.2021 16:51А для чего же? Раз не для казуальных игр, как написанно в документации которую я приводил в статье. Мне действительно интересно узнать.
Suvitruf
05.12.2021 17:41Ну да, для казуалок. Но ведь ваш тезис изначально был другой.
Все ведёт к тому, что о монобехах просто забудут, как о старом решении
Казуалки лишь часть игр на Unity. Монобехи никуда не уйдут, т. к. Project Tiny не подойдёт для многих типов игр.
Jes28
05.12.2021 20:57+3для рекламы и GooglePlay Instant
для игр которые будут весить до 10 MB
А MonoBeh если и уйдут в историю году эдак в 2030 то к тому времени DOTS станет таким же удобным как сейчас MonoBeh
Я понимаю что эта статься это крик души и именно по этому многие тезисы недостаточно аргументированы. Просто субъективное часто неверное мнение автора :)
Kardy
05.12.2021 14:11+17То что юнити раз за разом пытаются ввести какую-то фичу тысячелетия, не справляются и дальше делают вид что ничего не было, это известный, и немножко печальный факт.
В остальном или вкусизм, или недостатки которые перекрываются недостатками в других движках (идеального же нет). Да, юнити подвисает после каждого изменения в коде. А анриал выдает ворох предупреждений после каждой передвинутой лампочки. Да, юнити не может в интерфейс, но в анриал, как по мне, достаточно мрачная работа с объектами, и т.д.
Так что в принципе, для любой игры кроме "АА симулятора ходьбы со светом из коробки" юниту подойдет как минимум не хуже.
Suvitruf
05.12.2021 14:11+3У меня на эту тему здоровый тред в Твиттере был. Проблем много, но у каждого движка они есть.
Хотя вот с 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 вам так не хватает?Antonidiuss
05.12.2021 16:15Самое забавное - в юнити 2021 есть поддержка С#9.
HelpOrMe Автор
05.12.2021 16:16Поддержка C# 9 In progress уже как минимум пол года и не релизнута. Не верите мне, повертье роадмапу самого Unity.
AntonovDV
05.12.2021 19:03+2Unity 2021.2 уже с октября в релизе, там есть поддержка
HelpOrMe Автор
05.12.2021 19:04-5Ага, да, в мануале написали. Хотя и фитчи с оверрайдом вовращаемых типов нет. Поправлю в статье.
usa_habro_user
05.12.2021 20:56+6фитчи
Любопытно, откуда буква "т" берется (не первый раз уже наблюдаю)?
tommyangelo27
05.12.2021 22:48+2Наверное feaTure так читают...
HelpOrMe Автор
05.12.2021 22:50-10Вам серьезно не все равно на транслитерацию английского слова?
usa_habro_user
06.12.2021 00:59+1Да нет, в принципе, пофик, но всю жизнь "фичи" были "фичами", там "т" и в оригинале не произносится.
0x0737
07.12.2021 16:38Но ведь там большие проблемы с зависимостью от нового рантайма, они для этого сейчас и начали свой форк CoreCLR и будут переходить на csproj со своих asmdef. На демонтаж старой инфраструктуры может уйти много времени
HelpOrMe Автор
05.12.2021 16:20+3UE сейчас: «Ну да, ну да, пошёл я нахер». Каждая компания пытается расширить ЦА своего продукта.
UE не пытается быть универсальным, но ЦА расширяет, к примеру с Мандалорцем вышло здорово, видны перспективы.
Suvitruf
05.12.2021 16:30Как Юнити (который изначально был под мобилки) старается в ПК, так и UE старается в мобилки.
BioHazzardt
06.12.2021 15:20+2который изначально был под мобилки
ЩИТО? когда я ковырял юнити (около 10 лет назад) там никаких мобилок не было, даже под браузер специальный плагин нужен был для запускаSuvitruf
06.12.2021 16:09+2Мой косяк. Я с Unity начал работать лишь с 4 версии. А тогда компания движок позиционировала именно для разработки под мобилы.
HelpOrMe Автор
05.12.2021 16:49+1На телефоне не увидел весь комментарий. Допишу ответ.
Вам ничто не мешает логику отделить от монобехов. К примеру, тот же 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.
FloorZ
06.12.2021 08:41+8Началось. И почему это искать обьекты на сцене не надо? У Valve в Source есть и поиск сущеностей на сцене, и поиск сущеностей в радиусе, и поиск сущеностей в aabb и т.д, и работает он быстро. Почему базовый функционал движка не работает как следует и я не могу его использовать, а должен писать новое решение. Конкретно DI контейнер мне тут не поможет.
Мы из коробки имеем немплохой контролль.
Что мешает написать в пару строк "SearchableObjectManager" и спокойно в него забивать только те обьекты, которые можно искать. По ХП, по радиусу и т.п. Просто искать конкретную сущность по всей сцене - это не правильно в любом движке априори.Должно быть события или причина, что бы один обьект взаимодействовал с другим. Например что бы НПЦ взял в инвентарь интерактивный обьект, который видит. Ему не надо этот обьект искать по сей сцене. Этот обьект должен попасть в поле зрение НПЦ, т.е. тут отработает физика, когда меш обьекта попадает в поле радиуса. С этого момента НПЦ известно об существовании этого обьекта и он запишет его RID/ID/Ссылку на него куда то в память. И когда наступит триггер - он обратится к памяти и попытается взаимодействовать с этим обьектом.
а если у тебя появляется необходимость на сцене ИСКАТЬ другие обьекты, для взаимодействия - то что-то изначально в построении игры не правильно, даже в рамках ECS. Один компонент одной сущности взаимодействует с другим компонентом другой сущности. Но никогда не должны взаимодействовать с сущностью напрямую.
В каком мире буквальное перетаскивание руками компонентов с обьектами по иерархии сцены и написание лейаута со стилями тоже самое?
Qt например?
Я считаю, что игровые интерфейсы построенные на xml, js и т.п. - не лучшее решение. Интерфейсы - это не всегда плоская веб-картинка на плоском мониторе. Интерфейс может быть обьемным, трехмерным, иметь более сложную логику, а не быть строго квадратной абстракцией загноновй в xml/js параметры.на сегодня мне нравится решение godot. Интерфейсы имеют стили, они легко анимируются. Но при этом ui - это все обьекты, а не веб-магия. И мне не надо обучать дизайнера, который рисует кнопочки, рисует мне персонажей, травку, муравку и т.д. - эти кнопочки кодить в xml. Он легко может драг-н-дроп глянуть, как на игровой сцене его супер-кнопка смотрится прям сейчас.
creker
05.12.2021 14:24+8Преимущества DOTS то вполне понятны. Это реализация data oriented подхода, который критичен для производительности любого кода на современных процессорах. Очевидно, что сделать это простым сложно. Особенно для дизайнеров. Даже для программистов подход не очень-то стандартный.
Зачем они это сделали кажется рассказали на SIGGRAPH 2021 REAC: Unity Rendering Architecture. Они как раз таки хотят освободиться от стереотипа, что юнити это двиг для инди и мобильного треша. Их идея сделать архитектуру, которая скейлится от мобилок, до хайэнд пека и рендер ферм. И подход DOTS здесь понятен. Чтобы скейлиться нужно уметь параллелить код. Желательно автоматически, подстраиваясь под конкретную железку. M:N модель многопоточности, реализацией которой Job системы и являются, это позволяют и я уже неоднократно видел доклады про них в современных играх. Собственно, не только игры любят этот подход.
И дальше будет только хуже, потому что ноги здесь растут из проблем в масштабировании железа. В индустрии огромная проблема с дизбалансом вычислительной мощности и скорости памяти, которая ощущается от мобилок вплоть до HPC и облаков. Кэши кое как эту проблему скрывают, а data oriented подход призван эти кэши наиболее эффективно использовать. Так что Unity тут не более чем подстраивается под современные реалии.
Suvitruf
05.12.2021 14:26+2Проблема DOTS'а в том, что они про него уже который год рассказывают. Они его нахваливали ещё когда я на Юнайте в Копенгагене был (года 2-3?! назад).
А сейчас вон вышел UE5, на фоне него все эти DOTS'ы и ECS'ы Юнитишные вообще игрушкой кажутся, учитывая, что они всё ещё не доделаны.creker
05.12.2021 14:30+2Я здесь чисто мимо проходило, любопытно чего в геймдеве творится, но в чем проблема конкретная? Сам подход для меня очевиден. По-другому они на рынке не выживут. Эта проблема не 2 и не 3 года уже существует и становитсят только хуже. Да, сложно и отлаживать его можно долго, но чего поделаешь. Процессоры, которым не нужны кэши, наше поколение вряд ли застанет.
Suvitruf
05.12.2021 14:35В DOTS как идеи нет никаких проблем, крутой шаг. Проблема не в идеи, а в том, что Unity последние годы уходит в сторону расширения ЦА, но не в плане разных игр, а в плане юзеров. Визуальные тулзы, для кинематографа что-то делают и т. п. В итоге основное направление проседает.
Часто покупают какое-то решение и убивают. Вон купили Bolt, хотели аналог Блюпринтов из UE сделать, но забили на этого в итоге и заморозили Bolt 2.
Сейчас вон UE5 вышел, Godot 4.0 готовится к выходу. Если Unity так и дальше продолжит тупить, то грустно…creker
05.12.2021 14:43Ну тут их тоже можно понять. Они видимо гонятся за анрилом, который подмял под себя уже и кинематограф. Другое дело, что анрил вроде бы не ставит перед собой задачу быть удобным для всех, от инди до кино. И смотря на то, что они творят в 5 версии в плане рендера, смотреть на юнити конечно печально.
Godot 4.0
Им кто-то реально пользуется?
HelpOrMe Автор
05.12.2021 16:52+3А что с годотом не так?
adictive_max
06.12.2021 15:06+2То, что единственное его реально преимущество - это опенсорсность и бесплатность. Ну и UI-билиотека неплохая.
В остальном же, читая что в "а в Unity вот така фича тормозная/неудобная/глючная", почти всегда оказывается, что в Godot подобной фичи вообще нет. То есть там надо под себе с нуля писать почти всё.
И вот тут на сцену выходит AssetsStore, в котором "почти всё" есть. А у Godot в asset library нет. Понятно, что большая часть это шлак, но в Godot asset library 1096 пакетов, а в Unity AssetsStore 2963 страницы.
Вообще, по моим впечатлениям, это примерно как Gimp после Фотошопа. Формально вроде бы большая часть фич присутствуют, но как только выходишь за рамки туториалов, и начинаешь делать реальные задачи, то почему-то оказывается, что на работу уходит в 2-3 раза больше времени.
В целом, это нормальный движок для супер-мелких проектов, которые можно в одно лицо запрограмить в пределах 1-2 месяцев. Если больше, вы уже закопаетесь в написании собственной "стандартной библиотеки".
FloorZ
06.12.2021 09:00+1три года назад, известно было об одном только проекте в бете, в стиме мне, на godot 2.x еще.
Cейчас уже к версии godot 3.4, игры начали плодится как грибы. За последние два года, игр стало существенно больше на мобилке. 2022 год, должен заполнится релизами игр, которые начали делать в 2018-2019ых годах.
holydel
05.12.2021 14:41+1Тут всё очевидно, двигать 50 тысяч снарядов в каком-то шутере быстрее в 32х потоках одновременно.Ну вообще-то не очевидно. Вдруг мы в память уперлись.
staticmain
05.12.2021 16:07Странно что не упоминаются cache misses, которые неизбежны если есть не централизованное хранилище, а список объектов, по которые бегает итератор процессируя движение или изменение свойств. С учетом того, что информация об объекте весит не одну страницу то при таком подходе все будет упираться в скорость RAM и размер L1/2/3 процессора
HelpOrMe Автор
05.12.2021 16:14Изначально в статье об этом было написано, но нигде не нашел источник с которого можно было бы подтвердить информацию. Раньше в документации Entities писалось, что данные хранятся эффективно в памяти процессора, и из-за этого меньше миссов. Но это куда-то пропало после какой-то минорного обновления Entities, или я не смог найти.
creker
05.12.2021 16:27В этом и есть идея data oriented архитектуры, реализацией которой DOTS является - хранить объекты целиком как классы или структуры чрезвычайно не эффективно, если их много и их надо постоянно обновлять.
Tiendil
05.12.2021 15:14Amethyst. Движок на Rust, пока без своего редактора, естественно опенсоурс.
Наткнулся недавно на эту штуку. Выглядит интересно, но смущает, что они уже давно переходят (?) на новую ECS библиотеку и статус перехода со стороны не понятен. Тем более, что по докам старая выглядит удобнее.
Suvitruf
05.12.2021 15:17Ожидал этого комментария от ozkriff ????
ozkriff
05.12.2021 15:25+7Я честно стараюсь поменьше без приглашений врываться и евангелировать за раст)
Но, если уж на то пошло, Amethyst как движок давно уже не сильно живой был, а недавно совсем помер. Я бы из претендующих на масштабность чисто растовых движков советовал смотреть на Bevy или rg3d - только сразу предупреждаю, что это все еще штуки в первую очередь для энтузиастов, слишком все сырое.
asso
06.12.2021 12:34+1С одной стороны огорчает поддержка VR в движках на расте. А с другой стороны это возможность поделать свой движок и изучить что-то новое :)
domix32
06.12.2021 13:37Можно предложить врываться в wasm + WebVR.
asso
06.12.2021 20:34Хочется нативное решение для Квеста сделать, поэтому wasm не подходит. Сейчас использую связку из OpenXR и ash. Для тестирования собираю "плосскую" версию с winit. Поглядываю на Vulkano как на безопасную альтернативу ash. На прошлой неделе в wgpu добавили поддержку Multiview, что то очень радует, но с наскока "ворваться" не вышло: не понял как подружить wgpu с OpenXR.
HelpOrMe Автор
06.12.2021 13:55Тоже хотел написать движок на расте для VR в открытом мире, читал учебник по вулкану перед тем как статью начал писать ;)
asso
06.12.2021 20:36У меня примерно такая же задача: мир планетарного масштаба, но не очень детализированный. Предназначенный в основном для просмотра с высот от 500 до 10000 метров. Для этого готовых решений практически нет.
Perforethor
05.12.2021 15:19-10Godot. Сам не пробовал, по ощущениям Unity v2, но опенсоурс и не будет требовать от вас деньги и ставить свой логотип в начале.
Дальше можно не читать, и забыть что перед этим прочитал в этой статье.
Atreides07
05.12.2021 16:01+7Microsoft XNA. Не движок, но фреймворк для создания игр на C#, больше не поддерживается. Но на нем создают довольно много разных инди игр и по сей день, одна из самых популярных это Stardew Valley.
На самом деле фреймворк XNA получил свое развитие в виде https://www.monogame.net/ - последний релиз был год назад, а последний PR был смержен 27 октября, т.е. пока еще живой.
VEG
05.12.2021 17:17+4Есть ещё одна новая реализация XNA под названием FNA: fna-xna.github.io. Активно развивается и дорабатывается. Некоторые известные инди-игры перешли на него с MonoGame. Например, Fez.
Miwwa
05.12.2021 17:23+2А также есть второй форк XNA - FNA https://github.com/FNA-XNA/FNA с последним релизом 4 дня назад. Так что дело XNA живет по сей день
SH42913
05.12.2021 16:39+6Такой паттерн хорошо подходит сложным играм, в которых есть очень много сущностей которые надо очень часто перебирать. ... ECS плохо подходит играм, в которых мало сущностей и их не надо часто перебирать (например 99% мобильного рынка).
Позволю себе не согласиться с таким утверждением. ECS в первую очередь подход к проектированию кода, а не паттерн для быстрого итерирования по тысячам сущностей. Главные достоинства ECS - слабая связность логики(а следовательно хорошая модульность, тестируемость) и комбинаторика свойств(проще сочетать в сущностях различные элементы логики). Благодаря этим достоинства ECS хорошо подходит как простым играм(99% мобильного рынка), так и сложным, особенно где много вариаций сущностей. И очень хорош для какого-нибудь гиперкэжа, где можно реюзать большую часть кода между проектами(при грамотном проектировании, ессесно).
PS Есличто речь именно про ECS, а не DOTS
HelpOrMe Автор
05.12.2021 17:03+1Смею тоже не согласится. Для маленьких игр, к примеру новелл, ECS абсолютный оверкилл как не посмотри. А так вы правы во всем правы!
SH42913
05.12.2021 18:09+1Для маленьких игр, к примеру новелл, ECS абсолютный оверкилл как не посмотри
С этим утверждением склонен согласиться :)
Под маленькими играми просто представлял какой-нибудь гиперкэж, где от ECS всё таки есть польза
hit3nkuro
05.12.2021 16:52GameMaker: Studio. Создан для 2д игр, на нем сделали Undertale. Без подписки минимум за 10$ делать ничего не хочет.
Как это ничего не хочет? Там же платная подписка только для экспорта?
rg_software
05.12.2021 18:39+2Вот если совсем кратко, то мне кажется, что нынешних компьютеров с головой хватает для нужд инди-разработчиков. Иными словами, MonoBehavior, C#, сборка мусора и прочие тормоза -- ну и ладно, сгодится. Бывает, появляется что-то жрущее процессор типа хитрых шейдеров или какой-то умной физики, чтобы волосы там или юбочка развевались красиво, но на этом всё. Поэтому разговоры про миллионы юнитов и летящих пуль и прочую голливудскую красоту -- это всё не для простых смертных. Могу ошибаться, конечно, но так мне видится.
Соответственно, затронутые автором проблемы -- это про AAA проекты фирм типа EA или UbiSoft, где как раз миллионы юнитов, графика как в блокбастере, вылизанный мир и т.д. и т.п. Ну так и пусть со всей этой радостью, гм, имеют дело, за такие-то деньги. Выдавим скупую слезу по их тяжёлой участи.
nidalee
06.12.2021 09:12+2AAA проекты фирм типа EA или UbiSoft, где как раз миллионы юнитов, графика как в блокбастере, вылизанный мир и т.д. и т.п.
У них в основном свои движки.
asso
06.12.2021 13:42+3Целевой платформой может быть не только ПК. В шлемах VR проблема с производительностью проявляется в полный рост и без миллионов юнитов и пуль. Лично мне поэтому не хочется использовать Unity, а хочется сделать движок, оптимизированный под мою конкретную задачу. Хотя на самом деле это только одна из причин. Другая в том, что хочется изобрести свой велосипед и получить в процессе опыт и удовольствие :)
KislyFan
05.12.2021 18:53+7При всем уважении к автору, статья достаточно спорная. Не совсем понятно, как долго он работает с 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
noldowalker
06.12.2021 08:05+4Поддержу про интерфейс как человек который из веба перекатился в геймдев на Юнити. Работать с ЮИ (на проекте много формочек, панелек, окошек открываемых друг из друга) на юнити после JS+HTML+CSS сплошное удовольствие. Настраивается все очень легко, якоря, предпросмотр, доступ по дереву к нужным компонентам, скейлинг в зависимости от разрешения, контейнеры со списками которые умеют в выравнивание из коробки.
После мрака стилей которые надо вслепую верстать внахлест и проверять проходя до нужного компонента в интерфейсе прям кайфуешь.
ProtossOP
07.12.2021 19:43+1Уже анонсирован ввод классов и методов для работы с неуправляемой памятью, которые фактически из C# делают C++.
Можно по подробнее? Может какими-то ссылками поделитесь или скажите где про это читали? Мне как шарписту очень уж интересно почитать об этом. Заранее спасибо.
buldo
05.12.2021 19:02+3Я ни разу не из game dev, но вот это зацепило:
Для того, что бы проитерировать 3 компонента c помощью IJobChunk, вам надо 43 строки кода
Собственно, если бы мне на бэке нужно было бы что-то асинхронно выполнить, у меня был бы ± точно такой же код по объёму и смысла.
Так что претензии не понимаю.
HelpOrMe Автор
05.12.2021 19:45+1Но это же не является оправданием. IJobChunk вам нужен регулярно и постоянно писать столько бойлерплейта не идет вам на руку.
Jes28
05.12.2021 21:45+3Неверно
есть куча готовых встроенных способов это упростить до нескольких строк и можно свои сделать
IJobChunk нужен только если планируется оптимизация простого кода, а оптимизация всегда делает код менее простым но более шустрым
zukrac
05.12.2021 19:07-1У Юнити всё плохо, но в перспективе всё хорошо.
Не было DOTS - плохо, но ввели и в будущем станет хорошо. То что есть уже сейчас можно использовать. И это прилично ускоряет.
Количество готовых крутых решений (платных и встроенных) увеличивается, приближается к количеству таких в Unreal.Таким образом скоро ААА-проекты на Юнити догонят ААА-проекты Анриала.
Мне кажется перспективы хорошие у Юнити, как у движка так и у компании.
Artemko_one
06.12.2021 11:54Дело в том, что когда это "будущее" наступит, это будет уже неактуально. И в Unreal выйдут Lumen и Nanite, и ещё много чего может успеть выйти до того, как Unity доделают DOTS.
Unity AAA догонят нынешние Unreal AAA, но не актуальные на будущий момент
maxgammer
05.12.2021 19:07+1Статья не понравилась абсолютно. Очень однобоко получилось и не аргументированно вообще.
Я уже лет 15 наверное плотно работаю с 3D графикой и на чистом C++ (OpenSceneGraph например), так и на Unreal/Unity. Вот работы - https://www.youtube.com/channel/UC6w7MxEoE2tgWjqi5PqlFAg.
Так вот точно могу сказать, что ерунду можно устроить и там и там, порог входа везде достаточно низкий и можно кашу из BluePrint'ов заварить быстро и не разберется потом никто.
Мне оба инструмента абсолютно утраивают и я их кстати никогда и не сравниваю.
HelpOrMe Автор
05.12.2021 19:37+2однобоко
Так в этом и смысл, я же в начале статьи обозначил, что хочу написать о минусах статьи.
не аргументированно вообще
Я даже не знаю что ответить. Вам виднее.
VioletGiraffe
05.12.2021 19:28+4Они решили, что лучший способ сделать сишарп таким же быстрым как и плюсы, это сделать из сишарпа плюсы!
Какие же это плюсы, в С++ не нужно использовать голые указатели и функции работы с памятью (кроме очень ограниченных участков внутри имплементации, например, кастомного контейнера). А здесь получился чистый Си.HelpOrMe Автор
05.12.2021 19:29-2Да, это Си, изначально в статье так и было, но с С++ выходит комичнее, да и смысл понятен :)
dnnkeeper
05.12.2021 20:20+2Я тоже частенько ворчу на Unity и с завистью поглядываю на новые фичи UE, однако не считаю правильным драматизировать ситуацию. Да, я согласен с критикой того, что новые направления развития Unity оказались чересчур масштабными, разносторонними и увязли в производстве. Но никаких серьезных проблем с проектированием на MonoBehaviour в юнити я не вижу даже для больших проектов, стремящихся к ААА-уровню. Все критичные для производительности места можно расшить. Удобство работы плюс-минус сравнимо с UE, а где-то и лучше за счёт расширений. Фундаментальных проблем препятствующих качественной разработке нет. Есть лишь временные трудности у авторов ассетов на сторе, так как при столь радикальных изменениях которые вносятся в связи с переходом на SRP и DOTS им трудно добиваться стабильности. Но эта проблема осознана, критика услышана. Весь этот год заметно, как движок стабилизируется. Очевидно, конечно, что Unity проигрывает UE в темпах внедрения инноваций и отчаянно пытается сравняться в темпах захвата новых ниш, но это не катастрофа. Будем надеяться что переход на DOTS состоится и у команды найдутся силы вернуться к развитию менее фундаментальных функций и пекеджей, таких как мультиплеер, граф анимаций, альтернативы enlighten realtime gi и пр.
HelpOrMe Автор
05.12.2021 20:56+1серьезных проблем с проектированием на MonoBehaviour в юнити я не вижу даже для больших проектов, стремящихся к ААА-уровню
Довольно странно, можете привести примеры игр стремящихся к ААА уровню, которые не испытывают проблем с MonoBehaviour? Я думал что к этому вообще притензий не будет.
Да, я согласен с критикой того, что новые направления развития Unity оказались чересчур масштабными, разносторонними и увязли в производстве.
У меня были ещё вопросы к тому, почему они делают это на C#. Могли бы написать биндинги к Rust и на них уже делать ECS, и Burst бы не нужен был кстати.
А так я тоже надеюсь что они как-то пофиксят всё. Я не ярый ненавистник Unity, каким меня тут воображают, просто статьи о минусах Unity не было.
AlexdeBur
05.12.2021 21:00+3Разрабатывал на Юнити много чего 3+ года подряд, да и сейчас иногда возвращаюсь (хотя свичнулся в бэкенд).
На самом деле в нем шикарная работа с разработкой внутриигрового UI сейчас. Я бы с огромным удовольствием верстал и страницы для веба в таком редакторе - перетаскивая объекты, настраивая background image, якоря и так далее.
А основные проблемы на мой взгляд - юнити гонится вообще в разные стороны и не доводит ничего до конца. Множество багов, которые не фиксятся годами. И каждая версия приносит их еще больше. 3-5 лет назад движок был куда стабильнее.
FDsagizi
05.12.2021 21:08+4Согласен, огромная проблема юнити, что в мажорных релизах они не выбрасывают старый мусор а многие вещи не развиваются вообще:
UNet можно было развивать и улучшать
Меши - нету стримминга, приходиться пилить костыли
Скиннинг через через шейдеры отсуцвует как понятие, приходиться пилить костыли. ( да в юнити скиннинг через CPU и копию меша )...
Меш Коллайдеры - нет стримминга, зависят от мешей (которые ориентированны на рендер), хотя должен быть свой класс...
Анимация - не стримминга, стремный аниматор, с кучей проблем и слабым UI
Звуки - просто ужас, нету нормального стриминга, есть проблемы с ФПС, проблемы с памятью ...
Текстуры - стримминг есть, но кривой и косой.
Стриминг как таковой отсуувует в понимании доступ к единице ресурса, или его части. Взять тот же Roblox, при входе в игру видно как все постепенно выкачивается с сервера. Юнити просто не готов так работать, из-за это:
Нет нормальной работы в веб среде, где нужен доступ к единице ресурса, и доступ к разным типам текстур pvrtc or etc or .... По этому нет мобил ...
Нет окклюжн кулинга для динамичных сцен, только запеченная статика.
Нету возможности в редакторе запустить несколько игр сразу ( для теста сетевого кода ), приходится использовать хард линки и несколько редакторов...
То, как редактор работает с ресурсами, это вообще кошмар, не дай бог надо сделать re import all...
Нету доступна к текстуре глубины в стандартном рендере, как будто это что-то страшное, приходиться 2 раза рендерить сцену в форварде.
И еще вагон с тележкой мелочей, которые на вскидку не скидку не вспомню ....
Тем не менее, я благодарен юнити, и желаю им развития и успехов!
dnnkeeper
06.12.2021 01:06На счёт стриминга не понял - а как же addressables? Мы вполне хорошо стримили уровни для мобильной AR игры. Что еще удобно - не нужно делать новый билд и заливать всё на стор, просто обновляем addressables с правками уровней или префабов. За счёт базы универсальных компонентов удавалось даже новые режимы игры создавать без перекомпиляции.
Suvitruf
06.12.2021 01:51+1addressables просто механизм даёт, весь стриминг и всю работу с ресурсами самим нужно писать. На фоне UE, где это из коробки есть, совсем печально. В UE5 вон World Building просто прелесть.
domix32
06.12.2021 13:44+2Маленько офтопный вопрос — почему вы везде пишете две м в слове стриминг? Их нет даже в оригинале — streaming.
Myxach
08.12.2021 04:56Про аниматор - не удобная работа с спрайт листами. Создавать несколько анимаций, вручную перетаскивать каждый спрайт для каждого имеющего спрайт-листа это куда менее удобно, чем setSpriteRect(frameSize.X*frameID,frameSize.Y*animID,frameSize.X,frameSize.Y)
Вот представим 200врагов и ты для 200врагов делаешь 4 анимации, заполняешь её 4 спрайтами. И делаешь 200одинаковых аниматоров....ладно, с этим разобрались и тут решили 4 фреймовую анимаширить до 8фреймовой.
khmheh
05.12.2021 21:30Имхо, Amethyst пока не альтернатива Unity, потыкаться для развлечения можно, но что они там наворотили... Чего только стоят имплементация загрузки ресурсов и несобирающаяся документация на docs.rs. И вроде бы разобраться можно в этом всем, да только скудные возможности отбивают всякую мотивацию. Так что пока надеемся и ждем.
ScratchUA
05.12.2021 23:02+3Анонс мнимого продолжения "У Unity всё плохо. Часть 2, или Что у кого болит..."
В этом выпуске мы пожалуемся на:
• Scriptable Rendering Pipelines и какого хрена Unity Technologies постоянно всё ломает;
• пакеты Input System и Animation Rigging и почему они не станут панацеей от болезней систем ввода и анимации;
• замороженную разработку пакета Kinematica, реализующего технологию Motion Matching;
• новый сетевой стек Netcode for GameObjects, который в плане эффективности устарел ещё до релиза;
• отсутствие нативной поддержки Terrain Details в HDRP.HelpOrMe Автор
05.12.2021 23:04Надо продавать права на экранизацию
ScratchUA
05.12.2021 23:33+7И, в итоге, получится многосерийный арт-хаус "не для всех", потому что типичный workflow 90+% пользователей Unity не включает в себя практически ничего из вышеперечисленного. Обычно всё как-то так:
1. Сэкономил денег, купил доступный Low-Poly пак от Synty с модельками замков, хижин и персонажей, расставил на сцене - красиво!
2. Почитал про программирование логики игры в C#. Блин, как же сложно.
3. Попробовал бесплатный Visual Scripting, тоже не осилил, снова начал экономить.
4. Купил какой-то Builder, поменял модельки, стало ха-ра-шо. Уже можно грабить корованы, собирать лут и раздевать принцессу.
5. Захотелось добавить воду, снова начал экономить, купил ассет воды. Вода почему-то пропадает, если я удаляю скрипт Water System, надо впаять 1 звезду, пожаловаться разработчику (это не стёб! пруф) и запросить рефанд.
6. Рефанд отклонили, надо копить на новый ассет воды...
и так до бесконечности, а вы тут DOTS, ECS, Burst...
F376
06.12.2021 04:00Что там с кооперативным редактированием Unity проекта в 2021 году? Что происходит если два человека поправили одну и ту же сцену?
Goldseeker
06.12.2021 12:46Не видел движков, у которых этой проблемы проблемы в том или ином виде нет. Вот в Unreal вообще все ассеты бинарные и если конфликтуют то делай что хочешь.
AntonovDV
07.12.2021 17:24Используем UnityYAMLMerge, но от большой переделки иерархии это все равно не спасет, придется править конфликты руками (со временем и в этом можно руку набить)
Evengard
06.12.2021 06:37+2Раз уж затронута тема UE и C# - кто нибудь пробовал вот это?
https://github.com/nxrighthere/UnrealCLR
Заявляется полная интеграция .NET 5.0 внутрь UE с доступом ко всему API UE.
khrundel
06.12.2021 07:37+4Если убрать из статьи воду (что ни говори, ругать UI редактора движка, на котором написана половина игр как-то странно, видимо люди справляются), то в статье противопоставляются Unity, в котором для тяжёлой графики плюсообразный C#, а для лёгких игр обычный C# и UE, в котором для чего-то сложного плюсы, а для простого блюпринты. Выбор из этих 2х совсем неочевиден. В статье явно не хватает ответа на вопрос о совместимости DOTS с простым юнити кодом. Если уперевшись в производительность классического Unity-кода на C# можно переписать одну подсистему на DOTS и получить высокую производительность это одно, а если нужно будет переписывать всё, то как бы совсем другое.
maxcat
06.12.2021 07:58+3>в юнити старый c#, магические месаджи, издевательства над языком
Используйте Stride3d это самый идейно дотнетовый и при этом кросплатформенных движок.
>UIElements (UIToolkit), с xml и css, но без js
А зачем js в не вебпомойке? Вы возмущаетесь, что c# делают like cpp, но при этом зачем-то хотите в юнити like веб с js.
А по хорошему там и CSS не нужен. Это же очередная вебошибка - использовать для стилей аж ещё один язык.
Надо как в WPF: xaml+cs.
Хотя на самом деле любой язык разметки отличный от языка логики - лишнее.
Удобнее всего писать всё на одном языке - не запоминая лишний синтаксис
HelpOrMe Автор
06.12.2021 11:54-1Для xml/css/js уже есть разработчики, материалы для обучения, опыт, методики, бест практис и т.д. Не зря же они и начали разрабатывать UIElements, а js к тому же просто удобный, можно и попробовать и без него обойтись.
maxcat
06.12.2021 12:12+6Да, для xml (xaml) есть уже материалы и коммунити: WPF, Avalonia, Xamarin, UWP.
Js вообще не нужен, особенно в своей неродной среднее - не браузере. А особенно, когда уже всё на дотнете, а именно c# сделано. А вы хотите прикручивать сбоку лишний стремный язык и дублировать на нем код.
Если нужен js в десктопе (мисье знает толк) можете рассмотреть такие кривые поделки, как Facebook spark ar, snapchat lens studio.
Но не надо тащить ваш отсталый веб в десктоп. В этом абсолютно нет смысла: тут уже давно есть удобные, производительные, современные, кроссплатформенные языки и решения.
noldowalker
07.12.2021 08:40+1UIElements это очень круто, так как у тебя условно визуальный, настраиваемый редактор для визуального интерфейса, который можно прям на месте покрутить потыкать. После 5+ лет в вебе (благо я был фулстаком и фронт верстал не очень много) я надеюсь что мрака из стилей и верстки больше не коснусь никогда.
Это вообще что такое, когда вам нужно для того, чтобы сделать интерфейс, отдельный язык со стилями, отдельный язык с разметкой, отдельный язык для логики, все это друг в друга имплементируется, сверху для "простоты" накручивается фреймворк и пара библиотек.
А еще вы это верстаете вслепую, сначала поменяете стиль, допишете функцию которая разворачивает стор в набор элементов, а потом у вас верстка поплывет потому что 3 стиля применяют свойство в странном порядке.
Спасибо, сами в этом варитесь, пожалуйста оставьте визуальный редактор юнити интерфейса там где он был.
pecheny
06.12.2021 15:47+3Удобнее всего писать всё на одном языке — не запоминая лишний синтаксис
Точно-точно. И язык такой давно придуман – лисп называется. Там и гомоиконичность, и лишнего синтаксиса запоминать точно не придется, его всего ничего.maxcat
06.12.2021 17:05-3И лисп из того же века, что и js. Наверняка и удобность та же. В общем прах к праху
pecheny
06.12.2021 18:03+3Несмотря на то, что лисп действительно отлично подходит для смешения декларативной разметки и логики приложения в рамках одного языка, мой призыв все же был иронией.
Я хотел лишь ненавязчиво подчеркнуть излишнюю категоричность утверждения формально подходящим, но очень специфическим примером.
Замечу, что не могу припомнить такого странного критерия как век создания, для оценки языка программирования, упомянутого не в качестве шутки. Равно как и применение его в качестве оценки удобства.
Suvitruf
06.12.2021 18:17Если до такого доходить, то лучше уж Lua.
pecheny
06.12.2021 21:10+3Я упомянул лисп не за его легкую встраиваемость, а именно за синтаксис. Язык разметки предназначен для описания данных, ЯП – для описания логики. Лисп обладает свойством гомоиконичности, из которого следует тождественность синтаксиса для обеих задач.
Поскольку критерием критики в исходном комментарии являлась необходимость учить новый синтаксис, дополнительная ирония состоит в том, что синтаксис лиспа можно описать семью строчками (и он подойдет и для данных, и для логики); что, впрочем ничего не говорит о простоте использования (особенно, человеком неподготовленным).Suvitruf
06.12.2021 21:34Спасибо за развёрнутый комментарий, правда, я ответить по существу не могу. В своё время, если память не изменяет, лишь с CLISP'ом в универе поработал, больше после этого не было возможности ????
Ichimitsu
06.12.2021 09:26+3Статья про минусы, это хорошо, но однополярно, надо бы такую же, но про плюсы. Например то, что Unity позволяет построить архитектуру вообще исключив MonoBehaviour (оставив, его только для запуска всей логики Awake или Start). Бизнес-логика вообще не требует MonoBehaviour. Например, есть возможность строить все на ScriptableObject, который почему-то все игнорируют или юзают для создания Asset'ов данных.
В целом Unity это такой механизм, который позволяет творить многое, если что-то не устраивает. Для меня лично единственный минус движка - это его однопоточность. Т.е. можно было бы не юзать MonoBehavoiur вовсе, но ты не можешь получить доступ к UnityObject вне основного потока, точнее доступ получишь, но ничего сделать с этим объектом не можешь и это проблема конечно, из которой вытекают проблемы с UI, Input'ом и т.п.
Благо что бизнес-логику все таки можно спокойно распаралелливать и выносить вообще туда, куда тебе надо, а проблемы View оставить на Unity.
andreypavluyk
06.12.2021 11:47-1Спасибо за статью, согласен с тем, что однобоко написано..
HelpOrMe Автор
06.12.2021 11:49Я же хотел написать о минусах Unity, даже обозначил это в начале, я не писал обзор на Unity или что-то в этом духе. Может заголовок обманчив, для следующих статьей учту.
Newbilius
06.12.2021 11:49+10Перефразируя классика, "игровые движки делятся на два типа — те, которые все ругают, и те, которыми никто не пользуется" :)
LinearLeopard
06.12.2021 11:58Сорян, ни разу не программист игр, возник вопрос по ECS, я правильно понял, что движок заставляет создавать объект под каждую пулю и систему, которая ими управляет? Это прямо честный объект с выделением памяти и сборкой мусора?
Tiendil
06.12.2021 12:05+1Системы создаются не под «каждую пулю», а под каждый тип взамиодействия. Вне геймдева такую логику обычно называют менеджерами. Например, можно сделать систему для изменения координат всех пуль на основе их скорости и прочих свойств.
По поводу «объект под каждую пулю» — это сильно зависит от конкретного движка и желаемой игровой логики. Если, например. каждую пулю надо честно рисовать и поведение каждой пули зависит от физики, то отдельный объект будет удобнее. Если это не требуется, то возможны варианты.
HelpOrMe Автор
06.12.2021 12:08+1Не под каждую систему, просто разные системы могут итерировать выбранные ими компоненты у пули (сущности), сущностей на сцене много, соответственно и системы итерируют нужные себе компоненты всех пуль на сцене. Технически, сущность в Entities это структура с двумя int32 полями, так что это честный обьект, если вы про это. Сборки мусора GC сущности как и компоненты не подлежат, они аллоцируются кастомным аллоктором Unity, если, опять же, вы про это.
LinearLeopard
06.12.2021 13:39Технически, сущность в Entities это структура с двумя int32 полями, так что это честный обьект, если вы про это. Сборки мусора GC сущности как и компоненты не подлежат, они аллоцируются кастомным аллоктором Unity, если, опять же, вы про это.
Да про это, просто в моём понимании алокации и уборки — вещи затратные, но, видимо, в своём алокаторе unity соптимизировали эти моменты)Miwwa
06.12.2021 21:08-1но, видимо, в своём алокаторе unity соптимизировали эти моменты)
Ох, если бы они хоть что-то оптимизировали(
max_mustermann
06.12.2021 13:36Я не из game dev, поэтому задам такой наивный вопрос: а что это за шутеры такие, что у вас одновременно 50К снарядов летят? Это типа на сцене 10 тысяч персонажей и все одновременно стреляют или как такое вообще возможно?
HelpOrMe Автор
06.12.2021 13:37-1Это же пример ;D
max_mustermann
06.12.2021 14:00Пример чего?
HelpOrMe Автор
06.12.2021 14:01Пример работы ECS
Suvitruf
06.12.2021 14:42Зачем нереалистичные примеры приводить? ????
UrsusDominatus
06.12.2021 17:06Я вон, ниже, ссылку на видео давал. Игра на Unity + DOTS. Куда уж реалистичнее
Suvitruf
06.12.2021 17:41В посте речь была про шутер же. А так да, какие-нить симуляции и стратегии могут много юнитов и снарядов насчитывать)
domix32
06.12.2021 13:50Какой-нибудь Total War like геймплей думаю вполне может покрыть 50к снарядов. Ну и по мелочи всякие разрушения с физикой обломков тоже довольно многочисленными бывают.
max_mustermann
06.12.2021 14:08Total War явно не шутер. И нет там никаких 50К снарядов, с точки зрения физики выстрел хоть тысячи арбалетчиков - это один выстрел, у него есть одна своя траектория и один условный эллипс поражения.
ksbes
06.12.2021 15:31+4Supreme Commander. Там на столько всё физично, что выстрелы дальнобойной артиллерии могут сбить случайно пролетающий мимо самолёт. А юнитов там по 2000 на каждого игрока, а игроков - 8-16 и юнит может до десятка снарядов за залп выдать. Вот и считайте. В реале (виртуале?) до 50к вряд-ли доходит (игра просто захлебнётся), но пару тысяч снарядов на всей карте (а там можно вполне себе обозревать всю карту за раз) в генеральном сражении - вполне себе обычное дело.
KAW
06.12.2021 14:17Я бы поспорил у утверждением, что Unity для простых игр. Смотря что считать "простым": Pillars of Eternity написаны на Untiy.
Так же не соглашусь, что Unity "не для программистом": в отличие от Unreal Engine в Unity нет нативного визуального программирования, в отличие от GameMaker есть полноценный .Net со всеми возможностями "попрогать": от многопоточки до реактивного программирования.
А еще не соглашусь, что ECS в Untiy это только DOTS. На мой взгляд, DOTS - мертвый продукт, он еще не вырос, но уже выглядит противно. Я дико рекомендую LeoEcs как пример хорошего ECS фреймворка: он приятный, более функциональный и лучше интегрируется с системами Unity. Конечно, бесплатной векторизации мы не получим, но получим "бесплатные" оптимизации кеш миссов (для чего и нужен Data Oriented Programming). А SIMD можно и нативно использовать в тех местах, где он нужен: для массового pathfinding, обработки повреждений в больших сражениях и проч.
Suvitruf
06.12.2021 14:43Так же не соглашусь, что Unity «не для программистом»: в отличие от Unreal Engine в Unity нет нативного визуального программирования, в отличие от GameMaker есть полноценный .Net со всеми возможностями «попрогать»: от многопоточки до реактивного программирования.
Ну… есть Bolt ????
А вот Bolt 2, правда, пока заморозила…
kraidiky
07.12.2021 10:48Болт, трудно отлаживаемое гавно, молча глотающее эксепшены. Мы хотели его использовать для левелдизайна, за три недели замучались, перешли нафиг на FlowCanvas и бед не знаем. Всем советую вместо болта.
Suvitruf
07.12.2021 12:27Ну да, т. к. это стороннее решение. Поэтому Юнитишники и начали Bolt 2 сами делать с кодогенерацией, но не сложилось.
kraidiky
07.12.2021 23:57+1Там отличия далеко не только в кодегенерации, тем более, что если вы компилируетесь под эпл кодегенрация у канваса тоже есть. Потому что как эпл не любит рефлекшена.
Например во FlowCanvas каждый экземпляр ноды — это экземпляр класса, распатитесь аллокацией за удобство написания и отладки. А в болте ребята попытались выползти на принципе что любая нода это статический метод, а все переменные составляют часть Flow. Из-за этого и Flow раздуло и отлаживать это — убиться проще, и output.Do(new Flow()) нельзя сделать. Если уж взялись соревноваться за 0 аллокаций надо же было соотвествующими инструментами обложиться со всех сторон. Короче слишком на многое позарились и не вывезли. Как только вам надо их стандартный набор нод расширить — всё туши свет.
Ну и повторюсь, идея скрывать эксепшены чтобы не пугать криворуких пользователей это просто шедевр мысли.Suvitruf
08.12.2021 01:14Всё так. Поэтому я такие штуки обычно советую чисто для прототипирования для ГД или для обучения.
DeepFakescovery
06.12.2021 16:03Т.е. по вашему сейчас многомиллионная индустрия успешно продаваемых Unity игр в Steam и android app store должна закрыться?
C++ это прошлый век. Даже пользователи UE4 стараются писать всё на блюпринтах, и не лезть в C++ грязь. Вот только писать на C# так же приятно как на блюпринтах, только быстрее. А код C# компилится в нативный С++ и затем со всеми оптимизациями компилится в исполняемый код.
В UE архитектура предполагает использование только под шутеры со своим бредом ввиде жесткой связки APlayerController -> APawn, нельзя просто разместить 3д объекты, направить на них камеру и получать визуализацию 3д мира, нужно городить кучу бессмысленных классов, что умножается на 2 в случае C++ из-за .h файлов.
Unity это не только игры но и визуализация и обучающие программы.
Сейчас есть много новых движков на C#.
Короче статья - писк умирающего С++ динозавра.
HelpOrMe Автор
06.12.2021 17:09Т.е. по вашему сейчас многомиллионная индустрия успешно продаваемых Unity игр в Steam и android app store должна закрыться?
Нет, я просто написал статью о минусах Unity. Я вообще ничего не говорил о том, что C# хуже чем С++ или вообще хоть как-то их сравнивал. Ощущение, что вы читали статью по диагонали.
Короче статья - писк умирающего С++ динозавра.
Я на С++ писал полторы программы после того как прочитал по нему книгу, мне не понравилось нагромождение принципов и стандартов, я перестал на нем писать. Та и по возрасту я не могу быть С++ динозавром, он же меня старше почти в 2.5 раза.
Ritan
06.12.2021 18:58+1Как должно быть прекрасно жить в мире розовых пони и радуг. А в реальности даже С++ не всегда может достаточно оптимизировать код( приходится идти и тюнить код, чтобы генератор нармально отработал ) , что уж говрить про поделие с трансляцией динамического языка с GC на C++
нужно городить кучу бессмысленных классов, что умножается на 2 в случае C++ из-за .h файлов.
Право дело. Что же это за движок, раз нельзя всё разместить в `public static void main`
Alex_Builder
08.12.2021 06:09C++ это прошлый век. Даже пользователи UE4 стараются писать всё на блюпринтах, и не лезть в C++
Прошлый, прошлый. Только вот беда, что одни и те же несложные алгоритмы на С++ даже без особых танцев с бубном и оптимизации на SSE/AVX и то выполняются порой в разы быстрее, чем на C#. SciMark вам в помощь для осознания сего факта.
А C# я тоже очень люблю в офисных и даже в инженерных поделках. Один только LINQ to Object экономит массу времени в написании рутинного перемалывания данных.
Но все же не место этой удобной мэнеджет погремушке в высокопроизводительном коде. И напрасно Unity на радость школоте его как скрипт прикрутили. UE на этом паровозе им не догнать.
DeepFakescovery
08.12.2021 08:59все высоконагруженные алгоритмы связанные с рендерингом встроены в движок. В юнити есть даже DOTS. Тебе даже с BSP деревьями не надо иметь дел. Юзеру остаётся управлять только логикой. Если ты изобретаешь велосипеды на avx, скорее всего ты не используешь движок по назначению. Более того, если твоя игра жрёт проц, значит архитектура твоей игры убогая, и тебе надо отправляться на перестажировку, как это стало с Battlefield 2042, которая жрёт 80% проца i7-9700K при этом количество объектов в мире можно сосчитать на пальцах, и С++ его не спас, наоборот критические баги фиксятся неделями, потому что очевидно что игра компилится долго , и хотфиксы не залить. В итоге 80% юзер базы уже отвалилось. Это всё что надо знать про написание ААА игр на С++ в 2021.
Если бы С++ был отличен, то UE пользователи на нем бы и писали , но они предпочитают blueprints.
Если 20 лет назад тебе надо было писать сырой код OpenGL то сейчас надо управлять лишь логикой игры, и С++ для этих целей не подходит.
Вот еще пара относительно новых движков, которые так же используют C# - Xenko и FLAX.
yasha_akimov
06.12.2021 18:30+1Ещё до появления dots я делал отдельный класс, который хранил в себе ссылки на компоненты разных объектов и в параллельном цикле бегал по ним. Все новые механики, связанные с большим числом компонентов, писались через вот такие вот системы. Лично мне казалось, что ввести подобную фичу в сам движок это как раз способ усидеть на двух стульях, так как у нас и производительность вырастает, и многопоточность легко реализуется, и простота сохраняется, так как по сути вместо FixedUpdate мы просто имплементируем другой метод, а всё остальное делается за нас.
Wohlstand
06.12.2021 22:19+1Microsoft XNA. Не движок, но фреймворк для создания игр на C#, больше не поддерживается. Но на нем создают довольно много разных инди игр и по сей день, одна из самых популярных это Stardew Valley.
Всё благодаря проекту FNA, который его возродил из пепла. Теперь даже Terraria, некогда созданная с помощью XNA, теперь сидит на FNA, и даже имеет нативную сборку под Linux (установил игру из Steam и увидел в файлах факт использования FNA).
trolley813
06.12.2021 22:57Думаю, можно и про O3DE написать, хотя оно сравнительно молодое - первая стабильная версия вышла несколько дней назад. Вкратце - это 100% open-source продолжение Lumberyard от Amazon (видимо, очищенное от несвободного кода), переданное под контроль Linux Foundation. Пробовал, выглядит более-менее неплохо, хотя документации пока очень не хватает.
Alex_Builder
08.12.2021 02:20-2И на какие только извращения не идут любители офисных мэнэджет-песочниц, чтобы не учить C++ :D
Myxach
08.12.2021 08:52Так, почему у меня ощущение, что автор использует MonoBehaivor как-то не так? Ощущение, что он его использует как скрипт объекта, а не независимый компонент
lookid
Любой движок станет out of control, если дать волю художникам. Поэтому нужно постоянно бенчмаркать и постоянно микро-оптимизировать. Чтоб не проснуться, а у вас ночной билд 15fps на тир-1 таргете.
ThePaleEmperor
Что? Выдйет из-под контроля?