Комментарии 43
Почему не C# первым?
Почему он должен быть первым?
Потому что подавляющее большинство разработчиков игр в снг - это разработчики на юнити, а он использует c#.
Было бы логично таргетить в эту аудиторию. А так, мимо кассы, получается.
Не соглашусь. Половина использует анрил, а там с++. Да и наоборот отлично, когда у тебя внутренние библиотеки в Nau Engine написаны на с++, и ты сам тоже пишешь код на с++. Да и с++ довольно популярный язык.
Ну это просто не правда:)
Посмотрите количество вакансий, большинство будет unity.
Библиотеки на c++ пусть будут написаны, это не мешало сделать c# первым.
Как вы из "Посмотрите количество вакансий, большинство будет unity" делаете вывод что "подавляющее большинство разработчиков игр в снг - это разработчики на юнити"?
Может наоборот. Разработчиков на юнити мало -> вакансии не закрываются.
В общем неубедительно.
Игры делаемые в рф на unity как правило лутбоксовые казино, по этому там так много вакансий unity c#. Этот движок просто пытается быть движком в нем даже lua есть. Пусть переучиваються. Аудитория это история про просто потребителей, которые выйдут на него через рекламу. Работники попадут на этот движок исходя из: делал игры, стек не знаком, пишу на таких то языках, готов учиться новому
Мое личное определени лутбоксового казино — море контента который клепают дизайнеры и художники, код и геймплей не важен
Это так не работает при найме.
Когда студия выбирает стек, она изначально планирует, кто сможет на этом работать. Если таких разработчиков будет мало, а вакансий станет много, то расходы будут выше рынка. Ну или придется довольствоваться работниками, которые за счёт работодателя будут изучать для себя новый стек. Звучит как плохая идея для бизнеса.
В целом большая часть разработки строится на том, чтобы не повышать сложность проектов всеми силами, чтобы вхождение новых людей в проект было максимально быстрым. Иначе проект умирает.
Так можно рассуждать, если проект делается для себя - как хочу, так и ворочу.
Если мы делаем полезный тул для рынка и хотим конкурировать с существующими инструментами - мы должны ориентироваться на особенности рынка.
Если большая часть рынка - фритуплей и инди, мы должны позаботиться о разработчиках фритуплея и инди.
Это не мешает стремиться к разумному/доброму/вечному и рекламировать себя как самые последние рендер технологии.
Как минимум несколько решений этого движка были выбраны разумно - опен сурс (это безопасность определенного рода), база в виде существующего движка (это говорит о вменяемости авторов, готовых ехать, а не шашечки), заявленная мультиплатформа (конкуренция существующим решениям), пусть первый шаг и PC
Да нет, логично делать плюсы первыми, если сами библиотеки написаны на плюсах. У меня больший вопрос к тому, почему вторым оказался Lua. Не, может его легче добавить, ввиду особенностей, но грёбанный Lua блин...
половина от чего? 10000 разработчиков С++ против 5 млн на C#+Unity? Первые торчат в ААА компаниях, а остальные и есть остальные. Если вы работаете в ААА компании, то вы и не знаете про остальных.
И половина из этой половины пишут игры на blueprint
В анриле на плюсах пишут единицы, а большинство программирует мышкой на блюпринтах. Потому что плюсы это неудобно для игровой логики
Ну, это смотря что называть игровой логикой. Скажем, игровые механики, особенно сложные и "тяжёлые", может оказаться проще и удобней как раз на це++ делать, чем пытаться скриптами их реализовать. А вот простенькие реакции на, грубо говоря, обшаривание очередного сундука на скриптовом языке и сделать проще, и не потребует долгой и нудной перекомпиляции при каждом изменении...
А вот что в унрыле нет нормального скриптового языка -- это, как по мне, здоровенный минус. Блюпринты для сложной логики неудобны.
Как разработчик на Unity в СНГ, вопрос, почему надо таргетить именно Unity и СНГ?
Даже если мы берём Unity как самый популярный движок по миру, любой ААА движок это всегда C++, самый популярный скриптовый язык среди геймдев плюсовиков это Lua, так что на мой взгляд отличный выбор.
Если ориентироваться на популярность, то скриптовым языком надо добавлять Python или JavaScript, но ориентироваться надо не на вакансии. Движок должен быть ориентирован на целевую аудиторию (не самую широкую из возможных) и использовать соответсующий инструментарий.
К тому же как с Godot, можно прикрутить любой язык, так что C# на стороне скриптинга мы тоже в последствии увидим.
Потому что у dotnet большое игровое и не игровое коммунити. Потому что dotnet производительный и гибкий
Ага, а ещё dotnet нормально работает только на WIndows, рынок которой находится на закате.
dotnet нормально работает везде.
Ваша информация опоздала лет так на 15
Во-первых не везде, как минимум под Linux всё, что на дотнете работает как Г. А во-вторых тащить в движок мусор в виде всего фреймворка dotnet, завязанный на инфраструктуру Microsoft, которая саботирует всё, что связано с нашим рынку, в угоду инвалидам умственного труда, которые не могут освоить примитивный LUA, используемый в чёртовой прорве игровых движков и даже во всяких Roblox'ах - шаг неразумый. Я рад, что разработчики не пошли по этому пути.
И потому что dotnet имеет реализации не только c#, но и lua, и питона, и js, и чего угодно можно сделать работающим в clr и использующим инфраструктуру dotnet
Причём тут c++? Речь про Lua. На нем пишут в снг два с половиной человека. Таргетить на него это потерять кучу аудитории и рисковать судьбой движка в целом. Крайне странное решение менеджмента. Впрочем, сейчас это звучит как просто форк дагора без чего либо еще...
Даже если мы берём Unity как самый популярный движок по миру, любой ААА движок это всегда C++
Так nau engine это не ААА движок. Это наше импортозамещение и вроде как он должен ориентироваться на нужды российских разработчиков. Много в России ААА игр выводит? Поэтому я соглашусь, что логичнее было бы начать именно с c#
>основное написание пользовательского кода предполагается средствами языков C++ (для всех систем движка) и Lua (для основных функций и систем)
запахло нафталином или чем там пахнет прошлый век
UE4, UE5, Unity3D на C++. Где же прошлый век-то?
Скриптинг - это уже отдельная тема. Впрочем, LUA себя хорошо зарекомендовала, как скриптовый язык (особенно для игр), и имеет низкий уровень входа. Похоже, в комментарии к этой статье подабежали M$-дрочеры, коих старательно плодили универы в РФ, получавшие вкусные откаты от M$.
В Unity пользовательский код на c#, причем даже сложный где требуется высокая производительность. Сами юнитеки многое стараются писать на удобном C# вместо cpp, и придумывают даже для этого суперхитрые компиляторы типа burst
В Unreal приходится колоться об плюсы, да. Так как там нет нормального языка для игровой логики. Но зато там геймдизайнеры чувствуют себя комфортно программируя мышкой (в юнити, кстати, тоже можно так)
В поделке от ВК же теперь предлагается либо колоться об плюсы, которые неудобны; либо использовать LUA, который и для программистов неудобен, и для геймдизанеров. А раньше предполагалось использовать c#, то есть как минимум программисты были бы довольны.
LUA себя зарекомендовал как средство для примитивных скриптов, когда ещё ничего нормального не было придумано либо в те времена на что-то удобное не хватало ресурсов. Низкий уровень входа нивелируется примитивностью языка и слабой инфраструктурой.
Похоже в комменты понабежали деды из 90х, которые игр никогда не делали, только модики для WoW и другого раритета.
Кстати, чему надо было учить в вузах? Во многих вузах учили бесполезным паскалю (или делфи), бейсику, а если повезёт то уже учили писать на c или cpp. Чтобы учили c# или java должно было уже сильно повезти
Впрочем если хочется dotnet, то есть и так куча движков, кроме юнити, и в кое чем даже лучше юнити
Быстро можно вспомнить stride engine (open source) и everengine, а так чуть ли не каждый год новый движок на дотнете или с его поддержкой появляется (:
А почему, взяв за основу Dagor, не стали брать daScript в качестве скриптового языка? И в целом в статье не хватает причин выбора тех или иных библиотек вместо альтернативных. Почему gainput, а не SDL? Почему Dagor, а не sokol/bgfx/theForge и т.д.? Из-за лицензий или были какие-то другие причины?
За саму тему плюс, но отсутствие C# который не только Unity но еще и Godot и поддержка только Windows заметно расстраивают, буду надеяться что это все временно.
Изначально заявлялось о модульности движка. Закладывается ли на будущее возможность подключения альтернативных рендера, физики и т.д.?
А для меня наоборот плюс, вернее два плюса, что в качестве основного языка для написания пользовательского кода выбрали C++, а не C#.
Хорошо что не стали брать C#. А-то сидеть по 20 сек с перекомпиляцией при небольшом изменении кода в Unity вымораживает. Да и бинарник + 10мб на mono не будет раздут. А lua идеально подходит для скриптинга - максимально быстрый интерпритируемый язык на котором и сложную логику можно писать. А если совсем уж bullethell игра, то с++ рядом. Короче одобряю такой выбор.
Скрытый текст
Ну как так то, 100$ на code sign зажали?
1) C++ в 2024 - это мягко говоря устарел, тем более в коде движка. unity уже 10 лет от него с трудом избавляется. Это сразу ставит крест на кросс-платформености, производительности и быстрой компиляции.
2) Нет поддержки .Net, - это как вообще? Lua - устарел 10 лет назад. Движок обязан быть мультиплатформенным и без тупых скриптов. Кому вообще нужен ECS на Lua?
3) Нулевое копирование лучших решений с unity. Никто не будет от них отказываться. Исходники unity несложно достать, но ковыряться в c++-легаси никто не хочет.
4) От движка требуется лишь одно - быстрый, удобный, и полностью кастомизированный ui.
5) Render Pipeline - те же грабли что и у unity. Где низкоуровневый доступ? Где ComputeShader?
6) Где демо-игра? Если команда движка не делает игру на нем, то она не понимает что движку нужно.
7) Движки теперь может написать любой школьник. Реализовать и внедрить сторонние технологии - дело месяца. Весь нужный графический функционал реализован в dx11, архитектура остальных api подобна. Основная сложность - готовые для продакшена и рабочие тулзы, гибкий ui, горячая и мометальная компиляция кода и шейдеров на лету.
1) C++ в 2024 - это мягко говоря устарел, тем более в коде движка. unity уже 10 лет от него с трудом избавляется. Это сразу ставит крест на кросс-платформености, производительности и быстрой компиляции.
Предлагаю движки писать на питоне, отличная тема.
4) От движка требуется лишь одно - быстрый, удобный, и полностью кастомизированный ui.
А, C++ в топку, но нужен быстрый. Что возьмем, C#/Rust/Python )?
7) Движки теперь может написать любой школьник. Реализовать и внедрить сторонние технологии - дело месяца. Весь нужный графический функционал реализован в dx11, архитектура остальных api подобна. Основная сложность - готовые для продакшена и рабочие тулзы, гибкий ui, горячая и мометальная компиляция кода и шейдеров на лету.
Хм, мы то идиоты год систему частиц внедряли с переписыванием всего рендера. Надо было школьника попросить что б за пару недель это сделал. dx11 кстати топ тема, предлагаю на нем в linux разработку вести.
Unity в действительности может отказываться от чего угодно. Что последнее на нем выходило на ПК кроме индюшатины разной степени упоротости? Движок чисто под мобилки заточен.
Nau Engine: взгляд под капот. Ядро движка