Pull to refresh

Comments 10

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

А что там с диффами и мержами? Помню в 4 анриле приходилось знатно мучиться. Тулза для мержа постоянно крэшила при изменениях в используемых типах данных.

Тоже хотел про это написать. Уже 5.4 выходит, а блюпринты нельзя адекватно мёрджить системами контроля версий.

Как делается у нас с Plastic SCM когда конфликт. Оставляется своя версия. потом, если не подключена в редактор система контроля версий она включается(иногда настройка включения слетайте). после средствами анрила просматривается история и сравнение с Depot. Нужное добавляется. Если часто мержить и знать кто работает в файлах - проблем меньше.
Еще меньше проблем если есть хоть какая-то композиция и иерархия. тогда вероятность что много человек в одном файле будут работать меньше

А если нужно что-то удалить, а не добавить? Там пару полей перенести из одной структуры в другую. Как сейчас не знаю, но раньше падало. И да, мы тоже через Plastic SCM работали.

Я не программист, но от этих Блю-принтов голова кругом идёт, всегда хотел научиться делать игры, проходил курс не до конца по Python, а потом узнал про GDscript попробовал и уже разрабатываю игру как 3 месяца, написал около 3-3.5 тыс строк кода уже, и мне как инженеру в прошлом намного проще сделать что-то через формулы и код, как по мне переделать или добавить что-то для какого-нибудь скила в игре намного проще будет через код. Хотя при этом в проектировании тоже приходилось сталкиваться с аналогом этих принтов, в Revit есть Dynamo использующая такой метод, так вот когда я делал что-то в ней меня не покидала мысль что я пытаюсь работать но вместо рук делаю это ногами, собственно поэтому и хотелось изучить какой-нибудь ЯП, потому был уверен через код это всё сделать намного проще можно. Я вот смотрю на эту картинку с нодами и связями, представляю какой кошмар если нужно будет изменить или переделать логику. Минимально разобраться в ЯП не так сложно, есть GPT который объясняет какие то вещи, есть гайды на Ютубе, начинаешь с малого потом начинаешь делать всё более сложные и сложные вещи используя минимум который получил.

Сразу видно что статья не от человека с длинным опытом работы в блюпринтах.

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

Ну и производительность циклов просто ужасна. Даже небольшой цикл с перебором 10 значений в тике на 100 акторов очень сильно просадит проц.

Но с другой стороны мы имеем плюсы которые в рантайме применяют изменения в движке через раз... Хочешь достоверно проверить свой код - перезапускай движок.

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

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

у меня такой вопрос.
создатели смуты всю игру чтоли запилили поверх этих блупринтов?
просто глядя на неё и фпс в игре , такое чувство что да

Вам не кажется что мы находимся немного в другом времени где мощности компьютера у большинства пользователей позволяют переварить любой код, идеальный написанный на плюсах либо огромную логику на event tick . А основная часть оптимизации если брать UE так это визуальная часть где основную долю ресурсов съедает графика. Тени, освещение, текстуры, количество полигонов в модельки и одновременно загруженных на уровне в одном месте.

Sign up to leave a comment.

Articles