godot-proposals VS godex

Mm.

I like godot, but c# is second class citizen in that ecosystem, which they are open about (1) and despite improving (2), it still a bit rough.

“Fully supports”? I’d say more like “works mostly”.

/shrug

Gdscript is a weird stupid custom language. I feel like in most cases you shouldn’t write a new programming language for your application unless there’s no viable alternative.

I know, unreal did it with blueprint, but that’s because there are no good open visual scripting languages; and they had a lot of existing infrastructure from their previous (also stupid, for the same reasons) unreal script.

What they’re doing with verse is arguably also stupid, but I’ll give them the benefit of the doubt on the basis of a) having done it before, b) having unusual requirements for their metaverse ambitions.

Anyway. Godot did have any good excuse; gdscript was not something people asked for or wanted; it was a lazy version of python because actually embedding python was too hard.

One thing you can look back at in Unitys history that is in their aborted attempt to have js, c# and boo as scripting targets.

…but over time, it became clear that having feature parity in all of them wasn’t plausible.

I guess we’ll see where godot ends up, but my $0.02 is that as the api surface increases, feature parity is difficult to maintain, and gd supoort for other languages will wane with community interest.

The only language they are committed to is gdscript.

[1] - https://docs.godotengine.org/en/stable/tutorials/scripting/c...

[2] - https://github.com/godotengine/godot-proposals/discussions/4...

Godot was fine, for the most part, it's a good engine for small games. The main issue was around working together and resolving conflicts with git (Godot isn't really working and constantly kept changing IDs in resource files), and it kept losing data in scenes when the code changed so we had to rebuild things several times. On previous test games we also ran into huge performance issues in the editor when we wanted to do too much work in scenes, so we had to switch to doing most of the work in code.

The worst part was when I had to rip out a bunch of testing code that used @tool for release as it seemed to cause issues when doing a release build. The engine is generally not great when you want to follow clean software engineering (e.g. dependency injection is not possible, I opened a proposal to that end here[1]).

[1]: https://github.com/godotengine/godot-proposals/issues/8850

If we had a Mask2D, this would be super easy and straight forward.

So if that's what OP meant, clip_children property won't work. Instead OP needs to use a CanvasGroup parent and the Line2D (with CanvasItem Material in Subtract mode) and TextureRect as siblings, or any of the other methods explained here until we have a Mask2D node.

There is an open proposal to have a compile option for a LibGodot, as a Library https://github.com/godotengine/godot-proposals/issues/6267

Yes, there could be the option to open at least 2 tabs at the same time, when working with scripts. This has probably already been suggested in: https://github.com/godotengine/godot-proposals

I cannot tell exactly where the jitter is from the video, but if it is what I'm thinking of, it is a known issue, see here. There is a proposal to fix this, with tons of discussion here. Try some of the workarounds mentioned in these two links. Game looks great by the way!

It's in the release notes. Here is a link to the pull request, based on this proposal.

Currently not possible: https://github.com/godotengine/godot-proposals/issues/7213

I wonder if Godex[0] could be a fit for you. ECS based Godot, based on 3.x which has much more broad WebGL support.

[0] https://github.com/GodotECS/godex

There is usually a few steps how to deal with performance issues before reaching the conclusion "I need ECS", but if you need it then try https://github.com/GodotECS/godex

You might want to check out Godex. It is a Godot extension that introduces an entity/component system. It is not mature yet, but it is under development and seems promising. https://github.com/GodotECS/godex

However, the great thing about godot, is if you want a feature, like ECS, for example just add it yourself.

You can try the fork called Godex, it has ECS built into it and is a lot of fun to use in my opinion.

There is an ECS port for Godot named Godex, but it isn't hugely mature:

https://github.com/GodotECS/godex

I haven't used it, though I've been curious about it. As far as better options for ECS game engines go, I'd go with Bevy (personally), but you'll have to learn Rust (which I'm a proponent of anyway).

https://bevyengine.org/learn/book/introduction/

But both of these are still in "Beta", if that's even the proper term for their development cycle, at this point. They work, technically, but they could use some help, to my understanding.