Godot 4.3 с поддержкой Wayland

Добавлен эффект Parallax2D.

Что? Параллакс там уже сто лет как есть.

Угу. Там просто плюшек добавили.

While you were able to add a parallax effect to your games already, the previous implementation of Parallax2D came with limitations. For instance, overlaying effects as seen in the video here was impossible before.

https://godotengine.org/article/parallax-progress-report/

Круто.

Как-то упустил - на нём теперь можно выбирать видяху на которой запускать?

В смысле? Там выбираешь API. Повыше с большими возможностями для карт по мощнее и пониже для всего остального. От уровня API зависят фичи. Но это лучше у GREAT-DNG спросить

Разбудите, короч, когда починят взаимодействие CharacterBody2D и RigidBody2D, а то оно даже касания между ними не фиксирует. Возможные решения одно круче другого:

• Перейти с CharacterBody на RigidBody - сразу меняется вообще вся физика управления, нельзя контролировать взаимодействие с гравитацией, ибо оно принудительно просчитывает силы, меньше функционала например нет коллизий с полом, стенами, реализуй всё с нуля на рейкастах, минус весь функционал, что был заточен именно прд игроковскую сущность
• Или решать через слои и маски коллизий. Тогда оно работает, но characterbody может «пнуть» любой объект в стену и пропихнуть сквозь любое препятствие

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

Дополнительно из минусов - это попытка максимально привязать к GDScript и к внутреннему IDE, который лишь немного обгоняет блокнот из винды.

• Заявленная поддержка С# заканчивается тогда, когда вы хотите найти функцию в документации. Вам дают хренову тучу инструкций о том, по каким правилам и с какими исключениями надо переименовать оригинальные имена функций, чтобы получились имена из С# (типа isonfloor -> IsOnFloor), правда части аргументов кое где нет, части функций нет, а то что делается через встроенный модуль в ГД требует подключения доплиб прд #, например работа со временем.

• Любая помощь на форумах и дискорде в 99% только для их примитивного GDScript. Часто даже бывает, что вам скажут решение проблемы, вот только такого функционала для С# не будет, в большинстве случаев вопросы по С# вообще игнорируются и на вас могут агрессивно наехать типа зачем вы вообще используете такой сложный язык, есть же GDScript (в котором нет даже 1% функционала С#)

• Никакого встроенного функционала фильтрации С# библиотек при релизе. Типа ну вот компилятор и редактор знают, какие модули вы подключили (например только Сore), но экспортировать будут принудительно вообще все либы, начиная с LINQ и кончая FTP. Из коробки не настраивается, нужно компилить из командной строки, руками убирая модули, которые не нужны. По умолчанию пустой билд будет 300 метров.

• Если пытаться писать на С# в их редакторе - то будет недоступен функционал интеграции с их же связкой с GUI. Например при перетаскивании узла дерева объектов в панель кода оно вставит GDScript код доступа к объекту полностью проигнорировав что дело идет в файле cs, созданным через их же гуй с пометкой что это проект С#. Прдобная лажа при попытке добавить местный аналог кутешных сигнал-слотов для С#: оно сгенерирует функции, да. Но поместит их в корень файла, а не в класс. Скомпилить так нельзя, а при попытке переместить определения в класс вы получите рабочий код, но редактор теперь всегда будет генерировать ворнинг о том, что такая функция в файле не найдена.

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

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

• Вместо решения багов или сбора фидбека - бесконечные инклюзии и DEI. Пока я не отрубил уведомления - каждую неделю кто-то делал @everyone с призывом присоединяться к очередному эвенту чтобы «добавить себе в резюме инклюзивные игры». Да шоб вы так баги чинили, а не слали в пешее эротическое с формулировкой «если чото не нравится - вали в свою юнити, там работай со светом и пмши на С#»

Из плюсов:

• Ну оно как-то, но работает

«Тело, которое перекрывает источник начнет светиться само»

Такое сильное излучение??..

Верно, как я понимаю, просто выбирается абстрактный API над Vulkan/Direct3D/Metal/OpenGL. В зависимости от необходимых наворотов берётся более лёгкий (в ветке 4.x Computability, в 3.x GLES2), более тяжёлый (Forward+ и GLES3 соответственно) или мобильный (Forward Mobile).

Подробнее в документации.

Уточнил.

Но зачем это нужно?

Это попытка создать бесплатный unity

Не уверен что они прям с Unity конкурируют, Godot наверное попроще но и легковесней.

Они вообще непонятно с кем конкурируют. Движок собирает в себе вообще все bad practice, которые возможно. Например всё устроено так, что вы вынуждены писать всю бизнес-логику в обработчике update кадра (60 раз в секунду). Любая попытка рассчитывать что-то в отдельном потоке приведет к тому, что вы сломаете движок или внутренний стейт, ибо все прибито гвоздями к потоку, в котором вызывается update.

В том же потоке работает физический просчет тел. В настройках есть галка «считать физику в другом потоке», но она приводит к абсолютно спорадическим импульсам и запрету взаимодействия с физическими телами из потока с update.

Список внушает уважение. Сразу видно человека, работавшего с сабжем достаточно плотно.

Пробовал что-нибудь из перечисленного багрепортить?

Главное новшество Godot 4.3 – это начальная поддержка Wayland.

Можно начинать закапывать.

Оно всё зарепорчено. Баги висят годами, их никто не правит.

Например:

• https://github.com/godotengine/godot/issues/70671 - одно из многочисленных обсуждений коллизии (я там тоже есть), 2 года, никто не чешется.

По свету тоже были ишуи.

Там 10к+ открытых ишуёв.

Вот поэтому я разлюбил комбайны, особенно привязанные к слабым языкам. Тот же Defold, например, там Lua — дальше стандартного API не разгонишься. Для индюшатины большая часть фич всё равно не нужна.

Типичный опенсорс проект в наши дни

Дык а кто фиксить-то будет, если все только багрепортят?

Unreal engine. Зачем тебе этот анскильный godot?

обидно что не достойный проект распиарен и заспонсирован

В соло пилить что-то на анреале - это лютейший оверкилл. Он заточен под огромные команды, где нужно иметь специалистов по каждому шагу воркфлоу, начиная от раскидывателя графов, кодера, сцен-дизайнера и проч. Это для корпов.

Я думал юнити поковырять, но их вот эта херня с «с завтрашнего дня вы должны нам миллион денег» отвадила.

Настолько недостойный, что на нише составляет конкуренцию Unity и Unreal Engine

На словах - да. По факту уровень LÖVE.

Не, народ, я имел в виду другое. Раньше (до и после перехода на вулкан) при запуске на дискретке в лаптопах с оптимусом Годот и его игры вешали систему наглухо в произвольный момент. Было обсуждение и планы сделать всё по умному. Потом потерял из виду всё и не знаю, уже сделали? Или всё ещё вешается? Но да ладно.

C# должен умереть, любители C# должны страдать

Годот и его игры вешали систему наглухо в произвольный момент.

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

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

Разрабам башляют по 50к$ ежемесячно https://fund.godotengine.org/ вот пусть и правят

Как пафосно. Но мы же в реальной жизни живём? Имеем что имеем.

Или ты намекал на Haiku? И сколько игровых движков и аппаратных ускорений на ней уже работает?

Godot - это сильный кандидат на звание «Overhype-2024». Раз тут его сравнивают с Unity и UE, то какие на нем коммерческие проекты выходили, кроме провального порта Sonic Colors?

А какой движок есть более-менее простой для самообучения? С более-менее современным рендером и своим редактором.

Попробуйте лёву например. Достаточно примитивен, но функционален.

Если хочется обучиться более низкоуровнево, то можно попробовать pico8

Коммерческих вроде не было, были индюшки, 5 из которых даже что-то заработали.

Defold. Он не такой фичастый как Godot, но суть та же. На нём любят пилить 2D для мобилок.

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

Из низкоуровневого — ebitenengine. Там как раз хороший рендер, но все базовые штуки вроде коллизий придётся писать самому или подключать библиотеки от сообщества.

По факту уровень LÖVE.

Фига ты захейтил прям годот :)

Godot всё-таки движок, со сценами там всякими, конечными автоматами и т.п., а LOVE это просто обёртка над SDL/Box2D для Lua.

Фига ты захейтил прям годот :)

Ну смотрите, логика у меня простая:

Вот делаем, мы, например, клон super mario. Примитивная графика, прямоугольные хитбоксы, физику пишем руками.

Результат:

• LOVE: всё работает
• Godot: всё работает

И тут мы собираемся добавить что-то сверху. Освещение, партиклы, шейдеры, физику.

• LOVE: делай руками или вообще нельзя
• Godot: фиг ты что добавишь, потому что забагован абсолютно каждый компонент.

Например, в godot есть возможность добавить спрайту анимированную секвенцию. Т.е. например анимация ходьбы или приседания. Вот только нет АБСОЛЮТНО НИКАКОЙ возможности синхронизировать анимацию с хитбоксом. Вы присели? Да. Ваш хитбокс изменился? Нет. И так во всём. Световые эффекты, состоящие всего из двух вариантов - точечного (про него я написал выше) и освещение сверху. При попытке включить тени от последнего вы получите бесконечную тень, падающую под углом. Т.е. например летите вы в небе, а от вас вниз падает бесконечное затемнение. Без рассеивания. Потому что рассеивание в godot - это нарисовать не 1 а N прямоугольников тени со смещением в несколько пикселей. Из-за чего тень рисуется за пределами бокса.

Расплывчато за тень пояснил, вот скриншот: https://i.postimg.cc/SsTj9rTm/image.png

В итоге получаем следующее - godot шире лёвы по функционалу, но при попытке использовать этот более широкий функционал вы столкнетесь с тем, что

• или он не работает
• или он забагован
• или вам нужно реализовать его руками

Тот же Parallax2D, который они снова поменяли на предыдущих релизах работал так - вы помещаете на сцену слои, задаете им скорость смещения относительно камеры. Запускаете. Оно работает, да. Но начальная точка фона никак не совпадала с тем, как вы поместили её на сцену. Это как-то зависело от включенного рендерера, скейлинга, начальной позиции камеры, еще каких-то параметров. Из-за чего рисуешь фоны для параллакса, помещаешь на сцену, на сцене круто, включаешь игру - и у тебя сразу сзади фон кончился и больше не проматывается. А включить бесконечную прокрутку там нельзя, только N раз.

Например, в godot есть возможность добавить спрайту анимированную секвенцию. Т.е. например анимация ходьбы или приседания. Вот только нет АБСОЛЮТНО НИКАКОЙ возможности синхронизировать анимацию с хитбоксом. Вы присели? Да. Ваш хитбокс изменился? Нет.

Чем не устраивает вариант с добавлением спрайта в AnimationPlayer? https://litter.catbox.moe/p2lzod.mp4

То что нет никакой автоматизации. Вам нужно для каждого кадра руками указывать шейп, особенно классно, когда шейп не rect, а polygon. Нет никакого инструмента синхронизации «из коробки». Если вы тут пальцем накосячите - получите или невидимый хитбокс в игре или «прострел» сквозь спрайт. Движок, блин, знает где прозрачные пиксели, почему он не может сам на их основе сгенерировать полигон?

Вот вам пример спрайтшита: https://www.spriters-resource.com/resources/sheets/17/18601.png?updated=1460954785 сколько у вас часов займет руками менять шейпы под каждый кадр?

Ты как-то ворота передвинул с невозможности синхронизировать хитбокс и фреймы спрайта (что оказалось неправдой) на невозможность генерации хитбокса на основе битмапа. Вообще это сама по себе задача не тривиальная, ведь в разных кейсах могут быть разные требования например к сложности полигона. Или например у меня у персонажа есть пышные волосы, и я не хочу чтобы они были частью хитбокса. Гуглеж говорит что есть функция opaque_to_polygons, возможно она решит твою проблему :) Вообще во многих играх с pixel-perfect коллизиями не заморачиваются для маленьких объектов.

Ну и напоследок, ничего этого нет в Love2D. Окей я провожусь полдня расставляя хитбоксы для моего зайчика, ты будешь две недели писать просто систему правления анимацией на lua с нуля для Love2D. Это вообще не сопоставимые вещи.

с невозможности синхронизировать хитбокс и фреймы спрайта

Я исходно имел в виду, что нет именно синхронизации, а не ручного расставления точек хитбокса.

От Unity одни проблемы.

Ну значит багрепорты тех, кто башляет, таки закрывают

Т.е. например анимация ходьбы или приседания. Вот только нет АБСОЛЮТНО НИКАКОЙ возможности синхронизировать анимацию с хитбоксом.

рисуешь фоны для параллакса, помещаешь на сцену, на сцене круто, включаешь игру - и у тебя сразу сзади фон кончился и больше не проматывается. А включить бесконечную прокрутку там нельзя, только N раз.

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

C# то, C# сё

Основной язык движка GDScript. С шарпом есть подводные камни, как есть и свои плюшки, эта тема обсуждалась сотни раз, все плюсы и минусы можно проанализировать заранее. Использовать шарп в годо только с четким пониманием что и зачем ты делаешь.

Абсолютный хаос на форумах и дискордах

Сам ответил, все эти сообщества ведутся рандомными сторонними людьми. Плюс основная масса геймдев комьюнити это «Здравствуйте. Я Кирилл. Хочу сделать игру, 3Д-экшон, суть такова…» независимо от движка. Кстати, именно форум годо вполне неплох в плане поиска ответов на типичные вопросы. Также читать документацию, гитхаб. Дискорд лучше забыть как страшный сон, чатики в принципе худшая форма для обмена знаниями.

фиг ты что добавишь, потому что забагован абсолютно каждый компонент

Ну дичь же ну, не позорься. Да, баги есть, много, особенно в четверке. Но ничего катастрофичного, рутина игростроя на любом движке. Если смотреть на функционал, то даже со всеми своими проблемами годо очень сильно опережает конкурентов на онтопике. Достаточно чутка поковырять LOVE или Defold, чтобы офигеть сколько фич там нужно реализовывать самому или плагинами от Васянов по сравнению с сабжем. Круче только проприетарщина типа юнити, где поддержка линукса чисто формальная, заниматься полноценной разработкой на онтопике не выйдет.

Короче, мое личное мнение, Godot - вполне достойный проект. Да, есть куча объективных проблем, но это лучший на данный момент игровой движок где линуксоид может чувствовать себя first class citizen. Текущего его функционала и стабильности уже хватает на проекты уровня мелких студий, надеюсь в будущем ситуация будет только улучшаться.

Основной язык движка GDScript. С шарпом есть подводные камни

Разрабы: можете писать на GD или C#
Я: люде неадекватно реагируют если говоришь что пишешь на C#
Worron: Зачем ты пишешь на C#? Пиши на GD!!!

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

Звучит как кто-то неасилятор и не разобрался, а тысячи игр на unity, которые разрабатывались на linux и работают на любой платформе только что схватились за сердце.

Но ничего катастрофичного

Ну так покажите решение например пресловутого взаимодействия двух базовых вещей - CharacterBody и RigidBody.

Или решать через слои и маски коллизий

что в них плохого?

characterbody может «пнуть» любой объект в стену и пропихнуть сквозь любое препятствие

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

что в них плохого?

characterbody может «пнуть» любой объект в стену и пропихнуть сквозь любое препятствие

Кроме этого - ничего.

Ты что-то делаешь не так, показывай проект с демонстрацией.

Конечно, все кругом дураки, один вы молодец. Выше ссылка на ишую, там всё приложено. И там тоже отметились такие же «дураки» как я, у которых физические тела сквозь стены пропихиваются из-за этого.

https://github.com/godotengine/godot/issues/70671#issuecomment-2106066147

Worron: Зачем ты пишешь на C#? Пиши на GD!!!

Не хочешь не пиши конечно. Просто обращаю внимание, что 80% твоего негативного опыта не касаются 90% процентов пользователей годо.

люде неадекватно реагируют если говоришь что пишешь на C#

Ну как бы тут есть «условно адекватная» причина такой реакции. Повторюсь, в комьюнити приходит куча людей без какого-либо релевантного опыта, они могли выбрать язык потому-что название понравилось. Буквально. Взгляни со стороны, вот ты выбрал неродной для движка язык, на неродной для этого языка операционной системе, теперь страдаешь. Убедиться что ты не из таких заблудившихся новичков - естественная реакция, если общение происходит не в специально помеченных С# темах.

а тысячи игр на unity, которые разрабатывались на linux

Давай пруфы, про тысячи unity игр разработанных на линукс. Именно разработанных, а не работающих, как было до стыдливого редактирования сообщения.

Ну так покажите решение например пресловутого взаимодействия двух базовых вещей - CharacterBody и RigidBody

Ну вот, первый же туториал из гугла, с видео и демонстрационным проектом в комплекте, проверил, ничего сквозь стены не пролетает.

проверил, ничего сквозь стены не пролетает.

Дядя, вы слепой? Вы буквально дали видео-демонстрацию с анимацией того, как блок наполовину проходит сквозь стену:

https://kidscancode.org/godot_recipes/4.x/img/char_push_inf.gif

И да, там предлагается:

func _physics_process(delta):
    # after calling move_and_slide()
    for i in get_slide_collision_count():
        var c = get_slide_collision(i)
        if c.get_collider() is RigidBody2D:
            c.get_collider().apply_central_impulse(-c.get_normal() * push_force)

Это НЕ работает, если физический объект коснулся characterbody СВЕРХУ. О чем и обсуждается в контексте ишуёв. Если вам на голову падает блок - get_slide_collision_count возвращает 0.

вот ты выбрал неродной для движка язык

https://godotengine.org/article/platform-state-in-csharp-for-godot-4-2/ заявляется о полной поддержке

Убедиться что ты не из таких заблудившихся новичков

Абсолютный идиотизм (как со стороны разработчиков, так и со стороны пользователей) - это использовать для разработки язык, существующий ТОЛЬКО в рамках этого «движка», не имеющий никакого практического применения и разрабатываемый этими самими разработчиками в соляново. Если хотели сделать хорошо нубам в программировании - могли взять lua, как defold и love. Но нет, надо было изобрести какой-то велосипед с квадратными колесами, на котором можно ездить только по вот этой дорожке. C# и C++ - стандарт для разработки игр. На том же самом GDScript предлагается писать чертову лапшу из обработки стейтом, в том время как для C# я могу написать (и написал) табличную стейт-машину, в которой например coyote добавляется буквально в два микроблока:

    private void _TableCoyote() {
        var partTable = new List<ControlInterpreter.TableRecord> {
            new ControlInterpreter.TableRecord {
                Name            = "Coyote timer set",
                TouchListLost   = new List<string> { "on_floor" },
                FilterStates    = new List<string> { "jumping"  },
                Func            = () => {
                    controller.jumpCoyoteTimer = ControlInterpreter.jumpCoyoteTime;
                }
            },
            
            new ControlInterpreter.TableRecord {
                Name            = "Coyote jump",
                FilterTouchList = new List<string> { "on_floor" },
                InputsNew       = new List<string> { "player_jump" },
                TimersList      = new List<string> { "jumpCoyoteTimer" },
                Func            = () => {
                    controller.jumpCoyoteTimer = 0.0;
                    controller.JumpCommon();
                }
            }
        };
        controlTable.AddRange(partTable);
    }

При этом обрабатываемых параметров 15 штук, начиная от касания поверхностей и заканчивая списком только что завершившихся таймеров. С помощью LINQ существующий внутренний стейт накладывается на таблицу и просто вызывает список лямбд, нужных для обработки логики в этот момент. Никаких макарон, никаких глобальных переменных. Даже сама таблица обработки (в данный момент с 29 записями) разбита на разные файлы, которые объединяются в конструкторе модуля. У GDScript нет абсолютно никакой мощи, как у языка программирования, это средство для производства лапшекода.

Какие то выходили https://godotengine.org/showcase/

Давай пруфы, про тысячи unity игр разработанных на линукс

А что значит «разработанных»? Это только к коду относится?