Создание игры. Прошу совета и помощи
Здравствуйте, друзья!
Как и многие среди вас, являюсь неизлечимым геймером.
В последнее время обнаружил, что ААА-игры приносят всё меньше и меньше удовольствия, а чаще, так и вообще не приносят оного.
Так я погрузился в тему эмуляторов ретро консолей. 40+ часов в восьмибитного Darkwin Duck? - Не вопрос! Столько же в каждую часть Червяка Джима с шедевральной Mega Drive? - Изи! Теперь вот ещё и Flashback...
Давно мечтал сделать что-то своё, но тогда я сильно был погружён в дарксоулсы, и понимал что вдохновляясь этим, сделать что нибудь подобное нереально.
Теперь же увидев насколько могли ребята из 90-ых, вера в свои возможности немного вернулась.
Хотелось бы попробовать сделать геймплейно просто 2D платформер, аля Червяк Джим, визуально выполненное в технике ротоскопии как Mortal Kombat/Flashback и иже с ними.
Только представьте, насколько можно всё сделать плавно и красиво с нынешними технологиями.
Реально я силён по части звукового оформления. У меня есть студия звукозаписи и сделать красивую оригинальную/авторскую озвучку я смогу точно: и музыку и FX-ы.
Наверняка, что-то сумею освоить в процессе.
Может кто-то захочет принять участие.
Может присоветуете движок и мануалы.
Буду признателен за любой отклик!
Всем благ и улыбок!)
В Питере шаверма и мосты, в Казани эчпочмаки и казан. А что в других городах?
Мы постарались сделать каждый город, с которого начинается еженедельный заед в нашей новой игре, по-настоящему уникальным. Оценить можно на странице совместной игры Torero и Пикабу.
Реклама АО «Кордиант», ИНН 7601001509
Новая игра!
Здравствуйте. Хочу представить свою игру.Название- старинное зло.Жанр - визуальная новеллаДвижок- UnrealEngineПока ещё в разработке.
Godot Engine. Обзор игрового движка
Всем привет, дорогие товарищи! Представляю вашему вниманию большой обзор игрового движка Godot Engine. Надеюсь, вам будет интересно :)
Для ЛЛ: многабукв, но можно пролистать в конец поста – там есть список преимуществ и недостатков движка. Godot классный! Попробуйте Godot!
Этот материал актуален для молодых игроделов –кто делает первые шаги в индустрии и мучительно выбирает движок. А также для тех разработчиков, кто устал вносить денежки владельцам проприетарного ПО и хотел бы пересесть на что-то подешевле.
Статья написана с целью познакомить сообщество с игровым движком Godot, а не сравнить его возможности с конкурентами, поэтому попрошу воздержаться от холивара на тему «чьи поезда поездатее».
Мною было приложено много усилий, чтобы обзор получился ёмким и более-менее объективным. Это не копипаста чьей-то более ранней статьи, обзор основан на личном опыте использования движка.
Немного истории
Разработкой движка Godot (читается «годо») с 2007 года занимались Хуан Линетски и Ариель Манзур. Стоит отметить, что в те бородатые времена движок был проприетарным, закрытым и создавался для нужд частных заказчиков.
В 2014 году авторы выпустили обновлённую версию движка под лицензий MIT и выложили исходники на GitHub, разработка перешла сообществу Godot Engine Community, и продолжается до сих пор.
Репозиторий Godot Engine Community на GitHub
Обзор
Godot Engine – очень компактный (~74MB), быстрый и оптимизированный движок, позволяющий создавать с нуля любую игру любого жанра. Он кроссплатформенный, мультифункциональный, бесплатный, опенсорсный.
Кстати «с нуля» здесь ключевое. В базовой сборке Godot не имеет шаблонов для игровых процессов, однако есть огромное количество плагинов, аддонов и внешних библиотек, которые могут помочь со стартом. Доступ к репозиторию осуществляется прямо из окна запуска движка. Просто переходим на нужную вкладку и листаем ;)
Он достаточно дружелюбен к новичкам. Элементы документации продублированы в трёх местах, что обеспечивает быстрый доступ к справке «без отрыва от производства». Так же в движок зашиты ссылки на он-лайн ресурсы, которые помогут вам в решении большинства проблем.
Несмотря на свою легковесность, Godot обладает необходимым и достаточным функционалом разработки (об этом ниже), а так же берёт на себя базовые оптимизационные задачи, такие как: управление памятью и ресурсами компьютера, интеграция устройств ввода, сборка и оптимизация продукта под различные платформы – от мобильных, до консолей.
При этом базовая сборка не тащит за собой «ваще все библиотеки, которые только есть в природе» – вплоть до того, что в ней отсутствуют инструменты для билда. Godot – это конструктор. Он не знает, чем вы будете заниматься, поэтому предоставляет функционал разработки… и… всё! Остальное вы докачиваете сами по мере необходимости.
Периодически в этих ваших интернетах на форумах и у обзорщиков проскальзывает снисходительная ремарка «Godot – движок для первой игры, и всё». Это не так. Godot – высокоуровненвый профессиональный инструмент, достаточно дружелюбный, но своеборазный и сложный в освоении, если вы хотите нарисовать что-то сложнее пиу-пиу платформера.
Среда разработки
Godot «из коробки» обладает всеми необходимыми компонентами для разработки, отладки, тестирования и конструирования игры, не требует использования дополнительного ПО для создания программной и архитектурной составляющих (разумеется, вам в любом случае потребуются программы для создания визуального контента, звуковых ассетов, etc.).
Однако, если по какой-то причине, встроенные инструменты вас не устраивают, вы легко можете воспользоваться привычным. Godot умеет дружить со множеством внешних редакторов и IDE.
Для воплощения ваших самых смелых идей он имеет 2D и 3D пространство со стандартным набором классов и объектов, а так же редактор скриптов и два редактора шейдеров — для прямого программирования и визуальной настройки. Поведение любого класса вы можете расширять и/или изменять по мере надобности.
Об особенностях рендера и визуальной среды ниже.
Редактор скриптов обладает возможностями дополнения кода, авто-отступами, подсветкой синтаксиса, быстрым доступом к API движка и докам.
Интерфейс приятный, лакончиный и довольно интуитивный:
Внутренние ресурсы проекта
Основным объектом для программных манипуляций является дерево «сцен» и «узлов». Узлом может являться как самостоятельный объект, так и группа объектов. Прелесть заключается в том, что любой из узлов в любой момент времени можно изолировать в самостоятельный компонент («сцену»). Поэтому при разработке можно быстро и безболезненно редактировать, масштабировать или полностью менять структуру проекта и/или его отдельных модулей.
Все игровые ресурсы (графические и звуковые ассеты, скрипты, конфиги, шейдеры, etc.) хранятся в файловой системе как набор файлов, не являясь частью БД или иерархических компонентов структуры самого движка. К файловой системе можно обращаться как непосредственно средствами вашей ОС, так и из редактора проекта.
Возможно, вам трудно осознать преимущества этого подхода, поэтому отмечу, что упрощённая система хранения данных обеспечивает лёгкий доступ всех членов команды разработчиков ко всем ассетам (мы не зависим от версии БД, текущей версии продукта и даже версии самого движка!), а так же сильно облегчается контроль версий — особенно если применяете внешние системы управления.
Скрипты
Godot исользует собственный высокоуровневый динамически типизированный скриптовый язык программирования — GDScript, который является плодом порочной связи гибридом Python и Lua.
Язык специализировался и оптимизировался под ранее упомянутую архитектуру систем сцен и узлов, однако если по какой-то причине вам хочется писать на другом языке (допустим, не хватает каких-либо инструментов, или вы просто не хотите осваивать новый синтаксис), Godot умеет интегрировать другие языки программирования, в частности C#, C++, Rust.
Помимо этого (начиная с версии 3.0) присутствует компонент для визуального программирования — Visual Scripting. Про него не могу ничего сказать, не приходилось пользоваться, но, думаю, это легко нагуглить.
Идеология движка имеет строгое ограничение: один узел — один скрипт. Однако, если вам необходимо менять поведение и/или состояние объекта в зависимости от игрвого состояния, Godot любезно предоставляет возможность заменять один скрипт на другой «на лету» или пользоваться внешними скриптами, которые вообще не привязаны ни к одному узлу — например, это могут быть списки оружия, брони и соответствующее им поведение, которое подхватывается из мирно дремлющего скрипта активным и применяется.
Визуализация
Графическая система — OpenGL ES. Для рендеринга 3D-сцен применяются технологии order-independent transparency, normal mapping, specularity, полноэкранные постэффекты типа FXAA, bloom, DOF, HDR, гамма-коррекции, distance fog, динамические тени на основе shadow maps и другие.
Отдельно стоит отметить превосходную симуляцию освещения и постобработки. В возможностях манипуляций со светильниками Godot не уступает движкам, специализирующимся на кинематографических эффектах для игр.
В отличие от многих других движков, которые имитируют 2D-среду на 3D пространцстве, 2D компонент Godot полностью изолирован, оптимизирован и имеет свой собственный набор классов и объектов. Следствием этого является компактность и быстродействие готового игрового продукта (мы не тащим с собой тяжёлые 3D-объекты и обвязку к ним там, где это не требуется), а так же удивительная лёгкость манипуляций с 2D компонентами в процессе разработки.
Помните, выше упоминалось, что Godot поддержит вас в любых самых сумасшедших начинаниях? ;) Стартуя работу с 2D сценой, вы легко можете добавить в неё 3D объекты или целые блоки, воспользовавшись многоуровневой системой вьюпортов. Благодаря изоляции 2D и 3D пространства (и, разумеется, многопоточности) компоненты не мешают друг другу и не тормозят работу продукта. В обратную сторону это тоже работает ;)
Игровая физика
Физический движок для 2D и 3D тоже уникальный и разработан с нуля, что позволило добиться требуемого уровня оптимизации физической подсистемы. Реализованы возможности рейкастинга, обнаружение столкновений, динамики твёрдых тел и соединений между ними. Так же имеется обширный арсенал инструментов, осуществляющих кинематику.
Кстати, объекты предназначенные для распознавания физических взаимодействий, полностью изолированы от визуализационных, что облегчает манипуляции с теми и другими и гарантирует, что вы не поломаете визуал своего сложного десептикона столкновением с автоботом.
К сожалению, в версиях движка 3.0 — 3.5 (к настоящему моменту самая свежая из стабильных) на 2D пространстве отсутствует физика частиц — поведение имитируется, оставаясь не более, чем визуальным эффектом. Честной физики мы тут не увидим. В Godot 4.0 этот компонент улучшен, но это всё ещё альфа — имейте это в виду, если захотите поиграть с физикой частиц в новой версии движка. Для 3D всё в порядке.
Платформы
Напоминаю, для того, чтобы сбилдить проект вам сперва нужно скачать и настроить соответствующий компонент. Выбор при этом у вас впечатляющий. Godot поддерживает Windows (и UWP OS), MacOS, X11 (Linux, BSD), Android OS, iOS, HTML5. Также можно производить экспорт на другие платформы вручную через компилирование движка для SDK целевой платформы.
Система ввода поддерживает клавиатуру, мышку, геймпад и сенсорный экран (разные устройства могут быть назначены на абстрактное действие, и оно будет рассматриваться независимо от использованного метода ввода).
Подведём итоги
Здесь перечислены плюсы и минусы движка в голом виде — без дополнительных библиотек и плагинов, как будто вы его только что скачали.
Плюсы:
- компактность;
- MIT лицензия;
- открытый код;
- не трубет установки;
- кроссплатформенность;
- гибкость;- универсальность;
- быстродействие;
- многопоточность;
- высокая оптимизация;
- эффективное управление ресурсами компьютера;
- удобство для использования;
- быстрый доступ к справке и внешним библиотекам;
- возможность взаимодействия с компонентами управления из вашего скрипта (например, можно статистику смотреть не на выделенной панели, а вывести прямо во вьюпорт игры).Минусы:
- скундый набор инструментов визуальной разработки;
- отсутсвие предустановленных тимплейтов;
- отсутствие встроенных инструментов для билда;
- неудобные инструменты вёрстки диалоговых окон;
- слабые AR/VR компоненты;
- осутствие физики для 2D частиц;
- отсутствие возможности редактирования мешей и уровней сглаживания;
- низкая популярность в России (очень мало материалов на русском языке).
Благодарю за внимание! Надеюсь, вам было интересно в общих чертах познакомиться с Godot. Если у вас остались вопрсы, можете задать их в комментах, постараюсь ответить на все :)
Всем хорошего дня, вдохновения и успехов в освоении Godot!
P.S.: Следующим постом выложу полезные материалы для новичков с кратким описанием полезности.
P.P.S.: К сожалению, невозможно запихать в один обзор всю полезную и интересную информацию, поэтому в перспективе планирую сделать подробное описание каждого блока с разбором функциональных компонентов. Пожалуйста, посигнальте в комментах, если эта информация вам интересна.
Похоже верха нашей страны взялись за игровую индустрию всерьёз и надолго
В Госдуме совсем недавно предложили создать собственный игровой движок. С инициативой выступил заместитель председателя комитета Госдумы по информационной политике, информационным технологиям и связи Антон Горелкин.
Товарищ депутат выразил опасения о судьбе Atomic Heart, игры от московской студии Mundfish. Он верит, что проект выстрелит и будет качественным, но напомнил, что игра разрабатывается на Unreal Engine.
«Atomic Heart разрабатывается на игровом движке Unreal Engine, который принадлежит американской компании Epic Games. В начале марта она присоединилась к санкциям против России и прекратила продажу своих игр. Доступ к движку для российских разработчиков пока сохраняется, но в любой момент может быть прекращен. Та же история с другим стандартом игровой индустрии – движком Unity, который также принадлежит американцам», — подчеркнул Горелкин.
Он признал, что конкурентоспособных аналогов у России пока нет. Поэтому в сложившейся ситуации в России нужно в срочном порядке создавать свой игровой движок.
«Это должно быть open-source решение, которое российский геймдев сможет бесплатно использовать для своих проектов. Считаю это приоритетной задачей в части государственной поддержки отечественного игрового рынка, поэтому направил в Минцифры РФ предложение обсудить с отраслью эту идею и механизмы её скорейшей реализации», — написал Горелкин.
И вы знаете, всё это вызывает достаточно спорные чувства. С одной стороны, инициатива благая во всех смыслах. И людям в сфере IT будет чем заняться, у них будет бесценный опыт разработки движка с нуля, подготовки инструментария к нему. Для инди-разработчиков это тоже плюс, ибо имея стандартизированную платформу проще подходить к самой разработке, так как все будут понимать, как на ней работать.
С другой же стороны, всё упирается в несколько моментов. Первый и самый очевидный — а будут ли реально разрабатывать этот движок? Или его концепт будут переосмыслять раз 15, осваивая бюджетные средства. Вторым моментом, естественно, является качество итоговой продукции. Люди в крупных студиях не просто так отказываются от внутренних движков в пользу Unreal Engine 5. Вот возьмите CD Project Red даже. Это действительно крутой, навороченный и универсальный движок, на котором можно делать почти что угодно. Смогут ли наши родить что-то хотя бы уровня Unity — я не знаю, но последить за этим будет любопытно.
Автор: Павел Широков
Подписывайтесь на наш блог, чтобы не пропустить новые интересные посты!
Поиск исходников или движка Virtools 2.1
Доброго времени суток.
Ищу исходники, утилиты и прочее связанное с движком Virtools 2.1 на котором были созданы игры Syberia, Still Life от Микроидс. Несколько дней шерстил поисковик, но кроме упоминаний ничего не нашел. Вдруг кто-то знает где можно найти. Исходя из упоминаний на сайтах, движок(конструктор) выходил на дисках, возможно где-то лежит СД образ.
Unreal Engine vs Unity Engine
Я рассмотрю оба пациента со стороны моего опыта работы с ними и общедоступной информации. Все нижеуказанные аргументы являются личным, субъективным мнением основаным на объективной реальности и предоставленных фактах, поэтому возможны неточности, либо упущения.
Для себя я определился с тем, кто лучше, однако для некоторых проектов я бы выбрал один движок, а для некоторых другой.
К слову, это самая крупная статья по этой теме в интернете (на рус. и англ. языке), по крайней мере среди тех, что я смог найти.
Также пост имеет одну рекламную интеграцию, ради которой, в сущности, и писался этот пост, т.к. администрация пикабу верно заметила, что плюсики - это не та оплата, которая интересна, чтобы писать крупные, полезные и интересные посты, поэтому прошу отнестить к этому с пониманием, так как данная интеграция дополняет взгляд на проблему. Требования сообщества требуют того, чтобы ссылка была либо в начале, либо в конце поста, поэтому я ставлю её тут: это ссылка плагин для Unity - Fast Data View.
Пост построим по типу: название рассматриваемой части движка + пояснение.
Комфортно-минимальные системные требования
Юнити: видеокарта на 2гб+, 4-8 гб оперативы, проц 2+ ядра на 2.5 ГГЦ+
UE4: видеокарта на 2гб+, 8-16 гб оперативы, проц 4+ ядра на 3 ГГЦ+
Это, в общем, требования для ПК программиста. Конечно, все зависит от запущенности вашего проекта и загруженности сцен, которые вы запускаете, но этих характеристик хватит чтобы, как минимум, запускать ваши фичи на тестовой сцене. Но даже на загруженных сценах можно отключить, что сильно ест ресурсы, и запустить их для проверки.
Оперативная память и её текучесть
На всех движках память может течь. Это никак не победить щелчком пальца, поэтому внимательно следите за вашим кодом, чтобы это пресечь.
Так или иначе, когда вы много раз перезапускаете сцены часто память утекает, поэтому вы можете найти от чего именно это происходит (что может занять прилично времени) и исправить, либо использовать программы для очистки оперативной памяти (в гугле ищите). Они помогают неплохо, довольно быстро очищают утёкшую память, что лишает необходимости перезапускать окно редактора для очистки памяти.
Однако я не заметил, чтобы UE хоть как-то освобождал память самостоятельно в отличии от Unity.
Но у UE есть еще один грех: бывает, что вы откроете какую-то большую сцену и она откроется нормально, потом закроете UE, попытаетесь открыть ииии... он не открывается! Выпадает с ошибкой, потому что оперативной памяти ему не хватило (такое бывает, если ссылочная масса плохая). Приходится очищать Intermediate папку, чтобы не открывало эту сцену сразу. Можно, конечно, установить себе просто 64-128 гб и не ловить таких проблем.
Физические размеры проекта
Изначальные размеры проектов не шибко велики, но как только вы начинаете пихать ассеты, проект копит всякий мусор, то размер резко выростает, хотя это происходит и незаметно.
Проблема большого размера проектов заключена только в том, что в случае, если вы скачиваете проект с удалённого Git сервера - это может занять очень много времени.
От того, что движок UE открыт, то скорее всего вы будете его править, поэтому и хранить дополнительную версию своего собственного движка вы будете также в отдельном репозитории (либо как ветку к оригинальному гиту движка). Поэтому для подключения к работе удалённо человеку нужно будет качать и ваш собственный движок.
Примерные размеры движка UE - 70 гб.
Примерные размеры движка Unity - 2 гб.
Но так же папка GIT\SVN и Intermediate в UE весят просто безумно много потому что все предыдущие версии ассетов там хранятся, что позволяет вам смотреть версии блупринтов через Version Check (который, к слову, очень долго грузится. По 2 минуты на каждое открытие, потому что сделано настолько топорно, что тупо грузит все данные что есть, а потом отображает, вместо того, чтобы грузить указанное количество версий ДО). А сами блупринты весят очень много относительно скриптов в юнити, поэтому и размеры проекта отличаются разительно.
Также папка Intermediate есть и в директории проекта и в директории движка и они обе копят мусор бесконечно. Т.е. для нормальной работы в UE вам нужно где-то 300-500 гб. свободных.
GIT\SVN\Система контроля версий
Основная тема, по которой UE просто в салат проигрывает и по которой многие крупные команды просто дропают UE и уходят на другие движки.
Дело в том, что все ассеты Unreal (кроме кода), включая блупринты НЕ МЁРЖАТСЯ. Т.е. если вы изменили что-то в блупринте какого-либо объекта, и кто-то уже изменил его и залил в GIT, то у вас есть возможность либо взять его изменения и по памяти (либо достав автосейв из папки проекта) копировать абсолютно всё, что вы писали и надеятся, что никто в этот момент ещё раз не залил этот ассет, иначе вам придётся всё повторять и снова надеятся, что никто его не изменит.
Т.е. ситуация такая:
ᅠ1. Вы добавляете в блупринт какой-то код минут 10
ᅠ2. Кто-то наверняка что-то залил в гит в это время, поэтому вы закрываете редактор (чтобы залить в гит, потому что с открытым редактором нельзя сделать pull из гита (отдельный лол))
ᅠ3. Делаете pull и обнаруживаете конфликт вашего блупринта - похоже кто-то его изменил! У вас есть вариант: взять вариант из гита (потеряв свои изменений), просто перетереть чужую работу своей версией (этот человек будет не рад до уровня жалобы начальнику, что вы немного оборзели).
ᅠ4. Допустим, вы берете из гита версию. Дальше вы открываете редактор, минут 5 добавляете свои прошлые изменения, еще минуты 2 проверяете, что все работает.
ᅠ5 .Закрываете редактор.
ᅠ6. Снова пытаетесь сделать pull и снова кто-то перезалил файл!
ᅠ7. И вы вот так вот маструбируете ассетом туда сюда, тратя кучу времени и нервов, чтобы залить свою работу.
По моему опыту в работе небольшой командой (6-7 человек) бывало, что приходилось сделать 4 итерации такие, чтобы залить свою работу. А если в команде человек 50? А ведь некоторые сущности Unreal существуют в одном экземпляре, типа GameInstance, GameMode, PlayerController, PlayerState, GameState.
С помощью SVN вы можете заливать свои ассеты без pull-а (т.е. не закрывая редактор), но вы просто перетираете ту версию, которая там лежит (но в SVN сложно с фичами и ветками работать) Т.е. это вариант для дизайнеров, которые сами со своими файлами работают и туда никто не лезет.
Также не забывайте, если ссылочная масса блупринтов у вас очень плохая, то редактор у вас будет открываться по 5 минут. Т.е. времени на все эти абсолютно бесполезные телодвижения уходит просто гора.
А еще есть фишка, что если у вас блупринтовый класс наследуется от кодового класса, и вы в кодовый класс добавили переменную и назначили ей какое либо значение и залили в гит кодовый класс, а потом кто-то залил блупринт наследуемый от этого класса (до того, как взял ваш класс), то Unreal перепишет ваше значение на дефолтное значение для переменной и вы будете безумно долго соображать, в чём же проблема. Таких фишек на самом деле масса.
Data view/удобное отображение данных ассетов для геймдизайнеров и программистов
Постоянно в процессе разработки любой игры есть необходимость настраивать баланс. Баланс между мобами, оружием, умениями, фракциями и так далее. Какие инструменты для удобной настройки баланса могут предложить нам UE и Unity?
Общее:
Вы можете открывать ручками каждый ассет и сравнивать их переменные между собой, имея уйму вкладок на экране. Это очень долго и тупо.
UE:
Для хранения систематизированных данных в Анриле есть только DataTable. Ничего больше. Он просто хранит массив каких-то структур в статике. Т.е. если у вас есть типы персонажей, то вы заводите всех и общие поля в какую-то структуру и потом, в самом ассете персонажа вы достаёте данные из структуры и назначаете значения переменных ассета.
А что делать, если у определенных классов есть особые переменные? Вносить их тоже в структуру. Выходит, что рядом с общими переменными нужно создавать поля для особых переменных, которые встречаются всего в одном классе, ибо структуры не наследуются.
Удобно ли это? Нет. Это полная дичь, но вариантов нет. Зачастую, ваша структура будет иметь 20-40 полей (что очень дофига) и каждое поле вы должны будете ручками назначить для переменных. Дичь полнейшая, но других вариантов нет.
Unity:
Изначально в юнити не предусмотрено тулзов для удобного просмотра ассетов, однако это можно написать самому (в отличии от UE писать расширения для Unity не так сложно), либо купить тулзы, которые позволят удобно видеть список всех ассетов определённого типа в проекте, без необходимости писать какой-либо дополнительный код для этого, которые позволяет легко сравнивать ассеты на одном экране.
И сам факт - вы НИКАК не ограничены в требованиях постоения архитектуры при использовании этих тулзов, потому что вы не должны ориентироваться на то, что данные будут лежать в какой-то особой структуре, которые лежат в каком-то особом месте.
В этом плане, юнити на две головы выше Unreal, потому что нет никакой необходимости следовать какой-то жесткой структуре проекта, которую вам задали разработчики.
Т.е. чтобы не быть в этой теме голословным, вот пример с описание:
Например, я хочу создать шутер, у меня есть оружие и патроны, я хочу видеть их все удобным списком, изменять данные и так далее.
Unreal:
Так как списком в Unreal можно смотреть только структуры, то данные оружия и патронов должны быть в структурах, а потом нужно создать класс, который содержит поле этой структуры и в констракшн скрипте берёт из таблицы эту структуру и назначает её переменной. Т.к. ссылку на структуру дать нельзя и удобно просматривать переменные классов тоже нельзя. Так как в классах от UObject нет Construction Script, то наши Ammo должны лежать в Actor классе.
Т.е. мы создали уже 6 сущностей (структуру аммо, дататейбл, класс, структуру оружия, дататейбл, класс).
Помимо этого, создавая каждый раз оружие новое или патроны, нужно не забыть добавить его в дататейбл, создать нового эктора, перегрузить его Construction Script и так далее.
Скрины:
Unity:
ᅠ1. Создаём класс weapon
ᅠ2. Создаём класс ammo
ᅠ3. Создаём инстансы классов
ᅠ4. Открываем плагин Fast Data View и видим их все в удобном списке с возможностью показать их все сразу рядом и изменить размеры, отображения, видимые\скрытые переменные, сделать выборку переменных из списков и прочее, прочее.
Скрины:
Итог:
У юнити мы создали всего 2 сущности, которые не требуют никаких извращений и получили наиболее удачное и лёгкое отображение данных, которое можно создать\изменить абсолютно для любого класса за одну минуту.
У анрила мы создали целых 6 сущностей, список которых можно видеть только в убогом оконце DataTable, вид данных изменять никак нельзя, классы нужно заранее прописывать (т.е. просто так взять любой класс и посмотреть список объектов от этого класса и значения его переменных списком нельзя).
К тому же, так как в c++ нет свойств (get; set), то мы не можем видеть там функции, которые показывали бы суммы каких-то данных, а в Unity мы видим в полях Damage и DamagePerSecond динамически изменяемые свойства (по сути функции, но на скринах не показал их, т.к. в анриле такого нет даже рядом).
Разницы в удобстве и подходе, как по мне, очевидная.
Архитектура
Юнити поддерживает почти любую вашу архитектуру, которые вы можете строить так, как захотите и спланируете, конечно, следуя объектно-компонентному подходу по итогу.
Unreal сажает вас на свою собственную архитектуру и подход от которого отойти практически нереально.
У Unity есть ряд сущностей: gameObject, prefab, scriptable object, monoBehaviour components
У Unreal: GameInstance, GameMode, PlayerController, PlayerState, GameState, Pawn, Actor, Character, Child Actor, Actor Component, Scene component, Character Movement Component и еще ряд компонентов со своими особенностями.
Т.е. у анрила четко прописаная архитектура и прочее, чему вы должны следовать. Если вы не будете ей следовать, то вы будете регулярно ловить баги и непонимание.
К тому же, для понимания положения, чтобы перенести какие-либо данные, либо объекты между уровнями нужно сделать следующее:
Unity: добавить на любой gameobject скрипт DontDestroyOnLoad
Unreal: добавить данные в класс GameInstance.
Т.е. у анрила есть только один объект, который может переносить информацию между уровнями и в крупных командах будет постоянно столкновение лбами на этом объекте, потому что он нужен всем и умеет переносить только типы значений. Все ссылки будут удалены. Т.е. все данные, что вы хотите переносить должны храниться в структурах и ни в коем случае не в классах. И любые объекты на сцене перенести НЕВОЗМОЖНО. Т.е. вы даже чисто теоретически не можете многие вещи сделать независимыми модулями, т.к. в ряде общих объектов вы будете вынуждены вносить какие-то данные.
Графика\качество картинки итогового продукта
Из коробки изначальная графика Unreal лучше, чем Unity, но, в целом, по итоговым результатам, если опытная команда приложит руку к созданию, то графика на каждой из платформ будет плюс-минус одинаковая.
Хоть эпики и полностью делают ставку на графику во всех своих разработках и рекламах, графика Fortnite крайне далека от показываемой ими фотореалистичности и детализированности сцены. Т.е. сами эпики своей "супер фотореалистичной" графикой в своих проектах не пользуются. Почему? Вопрос открытый.
Внешний вид редактора
По моему мнению, редактор Unreal выглядит более стильно, чем редактор юнити, но и ресурсов на этот стиль он требует несколько больше. Как по мне, Unity стоит провести редизайн, т.к. в настоящий момент редактор выглядит слишком минималистично, но это по причине того, что Unity нацелены на то, что у некоторых начинающих разработчиков нет денег на такие компы, какие требует UE.
Отладка
Отладка идентичная. Всё примерно 1 в 1. Т.к. оптимизация - это то, что мне больше всего нравится в разработке, то я изучил все тулзы и они плюс-минус идентичные.
Код
Бытует мнение, что код на ++ более "правильный" для разработки, более православный (не зря же в названии целых ДВА креста), а #, мол, для работяг, потому что на ++ написано большинство движков и игр, но вот моё мнение и аргументы на тему сравнения ++ и #, соглашаться или нет - дело ваше:
ᅠ1. Когда разработка игр набирала обороты и индустрия только появлялась, то # еще только-только появился, поэтому специалистов на нём было мало. Был С и был С++ и люди выбрали С++ из-за ООП и более строгой типизации и меньше шансов себе в колено выстрелить, но у C# в этом всём еще больше строгости и меньше вариантов ошибки. Я считаю, что если бы индустрия появлялась сейчас, то все бы выбрали C#.
ᅠ2. С# на всех проектах одинаковый, С++ на каждом проекте абсолютно разный. Подход к коду в С++ на каждом проекте абсолютно другой.
Если вы работали на UE c C++, то придя в какой-то другой проект на C++, то вы поймёте, что подход, функции и код абсолютно другой. Т.е., например, в коде UE очень не рекомендуют использовать стандартные библиотеки С++, т.е. то, что вы учили в универе вам не слишком поможет.
На С# я писал .net приложения, Unity приложения, немного сайты - все практически идентичное, кроме некоторых моментов.
Таким образом, работая с С# на Unity у вас больше возможных путей развития, чем c C++ Unreal.
ᅠ3. Омега душная история с хидерами и PCH в С++. Бывает, что копируешь все хидеры из одного класса в другой, пытаешься использовать функции из них и функции не находит! И ты бесконечно долго сидишь и ломаешь голову почему и как это решить. В C# такой ерунды нет даже рядом, поэтому обучение C# и написание кода идёт намного быстрее. Да и если ты даже немного накосячишь с хидерами в C++, то редактор может начать в разы дольше запускаться, что тоже не круто.
ᅠ4. Все модули, которые требуют высокой производительности, можно написать на любом языке и закрыть в dll (лично я в своей практике таких потребностей не встречал).
Блупринты
Особая разработка Unreal для тех, кому сложен код. Это визуальный код с помощью блоков.
Зачем он придуман?
ᅠПотому что осилить анриловский код на С++ не только лишь все могут, а так как Unreal - это движок написанный дизайнерами для дизайнеров, то придумали блупринты.
Разработчики утверждают, что вы можете использовать блупринты или код - как захотите. Мол, если вы решили использовать блупринты, то код вам совсем не нужно писать. ЭТО ВСЁ ЛОЖЬ!
Вы обязаны использовать и код, и блупринты. Без вариантов.
Блупринтами вы не сделаете и 10% того, что можете сделать кодом, а от попытки использовать некоторые вещи в коде - вы посидеете.
Минусы работы с кодом:
ᅠ1. Если вы даже немного накосячите в хидерами и ссылочной массой, то код будет компилиться очень долго. Каждый раз при изменение кода вы будете долго сидеть и ждать пока он компильнется.
ᅠ2. Некоторые фичи использовать в коде больно физически. Например, система переводов - она нацелена на использование исключительно из блупринтов.
ᅠ3. Можно косякнуть легко.
ᅠ4. Добавив новый класс нужно ручками нажимать на "Generate Visual Studio project files".
Минусы работы с блупринтами:
ᅠ1. Не сделать большинство вещей, что приходят на ум программисту, но не приходят на ум дизайнеру. Например, взять все кнопки на всех виджетах и назначить им какой-либо звук, либо зашифровать строку, либо разрезать меш на несколько частей и тд. тп.
ᅠ2. Каждая прямая ссылка на каждый объект наращивает ссылочную массу, что повышает время запуска редактора. Если объект ссылается на объект, который ссылается в свою очередь на ссылаемый объект, то время загрузки редактора растёт. Даже если объект будет ссылаться на объект и где-то там в ссылках у этого объекта есть объект, которые ссылается на первый объект, то это повысит время загрузки редактора.
ᅠ3. Блупринты не мёржатся.
ᅠ4. В целом на блупринтах писать дольше, чем обычным кодом.
ᅠ5. Все математические вычисления в блупринтах потребляют больше ресурсов.
ᅠ6. Чтобы функции\переменные были видны в редакторе необходимо их особым способом помечать, поэтому многие вещи изначально скрыты в блупринтах. И для того, чтобы, например, юзать SteamSDK в блупринтах придётся либо пару месяцев писать обёртку под блупринты, либо купить готовый плагин обёртки за деньги (который периодически с обновлением движка ломается).
Почему блупринты в целом порочная концепция?
Каждый геймдизайнер начинает писать код. Думаю, любой программист понимает, что это влечёт кучу уникальных реализаций на каждый вздох.
Вместо общепринятой концепции: геймдизайнеры пишут требования к тулзам -> программисты реализуют тулзы -> геймдизайнеры их используют, - мы получаем, что геймдизайнеры пишут код. Не тулзы, которые работают по общим принципам и поэтому в них минимум багов, а уникальные реализации, каждая из которых это кладязь для багов\пожирания ресурсов.
Звук
Я бы сказал, что он примерно одинаковый и там, и там, но я с ним не работал, поэтому за достоверность не ручаюсь. Да и по качеству звука оценить разницу не могу, но так или иначе всё равно многие крупные компании выбирают имплементировать Wwise даже при том, что он забирает 5% от доходов.
Расширений редактора
В целом, все движки поддерживают плагины, но написать плагин\расширение на Unreal сложнее по той причине, что писать его придётся полностью на C++, в омега захардкоженной экосистеме анрила. Например, вы хотите изменить вид отображения переменных в блупринтах - и это оказываться весьма тяжкая задача, в отличии от аналогичной задачи в Unity,
Подход к мультиплееру
Изначально, в UE мультиплеер как бы подразумевается как данность, т.е. все объекты имеют плашку сериализации, а все функции можно сразу помечать как мультикасты\серверные\клиентские функции и пр.
Т.е. их как бы можно не включать, но сама тенденция, что все мультиплеерные штуки захардкожены в движок показательна. Да и написать собственный мультиплеер будет крайне сложно.
В Unity добавляются мультиплеерные штуки как компоненты, всё помечается атрибутами и так далее. Всё сделано как модуль и не захардкожено под самую жопу.
Относительно мультиплеерной производительность и оптимизации - всё примерно одинаково. По логике - в юнити всё более грамотно сделано, но относительно стандартного разработчики - всё воспринимается примерно одинаково.
Стандартные редакторы материалов\геймобджектов и пр
UE тут побеждает Unity с головой. Во много в UE все эти редакторы более удобные и приятные глазу, чем аналоги в Unity, но функционально всё примерно идентично.
Т.е. в Unreal редактор материалов имеет свой особый интерфейс, а в Unity шейдеры пишутся кодом (хотя вроде бы какой-то похожий редактор для Unity я уже видел), но по итогу это одни и те же шейдеры.
Проблемы в редакторе уровней
В UE есть масса проблем с редактором уровней. Например, используя синглтон какой-либо как эктора, он почему то иногда дублируется на сцену. Т.е. в рантайме появляется объект и когда сцену выключили (по esс), то он почему-то остался. Почему? Неизвестно.
Также бывает, что есть объект имеет на себе много child экторов и этот объект удаляем со сцены, то иногда все эти чайлд экторы не удаляются вместе с объектом, а просто падают в сцену.
В Unity я таких проблем пока не заметил, но не отрицаю, что они могут быть.
Система переводов
В UE есть только одна система переводов, она жестко захардкожена в движок и её никак не вынять и не заменить нормально. Она уже более 3 лет лежит под плашкой "Эксперементальная" и, скорее всего, никогда оттуда не уйдёт из-за того, что в ней много багов, однако, если работать по четко намеченным лекалам, то она вполне жизнеспособна и как-то работает, особенно, если не требовать от неё невероятных вещей, типа "нажал на кнопку и все фразы перевело на все указанные языки через гугл переводчик" и использовать её только через блупринты (не через код, потому что в коде её использовать - это ад).
В Unity стандартной системы переводов нет, однако, в Unity большой выбор различных систем переводов в магазине, с отзывами и возможностью их пощупать бесплатно. Да и они умеют полностью переводить все данные на все языки через гугл переводчик по нажатию кнопки.
Понятно, что гугл переводчик - это такое, но как placeholder нормальная тема.
Претенциозность платформ
Дело в том, что компания Unreal очень сильно пытается мелькать в информационном поле и во всех около игровых сферах пытается впихнуть своё Я. Например, создали свой магазин и не добавив даже поиска по играм сразу заявили, что они "убивцы стима". Это типичная маркетинговая стратегия анрила - создать какой-то некачественный и недоделанные продукт и сразу начать его рекламить и объявлять всем "войны".
Дело в том, что Unreal позиционируют себя как писец, хлебец и на дуде игрец. Т.е. во всех сферы они пытаются залезть, но во всех сферах они пытаются максимально накидать рекламы при довольно низком качестве продукта, в отличии от Unity, которые занимаются только движком.
Т.е. у Unity позиция:
ᅠEсть мы и вот наш продукт.
Позиция у Unreal:
ᅠМы двигаем индустрию вперёд, ну и что, что у нас тонны багов, зато мы постоянно добавляем новые технологии в движок, ну и что, что они работают кое-как - зато они передовые! А еще у нас магазин убийца стима, которые ориентирован как бы на разработчиков, но по функционалу отстаёт от стима лет на 10, а ещё мы создадим издателя своего и будем платить разрабам за разработку.
Я считаю, что не сегодня-завтра из-за всех этих тенденций Unreal скажет, что игры на Unreal можно продавать только на площадках, которые они одобрят. Т.е. сначала они станут издателями каких-то игр и запретят продавать их где угодно, кроме Unreal магазина, а потом и все игры на UE запретят продавать где-либо, кроме их площадки. Просто будет кабала, которая пока они не в позиции лидера как бы выгодна, а как только они станут лидерами, то гайки всем закрутят.
Вакансии
Вакансий на Unreal всегда намного меньше, чем на Unity. Взяв тот же hh и спросив по вакансиям получаем:
741 вакансий по Unity
186 вакансий по Unreal
Это по всему СНГ, по другим сайтам примерно всё в таком же соотношение.
Магазин ассетов
Магазин ассетов в Unreal в большинстве своём содержит только модели\текстуры и обёртки под блупринты, в отличии от магазина Unity, который содержит абсолютно всё, что можно. Но в этом всё играет роль подход Unity и UE к своим движкам.
Во-первых, как я уже сказал, плагины под Unity писать намного проще.
Во-вторых: Unity не так захардкожен, как Unreal. Даже при том, что движок Unity закрыт - он более поддатлив к расширению.
Стоит отметить, что ряда вещей, которых в Unity изначально нет (но есть в магазине), изначально есть в Unreal бесплатно. Типа изменения цвета папок и пр. Как по мне, то для норм работы с Unity так или иначе 100-200$ выложить на плагины придётся, в отличии от Unreal (возможно, потому что у Unreal особо нечего покупать для удобной работы с редактором).
В магазине Unreal есть интересные бесплатные вещи, типа особого скриптового языка, который можно использовать в редакторе и не надо долго компилить, НО, докинуть еще одну сущность к коду и блупринтам - это крайне сомнительная идея. Что-то там, что-то там реализовано и если начать искать где какая-то логика реализована, то куча времени уходит чёрти куда. Да и хз как там будет с отладкой.
Итог
Unreal-------------------------------------------------------------------------------------------------------------------------------------------------------------
Unreal Engine - это движок нацеленный исключительно на дизайнеров. Все удобные тулзы - только для дизайнеров. Геймдизайнеры, контентщики, программисты - всем огромную дулю в зубы от эпиков, потому что удобные тулзы не показать в видосике и не получить "Вау" эффект как от очередной итерации графики. Действуя только из соображений маркетинга мы получаем полусырой продукт под подливой передовых технологий, который к тому же захардкожен и закостылен настолько, как будто бы его делали студенты третьего курса.
Все положительные отзывы об UE4 - это отзывы дизайнеров, моделлеров, создателей шейдеров и так далее, т.е. тех, кто работает только с графикой либо имеет мало опыта в создание игр. Графика - это единственное чем можно похвалиться UE4, но сами же эпики не создают "фотореалистичных" игр.
70% содержаний апдейтов движка - это исправление предыдущих багов, которые зачастую порождают еще баги. К тому же, некоторые баги не могут исправить уже многие годы, по типу добавления поля в BP структуру от которой ломается весь проект, ибо все места, где структура используется вдруг не могут найти эту структуру и приходится изощерятся и молится, чтобы этот баг не словить в очередной раз.
Но маркетинговый отдел у Epic работает хорошо. Но всё это выглядит так, будто бы Unity - это нож, который особо в рекламе не нуждается и работает хорошо в большинстве ситуаций, а Unreal - это набор различных приблуд для кухни с AliExpress, который работает хорошо только в рекламных роликах, а когда начинаешь их использовать, то понимаешь, что это мусор, но так как приблуды красивые, интересные и их много, то про них можно рассказывать очень долго в рекламных роликах.
Ни в одной из статей я не встречал упоминания того, что UE очень слабо работает с системами контроля версий, а размер проекта растёт как на дрожжах. Видимо, это считают несущественными деталями.
Создавать какие-либо игры кроме шутеров\платформеров\хорроров на Unreal Engine - это копать овраг чайной ложкой - сделать возможно, но долго и муторно. Так как нет никакой возможности удобно и быстро просматривать и сравнивать статические данные, настраивать баланс, которых в любых РПГ, стратегиях и пр. в разы больше, чем в шутерах.
Unity-------------------------------------------------------------------------------------------------------------------------------------------------------------
Unity предпочитают не заливать от своего имени тестовые фичи, предлагая пользователям огромный ассортимент торговой площадки, однако, некоторые вещи из торговой площадки, такие как Text Mesh Pro они включили в стандартные ассеты.
Интерфейс юнити никак не поменялся за последние лет 5. Юнити не хватает тулзов для дизайнеров, которые есть у Unreal, что делает работу визуальных дизайнеров не самой удобной.