"Но заменить С++ в полной мере он вам не позволит.

В какой то момент вы просто станете смотреть на лапшу прилипшую ко дну кастрюли и плакать." - типа на плюсах не так происходит? Пишут проект годами, а потом в один прекрасный момент понимают, что не способны его более поддерживать 😂
"Когда в вашем проекте будут появляться длинные макароны, более 20 блоков можно задуматься о переносе их в С++" - можно задуматься о функциях, компонентах, макросах. В плюсах будет тот же винегрет только в профиль - функции по 200 строк.

Разумеется легаси есть везде, но макаронное легаси мне кажется одним из самых ужасных.

Не понимаю людей которые макаронят так много

в движке тоже встречал странные вещи 😂 а 16к - это уже хоррор )

Да... Русское "инди" оно такое

Видели бы вы функцию, которая блипринты компилирует.... Там у тебя весь компилятор считац в одной фукнции)))

в начале своей карьеры как-то видел выражение "крут не тот программист, который умеет писать простые программы на плюсах, но тот который на Вижуал бейсике может написать сложную программу" 😉

тут вопрос в определении сложности

сложно не в контексте читабильности конечно 😂 а в полезности для юзера

Язык это просто инструмент, который решает свои задачи. Хороший программист использует тот язык, который подходит под решение конкретной задачи. Блюпринт решает задачу доступности движка для начинающих разрабов и быстрого написания простых фичь.

И слабых компьютеров!

конечно, если речь про среднего уровня программиста. Но дело в том, что в "непредназначенных" языках могут быть те возможности, о которых большинство и не подозревает.

А ты видел ProcessEvent? Это тебе не указатель в стек положить.

Я знаю о возожности макарон медленно работать и не удобно читаться.

как они могут не удобно читаться, если они создавались для удобства прочтения? Надо эпикам рассказать, что их инструмент провалился )) но а скорость зависит во многом от программиста. Тем более, что самые скоростные вещи должны делаться движком - просчет вершин, подгрузка ресурсов и прочее.

А чего на visual, я просто на basic писал, как и многие в начале девяностых)))

Еще раз. Блюпринт решает проблему доступности для начинающих. Большую лапшу на несколько экранов проще читать в виде с++ функции, которая влезает в экран.

большие функции в 200 и более строк не удобнее читать, чем лапшу.

Мне блупринты удобны очень, а если что очень большое получается, то можно сделать на плюсах и в одну функцию для блупринта запихнуть))))

А ещё высокой скорости изменений(например, прототипирования, либо конфигурирования)

У меня много вопросов к таким функциям

Да.

потому если следуешь правилу не писать функции более 10 строк, то и лапша из более 10 элементов тоже не получится.

Удобнее, там есть подсветка и Ctrl+F гораздо удобнее, чем в бп В принципе с текстом удобнее работать, т.к. на этом уже много копий сломано =)

а принтах у тебя поиск не работает? элементы не выделяются разным цветом? Но лично я не пишу громадных функции как в принтах так и в плюсах. Поэтому не вижу лапши не там ни тут, не люблю лапшу, она плохо переваривается )

Большие функции на С++ это не так страшно, как кажется, поверь

Я же написал, чувак Удобнее Дольше с этим люди работают Дольше инструменты эволюционируют Больше ресурсов потрачено Чаще я с этим работал == удобнее

ахахах, если б не приходилось дописывать за "бесстрашными" их вермишель.

возможно, тебе удобнее. Но мне удобнее, когда код структурирован и есть четкая архитектура. А когда нужно поисками выискивать нужные участки кода - это ни в каком редакторе не удобнее.

Ясно, приходи через пару лет, ещё раз поговорим об этом =)

На VB программы писать по сложности, то же самое что и на C#, потому как отдельно от .NET и переопределения API функций Винды а также встроенных инструментах -ты там мало что напишешь, VB это сложный язык если его рассматривать в стеке технологий, Он лишь слегка засахаренный по синтаксису. Понятно что написать софт на VB в разы быстрее чем на C++.Он медленный в нагруженных задачах - это плата за "сахар".

а что через пару лет произойдет? )

"выучишь 800 нод" (с) 😂

Ну хз, максимализм пройдёт, например Опыта появится побольше Пока это выглядит очень прямолинейно, отчего кажется что опыта с гулькин хуй

да, но потом в С++ можно и БП узлы использовать

ну да, более 10 лет писать на плюсах это с гулькин...

Из C++ в принципе можно бп использовать

ну и подход у вас)) бытовой, как у барана, глядящего на новые ворота) кто кого перебодает))

Первые 100 страниц вроде Совершенного Кода нужно курнуть, бро

да, Я это и имел в виду что там можно опыт применять если есть понимание работы С++

Ну тогда ты идеалист и я тихо удаляюсь в угол =) Спорить особого смысла не вижу =(

это не мой подход. это местный мем, кавычки цитата, копирайт. чувство юмора у вас батенька отсутствует

Это называется логика и умение структурировать и декомпозировать 🤣

Я просто не понял, что над этим надо смеяться))

и что в совершенном коде пишут, что если ты делаешь вермишель в принтах, то при переходе на плюсы ты каким-то чудом начнешь писать функции по 10 строк?

там даже смайл был. ну да ладно. проехали

это потому что я за такой подход что надо всё изучать постепенно и тогда не будет сильных провалов, но в тоже время будет прогресс и тем самым не будет отторжения, как в игре: накачка дофамином)

Так важен баланс, между всеми возможностями движка

Это по первому утверждению

за свой опыт понял, что глупо не использовать визуальные средства и писать всякие объекты-мегакотроллеры для создания тех алгоритмов, которые можно настроить визуально. Не стоит отвергать прогресс и удобство разработки. И не стоить фанатеть от плюсов, шаблонов и т.д. Главное, что решить задачу быстро и качественно, а не "как в статье написано".

а, ну так да, плюсы ничего не дадут, если нет понимания того как строить архитектуру. Но если уже есть опыт создания гибкой архитектуры, то и принты очень даже подходящий инструмент. З.Ы. конечно, местами всеравно приходится плюсы использовать, не писать же формулы диаграммами 😂

Я предпочитаю БП для скриптинга на уровнях. Когда на уровне надо подружить сотни объектов друг с другом - это лучшее решение. Также на них приятно простую логику писать и мишуру приделывать

Писать объекты мегаконтроллеры - это антипаттерн, не важно на чем ты пишешь.

дело НЕ в размере, а в концепции - писать кодом то, что настраивается визуально.

Поддержка формул есть в BP, не обязательно спускаться на уровень С++

Когда делаешь большие системы тебе на с++ нужно написать то, что ты потом настроишь визуально. Когда я делал маленькие проектики по 3-4 месяца я тоже думал, что все можно намакаронить.

а я начинал со сложных систем, где все прописано кодом. Поэтому сейчас так люблю визуальные средства и понимаю, что если понимать зачем они созданы, то качественные решения на них так же можно создавать. Грамотная архитектура и на принтах возможна - там все те же функции, объекты, классы.

Грамотная архитектура возможна, не спорю. Но блюпринт же попимо того что не удобный еще и дико медленный же?

самое плохое что он сохраняется в двоичном виде

вот именно с этим я и не согласен. Во-первых, описание алгоритмов диаграммами имеет свои плюсы и минусы. Минусы громоздкость, а плюсы читабильность и очевидность. Соответственно, нужно не стеснятся создавать кучу функции с небольшим количеством диаграмм, тогда и выглядить будет все как настольная книга. Во-вторых, скорость зависит от того какие алгоритмы и как реализовывать. По своему другому направлению пишут проекты и на php и на js, которые по факту не могут быть самыми быстрыми, но производительности более чем хватает. Естественно, что на принтах не стоит писать перебор пикселов изображения и подобные вещи, но для логики игры, где нужно сделать выбор по булеву значению - что там может быть медленным?

Там медленно вообще все. У тебя все с++ фнукции, который он дергает ищутся по указателям и именам, все параметры аллоцируются в куче. Постоянно он ходит в операту зачем то. И это все нужно что бы просто вызвать один евент, безотносительно того, что в самом евенте. На с++ нет таких накладных расходов на вызов функции

тогда почему не писать на асссемблере? знаешь сколько накладных расходов в плюсах? ты одну функцию дернул, а там за сам вызов 10+ операций сработало, которые тебе никак не нужны.

логика игры может быть тяжелой

fcctv,kth gkfnajhvjpfdbcbv

Ну нееее, это уже крайность. Да и на самом деле с++ не много накладных расходов дает. А там где они есть можно использовать интринзики, которые решают большой спектр проблем

это уже конкретика. Мне как-то доводилось оптимизировать работу древовидных списков, которые медленно грузились. В итоге выяснилось, что работу удалось ускорить раз в 10 ) А останется ли тяжелая логика таковой после оптимизации заранее явно не скажешь.

потому что современный компилятор это сделает лучше чем ты, если ты не бородач с C++ Conf

вот я так же считаю и про принты, что это уже крайность. Достаточно производительно они решают свои задачи.

лучше чем я не сделает, в отладке где асм код вижу чего бы можно было вырезать оттуда. Это, насколько, мне кажется, очень очевидно даже для начинающего разработчика на ассемблере. Но, понимаю зачем это нужно и согласен с платой за удобство разработки с поддержкой ООП и чтобы не приходилось в стек руками добавлять параметры и не листать справочник операций проца.