Comments 51
Или вы принципиально не рассматриваете то, что сделало комьюнити, а не разработчик?
Но плюс ли это? Это же все мусор для прототипирования и новичков
В Unreal тоже есть виртуальные оси, но там есть разделение на собственно оси (значения, полученные от джойстика, и т.п.) и кнопки действия. В отличие от Unity, мы привязываем оси и кнопки к функциям класса, который реализует управление персонажем. Связь создаётся через компонент UInputComponent. Такой компонент ввода есть у класса персонажа ACharacter.
Вызовом BindAxis(«MoveRight», this, &AUShooterCharacter::MoveRight) в Input Component мы привязываем нажатие кнопки MoveRight к вызову одноимённой функции движения. Не требуется каждый кадр заниматься опросом кнопки.
Также в Unreal не ограничено количество альтернативных кнопок. В Unity в Input Manager есть только основная кнопка и альтернативная. Чем больше устройств ввода в вашей игре, тем острее может быть эта проблема.
Для Unity можно приобрести плагин Rewired, который ооооооооооооочень значительно расширяет и упрощает работу с контроллерами. За пару часов можно настроить проект для работы с клавой, мышью, десятком геймпадов и под планшет.
Тут мы видим уже знакомые нам состояния Idle/Run, Jump, Dead. Но один узел совмещает в себе Idle и Run. Внутри него находится так называемый Blend Space 1D, он используется для плавного перехода анимации в зависимости от значения одной или нескольких переменных. С помощью Blend Space можно привязать скорость персонажа к переходу между анимацией Idle и Run. Кроме того, получится настроить несколько точек перехода. Например, от нуля до метра в секунду персонаж идёт медленно — это будет движение, интерполированное между анимацией Idle и Walk. А после некоторого порогового значения включается бег (Run). И всё это будет в одном узле Animation Blueprint’а, который обращается к Blend State.
Ну в юнити все эти blend tree тоже есть.
Дело в том, что так как юнити не определяет дубликаты в сцене, то с точки зрения скорости загрузки сцены и т.п. все однотипные объекты лучше инстанцировать при загрузке. Поэтому, по сути, в моём понимании, префаб стола один, а внутри него есть скрипт, берущий префаб ноутбука и создающий необходимый ноутбук, с необходимым цветом экрана. По крайней мере в UI — это точно самая адекватная практика. С 3д, тут соглашусь, если требуется baked освещение и т.п. начинаются пляски с бубном, да и редактировать такое может не очень удобно. Это тожно можно хитро обойти малой кровью, но это уже нужно знать как (да и писать что-то для движка, чтобы с ним было просто удобно работать, звучит странно)
В анреале (по рассказам, сам я с ним пока не работал) проще работать с помощью визуального программироваиня, а в юнити всё проще делать скриптами. И описанное выше делается достаточно тривиальным скриптингом. Но если вы повторяете изменения вручную, создаёте новые префабы на старом скелете, перенося скелет целиком — вы делаете что-то не так. Так как в моём понимании префаб — это по сути минимальная логическая единица, которая потом инстанцируется с параметрами. Если придерживаться этой логики, то таких проблем особо не возникает.
Обычно создается наследник класса HUD, через который идет взаимодействие механики игры и интерфейса (обмен данными, обработка событий и т.д.). Окошки и прочие элементы интерфейса создаются через Widget Blueprint-ы, которые сочетают в себе визуальную часть UI и блупринтовую логику (переменные, функции и т.д.). На старте (или по событию) наследник HUD-а создает один или несколько основных виджетов и сохраняет ссылки на них у себя в свойствах (Variables). Конкретная схема виджетов и их вложенности/взаимодействия зависит от того каким должен быть интерфейс. Анимации создаются и редактируются прямо в редакторе интерфейса. После создания пустой анимации добавляются участвующие в ней виджеты и их свойства (позиция, цвет и т.д.). Анимации воспроизводятся функцией Play Animation в блупринте этого элемента. Одна анимация может управлять сразу несколькими виджетами. Подробнее лучше смотреть какой-нибудь туториал, например UE4 UMG Animation
Стримы по созданию игр по разным аспектам.
Не сочтите за рекламу, если что.
Визуальное программирование — это не программирование. Это применимо лишь в качестве стейт-машины для анимаций, простых сценарий. В добавок, они еще и бинарные, что мешает использовать git. Для более взрослой логики, эти принты становятся абсолютно нечитаемы, и нельзя применять шаблоны проектирования.
Хороший движок отличает хорошее api, расширяемость, гибкость, простота и возможность быстро сделать тулзу.
Unreal, имхо, уже архаичный, как и Photoshop, 3DsMax, с ужасным api и интерфейсом.
Unity — далек от идеала, но развивается в нужную сторону.
ps проблем с вложенными префабами в Unity нету — вместо них теперь сцены.
pps проблема юнити — устаревший рантайм и C#
- максимально все делается кодом, встроенная компонентная архитектура не применяется
- отделяется игровая логика от движка
- для особых случаях и для левел-дизайнеров пишутся множество тулзов(они не кодят и не умеют)
- непосредственно с редактором пользуются только FX, левел-дизайнеры, и технические художники
А вот для Unreal мне не понятен воркфлоу. Кто такие «дизайнеры»? Чем занимаются программисты? Как делаются тулзы для редактора? И почему же отказались от скриптов из UDK в пользу блюпринтов?
В средней игре миллионы строк кода с постоянным рефакторингом. Я не в состоянии представить весь этот код в виде блюпринтов.
Не соглашусь насчет того, что в юнити "встроенная компонентная архитектура не применяется", ведь механика добавления компонентов на объекты, их поиск и взаимодействие (даже обращение к встроенному свойству transform или поиск объекта в сцене) — как раз использование этой самой архитектуры. Даже автоматический вызов функций Update, LateUpdate, OnGUI и т.д. тоже является ее частью.
Теперь к анриалу. В данном ключе "дизайнеры" — те, кто не пишут код, но могут менять/настраивать блупринты. Воркфлоу в анриале такой:
- если в проекте вдруг нет программистов, весь проект делается на блупринтах (лично таких случаев не встречал, но недавно был пост как раз о разработке игры таким способом)
- если в проекте есть программисты, они в зависимости от требований реализуют на свое усмотрение часть функционала в виде кода, а часть — в виде блупринтов.
Редактор можно расширять плагинами, именно так делаются для него тулзы. Да, при изменении кода приходится адаптировать блупринты к сделанным в коде изменениям. От скриптов отказались, видимо, потому что весь функционал, доступный ранее в скриптах, теперь есть в блупринтах. И люди, которые раньше "боялись" программировать, теперь смогут собрать игру на более понятных для них визуальных схемах.
Примерно какого уровня игра?
Не соглашусь насчет того, что в юнити «встроенная компонентная архитектура не применяется», ведь механика добавления компонентов на объекты, их поиск и взаимодействие (даже обращение к встроенному свойству transform или поиск объекта в сцене) — как раз использование этой самой архитектуры. Даже автоматический вызов функций Update, LateUpdate, OnGUI и т.д. тоже является ее частью.
На самом деле увы и да. Практически не применяется в любом достаточно крупном коммерческом проекте. И собственные компонентная система, и свое связывание компонентов их с объектами. И даже тупо искать объект на сцене стандартными методами очень плохая идея — нужное кэширование все равно и самому отслеживать добавление и удаление объектов на сцене.
И автоматические вызовы выше перечисленные не используются — ну вернее висит один объект в сцене которые их получает, и уже через собственную компонентную систеум диспатчит в свои компоненты.
Ибо ответ простой — все что предлагает «встроенная компонентная архитектура в Юнити» можно написать самим и оно будет работать и быстре (сильно быстрее, на порядк) и удобной.
Да, знакомый подход с кэшированием, но это скорее вопрос оптимизации, и далеко не во всех проектах "обходят" встроенные средства стороной. В юнити частенько приходится многие вещи оптимизировать. Вручную создавать частицы одним эмиттером вместо сотни, "лепить" специальные отражения для воды, дабы каждая лужа сцену не рендерила сама и т.д. Основная фишка юнити — "казуальное", доступное устройство движка, и с ростом масштаба/требований проекта все больше надо воевать за производительность в ущерб "универсальности" и "удобства" :) Хотя, геймдев в целом это искусство фейка и компромиссов, так что нам не привыкать)
А можете подсказать готовые фреймворки для такого подхода, прошедшие боевое тестирование на реальных проектах? Или каждый разработчик пишет свой велосипед?(
https://www.youtube.com/watch?v=bzHevRs-cd4
Тут участвует один из разработчиков UE. Подкаст на русском!
Меня удивляют люди которые блюпринты считают преимуществом.
"Ведь благодаря таким системам даже далекие от программирования люди могут составить схему взаимодействия объектов или связать какую-то последовательность действий" — объясните мне, зачем людям далеким от программирования лезть в разработку игр?
Главное преимущество Unity это C#. Вся его мощь и элегантность доступна в Unity. То что я делаю 2 строчками кода в UE нужно блюпринтить этажами. И вы явно не разбирались в Animator'е Unity и представили как примитивный инструмент. Вы можете смешивать анимации используя слои. К любому состоянию можете написать необходимое поведение.
В UE ужасная документация и скудный набор стандартных решений. Также не понял про ui и префабы. Любой объект можно сохранить в префабы. Unity к тому же представляет весьма удобный инструмент для создания резинового ui для множества экранов.
Проблема префабов — в отсутствии "наследования" объектов, а не в невозможности сохранить в файл. Насчет аниматора согласен, я чаще управлял анимацией старым способом, из кода. Но слои в демке используются. Так что да, имеет место легкая недосказанность :)
Две строчки кода скорее всего будут такими же двумя вызовами блупринта. В "запущенных" случаях, можно перенести часть реализации в код.
Лезть в игры не зная программирования бывает полезно. Некоторые разберутся из каких компонентов состоит игра, другие — начнут учиться программированию. Художники и левел дизайнеры смогут собрать простенькую интерактивную сценку. Применений блупринтам — 1000 и 1 штука. Не только лишь суровым кодом создаются проекты.
Зависит от данных. Если это настройки или сохраненные игры, можно написать расширение класса SaveGame. Если нужны кастомные свойства на игровых картах — пишем свой класс WorldSettings. Достаточно все поля, требующие сохранения, отметить как UPROPERTY. Для общих данных можно использовать классы DataTable и DataAsset. Для DataTable надо будет сначала описать структуру данных (создать блупринтовую или C++ структуру), а для DataAsset — унаследовать свой класс от него. Кроме встроенного редактора таблиц, в DataTable можно импортировать данные из csv файла. Также можно просто создать структуру и объявить ее как свойство эктора или компонента.
Предпочитаю сравнивать достоинства игровых движков по количеству AAA тайтлов выпущенных на нем. Проблема Unity в том, что толковых игр на нем так и не сделали, сомневающиеся могут сравнить список игр на Unity и на Unreal Engine на вики.
Так можно и про юнити с ассет стором сказать. Купил ассет, поменял название, запостил в стим! Человеческий фактор, а не изъян технологии. Если же проект грамотно построен, минус превращается в плюс. Например, дизайнеры звука могут настроить желаемое поведение звуковым эффектам через редактор Sound Cue. Например, играть случайный звук вместо единственного заданного, выбрать нужный звук в зависимости от внешних условий (скорости передвижения игрока, например) и т.д. В результате у программистов больше времени чтобы писать код и они не отвлекаются на подобные мелочи.
Что в вашем понимании есть "нормальный шейдер"? Сейчас большинство движков имеют собственную основу для системы шейдеров и материалов. Прежде всего это связано со сложными моделями освещения, многообразием комбинаций типов геометрии, освещения, материалов и поддерживаемых платформ. Проблемы с вмешательством в рендер могут возникнуть в Unity, где исходный код движка не доступен. В анриале вы можете собрать кастомный движок, добавив нужный функционал.
А как с этим дела у Unreal, насколько легко писать шейдера и вообще графику?
Ну и конечно же, через исходники движка можно с легкостью добавить что угодно. Включая шейдеры и свои фичи.
Анрил это движок в котором есть фиксированный, поставляемый разработчиками набор фич, и расширить этот набор практически невозможно. Если у вас есть идея например сделать игру с нестандартной графикой — на анриле попросту прийдётся отказаться от этой идеи.
Compute шейдеры вполне можно использовать. Сделано даже без модификации движка, см. UE4ShaderPlugin. Но в целом, любой движок стоит выбирать исходя из требований проекта. В Unity, например, годами отсутствовал normal mapping на ландшафте, gpu skinning и instancing. Но разработчики до этого добрались и реализовали.
И потому было интересно почитать про Blueprints и код.
В том же Гудини есть Vex(Cи-подобный язык) и VOP-нетворки(как раз это самое визуальное программирование), который генерит тот же самый vex код(посмотрев который ты можешь переписать на чистом vex если перфекционист или уж так критична скорость).И ситуация такова что ты можешь писать код, тут же обращаться к нему с Vop и наоборот, потому как есть по сути одно целое.Vop удобен как для прототипирования так и в некоторых моментах читаемостью, и наоборот циклы например удобнее реализовать кодом.
Но никто не заставляет тебя строго использовать тот или иной метод.
Имхо за этим прекрасное будущее: в скорости и свободе разработки, который дает этот подход.
И это благо и по причине таковой, что даже простой дизайнер может немного начать разбираться в программировании и слабать нужный инструментарий под себя.
Стоит ли ожидать наплыва прогеров-индусов от дизайнеров? Очевидно нет.А вот определённую часть работы с прогера они снять могут.
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
Unreal Engine на ноутбуке ценой до 60к — сказка.
То же касается iMac до 2014-15 годов, Mac mini, к сожалению, тоже.
UE4 для Unity-разработчиков