Всем привет, последние года три мое основное хобби – создание игр. Не могу сказать, что я добилась чего-то сверхъестественного, но в Steam есть две мои игры (горжусь самим фактом доведенных до конца проектов, но сейчас многое в них уже поменяла бы). И обе эти игры сделаны на движке Unity.
Почему на нем?
Когда не знаешь ничего о создании игр и только начинаешь погружаться в тему, именно он всплывает первым как очевидный вариант для ознакомления. О нем много информации, куча курсов, уроков, в том числе и на русском, даже книги выпускают и переводят. Он бесплатный, в конце концов, а в сети можно найти множество примеров успешных проектов, сделанных на Unity. В общем выбор казался очевидным. И в целом меня все устраивало, хоть и были недостатки. Однако свою третью игру я начала делать на движке Godot. Здесь я расскажу причины, а также поделюсь своими первыми наблюдениями о плюсах и минусах этого перехода.
Даже, когда я работала с Unity, он мне казался каким-то тяжёлым и неповоротливым. Он долго запускается, игры, которые должны весить 0,3-0,5 Гб, на нем весят 1,5-2 Гб. И вроде бы в современных реалиях это не такая большая беда, но мой внутренний перфекционист каждый раз хватался за сердце, когда это осознавал. Да и в целом Unity создавался для 3D игр, а нормальную поддержку 2D в нее добавили относительно недавно, да и то, по сути, костылем, а я в 3D соваться не планирую, так и зачем мне все это? Все больше и больше мне стало казаться, что я пытаюсь вырыть яму, чтобы посадить фиалку, экскаватором. Вроде бы вещь свою функцию выполняет, но мои цели иные.
В общем, когда я закончила свою вторую игру, я начала находиться в пассивном поиске нового движка для следующего проекта. Пассивным, потому что я ничего специально не искала, но, если на глаза случайно попадалось что-то интересное, я искала более подробную информацию в интернете и брала на заметку. Так я и наткнулась на Godot, и он меня привлек.
Если честно, переходить на другой движок мне было лень, да, банально просто лень. Это на Unity я уже что-то умею, а какие-то несложные вещи делаю с закрытыми глазами. А тут снова все заново, и интерфейс другой, и организация проекта другая, да и, может, вообще язык новый изучать придется. Но все же я решила попробовать скачать Godot и почитать документацию.
ООП как по учебнику
Ходят слухи, что и в Unity можно использовать все прелести объектно-ориентированного программирования, но у меня никогда не получалось, точнее, я об этом даже особо не задумывалась. Просто мне всегда казалось, что движок под это не заточен, и организация сцен здесь такая, что многие штуки, которые должны являться преимуществом и удобством ООП, здесь выглядит как лишние проблемы.
В Godot все иначе. У меня создалось впечатление, что весь движок создавали вокруг идей ООП. Здесь даже, если не хочешь или не умеешь пользоваться его принципами, все равно будешь. Да, после Unity пришлось привыкать к новой организации пространства, но оно того стоит. Я не буду долго рассказывать, как там все устроено, все равно не смогу сделать это лучше и грамотнее, чем в документации, но прочтите про сцены, узлы, экземпляры. Это первое, что меня привлекло, удивило и обрадовало.
Сигналы
Мне очень понравилось, как работают сигналы в Godot. Я не знаю, как там все это устроено «под капотом», и что на самом деле происходит, когда посылается сигнал, но мне, с точки зрения пользователя, кажется очень логичным, что не нужно постоянно проверять нажата ли кнопка или не покинул ли объект экран. Здесь именно кнопка в момент нажатия или объект, который покидает экран, посылают сигналы о том, что произошло. Удобно и логично.
UI-элементы
У меня складывается впечатление, что в Unity и Godot разные понимания о том, что такое пользовательский интерфейс. В первом все возможности заточены больше для меню и настроек, все эти кнопки, ползунки, панели выглядят так, будто разработчики Unity планировали, что с их помощью будут создавать меню выбора языка или сложности и настройки громкости звуков. Нет, они, конечно, тоже нужны и важны, но внутриигровые метрики, вроде шкалы здоровья, создаются со скрипом и сложностями. Может, и есть дополнительные библиотеки для этого, но я не искала, мне и так Unity, как я писала выше, всегда казался тяжеловатым, а еще и библиотеки дополнительные.
А в Godot будто бы больше заботились именно о внутриигровом интерфейсе. Ту же шкалу здесь сделать гораздо проще.
Кстати, мою версию с различным подходом поддерживают документации этих двух движков. В Unity в главе про пользовательский интерфейс приводится в качестве примера именно создание меню.
А в Godot – характеристики игрока внутри игры.
Еще, вроде бы, добавление локализации в игру выглядит куда удобнее, чем в Unity, но я с этим пока не до конца разобралась, так что утверждать не буду.
Работа с изображениями
А вот здесь я столкнулась с трудностями и вопросами. В Unity все интуитивно понятно: загружаешь лист спрайтов и «режешь» его как душе угодно, исходя из своих целей и потребностей.
А в Godot все чуть сложнее. Во-первых, мне пришлось кучу времени потратить, чтобы вообще найти, как вырезать кусок из листа спрайтов. В официальной документации я этого не нашла, найти в интернете по-человечески тоже не получалось. У меня уже даже стали закрадываться подозрения, что это сделать невозможно, и все изображения придется резать заранее и загружать по одному, но это же бред какой-то!
В итоге все-таки нашла, как это сделать, но только посмотрите, как неудобно.
Вы добавляете новый узел Sprite
Загружаете в него лист с изображениями
Внизу экрана каким-то чудесным способом замечаете вкладку «Область текстуры».
Выделяете необходимый фрагмент
И… Ничего не меняется на экране
Просто потому что в инспекторе вы не открыли вкладку Region и не поставили галочку напротив Enabled.
Как-то много неочевидных движений для одного такого простого действия.
Но, помимо этого, здесь не очень удобная анимация. Дело в том, что для подготовки кадров анимации лист со спрайтами в обязательном порядке делится на равные части по горизонтали и вертикали. И если у вас на листе только кадры для анимации, то в целом ничего страшного, даже, возможно, так удобнее, но вот, если это сборный лист со множеством всего, то это тоже придется учитывать и подгонять заранее.
Расположение элементов в пространстве
В основном я, конечно, о UI – элементах. В Unity с правильной настройкой Canvas в первые раза тоже пришлось немного повозиться, но, в целом, все оказалось все-таки проще, чем в Godot.
Я вроде уже что-то здесь сделала, но на автомате все равно пока не получается разбираться со всеми этими якорями и отступами. Слишком запутано выглядит, хотя, признаю, что смысл в этом есть.
C# или GDscript
Одной из причин выбора движка Godot была поддержка в нем языка C#, с которым я знакома. Но в процессе чтения документации и первых попыток чего-то сделать своими руками, стали закрадываться сомнения.
Во-первых, поддержку C# добавили позже, а значит многие элементы созданы и заточены под GDScript, и это заметно. Некоторые штуки, описанные в документации, делаются в одну строку в GDScript и в пять строк на C#. Разница есть, и она очевидна.
Во-вторых, движок позволяет писать на GDSript прямо внутри программы без установки дополнительных надстроек, это удобно.
Не без противоположного мнения, конечно, - в интернете ни раз встречала мысли, что у C# больше возможностей, и с GDScript будет просто невозможно сделать какие-то вещи. С другой стороны, в одном проекте тут можно использовать и оба языка, так что, проблем, вроде, возникнуть не должно.
До сих пор не уверена в правильности решения, но пока я выбрала все-таки GDScript, освоить его несложно. Самое тяжелое – отвыкнуть ставить точки с запятыми в конце каждой строки, до сих пор на автомате ставлю.
Вот такой мой опыт перехода из Unity в Godot, это первые различия, плюсы и минусы, которые мне бросились в глаза, но, уверена, что не последние. Думаю, к тому моменту, как закончу свою первую игру на этом движке, появится еще что-то, так что второй, более полной части, скорее всего, быть.
Автор:
BasicSloth
