Comments 33
Иными словами, проблема разного язык разработки не в том, что может понадобиться больше времени на его изучение для новичков, а в некотором постоянном оверхеде на разработку в UE по сравнению с Unity. Я намеренно не говорю тут про разницу в производительности итогового кода, про которую почему-то часто упоминают в других сравнениях, так как практическая разница при реальном использовании сильно преувеличена.
Вот тут бы поподробнее, на самом деле. Почему преувеличена? На чем базируется такое мнение? Возможно, есть ссылка на бенчмарки для сравнения?
Понятно, что в общей картине язык внесет очень небольшой импакт на производительность, но все же.
Шарп сильно проще чем плюсы анрила с своими макросами и препроцесосром. Фактически - у Анрила своя вариация плюсов с сахаром и правилами.
Я согласен с тем, что шарпы проще (но с некоторыми оговорками), но мне интересно больше про последнее, где говорится, что разница в использовании преувеличена. Звучит просто странно, ведь C# требует рантайм, а C++ нет. Ссылку бы на источник таких сведений.
А, в этом плане. Я думаю рантайм маленький. А если говорить про игры, то игры в целом на каждый кадр делают дофига операций и приходится играть с оптимизацией. Тот же Юнити вообще для мобилок топ, а там железо сами понимаете.. в итоге узкое место всегда производительность gpu.
А у вас C++ тоже с нехилым рантаймом идёт в случае Анрила, а последние версии .NET компилируют те части IL, что должны работать побырее в байткод, который исполняется напрямую на процессоре. Так что перфоманс от языка в данном случае можно не учитывать вовсе. Важнее перфоманс систем самого движка, который тут зависит от задачи в основном. Если сравнивать маленький лёгкий проект, на двух движках, то скорее всего у Unity будет меньше потребление памяти, и мб производительность, но по мере увеличения комплексности и размера проекта, начальный оверхед Unreal начнёт уходить на задний план, благодаря стабильности масштабирования этих систем вширь по сравнению с Unity
Речь про эффект на производительность всей игры. Вы сами ответили в целом, что пользовательский код - меньшая часть всех вычислений.
Поэтому на практике в рамках оптимизации обычно приходится оптимизировать не скорость выполнения конкретных кусков пользовательского кода, а снижать необходимое количество вызовов к API движка. Но в некоторых статьях пишут, что C++ быстрее чем C#, создавая впечатление, что поэтому игра на UE будет заведомо производительнее - это вот как раз преувеличение.
Тогда понял, что Вы имели в виду. Соглашусь, это и правда может создавать некорректное впечатление. Но Ваша формулировка тоже несколько размыта и, вероятно, лучше ее несколько уточнить.
Спасибо за ответ!
Производительность c# очень сильно зависит от используемого компилятора.
В тренде по переходу на .net core есть хорошее сравнение от разраба из MS
https://forum.unity.com/threads/unity-future-net-development-status.1092205/page-50
Там же хорошее обсуждение по производительности компилируемого кода в целом
Снижение производительности можно узнать, сравнив системные требования игр. Какая-нибудь условная Firewatch будет предъявлять примерно те же системные требования, что и What Remains of Edith Finch при несравнимо худшей графике. Какой-то сногсшибательной по графике игры на Unity вообще не знаю. Если знаете - поделитесь.
А каков критерий "сногсшибательности" графики? Escape From Tarkov очень хорошо выглядит например. The Forest в свои года выглядела очень достойно. Если говорить за реализм.
Если говорить о стилизации, то Valheim выглядит просто превосходно, много красивых игр света на локациях, и общий стиль симотный. Genshin Impact смотрится очень достойно.
Достойную то картинку при желании и умении можно и из Godot вытянуть, инструменты во всех трёх вариантах для этого есть.
Можно подробнее рассказать про тесты на UE? Работаю в юнити, и мы используем Unity Test Framework , едитор тесты для валидации разных типов ассетов, и юнит тестирования систем. и плей моды тесты для более чего сложно, когда нужен мир, тестирования взаимодействия юнити и систем и тд. И это довольно просто
Пример теста, который можно сделать на UE:
1. Создаём сервер с какой-то картой
2. Подключаем два клиента
3. Проверяем что на сервере и на обоих клиентах появились оба аватара
4. Первый аватар прожимает абилку невидимости
5. Проверяем, что на втором клиенте исчезла информация про первого аватара
6. Ждём окончания действия абилки
7. Проверяем, что на втором клиенте вновь появилась информация про первого аватара
Это про сетевой тест, но насколько я понял, в Unity и с несетевыми тестами есть проблемы (выдуманный тест чисто для примера):
1. Создаём мир с какой-то картой
2. Спавним игрока
3. Проверяем, что каждую минуту игрок получает какое-то количество очков за то что он жив
4. Проверяем, что через 15 минут матч завершается
Как понимаю в Unity потребуется магия с ускоренным течением времени, когда реальное время выполнение теста всё равно будет фиксированным и не будет зависеть от производительности билдера. В случае UE все тесты выполняются за миллисекунды/максимум секунды если там прокручивается несколько минут игрового времени. Но может в Unity тоже можно прокручивать время детерминировано и как хочешь и я просто не нашёл как это сделать.
Это про сетевой тест, но насколько я понял, в Unity и с несетевыми тестами есть проблемы (выдуманный тест чисто для примера):
Нет такой проблемы. В Unity тебя никто не заставляет привязываться к реальному времени. Я бы наоборот сказал, что в Unreal сложнее, так как в C# инструментарий для тестирования более развит.
Вот это кстати интересная особенность, что тесты в анриле отрабатывают за минимально возможное время.
В юнити на плеймод тестах с запуском сцены такое придётся делать вручную через большой timeScale, что наверное может приводить к багам.
Тесты на мультиплеерную игру в юнити вообще не сделаешь, разве что писать свой туллинг поверх какого-нибудь ParrelSync, потому что юнити не умеет запускать второй клиент в рамках одного редактора.
Уровень поддержки C# со стороны IDE качественнее, чем для C++, особенно в Visual Studio. Благодаря JetBrains Rider различия в поддержке сильно снизились, но всё равно опыт работы в IDE для C# будет приятнее.
А чего конкретно больше всего вам не хватает в студии для плюсов в сравнении с шарпом?
Сколько бы я независимых постов на тему игровых движков не находил - Unreal всегда изображён чем-то плохим и недоделанным. Часто преследует такое чувство словно этот движок создаёт только одни проблемы
Сообщение из будущего)
После того как Godot выкатил интегрированную версию движка под Blender в виде расширения. Очень многие сменили свои пристрастия в выборе игрового движка.
Чуть подробнее об этом..
LibGodot позволит встраивать Godot в другие приложения, например, в Blender 😱 или Blender в Godot 🤔 в общем не суть)
История от Miguel de Icaza про встраиваемый игровой движок
Много лет назад, работая в Xamarin, где мы создавали кроссплатформенные библиотеки для мобильных разработчиков, мы хотели предложить нашим пользователям возможности 2D и 3D игр в виде добавления 2D или 3D контента в их мобильные приложения.
Для 2D мы создали и разработали множество библиотек, вдохновленных Cocos2D.
С 3D ситуация была сложнее. Мы финансировали несколько библиотек в течение нескольких лет, вносили свой вклад в другие, но ничего не вышло (история этого заслуживает отдельного поста).
Примерно в 2013 году мы огляделись вокруг, и на тот момент у нас было два претендента: один - встраиваемый движок с множеством симпатичных функций, но не очень хорошей поддержкой пользовательского интерфейса под названием Urho, а второй - Godot, который имел отличную IDE, но не поддерживал встраивание.
В то время я связался с Juan, чтобы обсудить, можно ли превратить Godot в такой движок. Хотя я обычно веду подробные записи всех своих встреч, эти записи, к сожалению, пропали в результате приобретения Microsoft, но из того, что я помню, Juan сказал мне: "Godot - это не то, что вы ищете" в двух измерениях, не было никаких ближайших планов по превращению его во встраиваемую библиотеку, и он не был таким продвинутым, как Urho, поэтому он рекомендовал мне выбрать Urho.
Мы вложили значительные средства в привязку Urho и создали UrhoSharp, которая стала отличной 3D-библиотекой для наших пользователей C# и работала не только на всех настольных и мобильных платформах, но мы проделали тонну работы, чтобы сделать ее отличной для гарнитур AR и VR. К сожалению, руководство Microsoft оставило UrhoSharp умирать.
Затем сопровождающий Urho ушел с поста, и Godot стал одним из самых популярных проектов с открытым исходным кодом в мире.
В прошлом году @Faolan-Rad внёс патч для Godot, чтобы превратить его в библиотеку, которую можно было бы встраивать в приложения. Я использовал эту библиотеку для создания SwiftGodotKit и с тех пор очень доволен ею - она позволяет людям встраивать содержимое Godot в свои приложения.
Однако патч имел серьезные ограничения: он мог запускать только одну игру Godot в качестве встроенной системы и не мог делать ничего больше. Ребята из Smirk Software хотели пойти дальше. Они хотели разместить независимые сцены Godot в своем приложении и иметь больше контроля над ними, чтобы они могли посыпать свое мобильное приложение контентом Godot по своему усмотрению.
Они профинансировали некоторые первоначальные работы и наняли Gergely Kis's company для выполнения этой работы.
Gergely продемонстрировал эту работу на GodotCon в прошлом году. Я вернулся с GodotCon очень воодушевленным и решил превратить свой прототип Godot on iPad в полноценный продукт.
Одной из функций, которые мне были нужны, была возможность встраивать фрагменты Godot в отдельные компоненты пользовательского интерфейса iPad, поэтому мы работали с Gergely над созданием и полировкой этого патча для общего использования.
Сейчас на рассмотрении находится полный патч, позволяющий людям встраивать произвольные сцены Godot в свои приложения. Для пользователей SwiftUI это означает, что вы можете встроить сцену Godot в представление, отображать и управлять ею по своему усмотрению.
Надеюсь, команда примет это изменение в Godot, и как только это будет сделано, я обновлю SwiftGodotKit, чтобы предоставить эти новые возможности пользователям Swift (привязка для других платформ и языков оставлена на усмотрение)
После разговора с Juan прошло всего десять лет, но я снова твёрдо стою на земле Godot) 23 апреля 2024 г.
LibGodot - это система, позволяющая компилировать Godot как библиотеку и подключаться к ней с помощью GDExtensions, передавая указатель функции на точку входа реализации GDExtension перед запуском Godot.
LibGodot добавляет поддержку языков, которые поддерживают C, но не могут быть скомпилированы в общую библиотеку.
LibGodot позволяет использовать различные режимы выполнения C#, позволяя компилировать dotnetAOT, поддерживать C# android и C# web.
https://github.com/migeran/libgodot_project
https://github.com/godotengine/godot/pull/72883
https://tirania.org/blog/archive/2024/Apr-23.html
Самая большая проблема игр на UE - так это то что все новые игры на нем почему то юзают в лучшем случае пару ядер) и с чем связана такая тенденция я пока понять не могу. Проблема на стороне разработчика или на стороне движка? На unity возможно такое тоже присутствует, но игр на пк не выходит столько, что б проверить это
А можно пару примеров улучшения уешного C++ по сравнению с обычным? Например, если там своя стандартная библиотека (как я понял), то как выглядит работа с коллекциями? Спасибо.
UE библа практически идентична STL. Но имеет некоторые различия, которые обусловлены кросс-платформенностью. Просто сядь и начни работать с UE, и сам всё увидишь и поймешь =) А до тех пор будешь только сомневаться и вносить смуту =)
Спасибо большое за ответ и моё сэкономленное время, я уж хотел действительно скачать.
Я ищу нечто максимально непохожее на упоротый STL, и при этом достаточно популярное, чтобы проект завтра не закрылся (как, например, этот). Но таких проектов мало, и приходится смотреть даже в сторону игровых движков.
В следующем году выходит первая версия Carbon, наверно, лучше просто подождать, а потом переписать всё на нём.
Эммм. Анрил не про замену STL. Ты что-то совсем не то крутишь.
То, что я ищу замену STL даже в таких странных местах, как Анрил, показывает всю глубину отчаяния.
Например, после публикации этого списка, я полностью его прошёл, но увы.
Все ещё мне не понятна цель замены STL. Не нравится - может быть ты не на том языке просто пишешь код? Ну то есть, почему ты ищешь замену? Тебе не понятно, как оно работает? Тебе кажется это слишком сложным? Ты считаешь, что надо понимать реализацию до каждой строчки? В чем твоя проблема? Озвучь ее, и возможно она решится
Долго писать, но я не могу отказать человеку, который сэкономил мне время.
Стандартная библиотека плюсов — с моей точки зрения, худшее, что можно придумать. Автор STL, взятого в ней за основу, откровенно говорит, что считает ООП ошибкой. Куда смотрел комитет, как поделие такого экстремиста всучили миллионам программистов — этого я не пойму никогда. Он говорит, что ООП мешает писать алгоритмы. Дядя Стёпа! Средний прикладной программист пишет алгоритмы (в твоём понимании) раз или два в год. Всё остальное время он их вызывает. Так под кого должен быть заточен язык? Что мы в итоге имеем. Строка, которая не умеет делать ничего. (Кроме как просто быть строкой). Коллекции, в которые не энкапсулированы алгоритмы. И вдобавок самая дерьмовая терминология (каким же надо быть извращенцем, чтобы вместо List<>::Add запилить vector::push_back).
На этот фундамент в виде STL'я ебустисты накрутили приколы в духе std::chrono::system_clock::now().time_since_epoch().count() на замену time(NULL), что совершенно не улучшило вкус стандартной библиотеки.
Когда разработчики дотнета поддержали лямбды, они одновременно с этим запилили в стандартную библиотеку LINQ. Где аналог LINQ в стандартной библиотеке C++ после того, как в С++ появились лямбды (синтаксис запросов не нужен, синтаксиса с функциями более чем достаточно)? Ответ знаем мы оба.
И т.д. и т.п.
Можно видеть, что я критикую только стандартную библиотеку. К синтаксису языка у меня тоже есть претензии, но с его недостатками я готов мириться. А вот мириться со стандартной библиотекой может только тот, кто не пишет на других языках и не понимает, чего он лишён и что ему дали вместо этого.
Большинство тех, кто не любит стандартную библиотеку тупо ушли на другие языки. (В том числе «Си с классами»). Но есть, к сожалению, ещё и бизнес-требования (например, никакой виртуальной машины, т.е., CLR/JVM). Эти требования ставят жирный крест на большей части возможных альтернатив. Остаётся, по большому счёту, Rust и Carbon (и я уверен, что Carbon порвёт Rust как грелку), но хотелось бы иметь возможность хотя бы некоторые вещи писать на плюсах. (Carbon, собственно, и предполагает писать параллельно на обоих языках). Что возвращает нас к вопросу о приличной стандартной библиотеке. А писать свою библиотеку я морально не готов. Тащить Qt или MFC только ради их «стандартной части» тоже бы не хотелось.
Примерно так.
Сдается мне, что простота юнити преувеличена.
Ещё одна статья Unity vs Unreal Engine