Я не gamedev, я разработчик на c/c++. В основном занимался разработкой под встраиваемые системы и низкоуровневым программированием. И для меня все эти ваши блюпринты выглядят как самый настоящий ад. И намного проще всё сделать именно в виде кода на c++. А c++17 и выше позволяют писать почти в стиле скриптового языка.
6:25 Что же случится дальше при нулевом указателе? Может быть краш? Не пробовал проверить? Это такой же, далее тупой вопрос из разряда "Почему, если я вышел за пределы массива моя программа получила критическую ошибку?". Движок UE это набор шаблонов пользовательских типов данных, которые любой программист, когда учит с++ пишет сам, просто в UE их уже написали и деструкторы налажены таким образом, что бы отслеживать незарегистрированные указатели в цепочке наследования. Ошибки можно увидеть при компиляции из IDE, для этого достаточно снять галочку с Live Code и в visual studio нажать alt+b. Ошибки макросов UPROPERTY и других, не показывает. Одним словом если написал не правильно EditEnywhere как я написал вместо E нужно A / EditAnywhere, то ошибки не будет показывать IDE. Для логов UE_LOG используют GEngine->UE_LOG... ведь GEngine можно проверить. Одним словом UE это те же правила с++, те же возможности с++, так же обратная совместимость с с++ (ведь переписать их класс можно под себя). Минус только в другом языке(Английский и их сокращения). Привыкнуть можно к этому со временем. У меня комп не топ, зеон 2670v3, 48гб оперативки и 1070ti, дешманский ssd на 512 с али и я больших проблем не ощущаю. Как при первом пуске, так и при последующих пусках анрила. У меня стоит анрил открытого исходного кода, 200гб занимает. Анрил запускается в режиме Development edit вроде так, а не debug. Так же не стоит забывать, что блюпринты использую библиотеки которые тебе не нужны, а может и нужны, но проверять ты их будешь всегда. В с++, этим распоряжаешься ты, если нужны сферы то их нужно подключить, нужен ИИ подключи 2 библиотеки, нужен статический мешь, то подключай и тд. По поводу своих блоков в UE для БП, это же есть и так, для членов это UPROPERTY(), а для методов это UFUNCTION(). Затем пользуешься своей писаниной в БП, а если наоборот, то нужно лезть в движок искать их функцию и вводить кучу параметров(кроме определенных уже). Так же обрати внимание, что все эти минусы с управлением памяти дают возможность самому контролировать процесс разработки, так же все фишки с процессорным распределением ресурсов остались так же, ведь это помогает тебе делать огромные миры и множество объектов, а не как в юнити игру размером с комнату где уже плохо движку. Сам посмотри на этот счет из представленных существующих проектов обоих движков. Я прямо не спец конечно, но что знаю описал.
А как создавать огромные миры? И можно ли условно создать планету таким образом, что это по сути что-то в духе квадрата, но когда ты преодолеваешь верхнюю границу мира в море условно, то оказываешься в нижней части карты со стороны моря. Без прогрузок. Чтобы даже видно было с верхней части карты пейзажи с нижней. В целом примерно как работает телепорт в Портал 2, только огромный бесшовный телепорт по краям карты.
@@Хакод По сути границ нет в подобной логике. Написать можно очень многое, главное найти этому применение. Обычно упираются в визуал(графику красивую). Ну я обычно сталкивался с притиркой кода и мешей с анимациями, что бы они работали в нужный момент, когда воспроизводятся. Как пример самый простой в понимании, это боевая система или другие взаимодействия. Анимаций много как правило. Это не говоря о какой нибудь процедурной анимации или процедурном взаимодействии, где могет быть проблемы не явные. По этому если придумывают, что то в подобном роде как ты описываешь, нужно определять заранее силы. Проще говоря как в этом мире ты будешь все это дружить вместе, так как законы не стандартны в простом понимании.
@@shandy6113 меня интересует именно сама реализация, чисто технически. Вот мы в верхней части карты, далее - ничего нет. Мы создаём условный "Коннект" этой верхней части карты с нижней таким образом, что у игрока при достижении верхней части карты банально просто дальше по горизонту прогружается нижняя часть карты и так можно бегать бесконечно, имитируя тем самым планету. Суть вопроса в том, возможно ли это, и если да, то возможно ли это сделать совершенно не влияющим на нагрузку как самого движка, так и клиента игрока.
@@Хакод Я не думаю, что тебе кто либо в комментариях напишет реализацию, которая сходу тебе подойдет целиком. Опять же повторюсь, это написать можно. Скорее всего через отдельный самописный плагин для твоей планеты и взаимодействием с ним остальных актеров. Я такого не пробовал делать, но как правило в анриле все делают на плоскости. Так что переписывать движок придется.
@@shandy6113 а чисто технически, просто карта в тысячу на тысячу километров будет очень тяжёлой сама по себе даже пустой? Анриал способен работать с такими размерами игрового мира? Или движок даже пустым начнёт уже пыхтеть?
Я привык избегать по максимуму С++ в UE в своих проектах, но на работе всё-таки приходится использовать, ведь масштаб проекта иной. Всё, что можно, всё на Блюпринтах, если острая необходимость на плюсах, то на плюсах. Сочетание обоих инструментов - это залог успешной разработки.
Я сначала подумал автод дурачек, и просто не слышал про оптимизацию. Что можно при необходимости выключать встроенные неиспользуемые методы. А потом увидел интерьвю с Сакутиным, где они продают его курсы по юнити и все встало на свои места...
@@DecembristITTV Ну, в vs2022 это делается - включив режим debug, тогда конечно нужно будет ждать запуск движка. Я один раз даже не понял, почему вместо значения об ошибке из vs с неправильным значением, у меня какая-то ересь с памятью, а потом вспомнил, что я движок запустил отдельно. Изменено: у меня оказывается режим Development какой-то там
Делаю две игры сейчас (сетевую и однопользовательскую) чисто через Блупринты. C++ уже забыл. И надоел он уже давно МНЕ. Очень сложную игру делаю (и одну менее сложную). Но ничего не тормозит! Процессор i3 9000 и 4060 видюха. Меня всё устраивает. Unreal Engine это просто прекрасно. Люди могут делать сложные игры без команды и быстро! Такого не было 15 лет назад! Я о**уительно рад тому, что люди могут сами делать игры свои! Короче, просто очень рад:) 😂🎉 Очень сильно не согласен 14:45 Скорость чтения блупринтов выше, чем скорость чтения кода в 2 - 4 раза. А скорость написания - ещё выше... В целом игры делать быстрее. Но я делаю эти игры 24/7 и НАИЗУСТЬ знаю где у меня что в "коде" блупринта. Мне ничего ИСКАТЬ не надо. Я помню где-что.
Вот такие дегенераты больше всего бесят в коммерции. "Я всё знаю наизусть", "мне удобно", "пишу БП в 2-4 раза быстрее, чем плюсы". У меня к тебе ряд вопросов: 1) что будешь делать, если кто-то другой внёс важные изменения в твой блупринт и залил в скв, а ты тоже дофига сделал. Как будешь соединять воедино обе пачки изменений? 2) если есть блупринты, в которых дофигище методов и логики, по несколько графов, много переменных, то как ты будешь в них искать что-то конкретное, если ты точно не знаешь, в каком именно блупринте находится функционал, который ты ищешь. Как ты его найдешь? Документации нет, а времени мало. 3) твои макароны начинает модифицировать человек, который не знает тонкостей работы execution flow, в следствии чего не понимает, что delay в одной из веток then не застопорит последующие и т.п. приколы с другими макросами, конструкциями и асинхронными методами. В итоге ловишь кучу багов, но разбираться и исправлять надо тебе. Поскольку функционала тьма, то не факт, что понятно, где именно поменяли логику таким образом, что всё сломалось. А разобраться надо быстро. А у тебя есть diff только для блупринтов. Сравнивать другие uasset'ы ты не умеешь.
13:51 Ну мне интересно, а почему вы не показываете удачные примеры организации блюпринтов? Реально показать человеку который с этим никогда не работал это покажется макаронный ад. Но разве UE не дает возможности это все структурировать. К примеру это можно свернуть в блок либо вынести в функцию или макрос. Понятное дело, что если все лепить в кучу и просто подписывать это комментариями, то это будет ужас. А если у тебя все распределено по функциям(получение урона, движение и т.д.) то по сути у тебя огромный блок нодов просто сворачивается и превращается в один, который принимает значение и возвращает. По поводу того что это читать сложно, да это сложнее чем читать код, но по большей части для людей, которые к этому не привыкли и непонятным образом все организовали. Хотя я буду согласен, что если мы возьмем 2 человека один который пишет код, а другой который использует блюпринты и там у обоих хорошая понятная структура, то в коде разберешься намного быстрее. По поводу того что сложно искать код и редактировать это не правда. Как вы показали блюпринты достаточно удобно подсвечивают ошибки, а по поводу того что сложно редактировать, так опять же возвращаемся к самой организации проекта, если у вас блоки кода разбиты на функции по типу "Получение урона" и у вас проблемы со значением, то что вы делаете правильно открываете Blueprint (Function, Macro) Library далее функцию получения урона и там редактируете. Ну если у вас вся игровая логика зашита непосредственно в классах, персонажа, врага и т.д. то да это проблема. Ну Эпики очень много сделали для того чтобы ты мог организовать все как тебе удобно. Ну а если этого мало то полно расширений которые еще больше помогают все организовать.
@@DecembristITTV Да, полностью согласен. Это действительно лучший visual scripting. Ваша идея очень хороша в плане того чтобы код преобразовывать в визуальные сценарии и наоборот. Я думаю это было бы актуально не только в UE но и как отдельный язык программирования. Я работаю в сфере Data Science я хорошо знаком с программированием и так же работал с No code решениями которые многие хейтят. И могу сказать no code в некоторых случаях очень хорош особенно тем что ты можешь взять планшет и одним пальцем набросать небольшую автоматизацию. Это конечно не так актуально как код. Но если бы такой язык был это было бы очень неплохо и если бы была возможность еще переводить визуальные сценарии на любой язык думаю это был бы интересный инструмент. Накидал визуально сохранил в нужном формате потом скомпилировал и все или запустил через интерпретатор.
Ну такое. Лично у меня УЕ С++ был первым языком программирования. За пару лет привык, ошибок почти нет. Свободно пишу код как на БП, так и С++, иногда переписываю туда-или обратно, если стоит такая задача. Сложный спагетти код это скорее признак анскила. Потому что даже на БП можно писать изящно. На С++ с одной стороны писать чуть сложнее, но с другой- сейчас есть ЧатЖПТ, он может писать куски кода, тесты, проверять ошибки, что ускоряет работу.
Здравствуйте, где учили анрил с++? Есть что то подробное по нему от А до Я? Документация анрила это конечно плюс, но она нифига не понятна. Заранее спасибо.
@@shandy6113 советую начать с практики. Взять любую серию уроков и повторять за автором шаг за шагом. Через полгода примерно придет понимание что где лежит. Документация вам не понятна, потому что не понимаете принципов ООП и устройство движка. Это придет со временем. Главное делать практику. Если не понятно, закрывать урок и искать другого автора, у которого понятно.
@@Poloskun4ik Я понимаю принципы ООП, я не понимаю английский к сожалению)) Некоторые методы имеют ряд параметров которые не понятно откуда брать. Как я понял, эти методы из БП. Мне как бы примерно понятно, что происходит в коде, но из-за реализации их классов другими людьми не совсем понятны тонкости которые я могу использовать. Опять же встает вопрос, я использую то или нет и есть ли альтернатива в некоторых моментах. Ну я даже почувствовал будто я с++ заново изучаю, только в этот раз я понимаю синтаксис)) Иногда даже зависаю на некоторых легких ситуациях из-за не понимая, что я получаю и куда это передать)) В движке когда лазил вроде как в классе актера или в срр физики, нашел комментарий по типу "я не знаю, что это делает, но я оставлю это тут ...". Как я уже писал, в документации не шибко написано про некоторые вещи, да и к тому же про некоторые вещи вообще ничего не написано. )) По этому решил спросить, может есть где то материал который по движку досконально проходится структурировано.
@@shandy6113 я такой документации не видел. А чтобы искать нужные методы и примеры их использования, делал запрос через Яндекс и иногда чатжпт. Когда пишу код с нуля, часто делаю прототип на БП и потом уже переписываю на с++, так проще. Но если в плане разбираться в чужом кода, согласен это трудно.
Проблема геймдева глобально в том что для крупного проекта важен "Редактор" - причем важнее всех остальных частей движка, без редактора ты просто не сможешь связать художников, звуковиков и т д воедино. BluePrint единственный способ усилить эту синергию. Если Эпики и дальше развивали С++, это бы просто создавали команды разработчиков которые потом могут мирно перейти ну кучу других технологий/движков со своими навыками.
4:22 Хз что за конфиг у вашей машины, зеон или селерон, но у меня компил аналогичного примера занимает 0.5 сек, а общее время выполнения LiveCoding меньше 2 секунд.
Вижу сразу, человек не понимает про что говорит "Видно опять программиста который говорит что ++ не подходят" хотелось бы узнать у уважаемого, участвовал ли он в коммерческой разработке чего-то для геймдева, и что бы он сказал например за source 1 собрал ли бы он его и посмотрел на код структуру движка и так далее и вот тогда говорил бы что такое движок и плюсы, так еще не известно какое железо ЧТО ДОЛГО ЗАГРУЗЖАЕТ:/ к остальному вопросов нет
Оба предложенные варианта - ерунда. Свой язык, это полная утопия. А парсинг блупринтов, это дополнительная головная боль разработчика и усложнение пайплайна. И если для больших студий это еще худо-бедно допустимо (но зачем им оно, если им проще нанять дополнительно C++ девелопа), то для инди это просто будет непонятный атавизм. На мой взгляд, нужно идти другим, более адекватным путем - взять все лучшее от скорости компиляции и удобства графических форм, и при этом развить их в максимально удобный формат "сверху вниз - слева направо" (это если простым языком). Наиболее здраво к этому уже как ни странно приблизились разработчики движка Construct 3. В их визуальной системе используется такой подход. Он не идеален, и там тоже есть что улучшать, но вектор правильный. Из всех систем визуального программирования, пожалуй только их система не вызывала ломки при переходе от написания кода к визуалу. Если и говорить об улучшении для UE, то нужно упрощать и делать удобней, а не наворачивать сверху дополнительное, и уж тем более не изобретать аж целый велосипед в лице языка. И конечно, это мое скромное имхо, но я уверен, что работающие с движком меня поймут.
как по мне - в идеале еще одна кнокка на БП - траслировать с спп файл и все. А если еще и наоборот ил спп в БП - прям сказка была бы. Этим бы решалась и проблема с вершион контрол
@@user-dzimka а в чем проблема сделать cpp в БП? Если я правильно понимаю, то ты пишешь про блоки БП которые можно писать в cpp файле, а затем вызывать их в БП. Если да, то их можно было всегда писать, а иначе как по твоему они написаны?) UFUNCTION (), UPROPERTY () тебе в помощь и макросы. В обратную сторону это тоже работает, но как правило необходимо писать все параметры метода начиная от актера и заканчивая цвета предмета, а те что стоят по умолчанию(определены уже) можно опустить.
да, там даже и ьез ошибок он вылетает, если много вкладок открыто и там где обычно не вылетает, при каких 2-3 вкладак даже открытых спецыфичных он вылетает. поэтому после каждого редактирования блупринта или ассета нужно его сохранять, даже перед компилированием, а то и при компилировании может вылетить или зависнуть и пр деться насильно закрывать... очень багован наверно можно счказать и эти баги тянуться годами от 4,25 версии, когда п5рвый раз начал изучать унреалэнджен... Какоето несерьезное отношение к багам, кряшам, но зато видемо позволят быстро всякие новые функции внедрять и быстро разрабатывать движок. ну и бесплатный, так что приходиться терпеть и быть благодарным, дареному коню в зцбы не смотреть... хотя временами бывают мысли перейти на годод или унити. но в унити мне политика не нравиться, что с твоего заработка нужно денги отдавать юнити. а в унриле до определенно количества денег, ничего не надо платить унрилу, както меньше суеты и волоки по моему. и на юнити с шарп, не хочеться много времени терчть на его изучение. уже на унриле много научилься на блупринтах и всякого. ну и размер игры слышал что в юнити тоже намного меньше... но это как хоби, был бы разработчик серьезный, то может бы на юнити перешел. и на унриле я могу зделать одну игру и для андройда и для виндовс несильно изменив ее. не знаю или на юнити такое возможно...
Про дебаг плюсов не понял. Что значит не узнаете значения переменных в дебаге? Из студии в дебаг режиме можно все значения переменных посмотреть, их типы и адреса в памяти.
@@DecembristITTV может в каких то случаях это бывает (хотя я реально очень удивлюсь если это так), но я ни разу не сталкивался. На работе сейчас много дебажить приходилось и никогда ничего подобного не было, за исключением случая, когда я случайно попытался дебажить в режиме релиз ) Ещё может быть не скачаны дебаг символы анриаловские? При установке он спрашивает качать или нет.
я на c++ написал несколько программ для виндовс. и мне тоже не понятно от куда некоторые ошибки возникают. но я почти все на блупринте делаю. казалось должен быть как рыба в воде на с++, но я не с визуал студио работаю и не игры пишу, а windows api использую, если правильно назвал, со звуком, с виндовс интерфейсом, видемо действительно это не тот с++ в унреал энджене...
Ты сравниваешь C# и c++? Во втором же компилируется всё, а в C# компилирует в CL и потом интерпретирует, он не будет всё пересобирать если модули не связаны
Какое дно пробито?), если поможет почему не пользоваться, хотя мне лично не кажется удобным. Твое мнение это только мнение, даже если тебе кажется, что тебе этот мир абсолютно понятен, братишка)
@@DecembristITTV Ужас, они даже в анрил интегрировали этот вонючий джаваскрипт, позор. Javascript объективно плохой язык для серьёзного программирования.
Вообще то когда-то давно выбирали не движок, а библиотеку для какого-то языка. Но тогда, давным давно - чтобы приступить к разработке самой игры - нужно было сначала пройти через все тернии по изучению графической библиотеки. А крупные компании делали свои собственные библиотеки, которые разрастались, разрастались, обрастали всякими редакторами и визуальными инструментами и в итоге получался "движок", на котором игру должны были делать уже не программисты а дизайнеры. Вообще странно и совершенно непонятно, что мешает Эпикам сделать как опцию текстовый формат работы с блюпринтами, по идее - ничего принципиально сложного для них в этом нет. Для программирования на мой взгляд блюпринты ну совсем неудобны по причинам, которые упоминаются в ролике: 1. Нет привычного форматирования сверху вниз. Для чтения кода обычно достаточно прокручивать вверх-вниз, F12 для перехода к месту объявления переменной, метода, класса. 2. При большом количестве связей и переменных визуальное программирование превращается в трудно распутываемый клубок. 3. При чтении текста кода легче находить места интереса, легко искать по именам методов, переменных, любым текстовым данным. 4. Инструменты рефакторинга кода позволяют быстро выделять нужные куски кода в отдельные функции и методы - это привычное удобство, которого нет в блюпринтах из за визуального редактора.
Потому что нет экспорта на все платформы, и потому что эдитор не умеет мапить ивенты на си шарп классы, + не все си шарп апи работают, например в работе с асинхами. Ну и в общем то как надо работать с си шарп кодом больше похоже на костыль приставленный к основному языку.
@@DecembristITTV всё что ты описал кроме экспорта легко решается самим кодом на шарпе, для этого не нужна специальная поддержка движка. Есть фреймворки на гитхабе от студий использующих godot где всё это и многое другое уже решено. C# более полноценный язык чем gdscript, его базовые фичи позволяют сделать любой api и стабильно работающую кодогенерацию в два счета
Ну ты спросил почему поддержка неполноценная, Я ответил, ты подтверждаешь своим ответом что поддержка менее полноценная. И что нужны дополнительные усилия. Никто не говорил что поддержка 0вая и тем более что C# в сравнении с гд скрипт в вакууме проигрывает Экспорт это значительная проблема.
Они мнего чо обещают но это всегда затягивается. А дружить эти фреймворки от компаний не надо усилий приложить? А изучать их дополнительно? Все должно из коробки работать как в гд скрипт, не понимаю зачем с этим спорить.
как по мне, свой язык для движка звучит как дичь лучше всегда брать существующий и адаптьировать его под движок у существующих языков уже есть комъюнити, уже решено много болей, уже есть какая- то инфраструктура и тд например тот же JS отличный язык для скиптовой логики так же с ним посоперничать может lua, но по кол-ву инструментов, инраструктуре и комънили это кончно пропасть
Ну на Анрилке по сути дела кастомный С++. То есть от плюсов там только базовая база (синтаксис). А все остальные библиотеки там анриляшные. Поэтому смена языка может пройти почти незаметно.
В UE самый настоящий С++. Не нужно слушать всяких проходимцев, которые не открывали движка. Чтобы в этом убедиться, достаточно скомпилировать Unreal в Visual Studio. Свои собственные реализации структур данных, не говорит, что язык там другой.
Какой же ты навязчивый гражданин, слушай а в самых настоящих плюсах тоже сборщик мусора свой есть? Я так понимаю у тебя рекорд Гиннесса по количеству открываний движка?)
@@Alex_Veresov он то настоящий, но по сути у тебя фреймворк построен вокруге. Никто не говорит о том что это не плюсы. Просто объясняется, что там много чего сделано для того чтоб лишний раз себе колено не отстрелить.
@@Alex_Veresov самый настоящий да. С самым настоящим стилем середины-конца 90х, кто диды - помнят такую дичь как MFC для гуя и ATL для COM-объектов - вот с такими же волшебными кулхацк-макросами на сишных дефайнах. Когда в первый раз начал изучать тему - из документации и туторов аж родным вижуал студио 6.0 нафталином пахнуло)))
Современные версии языка c++ позволяют почти полностью обойтись без использования указателей. А большая часть проблем - это проблема кривых рук и плохого знания инструмента с которым работаешь.
@@Alexander_Gurov_RF анрил компилируется при минимально 17 стандарте и вроде как поддерживает 20, но прикол в том что использование std в рамках анрила считается плохой практикой. Обычно все нужные фичи внедряются отдельно в движке, для лучшей связки с ним же. Банальное smart pointers у UE свои.
Может быть юнити компилируется быстрее потому что это не та компиляция, что на C++? Может быть он компилируется быстрее потому что там JIT компиляция? Что всенепременно потом сказывается на производительности в рантайме.
В рантайме все компилируется в машинный код там. Для ААА студий мб производительность рантайма, с которой +/- все нормально и у других движков, может иметь решающее значение, но мне как индюшатнику надо быстро прототипировать мочь, чего не получается с плюсами сейчас.
Чел, ты выдал базу, а токсичных ущемленцев ниже в комментах не слушай. Все эти проблеы в плюсах более чем реальны. Язык потихоньку движется к меньшему времени компиляции, новая система модулей появилась. Но это будет происходить долго. Ну как обычно в С++. Всё равно в языке и хороших сторон достаточно. Просто для каждой задачи нужен свой инструмент. Поэтому у каждого движка и есть свой язык. Зато в UE высокая реалистичность, и, думаю, она была достигнута именно благодаря плюсам и сложным алгоритмам и большому числу оптимизаций сделанных с помощью плюсов. Я сам программирую на плюсах, со временем хочу перейти на другой язык, а пока что мой фреймворк позволяет программировать достаточно комфортно, и в целом это распространенная практика, что пробелы плюсов заполняют сами фреймворки. Плюсы - это вообще опенсорсный свободный проект, и всё наиболее крутое надо искать во фреймворках, созданных крупными коммерческими компаниями.
@@DecembristITTV зато они быстрые и производительные. За это мы и любим Unreal. А плюсы, на мой взгляд, не удобны для всего. Если их можно не использовать - лучше не использовать.
@@DecembristITTV Держи, бро. Только руки дошли, помню про тебя Building Cpp1Editor... Using Visual Studio 2022 14.39.33523 toolchain (------) and Windows 10.0.22621.0 SDK (------). Determining max actions to execute in parallel (14 physical cores, 20 logical cores) Executing up to 14 processes, one per physical core ------ Building 1 action(s) started ------ [1/1] Compile [x64] MyActor1.cpp Total time in Parallel executor: 0.34 seconds Total execution time: 0.82 seconds File -----.obj was modified or is new Building patch from 1 file(s) for Live coding module -----.dll Creating library -----.exp Successfully linked patch (0.000s) Patch creation for module -----.dll successful (0.000s) ---------- Finished (0.000s) ---------- Accepted Live coding shortcut ---------- Creating patch ---------- Running -----.uproject""" -LiveCoding -LiveCodingModules="-----.json" -LiveCodingManifest="-----.json" -WaitMutex -LiveCodingLimit=100 Using bundled DotNet SDK version: 6.0.302 Building Cpp1Editor... Using Visual Studio 2022 14.39.33523 toolchain (-----) and Windows 10.0.22621.0 SDK (-----). Determining max actions to execute in parallel (14 physical cores, 20 logical cores) Executing up to 14 processes, one per physical core ------ Building 1 action(s) started ------ [1/1] Compile [x64] MyActor1.cpp Total time in Parallel executor: 0.30 seconds Total execution time: 0.71 seconds -----.obj was modified or is new Building patch from 1 file(s) for Live coding module -----1.dll Creating library -----.lib and object -----.patch_1.exp Successfully linked patch (0.000s) Patch creation for module -----.dll successful (0.000s) ---------- Finished (0.000s) ----------
Эта фраза абсолютно понятна носителю языка, так говорят все, есть ещё куча таких фраз. Если ты зашел сюда поумничать, то ладно, признаю, ты очень умный. Больше так не делай, спасибо.
@@DecembristITTV этого недостаточно. Требуется, чтобы люди говорили правильно. Я сюда зашёл посмотреть про UE, скоротать время, отдохнуть немного. Но просмотр был испорчен плохими комментариями к действиям.
не досмотрел до конца , но так скажу что hot reload и live code мало кто использует , обычно проект перекомпилируется через ide что занимает 10 - 15 секунд
блупринты позволяют какбы избегать ошибоки кряшов в игре, хоть и не полностью. говорят еще что они медленее чем код, особенно математические вычесления. но если простенкая игра то там особо не важно чуть быстрее или медлене будет выполняться и больше или меньше чуть загружаться процесор. На андройде если какихто сложных симуляций нет, то ничего у меня не лагает на поко икс 3 нфс на нативном разрешении, не уменьшеном.
Как ни крути Unity не получилось превзойти UE в больших проектах, рассматривать запуск проекта, как то глупо ) Главное в другом, это вход в движок, вход по росту скилла, он гораздо лучше, быстрее в игре, больше держит контента, многое прощает, красивее, все с коробки, это и есть будущее, программисты не так сильно могут включить зависимость от себя, теперь это все не так сложно.
Глупо игнорировать минусы вместо того чтобы о них говорить. Я говорю о конкретных проблемах связанных с кодированием. Когда движок крашится на ошибку в игровом коде, а в других движках такого нет это значимая проблема. Особенно в контексте скорости запуска. Попиши на плюсах, будешь вечно смотреть на загрузочную плашку. Игнорировать прогеров и их подходы можно, однако если над проектом будет работать больше 1 человека начнутся типичные проблемы с этим связанные
Анриал топ, даже со своими ошибками и приколами, графика топ, куча методов оптимизации, куча настроек для оптимизации движка и там даже можно сделать один проект на двоих человек и у меня компилируется все меньше чем за 200 мс
По читаемости это объективная правда. Но скрипт как альтернатива типа Версе тоже такое себе).@@DecembristITTV Как вариант претензия Эпикам основная и ты ее упомянул это запутанная трасировка и трактовка Acces Violation для 99% случаев ошибок новичка в UE). И да она конфузит только новичков которые не могут локализовать проблемное место в коде и определить конкретную причину по всему call стеку.
запускай стедлон, если хочешь что бы движок не падал( но есть ли смысл???), повторные запуски проекта обычно быстрее. Цена обработки исключений слишком большая, что бы их использовать в игровом движке.
1. Интересный заход про то, что языки не выбираешь. C#? Unity. Java? Libgdx. C++? Unreal + треть гитхаба самопальных. JS/TS? Defold/Cocos Creator. Rust? Bevy. Just4Fun можно юзать Go с каким-нибудь g3n (только загуглил). 2. "В Unity нет альтернативы. Там только C#." Unity Bolt: я что, шутка для тебя? Либо смеха ради ставь бородатые версии, до v5. Там вообще 3 языка: C#, JS и Boo (что?). 3. Анрил с крестами вообще не трогал. А если код с ошибкой в try/catch и выводить messege и call stack в лог. Отработает?
1. Я сказал, ты выбираешь движок а не язык, возьми подпиши на Java в Unity например, можешь? нет. 2. Болт это кусок говна, change my mind, то что там когда то было не вижу смысла обсуждать, было и было. 3. Отработает, тока try/catch там не приветствуется, да и все ты на свете в него не обернешь. Там часто ошибки просто из движка вылетают. Без негатива)
Ща нам Тим Свинни завезёт Вёрс и заживём! (Нет). А вообще у анрила свои преимущества перед юничкой. Его зверская строгость дициплинирует и не поучится с тремя красными ошибками и десятком жёлтых спокойно запускать и разрабатывать проект. Приходится следить за тем, что делаешь. Да и блупринт чертовски хорош.
unreal verse 💀💀💀 это показывает общую деградацию эпиков С++ идеальное решение, просто анрил своей рефлексией все портит, да и в принципе это не серьезный движок, сейчас тупа махают хвостом перед инвесторами
Verse изначально был придуман не для разработки игр, а внутриигрового контента от игроков в играх по типу метаверсов. Плюсы всегда останутся предпочтительней
Это звучит как будто человек в детве упал с велосипеда, потом рассказал как это было больно и плохо своему другу, а этот друг потом решил не учится кататься на велосипеде. Все детство этот так называемый друг бегал за своими друзьями на велосипедах, никогда не прокатился по лесу на нем, потерял много ярких событий и в итоге остался один в какой то момент. Потому, что бегать долгое время когда нибудь надоест, а некоторые вещи потом очень сложно переиграть по другому.
Я не gamedev, я разработчик на c/c++. В основном занимался разработкой под встраиваемые системы и низкоуровневым программированием. И для меня все эти ваши блюпринты выглядят как самый настоящий ад. И намного проще всё сделать именно в виде кода на c++. А c++17 и выше позволяют писать почти в стиле скриптового языка.
6:25 Что же случится дальше при нулевом указателе? Может быть краш? Не пробовал проверить? Это такой же, далее тупой вопрос из разряда "Почему, если я вышел за пределы массива моя программа получила критическую ошибку?". Движок UE это набор шаблонов пользовательских типов данных, которые любой программист, когда учит с++ пишет сам, просто в UE их уже написали и деструкторы налажены таким образом, что бы отслеживать незарегистрированные указатели в цепочке наследования. Ошибки можно увидеть при компиляции из IDE, для этого достаточно снять галочку с Live Code и в visual studio нажать alt+b. Ошибки макросов UPROPERTY и других, не показывает. Одним словом если написал не правильно EditEnywhere как я написал вместо E нужно A / EditAnywhere, то ошибки не будет показывать IDE. Для логов UE_LOG используют GEngine->UE_LOG... ведь GEngine можно проверить. Одним словом UE это те же правила с++, те же возможности с++, так же обратная совместимость с с++ (ведь переписать их класс можно под себя). Минус только в другом языке(Английский и их сокращения). Привыкнуть можно к этому со временем. У меня комп не топ, зеон 2670v3, 48гб оперативки и 1070ti, дешманский ssd на 512 с али и я больших проблем не ощущаю. Как при первом пуске, так и при последующих пусках анрила. У меня стоит анрил открытого исходного кода, 200гб занимает. Анрил запускается в режиме Development edit вроде так, а не debug. Так же не стоит забывать, что блюпринты использую библиотеки которые тебе не нужны, а может и нужны, но проверять ты их будешь всегда. В с++, этим распоряжаешься ты, если нужны сферы то их нужно подключить, нужен ИИ подключи 2 библиотеки, нужен статический мешь, то подключай и тд. По поводу своих блоков в UE для БП, это же есть и так, для членов это UPROPERTY(), а для методов это UFUNCTION(). Затем пользуешься своей писаниной в БП, а если наоборот, то нужно лезть в движок искать их функцию и вводить кучу параметров(кроме определенных уже). Так же обрати внимание, что все эти минусы с управлением памяти дают возможность самому контролировать процесс разработки, так же все фишки с процессорным распределением ресурсов остались так же, ведь это помогает тебе делать огромные миры и множество объектов, а не как в юнити игру размером с комнату где уже плохо движку. Сам посмотри на этот счет из представленных существующих проектов обоих движков. Я прямо не спец конечно, но что знаю описал.
А как создавать огромные миры? И можно ли условно создать планету таким образом, что это по сути что-то в духе квадрата, но когда ты преодолеваешь верхнюю границу мира в море условно, то оказываешься в нижней части карты со стороны моря. Без прогрузок. Чтобы даже видно было с верхней части карты пейзажи с нижней.
В целом примерно как работает телепорт в Портал 2, только огромный бесшовный телепорт по краям карты.
@@Хакод По сути границ нет в подобной логике. Написать можно очень многое, главное найти этому применение. Обычно упираются в визуал(графику красивую). Ну я обычно сталкивался с притиркой кода и мешей с анимациями, что бы они работали в нужный момент, когда воспроизводятся. Как пример самый простой в понимании, это боевая система или другие взаимодействия. Анимаций много как правило. Это не говоря о какой нибудь процедурной анимации или процедурном взаимодействии, где могет быть проблемы не явные. По этому если придумывают, что то в подобном роде как ты описываешь, нужно определять заранее силы. Проще говоря как в этом мире ты будешь все это дружить вместе, так как законы не стандартны в простом понимании.
@@shandy6113 меня интересует именно сама реализация, чисто технически. Вот мы в верхней части карты, далее - ничего нет. Мы создаём условный "Коннект" этой верхней части карты с нижней таким образом, что у игрока при достижении верхней части карты банально просто дальше по горизонту прогружается нижняя часть карты и так можно бегать бесконечно, имитируя тем самым планету.
Суть вопроса в том, возможно ли это, и если да, то возможно ли это сделать совершенно не влияющим на нагрузку как самого движка, так и клиента игрока.
@@Хакод Я не думаю, что тебе кто либо в комментариях напишет реализацию, которая сходу тебе подойдет целиком. Опять же повторюсь, это написать можно. Скорее всего через отдельный самописный плагин для твоей планеты и взаимодействием с ним остальных актеров. Я такого не пробовал делать, но как правило в анриле все делают на плоскости. Так что переписывать движок придется.
@@shandy6113 а чисто технически, просто карта в тысячу на тысячу километров будет очень тяжёлой сама по себе даже пустой?
Анриал способен работать с такими размерами игрового мира? Или движок даже пустым начнёт уже пыхтеть?
Я привык избегать по максимуму С++ в UE в своих проектах, но на работе всё-таки приходится использовать, ведь масштаб проекта иной. Всё, что можно, всё на Блюпринтах, если острая необходимость на плюсах, то на плюсах. Сочетание обоих инструментов - это залог успешной разработки.
Если использовать их вместе, то это вообще заебись
интересно, как это можно реализовать
Я сначала подумал автод дурачек, и просто не слышал про оптимизацию. Что можно при необходимости выключать встроенные неиспользуемые методы. А потом увидел интерьвю с Сакутиным, где они продают его курсы по юнити и все встало на свои места...
У меня нет интервью с Сакутиным. Напиши как выключить эти волшебные оптимизации, Я проверю. Потому что фанатиков вдыхающих копиум тут каждый второй
@@DecembristITTV Ну, в vs2022 это делается - включив режим debug, тогда конечно нужно будет ждать запуск движка. Я один раз даже не понял, почему вместо значения об ошибке из vs с неправильным значением, у меня какая-то ересь с памятью, а потом вспомнил, что я движок запустил отдельно.
Изменено: у меня оказывается режим Development какой-то там
Делаю две игры сейчас (сетевую и однопользовательскую) чисто через Блупринты. C++ уже забыл. И надоел он уже давно МНЕ.
Очень сложную игру делаю (и одну менее сложную). Но ничего не тормозит! Процессор i3 9000 и 4060 видюха. Меня всё устраивает.
Unreal Engine это просто прекрасно. Люди могут делать сложные игры без команды и быстро! Такого не было 15 лет назад! Я о**уительно рад тому, что люди могут сами делать игры свои!
Короче, просто очень рад:)
😂🎉
Очень сильно не согласен 14:45
Скорость чтения блупринтов выше, чем скорость чтения кода в 2 - 4 раза. А скорость написания - ещё выше... В целом игры делать быстрее.
Но я делаю эти игры 24/7 и НАИЗУСТЬ знаю где у меня что в "коде" блупринта. Мне ничего ИСКАТЬ не надо. Я помню где-что.
Ну тут надо смотреть как ты пишешь код обычно, но если нраица то я рад, просто есть те кому не нраица 👍
👍
Возможно ты просто не писал на чём-то другом и уже привык к этому, и тебе кажется это нормальным))
А ты попробуй не в одиночку, а командой...
Вот такие дегенераты больше всего бесят в коммерции. "Я всё знаю наизусть", "мне удобно", "пишу БП в 2-4 раза быстрее, чем плюсы". У меня к тебе ряд вопросов:
1) что будешь делать, если кто-то другой внёс важные изменения в твой блупринт и залил в скв, а ты тоже дофига сделал. Как будешь соединять воедино обе пачки изменений?
2) если есть блупринты, в которых дофигище методов и логики, по несколько графов, много переменных, то как ты будешь в них искать что-то конкретное, если ты точно не знаешь, в каком именно блупринте находится функционал, который ты ищешь. Как ты его найдешь? Документации нет, а времени мало.
3) твои макароны начинает модифицировать человек, который не знает тонкостей работы execution flow, в следствии чего не понимает, что delay в одной из веток then не застопорит последующие и т.п. приколы с другими макросами, конструкциями и асинхронными методами. В итоге ловишь кучу багов, но разбираться и исправлять надо тебе. Поскольку функционала тьма, то не факт, что понятно, где именно поменяли логику таким образом, что всё сломалось. А разобраться надо быстро. А у тебя есть diff только для блупринтов. Сравнивать другие uasset'ы ты не умеешь.
13:51 Ну мне интересно, а почему вы не показываете удачные примеры организации блюпринтов? Реально показать человеку который с этим никогда не работал это покажется макаронный ад. Но разве UE не дает возможности это все структурировать. К примеру это можно свернуть в блок либо вынести в функцию или макрос. Понятное дело, что если все лепить в кучу и просто подписывать это комментариями, то это будет ужас. А если у тебя все распределено по функциям(получение урона, движение и т.д.) то по сути у тебя огромный блок нодов просто сворачивается и превращается в один, который принимает значение и возвращает. По поводу того что это читать сложно, да это сложнее чем читать код, но по большей части для людей, которые к этому не привыкли и непонятным образом все организовали. Хотя я буду согласен, что если мы возьмем 2 человека один который пишет код, а другой который использует блюпринты и там у обоих хорошая понятная структура, то в коде разберешься намного быстрее. По поводу того что сложно искать код и редактировать это не правда. Как вы показали блюпринты достаточно удобно подсвечивают ошибки, а по поводу того что сложно редактировать, так опять же возвращаемся к самой организации проекта, если у вас блоки кода разбиты на функции по типу "Получение урона" и у вас проблемы со значением, то что вы делаете правильно открываете Blueprint (Function, Macro) Library далее функцию получения урона и там редактируете. Ну если у вас вся игровая логика зашита непосредственно в классах, персонажа, врага и т.д. то да это проблема. Ну Эпики очень много сделали для того чтобы ты мог организовать все как тебе удобно. Ну а если этого мало то полно расширений которые еще больше помогают все организовать.
Этого лучший visual scripting который есть, просто сам по себе visual scripting не очень удобен бай дизайн
@@DecembristITTV Да, полностью согласен. Это действительно лучший visual scripting. Ваша идея очень хороша в плане того чтобы код преобразовывать в визуальные сценарии и наоборот. Я думаю это было бы актуально не только в UE но и как отдельный язык программирования. Я работаю в сфере Data Science я хорошо знаком с программированием и так же работал с No code решениями которые многие хейтят. И могу сказать no code в некоторых случаях очень хорош особенно тем что ты можешь взять планшет и одним пальцем набросать небольшую автоматизацию. Это конечно не так актуально как код. Но если бы такой язык был это было бы очень неплохо и если бы была возможность еще переводить визуальные сценарии на любой язык думаю это был бы интересный инструмент. Накидал визуально сохранил в нужном формате потом скомпилировал и все или запустил через интерпретатор.
Ну такое. Лично у меня УЕ С++ был первым языком программирования. За пару лет привык, ошибок почти нет.
Свободно пишу код как на БП, так и С++, иногда переписываю туда-или обратно, если стоит такая задача.
Сложный спагетти код это скорее признак анскила. Потому что даже на БП можно писать изящно.
На С++ с одной стороны писать чуть сложнее, но с другой- сейчас есть ЧатЖПТ, он может писать куски кода, тесты, проверять ошибки, что ускоряет работу.
Здравствуйте, а у меня вопрос вы сейчас работаете ил учитесь используя С++ хотеля бы с вами пообщаться немного по этому поводу
Здравствуйте, где учили анрил с++? Есть что то подробное по нему от А до Я? Документация анрила это конечно плюс, но она нифига не понятна. Заранее спасибо.
@@shandy6113 советую начать с практики. Взять любую серию уроков и повторять за автором шаг за шагом. Через полгода примерно придет понимание что где лежит.
Документация вам не понятна, потому что не понимаете принципов ООП и устройство движка. Это придет со временем. Главное делать практику. Если не понятно, закрывать урок и искать другого автора, у которого понятно.
@@Poloskun4ik Я понимаю принципы ООП, я не понимаю английский к сожалению)) Некоторые методы имеют ряд параметров которые не понятно откуда брать. Как я понял, эти методы из БП. Мне как бы примерно понятно, что происходит в коде, но из-за реализации их классов другими людьми не совсем понятны тонкости которые я могу использовать. Опять же встает вопрос, я использую то или нет и есть ли альтернатива в некоторых моментах. Ну я даже почувствовал будто я с++ заново изучаю, только в этот раз я понимаю синтаксис)) Иногда даже зависаю на некоторых легких ситуациях из-за не понимая, что я получаю и куда это передать)) В движке когда лазил вроде как в классе актера или в срр физики, нашел комментарий по типу "я не знаю, что это делает, но я оставлю это тут ...". Как я уже писал, в документации не шибко написано про некоторые вещи, да и к тому же про некоторые вещи вообще ничего не написано. )) По этому решил спросить, может есть где то материал который по движку досконально проходится структурировано.
@@shandy6113 я такой документации не видел. А чтобы искать нужные методы и примеры их использования, делал запрос через Яндекс и иногда чатжпт.
Когда пишу код с нуля, часто делаю прототип на БП и потом уже переписываю на с++, так проще.
Но если в плане разбираться в чужом кода, согласен это трудно.
Проблема геймдева глобально в том что для крупного проекта важен "Редактор" - причем важнее всех остальных частей движка, без редактора ты просто не сможешь связать художников, звуковиков и т д воедино. BluePrint единственный способ усилить эту синергию. Если Эпики и дальше развивали С++, это бы просто создавали команды разработчиков которые потом могут мирно перейти ну кучу других технологий/движков со своими навыками.
4:22
Хз что за конфиг у вашей машины, зеон или селерон, но у меня компил аналогичного примера занимает 0.5 сек, а общее время выполнения LiveCoding меньше 2 секунд.
Хотя проц который будет 37 секунд компилировать 1 cpp и DLL к нему, менее вероятен чем медленная ОЗУ или накопитель
Сказки, не бывает такого)
@@shadowzain да, именно так, я вру
Вижу сразу, человек не понимает про что говорит "Видно опять программиста который говорит что ++ не подходят" хотелось бы узнать у уважаемого, участвовал ли он в коммерческой разработке чего-то для геймдева, и что бы он сказал например за source 1 собрал ли бы он его и посмотрел на код структуру движка и так далее и вот тогда говорил бы что такое движок и плюсы, так еще не известно какое железо ЧТО ДОЛГО ЗАГРУЗЖАЕТ:/ к остальному вопросов нет
Я писал на всех в мире движках, доделал только одну игру и она не была на анриал. И везде было быстрее чем тут, на этом железе.
можешь сказать какое у тебя железо было вовремя записи ролика?
Оба предложенные варианта - ерунда. Свой язык, это полная утопия. А парсинг блупринтов, это дополнительная головная боль разработчика и усложнение пайплайна. И если для больших студий это еще худо-бедно допустимо (но зачем им оно, если им проще нанять дополнительно C++ девелопа), то для инди это просто будет непонятный атавизм.
На мой взгляд, нужно идти другим, более адекватным путем - взять все лучшее от скорости компиляции и удобства графических форм, и при этом развить их в максимально удобный формат "сверху вниз - слева направо" (это если простым языком). Наиболее здраво к этому уже как ни странно приблизились разработчики движка Construct 3. В их визуальной системе используется такой подход. Он не идеален, и там тоже есть что улучшать, но вектор правильный. Из всех систем визуального программирования, пожалуй только их система не вызывала ломки при переходе от написания кода к визуалу.
Если и говорить об улучшении для UE, то нужно упрощать и делать удобней, а не наворачивать сверху дополнительное, и уж тем более не изобретать аж целый велосипед в лице языка. И конечно, это мое скромное имхо, но я уверен, что работающие с движком меня поймут.
Да этот Версе погоды не сделает. А как итог где Фортнайт, который грозился стать Роблоксом))) собственно Версе и стал проблемой этого СДК.
как по мне - в идеале еще одна кнокка на БП - траслировать с спп файл и все. А если еще и наоборот ил спп в БП - прям сказка была бы. Этим бы решалась и проблема с вершион контрол
@@user-dzimka а в чем проблема сделать cpp в БП? Если я правильно понимаю, то ты пишешь про блоки БП которые можно писать в cpp файле, а затем вызывать их в БП. Если да, то их можно было всегда писать, а иначе как по твоему они написаны?) UFUNCTION (), UPROPERTY () тебе в помощь и макросы. В обратную сторону это тоже работает, но как правило необходимо писать все параметры метода начиная от актера и заканчивая цвета предмета, а те что стоят по умолчанию(определены уже) можно опустить.
Мне как человеку, сидящему на юнити, странно видеть, что при ошибке в коде редактор вылетает
да, там даже и ьез ошибок он вылетает, если много вкладок открыто и там где обычно не вылетает, при каких 2-3 вкладак даже открытых спецыфичных он вылетает. поэтому после каждого редактирования блупринта или ассета нужно его сохранять, даже перед компилированием, а то и при компилировании может вылетить или зависнуть и пр деться насильно закрывать... очень багован наверно можно счказать и эти баги тянуться годами от 4,25 версии, когда п5рвый раз начал изучать унреалэнджен... Какоето несерьезное отношение к багам, кряшам, но зато видемо позволят быстро всякие новые функции внедрять и быстро разрабатывать движок. ну и бесплатный, так что приходиться терпеть и быть благодарным, дареному коню в зцбы не смотреть... хотя временами бывают мысли перейти на годод или унити. но в унити мне политика не нравиться, что с твоего заработка нужно денги отдавать юнити. а в унриле до определенно количества денег, ничего не надо платить унрилу, както меньше суеты и волоки по моему. и на юнити с шарп, не хочеться много времени терчть на его изучение. уже на унриле много научилься на блупринтах и всякого. ну и размер игры слышал что в юнити тоже намного меньше... но это как хоби, был бы разработчик серьезный, то может бы на юнити перешел. и на унриле я могу зделать одну игру и для андройда и для виндовс несильно изменив ее. не знаю или на юнити такое возможно...
@Alksbbch на юнити тоже блюпринты есть, да и деньги отдавать вроде не надо.
@@maxonclaxonКак сейчас юнити, лучше стало?
will it run on my 486 ? 🤔
Give it a try)
23:26 так что самое главное то?
Час прошёл и ни одного коммента до сихпор, ладно уговорил буду первым.
Про дебаг плюсов не понял. Что значит не узнаете значения переменных в дебаге? Из студии в дебаг режиме можно все значения переменных посмотреть, их типы и адреса в памяти.
У меня в rider некоторые переменные не выводятся, нам написано "значение скрыто из за оптимизаций"
@@DecembristITTV хм, в студии такого нет.
Мне казалось в студии также, надо проверить
@@DecembristITTV может в каких то случаях это бывает (хотя я реально очень удивлюсь если это так), но я ни разу не сталкивался. На работе сейчас много дебажить приходилось и никогда ничего подобного не было, за исключением случая, когда я случайно попытался дебажить в режиме релиз ) Ещё может быть не скачаны дебаг символы анриаловские? При установке он спрашивает качать или нет.
C++ норм !! 12 лет работаю проблем нет !
Мне бы твои 12 лет
я на c++ написал несколько программ для виндовс. и мне тоже не понятно от куда некоторые ошибки возникают. но я почти все на блупринте делаю. казалось должен быть как рыба в воде на с++, но я не с визуал студио работаю и не игры пишу, а windows api использую, если правильно назвал, со звуком, с виндовс интерфейсом, видемо действительно это не тот с++ в унреал энджене...
Ты сравниваешь C# и c++? Во втором же компилируется всё, а в C# компилирует в CL и потом интерпретирует, он не будет всё пересобирать если модули не связаны
Я это все понимаю. Но сравниваю Я не C++ и C# а скорость разработки в движках
Ну и в C++ в UE компилируется не все а только затронутое изменениями, если верить логам
как выбрать другой язык в Ue5?
Погугли unreal.js это все что есть, помимо cpp и blueprint
unreal javascript? новое дно пробито
@@DecembristITTV
Какое дно пробито?), если поможет почему не пользоваться, хотя мне лично не кажется удобным.
Твое мнение это только мнение, даже если тебе кажется, что тебе этот мир абсолютно понятен, братишка)
@@DecembristITTV я не писал такой вопрос.
@@DecembristITTV Ужас, они даже в анрил интегрировали этот вонючий джаваскрипт, позор. Javascript объективно плохой язык для серьёзного программирования.
А у крупных студий тоже такой запрос есть?
Вообще то когда-то давно выбирали не движок, а библиотеку для какого-то языка. Но тогда, давным давно - чтобы приступить к разработке самой игры - нужно было сначала пройти через все тернии по изучению графической библиотеки. А крупные компании делали свои собственные библиотеки, которые разрастались, разрастались, обрастали всякими редакторами и визуальными инструментами и в итоге получался "движок", на котором игру должны были делать уже не программисты а дизайнеры. Вообще странно и совершенно непонятно, что мешает Эпикам сделать как опцию текстовый формат работы с блюпринтами, по идее - ничего принципиально сложного для них в этом нет.
Для программирования на мой взгляд блюпринты ну совсем неудобны по причинам, которые упоминаются в ролике:
1. Нет привычного форматирования сверху вниз. Для чтения кода обычно достаточно прокручивать вверх-вниз, F12 для перехода к месту объявления переменной, метода, класса.
2. При большом количестве связей и переменных визуальное программирование превращается в трудно распутываемый клубок.
3. При чтении текста кода легче находить места интереса, легко искать по именам методов, переменных, любым текстовым данным.
4. Инструменты рефакторинга кода позволяют быстро выделять нужные куски кода в отдельные функции и методы - это привычное удобство, которого нет в блюпринтах из за визуального редактора.
Не понял. Почему ты считаешь поддержку C# в годот неполноценной?
Потому что нет экспорта на все платформы, и потому что эдитор не умеет мапить ивенты на си шарп классы, + не все си шарп апи работают, например в работе с асинхами. Ну и в общем то как надо работать с си шарп кодом больше похоже на костыль приставленный к основному языку.
@@DecembristITTV всё что ты описал кроме экспорта легко решается самим кодом на шарпе, для этого не нужна специальная поддержка движка. Есть фреймворки на гитхабе от студий использующих godot где всё это и многое другое уже решено. C# более полноценный язык чем gdscript, его базовые фичи позволяют сделать любой api и стабильно работающую кодогенерацию в два счета
Ну ты спросил почему поддержка неполноценная, Я ответил, ты подтверждаешь своим ответом что поддержка менее полноценная. И что нужны дополнительные усилия. Никто не говорил что поддержка 0вая и тем более что C# в сравнении с гд скрипт в вакууме проигрывает
Экспорт это значительная проблема.
@@DecembristITTV Экспорт обещают скоро поправить. Установить пакеты с нугета я не рассматриваю как значительные усилия.
Они мнего чо обещают но это всегда затягивается.
А дружить эти фреймворки от компаний не надо усилий приложить? А изучать их дополнительно? Все должно из коробки работать как в гд скрипт, не понимаю зачем с этим спорить.
Язык Haxe может компилироваться в другие языки, в шарпы, джаву, js, плюсы, php, можно сделать таргет для блюпринтов наверно
любой язык может компилироваться в любой язык. этим занимается транспайлер
@@404Negative возможно, просто на haxe это стратегия разрабов языка, а на других это стороние решения, разный уровень поддержки получается
как по мне, свой язык для движка звучит как дичь
лучше всегда брать существующий и адаптьировать его под движок
у существующих языков уже есть комъюнити, уже решено много болей, уже есть какая- то инфраструктура и тд
например тот же JS отличный язык для скиптовой логики
так же с ним посоперничать может lua, но по кол-ву инструментов, инраструктуре и комънили это кончно пропасть
Ну на Анрилке по сути дела кастомный С++. То есть от плюсов там только базовая база (синтаксис). А все остальные библиотеки там анриляшные. Поэтому смена языка может пройти почти незаметно.
В UE самый настоящий С++. Не нужно слушать всяких проходимцев, которые не открывали движка.
Чтобы в этом убедиться, достаточно скомпилировать Unreal в Visual Studio.
Свои собственные реализации структур данных, не говорит, что язык там другой.
Какой же ты навязчивый гражданин, слушай а в самых настоящих плюсах тоже сборщик мусора свой есть?
Я так понимаю у тебя рекорд Гиннесса по количеству открываний движка?)
@@Alex_Veresov он то настоящий, но по сути у тебя фреймворк построен вокруге. Никто не говорит о том что это не плюсы. Просто объясняется, что там много чего сделано для того чтоб лишний раз себе колено не отстрелить.
@@Alex_Veresov самый настоящий да.
С самым настоящим стилем середины-конца 90х, кто диды - помнят такую дичь как MFC для гуя и ATL для COM-объектов - вот с такими же волшебными кулхацк-макросами на сишных дефайнах. Когда в первый раз начал изучать тему - из документации и туторов аж родным вижуал студио 6.0 нафталином пахнуло)))
Современные версии языка c++ позволяют почти полностью обойтись без использования указателей. А большая часть проблем - это проблема кривых рук и плохого знания инструмента с которым работаешь.
в UE ты не можешь использовать современную версию С++
@themachine9329 хотя бы c++17 можно использовать?
@@Alexander_Gurov_RF анрил компилируется при минимально 17 стандарте и вроде как поддерживает 20, но прикол в том что использование std в рамках анрила считается плохой практикой. Обычно все нужные фичи внедряются отдельно в движке, для лучшей связки с ним же. Банальное smart pointers у UE свои.
Может быть юнити компилируется быстрее потому что это не та компиляция, что на C++? Может быть он компилируется быстрее потому что там JIT компиляция? Что всенепременно потом сказывается на производительности в рантайме.
В рантайме все компилируется в машинный код там. Для ААА студий мб производительность рантайма, с которой +/- все нормально и у других движков, может иметь решающее значение, но мне как индюшатнику надо быстро прототипировать мочь, чего не получается с плюсами сейчас.
Чел, ты выдал базу, а токсичных ущемленцев ниже в комментах не слушай. Все эти проблеы в плюсах более чем реальны. Язык потихоньку движется к меньшему времени компиляции, новая система модулей появилась. Но это будет происходить долго. Ну как обычно в С++. Всё равно в языке и хороших сторон достаточно. Просто для каждой задачи нужен свой инструмент. Поэтому у каждого движка и есть свой язык. Зато в UE высокая реалистичность, и, думаю, она была достигнута именно благодаря плюсам и сложным алгоритмам и большому числу оптимизаций сделанных с помощью плюсов.
Я сам программирую на плюсах, со временем хочу перейти на другой язык, а пока что мой фреймворк позволяет программировать достаточно комфортно, и в целом это распространенная практика, что пробелы плюсов заполняют сами фреймворки. Плюсы - это вообще опенсорсный свободный проект, и всё наиболее крутое надо искать во фреймворках, созданных крупными коммерческими компаниями.
Самый недооцененный канал на Ютубе
Самый переоценённый канал на ютубе.
Ну то есть плюсы плохие потому, что они сложные и потому что компилятся долго?
Плюсы не плохие, плюсы неудобные для геймдева, учитывая что есть рабочие альтернативы
@@DecembristITTV зато они быстрые и производительные. За это мы и любим Unreal.
А плюсы, на мой взгляд, не удобны для всего. Если их можно не использовать - лучше не использовать.
Unreal очень медленный, непонятно почему в unreal for fortnite они это поняли и сделали отдельный язык, а в основном движке нет...
Что ты несешь, откуда это информация, какой unreal for fortnite?
Пожалуйста, пиши java, sharp и не трогай unreal и c++. В чем не разбираешься от слова совсем.
Натыкался ли ты на Unreal Engine Angelscript?
Я сам еще не трогал, но по описанию пушка-бомба
Ещё Не пробовал, как раз на завтра про это новость в тг канале написал. Единственное чо мне не нравится - это форк движка
Что-то странное, у меня, когда все закешировалось, live code моментально работает, как в юнити. Комп хороший, да, все на ssd и памяти 64
Ну добавление хэловорда в существующий класс сколько идёт?
@@DecembristITTV Держи, бро. Только руки дошли, помню про тебя
Building Cpp1Editor...
Using Visual Studio 2022 14.39.33523 toolchain (------) and Windows 10.0.22621.0 SDK (------).
Determining max actions to execute in parallel (14 physical cores, 20 logical cores)
Executing up to 14 processes, one per physical core
------ Building 1 action(s) started ------
[1/1] Compile [x64] MyActor1.cpp
Total time in Parallel executor: 0.34 seconds
Total execution time: 0.82 seconds
File -----.obj was modified or is new
Building patch from 1 file(s) for Live coding module -----.dll
Creating library -----.exp
Successfully linked patch (0.000s)
Patch creation for module -----.dll successful (0.000s)
---------- Finished (0.000s) ----------
Accepted Live coding shortcut
---------- Creating patch ----------
Running -----.uproject""" -LiveCoding -LiveCodingModules="-----.json" -LiveCodingManifest="-----.json" -WaitMutex -LiveCodingLimit=100
Using bundled DotNet SDK version: 6.0.302
Building Cpp1Editor...
Using Visual Studio 2022 14.39.33523 toolchain (-----) and Windows 10.0.22621.0 SDK (-----).
Determining max actions to execute in parallel (14 physical cores, 20 logical cores)
Executing up to 14 processes, one per physical core
------ Building 1 action(s) started ------
[1/1] Compile [x64] MyActor1.cpp
Total time in Parallel executor: 0.30 seconds
Total execution time: 0.71 seconds
-----.obj was modified or is new
Building patch from 1 file(s) for Live coding module -----1.dll
Creating library -----.lib and object -----.patch_1.exp
Successfully linked patch (0.000s)
Patch creation for module -----.dll successful (0.000s)
---------- Finished (0.000s) ----------
нипониль. а куда делся коммент к цифрами ? нет смысла писать что ли ?
Какой?
@@DecembristITTV приколы ютуба, все вернулось
Уважаемый. Ты запускаешь же редактор проекта Unreal Engine, а не движок.
Ок, а движок как запустить? Как мне получить пользу от этого комментария?
@@DecembristITTVподумать над моими словами и прийти к правильным выводам.
Движок как запустить? Никак. Запускают игру, которая создана на движке.
Эта фраза абсолютно понятна носителю языка, так говорят все, есть ещё куча таких фраз. Если ты зашел сюда поумничать, то ладно, признаю, ты очень умный. Больше так не делай, спасибо.
@@DecembristITTV этого недостаточно. Требуется, чтобы люди говорили правильно.
Я сюда зашёл посмотреть про UE, скоротать время, отдохнуть немного. Но просмотр был испорчен плохими комментариями к действиям.
Ой все, иди трясись)
не досмотрел до конца , но так скажу что hot reload и live code мало кто использует , обычно проект перекомпилируется через ide что занимает 10 - 15 секунд
10-15 секунд компиляции это очень долго для современного железа
блупринты позволяют какбы избегать ошибоки кряшов в игре, хоть и не полностью. говорят еще что они медленее чем код, особенно математические вычесления. но если простенкая игра то там особо не важно чуть быстрее или медлене будет выполняться и больше или меньше чуть загружаться процесор. На андройде если какихто сложных симуляций нет, то ничего у меня не лагает на поко икс 3 нфс на нативном разрешении, не уменьшеном.
Бедняги с UE готовы даже свой язык писать. «Мыши плакали, кололись, но продолжали есть кактус»
Как ни крути Unity не получилось превзойти UE в больших проектах, рассматривать запуск проекта, как то глупо ) Главное в другом, это вход в движок, вход по росту скилла, он гораздо лучше, быстрее в игре, больше держит контента, многое прощает, красивее, все с коробки, это и есть будущее, программисты не так сильно могут включить зависимость от себя, теперь это все не так сложно.
Глупо игнорировать минусы вместо того чтобы о них говорить. Я говорю о конкретных проблемах связанных с кодированием. Когда движок крашится на ошибку в игровом коде, а в других движках такого нет это значимая проблема. Особенно в контексте скорости запуска. Попиши на плюсах, будешь вечно смотреть на загрузочную плашку.
Игнорировать прогеров и их подходы можно, однако если над проектом будет работать больше 1 человека начнутся типичные проблемы с этим связанные
Анриал топ, даже со своими ошибками и приколами, графика топ, куча методов оптимизации, куча настроек для оптимизации движка и там даже можно сделать один проект на двоих человек и у меня компилируется все меньше чем за 200 мс
Плюсы 200мс компилируются?
@@DecembristITTVА всё таки, какой архитектуры твой процессор и сколько у него ядер?
4 ядра 8 потоков или типа того, да это дефолтный топовый ноут из 2020го года за тыщу долларов, с видюхой 2060,
Про блюпринты вообще не правда, все зависит от того, кто пишет код на БП и какой подход использовать. Не слушайте этот бред дилетанта из видео.
Послушай дорогой не делетант, то что прогинг под UE это долго это не я придумал. Вопрос с чем ты сравниваешь. И еще "вы все врети" это не аргумент...
По читаемости это объективная правда. Но скрипт как альтернатива типа Версе тоже такое себе).@@DecembristITTV Как вариант претензия Эпикам основная и ты ее упомянул это запутанная трасировка и трактовка Acces Violation для 99% случаев ошибок новичка в UE). И да она конфузит только новичков которые не могут локализовать проблемное место в коде и определить конкретную причину по всему call стеку.
запускай стедлон, если хочешь что бы движок не падал( но есть ли смысл???), повторные запуски проекта обычно быстрее. Цена обработки исключений слишком большая, что бы их использовать в игровом движке.
Сколько боли в этих глазах
да ладно, не всё так печально по скорости
Ну на плюсах это самое печальное что есть в топе движков
1. Интересный заход про то, что языки не выбираешь. C#? Unity. Java? Libgdx. C++? Unreal + треть гитхаба самопальных. JS/TS? Defold/Cocos Creator. Rust? Bevy. Just4Fun можно юзать Go с каким-нибудь g3n (только загуглил).
2. "В Unity нет альтернативы. Там только C#."
Unity Bolt: я что, шутка для тебя?
Либо смеха ради ставь бородатые версии, до v5. Там вообще 3 языка: C#, JS и Boo (что?).
3. Анрил с крестами вообще не трогал. А если код с ошибкой в try/catch и выводить messege и call stack в лог. Отработает?
1. Я сказал, ты выбираешь движок а не язык, возьми подпиши на Java в Unity например, можешь? нет.
2. Болт это кусок говна, change my mind, то что там когда то было не вижу смысла обсуждать, было и было.
3. Отработает, тока try/catch там не приветствуется, да и все ты на свете в него не обернешь. Там часто ошибки просто из движка вылетают.
Без негатива)
В LibGDX даже редактора нормального нет, лол.
Который раз ютуб мне пушит видосы с этого канала и в очередной раз я убеждаюсь, что заходить сюда не стоило. Про указатели в 2024 даже слушать смешно
Что изменилось в 2024?
Надо было писать на "С"...
Для таких вещей нужен LUA, аминь!
Языки, для каждой задачи они по своему хороши
Чел не научился запускать редактор из под дебаггера и ноет об этом весь видос. Помянем.
А, ладно, умеет. Но выключать оптимизации не научился. Помянем.
И врёт про работу блупринтов. Какой байт-код? Какая компиляция в standalone? Ты про рефлексию вообще слышал? Может сам догадаешься, зачем она нужна?
Если бы ты вежливо разговаривать умел я бы с тобой поговорил, ну а так лососни тунца 😎
да, какой-то он нервный
@@DecembristITTV если бы ты хоть немного разбирался в UE, то с тобой был бы смысл общаться. А так сам тунца лосось))
Ща нам Тим Свинни завезёт Вёрс и заживём! (Нет). А вообще у анрила свои преимущества перед юничкой. Его зверская строгость дициплинирует и не поучится с тремя красными ошибками и десятком жёлтых спокойно запускать и разрабатывать проект. Приходится следить за тем, что делаешь. Да и блупринт чертовски хорош.
Моддинг был бы живым и тогда да, было бы супер
@@ГРУВБЛЭЙК Для анрила существует отдельный проект в виде UE4SS, который позволяет делать моды для любой игры на любой версии анрила.
Может кому будет интересно, есть приблуда для написания в UE на C#
th-cam.com/video/t8nP0IEWLZU/w-d-xo.html
Она не поддерживает 5 версию, ее забросили, и как я говорил в ролике это просто набор скриптов, они не заменяют плюсы и блюпринты
че эт c# скучный) он ж в godot тоже есть. Хотя несколько не удобно приделан.
годот только для 2 д игрушек
@@ak-rz7emдавно уже к годоту прикрутили 3d, и он довольно неплохой.
unreal verse 💀💀💀
это показывает общую деградацию эпиков
С++ идеальное решение, просто анрил своей рефлексией все портит, да и в принципе это не серьезный движок, сейчас тупа махают хвостом перед инвесторами
Ну а что плохого в verse, у тебя же не отбирают плюсы, для разработчиков среднего инди может норм зайти
Я лично буду пользоваться
Verse изначально был придуман не для разработки игр, а внутриигрового контента от игроков в играх по типу метаверсов. Плюсы всегда останутся предпочтительней
@@DecembristITTV говно синтаксис
так ты игромейкер ? я думал ты джава бекендер
Я везде и всюду, ничо не знаю, но все умею
никогда не работал с UE, и не собирался работать, но после твоего видоса точно не буду с ним работать!!
ну и зря.
Пох
Это звучит как будто человек в детве упал с велосипеда, потом рассказал как это было больно и плохо своему другу, а этот друг потом решил не учится кататься на велосипеде. Все детство этот так называемый друг бегал за своими друзьями на велосипедах, никогда не прокатился по лесу на нем, потерял много ярких событий и в итоге остался один в какой то момент. Потому, что бегать долгое время когда нибудь надоест, а некоторые вещи потом очень сложно переиграть по другому.
Skill Issue
Ich habe ein Problem
?
Роблокс имба 🎉
huisos
Поч?
bomj iobanai
А?
МакрОсы 🤣🤣🤣
Вообще, правильно мАкросы.