Obligatory relevant Godot-related links:
* https://docs.godotengine.org/en/4.1/tutorials/platform/conso...
* https://godotengine.org/article/godot-consoles-all-you-need-...
* https://w4games.com/2023/08/06/w4-games-unveils-w4-consoles-...
Couple of Godot-based games available on console:
* https://en.wikipedia.org/wiki/Cassette_Beasts#Development / https://godotengine.org/article/godot-showcase-cassette-beas...
The fact developers have been able to ship Godot games on console doesn’t help much unless those developers are willing to share whatever proprietary engine-to-console-SDK-interface code they wrote.
Unity and Unreal, in contrast, will happily license equivalent code to you.
I think this section of the second Godot link is worth pulling out and quoting:
> … it is impossible for Godot to include first-party console support out of the box. Even if someone would contribute it, we simply could not host this code legally in our Git repository for anyone to use.
> Additionally, it would not be possible to distribute this code under the same license that Godot uses (MIT) because this is in direct conflict with the proprietary licenses and non-disclosure terms that console manufacturers require to have access to the knowledge needed to write this code.
> To make it simple, it is not possible for Godot to support consoles as an open source project.
That was my intention.
> The fact developers have been able to ship Godot games on console doesn’t help much [...]
Well, it demonstrates that it's entirely possible, either via DIY, hiring an in-house specialist or contracting to one of the companies who has already implemented the functionality.
> [...] unless those developers are willing to share whatever proprietary engine-to-console-SDK-interface code they wrote.
The third party porting companies are willing to "share" that code--for a fee. They could also do the same for free as long as they respect the terms of their contract with the console platform (which probably is along the lines of "don't disclose anything to people who don't also have a contact with the console platform").
A group of companies could even cooperate on this but we'd presumably not know the details.
> Unity and Unreal, in contrast, will happily license equivalent code to you.
Sure, but it's also neither free[0] nor Open Source, e.g.:
"Build and deploy to closed platforms such as Nintendo Switch™, PlayStation®, and Xbox®. An active Unity Pro subscription is required to access these build modules via developer platform forums."
The nuance of "it is not possible for Godot to support consoles as an open source project" is that "it is not possible for [the] Godot [Project] to support consoles as an open source project [but the Godot Engine can be used on consoles if you write the support code yourself or license it from someone]".
Despite detailed explanations (from the devs) of the nuances, too many people interpret the situation as "you can't deploy Godot-based games on consoles" rather than "you can deploy Godot-based games on consoles but you can't get the code to do so from the Godot Project itself because vendors won't let it".
But perhaps for some people this isn't a significant distinction.
At the end of the day the situation is entirely driven by the requirements of the console platform owners.
You can choose to:
* depend on a closed source proprietary game engine & console integration and associated risks/benefits; or,
* an open source game engine & console integration via one of multiple vendors or DIY and associated risks/benefits.
The question developers are asking themselves is ‘if I start out building a game for the next two or three years, when I come to commercialize this, will I have palatable and viable options to do so?
Unity’s random adjustment of their terms is precisely what is driving developers away. But at least Unity is making it clear what those terms are. ‘Talk to one of us privately when you get to the point where you’re ready to port to a console’ is even less certain.
In short, no.
The most detailed explanation of why is probably this section of this article: https://godotengine.org/article/godot-consoles-all-you-need-...
A key aspect is that neither Godot (the project--which doesn't exist as a legal entity) nor Godot Foundation (which exists as a legal entity but AIUI has restrictions on what activities it can perform) would be able to satisfy the requirements of the console platform vendors in terms of qualifying for access to a platform SDK.
Godot, for example, doesn't support console builds, only working with a third party to facilitate porting to those platforms (that may change in the future now that they're getting a lot more support from the community after all this).
For the full nuanced details I've listed the relevant links here:
Nintendo Switch and Playstation and titles from Sony and Nintendo incorporate BSD-licensed open source code, so it is obvious that “open source is banned” is not true. It’s only GPL and other viral licenses that lawyers argue is too risky, because it might require disclosing proprietary source when linked.
Same goes for Apple App Store as well
Technically, they could. It would require someone who hasn't actually licensed the SDK, and so aren't subjected to an NDA, to reverse-engineer things and produce their own implementation under an open source license.
Certainly would be an enormous project, but it is well within the realm of the possible. It's been done with complex systems before.
Yes, I know it's possible to reverse engineer the consoles, but that doesn't make it a viable alternative for the games industry.
It makes it legally viable, in that it would allow the production of an SDK that isn't restricted by any NDA, and therefore could be incorporated into opens source projects.
- The platform holders can and will ban software built without the official SDK
- You'd get delayed access to patches, which might break compatibility with new OS versions
- You're relying on someone being able to reverse engineer new versions for the life of the console. This is a rare skill.
It's like saying you can write your own C compiler. Yeah you can, but you wouldn't use it in production at your job.
None of your points appear insurmountable or showstoppers to me, to be honest, but they would require approaches to mitigate them.