UEngine.Ru

ну спорно на самом деле ...
с нативизацией блупринтов разница в производительности с С++ кодом уже совсем не такая огромная... а даже наоборот слишком маленькая чтоб всерьез воспринимать как какой-то серьезный недостаток...
на принтах ОЧЕНЬ удобно прототипировать... решения иногда можно брутфорсить вариантами переключая разные ноды, меняя местами пины.
Самый главный недостаток блупринтов - малый функционал, блуепринтейбл функций мизер по сравнению с С++...
но сейчас 90% моего кода на С++...

а вот самая большая проблема С++ недокументированно очень много всего... чтоб понять как что-то работает нужно тупо читать код...

честно говоря сделать тоже самое на плюсах что уже готово в БП у меня пока отнимает больше времени чем полностью с нуля в БП все по новой запилить... и виновата в основном среда разработки... Висуал Студия - ужасна, по сравнению с интерфейсом БП анриала...
Но привыкну наверное-_-.

Да, выбор инструмента уже давно находится в области персональных предпочтений. Мне всегда нравилось программировать текстом где бы то не происходило (сейчас программирование меня не вставляет ни в каком виде).
Блупринт для меня не более чем "куча-мала". Прототипирование мне лично было проще делать текстом. Так что, как я и утверждал выше - спор ни о чем.

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

Я уже говорил, что основная проблема блупринта - принцип черного ящика. Я имею ввиду, что C++ формализированный язык, с ООП ориентацией. Разумеется на нем можно программировать как на блупринтах (функциональное программирование это вроде называется) совершенно не понимая даже поверхностных вещей в ООП. Но на сколько я понял - поверхностное восприятие всего окружающего мира сейчас основной тренд. Потому блупринты и популярны в среде новичков. И переток с Юнити на Анриал сейчас по моим наблюдениям уже не из-за картинки а из-за мнимой простоты блупринтов.
Потому качество написанного серьезно страдает. Ты уже заметил вторую причину этого - невозможность разобраться в блупринт куче спустя несколько месяцев. Но как я уже опять же говорил выше - сейчас программирование это банальное выполнение разовых заказов. Такого рода программистов не возьмут в серьезные компании, да они и не потянут серьезную работу.
"На скору руку" и "временно" - девиз современного общества.

но ведь и на принтах же можно программировать как на С++,
большинство принтовых ограничений распространяется и на С++ анриала...
например множественное наследование UCLASS() не поддерживает.

В БП вызываются те же С++ методы... кликнув дважды по любой ноде можно увидеть С++ код который она выполняет, черного ящика нет все доступно, если хочешь посмотреть как оно работает. Из ++ все равно прийдется вызывать те же методы что и из БП.

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

а говнокодить можно везде... и на ++ и в бп ...
макскрипт тоже может ООП... но я не понимал раньше этой концепции... поэтому говнокодил функциональным программированием в максе.

ООП не такая уж и сложная концепция, прочесть соответствующую литературу для понимания, и на практике на само проектирование чуть времени потратить прежде чем начинать чето писать...

Я осваивал ООП лет несколько. В то время не было литературы, интернета и стоящих книг. Потому так долго. Но главным препятствием было отсутствие практики. ООП и нужно в основном при проектировании всего проекта, но... Повторюсь. Если делать заказ разовый, то нет нужды проектировать архитектуру проекта. Тяп-ляп набросал, потестил - все работает и отправил заказчику.
А если работать несколько лет в рамках одного проекта, расширяя его по мере работы, совершенствуя, то нужно сразу продумать основную архитектуру и делать в соответствии с ней.
Так что ООП далеко не всегда и нужно. Для общего развития изучать концепцию ООП слишком сложно. Чаще нубы не понимают зачам им это нужно и продолжают кодить функциональным способом. Отсюда и вопросы как связать блупринты и иже с ними. Это причина и следствие.
Подавляюще большиснтво игроделАфф не боле чем временщики. Отсюда и результат - море однотипных или пустых вопросов и практиское отсутствие стоящих тем о том как делать игры, а не программировать отрыв конечностей...
Впрочем тема эта уже исчерпана и давно. Толку пеертирать ее очередной 100500-й раз нет смысла, почему я ее больше стимулировать не хочу.