o3de VS godot-proposals

It's odd to me that when the whole Unity fiasco happened, everyone was basically looking at either Godot or Unreal, but pretty much nobody mentioned or cared for something like O3DE.

If you praise Godot for being open source a lot, then it stands to reason that you should similarly prefer O3DE as opposed to Unreal: https://github.com/o3de/o3de/blob/development/LICENSE.txt (no idea why they're going for both Apache 2 and MIT license, though) vs https://www.unrealengine.com/en-US/license

Unless people just care about the options that are popular enough to warrant their attention and the features that they provide, whereas the licensing is actually a boon, rather than the main factor, given that Unreal also did some slight price increases a while later as well: https://www.unreal-university.blog/post/unreal-engine-5-pric...

Either way, it's still nice to have lots of options available regardless of the licensing details (though this kind of does fragment developers among bunches of different projects), be it Godot, O3DE, Stride, Unreal or even something like jMonkeyEngine (one of the rare Java engines/editors with 3D) or NeoAxis (that one had a cool voxel LOD solution, but performance on AMD hardware was bad).

03DE: Open source game engine, under Apache License 2.0, developed by Amazon and the linux foundation. Seems to work under a modular package called "gems", that you can use to pull in the functionality you need. It uses c++ as it's main language, but you can use Lua, python or visual scripting for scripting stuff. Has multiplayer built into the engine and what they call a "robust" system for open-world games. There seems to be a lot of tutorials on the site, but they aren't laid out great.

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