[keyle]

I've shipped a commercial game in Godot 3.2. I'm also well versed and shipped games in UE4.

All I can say is working with Godot is an absolute bliss. Seriously, it's fun, it's "easy" and it gets out of the way. Within a couple of weeks, you can be focusing on making your game, rather than a constantly evolving tech-demo.

There are only two caveats: understand what Godot is not good at, 3D open world / large landscape, and console development.

Godot 4.0 was a total mess the last time I tried it though. The Vulkan stuff was completely half baked and the UI was acting out. Godot 3.2 though, solid fun.

[stolen_biscuit]

I've had a similar experience. Godot is a fantastic 2D engine, and a capable 3D engine. If your goal is shipping a fully featured 3D game I'd still recommend Unity or Unreal over Godot, unless you're comfortable with it not being an industry leader. For 2D however, I'd recommend Godot above anything.

Godot 4.0 still has a long way to go before it's ready for everyday use fortunately, not even in alpha state yet so I wouldn't judge it too prematurely.

[keyle]

To be fair, it's perfectly fine for 3D, such as traditional "isometric" style 3D. It suffers more with the lack of clever culling in first person style cameras, especially near large objects (it renders the whole object, even if 5% of it is seen).

[onion2k]

it renders the whole object, even if 5% of it is seen

Do other engines cull parts of objects?

[bluefirebrand]

Absolutely. Vertex culling is a long-standing 3D engine optimization.

[kayamon]

No.

[videogreg93]

Godot 4.0 will include occlusion culling actually, so there's hope.

[blensor]

It's also slowly, becoming an alternative for VR development. They even had hand tracking on the Oculus Quest before Unity and UE

[extraduder_ire]

> They even had hand tracking on the Oculus Quest before Unity and UE

facebook is a large financial contributor to the godot project. I think they do some dev work too. I get the impression they really want more VR games to exist, and work well on their device, no matter how they get there.

[blensor]

Yeah, FB/Oculus has quite the interest in Godot. But at the moment there is no official Quest game made with Godot yet AFAIK. So far we made it into AppLab with VRWorkout, but the store is a completely different story

[Buttons840]

And as mentioned in the article/release, they are serious about maintaining Godot 3 and won't neglect it in favor of 4.

[hnick]

The more comments I read in this thread, the more this sounds like Perl 5 and Perl 6.

[enragedcacti]

It seems as though this is kind of a common paradigm for game engines. Because the tech and/or best practices move so quickly, trying to lock in full backwards compatibility becomes a burden and thus engine devs fall back to "If you started your game on 3.x then it's probably best to stay there. Your next game can start fresh on 4.x"

[bartvk]

It'll take some time before you can confidently make that assessment, though. It took ten years for Perl 6 to come out, and then actually it didn't come out as Perl.

[Buttons840]

Why Pearl instead of the dozens of other successful projects that maintain a stable version while working on a new version?

[hnick]

Because I worked with Perl and got burned a bit so it came to mind. I understand game engines are different and people build against stable versions for years sometimes.

[_6pvr]

This matches my experience (but replace UE4 with Unity).

Godot just doesn't fight you the way Unity does.

[aroman]

Can you give some examples?

[Hammershaft]

In my experience Godot is a significantly more coherent 2d engine. In Unity a 2d game is running in its 3d engine, and useful functions will often be limited to operating on different pairs of dimensions ((x,y) (x,z) (y,z)).

[aroman]

Sure, but as someone working on a moderately sized 2d game in Unity - I’ve never really found that to be anything more than a minor annoyance. At most it’s just an extra cast here or there.

Are there other examples of it being better for 2d?

[mekkkkkk]

One thing that makes Godot smoother in my experience is its project structure. It doesn't use traditional ECS, but relies on inheritance and composition. Combined with the "everything is a node" mindset, it makes it much easier to maintain a mental map of the game. The node hierarchy tree is much more revealing than in Unity atleast (I've dabbled in both).

EDIT: This doesn't just apply to 2D, so maybe it's a weird reply.

[lewispollard]

It uses pixels as its units for 2D, which is the main advantage over Unity, depending on your use case (ie, it's very good for pixel perfect 2D games). If you want to move your sprite 33 pixels, you just add 33 to the translation. This also applies to physics, GUI elements, etc. You can also combine the separate 2D and 3D renderers, while maintaining 2D pixel vectors for your 2D objects, and 3D unit vectors for 3D. Yeah, there are pixel perfect cameras and so on for Unity, but it's so nice to be able to just work in 2D as if it were actually 2D. Simple things in 2D renderers like alpha handling and overdraw was slower in Unity than Godot for that reason when I last used it, since it's more complicated to render those things in a 3D engine than a 2D one (admittedly, I last used Unity properly at least a couple of years ago, may have changed).

It has parallax scrolling features built in. Small thing, but there are lots of little features like that scattered in the default tools that just don't exist in Unity without writing your own, or paying for an asset. In Godot you just drop the node in and you're away. Godot has an asset store too - where everything is free and open source, and linked to their git repositories. For example, you can add a minecraft-like voxel engine, dialog editors, a Redux-like store, shaders, new GUI elements, and so on in Godot for free, in a click, without an account, or a single webview or browser page in sight. Granted, this means that older assets may no longer work or be maintained, but the same can be said of Unity (and my experience with the Unity asset store is that half the time, nothing works out of the box anyway even when you've paid a chunk for it, and rarely does a tool just do the simple thing that it says it does, and therefore takes a bunch of work just to get the thing to play nice with your code).

The recent 3.3 release added a bunch of 2D renderer improvements such as BVH partitioning/batching for rendering and physics, vertex pixel snap on the GPU,

The only thing that Unity has over Godot in terms of 2D imo is the Box2D physics engine (Godot uses its own 2D physics implementation that, while adequate for a lot of games, isn't quite as flexible as Unity). That said, there are at least 2 Godot plugin modules that add (partial) Box2D support just from a brief Github search.

Moving away from 2D specifically - the animation player/controller in Godot is amazing - you create an animation player node, and you can then key in literally any property of any object from the editor to be animated, and draw out animations with bezier curves and so on, animating multiple properties at once, which you can then play back with a simple call to `AnimationPlayer.play("name");`. You can use a single animation to animate vectors, enums, bools, simultaneously by just drawing them into the animation editor. Last I checked Unity didn't have anything like that. You've got a complicated mesh structure with layers of materials and shaders, and you want to interpolate various properties on various materials of those mesh structures, it's as simple as creating the animation, going to the materials, and hitting the key button on the properties you want to alter.

From a general design perspective, Godot's scene tree works kind of like Unity's nested prefabs - a feature they implemented long after Godot had nailed this kind of structure, and it still does it in a much simpler and less hacky way than Unity. Everything in a Godot game is already essentially a nested prefab, without the clunk of having to distinguish between regular prefabs holding nested prefabs, or ensuring your modified prefabs are in sync, and so on. You can create simple components composed of complicated structures of nodes, save them into a new scene file with a click, and drop that anywhere else in your scene tree wherever you like, as a native and expected behaviour. It's a bit like React components in that you can very easily combine and produce new combinations of your existing work, even at runtime. You can then easily share these nodes between godot projects, or even write a simple plugin to add them to Godot's list of built-in nodes.

Oh, and all of those scene, node and resource files are just plain text files, easily editable in a text editor, and extremely friendly to VCS.

Besides all of this, if you write a game in Godot you own 100% of the source code, both your game code and the engine supporting it. No licensing, no pricing plans, no salespeople. No official support, yet the community and contributors are extremely helpful. Engine doesn't do something you want? You can patch it and recompile, and add new third party C++ modules (eg, you can add full Javascript/Typescript/Rust/D/Python/Nim scripting support this way, as well as new engine features with native speed) by dropping them in the modules folder of the engine source. There's a legendary talk at GDC by Jeff Vogel, who's been writing obscure, ugly RPGs as Spiderweb Software since the mid-90s. One of his points is that if you want to make a living writing indie games as a solo developer, owning the source code is one of the best things you can do, since 20 years down the line you can still update and compile it, remaster, and sell more copies of work you finished long ago (which Jeff has done many times, and is still now writing those obscure games and supporting his family from it). Good luck getting Unity 2020 to work, build your game, and have the license to use it commercially in 2040 ;)

[bartvk]

Upvote for mentioning Jeff Vogel. His blog is here: https://jeff-vogel.blogspot.com/

He doesn't post often, but when he does, it's a great one about indie game development.

[aroman]

Thank you much for this incredibly detailed and thoughtful answer!

[IshKebab]

But that's how 2D games actually work. They're really just 3D games with an orthographic camera. It doesn't really make sense to have separate 2D and 3D engines.

[lewispollard]

Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on, which makes life a lot easier for many 2D games.

Plus, you can support a much larger range of hardware with a true 2D renderer that targets specific 2D graphics APIs, than with a cutting-edge 3D engine hacked to look 2D.

[pjmlp]

That would make sense 20 years ago, nowdays all graphic cards are designed for 3D APIs, regardless what you do, the driver only knows about 3D stuff.

[IshKebab]

> There's a pretty big overhead even if you're not using any 3D features.

Graphics cards haven't had 2D acceleration for decades so you're always using the 3D features.

[ludamad]

Core engines no, but Godot scene model overall fits very well for making 2D games. You end up using naturally named things, composing stuff on a 2D plane, etc. I'm sure an experienced unity user can cut through the noise.

[Qwertious]

Maybe HammerShaft is referring to the fact that Godot usually has separate components for 2D and 3D?

Like, there's Node2D and RigidBody2D and Bone2D and Camera2D etc etc etc.

[trinovantes]

I'd like to know more about what you mean by "Godot is not good at 3D open world". Is it just a matter of performance or something more architectural?

[keyle]

Architecturally it's perfectly fine, designing the 3D world is just as capable as the 2D world in terms of tooling. It's more a performance concern. The biggest pain is the lack of proper face culling. It does object culling, meaning if you don't see it at all, it's culled. However faces, not quite.

So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you run your framerate down to the ground if you render even only 5% of it, as it renders everything else as well.

You can mitigate that to some degree by breaking up objects, but even the shell being plain would still cause massive issues.

For first person, open world, or large environment type game, I'd recommend Unreal. For 3D isometric style games, it's perfectly suitable with knowing the caveats and minimal adjustments from an asset creation perspective.

[alkonaut]

> So if you're in space, and you're flying nearby a big ship full of triangles, such as an imperial star destroyer, you run your framerate down to the ground if you render even only 5% of it, as it renders everything else as well.

There is limiting of overdraw (not rendering the same pixel multiple times) which is easy with Z-buffers. There is frustum culling (not rendering triangles that are outside your FoV or facing away from you) already of course.

The final type of culling is occlusion culling which is avoiding rendering that starship because it's on the other side of a planet from your viewpoint (for example). That's not a feature of 3.X but it's a feature of 4.0. The technical details are pretty interesting, it uses Intel Embree (the raytracing library) to do a low-res raytrace to find the occlusions.

[meheleventyone]

AFAIK neither Unreal nor Unity will frustum cull the triangles of a model out of the box and although both offer some other forms of occlusion culling they also only operate at the whole model level.

[ganonm]

This is wrong. Unity has frustum culling enabled by default. You are correct that it only operates at whole model level though.

Occlusion culling in Unity is fairly straightforward. Simply requires a bake. It also supports 'occlusion areas' where you can give it a hint to do a higher resolution occlusion bake e.g. if you think the player will likely be in that area.

Edit: originally misread parent as stating Unity didn't frustum cull by default. Parent comment is correct.

[meheleventyone]

I’m not wrong just being more specific. All three engines frustum cull by default and all three do it at the level of the complete model. I said Unity and Unreal don’t frustum cull at the level of the individual triangle which was the factor the person I was replying to insinuated Godot lacked.

[ganonm]

Apologies, misread your comment as "won't frustum cull by default".

[speeder]

Godot wasn't intended to be used for 3D at all, it started as purely 2D engine.

The 3D it can do is kinda... "shoved" into it. It works but it wasn't designed from the ground up like other native 3D engines are.

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.

[lewispollard]

> The 3D it can do is kinda... "shoved" into it. It works but it wasn't designed from the ground up like other native 3D engines are.

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

[hn8788]

It was a little of both, but it's not really a valid complaint any more. When Godot first open sourced, it didn't have features like culling meshes that the player couldn't see, and the lighting implementation was pretty basic. The default language in the engine is basically python, so it could cause a performance bottleneck. Now it has a lot of the 3D performance features it was missing, and it has first-class C# support if the default language is causing a bottleneck.

[ImprobableTruth]

I tried Godot again like ~8 months ago and the C# support was still awful to the point that I'd consider 'first-class C# support' an outright lie. It might be 'officially supported', but it's in 'late alpha' since 2018 and is very obviously a second-class citizen, which should be clear just from the bad state of the C# docs. Community resources for C# are also much more sparse (subpar support probably contributes to this).

It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.

Keep in mind that I'm obviously quite soured by the experienced - Godot might still be the right choice for anyone who is considering. I'd just recommend anyone to factor the very rough C# support into their choice, especially for anyone planning to use it for a more involved project.

[lewispollard]

I've been using C# in Godot for all of my latest projects of the last ~year and have had absolutely no issues at all. Most of the docs these days have a "GDScript/C#" tab selection, and the intellisense support is so good that I rarely even have to check.

Now, I did already know the Godot API quite well when I started using C# so that contributes. But I haven't found it to be a second-class citizen at all, and in fact allows me to use features that I wouldn't have been able to in GDScript (native event handling, offloading to native data structures for computation rather than using the Godot API for them, nuget packages, and so on). I can also use eg Jetbrains DotTrace to profile code in much more detail than GDScript, and edit and launch my game code from an IDE without ever opening the editor.

You can also opt to use the dotnet-core compiler instead of the bundled Mono one these days which allows you to use some more modern features.

The only clunky thing I've found is that trying to use a native C# data type in a Godot Node object causes marshalling errors, but I'm pretty sure that would apply to nearly any Mono game engine and that Unity has similar issues (having to wrap things in MonoBehaviours etc- it's been a while so this may be inaccurate). The simple workaround is just to use the Godot API for things that are in the scene tree, and native types when you need to compute stuff with better performance.

I'm curious as to what actually felt rough to you in C#?

[datavirtue]

Yeah, no idea why C# was introduced other than to appeal to people with zero game dev experience who might be lured in by thinking their knowledge of C# is going to matter.

Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.

[ido]

Isn't it obviously to lure unity users?

[lewispollard]

> Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.

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.

[krapp]

GDScript isn't basically Python. It uses significant whitespace, but that's about as far as the similarities go.

[follower]

The Godot docs[0] describe the relationship as:

"It uses a syntax similar to Python (blocks are indent-based and many keywords are similar)."

And[1]:

"If you've ever written anything in a language like Python before then you'll feel right at home."

So it's more than just whitespace.

I seem to recall it being acknowledged that Python was a big influence on GDScript's design and in a number of cases "How does Python handle this?" drove some of the design decisions.

[0] https://docs.godotengine.org/en/stable/getting_started/scrip...

[1] https://docs.godotengine.org/en/stable/about/faq.html#what-i...

[alpaca128]

You are not wrong, but the original point was that GDScript is slow because its syntax is similar to Python's and Python is slow. That just doesn't make any sense.

> The default language in the engine is basically python, so it could cause a performance bottleneck.

[shoo]

python is slow because the extreme flexibility of the language makes it very difficult for compilers/interpreters to perform analysis that could allow optimisations

this doesn't have anything to do with the syntax. we could completely replace python syntax with e.g. pyc bytecode or serialised AST data but the language would still be challenging to execute efficiently as the language is still exactly the same

one can get a few ideas of how python could perhaps be made faster by reading about all the restrictions that rpython imposes

https://rpython.readthedocs.io/en/latest/rpython.html

[follower]

Ah, I didn't notice that detail of the discussion, thanks.

If "basically python" means "scripting language" vs "C++" then I can see why by that standard "performance" could be a concern to someone.

But, yeah, doesn't seem to be a Python/GDScript specific concern.

[keyle]

I use both GDScript and python professionally. Yes there are a lot of differences but overall if you know Python, learning GDScript is _very_ easy.

[publicola1990]

But why did they chose to invent GDScript and not chose to use/embed python itself? Using a newly invented special purpose language is something that often discourages me from considering a tool/framework.

[pansa2]

See “What were the motivations behind creating GDScript?”:

https://docs.godotengine.org/en/stable/about/faq.html#what-w...

[clarge1120]

I can’t tell if the Godot team is serious about commercial viability.

My company cannot afford to wait until Godot 4 to build product. And since we’ve got a big investment in prior work, there is little chance we will switch that work over to a platform that will be brand new in a short period of time.

[ShinTakuya]

Well you're welcome to hire some extra engineers on Godot's behalf. They can only go so fast with shoestring budget. If it doesn't meet your requirements, consider alternative engines such as Unreal.

Don't get me wrong, I'm not saying you have no right to complain. But the way you're going about it is off-putting. Godot's devs are working hard and what you're saying isn't constructive.

[lewispollard]

> I can’t tell if the Godot team is serious about commercial viability.

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

[kumarvvr]

> 3D open world / large landscape, and console development.

Will it be a good choice for FPS shooters taking place primarily in closed spaces like buildings, etc?

[keyle]

Yes if all your walls are individual meshes and you use large slabs for the ground (not the entire map being a floor).

If you're keen on this, I recommend using Trenchbroom for level design and the plugin that goes with it in Godot, it's pretty cool! (Qodot)

[lewispollard]

Though you can use the MultiMeshInstance node or SurfaceTool API to create and combine meshes at runtime.

[jay_kyburz]

There is no built in occlusion system. So I would say no.

[TeMPOraL]

Wait, so if it's not good at 3D outdoor scenes, and not good at 3D indoor scenes, then... what is it good at, in terms of 3D games?

That would only leave 3D models + minimal scene (e.g. top-down/isometric games), which minimizes the amount of occlusion?

[follower]

With regard to 3D indoor scenes, performance is entirely related to the complexity of the scenes & how much effort is put into loading/unloading non-visible areas etc.

For a couple of data points, here is the official Godot third person shooter demo:

https://github.com/godotengine/tps-demo

And you can also find "Platformer 3D" demo here (playable in browser too):

https://godotengine.github.io/godot-demo-projects/

The showcase also has some 3D games that have been produced:

https://godotengine.org/showcase

Also TailQuest in development 3D Platform/Puzzle:

https://www.reddit.com/r/godot/comments/gnfjn9/tailquest_so_...

Various people have experimented with voxel worlds and other things which push the limits of the engine & are viewable on YT.

In short, with 3.0, Godot isn't competing with, say, Unreal in the 3D realism stakes but it still has more 3D capability than most people who start to make a 3D game will actually hit when the scope of the work required becomes apparent. :)

[jay_kyburz]

Any game where camera frustum culling can easily cull the number of object rendered. So when the camera is pointing in a fixed direction and you have control what moves in front of it.

[badsectoracula]

FWIW it depends on the environments. Oblivion also doesn't have occlusion culling at all yet it ran on the original Xbox 360.

[alkonaut]

Occlusion culling is one of the big features of 4.0.

[tekni5]

I enjoyed the challenge of figuring out what game you made, by deciphering your profile. :)

[lattalayta]

What kind of game did you ship? Was it 2D or 3D?

I was starting to make a 3D game for mobile and was planning on using UE4, but I've heard a lot of good things about Godot. Are there any pain points or blind spots in Godot's feature set?

[keyle]

With UE4 you have a very large engine to deal with. With Godot you'll spend more time making your game look AAA.

for 2D I'd definitely go Godot.

I mostly do 3D games with fixed or limited range cameras (not first persons) so Godot works nicely.

Overall you'll need to understand well the engine you choose going forward. They all have their pros and cons.

As an example, it takes 3-4 hours to recompile the UE4 engine source code (for customization). Godot, about 4-12 minutes, in its entirety.

[mekkkkkk]

In general I'd say Godot is excellent for the average indie game. It might not be the best choice for cutting edge AAA rendering or performance. In my experience the most important aspect of an engine for a solo/hobby developer is the ergonomics and the workflow. I've found Godot to be a breeze of fresh air in this respect compared to the much more clunky Unity or UE.

[aflag]

Which language did you use? GDScript?

[keyle]

Yes GDScript. Very few gotchas, very easy to learn and maintain in my head. I believe I had to recompile the engine a few times for various things, which took a bit more, but the game can be shipped entirely with GDScript.

Having used C++ and Blueprints extensively, GDScript is really a breeze. Of course games perform better if made entirely in low level C++, but as an indie you have to make a choice and you have to ship a game.

[jokethrowaway]

I would add tilemaps to the things that don't flow very well.

Looking forward to better tilemap support in 4.0

[M5x7wI3CmbEem10]

what about 2.5D? side scroller games that allow limited movement on the z-axis. think Paper Mario

[follower]

> console development.

Curious if you had a direct experience with the console side of things with your game?

Also, can I provide you an opportunity to promote your game by asking you to tell us more about the game you shipped? :)

(The rest of this isn't directed at you but more trying to clarify the Godot console situation for anyone else interested.)

I've noticed there seems to be a lot of misunderstanding (particularly by "less commercially experienced" game devs) in relation to Godot's "console support" or apparent lack thereof.

Godot do now at least have a page[1] to directly address the issue and clarify the situation which can be mostly summed up with:

"... there is no engine that is legally allowed to distribute console export templates without requiring the user to prove that they are a licensed console developer."

and:

"Console ports of Godot are offered by third-party companies (which have ported Godot on their own)."

I seem to recall there was one FLOSS game engine that got a grant or something to incorporate support for some XBox initiative (that wasn't "full devkit support" level) but for every other major console there's no engine that has FLOSS code supporting it--and if it did then no one could probably tell anyone about it because of NDAs. :D

As a side note[0]:

"Additionally, there is some unofficial third-party work being done on building for some consoles. However, none of this is included in the default build scripts or export templates at this time."

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

Hope your game is selling well. :)

[0] https://docs.godotengine.org/en/stable/about/faq.html#which-...

[1] https://docs.godotengine.org/en/stable/tutorials/platform/co...

[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/

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