Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The anatomy of a Godot API call

sampruden.github.io

Post reply on HN
Print view View original

131–140 of 195 posts

Re: The anatomy of a Godot API call

#131

Post by 0x_rs »

CreepGin wrote: post #115

The biggest problem for me in moving to Godot is the editor tooling. I find the @tool and EditorPlugin workflow to be very finicky. Editor restarts were needed to refresh/correct changes from @tool scripts. And a lot of what I needed to do in the scene view (context-free) required hacky solutions. Not to mention, they changed a lot of related APIs in Godot 4, most of what I google are still from Godot 3 and don't wor…

It's made great progress in this regard since 3.x, and it's an an extremely powerful system, but dealing with some @tool intricacies can very quickly make you waste days trying to figure out what's going on. My greatest annoyance regrettably lies in one of Godot's most convenient features, custom resources, that are so extremely tedious to use with @export from the editor in any meaningful, useful way that I've personally given up on it for the time being, their lifecycles even avoiding _init() cross well beyond the bug behavior territory and GDscript permits no alternative approaches code-wise that aren't absolute monstrosities of jerryrigged variadic functions (not supported except for a few API calls resembling them) jumping one into another or endless walls of parameters you get lost into.

Re: The anatomy of a Godot API call

#132

Post by jayd16 »

tourmalinetaco wrote: post #127
sankhao wrote: post #121

Earlier quoted context omitted.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

It’s not about spending time, it’s about being ignorant of GDScript’s use cases. It’s like if people went into Python communities and shat all over it because C is faster. It’s true, but it misses the point that iterating in Python is leagues faster and is fast enough for a large section of projects.

I guess the argument is that GDScript has a different use case than Unity's C#? Seems like Unity devs know what a C# scripting engine is like and feel it covers the use case fine. To say they don't understand the use case would mean it must be different somehow. Can you go into that?

Re: The anatomy of a Godot API call

#133

Post by jayd16 »

TazeTSchnitzel wrote: post #84
neonsunset wrote: post #14

So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for G…

GDScript is in a much better place than most scripting languages because the compiler actually has quite a lot of static type information. If they invest in unboxing optimisations and a JIT, it can definitely become competitive with C#.

I can't help but think this is delusional. Microsoft has put massive effort and funding into C# and I just don't see how Godot, being much more niche, can reach that level of investment.

Re: The anatomy of a Godot API call

#134

Post by danbolt »

sankhao wrote: post #121
__loam wrote: post #97

Earlier quoted context omitted.

It is pretty shitty how people seem to be coming into Godot and immediately shitting on GDScript without trying to understand why it was built that way, and I say that as someone who shit on GDSCRIPT initially.

How long are they supposed to spend to start appreciating it enough to tolerate 20x performance penalty to core engine functions ?

For some, a few days of GDScript usage. For others, after they convert their bottlenecks into C++.

UE’s blueprints are much(!) slower than native code, but they’re still an incredible tool in the toolbox. GDScript is kind of the same; it’s covering a critical role of non-performance-sensitive glue.

That said, I’d really like to see Value Types added, as well as these sorts of heap allocations addressed in Godot 4 at some point.

Re: The anatomy of a Godot API call

#135

Post by lynzrand »

dandellion wrote: post #69
neonsunset wrote: post #14

So the decision for slow interop is caused by choosing to have parity between GDScript and C# because the former forces the types to be heap-allocated...and community might dislike a performance-friendly change which will break the parity in favour of C#. To be honest, if Godot embraces it becoming the Noah's Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for G…

I went into Godot thinking I'd hate GDScript and switch to C# pretty fast because I already knew it. Now I love GDScript, if I ever need performance I'll probably just go straight for C++.

C# strikes the balance between speed and dynamic features IMHO. Especially for games that need mod support (which is not that uncommon at all), using C# allows for the modders to easily interface with existing code, while still getting near-native performance thanks to the type system and JIT. C++ code in such case would be too rigid to be modified and hard to interface wth.

Re: The anatomy of a Godot API call

#136

Post by jayd16 »

rybosworld wrote: post #57

One thing that stands out as odd to me is the small selection of really "good" game engines. Unreal seems to have the most features and the steepest learning curve. Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains. Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many fe…

It really depends on what your game/team needs. If you're trying to make a match-3 then Unreal is maybe not the best choice. If you're trying for competitive cutting edge graphics in an engine that is mostly done so you can actually focus on the graphics, then Unreal is top of list.

I think its probably better to look at Unreal as state of the art but licensable. Other big game companies have cutting edge engines but they're proprietary and not available to license.

Re: The anatomy of a Godot API call

#137

Post by zzo38computer »

rybosworld wrote: post #57

One thing that stands out as odd to me is the small selection of really "good" game engines. Unreal seems to have the most features and the steepest learning curve. Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains. Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many fe…

I think that which game engine will be "good" depend on manyu things including what kind of game, what computer system, FOSS, licensing, other features, etc.

Re: The anatomy of a Godot API call

#138

Post by danbolt »

mardifoufs wrote: post #104
dandellion wrote: post #78

Earlier quoted context omitted.

They're commited to GDScript because it's a great scripting language. I started with Godot expecting to switch to C# pretty fast because I'm already familiar with C#, but I was pleasantly surprised with GDSCript. And I'm a programmer with more than 10 years of experience. For people who are still learning it must feel like the difference between trying to learn to ride a bycicle vs learning to fly a boeing 777.

Not being rhetorical or snarky, but what do you like about gdscript?

I can’t speak for the parent, but @onready combined with the $ operator is a delight when making a prefab.

I also very much like the way signals are declared compared to C#’s code generation.

I’m also a fan of TypeScript, so being able to do gradual typing while prototyping is a huge plus. It’s going to be a big advantage if they ever get JIT.

Everything being reference-counted, rather than fretting about GC pauses is comforting too.

Re: The anatomy of a Godot API call

#139

Post by Narishma »

jms55 wrote: post #119
Narishma wrote: post #105

Earlier quoted context omitted.

Bevy is even more immature than Godot. It doesn't even have an editor and its reliance on webGPU leaves a lot of platforms in the dust.

As a Bevy dev - what platforms? We support Vulkan, DirectX12, Metal, WebGPU (with a bit more limited features), and WebGL2 and GLES 3 (with a decent amount more limited features and performance).

Older devices. GLES 2 and DX9 to 11 mainly.

Re: The anatomy of a Godot API call

#140

Post by rudedogg »

jayd16 wrote: post #136
rybosworld wrote: post #57

One thing that stands out as odd to me is the small selection of really "good" game engines. Unreal seems to have the most features and the steepest learning curve. Unity is comparatively easier to learn. Fewer features but C# support is a big plus. The major downside is that the company is run by incompetent MBA brains. Godot is open source (awesome!) but doesn't seem ready for prime time. It doesn't have as many fe…

It really depends on what your game/team needs. If you're trying to make a match-3 then Unreal is maybe not the best choice. If you're trying for competitive cutting edge graphics in an engine that is mostly done so you can actually focus on the graphics, then Unreal is top of list. I think its probably better to look at Unreal as state of the art but licensable. Other big game companies have cutting edge engines but…

> focus on the graphics

Unreal isn't good just because of the graphics. It has loads of tools built in, and that's where most of the value is in my opinion.

This video will give you an idea: https://www.youtube.com/watch?v=k2IP5DYQ0-0

Post reply on HN