Comments 30
Статья полезная, сижу на Юнити, но хочется покопать разные движки и посмотреть подходы.
Единственное, чего не понятно - размеры игр.
Что значит должны и весят 1.5-2 гиг?
Речь об игре или все же о проекте?
Потому что проект весит +- 20 мб а остальное - сколько ресурсов положишь, столько и будет
"Самое тяжелое – отвыкнуть ставить точки с запятыми в конце каждой строки, до сих пор на автомате ставлю."
Вообще, GDScript не запрещает ставить точки с запятой в конце строки, мне не так уж и редко попадается код заставленный такими символами. Но без точек с запятой код всё-таки на мой взгляд лучше выглядит.
Даже, когда я работала с Unity, он мне казался каким-то тяжёлым и неповоротливым. Он долго запускается, игры, которые должны весить 0,3-0,5 Гб, на нем весят 1,5-2 Гб.
А вот тут согласен полностью. Раньше тоже на Unity работал, потом попробовал Godot. Сейчас когда открываю редактор Unity неприятно прям становится.
Ждём версии 4.0 с новым рендером, надеюсь тогда крупные компании обратят внимание на этот движок.
Кстати, если есть какие-то вопросы по godot можете ко мне обращаться, я его довольно неплохо знаю.
Делал игру Dive for Life в Godot. Движок понравился. Бубен потребовался только при настройке экспорта. Там, когда обновляешь штатно через интерфейс до свежей версии, искал он её в папке старой. Но это легко лечится переименованием.
Проблема иногда не в том, какой движок лучше или удобнее, а количество доступных ресурсов для него, как в виде объектов, так и информации по разработке и решению возникающих нюансов.
А по поводу Юнити понравилась фраза о том, что сделать игру на нем может и небольшая команда, но вот чтобы сделать игру, которая не будет тормозить или часто глючить, для этого нужна крупная команда.
Просто мне всегда казалось, что движок под это не заточен, и организация сцен здесь такая, что многие штуки, которые должны являться преимуществом и удобством ООП, здесь выглядит как лишние проблемы.
Хотелось бы чтобы раскрыли тему поподробнее. У меня лично особых проблем с ООП в юнити не было, особенно если строить проект вокруг какого-нибудь Zenject. Чем именно Godot показался удобнее?
Я не знаю, как там все это устроено «под капотом», и что на самом деле происходит, когда посылается сигнал, но мне, с точки зрения пользователя, кажется очень логичным, что не нужно постоянно проверять нажата ли кнопка или не покинул ли объект экран. Здесь именно кнопка в момент нажатия или объект, который покидает экран, посылают сигналы о том, что произошло.
Тоже хотелось бы уточнить. В юнити похожую функцию выполняют эвенты, причём их аж две разновидности - обычные C# эвенты плюс UnityEvents. Покидание объектом экрана мб действительно потребует написания своей собственной проверки, но вот какая-нибудь кнопка по нажатию вполне себе кидает эвент onClick без всяких доработок. Чем это отличается от Godot'овских сигналов?
inb4 нет, я не пытаюсь защищать юнити, хоть это и основная технология в моём стеке. Я понимаю что он та ещё срань в некоторых аспектах. Просто искренне интересно узнать про другие технологии для расширения кругозора :)
Хотелось бы чтобы раскрыли тему поподробнее. У меня лично особых проблем с ООП в юнити не было, особенно если строить проект вокруг какого-нибудь Zenject. Чем именно Godot показался удобнее?
Чем это отличается от Godot'овских сигналов?
Я с Zenject не работала, поэтому по нему судить не могу)
В Godot все строится на основе сцен. Сцен не в смысле игровых локаций, а в смысле, что каждый значимый объект игры - сцена. Персонаж - отдельная сцена, враг отдельная сцена, оружие может быть отдельной сценой. И проект - это набор вот этих вот сцен в самых разных его комбинациях. То есть можно создать один раз врага, один раз оружие, а дальше уже "вешать" на него всякое. В Unity можно теги добавлять, можно одни скрипты использовать, но это немного не то. Может, чего просто в Unity не знаю)
Чем это отличается от Godot'овских сигналов?
Да наверно, ничем, ну кроме того, что один инструмент используется для любых типов событий
Disclaimer: я не имею желание очернить, обелить или оскорбить любого человека или технологию в нижележащем тексте. Фактологических ошибок в статье немного, но я значительно не согласен с идеей статьи. Не стоит принимать мой токсичный комментарий (хотя я честно пытался сделать его менее "токсичным") близко к сердцу.
Почему на нем?
Он долго запускается, игры, которые должны весить 0,3-0,5 Гб, на нем весят 1,5-2 Гб.
Если под "долго запускается" имеется ввиду редактор, то ему это позволительно делать (можно привести аналогию с простым "блокнотом", который потребляет пару МБ ОЗУ и запускается мгновенно, и с "блокнотом для программистов", который потребляет ГБ ОЗУ и может запускаться до нескольких минут на огромных проектах). Если же речь про сам итоговый билд игры, то, исходя из моего опыта, запуск может казаться долгим лишь из-за лого самого юнити в бесплатной версии.
Про объем билда могу лишь не согласиться. Только что проверил на актуальной LTS-версии - сделал за пару часов аналог flappyBird'a используя шаблон 2D (не прибегая к тюнингу для снижения размера итогового файла). И при размере ассетов в 200кб, билд windows-x64 занимал 59.8МБ, а файл .apk для android лишь 18.3МБ. Разумеется, это в 18 раз больше, чем на нативных для платформы ЯП (хотя для винды нужен будет ещё msvc-redist), но где Вы последний раз видели игру меньше, хотя бы, 10 мегабайт?
нормальную поддержку 2D в нее добавили относительно недавно, да и то, по сути, костылем
Думаю, что поддержка 2D в UE4 Вас шокирует... Касательно юнити, там очень хорошая поддержка 2D, даже физика не от 3D, так что претензии на 3D-корни движка мне не ясны. Если конкретно идет речь про оверхед от математики, то он предельно низок, и, на самом деле, выгоды от использования именно 3D-математики больше. Если же важна именно скорость рендеринга (т.е. аппаратное ускорение 2D-отрисовки), то, увы, но её, вроде бы, теперь вообще нигде нет. После популяризации DirectX10/OpenGL3 все ушли с фиксированного конвейера рендеринга, то есть, ради возможности использовать пост-процессинг и кастомные материалы (гуглится по запросу "2d shaders") мы стали даже 2D рисовать как 3D. Возможно, что за счет упрощения математики в шейдере из-за отказа от 3-го измерения в Godot'е, будет некоторое увеличение скорости, но оно будет несоизмеримо мало по сравнению с грамотной работой с ассетами, хотя бы, в том же юнити.
ООП как по учебнику
прочтите про сцены, узлы, экземпляры
Прочитал. В терминах юнити это будет: префабы, компоненты, экземпляры (инстанцы, если пользоваться общеупотребильной терминологией). На самом деле, идея с иерархией компонентов - достаточно интересная, но как и в том же анриле, вызывает сомнения. На ум приходит лишь польза от перемещения дочерних объектов вместе с родительскими, но это применимо лишь для тех компонентов, что имеют координаты в сцене. Погуглив, четкого ответа на вопрос "зачем так сделано" я не нашел.
У юнити есть множественно крайне сомнительных решений в архитектуре, но здесь это не оно, по моему мнению.
Сигналы
В Unity есть множество callback'ов (функций, что вызываются в скрипте, когда происходит какое-то событие) как от компонентов (OnTriggerEnter2D), так и от движка (Start, Update). Также можно делать собственные callback'и через UnityEvent (ну, или event из самого C#). Вообще, концепция событийно-ориентированного программирования развита в юнити достаточно не плохо, но если Godot достигает в этом аспекте новых вершин, то это действительно хороший повод к нему приглядеться.
не нужно постоянно проверять нажата ли кнопка или не покинул ли объект экран
Я не знаю, получилось это случайно, или при написании статьи в качестве опорного референса излишне использовались официальные туториалы по Godot Engine, но эта формулировка звучит очень похоже на заголовок из главы про сигналы.
UI-элементы
В первом все возможности заточены больше для меню и настроек
И это более правильный подход, потому что организовать интерактивный GUI гораздо сложнее, чем обычный счетчик патронов или hp-bar.
внутриигровые метрики, вроде шкалы здоровья, создаются со скрипом и сложностями
Я, хоть и не использую юнити в качестве основного инструмента, но ни разу за время моего пользования им (вернее, "новой" UI-системой, которая используется по умолчанию с 20..18(?) года) я не испытывал какой-то особой боли. Даже сейчас в пустом проекте я создал и настроил несколько счетчиков и полосок (хотя, с прогресс-баром возникли сложности, да, поэтому я его сделал из слайдера). Возможно, что проблемы начинаются при попытках переиспользовать настроенные GUI-префабы, но, если я правильно понял, то Godot не преподносит в этом плане ничего нового.
А в Godot – характеристики игрока внутри игры.
Что намекает на то, что интерактивные, сложные, многослойные интерфейсы на нем проектировать не стоит.
C# или GDscript
Некоторые штуки, описанные в документации, делаются в одну строку в GDScript и в пять строк на C#
Подозреваю, что остальные 4 строчки в C# состоят исключительно из { и }.
у C# больше возможностей, и с GDScript будет просто невозможно сделать какие-то вещи
Если я правильно понимаю, то GDscript полон по Тьюрингу, что означает, то, что, технически, на нем можно сделать абсолютно все. На практике же, ограничения появляются в недоступности некоторых API, чего, по идее, быть не должно, если движок действительно проектировался под GDscript и этот ЯП до сих пор поддерживается.
мы стали даже 2D рисовать как 3D. Возможно, что за счет упрощения математики в шейдере из-за отказа от 3-го измерения в Godot'е, будет некоторое увеличение скорости, но оно будет несоизмеримо мало по сравнению с грамотной работой с ассетами, хотя бы, в том же юнити.
Попрошу отметить, что API того же openGL не заставляет использовать третье измерение.
В простейшем случае, если 2д графика не подразумевает вращение и масштабирование спрайтов, для рисования спрайта для каждой вершины достаточно передать 2д вектор позиции и 2д вектор текстурной координаты. В качестве юниформ - позицию камеры в виде 2д вектора. Для вычисления позиции на экране будет достаточно из позиции вершины вычесть позицию камеры. А в 3д придётся передавать и 3д позицию, и умножать на 4х4 матрицу камеры - больше данных и вычислений с ними.
Кроме того, можно сделать спецефические оптимизации типа укладывания спрайтов в одну текстуру и передачу позиций спрайтов или текстурных координат с помощью инстансирования.
Кроме того, можно будет отключить буфер глубины и использование z-координаты в принципе, отключить отсечение обратно повернутых полигонов, не использовать мип-мап уровни текстур и выбрать режим GL_NEAREST.
Можно сказать, что видеокарты быстрые, и все эти ухищрения не дадут заметного эффекта. И что всё то же самое можно реализовать на Unity.
Но наблюдение за некоторыми мобильными поделками, тормозящими на сотне-тысяче спрайтов, наводит на мысль, что разработчики не особо заморачивались и специально настроенный "2д режим" им бы не помешал.
Попрошу отметить, что API того же openGL не заставляет использовать третье измерение
Да, именно так. Когда я писал "мы стали даже 2D рисовать как 3D", я имел ввиду, что после перехода на гибкий конвейер, видеокарте стало абсолютно безразлично что считать, и что весь смысл, который есть в данных - вкладываем в него мы (ну, ещё есть выходной буфер, который имеет уже одно конкретное заранее назначенное разработчиками OpenGL'я предназначение, но суть не об этом).
2д графика не подразумевает вращение и масштабирование спрайтов
Увы, но почти всегда это не наш случай. Хотя бы масштабирование, но матрица (или не матрица, но с матрицами, возможно, будет быстрее) преобразований должна быть почти всегда, так что её нигде кроме, допустим, того же SRP (как Scriptable Rendering Pipeline в Unity) не найти в готовых движках.
Я выше написал "с матрицами будет быстрее", предполагая, что для матриц есть аппаратное ускорение, и что оно выполнится так же быстро (условно - за один такт), как и просто перемножение/сложение векторов. Но данных будет однозначно больше (впрочем, можно и на процессоре большую часть матриц перемножить). Однако, надо профилировать, в разных вариантах, и на разных видеокартах.
можно будет отключить буфер глубины и использование z-координаты в принципе
И как же тогда определять порядок отрисовки? Допустим, z-координата (или слой, или как угодно это можно называть) будет лишь на стороне процессора. И мы будем регулировать порядок отрисовки порядком вызовов отрисовки (т.е. метод художника). Хорошо, это будет работать, но не факт, что это будет быстрее, потому что таким образом мы ломаем параллелизм видеокарты и большинство ядер (особенно при отрисовке маленьких спрайтов, или при огромном количестве ядер) будет простаивать, ожидая отрисовки этого маленького спрайта (чтобы случайно его не закрасить). А ещё, отказавшись от Z-буфера мы выиграем целых 8мб видеопамяти.
не использовать мип-мап
выбрать режим GL_NEAREST
Во многом это зависит от визуального стиля (пиксель-арту точно пойдет на пользу), но обычно при очень маленьком масштабе рисуемый объект становится раздражающе не-сглаженным, что, зачастую, не самый желанный эффект.
наблюдение за некоторыми мобильными поделками, тормозящими на сотне-тысяче спрайтов
Я почти уверен, что там проблема в (случайно) убитом батчинге и инстансинге. Но без конкретных примеров (а ещё лучше с возможностью модифицировать их исходники и произвести оптимизацию) говорить об этом бессмысленно. Сделать плохо можно на любом движке, и с любым рендером.
P.S. Я не осуждаю, но мне и правда интересно: это Вы поставили мне минус в карму, и если да, то, неужели, за мой комментарий?
Нет, минус не мой.
Я привёл максимально упрощённый пример 2д графики, который мог бы быть в каком-нибудь Марио и в котором текстуры рисуются на экран пиксель-в-пиксель.
В более сложных случаях рендеринг действительно становится похожим на 3д и использует его подходы.
Наверно, моё мнение чем-то похоже на рассуждения типа "а вот ассемблер лучше, чем си": я изначально освоил именно OpenGL и после этого некоторые подходы в Unity кажутся слишком высокоуровневыми и избыточными.
Близко к сердцу не принимаю) И спасибо за такой огромный и подробный ответ на статью
Фактологических ошибок в статье немного, но я значительно не согласен с идеей статьи
В принципе, мне кажется, что вот именно в этом и наши разногласия. Мне Unity не особо нравился, я попробовала Godot, который, по первому впечатлению, зашел мне куда больше, и в этом был посыл статьи. Если подумать, можно написать обратную статью, используя практически те же факты (пример с UI-элементами). Да и с возможностями Unity я не на 100% знакома (а с Godot пока тем более), так что вся статья - это просто вопрос восприятия.
Радует, что автор ищет для себя что-то новое, но статья получилась категоричной.
Есть много игр, сделанных на Unity, где UI выглядит шикарно со множеством сложных анимаций и визуальных эффектов. Потратить больше времени на изучении вопроса, тогда бы не было сложности при работе с позиционированием элементов.
Блок про ООП крайне невнятный, причем здесь работа со сценами и принципы программирования?!
"Сигналы" - в C# есть события и делегаты, пользуйся на здоровье :)
В документации Unity есть даже описание того, как вызывать методы на объекте, который пропадает из области видимости камеры (здесь надо учитывать, что при работе в редакторе есть некоторые неочевидные проблемы).
На Unity в целом есть игры, которые выглядят прекрасно, а не только их UI, так что движок, которым пользуется такое количество людей и на котором сделано столько игр, плохим по определению быть не может.
Это не объективное сравнение двух движков (в противном случае мне как минимум бы стоило что-нибудь доделать до конца на Godot), это просто первое впечатление, в котором я подметила какие-то плюсы
А как в Godot с инструментами для монетизации?
Спасибо за чтиво. У меня, наоборот, совсем противоположная история: нашел для себя Godot, сделал на нем пару-тройку игр, взвесил все «за», «против» и всё-таки перешел на Unity.
Godot, не смотря на свои особенности, ещё сыроват (подождем до 4.0, там до 5.0, а от туда можно и до 6.0, как шутят некоторые разработчики).
Помимо этого, структура нодов и сцен показалась уж слишком громоздкой: одна сцена может иметь кучу вложенных объектов, из-за этого иерархия становится слишком большой, с системной компонентов в Юнити я такого не чувствую.
Надеюсь, в будущем интерфейс Godot перетерпит изменения и разработчики смогут, как минимум, перемесчасть любую его часть свободно (К слову, на последнем Q&A разработчики сказали, что данная функция не появится в ближайшее время, разве что окно с кодом можно будет вынести на второй монитор).
Для 2D Godot прекрасен, но я решил пересесть на 3D и, само собой, Unity тут оказался полезнее.
Спасибо за комментарий)
Помимо этого, структура нодов и сцен показалась уж слишком громоздкой: одна сцена может иметь кучу вложенных объектов, из-за этого иерархия становится слишком большой, с системной компонентов в Юнити я такого не чувствую.
А у меня противоположная ситуация, структура в Godot нравится куда больше, чем в Unity
разработчики смогут, как минимум, перемесчасть любую его часть свободно
Вот это, кстати, да, недостаток. Под себя перемещать элементы хотелось бы. Привыкнуть можно, но могло бы быть и удобнее
Не хотите вступить в наш Unreal культ?
Unity создавался для 3D игр, а нормальную поддержку 2D в нее добавили относительно недавно
Логично было слышать такое в статьях 2014 года, но в 2021?
но внутриигровые метрики, вроде шкалы здоровья, создаются со скрипом и сложностями.
Тот же компонент Slider, что демонстрировался в настройке громкости звука и показанной документации. Когда не хочется разбирать пример из документации - достаточно поискать другие примеры в интернете. Хорошо или плохо, но туторов на эту тему тонна
начала находиться в пассивном поиске нового движка для следующего проекта.
есть ещё free-open source игровой движок Open 3D Engine https://o3de.org/
была новость про анонс этого игрового движка: https://habr.com/ru/news/t/566482/
Даже, когда я работала с Unity, он мне казался каким-то тяжёлым и неповоротливым. Он долго запускается, игрыСразу видно, что человек с UE никогда не работал (¬‿¬ )
Ходят слухи, что и в Unity можно использовать все прелести объектно-ориентированного программирования, но у меня никогда не получалось, точнее, я об этом даже особо не задумывалась. Просто мне всегда казалось, что движок под это не заточен, и организация сцен здесь такая, что многие штуки, которые должны являться преимуществом и удобством ООП, здесь выглядит как лишние проблемы.Да вроде как раз заточен под ООП. Все этит Монобехи из коробки и т. п. Можно ещё обмазаться Zenject.
Для сигналов есть Action'ы/Event'ы.
Еще, вроде бы, добавление локализации в игру выглядит куда удобнее, чем в Unity, но я с этим пока не до конца разобралась, так что утверждать не буду.С I2 Localization всё удобно и просто в Unity.
Да и в целом Unity создавался для 3D игр, а нормальную поддержку 2D в нее добавили относительно недавно, да и то, по сути, костылемНесколько лет назад. И с тех пор эти инструменты очень сильно прокачались.
С другой стороны, в одном проекте тут можно использовать и оба языка, так что, проблем, вроде, возникнуть не должно.Не самая лучшая практика, особенно, если несколько человек на проекте.
А мене в Годо очень понравилась родная документация. Step-by-step вообще божественно написан. Ребята очень постарались, чтобы максимально опустить порог входа: понятно не только программисту, но и дизайнеру.
Из Unity в Godot. Первое впечатление