Godot's only issue is the lack of console support, but that's because they can't get the licenses as an open source project.
The Godot developers created a new business entity that will facilitate porting games to closed platforms.
I was going to say, I know Cassette Beasts released on Switch and it uses the Godot engine, so there's no way it doesn't support consoles.
Also, Sonic Colors on Switch used Godot code in violation of the license, whoops.
They support dual licensing for this very reason.
How does that help if there's no engine support?
It essentially allows for special closed source builds. These closed source builds can have the engine support for consoles and still be in keeping with Sony/Microsoft/Nintendo's licenses.
I didn't know that. How do the developers get access to these builds? Are they sold? Or do they need to build it themselves?
So, basically the console manufacturer gives you the SDK, integration code, etc after you sign their NDAs. After that, you can either use what they gave you to port it yourself to that console, or you can pay someone else for their build.
Hey EU. How about lowering that barrier to entry by pumping a couple of million Euro's into cold-room reverse engineering the API's and developing an open source alternative that can be distributed freely.
We'll invite Sony lawyers, Microsoft lawyers, watch them cope and seethe as their framework is made more open...
...aaaand then realising that a lot more people will take the shot to pay for actual licensing. Go figure.
You're still going to need them to sign your binary for the console to recognize it as legit.
Circumventing the official path worked back in the 80s and 90s, but modern consoles and their SDKs were designed with those lessons in mind.
It's still valuable information for those that would seek to load homebrew (unsigned code) onto their systems.
Console security is one of those things where every additional barrier helps. The goal isn't to outright prevent homebrew or piracy but to limit the scope of breaches and delay them as much as possible. Even modern consoles like the Switch and PS5 are not immune
It would be great if there was a guaranteed way to homebrew your consoles, but yeah security and stability is the real thing we benefit from. I don't think anyone would advocate for more hackers in console multiplayer games, and I don't want a homebrew game I'm running to crash or brick my system because of their fly-by-night hardware usage.
So, I didn't bring up Xbox earlier, because Microsoft has an official way to run homebrew on Xbox consoles.
All modern Xboxes have access to something called developer mode. This allows people to put whatever code they like on it, but removes the ability to play retail games. The change isn't permanent, however, and switching between the modes is perfectly safe.
This is a big part of the reason why Xbox 1 never had piracy; pirates couldn't piggyback on the back of homebrewers, who simply opted to use developer mode instead of cracking the console.
Interesting, I didn't realize this. I assumed a dev kit was always required for that behavior, and that's why Nintendo offering a cheap switch dev kit was such a big deal. TIL
I am not sure this is something other engines even offered at this level, but my issue is bindings support.
3.X had (3rd-party) production-ready bindings, even for niche languages.
4.X, with hopes of improving support for compiled languages, has a new bindings system meaning that all bindings need to be redone as a new effort. This happened with the language that I'm interested in, the group that made the production-ready 3.X bindings abdicated the crown and there have been splintered efforts by individuals to work on 4.X bindings.
So it (3.X vs 4.X) is language vs engine features. When/if 4.X bindings do come out, it is not known how similar they will be so (aside from non-Godot-specific code) that will likely add complication to it as well.
I don't really care about consoles (needing to jump through hoops to develop for it is one reason) so a different potential issue would web export limitations. Both for different languages and for visual quality (AA). Those were issues in the past, though I'm not actually sure where they're at now (the 4.1 docs do say you can't have C# web exports in 4.X).
Godot's only issue is the lack of console support, but that's because they can't get the licenses as an open source project.
The Godot developers created a new business entity that will facilitate porting games to closed platforms.
I was going to say, I know Cassette Beasts released on Switch and it uses the Godot engine, so there's no way it doesn't support consoles.
Also, Sonic Colors on Switch used Godot code in violation of the license, whoops.
They support dual licensing for this very reason.
How does that help if there's no engine support?
It essentially allows for special closed source builds. These closed source builds can have the engine support for consoles and still be in keeping with Sony/Microsoft/Nintendo's licenses.
I didn't know that. How do the developers get access to these builds? Are they sold? Or do they need to build it themselves?
So, basically the console manufacturer gives you the SDK, integration code, etc after you sign their NDAs. After that, you can either use what they gave you to port it yourself to that console, or you can pay someone else for their build.
https://docs.godotengine.org/en/3.2/tutorials/platform/consoles.html
This, right here.
Hey EU. How about lowering that barrier to entry by pumping a couple of million Euro's into cold-room reverse engineering the API's and developing an open source alternative that can be distributed freely.
We'll invite Sony lawyers, Microsoft lawyers, watch them cope and seethe as their framework is made more open...
...aaaand then realising that a lot more people will take the shot to pay for actual licensing. Go figure.
You're still going to need them to sign your binary for the console to recognize it as legit.
Circumventing the official path worked back in the 80s and 90s, but modern consoles and their SDKs were designed with those lessons in mind.
It's still valuable information for those that would seek to load homebrew (unsigned code) onto their systems.
Console security is one of those things where every additional barrier helps. The goal isn't to outright prevent homebrew or piracy but to limit the scope of breaches and delay them as much as possible. Even modern consoles like the Switch and PS5 are not immune
It would be great if there was a guaranteed way to homebrew your consoles, but yeah security and stability is the real thing we benefit from. I don't think anyone would advocate for more hackers in console multiplayer games, and I don't want a homebrew game I'm running to crash or brick my system because of their fly-by-night hardware usage.
So, I didn't bring up Xbox earlier, because Microsoft has an official way to run homebrew on Xbox consoles.
All modern Xboxes have access to something called developer mode. This allows people to put whatever code they like on it, but removes the ability to play retail games. The change isn't permanent, however, and switching between the modes is perfectly safe.
This is a big part of the reason why Xbox 1 never had piracy; pirates couldn't piggyback on the back of homebrewers, who simply opted to use developer mode instead of cracking the console.
Interesting, I didn't realize this. I assumed a dev kit was always required for that behavior, and that's why Nintendo offering a cheap switch dev kit was such a big deal. TIL
I am not sure this is something other engines even offered at this level, but my issue is bindings support.
3.X had (3rd-party) production-ready bindings, even for niche languages.
4.X, with hopes of improving support for compiled languages, has a new bindings system meaning that all bindings need to be redone as a new effort. This happened with the language that I'm interested in, the group that made the production-ready 3.X bindings abdicated the crown and there have been splintered efforts by individuals to work on 4.X bindings.
So it (3.X vs 4.X) is language vs engine features. When/if 4.X bindings do come out, it is not known how similar they will be so (aside from non-Godot-specific code) that will likely add complication to it as well.
I don't really care about consoles (needing to jump through hoops to develop for it is one reason) so a different potential issue would web export limitations. Both for different languages and for visual quality (AA). Those were issues in the past, though I'm not actually sure where they're at now (the 4.1 docs do say you can't have C# web exports in 4.X).