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

[lewispollard]

Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.

[pjmlp]

Yes naturally, GL ES 2 is a 3D API.

There used to be a time when we had accelerated 2D graphics cards, even with support e.g. GDI, and then the 3D graphics accelerator was an additional card.

So there was a transition period when GPUs were still 2D accelerators that could do some 3D on the side.

Then graphics cards got the ability to do matrix operations in hardware, this was still mostly 2D with 3D super powers.

However then shaders came into the picture, as consumer hardware finally became cheap enough to adopt capabilities of graphics workstations hardware.

First only Assembly language for GPUs, but by the time DirectX 8 and OpenGL 2.0 became widespread, we got C like shading languages.

GL ES 2.0 is basically OpenGL 2.0 only with shaders and hardware transform and lighting removed.

If you want to make best use of the GPU there is no way around writing shaders, regardless of it being 2D or 3D graphics engine.

In fact you want to code most of the typical 2D effects as shaders running directly on the GPU.

[lewispollard]

Ah, thanks for your explanation - I'm with you now. I've done some shader programming myself, both "from scratch" and also in Godot, but I'm not an expert. So if you're using a 2D transform type, on the hardware it's still using a 3D/quaternion transform? Interesting.

And so even if I was careful to write shaders that efficiently operate in 2D space, those efficiencies would be trumped by the hardware converting it all to 3D space anyway?

I guess my intuition was that if you have a full 3D shader setup, eg the Unity renderer, that you add a layer of new shaders on top of to give a friendlier 2D API, that's going to be slower than just writing the 2D API on its own.

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

[lewispollard]

Apologies for repeating my reply to the other comment, but I am interested in getting an answer to this question.

Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.

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