[keyle]

I shipped a game exclusive to PS4 using UE4 about 4 years ago.

Godot by default does not support consoles. Yes, you can to employ another company to port it for you, but that is a no go for me. UE4 on the other hand you can do it all yourself once you get the developer kit and access (legally) to the platform of your choice.

On the other hand you can easily do mobile with Godot.

[adkadskhj]

Any idea why Godot does not do consoles? Is it a licensing problem, resources problem (ie technical difficulty), or..?

I'm curious because i'm dabbling in some gamedev and wanting to eventually ship mobile and console. I'm more focused on bleeding edge tooling though, Rust gamedev specifically, but i'm curious if the reasons Godot doesn't ship to console also means any Rust project won't be able to ever, either.

Is there something preventing opensource lowbudget projects from shipping to console? Are you forced to go UE4/etc if you want to ship consoles?

[follower]

Someone else already answered with the link to the official Godot information page[0] which can be summarized as:

* Godot dev team isn't a commercial entity with console development license agreements.

* Even if they were, the console support couldn't be truly Open Source due to licensing & NDA agreements with the console manufacturers.

* There are third parties who have ported Godot to consoles who may work with you port your own Godot game.

* You could always port it yourself.

Another aspect that they don't mention is that for the Godot dev team themselves to support consoles they'd essentially have to create an entire parallel development infrastructure (repo, issue tracking, CI etc etc) per console to maintain the NDA confidentially requirements.

In regard to Rust, they were another example I mentioned up thread about this very situation:

"""

The situation is also the same for other FLOSS projects, e.g. the Rust language, where the issues tracking game console support basically say "if you have the ability to develop for (current) game consoles, you also know we can't talk about it here where others aren't under manufacturer NDA":

https://github.com/rust-gamedev/wg/issues/90

https://github.com/EmbarkStudios/rust-ecosystem/issues/18

https://www.reddit.com/r/rust/comments/jtqgn4/q_feasibility_...

"""

So, the "something" that is "preventing opensource lowbudget projects from shipping to console" is manufacturer license agreements/NDAs that are the antithesis of & a barrier to cross-company Open Source development. :)

[0] https://docs.godotengine.org/en/3.0/tutorials/platform/conso...

[megapoliss]

> Any idea why Godot does not do consoles?

Console SDK seems to be not compatible with open source

https://docs.godotengine.org/en/3.0/tutorials/platform/conso...

[e12e]

For those interested in Godot, but wanting console support - heaps might be of interest:

https://heaps.io/

It is another, smaller engine. I would say less featureful than Godot, but I imagine there are some overlapping use-cases?

Ed: and for something quite different - dragon ruby seems a lot of fun (not free, not open source, though): https://dragonruby.org/

[follower]

Ah, seems its developer occasionally comments on HN: https://news.ycombinator.com/item?id=26292740 :)

[follower]

I was curious how Heaps.io could be an Open Source project while also supporting consoles (PlayStation, XBox, Switch) so researched it a bit.

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/

[follower]

Some other details from spelunking the code base...

The exposed console functionality interface can be found via `hl_console`, `usesys` & `usegl` references:

* https://github.com/HaxeFoundation/hashlink/search?q=hl_conso...

* https://github.com/HeapsIO/heaps/search?q=usesys&type=code

* https://github.com/HeapsIO/heaps/search?q=usegl&type=code

The "interesting" pieces are all in some other codebase, e.g.:

* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf...

* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf...

And, if you're a weirdo like me that likes trawling for small console development details (e.g. they treated as ~BSD system) in the code base check out these:

* https://github.com/HeapsIO/heaps/pull/491 (fixes for Nintendo "NVN")

* https://github.com/HaxeFoundation/hashlink/commit/7af111a38f... (PlayStation related naming becomes generic "console" naming)

* https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd0... (More specific console -> generic changes)

* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... (Console brand specific defines)

* https://github.com/HeapsIO/heaps/pull/349

I guess it's all sufficiently vague to not break any NDAs. :)

I think my curiosity is now satisfied. :D

[adkadskhj]

Interesting. They mention porting is possible - what would that look like i wonder? Would you make your game run under both UE4 and Godot? Or do they attempt to put a layer between whatever engine you use and the actual console APIs?

[follower]

In another comment about Heaps.io I summarized their process: https://news.ycombinator.com/item?id=26910210

Essentially the main parts are probably:

* Support the platform native C compiler. (e.g. convert your build system & any idiosyncrasies in your/their code).

* Support the platform OS.

* Support the platform native graphics API.

And, yeah, the easiest way to do this (while still maintaining cross-platform compatibility) is to have an abstraction layer of some sort between the game engine & console specifics.

And, Godot does already have this abstraction layer to support multiple platforms, it's just that everyone who wants to use it on consoles has to reimplement it themselves--unless they work with a third party who has already ported it.

(AFAICT there's nothing that would stop a company from doing a console Godot port and then saying "We can't Open Source this code but will license it freely to anyone who can prove they're a registered console developer" but I'm not sure what the commercial incentives for that might be.

It'd reduce unnecessary duplication and could in theory allow for (licensed developers) to improve the code base in cooperation but would be quite the undertaking & also a significant but also necessarily invisible community contribution!)

[follower]

Thanks for sharing your experience.

And, yeah, that's fair enough--although I imagine if you offered one of the companies enough money they might be willing to license their port under similar terms to those Epic offers UE4 console support under. :D

(And given at least two companies have apparently ported Godot so far, porting it oneself is presumably also an option & one would have full source to work with.)