Live data from Hacker News

Godot 4.6 Release: It's all about your flow

godotengine.org

121–130 of 135 posts

Re: Godot 4.6 Release: It's all about your flow

#121

Earlier quoted context omitted.

But then I have to code in those other languages, languages that require manual memory management that I'm not as familiar with. C# is many times faster than gdscript, and I don't have to think about memory hardly at all. And it's easy enough to code the whole game in it.

You can use C#. It is well supported except for the (currently) missing web target and Microsoft is funding C# support so it will not get abandoned. You can also use other garbage collected languages. I once tried the Lua bindings and they worked fine. The problem with C# is that its garbadge collection is not really suited for game dev. The creator of the Mono runtime actually calls using C# his Multi-million dollar…

I know, I already use C# for Godot. My original comment was just to explain why I don't use gdscript.

Swift might be cool too, I've only used it a bit but I liked what I saw.

Re: Godot 4.6 Release: It's all about your flow

#122

Earlier quoted context omitted.

To me it is so conceptually clean and easy to work with. Unity and Unreal are great products, but they also seem kind of clunky and bloated.

> but they also seem kind of clunky and bloated Like their predecessors, they were initially conceptually clean and simple in the beginning too. But then decades of feature development, the scope creep overcomes the clean architectures and design decisions. Lets see if Godot remains the same in 10-20 years, I'm cautiously optimistic :)

Godot is surprisingly old. But I take your point.

Re: Godot 4.6 Release: It's all about your flow

#123

Earlier quoted context omitted.

might be geometry dash.

What OP is describing is Tomb of the Mask or in that genre. There’s a good GIF embedded here showing the navigation mechanic: https://en.wikipedia.org/wiki/Tomb_of_the_Mask

That’s the one!

Re: Godot 4.6 Release: It's all about your flow

#124
post #26

Earlier quoted context omitted.

You can make up some 'critical defects' for every tool and engine in the universe. So what game engine is perfect for an 'ambitious developer' to use?

Unity, Unreal, Monogame are a few engines via which ambitious games are regularly shipped. Godot is not among them because Godot has very few good games in it, with a terrible use:release ratio, which is in turn because it is primarily a game dev tutorial platform. I'm not sure if there is any example of a studio or person making their second game in Godot when their first was not, and this rare occurrence seems to m…

Don't all game engines have a terrible use:release ratio? How did you determine that ratio for Godot and Unity and does it matter? You can't blame the engine for all occurrences of beginners losing interest in building a game.

While 3D is still in heavy development it's actually easier to build simple 2D games in Godot. You can finish a simple game before the Unity installer is finished. Game engines aren't a fixed thing either. Assuming improvements continue Godot will get easier to use and gain market share.

Re: Godot 4.6 Release: It's all about your flow

#125
post #69

Earlier quoted context omitted.

Thanks! I bet I've had it confused with something else then.

Might’ve been MonoGame? It sounds enough like Godot that you might’ve confused the two, it’s a code-first framework, and it’s popular enough that you might’ve heard of it (Stardew Valley, Bastion, and Celeste are all built on MonoGame)

[flagged]

Re: Godot 4.6 Release: It's all about your flow

#126

Earlier quoted context omitted.

I would bet SDL; it's a C library that a ton of other libraries are influenced by or based on. It's not usually thought of as an engine on its own nowadays

Nah, like you said, SDL is just window creation and a bit of audio etc. If that counts as a "game engine" then so does every web browser. EDIT: Sorry if I seem grumpy, I'm not actually grumpy at you, I'm grumpy at PyGame for calling itself a game engine when really it's just SDL + the ability to blend images.

I wasn't alive or making games at the time, as I was a baby, but I believe SDL would have been understood as an engine when it released.

I wouldn't call it one nowadays, except in so far that someone looking for an engine might find themselves happy with SDL (or PyGame, etc)

Re: Godot 4.6 Release: It's all about your flow

#127

Earlier quoted context omitted.

It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.

But then I have to code in those other languages, languages that require manual memory management that I'm not as familiar with. C# is many times faster than gdscript, and I don't have to think about memory hardly at all. And it's easy enough to code the whole game in it.

rust and swift don't require manual memory management. rust is RAII and swift is either value types or reference-counted.

(yeah there are escape hatches, but it's weird to use them)

Re: Godot 4.6 Release: It's all about your flow

#128

Is there anything in this which will make it easier/better to make GUI applications? https://github.com/derkork/openscad-graph-editor kind of has me considering using Godot for creating a drawing program....

Check Lorien, a whiteboard/drawing app made in Godot.

https://github.com/mbrlabs/Lorien

Re: Godot 4.6 Release: It's all about your flow

#129
post #66
post #2

wow, this release looks really cool! this part especially: > With the new LibGodot, you can now embed the engine directly into your own applications. Instead of running Godot as a separate executable, you can control startup, manage the engine loop, and integrate it seamlessly into custom workflows. it might seem like a small thing but the IoC setup of Godot makes it really annoying to build certain game infrastructu…

> I'll probably wait for a couple versions before trying it out on my game since I'm sure it's not exactly battle-tested yet Who better to do the battle-testing?

Indeed. If a test runner embedding the Godot engine is now feasible on paper a proof of concept implementation seems deserved: if there are fatal bugs or limitations they will be eventually corrected (sooner if properly discovered, reported and discussed), and if there are none the new technology is "battle-tested" enough.
Post reply on HN