Comments 25
Нужно больше статей по UE4.
А чего решили на С++ писать? Пробовали тоже самое реализовать через редактор blueprint'ов?
А разве блбюпринты вообще годятся для написания чего нибудь сложного?
ИМХО они для введения, для клепания простых прототипов.
Проекты имеет смысл делать на С++ — это дает больше контроля, больше возможностей.
ИМХО они для введения, для клепания простых прототипов.
Проекты имеет смысл делать на С++ — это дает больше контроля, больше возможностей.
Логика как в статье — почему бы и нет. Я уж не знаю про скорость (да и игровая логика не то чтобы сильно требовательна к ресурсам), но одно серьезное препятствие это конечно громоздкость.
Вот например шейдеры. Там блюпринты прижились и используются для создания сложных материалов, но в итоге получается огромная куча блоков, в которых несколько сложно разбираться. Хотя блоки комментариев спасают.
Чуть ли не главная фишка блюпринтов же — дать возможность пилить шейдеры и логику дизайнерам, а не программистам. Это очень круто, хоть я и сам программист. Теже материалы делать блюпринтами очень интересное занятие и куда более интерактивное, нежели писать код.
Судя по различным обсуждениям, все сводится к одному — делать на блюпринтах все до тех пор, пока не упрешься во что-то. Будь это возможности, производительность, читабельность. Тогда что-то можно перенести на плюсы. Но это все так, инди, аркадки. Что там с ААА не слышал — насколько там блюпринты популярны. Не удивлен, если блюпринты там даже в расчет не берутся.
Вот например шейдеры. Там блюпринты прижились и используются для создания сложных материалов, но в итоге получается огромная куча блоков, в которых несколько сложно разбираться. Хотя блоки комментариев спасают.
Чуть ли не главная фишка блюпринтов же — дать возможность пилить шейдеры и логику дизайнерам, а не программистам. Это очень круто, хоть я и сам программист. Теже материалы делать блюпринтами очень интересное занятие и куда более интерактивное, нежели писать код.
Судя по различным обсуждениям, все сводится к одному — делать на блюпринтах все до тех пор, пока не упрешься во что-то. Будь это возможности, производительность, читабельность. Тогда что-то можно перенести на плюсы. Но это все так, инди, аркадки. Что там с ААА не слышал — насколько там блюпринты популярны. Не удивлен, если блюпринты там даже в расчет не берутся.
Ну вот у нас есть программист.
Ему надо решить задачу по перемещению юнита из точки А в точку Б.
Причем он прекрасно понимает, что задачу могут через пару месяцев изменить и придется переделывать.
У него нет проблем с кодом, он не дизайнер, он — программист.
Зачем ему вообще к блюпринтам прикасаться?
Ему надо решить задачу по перемещению юнита из точки А в точку Б.
Причем он прекрасно понимает, что задачу могут через пару месяцев изменить и придется переделывать.
У него нет проблем с кодом, он не дизайнер, он — программист.
Зачем ему вообще к блюпринтам прикасаться?
А зачем в играх скриптовые языки используют? Чтобы дать работу дизайнерам, которые и будут заниматься игровой логикой без того, чтобы сидеть и читать Страуструпа. В анриле блюпринты — по сути, это та самая скриптовая система. Весь критический к производительности код можно убрать в плюсы, а снаружи делать блюпринтами. Программисты хороши там, где есть задача и можно написать и забыть. Блюпринты и скриптовые языки хороши там, где задача именно постоянно меняется, нужно что-то постоянно твикать, отлаживать, подправлять. В плюсах этим не занимаются даже ААА студии, у них скриптовые языки для этого отведены. Важнее сделать процесс быстрым и легким, а не гнаться за тактами, которые плюсы выиграют против скриптов
По вашему — задача описанная в этой статье — это задача для дизайнера?
Я не вижу там ничего связанного с работой дизайнера. Там чисто программистская задача.
Я не вижу там ничего связанного с работой дизайнера. Там чисто программистская задача.
Почему бы и нет? На блюпринтах успешно пишут и системы анимации со своими стейт машинами. В редакторе для этого полно инструментов. Тут конечно уже тонкая грань из-за этих блюпринтов — на них это все успешно пишется и не выглядит ужасающе громоздко. Хотя, если отбросить все эти упрощения блюпринтов, подобная логика действительно более уместно смотрится в ядре, где скриптам не место.
Нет, потому что задача дизайнеров — геймплей.
Core функционал — это задача программистов, даже если инструментарий позволяет мышкой создавать Core функционал дизайнеру, это еще не повод так делать.
Core функционал — это задача программистов, даже если инструментарий позволяет мышкой создавать Core функционал дизайнеру, это еще не повод так делать.
Помнится по первости я написал логику сближения корабля с точкой назначения, путём постепенного снижения скорости и продолжения движения к точке — эдакое равномерное падение на точку назначения. В blueprint'ах это заняло три экрана, в коде — 10 строк. Наглядности в них мало. Только для небольших задач.
Именно. Мы blueprint оставили только для проектирования интерфейсов через UMG, и то их максимально в код заворачиваем. А также шейдеры. Кстати, они уже не считаются blueprint'ами, лишь визуально сходится процесс разработки.
На гитхабе лежат исходники Unreal Tournament 4, можно посмотреть как это делают в AAA (там всё на С++).
Блюпринты очень быстро превращаются в лапшу, с ними очень много рутины по организации нод, что бы это было более менее читабельно.
Блюпринты очень быстро превращаются в лапшу, с ними очень много рутины по организации нод, что бы это было более менее читабельно.
А какой-нибудь сценарный язык пробовали прикрутить? Или на С++ комфортно?
Скриптование — это отдельная тема. И там блюпринты вполне уместны. Также как и в материалах.
Речь только о логике ядра проекта.
Речь только о логике ядра проекта.
Вообще не видно никакой необходимости. Тот же AI прекрасно идёт через встроенные Blackboard'ы и немного кода.
Ну как минимум, что бы избавиться от долгой перекомпиляции проекта. Был же UnrealScript в прошлых версиях, а тут бы не плохо смотрелся Python или C#, или ещё что-нибудь.
В 4.7 версии скорость сборки очень хорошо подняли. Конечно всё зависит от размера проекта. Зато используется всё нативное. Мы пока что в этом не ощутили проблемы. Прототип собирался полностью за минуту где-то. И это до оптимизации, с ним мы работали в 4.6 ещё.
А как с обратной совместимостью в между версиями? Я собираю прототип, вся логика на Blueprint и периодически, что-то меняется. Приходится переделывать.
Пожалуй самой страшной проблемой для нас была работа с UMG, потому что мы начали использовать его прямо сразу как он появился в прототипизированном виде с 4.3. До 4.6 по всей видимости у них в UMG произошло множество изменений и у нас всё пришло к тому, что любое изменение в любом виджете, при компиляции, приводило к падению UE4.
В остальном, примерно раз в 2 версии, происходят архитектурные изменения и приходится что-то менять, но это занимает крайне мало времени, Epic в этом плане работают на совесть. Ну а что до UMG, то тут конечно проблема в наследии с первых версий.
В остальном, примерно раз в 2 версии, происходят архитектурные изменения и приходится что-то менять, но это занимает крайне мало времени, Epic в этом плане работают на совесть. Ну а что до UMG, то тут конечно проблема в наследии с первых версий.
Подводя итоги прототипа, мы сделали вывод, что blueprint'ы хороши только для простеньких игр и несложных операций. Если вы хотите часть игр писать в C++, то лучше всё максимально уносить в код. К тому же через blueprint'ы написать свой movement component — это no way.
Вопрос, который, думаю, интересуют очень многих.
По каким материалам вы изучаете UE?
Хватает родной документации, или есть какие-то дополнительные материалы?
С чего начать(и продолжить) новичку в UE?
По каким материалам вы изучаете UE?
Хватает родной документации, или есть какие-то дополнительные материалы?
С чего начать(и продолжить) новичку в UE?
Официальная документация + туториалы от сообшества — это отличный старт. С них и начинали. Плюс answerhub и форум, где отвечаю достаточно быстро. Зачастую сами разработчики. Они на форуме сейчас отобрали представителей сообщества, опытных, которые постоянно мониторят его и стараются направлять. Кстати, где-то там собирались запускать что-то рускоязыное, можно уже темы найти.
Однако порой приходится только методами проб и ошибок узнавать как поступить правильно. По-началу вариативность казалась костыльной или каким-то тяжёлым наследием, а сейчас приходим к выводам, что возможность реализовать одни и теже вещи принципиально разными способами (например, работа с камерой) — это направление унификации движка. Т.к., всё-таки UE4 базируется на UE3 и ещё имеет в своей архитектуре местами прибитое гвоздями направление в сторону FPS.
Подводя итог: туториалы+форум+answerhub+свой опыт. Готовьтесь к тому, что вы будете разбираться в исходниках проектов-примеров и исходниках движка. Кстати, их не стоит бояться, они написаны весьма чисто и прозрачно.
Также есть неофициальный irc канал, где постоянно сидит порядка 100 девелоперов и помогают своими советами.
А новичку в гей-деве начать стоит с blueprint'ов, чтобы ознакомиться с архитектурой и понятиями проекта. Когда уже въедешь в иерархию и чем отличается Actor от Pawn'а — тогда уже можно начинать в код идти. Постоянно обращайтесь к проектам — примерам, в них очень много полезного. Даже простые бабочки, которые используются для окружения имеют весьма навороченную систему взаимодействия с окружающей средой и поведение.
Однако порой приходится только методами проб и ошибок узнавать как поступить правильно. По-началу вариативность казалась костыльной или каким-то тяжёлым наследием, а сейчас приходим к выводам, что возможность реализовать одни и теже вещи принципиально разными способами (например, работа с камерой) — это направление унификации движка. Т.к., всё-таки UE4 базируется на UE3 и ещё имеет в своей архитектуре местами прибитое гвоздями направление в сторону FPS.
Подводя итог: туториалы+форум+answerhub+свой опыт. Готовьтесь к тому, что вы будете разбираться в исходниках проектов-примеров и исходниках движка. Кстати, их не стоит бояться, они написаны весьма чисто и прозрачно.
Также есть неофициальный irc канал, где постоянно сидит порядка 100 девелоперов и помогают своими советами.
А новичку в гей-деве начать стоит с blueprint'ов, чтобы ознакомиться с архитектурой и понятиями проекта. Когда уже въедешь в иерархию и чем отличается Actor от Pawn'а — тогда уже можно начинать в код идти. Постоянно обращайтесь к проектам — примерам, в них очень много полезного. Даже простые бабочки, которые используются для окружения имеют весьма навороченную систему взаимодействия с окружающей средой и поведение.
Вот нашел русский ресурс и тут потихоньку оформляют документацию.
Sign up to leave a comment.
Пишем компонент движения для RTS в Unreal engine 4