13 упоминаний #У***X4 в тексте (не считая название и тег) — многовато. Зачем так форсить? Статья написана с применением вышеуказанного ускорения и упоминаний могло быть в 4 раза меньше?
Unreal сам по себе весьма непростой движок, поэтому полтора года, особенно если человек начинающий, не так много. У многих инди проектов судьба печальная и зачастую не сильно зависит от используемого движка. Как говорится, "нельзя так просто взять и зарелизить свой первый проект". Конечно, базовые знания программирования (функции, циклы, переменные и т.п.) необходимы, чтобы хоть что-то реализовать на блупринтах. Блупринты хвалят, так как они предоставляют средства, которыми могут пользоваться не только программисты. В сложных проектах они тоже используются вовсю, просто основная часть сложных систем реализована на C++, а для блупринтов доступны функции взаимодействия с ними.
Проще для реализации игровой механики, меньше багов, приносимых попытками "побороть" третье измерение, выше производительность. Не будет случаев, когда из-за физики объект улетит за границы 2D мира "в глубину".
Да, знакомый подход с кэшированием, но это скорее вопрос оптимизации, и далеко не во всех проектах "обходят" встроенные средства стороной. В юнити частенько приходится многие вещи оптимизировать. Вручную создавать частицы одним эмиттером вместо сотни, "лепить" специальные отражения для воды, дабы каждая лужа сцену не рендерила сама и т.д. Основная фишка юнити — "казуальное", доступное устройство движка, и с ростом масштаба/требований проекта все больше надо воевать за производительность в ущерб "универсальности" и "удобства" :) Хотя, геймдев в целом это искусство фейка и компромиссов, так что нам не привыкать)
Compute шейдеры вполне можно использовать. Сделано даже без модификации движка, см. UE4ShaderPlugin. Но в целом, любой движок стоит выбирать исходя из требований проекта. В Unity, например, годами отсутствовал normal mapping на ландшафте, gpu skinning и instancing. Но разработчики до этого добрались и реализовали.
Что в вашем понимании есть "нормальный шейдер"? Сейчас большинство движков имеют собственную основу для системы шейдеров и материалов. Прежде всего это связано со сложными моделями освещения, многообразием комбинаций типов геометрии, освещения, материалов и поддерживаемых платформ. Проблемы с вмешательством в рендер могут возникнуть в Unity, где исходный код движка не доступен. В анриале вы можете собрать кастомный движок, добавив нужный функционал.
Так можно и про юнити с ассет стором сказать. Купил ассет, поменял название, запостил в стим! Человеческий фактор, а не изъян технологии. Если же проект грамотно построен, минус превращается в плюс. Например, дизайнеры звука могут настроить желаемое поведение звуковым эффектам через редактор Sound Cue. Например, играть случайный звук вместо единственного заданного, выбрать нужный звук в зависимости от внешних условий (скорости передвижения игрока, например) и т.д. В результате у программистов больше времени чтобы писать код и они не отвлекаются на подобные мелочи.
Зависит от данных. Если это настройки или сохраненные игры, можно написать расширение класса SaveGame. Если нужны кастомные свойства на игровых картах — пишем свой класс WorldSettings. Достаточно все поля, требующие сохранения, отметить как UPROPERTY. Для общих данных можно использовать классы DataTable и DataAsset. Для DataTable надо будет сначала описать структуру данных (создать блупринтовую или C++ структуру), а для DataAsset — унаследовать свой класс от него. Кроме встроенного редактора таблиц, в DataTable можно импортировать данные из csv файла. Также можно просто создать структуру и объявить ее как свойство эктора или компонента.
Проблема префабов — в отсутствии "наследования" объектов, а не в невозможности сохранить в файл. Насчет аниматора согласен, я чаще управлял анимацией старым способом, из кода. Но слои в демке используются. Так что да, имеет место легкая недосказанность :)
Две строчки кода скорее всего будут такими же двумя вызовами блупринта. В "запущенных" случаях, можно перенести часть реализации в код.
Лезть в игры не зная программирования бывает полезно. Некоторые разберутся из каких компонентов состоит игра, другие — начнут учиться программированию. Художники и левел дизайнеры смогут собрать простенькую интерактивную сценку. Применений блупринтам — 1000 и 1 штука. Не только лишь суровым кодом создаются проекты.
Не соглашусь насчет того, что в юнити "встроенная компонентная архитектура не применяется", ведь механика добавления компонентов на объекты, их поиск и взаимодействие (даже обращение к встроенному свойству transform или поиск объекта в сцене) — как раз использование этой самой архитектуры. Даже автоматический вызов функций Update, LateUpdate, OnGUI и т.д. тоже является ее частью.
Теперь к анриалу. В данном ключе "дизайнеры" — те, кто не пишут код, но могут менять/настраивать блупринты. Воркфлоу в анриале такой:
если в проекте вдруг нет программистов, весь проект делается на блупринтах (лично таких случаев не встречал, но недавно был пост как раз о разработке игры таким способом)
если в проекте есть программисты, они в зависимости от требований реализуют на свое усмотрение часть функционала в виде кода, а часть — в виде блупринтов.
Редактор можно расширять плагинами, именно так делаются для него тулзы. Да, при изменении кода приходится адаптировать блупринты к сделанным в коде изменениям. От скриптов отказались, видимо, потому что весь функционал, доступный ранее в скриптах, теперь есть в блупринтах. И люди, которые раньше "боялись" программировать, теперь смогут собрать игру на более понятных для них визуальных схемах.
Обычно создается наследник класса HUD, через который идет взаимодействие механики игры и интерфейса (обмен данными, обработка событий и т.д.). Окошки и прочие элементы интерфейса создаются через Widget Blueprint-ы, которые сочетают в себе визуальную часть UI и блупринтовую логику (переменные, функции и т.д.). На старте (или по событию) наследник HUD-а создает один или несколько основных виджетов и сохраняет ссылки на них у себя в свойствах (Variables). Конкретная схема виджетов и их вложенности/взаимодействия зависит от того каким должен быть интерфейс. Анимации создаются и редактируются прямо в редакторе интерфейса. После создания пустой анимации добавляются участвующие в ней виджеты и их свойства (позиция, цвет и т.д.). Анимации воспроизводятся функцией Play Animation в блупринте этого элемента. Одна анимация может управлять сразу несколькими виджетами. Подробнее лучше смотреть какой-нибудь туториал, например UE4 UMG Animation
Да, блупринты — весьма себе плюс. Это вам любой дизайнер подтвердит. Визуальный «скриптинг» вполне себя зарекомендовал, и, например, часто используется для описания материалов (шейдеров), причем не только в Unreal. Часть «сложной» логики можно реализовать кодом и сделать доступной для блупринтов, так последние станут менее запутанными и более читаемыми. Про «архаичность» и «тулзы» — анриал все-таки игровой движок, а значит главное его предназначение — создание игр, и с этим он вполне успешно справляется. Что именно показалось вам столь ужасным для меня остается загадкой. А заменять в юнити префабы сценами — как-то слишком странно и костыльно, даже само название намекает что в они предназначены скорее для частей уровня, а не для отдельных объектов.
Можно, но основа для их работы — базовые классы пост эффектов — входят в тот же самый пакет image effects. Поэтому без его импорта придется изобрести систему пост-эффектов заново. Вероятно оно того не стоит.
В юнити пост-эффекты, например, добавляются через импорт package-а. Наверное можно рассматривать как обучающий элемент — новички сразу узнают о механизме импорта ассетов :) Да и простому 2D проекту пост-эффекты могут быть не нужны. Так что наверное не минус и не плюс, а интересная особенность :)
Создавать же префаб ноутбука на столе скриптами, как вы предлагаете — не слишком наглядно для дизайнеров. Но тут можно либо сделать кастомные инструменты, добавляющие необходимые удобства, либо построить проект так чтобы проблема префабов максимально себя не проявляла :) В любом случае это дополнительная работа и ограничения.
13 упоминаний #У***X4 в тексте (не считая название и тег) — многовато. Зачем так форсить? Статья написана с применением вышеуказанного ускорения и упоминаний могло быть в 4 раза меньше?
Unreal сам по себе весьма непростой движок, поэтому полтора года, особенно если человек начинающий, не так много. У многих инди проектов судьба печальная и зачастую не сильно зависит от используемого движка. Как говорится, "нельзя так просто взять и зарелизить свой первый проект". Конечно, базовые знания программирования (функции, циклы, переменные и т.п.) необходимы, чтобы хоть что-то реализовать на блупринтах. Блупринты хвалят, так как они предоставляют средства, которыми могут пользоваться не только программисты. В сложных проектах они тоже используются вовсю, просто основная часть сложных систем реализована на C++, а для блупринтов доступны функции взаимодействия с ними.
Проще для реализации игровой механики, меньше багов, приносимых попытками "побороть" третье измерение, выше производительность. Не будет случаев, когда из-за физики объект улетит за границы 2D мира "в глубину".
Да, сравнение Unity 5 и UE4 4.16
Готового ничего не встречал, может потому что особо не искал) Тут скорее индивидуальный подход: находим что вызывает проблемы и исправляем :)
Да, действительно есть такой, OnRenderImage называется. Вероятно имеет смысл его использовать для совсем простых пост-эффектов.
Да, знакомый подход с кэшированием, но это скорее вопрос оптимизации, и далеко не во всех проектах "обходят" встроенные средства стороной. В юнити частенько приходится многие вещи оптимизировать. Вручную создавать частицы одним эмиттером вместо сотни, "лепить" специальные отражения для воды, дабы каждая лужа сцену не рендерила сама и т.д. Основная фишка юнити — "казуальное", доступное устройство движка, и с ростом масштаба/требований проекта все больше надо воевать за производительность в ущерб "универсальности" и "удобства" :) Хотя, геймдев в целом это искусство фейка и компромиссов, так что нам не привыкать)
Compute шейдеры вполне можно использовать. Сделано даже без модификации движка, см. UE4ShaderPlugin. Но в целом, любой движок стоит выбирать исходя из требований проекта. В Unity, например, годами отсутствовал normal mapping на ландшафте, gpu skinning и instancing. Но разработчики до этого добрались и реализовали.
Что в вашем понимании есть "нормальный шейдер"? Сейчас большинство движков имеют собственную основу для системы шейдеров и материалов. Прежде всего это связано со сложными моделями освещения, многообразием комбинаций типов геометрии, освещения, материалов и поддерживаемых платформ. Проблемы с вмешательством в рендер могут возникнуть в Unity, где исходный код движка не доступен. В анриале вы можете собрать кастомный движок, добавив нужный функционал.
Так можно и про юнити с ассет стором сказать. Купил ассет, поменял название, запостил в стим! Человеческий фактор, а не изъян технологии. Если же проект грамотно построен, минус превращается в плюс. Например, дизайнеры звука могут настроить желаемое поведение звуковым эффектам через редактор Sound Cue. Например, играть случайный звук вместо единственного заданного, выбрать нужный звук в зависимости от внешних условий (скорости передвижения игрока, например) и т.д. В результате у программистов больше времени чтобы писать код и они не отвлекаются на подобные мелочи.
Зависит от данных. Если это настройки или сохраненные игры, можно написать расширение класса SaveGame. Если нужны кастомные свойства на игровых картах — пишем свой класс WorldSettings. Достаточно все поля, требующие сохранения, отметить как UPROPERTY. Для общих данных можно использовать классы DataTable и DataAsset. Для DataTable надо будет сначала описать структуру данных (создать блупринтовую или C++ структуру), а для DataAsset — унаследовать свой класс от него. Кроме встроенного редактора таблиц, в DataTable можно импортировать данные из csv файла. Также можно просто создать структуру и объявить ее как свойство эктора или компонента.
Проблема префабов — в отсутствии "наследования" объектов, а не в невозможности сохранить в файл. Насчет аниматора согласен, я чаще управлял анимацией старым способом, из кода. Но слои в демке используются. Так что да, имеет место легкая недосказанность :)
Две строчки кода скорее всего будут такими же двумя вызовами блупринта. В "запущенных" случаях, можно перенести часть реализации в код.
Лезть в игры не зная программирования бывает полезно. Некоторые разберутся из каких компонентов состоит игра, другие — начнут учиться программированию. Художники и левел дизайнеры смогут собрать простенькую интерактивную сценку. Применений блупринтам — 1000 и 1 штука. Не только лишь суровым кодом создаются проекты.
Не соглашусь насчет того, что в юнити "встроенная компонентная архитектура не применяется", ведь механика добавления компонентов на объекты, их поиск и взаимодействие (даже обращение к встроенному свойству transform или поиск объекта в сцене) — как раз использование этой самой архитектуры. Даже автоматический вызов функций Update, LateUpdate, OnGUI и т.д. тоже является ее частью.
Теперь к анриалу. В данном ключе "дизайнеры" — те, кто не пишут код, но могут менять/настраивать блупринты. Воркфлоу в анриале такой:
Редактор можно расширять плагинами, именно так делаются для него тулзы. Да, при изменении кода приходится адаптировать блупринты к сделанным в коде изменениям. От скриптов отказались, видимо, потому что весь функционал, доступный ранее в скриптах, теперь есть в блупринтах. И люди, которые раньше "боялись" программировать, теперь смогут собрать игру на более понятных для них визуальных схемах.
Обычно создается наследник класса HUD, через который идет взаимодействие механики игры и интерфейса (обмен данными, обработка событий и т.д.). Окошки и прочие элементы интерфейса создаются через Widget Blueprint-ы, которые сочетают в себе визуальную часть UI и блупринтовую логику (переменные, функции и т.д.). На старте (или по событию) наследник HUD-а создает один или несколько основных виджетов и сохраняет ссылки на них у себя в свойствах (Variables). Конкретная схема виджетов и их вложенности/взаимодействия зависит от того каким должен быть интерфейс. Анимации создаются и редактируются прямо в редакторе интерфейса. После создания пустой анимации добавляются участвующие в ней виджеты и их свойства (позиция, цвет и т.д.). Анимации воспроизводятся функцией Play Animation в блупринте этого элемента. Одна анимация может управлять сразу несколькими виджетами. Подробнее лучше смотреть какой-нибудь туториал, например UE4 UMG Animation