Gamedev Александр Тим
1 713

Выбор универсального игрового движка на перспективу

В данный момент я пишу несложные, но ветвистые текстовые игры на RenPy со своими свистелками: инвентарь, прокачка, влияние прокачки на способы прохождения квестов.

В закладки

Есть ощущение, что я потихоньку упираюсь в потолок возможностей RenPy по своим хотелкам: с 3D не поработаешь, платформеры не запилишь, так как движок заточен только под одно направление.

Конечно, можно что-то придумать, но... Зачем?

В связи с этим возник вопрос: UE или Unity3D для соло-использования?

Я сам себе творец, пишу код / рисую / изучаю моделирование, поэтому нужды в командной работе пока (но только пока) нет.

UE по мнениям разных людей предрасположен для командной работы и для крупных проектов (не инди, до которого мне тоже ещё очень далеко). Да и делать текстовый квест на UE, наверное, глупо, хотя блюпринты...

С Unity3D, кажись, всё чуть проще и он более открыт к новичкам (субъективно), да и Си-шарп мне понятнее, чем плюсы.

Оба редактора щупал / тыкал, но какого-то определённого выбора так и не смог сделать.

Если у кого-то есть похожий опыт в выборе движка, буду рад и благодарен, если поделитесь мнением.

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Александр Тим", "author_type": "self", "tags": [], "comments": 154, "likes": 20, "favorites": 48, "is_advertisement": false, "subsite_label": "gamedev", "id": 43716, "is_wide": false, "is_ugc": true, "date": "Thu, 21 Mar 2019 20:41:45 +0300" }
{ "id": 43716, "author_id": 14599, "diff_limit": 1000, "urls": {"diff":"\/comments\/43716\/get","add":"\/comments\/43716\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/43716"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64954, "last_count_and_date": null }

154 комментария 154 комм.

Популярные

По порядку

Написать комментарий...
9

Не имеет значения. Если инди, то обоих хватит с головой. Если ААА, то у обоих упретесь в потолок.

Ответить
4

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

Про инди , хватит с головой, это тоже верно.

Ответить
0

Если у вас ААА юнитехи вам дадут сорцы движка, допиливайте, как хотите.

Ответить
0

Про это и разговор про потолок движка , который предлагают

Ответить
0

В UE4 более чем достаточно инструментов для оптимизации. Но они не самые простые и плохо документированы. Кроме того, движок требует изначально грамотного подхода. Поэтому игры самих эпиков оптимизированы отлично, а остальные игры на UE4 часто страдают.

Ответить
–10

Unity намного проще в освоении.
С блюпринтами в UE делать нечего, максимум демку собрать. Иначе на релизе багов будет немеренно. Если уж и изучать UE, то со знанием C++, а с нуля это лет 5 только до мидла.

Ответить
17

сразу видну что не работали нормально не с одним не с другим

Ответить
–3

Мне лень спорить.

Ответить
3

Мне тоже, ибо бред написали вы(

Ответить
0

Аргументируйте, пожалуйста, мне правда интересно узнать взвешенные "за" и "против" того или иного движка :)

Ответить
10

Про простоту нету смысла, у обоих движков имется схожий интерфейс, схожие апи для основ и тд. Разница в том что у UE больше фич из коробки чем в юнити и более новый интерфейс. А в целом они оба будут просты в начале. Про бп лишь ограничивается в требованиях, можно написать прототип в котором без ++ никуда. а можно всю игру без ++, тут зависит именно от того что хочет. Про баги полный бред так как это логическая проблема а не в языке и не в бп. 5 лета до мида? ну тоже бред, зависит от того как ты будешь выделять время на данную облость и цели которые хочешь достигнуть. Выучить сам язык это не сложно, сложно наверстать алгоритмическую базу и умение реализовывать задумки(опять же не зависит от языка и движка). Учить с++ дольше конечно, но после того как освоишь ты сможешь легко выучить другие языки(и #,python и тд).

Ответить
5

Unity: в чем-то проще, но можно налетать на костыли, которые кочуют из версии в версию. В некотором роде, C# понадобится раньше, чем C++ в UE

UE4: на блупринтах можно собрать всё, что подпадает под Ваши запросы, уйма гайдов и воркшопов в инете.

В плане командной работы и там и там нюансов хватает. В целом, UE значительно проще в освоении и дружелюбнее к новичкам. Ограничения в блупринтах появляются только в плане перфоманса в "тяжелых" случаях.

Ответить
–2

В целом, UE значительно проще в освоении и дружелюбнее к новичкам

Ну лол же, а? Нахера человеку учить блупринты, если есть сишарп? Куда он потом с этими блупринтами пойдёт?

Ответить
1

нахера человеку C# если есть C++? куда он потом с этим шарпом пойдёт в геймдеве?

Ответить
1

лол )) Куда он с этими плюсами пойдет в гемдеве? Кто сейчас на плюсах пишет? Дмитро, вы застряли где-то в 90х.. 80% современного игрописательства - это питон или сишарп.

Ответить
0

Блупринты - это блок схемы, на них реализуются те же алгоритмы, да там не всегда есть возможность тонкой настройки, но это не меняет сути, а синтаксис ЯП можно освоить менее чем за месяц.

Ответить
0

Я знаю, что такое блупринты. Алгоритмы прекрасно реализуются и на ЯП. Более того, куда проще и без всякого гемороя с возможностью оптимизации. Нет ни единой причины пользоваться блупринтами, кроме незнания языка, но это так себе причина.. Я могу понять блупринты в шейдерах, там действительно они удобны, но логику писать на блупринте - осотонеешь. По моей игре если судить (весьма простой), там этих блупринтов было бы на 20 ватманов, если распечатать.

Ответить
0

Да куда угодно. Единственная проблема - что у работодателей зачастую стоит психологический блок. Несмотря на то, что блупринты зачастую покрывают 95% потребностей, работодателю будет проще расставаться с зп за 100 тыщ, если ты знаешь плюсы (или говоришь, что знаешь).

Ответить
0

Или на 60 тыс, если знаешь сишарп )) Тем более, что для скриптов юнити сеньёра сишарпера не нужно. Там мидла за глаза, а то и вовсе джуниора.

Ответить
0

Новичку самое то блупринты, для понимания логики построения игры, а не просидеть над изучением языка и основ пару и понять что это не твое. Тем более в соло разработке не все упирается в Язык) Игра это не только "язык програмирования".

Ответить
4

Без плюсов не обойдёшься если нужно сторонние проги подгружать (если конечно в маркете под это нет плагинов), сеть настраивать и сильно переписать физику. Для всего остального есть блупринты. Причем не важно с чем работать - с интерфейсами, шейдерами, анимационными системами , спецэффектами - везде блупринты.
Самый ощутимый минус блупринтов - необходимо понимать как эпики задумали архитектуру. Написать архитектуру заново блупринтами - не выйдет.
Самый ощутимый плюс - освоить блупринты в 100 раз легче освоить, чем C#. Впрочем у Unity есть всякие playmaker`ы - аналоги блупринтов. Но не уверен что это дело рук юнити, а не сторонних разработчиков.
Некоторые говорят, что с 2D юнити лучше справляется, чем анриал. Но на самом деле разница несущественна. Потому как какой-нибудь game maker studio обгоняет и unreal, и unity по производительности в 25 раз (по 2D).
Иногда говорят ещё, что UE4 билды на ue4 очень тяжёлые, но если твой проект будет весить больше 200 мегабайт, то разницы нет. Если всё-таки меньше, то есть масса вещей, которые придётся поотключать перед билдом. Есть даже вроде какие-то соревнования в UE4 в жанре лучшая игра до 80 мегабайт или типа того.
Надеюсь, если что знатоки меня поправят.

Ответить
–1

освоить блупринты в 100 раз легче освоить, чем C#

Извините, это дичь.

Ответить
4

От вашего комментария было бы гораздо больше пользы, замени вы "извините" на какие-нибудь аргументы.

Ответить
1

Ну хорошо, аргументы в том, что освоить общепринятый и овер-распространенный язык с миллионами уроков и книг, в том числе и на русском, гораздо легче, чем местечковые квадратики-линеечки с иногда странной логикой коммуникации между собой. Скрипт - он и в африке скрипт, он понятен, лаконичен и самодостаточен. Логика на прямоугольчиках громоздка, труднопонимаема и трудноредактируема.
Достаточно?

Ответить
3

Мысль понятна, но она противоречит здравому смыслу. То что C++ распространён - не делает его легче в освоении. И миллионы книг по C++ говорят о том, что а) он востребован б) трудно понимаем в) появился гораздо раньше.

Со следующим утверждением я бы поспорил, если бы не одно "но" - если поменять скрипты и блупринты местами - то станет понятно что это утверждение субъективно.
Скрипт - он и в африке скрипт, он понятен, лаконичен и самодостаточен. Логика на прямоугольчиках громоздка, труднопонимаема и трудноредактируема.

Блупринт - он и в африке блупринт, он понятен, лаконичен и самодостаточен. Логика на скриптах громоздка, труднопонимаема и трудноредактируема.

Ну а так - как может быть блупринт трудночитаемым, если у него все переменные тупо по цвету отличаются? Т.е. можно не читая понять где какого типа переменная.
Суть визуального программирования именно в легкочитаемости.

Ответить
1

Миф о востребованности плюсов - это всего лишь миф. Раньше - да, сейчас - проще дельфисту работу найти, чем плюсовику. И требуются плюсовики не какие-то там джуниоры и мидлы, а сразу сеньёры. Конечно, учитывая дефицитность сеньоров, зарплаты у плюсовика огого, да поди найди эти места.. Сишарпер же нужен везде, куда ни плюнь, везде дотнеты.

Далее, надеюсь, не будете спорить, что сишарп легче освоить, чем плюсы, в разы? По моему, тут доказывать ничего не надо. Плюсы ошибок не прощают, сишарпы - очень даже, да еще и красненьким обведут..

как может быть блупринт трудночитаемым

Он громоздкий. На сишарпе одна строчка, на блупринте 10 блоков (образно говоря). Довольно несложная логика на сишарпах вмещается на один экран текста, блупринтам для этой же логики нужен ватман.. А если скрипт этот не просто скрипт, а скрипт по управлению другими скриптами, всё, это вилы. Вы упоретесь в сотнях связей объектов между собой.

Суть визуального программирования именно в легкочитаемости.

На уровне а+б может и да. Что-то более сложное, скрипт куда проще.

Но я не отрицаю полезность блупринтов в шейдерописании. Сам использую с удовольствием. Шейдеры, как правило, небольшие, логики у них почти и нет, обычно это математика. Блупринтами шейдеры пишутся намного проще.

Ответить
2

Я даже не намекал, что плюсы легче шарпа, мой тезис - и шарп, и плюсы - сложнее блупринтов.
По поводу громоздкости - отчасти это правда, но :
А) Добавить простой скрипт быстрее, чем его написать текстом (разве что скрипт совсем простой) .
Б) Скрипт можно скейлить не теряя читаемости
В) Любой скрипт легко превратить в функцию или макрос. А это значит, что скрипт управляющий другими скриптами будет выглядеть очень лаконично. Создание гигантского полотна - не более чем ошибка новичков.

Ответить
0

Простите.. и часто вы распечатываете свой код? просто любопытно все ватманами меряете))

Ответить
0

Изучение любого языка программирования начинается с освоения блок схем и алгоритмизации процессов... А Блюпринты - это почти чистые блоксхемы и есть.

Ответить
0

Изучение любого языка программирования начинается с освоения блок схем

)))

Ответить
0

да да я знаю что некоторые сразу бросаются писать свой игровой движок...

Ответить
0

Для освоения сишарпа, да хотя бы на курсы сходить, если так горит, или у знакомого сишарпера чего спросить. А вот где вы найдете курсы по блупринтам..

Ответить
0

В интернетах очень легко найти материал по блупринтам.

Ответить
1

Можно сделать игру полностью на блюпринтах, если это не AA и не AAA проект и вы не собираетесь заморачиваться с такими вещами как, чисто для примера, появляющиеся в реалтайме пятна крови на персонажах.

Ответить
0

Ваш пример, легко реализуется блупринтами. Большей частью - шейдером.
Вот тут парень в инди разделе сетевой шутер делал, где пол может быть потолком. Я не представляю как это реализовать блупринтами.
ААА тоже можно сделать, если мы говорим про какие-то анчартеды или метро (если допустить что с контент проблемы нет). Просто дольше. Зная код можно как минимум создать более удобные инструменты. К тому же код, более производителен (что на ААА будет заметно).

Ответить
0

Вот совершенно простой пример для симуляции качания ящика на волнах (фейкового качания).. Это одна строчка. Сколько вам там понадобится блоков в блупринтах?

Vector3 currentRotation=new Vector3 (Mathf.Sin(Time.time*amplitude+phase)*rotateSize.x,Mathf.Sin(Time.time*amplitude+
phase)*rotateSize.y,Mathf.Sin(Time.time*amplitude+phase)*rotateSize.z)
*Time.deltaTime;

Ответить
3

Таймлайн+set location. В таймлайне две переменные.

Ответить
0

Ваш пример, легко реализуется блупринтами. Большей частью - шейдером.

Нет

Ответить
0

Ну смотря что держать в голове. Я представил двух персонажей, где в одном случае он полностью в пятнах, а в другом - обычный. Соответственно тут лерп в материале. Если брызги крови и так далее, то тут частицы добавлять. Короче, если я и ошибся, то потому что плохо представляю задачу. Возможно, если бы понимал, то написал бы что не знаю как это сделать через бп.

Ответить
0

Даже в твоем примере, чтобы сделать интерполяцию, надо получить координаты на UV-развертке по координатам удара по персу. Соответствующая функция вынесена в блюпринты для static mesh-ей, но для skeletal mesh-ей - нет.

Ответить
0

Но у скелетал меша всё равно есть развертка. И текстура для неё. Выковырять её и по ней нанести кляксы в фотошопе и полученную текстуру использовать для крови.

Ответить
0

Тебе нужно знать, в каком месте на на персонаже рисовать кляксу. Как ты это узнаешь?

Ответить
0

Ну, если по текстуре ты не ориентируешься, то есть плагины фотошопа, которые визуализируют модель при рисовании, в блендере можно прям по модели рисовать. Если должна повреждаться не вся модель, то можно сделать по текстуре на каждую часть тела. Если имеется в виду рана в конкретной точке то через рендер таргет https://youtu.be/Jz050a2OMXE

Ответить
0

Ох ты ж, сколько раз надо повторить, чтобы дошло? Рендер таргет - это рисование на текстуре. Ее ты можешь использовать потом как маску, чтобы проявить повреждения на модели, что и происходит в этом видео. Когда ты тыкаешь мышкой в меш, появляется задача: надо от координат тычка мышью перейти к координатам на развертке, чтобы знать, где именно там, на рендер таргете, нарисовать пятно. Так вот, по хиту ты получаешь номер полигона, но у skeletal mesh component нет вынесенной в блюпринты функции, чтобы по номеру полигона получить координаты его вершин на развертке. Теперь ясно?

Ответить
0

Мы я так понимаю друг друга не поймём. Давай тезисно.
То что на видео подходит под описание задачи?

Ответить
0

1. Человек тыкает мышкой в манекен. 2. По хиту мышки определяются 3д-координаты, где "нанесен удар". 3. По 3д-координатам определяются 2д-координаты на UV-развертке, соответствующие тому же месту на модели. 4. По 2д-координатам на рендер таргете рисуется пятно. 5. Рендер-таргет обрабатывается в шейдере как маска, чтобы отобразить повреждения.

Пункт 3 делается на C++.

Ответить
0

Третий пункт можно реализовать с помощью render texture. Там под видео, есть ссылка на текстовое описание, которое поможет повторить результат.
Автор видео пишет, что такого результата добился используя исключительно блупринты и материалы. А у меня к сожалению, нет возможности попробовать воспроизвести опыт. Конечно, автор может лукавить, но с ссылкой под видео я бы рекомендовал ознакомиться.

Ответить
0

Третий пункт можно реализовать с помощью render texture.

Что ты под этим подразумаваешь? Чтобы отрендерить что-то на текстуре, нужно знать координаты, по которым будешь рендерить. Автор показывает, как сделать допразвертку, потому что у стандартного манекена, например, развертка отзеркалена, и потому простое рисование на первом канале будет зеркалиться с правой половину туловища на левую и наоборот.

Ответить
0

Upd. Прочитал описание. Попробую посмотреть, как это делается. Может действительно без определения координат, как он и утверждает. Но у меня есть сомнения насчет производительности такого шейдера.

Ответить
0

Бегло просмотрел статью. Она ведь для статичных мешей. Автор видоса, получается, в каждом кадре переразвертывает персонажа? Для практических целей это совершенно неприменимо.

Ответить
0

Это я увидел. Но также я увидел использование захвата сцены и рендера текстуры. Т.е. он получает координаты на скелете, потом вносит изменение в рендер текстуры. Мне кажется - это ключ
Зы: В статье описано отключение рендера

Ответить
0

В статье описано отключение рендера

Потому что в статье статик меш. Можно один раз отрендерить текстуру, а потом всегда переносить локальные 3d-координаты в 2d. Со скелетом так не прокатит.

Ответить
0

Я не совсем понял почему. Если текстура не обнуляется, а дорисовывется, то почему не включать рендер в момент клика и отключать после?
P.S. Мы хоть насущную проблему решаем или теоретическую? А то становится проще признать, что можно только кодом.

Ответить
0

Ваш пример, легко реализуется блупринтами. Большей частью - шейдером.

А не декалями?

Ответить
0

Декали жрут много и не факт что их можно применять к персонажам. Тут я больше от своего опыта отталкиваюсь, а я избегал декалей. Нанести статичное пятно крови на пол это да. Рисовать кровь на полу - рендером наверное, а на персонаже - лерпить материал через текстуру.

Ответить
0

и не факт что их можно применять к персонажам

Можно )

Ответить
0

Декал накладывается на skeletal mesh, но он будет некорректно пересчитываться при движениях костей вместо того, чтобы статично лечь на развертку.

Ответить
0

А кто вам сказал, что на персонаже один материал?

Ответить
0

Без разницы вообще.

Ответить
0

Я выше объяснил, в чем затык.

Ответить
0

ИЕ4 предоставялет инструмент компиляции блюпринтов в чистый код. Это позволяет ускорить производительность на финальных сборках - даже если код не править.

Ответить
0

Почему нет? Блупринты не подходят только если делаешь что-то сложное сетевое, со всеми остальными задачами прекрасно справляются.

Ответить
0

это какой-то кривой пример)

Ответить
0

Это пример, объясняющий, почему декали не работают.Вообще, я выше скидывал статью на tomlooman. Можете глянуть, она интересная. Единственное "но" - для skeletal mesh-a координаты полигона на UV-развертке можно получить только через C++. О чем я и сказал с самого начала.

Однако эпики сейчас весь пайалайн рендеринга рефакторят и унифицируют static и skeletal mesh-ы. Так что в ближайшее время, я думаю, лезь в C++ станет не обязательно.

Ответить
–1

Для соло - однозначно Юнити.

Ответить
0

Иначе на релизе багов будет немеренно

Шедеврально! Сразу видно знатока.

Ответить
7

Если не знаком с core-фичами движков, то отталкивайся от языка: С++ или C#

Ответить
7

Godot

Ответить
6

UE без вариантов

Ответить
6

Unreal Engine 4 без вариантов: ультимативная вооружённость инструментарием, полностью открытый код, высокая частота обновлений с исправлением ошибок, высокое качество кода в исходниках, самые актуальные технологии, простоя и достаточно легко настраиваемая сборка под различные платформы, мультиплатформенный редактор (Linux, Mac, Win), очень высокая производительность рендера и больше число оптимизаций из коробки, подробная насыщенная документация (но не ультимативная, некоторые вещи описаны очень скромно), огромное обилие обучающих материалов и ассетов, С++ и визуальное программирование.

Только на нём можно отрастить руки из плеч за счёт формирования адекватного понимания, какие инструменты применяются для разработки игр и зачем. Без этого будет крайне ограниченное и куцее восприятие разработки в целом. К примеру, на том же Unity целая куча "уникумов", которые кат-сцены делают кодом(!), в UE4 до такого адского маразма из начала 2000-х не дошло бы никогда. Отсюда у UE4 огромнейший выигрыш в формировании мышления разработчика, где задачи решаются надлежащими инструментами, а не наскоро костылями лишь бы было. Движок заставляет делать нормально и использовать его инструменты, что избавляет от костылестроения, что очень благотворно сказывается на скорости разработки и дебага. По прикидкам разработка (с учётом дебага) в 2-3 раза быстрее, чем на Unity.
UE4 это именно движок, а не косплей движка фреймворком с прибитым гвоздями редактором.

Ответить
5

У меня небольшой опыт в обоих движках, но все же выскажу.
В Анриле есть блюпринты при чем не только для логики. Они используются в анимации, в прописывании ИИ, для создания материалов и интерфейсов. Если неплохо знаешь английский, то на канале Matthew Palaje есть плейлист Let's Create, где он создает в блюпринтах всякие прикольные механики из игр от простого перемещения вплоть до способностей из овеврвотча и зельды. Неплохой старт.
Плюсы в УЕ слегка нагружены, но за пару вечеров можно втянуться хотя работа с плюсами и блюпринтами в связке слегка топорная(но опять таки я пока глубоко не залезал). Имхо, мне нравится редактор Анриала больше чем Юнити, он эстетичный, понятный. В нем есть встроенный инструментарий для создания ландшавтов(на ютубе еще можно поискать material blending или типа того, где можно "раскрашивать" поверхности разными материалами, наслаивая их(типа чтобы кирпичи выглядывали из-за цемента и все такое)).
У Юнити и плюсов это C#, который более лаконичный чем анриловские плюсы и понятный, но там многие вещи надо будет делать ручками(считай костыли), благо уроков в инете полно. Я сколько ни садился за этот движок, все он меня отталкивал чем-то. Но тогда мой старый компьютер не позволял мне постичь анрил, сейчас потихоньку исправляю ситуацию.
Ну и еще один камень в сторону Юнити - я помню прочитал давно на каком-то форуме, что Юнити позволит быстро создать что-то до определенного этапа, пока ты не упрешься в потолок и не придется костылить по черному..

Ответить
3

Про камень в огород верно. Разработчики unity часто вкручивают всякие ништяки по готовности подходящие под статус "бета", и часто их забрасывают. При создании крупного проекта с обширной логикой эти костыли и вылазят.

Ответить
0

Я слышал там много проблем со scriptableobject на поздних этапах и с префабами, хотя их вроде недавно улучшили, но все равно какие-то косяки есть(я профан в этом, поэтому не скажу точно)

Ответить
1

Да, есть такое. Во всяком случае было раньше точно, в актуальной версии не знаю, не буду утверждать.

Еще помнится момент, когда одну из демок комьюнити не смогло запустить в движке as is, пришлось ждать пару патчей. Движок в целом хороший, но эти моменты стоит обязательно учитывать на старте.

Ответить
0

Что за проблема с префабами? Впервые слышу..

Ответить
–4

Честно говоря, для крупного проекта с обширной логикой, я бы не брал ни того, ни другого. Зачем, если есть CryEngine ?

Ответить
1

Чтобы советовать CryEngine для крупного проекта, нужно не иметь ни грамма понятия, что он из себя представляет. CryEngine это крайне забагованный движок с очень неравномерным темпом развития, выхода обновлений и большим числом рудиментарного кода. Более-менее ситуация начала улучшаться последние полгода, но за это время не вышло ни одного значительного обновления, когда у того же UE4 вышло уже три(!) с "километровым" логом изменений в каждом.

Ответить
0

CryEngine которого больше нет? Давайте возьмем мертвый двигатель, это же так удобно...

Ответить
0

В Анриле есть блюпринты при чем не только для логики. Они используются в анимации, в прописывании ИИ, для создания материалов и интерфейсов.

Собственно, в юнити это тоже всё есть. Но используешь по желанию. И не только нативное, а еще и от независимых разработчиков, например, AMFShaderEditor

Ответить
4

Для соло-использования глянь ещё на Godot.
Простой в освоении, неплохо развивается, кроссплатформенный, абсолютно бесплатный. Поддерживает несколько языков программирования, в том числе и собственный, который очень похож на пайтон.

Ответить
1

Годот тема да, хотя без шарпа(нормальной поддержки) и fbx там делать нечего имхо, для 2д движок шедеврален.

Ответить
0

Там есть версия с шарпом :) Правда, сам не юзал, так что об уровне поддержки не знаю.

Ответить
4

В текущей версии (3.1) обещали, что поддержка шарпа уже вполне вменяемая. Так-то оно то же самое, что в Unity (то есть Mono), но кажется версия стандарта шарпа повыше.
Вообще, из плюсов:
- Кроссплатформенность, как уже выше заметили
- GDScript, который похож на питон, может быть плюсом для тех кто много работал именно с питоном. Вообще, там на выбор скрипт, шарп, плюсы или свой визуальный редактор
- Нативное 2D, в отличие от UE и Unity, где все сцены трёхмерные. 3D тоже есть :)
- Неплохое сообщество (особенно при знании английского)
- Простота
Из минусов:
- Некоторые сложности с импортом анимации в 3D. FBX не поддерживается по идеологическим соображениям - он закрытый. Поддерживаются GLTF и OpenCOLLADA(DAE). И ещё ЕМНИП поддержку .blend(сцен из блендера) обещали, но это не сейчас.
- Энное количество багов, впрочем, они есть везде и тут как-то побыстрее решаются.

Ответить
0

Зачем нужен устаревший FBX, когда есть Collada и gltf 2.0?

Ответить
1

Коллада? Ели, cпасибо - нинада. :)

Ответить
0

FreeCollada. Отлично работает как со статикой, так и со скелетными мешами.

Ответить
0

Дык, и FBX отлично работает и как кросс-пакетный формат, и как файл ресурсов для движков.
Я помню простыню коллады, когда пользовал ее для экспорта физических параметров, констрейнов и прочего лет 10+ назад. Наверняка, все стало компактнее, быстрее и удобнее, однако не вижу смысла менять шило на мыло. С FBX пока все очень хорошо.

Ответить
0

"Проблема" fbx в том, что это внутренний формат автостола и чтоб его использовать другим софтам ВРОДЕ БЫ надо башлять автодеску. Плюс формат регулярно обновляется, соответственно и другому софту надо за ним гнаться чтобы быть актуальным. Для всяких опен сорс проектов типа годота это довольно сложно.

Ответить
0

Зачем нужен устаревший FBX

Плюс формат регулярно обновляется

Что же выбрать? Что же выбрать?

Нууу... Майка, Блендер, Юня подсасывают? Для меня усе ОК. :)

Ответить
0

Кстати при экспорте из блендера в анрил скелетал меш неадекватно себя ведет с анимацией(с майкой такой беды понятное дело нет).
Хотя может уже починили хз. А по поводу устаревшего так то не я говорил:) По мне так пофигу пусть формату хоть 100 лет, если он справляется со своими задачами, то мне большего и не надо. А упомянутый выше gltf 2.0 по сути только для браузеров будет обладать преимуществом, в остальном такое..

Ответить
3

я бы доверил этот выбор монетке :[

Ответить
–3

А я бы - логике. Юнити - это сишарп, УЕ - это блупринты. Человек, повозившись с юнити, так или иначе выучит язык, хотя бы в простом варианте, повозившись с УЕ человек выучит.. блупринты. После юнити - это почти готовый джуниор на сишарпе, ему хоть бухгалтерскую совфтину давай, хоть игровую, он будет писать. После УЕ это никому не нужный блупринтщик. Делайте выводы сами. Юнити - профессиональный рост, УЕ - профессиональный тупик.

Ответить
0

Никто не говорит, что монетка не могла бы выбрать Юнити ;). Сложно сказать что лучше. Сложно сказать нужен ли человеку навык программирования в принципе в оторванной от геймдева плоскости. В УЕ есть сишка в конце концов. Единственное чем УЕ наверное предпочтительней для меня - тем что у него с исходным текстом вроде дела как получше, нежели с Юнити, т.е УЕ не против того чтобы ты его правил под себя. Юнити со скрипом расстались с ним и дают его только читать (что-то поменялось в этом плане?)

Ответить
–1

Сишка нонче если кому и нужна, так на сеньёр-уровне, мидлы и джуниоры по плюсам нонче никому и даром не впёрлись. А сишарпы - все востребованы.
"Править под себя" - хорошее выражение, возьму на вооружение.. "Накодил под себя". Шедевр.

Ответить
1

Зря вы настолько "токсичный" на самом деле, могу предположить что это просто усталость за неделю набежала и вообще вы ути-бозетьки-котицьки. Зря пытаетесь полезность и бесполезность чего-либо оправдать исключительно "рыночком", зря вообще соскакиваете с проблемы выбора инструмента, как вам понравилось "под себя", на проблему чего там нужно этому рыночку, человек спрашивает не для рыночка, а для себя. Сеньоры, мидлы, джуниоры... ах, оставьте. Все сначала пишут дерьмо (если опыта побольше - чуть менее дерьмо, но всё ещё дерьмо), а потом уже приводят его в порядок в соответствии с требованиями, задачей и найденными проблемами.

Ответить
1

Объясняю, почему я такой категоричный. Я за свою жизнь уже натыкался по тупикам, писал на дельфи, на фокспро, потом под голый опенгл, помогал развивать такой движок, как DGLEngine.. Всё это были тупики, полученные знания в которых, мне никак не пригодились в дальнейшем. Т.е. потерянное зря время. UE - точно такой же тупик. Из него автор не вынесет ничего, кроме знаний блупринтов, которые нигде, кроме самого UE ему не пригодятся. Посему, я и хочу предупредить автора от подобного безрассудства. Зачем тратить время жизни на то, что тебе никак не понадобится в будущем? А в случае с U3D автор выйдет уже зная c#, а это по любому понадобится, хоть где угодно. Знал бы я в юности, сразу бы учил связку java-phyton-с# )) Правда, в юности еще джавы и пайтона не было..

Ответить
0

Что такое блупринты и насколько много в них профессионального роста, не знаю, так что сравнивать что лучше для прокачивания скилла, не возьмусь, но хочу отметить, что при разработке простеньких проектов на юнити скилл с# выше junior'a и не вырастет, скорей всего. Довольно ограниченный профессиональный рост получается.

Ответить
0

С нуля до джуна - это такой довольно большой профессиональный рост. Но чаще до мидла.

Ответить
0

будем честны, если у человека есть опыт разработки с# только в unity, то никому в энтерпрайзе такой человек не нужен. Он так и останется разрабатывать под юнити, потому что только там сможет найти посильные вакансии. middle unity developer это не то же самое, что middle C# developer в других сферах использования .net.

Т.е. что в ue4, что в юнити ты не научишься ничему уникальному, чего не мог бы получить в другом движке.

Поэтому выбирать между этими двумя стоит исходя из предпочтений в функционале и парадигмах движков.

Ответить
0

будем честны, если у человека есть опыт разработки с# только в unity, то никому в энтерпрайзе такой человек не нужен

Нууу.. Человек начинает с простых юнитевских скриптов, тут понятно, что это даже до джуна не дотягивает. Потом человек узнаёт, что под юнити можно писать не только на нативных Monobehavior, а что можно создать синглтоны, наследуемую структуру классов, фабрики объектов и всё это без какой-либо привязки к Unity. И вот он уже джун ) Когда до него дойдет, что то, что он видит на экране, это всего лишь графическое отображение логики игры, что GameObject это не самостоятельная сущность, а лишь отражение программной сущности, он уже почти мидл.

Ответить
2

Вообще насрать.
1) Отталкивайся от Языка, С++ точно пригодится везде.
2) Отталкивайся от проекта (игру для мобилок можно и на Construct 2 собирать и будет топич, по опыту. )
3) Отталкивайся от доступности гайдов для новичка, меня в свое время , так UE приманил.
4) Отталкивайся от проекта (да я уже писал это)
5) Смотри на поддержку и комьюнити, более токсичного комьюнити чем у UE, я не видел такие говноеды заносчивые (не все конечно), но знай что можешь остаться с проблемой один на один, так как будут слать в гайд который ты уже читал, спасают чуваки с Reddit, они реально помогают ну и Флакки (он отличный чел, рубит в UE ) .
6) Посмотри на плагины с всяких прог и их доступность. (сейчас Юнити и Анриал в принципе все кушают)
7) Отталкивайся от проекта.
А что там будет через 5 лет, хуй его знает. Может новый какой движок родят, или мы все умрем в пепле ядерной войны.

Ответить
1

Отталкивайся от Языка, С++ точно пригодится везде

Например, где?

Ответить
2

Например, прикрутить сишную библиотеку в виде плагина к юнити.

Ответить
1

С таким же успехом вы можете прикрутить дотнетовскую библиотеку к юнити.

Ответить
0

Как относится прикручивание дотнетовской библиотеки к примеру использования плюсов?

Ответить
1

В пизде. Ты на полном серьезе такие вопросы задаешь?

Ответить
1

Я на полном серьезе задаю такие вопросы. Я, программист с 20 летним стажем, не знаю ни одну отрасль, где могло бы сейчас пригодиться знание С++. Ну может где-то при написании драйверов (ага, очень популярное занятие).

Ответить
0

Вот интересно с точки зрения вашего опыта:

Есть два программиста: один условный мидл по плюсам и другой условный мидл по любому популярному языку. Мне кажется, что кандидат с плюсов видится более компетентным в плане общих знаний о software engineering. И, соответственно, любой другой язык он освоит без серьезных проблем, так как вроде почти все они так или иначе написаны на c++. А значит и проблем по идее у него тоже нет в плане трудоустройства.

В плане применимости, плюсы это ж ОС, IDE... почти везде их можно применить, хотя не всегда в этом смысл есть.

Ответить
2

По своему опыту скажу - программист на С++ неспособен освоить никакой другой язык более высокого уровня абстракций. Плюсы ведут к профессиональной деформации, говоря обычным языком, переворачивает мозги набекрень. Вниз - легко, среди мидлов плюсовиков масса ассемблерщиков, а я даже знал одного, который прямо в хексе код лабал. А вот вверх - проблема. Без указателей жизнь немила, а сборщик мусора наводит вселенскую тоску и беспричинную ярость.

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

Ответить
0

Без указателей жизнь немила, ага, именно поэтому все используют shared_ptr, чтобы не заниматься ручным управлением памятью.

Ответить
2

Если без 3D, то Game Maker 2 - нормально для одиночки.
Если универсальный, то Godot, но 3D там не очень пока.

Если 3D и что-то простое типа валксима UE на BP.
Грубо говоря, он из коробки - красивее.

Если сложное, то одиночке проще Unity,
но тоже все проклянешь и не один раз :)

Ответить
1

Я х.з. кто эти люди, которые говорят, что движок в котором не нужно знать языки программирования сложнее чем тот, где их знать нужно. Как-то это совсем не логично т_т
Однако в UE из коробки не самая хорошая работа с местным "игровым интерфейсом" - UMG. В принципе на ютубе есть гайды по созданию ВН'ки на UE, но это точно не самое приятное что есть в движке.
Но планируешь уже переходить на 3дшечку и делать нечто большее, но не хочешь учить языки программирования (но логику придётся всё равно), то велком.

Ответить
0

Так я не говорю, что не хочу учить язык. Через тот же RenPy я заинтересовался Питоном и основы выучил. Просто если сравнивать плюсы и шарп, то у меня есть небольшой опыт в шарпе и он мне понятнее, чем плюсы.

Ответить
5

Если ты не студия на 10+ человек и не делаешь что-то сетевое и на консоли, то кодить в UE тебе нафиг не нужно. Функционал блюпринтов покрывает 95% игровых запросов. Что-то кодить тебе нужно только если тебе требуются большие (обработка логики в больше чем 1к объектов за кадр) вычисления, либо у тебя какие-то совсем суровые желания в голове.

Ответить
0

А вот это уже заявочка на победу. В блюпринты потыкался, но не настолько, чтобы увидеть эти плюсы.

Ответить
4

Проблема в том что большинство нытиков про "бп гавно, учи плюсы" достаточно не разбирались в движке и не имеют солидного опыта. За почти 2 года на UE я не встречал задач, которые я не решил бы на бп.
Из стандартного движка ты не сможешь только скомпилировать сервер себе, и бп очень плохи в вычислении больших объёмов информации.

Ответить
1

Блупринты проигрывают плюсам по следующим параметрам: Меньшее количество одновременно видимой логики на экране без необходимости скроллить. Более высокая скорость работы (если быстро печатаешь), на первых стадиях, когда только учишься будет казаться что все как раз наоборот, так как c++ дольше компилируется. Но я не противник блупринтов. Все таки иметь возможность не программисту понимать, писать и изменять логику игры - перевешивает все минусы. Поэтому логику с низким уровнем абстракции пишут как правило на плюсах, тогда как художнику не надо знать линейную алгебру, особенности наследования классов, но иметь возможность дергать логику высокой абстракции как раз кстати.

Ответить
0

Я уж не говорю про то что, нужный узел всегда можно написать на C++ (ну или воспользоваться MagicNode https://www.unrealengine.com/marketplace/en-US/magic-node)

Ответить
1

Для того чтобы его написать всё равно нужно изучать С или обращаться к кому-то. Просто в движке столько встроенных возможностей, что одинокому разрабу будет за глаза.
Ну и он точно не пропустит где-нибудь ; и не сможет подать неправильный тип данных куда не следует, как в "доступном движке для народа".

Ответить
0

Просто у вас задач не было, вот и всё..

Ответить
1

По поводу "на будущее" - глянь вот
https://www.youtube.com/watch?v=fnuWG2I2QCY
https://www.youtube.com/watch?v=Qjt_MqEOcGM
Ингейм ролики. Скачать и запустить у себя можно будет со следующей версией движка.

Ответить
0

Таки ингейм уже сейчас, а не "в будущем"..

Ответить
0

Таки ингейм когда-то в прошлом.
https://youtu.be/dO2rM-l-vdQ

Ответить
0

а что тут такого?

Ответить
1

Если с запасом на будущее - однозначно UE4. Нынче он развивается куда быстрее.
Да и на данный момент более чем хорош, а для новичков есть миллионы часов туториалов на ютубе и тысячи статей.
Комьюнити огромное и вполне дружелюбное, даже российское.
Шарпы хоть и легче плюсов, но блюпринты еще проще, а для синглплеерных игр их хватает за глаза в 99% случаев.
Собственно мой выбор несколько лет пал на UE4, пока ни разу не пожалел.

Ответить
0

А мне друг из садика сказал что UE для АУЕ, потому ты не прав и вообще какашка.

Ответить
1

После первых комментов я скачал UE.

Прочитав всю ветку сейчас, я отложил UE и пошёл допиливать свой проект на RenPy.

Спасибо, помогли! :D

Ответить
0

Если ты хочешь превратить хобби в работу - стоит вернуться в УЕ4 или взять Юнити. Если важнее сделать конкретный проект - то тут уже думай. Для текстового квеста Юнити лучше, но если захочется 3Д - в УЕ4 из коробки есть очень многое.

Ответить
0

Для нормального 3Д нужно либо самому хорошо моделить и любить это, либо брать кого-то в команду. Мне в приоритете пока в качестве хобби пилить свои проекты, а переносить половину работы с RenPy на Юнити не хочется, потому что я неоднократно искал какие-то адекватные инструменты для проекта и всё либо платное, либо не то, что мне нужно, а писать с нуля на C# свой велосипед... Не уверен, что мне это нужно на данном этапе.

Хотя если вы знаете что-то о текстовых квестах и Юнити что-то такое, чего не знаю я... Прошу поделиться :)

Ответить
2

Я скорее тыкал УЕ4 и он немного не фонтан с 2Д и сложными интерфейсами - тут поверю знакомым, пробовавшим оба движка, что Юнити удобнее.
Под оба двигла, кстати, полно готовых ассетов, много даже бесплатных (глянь официальные маркеты, они еще и каждый месяц допхаляву раздают).
Можешь попробовать сделать мелкие проекты на обоих движках, и посмотреть что больше понравится.

Ответить
0

UMG очень хорошо дружит со сложными интерфейсами

Ответить
0

Тут скорее про то, что работать не слишком удобно. Но я не видел, как в Юнити.

Ответить
1

Пишешь код - бери Юнити, он проще. Если плохо знаешь C#, то бери UE4, там блюпринты.

Ответить
–1

Возьмёт UE и никогда не изучит сишарп ) Тут надо определиться, человеку надо быстро сделать игру, или профессионально вырасти.

Ответить
0

Это верно. Еще одна деталь. Если ориентируешься на мобилки, то Юнити будет предпочтительным.

Ответить
0

Еще отчисления.. У меня проверсия Unity, без отчислений, даже если доход превышает $100к в год. Есть ли такая у UE ?

Ответить
0

Есть, но не для инди. А так - до 3к в квартал бесплатно, выше - 5%. Но давай серьезно, для инди это вообще не проблема.

Ответить
0

Ну я инди, у меня первый год по выходу было гораздо больше, чем 3к в квартал ) У меня было даже больше, чем 100к в год.

Ответить
0

Ну так отдать 5% - это разве проблема?

Ответить
0

Ну таки да.. Стиму отдай 30%, государству отдай 5%, банку отдай 5%, еще и этим отдавать? Таки жаба..

Ответить
0

Для первого проекта рекомендую остановиться на unity, возможности UE мне кажется тут избыточными.

Ответить
0

Для каждого человека - по разному. Я первый проект делал на УЕ, хоть и ушло на это много времени, но зато результат стал лучше ожидаемого. Хочу сказать, если человек хочет, то пусть пишет на юнити, или захочет на УЕ

Ответить
0

Для соло - Unity, для команды - UE.. Так-то UE картинку может дать получше юнитевской, но количество работы для этой картинки в разы больше, чем на юнити. Ну и нативный сишарп на юнити это таки плюс. Огромный плюс, я бы сказал.

Ответить
0

Категорично UE против Unity рекомендуют те, кто считает что игры нужно делать без программирования. Категорично один из движков так же рекомендуют те, кто не смогли разобраться во втором / слишком привыкли к первому. У UE хуже дела с мобилками и когда проект разрастается его компиляция очень долгая. Ещё ответов на вопросы проще найти было по Unity, больше комьюнити новичков, года два назад, сейчас не уверен что так же. У Unity сейчас минус в том, что все их новые крутые свистелки находятся только в тестовом виде.

Ответить
0

что все их новые крутые свистелки находятся только в тестовом виде

Да, потому, наиболее стабильная из всех последних, это 2017.3 без свистелок и перделок. Её и рекомендую.

Ответить
0

Ну, в моем проекте 2018.1.6, серьезные проблемы встречались, но мало.

Ответить
0

На перспективу мне кажется UE лучше - у них больше ресурсов для развития. А С++ там не сложный, библиотеки же, на голых плюсах уже никто не пишет давно.

Ответить
0

Вай великий холивар. Как по мне, лучше: то у чего инструментарий удобней и обширней. По поводу блюпринтов могу сказать одно. Кривыми руками можно и ложку во время еды сломать.

Ответить
0

А PUBG не AAA проект? Он сделан на UE и ни в какой потолок не упекается. Комментатор сверху не прав. Чтобы упереться в него нудно очень сильно постараться

Ответить
0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } } ]
Уве Болл вернулся в кино
и начал экранизировать flash-игры
Подписаться на push-уведомления