Pull to refresh

Comments 51

Кхм, насчет готового код и шаблонов, это помоем намного лучше развито именно у unity.
Или вы принципиально не рассматриваете то, что сделало комьюнити, а не разработчик?
Качество ассетов в unity asset store — очень разное, как и способы реализации и стиль кода. Анриаловские шаблоны рассмотрены в статье, т.к. сразу идут в комплекте движка, имеют встроенные мини-туториалы о их устройстве и единый стиль оформления, плюс построены на базе Gameplay Framework-а и не требуют каких-либо внешних компонентов.
Gameplay Framework — не внешний компонент?
Он входит в состав движка, его не надо отдельно скачивать или покупать.
У юнити тоже такие встроенные ассеты есть, которые можно установить вместе с движком
Но плюс ли это? Это же все мусор для прототипирования и новичков
В юнити пост-эффекты, например, добавляются через импорт package-а. Наверное можно рассматривать как обучающий элемент — новички сразу узнают о механизме импорта ассетов :) Да и простому 2D проекту пост-эффекты могут быть не нужны. Так что наверное не минус и не плюс, а интересная особенность :)
Ага, стандартные ассеты поделены на пакеты. (Надеюсь вы не думаете, что нельзя сделать свой пост эффект без импорта стандартных ассетов?)
Можно, но основа для их работы — базовые классы пост эффектов — входят в тот же самый пакет image effects. Поэтому без его импорта придется изобрести систему пост-эффектов заново. Вероятно оно того не стоит.
Вроде как не надо изобретать ничего:) Есть метод который обновляется из бехавиора, если весит на камере, вроде как RenderImage, в параметрах к нему идет кажись буфер изображения, его перекидываете в свой шейдер, и как душе угодно редактируете, и вуаля пост эффект, ничего не нужно изобретать:) И кстати оно стоит того, можно «облегчить» эффект, и контролировать его с учетом нужд архитектуры:) P.S. Но unreal мне нравится больше, от того что исходники разложены по полочкам, что мне по душе, плюс вроде реализован многопоточный рендер, который по отзывам не так выгоден, но это все равно круто:)

Да, действительно есть такой, OnRenderImage называется. Вероятно имеет смысл его использовать для совсем простых пост-эффектов.

Поправьте если ошибаюсь, но вроде пост эффекты можно сделать только через OnRenderImage:) Я же говорю, кидаете параметры к себе в шейдер и делаете что хотите, от глубины, до позиций пикселя) Я из unreal к себе в проектик fog переписал:) И все работает:)))
Почему только для простых?
В 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) тут я бы поспорил, ведь руками создавать второй префаб панели, чтобы поменять текст кнопки, или добавлять новый функционал, звучит как костыль. Она решается может не слишком удобно, и решается скриптингом. События, инстанцирование и правильные использование всего этого, позволяют собирать окна, как в конструкторе, но скриптингом (я уверен, что визуальное программирование в анреале лучше), но учитывая особенности юнити, не особо оптимально делать второй префаб стола, да и просто в ручную раскидывать однотипные объекты на сцене.

Дело в том, что так как юнити не определяет дубликаты в сцене, то с точки зрения скорости загрузки сцены и т.п. все однотипные объекты лучше инстанцировать при загрузке. Поэтому, по сути, в моём понимании, префаб стола один, а внутри него есть скрипт, берущий префаб ноутбука и создающий необходимый ноутбук, с необходимым цветом экрана. По крайней мере в UI — это точно самая адекватная практика. С 3д, тут соглашусь, если требуется baked освещение и т.п. начинаются пляски с бубном, да и редактировать такое может не очень удобно. Это тожно можно хитро обойти малой кровью, но это уже нужно знать как (да и писать что-то для движка, чтобы с ним было просто удобно работать, звучит странно)

В анреале (по рассказам, сам я с ним пока не работал) проще работать с помощью визуального программироваиня, а в юнити всё проще делать скриптами. И описанное выше делается достаточно тривиальным скриптингом. Но если вы повторяете изменения вручную, создаёте новые префабы на старом скелете, перенося скелет целиком — вы делаете что-то не так. Так как в моём понимании префаб — это по сути минимальная логическая единица, которая потом инстанцируется с параметрами. Если придерживаться этой логики, то таких проблем особо не возникает.
Пример про префабы был образный, чтобы показать суть проблемы.
Создавать же префаб ноутбука на столе скриптами, как вы предлагаете — не слишком наглядно для дизайнеров. Но тут можно либо сделать кастомные инструменты, добавляющие необходимые удобства, либо построить проект так чтобы проблема префабов максимально себя не проявляла :) В любом случае это дополнительная работа и ограничения.
Можете немного рассказать про систему, используемую для создания UI? Окошки / анимация / архитектура

Обычно создается наследник класса HUD, через который идет взаимодействие механики игры и интерфейса (обмен данными, обработка событий и т.д.). Окошки и прочие элементы интерфейса создаются через Widget Blueprint-ы, которые сочетают в себе визуальную часть UI и блупринтовую логику (переменные, функции и т.д.). На старте (или по событию) наследник HUD-а создает один или несколько основных виджетов и сохраняет ссылки на них у себя в свойствах (Variables). Конкретная схема виджетов и их вложенности/взаимодействия зависит от того каким должен быть интерфейс. Анимации создаются и редактируются прямо в редакторе интерфейса. После создания пустой анимации добавляются участвующие в ней виджеты и их свойства (позиция, цвет и т.д.). Анимации воспроизводятся функцией Play Animation в блупринте этого элемента. Одна анимация может управлять сразу несколькими виджетами. Подробнее лучше смотреть какой-нибудь туториал, например UE4 UMG Animation

Кстати, недавно наткнулся на один очень интересный канал на ютубе — Unreal Engine Rus
Стримы по созданию игр по разным аспектам.
Не сочтите за рекламу, если что.
Blueprint'ы — это разве плюс движка?
Визуальное программирование — это не программирование. Это применимо лишь в качестве стейт-машины для анимаций, простых сценарий. В добавок, они еще и бинарные, что мешает использовать git. Для более взрослой логики, эти принты становятся абсолютно нечитаемы, и нельзя применять шаблоны проектирования.

Хороший движок отличает хорошее api, расширяемость, гибкость, простота и возможность быстро сделать тулзу.
Unreal, имхо, уже архаичный, как и Photoshop, 3DsMax, с ужасным api и интерфейсом.
Unity — далек от идеала, но развивается в нужную сторону.

ps проблем с вложенными префабами в Unity нету — вместо них теперь сцены.
pps проблема юнити — устаревший рантайм и C#
Да, блупринты — весьма себе плюс. Это вам любой дизайнер подтвердит. Визуальный «скриптинг» вполне себя зарекомендовал, и, например, часто используется для описания материалов (шейдеров), причем не только в Unreal. Часть «сложной» логики можно реализовать кодом и сделать доступной для блупринтов, так последние станут менее запутанными и более читаемыми. Про «архаичность» и «тулзы» — анриал все-таки игровой движок, а значит главное его предназначение — создание игр, и с этим он вполне успешно справляется. Что именно показалось вам столь ужасным для меня остается загадкой. А заменять в юнити префабы сценами — как-то слишком странно и костыльно, даже само название намекает что в они предназначены скорее для частей уровня, а не для отдельных объектов.
Почти везде для Unity воркфлоу применяется такой:
  • максимально все делается кодом, встроенная компонентная архитектура не применяется
  • отделяется игровая логика от движка
  • для особых случаях и для левел-дизайнеров пишутся множество тулзов(они не кодят и не умеют)
  • непосредственно с редактором пользуются только 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 штука. Не только лишь суровым кодом создаются проекты.

Что на счет хранения данных в UE?)

Зависит от данных. Если это настройки или сохраненные игры, можно написать расширение класса SaveGame. Если нужны кастомные свойства на игровых картах — пишем свой класс WorldSettings. Достаточно все поля, требующие сохранения, отметить как UPROPERTY. Для общих данных можно использовать классы DataTable и DataAsset. Для DataTable надо будет сначала описать структуру данных (создать блупринтовую или C++ структуру), а для DataAsset — унаследовать свой класс от него. Кроме встроенного редактора таблиц, в DataTable можно импортировать данные из csv файла. Также можно просто создать структуру и объявить ее как свойство эктора или компонента.

А в unity подключил sqlite и радуешься.

Предпочитаю сравнивать достоинства игровых движков по количеству AAA тайтлов выпущенных на нем. Проблема Unity в том, что толковых игр на нем так и не сделали, сомневающиеся могут сравнить список игр на Unity и на Unreal Engine на вики.

Каждая третья мобильная игра на Unity.
99.9% мобильных игр не требуют графику как для РС.
Блюпринт в UE несет огромный минус, это как ютуб в котором все режиссеры, как инстаграм где все супер фотографы. А вот и очередь за программистами. Может и грубо звучит но подобные «упрощалки» влекут за собой появление тонны кривого и однотипного… вна. Сейчас, если сказать, что ты фотограф или дизайнер, так уже и не удивишь, каждый 1.01ый тоже.
Не думаю, что блюпринты создавались для программистов, скорее для гейм-дизайнеров. В крупных проектах обычно пишется множество софта, для тех, кто не умеет программировать.

Так можно и про юнити с ассет стором сказать. Купил ассет, поменял название, запостил в стим! Человеческий фактор, а не изъян технологии. Если же проект грамотно построен, минус превращается в плюс. Например, дизайнеры звука могут настроить желаемое поведение звуковым эффектам через редактор Sound Cue. Например, играть случайный звук вместо единственного заданного, выбрать нужный звук в зависимости от внешних условий (скорости передвижения игрока, например) и т.д. В результате у программистов больше времени чтобы писать код и они не отвлекаются на подобные мелочи.

В анриле на подцепить нормальный шэйдер, ни свою шадоу-мапу не отрендерить. Анрил это движок для тех, кто может с лёгкостью отказываться от фич.

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

В Unity средненький программист может вытворять с графикой довольно многое, и скорости прибавляет не только C# и скрытие рутины за ShaderLab но и встроенный frame debugger. Обидно что нет Occlusion queries, да и instancing появился совсем недавно. я за неделю написал упрощённый clustered forward rendering, только с поинт лайтами(написал бы полноценный но мне и этот не нужен).
А как с этим дела у Unreal, насколько легко писать шейдера и вообще графику?
Свой просчет освещения можно сделать. Даже на БП, если скилла достаточно. Редактор шейдеров в анриале нодовй, который позволяет очень многое и поддерживает вставки кодом.

Ну и конечно же, через исходники движка можно с легкостью добавить что угодно. Включая шейдеры и свои фичи.
Невозможно например написать свой DOF, невозможно поменять модель освещения, опять же как я говорила — невозможно отрендерить свою шадоу-мапу и сделать EVSM/MSM тени, запустить компьют шэйдер. А в юнити это всё можно без особых усилий.

Анрил это движок в котором есть фиксированный, поставляемый разработчиками набор фич, и расширить этот набор практически невозможно. Если у вас есть идея например сделать игру с нестандартной графикой — на анриле попросту прийдётся отказаться от этой идеи.

Compute шейдеры вполне можно использовать. Сделано даже без модификации движка, см. UE4ShaderPlugin. Но в целом, любой движок стоит выбирать исходя из требований проекта. В Unity, например, годами отсутствовал normal mapping на ландшафте, gpu skinning и instancing. Но разработчики до этого добрались и реализовали.

Интересная статья, далек от геймдева, правда порой лабаю ассеты для Houdini Engine для связки с другим 3д софтом и кто знает чем завтра будешь заниматься, тем паче HE для Unity и для UE присутствует.
И потому было интересно почитать про Blueprints и код.
В том же Гудини есть Vex(Cи-подобный язык) и VOP-нетворки(как раз это самое визуальное программирование), который генерит тот же самый vex код(посмотрев который ты можешь переписать на чистом vex если перфекционист или уж так критична скорость).И ситуация такова что ты можешь писать код, тут же обращаться к нему с Vop и наоборот, потому как есть по сути одно целое.Vop удобен как для прототипирования так и в некоторых моментах читаемостью, и наоборот циклы например удобнее реализовать кодом.
Но никто не заставляет тебя строго использовать тот или иной метод.
Имхо за этим прекрасное будущее: в скорости и свободе разработки, который дает этот подход.
И это благо и по причине таковой, что даже простой дизайнер может немного начать разбираться в программировании и слабать нужный инструментарий под себя.
Стоит ли ожидать наплыва прогеров-индусов от дизайнеров? Очевидно нет.А вот определённую часть работы с прогера они снять могут.
А как обстоят дела с модульностью в анриале?
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
Процесс геймдизайна Unity в разы менее требовательный по железу, чем Unreal Engine 4. Хотя бы из-за подходов к рендеру. Анрил «компилирует» на ходу, а это значит редактором особо не попользуешься, если проц. и карточка не топовые…

Unreal Engine на ноутбуке ценой до 60к — сказка.

То же касается iMac до 2014-15 годов, Mac mini, к сожалению, тоже.
Sign up to leave a comment.