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.
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.
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
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
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).