Godot's 2D engine gets several improvements for upcoming 4.0 | Hacker News Reader

Godot's 2D engine gets several improvements for upcoming 4.0

godotengine.org

136 pointsronjouch22 comments

I've started using Godot recently, and I absolutely love it!

I've written a lot of words - some of them even here on HN - about my frustrations around Unity, most specifically slow compile times and a poorly-thought-out and hobbled API that always seems to be 20% broken in frustrating ways. Godot fixes so many of the frustrations that I previously had with Unity, and it's such a breath of fresh air!

The APIs are generally well thought out and a pleasure to deal with. 2D always felt second-class in Unity - in Godot it's a clear first class citizen (I mean, just see OP). Things generally just make sense, and there's a lot of bells and whistles that I've found personally really useful.

The compile times are virtually instantaneous if you use GDScript - you can even hot load in new changes into a running game (although since it compiles so fast, I rarely even need to do that!) - and that is SUCH an important thing for game development that I can't even explain how great it is.

Also, the UI of the editor is just SNAPPY! Man do I love how fast everything feels in the editor. I hate to keep railing on Unity, but every time you edit a C# file at all in Unity, Unity has to do a reload of assets and it takes 5-10 seconds for the editor to be usable again. Compare this with Godot, which loads new assets virtually instantaneously, and practically never lags for any time at all. It's amazing. I can never go back.

It is a bit rough around the edges - it's only being developed by a small open source team rather than the hundreds of paid developers over at places like Unity and Unreal - but it's really a joy to use.

P.S. The only real problem I found with Godot is that GDScript needs a better typesystem, so I started working on a hobby project to compile TypeScript into GDScript[1]. It's a massive WIP right now but if that sounds like fun to you, I could really use some help.

[1]: https://github.com/johnfn/ts2gd

I don't know the full details behind it, but they're working on changes to the type system in GDScript. IIRC they said the biggest issue they hear about with the current system are that it's optional, which means that the compiler doesn't really do any optimizations based on knowing types ahead of time. In the future, there will be a setting to enforce static typing throughout a project, allowing the compiler to perform better optimizations because it knows that the type of a variable will never change.

Also you could use the (first citizen) C++ API, which has (obviously) types. Or use one of the community supported bindings for the gdnative API. I used Rust for a short experiment and it worked nicely.

Just want to echo all this praise for Godot. I developed games in JS for a while, then switched to Unity for platform/performance reasons. I really did not get on with Unity and struggled through the tutorials (I was so frustrated I wrote a tutorial about JS game dev in response [1]). Unity felt bloated, slow, making simple things unintuitive, and with a mess of an API.

Godot on the other hand is straightforward, fast, and lightweight in a way I didn't think was possible. Like I'm absolutely floored the executable is ~50MB and the low memory usage made me question intially if I had even launched it properly. Regardless of the pros/cons, I'm just enjoying gamedev again.

Coming from JS, the optional type system doesn't bother me none. My only annoyances are a few missing language features like increment operators or type coercion (even in Java I don't need to cast a number to a string to print it).

[1] https://nluqo.github.io/broughlike-tutorial/

I lightly used Godot before and using GDScript was a bad experience. It has some confusing semantics relating to reference counting and in-place modification (e.g. [0]) that make it really hard to use as a 'real' language (as opposed to small bits of code for scripting).

The mitigating factor is that it's got good bindings support and a codebase that's very tractable to poke around in, so you can easily extend it in other languages.

[0] https://github.com/godotengine/godot/issues/15265

They now have really pretty good C# support with integration support with Visual Studio (and with more complicated trickery, VSCode, which is my preference on Linux). It also speeds up your application a bit.

> about my frustrations around Unity, most specifically slow compile times...

fyi they've added incremental compilation support in 2021!

Wow, that's pretty big news! Though I'm so pleased with Godot these days it would be hard to drag me back.

The part that really excites me is at the bottom.

  More work is also going towards the 2D engine. Gilles Roudiere is working on a new 2D tilemap system an editor that will hopefully overcome most of the limitations with the current one. You can follow his progress on this twitter account.

The tilemap interface is useable but I've personally struggled to get autotiling to work for tilemaps that were supposedly designed for autotiling. I browsed through the twitter feed and the progress Gilles is making is really exciting and just a handful of the features will make the interface much easier to use even if autotiling remains challenging. Lots of quality of life improvements coming either way.

Do you think godot might become the linux of game engines in five or ten years?

Perhaps the Blender of game engines. Linux might be a bit of an overreach.

Since blender has a built-in game engine isn't blender the blender of game engines?

It hasn't anymore. They removed it some times ago

While I'm a Unity developer , I'm very very happy to see a solid open source option.

Kinda anti trust ish for Epic to fund Godot though. Unity competes with both Unreal ( I'll argue with HDRP Unity can generally match Unreal in most use cases) and Godot, while Unreal never competes with Godot.

I really want to use Godot in the future because it has amazing 2D features. I hope they will have good HTML5 support with small size, currently HTML5 export is limited and buggy. We currently use Unity project tiny and cocos creator to create HTML5 games.

The fact that Godot's own UI is made in Godot blows my mind.

Godot is really cool, and is one of the more "open" engines in my opinion.

That said, usual disclaimer applies: Godot is _not_ written in Go.

> one of the more "open" engines in my opinion

What does that even mean? It's literally open source.

It means the other engines are less "open"?

Sort of a subtle dig here -- What I mean is game engines _of this type_ where they have a whole IDE and everything tend to be so insular that even if they are open source, it tends to be hard to use parts of it without buying into the whole ecosystem. Maybe this is the nature of the beast when it comes to large game engines, I've just always dreamed of something modular that lets me pick what I want to use, and godot wasn't it either

I see now thanks for clearing that up.

"Open-source" means nothing alone, what matters is the licence. For eg. Unreal Engine is "open-source" but under strict license. Defold engine is also "open-source" but has a Apache-modified custom licence preventing the commercialization of editor derived work (so no commercial custom editor), etc.

There are many degree of openness and Godot goes full MIT so Godot is truely yours (both the editor and the engine)

Reply on news.ycombinator.com