nimfai: то что есть из коробки у ue4, нужно покупать у юньки. - НЕТ. вывод какой то притянутый.
правильный вывод: то что есть у анрила в коробке - у юньки заменено другими инструментами из коробки, но если ОЧЕНЬ хочется примерно, как в анриле, то можно скачать.
за 5 лет то можно понять, что инструменты разные и все по своему удобные в обоих движках? кому то неудобна крутая работа с анимацией в UE кому то удобно работать в юньке. (впрочем про про версию 5 летней давности я много слышал и про нестабильность и говеную оптимизацию и много плохого. юнити за 5 лет изменился.).
- и вобще где я такое сказал что надо покупать? пока не видел ни 1 проекта где покупка для первого проекта была бы необходимостью.
Без комментариев. - тем кому нечего сказать обычно ничего не пишут. тут коментировать нечего. либо ты ковыряешься в двигле 5 лет ради ковыряния и набивания скилла, либо желаешь иметь законченный проект. каждый выбирает для себя сам, что хочет.
Я работал с юнити 5лет, - хоть 1 проект продавался? закончен? впрочем это не так важно - не уверен что у тебя есть хоть 1 проект уровня поезда или света или 35 мм (это я взял проекты с упором на графоний и работу с анимацией) - иначе бы об этом знали бы многие. так что можно сколько угодно лет ковыряться в двигле - но так и не суметь понять, чем оно лучше / хуже. я не пытаюсь тебя принизить - обрати нимание на правильный вывод: можно ковыряться в моторе несколько лет, но так и не стать профи, или ковыряться но так и не научиться объяснять другому почему ЕМУ будет лучше выбрать именно этот мотор. хоть немного понятно к чему я?
Я знаю что говорю: - судя постам не... пока не знаешь - у тебя по ответам выходит так: мне нравится анрил и работать в нем, а вот юнька не понравилась. хз почему, просто анрил лучше по моему.
впрочем ты можешь знать, что угодно. я больше верю эпикам, которые говорили, что юнити очень неплох по их мнению. и себе, когда видел какую картинку способен выдать движок, в руках профи по графике.
и ещё раз вижу подтверждение факта - финальная аппеляция к собственному мнению/пристрастиям, ни 1 реально сильного аргумента в пользу однозначного выбора между юнькой и анрилом ещё никто не привел.
даже казалось бы очевидная слабость юньки в плане архитектуры объектов в крупном проекте - дело привычки и способности строить иерархию.
весь разговор напоминает мне сравнение машин - что то типа "я 5 лет ездил на бехе/ауди, а последние 3 года пересел на мерс амг" и вроде всем очевидно, что не только мерс развивается последние 3 года и выпускает новые модели... и что у мерса за 6 лямов есть аналогичные конкрутенты, и что конкструкторы из конкурирующих фирм не школьники, а профи, которые двигают свою продукцию более 5 лет, но все равно что то 1 круче. неужели не очевидно почему?
"Есть Blueprint" - мягко говоря весьма сомнительное преимущество. ибо если бы вы работали с Unity, знали бы что полноценное визуальное программирование есть и в ней. причем позволяющее делать аналогичные вещи что и в UE4.
"UE лучше редактор ландшафт" - крайне субъективно. хоткеи, движения карты есть и там и там, настройка интерфейса в юньке позволяет подогнать под дизайнера. но вобще то часто карты не делают в самом "редакторе из коробки". инструменты по созданию частей карты пишутся под конкретный движок (в случае обсуждения - либо на юнити, либо в на сях). те куцые возможности анрила в плане вырезов и прочей мелочевки с лихвой перебивает майя или макс, и готовые модели импортируются в редактор. по факту (это просто быстрее).
"Просто шикарный редактор UI и материалов" - для супер профи возможно... возникает логичный вопрос - инди будут использовать этот редактор на полную катушку? я таких проектов законченных не знаю. по факту в юнити, те же возможности для создания аналогичной картинки (ну право слово вы просто поищите аддоны). то же субъективное преимущество. к тому же если уж совсем хочется - можно делать модели в уе и экспортить их.
"Круто сделана работа с анимацией." - у многих аниматоров в профессиональном плане были коменты, что анимация в юньке сделана логичнее и менее заморочено, чем в анриле. и о какой анимации речь если делать анимацию в самом редакторе это, даже на мой взгляд мазохизм. прикручивание анимации? что в этом крутого? в юньке есть те же механизмы. да их придется скачать. но базовая анимация в юньке построена более логична для не профессиональной команды, т.е. при равном итоговом результате что будет гораздо выгоднее: разбираться в структуре UE, где она продиктована больше структурированной архитектурой самого движка или более интуитивном интерфейсе Юньки?
"Однако по Вашему вопросу." - у меня не было вопроса. или был?
ну и самый известный факт - реклама и пиар юнити вобще никак рядом не стоят с пиаром UE, ибо я пока не видел кроме профф разработчиков, кто мог бы мог охарактеризовать его объективно, без апелляции к личному мнению. про "инди" я вобще молчу, а это очень много говорит об отделе пиара и маркетинга эпиков (в вашем ответе кстати лишь подтверждение этого).
Это значит, "что UE лучше потому, что мне он больше нравится" - это аргумент.
"Что лучше знаете, тем и пользуйтесь." - не совсем согласен, ибо такой вывод слишком общий и очевидный совершенно не учитывающий реалии. команда может разваливаться и меняться, и тут важнее быстрый "въезд", что как раз для UE является минусом. есть движки на которых сетевые танки с простенькой механикой пишутся за 2-4 часа при полном отсутствии знания, и с графикой на уровне.
Константин Китманов: "Если это окажется чем-то серьезным, тогда и будете париться насчет лицензии." - даже если будет серьезное что то - просто почитать у них же на сайте отличия про версии, от бесплатной - там в соновном все направлено на колаборейшен и облачные сервисы. что не касается команд условно от 1-3 человек вообще никак (ну только если прям желание есть делать вид что команде из 2-х человек нужны технологии и жесткий контроль версий в облаке).
Юрий Ярош:
1. "а вот Unity режется автоматом" - во первых не автоматом, надо включать в проекте определенные настройки. и ваши слова опровергаются банальной базовой сценой с паралелепипедом после запекания. размер по умолчанию проекта по сравнению с проектом юньки заставляет изучить меню запекания.
при желании в юнити тоже можно порезать до минимума.
2. "Хотя размер Runtime у Unity больше. " - в итоге это не сильно влияет на конечного потребителя, если это специально не фиксировать. то есть придраться можно я согласен.
3. Оптимизация у UE лучше, по причине Target компиляции llvm'ом под конкретное устройство. - ну немного не так. юнити тоже может компилировать под конкретную версию. да и не в ней дело. юнька не написана на крестах. была бы написана, сравнение имело бы место.
4. "избыточная объектная модель приводит к тому, что оно жрёт в 1.5-2 раза больше памяти" - 1.5-2 раза в сравнении с чем? с UE? - ну бред. ядро движков писали люди не тупые. если на сцене одинаковые объекты и их кол-во - никто не выдумывает, какие то "особые алгоритмы ядра" жрущие на одной машине 4 гига, а на другой в той же сцене 8. Код юнити (ядро и основы многих технологий) написаны не школьниками. как и код UE.
максимум, что может быть в теории на одной тачке 4 гига на другой 5 (и то это если просто болт положить на все контейнеры и переменные, которые программер заводит).
5. "и можно и по потребности самому полезть в ассемблер, а с Unity так не получится." - 1. дизасеблу подвергается любой экзешник или длл, если знать как.
если понадобилось дизасемблить - это всего лишь намекает на 2 варианта - либо вы делаете что то не так, либо ваш проект сильно перегружен (вроде 850 уникальных механник в карточной игре "дурак" - ну ясно же что никто не будет даже 1/4 задумок смотреть, кроме пары фанатов).
почитайте статьи разработчиков - они явно намекают что движки затем и делались, что бы программеры сосредотачивались на конечном продукте, а не на дизасемблировании, и проблемах с GC или таргет компилом.
Chvalov: советую фильтровать то, что вам говорят, ибо люди часто либо не полностью объясняют (или не умеют объяснять так что бы кто то кроме них понимал), либо фигню несут, которая противоречит банальной логике. просто по коменту видно что Юрию, больше нравится UE, но это не значит что Юнити хуже по графике, или менее производительный... да это смешно.
"Unity - более стабильный, менее производительный," - у UE почему графика лучше считается? ведь используется по сути тот же dx - потому что там по умолчанию очень много настроек и шейдер фильтров, которые надо включать в юньке, это для примера (дело не только в них, но как пример).
насчет стабильности - ну вобще считается так, но вы не заметите что UE менее стабильный (за год дебагов - 1 вылет, и то я сам к этому экзепшену привел).
насчет менее производительности юньки - одинаковые сцены 300+ фпс в юньке и около 100 в UE говорят об обратном. все дело в настройках и объектах на сцене. вполне может получиться что игра на юньке будет более производительной, но я бы фильтровал эти слова так: если в UE проект идет на 60 fps в unity немного более вероятно, что без тщательной настройки у вас будет около 55 +/- 2-3 фпс.
можете посмотреть некоторые проекты на юньке, где графика на хорошем фрейм рейте у неподготовленных заставляет охать и ахать (то есть как минимум выглядит хорошо).
основная мысль поста - "при кривых руках и плохом понимании" - и самый оптимизированный движок будет выдавать менее 10 fps на пустой сцене.
p.s. не удержался, ну ведь вообще человеку ничего не объяснил
никакой на самом деле. лучше ответь на вопрос: для каких целей тебе важен размер на экране/кол-во строк?
у меня описание класса около 150 строк. в среднем 1 функция на 40-100 строк (как правило к каждому циклу или условиию 2-5 строк комментариев).
иногда из вложенности специально делаешь разветвленную структуру - что бы другие не тратили время на дебаг и понимание что тут твориться.
я к тому что все зависит от целей и понтов. там и размер функций подбирается под того с кем работаешь. хотя можно чисто по-русски - не думая - попросить уволить 1 программиста и нанять профессионала за 3-4 раза большую зп.
Дмитрий: поиск цели для атаки при спавне большого количества зомби. Тут пришлось перейти на нативный код, а позже полностью начать переписывать всю систему. Сейчас как раз заканчиваю её.
есть куча алгоритмов по поискам пути (цель - те же вершины). зачем было переписывать полностью? готовые решения не подходят?
Дмитрий: "Я не имел в виду, что сумма огромная или что-то такое." - а никто про это не говорил. просто непонятно причина, по которой упомянули сумму и сроки. тем более из последующего пояснения видно, что они тут "никаким боком не при чем". тем более я специально намекнул "только не думайте, что я не верю " - что не требовало объяснений. Дмитрий: Это не компания, а просто один человек из небогатой европейской страны. У человека обязательства перед издателем, он не хочет потерять его доверие.
весьма странное поведение для человека, который "не хочет потерять доверие". забавно, что ведет он себя по глупому. тем более он из европы.
тем более о чем речь если человек, Дмитрий: "решивший выпустить игру".
при чем тут Дмитрий: "У человека обязательства перед издателем, он не хочет потерять его доверие, наработанное за несколько лет до этого"....
чет я перестал понимать о чем речь. выпустить значит сделать игру? просто на мой взгляд выпустить включает в себя понятия сделать, и издать. Дмитрий: Первый программист был из Украины, но скиллы у него были довольно слабые и через какое-то время был уволен... Насколько знаю, перед вторым программером рейтинг в Стиме был около 60-70% положительных отзывов и огромное количество установок
по моему этот человек, не желающий терять доверие какого то там издателя, немного не своим делом занялся. 60-70% вполне неплохой результат. и 10% от вас не стоили тех усилий, по увольнению, по найму человека из канады и как результат вас в послдедствии. это чисто мое мнение основанное на полученной иноформации (по моему это очевидно). игры с меньшим процентом отзывов и меньшими напрягами вполне нормально отбивают вложенния в них.
Дмитрий: Я за день переписал световой движок, игра сразу стала выдавать пару сотен fps.... Ничего сверхнавороченного не было - игра 2d, вид сверху, помещения, толпы зомби, крафт и т.п.
всего пару сотен в 2д? игра сделанная не в конструкторе и световой движок вами переписан? за сутки. вероятно ничего сложного ни в самой игре ни в используемых алгоритмах нет. тогда фпсов мало.
честно скажите - вы хвалитесь или поясняете ситуацию? Дмитрий: недостаточных скиллов программеров использовались сомнительные решения
было же всего 3 программера.
(на что заказчиком было потрачено пол года времени и несколько тысяч долларов). - поверьте после миллиардного проекта (в баксах) в некоторых сферах бизнесса и уже полутора лет допиливания процедур, гораздо проще относишься к просранным срокам в геймдеве.))) хотя это я такой раздолбай - если нормально задачи не ставить и не прислушиваться к советам программистов выполняющих эту задачу... я не особо парюсь о результатах. и все же.. слышать "выдавалось примерно 3 FPS" - несколько странно. это российская компания? во первых уже хотя бы потому, что 3 фпса будут заметны сразу. (только не думайте, что я не верю - когда я работал фпс были норм, но вот с идеями и "интересным геймплеем и основными фишками" был полный швах).
Мне нет. только под PC либо ps3-4. там все стандартно и давно выверено. что бы загубить фпс там надо просто не думая код писать, либо придумать, что то настолько навороченное, в чем в реальности мало кто сможет разобраться и оценить.
Тут правда вопросик возникает - а оно надо вобще, так напрягаться то, если вам приходиться все это дело переписывать? (оставлю этот ответ на веру, ибо у меня на этот счет есть свои менеджерские взгляды).
Дмитрий:
Я говорил не о тех возможностях, которые уже предоставляет движок, а о возможностях, которые он не предоставляет.
значит я просто не понял что речь шла о движке а не о языке в целом из сказанного... Дмитрий: " Речь шла об вообще всех возможностях, которые даёт с++. "
это все не так важно.
перечитал - убедили - перспектива блюпринтов в серьезной студии - мапмейкер, скрипт-программер, гейм-дизигнер (хорошо, если главный);
если цель "карьеры в геймдеве" более важна, чем движок, инди-студия и создать законченный проект (пусть он и будет простеньким) - соглашусь. в этом случае да, нет возражений.
исключительно мои мысли: мне решение в 28 лет начать фактически с 0 и уйти в программинг кажется несколько импульсивным.
сильно не уверен, что в "одной большой стране" (хз откуда автор родом - если с украины, там получше вроде как слышал) он действительно сможет "изучать движок и наслаждаться любимым делом" (вероятно автор в скором времени откажется от этой гиблой затеи, если уже не отказался).
Дмитрий: "где не требуется максимальная производительность"
"вообще всех возможностях, которые даёт с++"
"максимальная производительность", "все возможности языка с++" - вы ведь в курсе, что асемблер быстрее? а если на машинном коде писать сразу так вобще! только быстрее - о чем речь: о человеко-часах или кол-ве операций в секунду? - опять абстрактная вещь. обсуждаем, идеально пишушего код, человека в вакууме при ответе на вопрос какой движок лучше выбрать автору?
что за "все возможности"? для чего они автору? как они ему помогут реализовать то, что он хочет? он точно будет использовать "ВСЕ ВОЗМОЖНОСТИ"? вы уверены?
держу пари, вы сами все возможности не знаете.
как и я, автор, а так же 99.5% программистов, которые все таки довели свои проекты до конца. причем не на с++, а на каком нибудь "медленном" delphi,java,c#,(вставьте свой вариант).
максимальная производительность чего? с каких пор механнике игры (геймплею) требуется максимальная роизводительность при мощностях современных процессоров? можете описать пример? а то боюсь разговаривать, не понимая о чем речь невозможно. или это какая то другая максимальная производительность?
"Я не утверждал, что с помощью blueprint ничего невозможно сделать." - да не утверждали. это я хватанул. диалог был таким:
"
Михаил Снэ Бьёрн Палагин Михаил Снэ Бьёрн Палагин:
а что я могу не зная C++ делать игру и ее механику полностью на блюпринте?
Написано 17 мая
Ответить
Coderast Coderast
Нет, блюпринт лишь помощник. ...
Написано 17 мая
"
что несколько неверно. полноценную игру с достаточно сложной механникой геймплея, аи, систем меню, спавна монстров, функций, макросов, евентов, и прочих взаимодействий игровых объектов с гг по определенным правилам от начала до конца + кучи других задач - можно. для некоторых это проще, чем наследование, и темплейты классов и переменных, виртуальные функции и перегрузки (хотя для некоторых и нет). и такие вещи есть не только в уе. В юнити кстати помимо С# есть скриптовый язык.
что я собственно и (по)пытался отметить. ничего более.
у этих методов правда недостаток - через 2 года автор мастер блюпринтов и скриптового юнити может быть не востребован в геймдеве в кое какой стране.
так же судя по тому что вы даже не намекнули на это - рискну предположить, что через кучу подготовительных этапов вы попросту ещё не прошли.
ответ на суть Вашего вопроса: ни один из тех, что вы выбрали. - но это только мое мнение на основе вашего вопроса и предистории к нему.
Дмитрий Дмитрий
Михаил Снэ Бьёрн Палагин: Например, основной язык в Unreal Engine - это C++, а в Unity - C#. Если у вас нет опыта ни в том, ни в другом, то логично будет выбрать тот, который учить проще.
вобще то нелогично... хотя бы из за этого: основной язык НА КОТОРОМ исходники УЕ - с++ язык для разработки blueprint / c++ (имено в такой последовательности). многие люди не зная ни одного языка программирования отлично разрабатывают логику без использования с++ в уе. как то им ничего не мешало создать клиент серверное приложение с созданием аккаунта, классов игроков, мобов, моделей, текстур.... чето странно люди не зная языка программирования вполне неплохо в сжатые сроки выдают вполне годные инди поделки...
"а что я могу не зная C++ делать игру и ее механику полностью на блюпринте? " - да. спагетти конечно ещё те получаются если механника навороченная... но делать можно абсолютно то же самое что и кодом. но в .нити есть плагины для такого же визуального программирования.
"
Coderast Coderast
Нет, блюпринт лишь помощник." - нет блюпринт - это шаблонное управление, под которым лежит тот же с++ код и доступ к тем же функциям.
однако в чем согласен интуитивно юнити ближе к инди студиям потому, что написан в соновном для них и в нем попроще разбираться основной массе (зависит от талантов и хотения человека).
но на первые проекты я даже его бы не рекомендовал. есть множество ругих движков с предоставляемой и говтовой клиент-серверной частью, анимацией, текстурами моделями, примитивной комбат системой, спелл-каст, левел эдитором, начальными моделями, системой раздачи квестов.
интересно вы понимаете сколько времени уйдет на реализацию этих вещей в выбранных вами движках? вы же не думаете что эти движки позволит вам перейти к геймплею сразу?
Даниил Басманов:
"Unreal и CryEngine всю жизнь были ориентированы на большие студии" - ну неправда. причина не использования этих двиков инди студиями - бюджет и стоимость подписок до недавнего времени. механизмы и технологии разработки поменялись но не настолько кардинально.
"управление командой" - вот в основном поэтому мелкие команды разваливаются. очень много особенно у нас в стране людей которые думают что если они будут управлять командой, то все будет сделано идеально. прошу прощения автор хочет не кучу кирпичей перетащить с одного склада на другой. и это посленее, чему ему надо обучаться. если он конечно хочет что нибудь сделать работающее, а не гордо заявить что его проект развалился из за идиотов которые не смогли его услышать.
"разработка игр, монетизация, маркетинг" - первое слишком асбтрактное понятие. остальные 2 - они нужны бизнесмену который не мечту реализует, а зарабатывает. надо ли говорить, что за поделка получиться из под пера такого "таланта"?
"Начинать делать игры с MMO это самоубийство" - тут согласен, но наполовину. Таких "хочу сделать мморпг" - миллионы. просто подумайте - что побуждает на это людей? в этом ответ в чем причина неудач. если правильно поймете.
" Навык завершения игр очень " - такого навыка нет. либо вы непонятно объяснили.
"Когда вы дойдёте до момента, когда вы можете за день наколбасить платформер" - способность необходимая для устройства в геймдев в качестве рядового разработчика. для создания игры она не особо нужна. не лишне, но только в случае когда вы загоняете себя в жесткие сроки. далее вопрос даже раскрывается почему так... но навык то нам все равно нужен - только зачем он нужен, когда с напарником надо год работать, а потом он уйдет неясно. В этой скорости на 50% и кроется причина того, что вы не сможете взаимодействовать с напарником. по сути если вы не клепальщик платформеров посвятивший этому последние 15 лет как минимум -это будет только мешать.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.