Godot 3.3

I mean, it's MIT licensed. So no, not really. It's designed to make games, and the commercials are left to you.

My advice: don't bother waiting for Godot 4 just because it sounds nice. You'd be surprised at how many of the "limitations" of the 3.x branches are not actually problems at all for most use cases (granted, your company may have a very niche use case...)

I mean, yes and no? In that the 3D renderer is a completely separate system to the 2D renderer. But, that means that the 3D renderer... was designed from the ground up to do 3D. Unlike the other direction with Unity, where 2D support is a hack of the 3D engine.

I've been using Godot 3's 3D features for quite a while now, and obviously as a single indie developer I'm not using it for AAA features, but it's still as competent as any other renderer I've used for my use cases.

> Last I checked the editor has no advanced 3D scene editing features, and the engine itself has no basic capabilities that are needed for large open world 3D games, like being able to load tons of stuff on the fly as the player moves in a way the player doesn't notice.

You're going to have to be more specific about "advanced 3D scene editing features", as the editor is actually very good, besides which, I compose most of my 3D scenes in code. Meanwhile, Godot supports everything needed to stream assets at runtime, from multi-threading support, to async resource loaders, LOD, and so on. Granted, you have to kind of roll your own.

The main issue people bring up for large, open world 3D games (which may be a dream of most developers who've not really made a game yet, but in any engine quickly becomes a "one day" project and not something feasible for most people) is the 3D renderer itself, which doesn't have occlusion culling, but again in most realistic cases you wouldn't ever notice this (and it has been added as a feature to Godot 4 already).

For example, recently I was messing around with voxels, and recompiled the engine with a C++ module called "Voxel Tools"[^1]. This supports level streaming and movement throughout large levels without floating point errors (ie, you have a VoxelViewer node that gives the illusion of moving through a large space, while actually not moving further from the origin than you can see).

https://github.com/Zylann/godot_voxel

You're going to have to know that stuff for any game engine that isn't just a pure C# framework. Unity is no exception afaik, you have to use the Unity API Job system to be able to run threads safely. I use async/await in Godot C# all the time. Threading requires using the Godot API, sure, that's natural, since threading can be a mess in video games.

The key aspect seems to be that there's a commercial entity behind the project who presumably has console development licenses.

AFAICT none of the console specific source is Open Source but the implication seems to be that the source is (freely?) made available to registered console developers due to the fact the developer of both is a licensed console developer and has decided to make it available to others.

Console development/distribution is mentioned in a couple of places in the documentation[0]:

"The hello.hl file contains bytecode that can be run with the HashLink virtual machine using hl hello.hl. It does give quite good performances and have been proven by successful commercial games such as Northgard or Dead Cells.

However, it is also possible to compile the HashLink code using a native compiler. This allows to compile for consoles and mobile.

This will create a directory out containing a lot of generated C code that needs to be built using a native compiler and linked to the same HashLink runtime[...]"

With regard to console support it says:

"... for Consoles (Nintendo Switch, Sony PS4, Microsoft XBoxOne), please contact us at nicolas @ haxe.org if you are a registered developer for one or several of these"

And here[1]:

"The final resulting shader will then be compiled to the target platform native shader language (HXSL currently supports GLSL for OpenGL, HLSL for DirectX 11+, AGAL for AdobeAir, and PSSL for Sony PS4)."

Also, this post[2] describes how the lower level parts (using Haxe/hashlink) integrate with native (i.e. console) platforms:

"The game gets compiled to a cross-platform .hl file that can be run with HashLinkVM JIT. It can also be compiled to C directly and compiled using any native compiler, which we are using for our console ports on PlayStation, Xbox and Nintendo Switch."

"We also have additional platform API libraries for Steam, as well as console integration libraries that are only accessible if you have a registered developer."

In the same post the Heaps.io console implementation is described:

"This architecture allows us to integrate new renderers or platforms by just porting a few classes given that the native libraries are been made available in HashLink. Heaps.io supports the following plaforms/renderer:

[...]

HashLink/C with NVN (Nintendo Switch SDK native graphics API)

HashLink/C with GNM (PS4 SDK native graphics API)

HashLink/C for Xbox One SDK"

[0] https://heaps.io/documentation/hello-hashlink.html

[1] https://heaps.io/documentation/hxsl.html

[2] https://haxe.org/blog/shirogames-stack/