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

111–120 of 195 posts

Re: The anatomy of a Godot API call

#111

Post by trinovantes »

Rapzid wrote: post #101
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…

Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... . One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying: > As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq…

That poll seems highly biased

How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey

Re: The anatomy of a Godot API call

#112

Post by dandellion »

krapp wrote: post #108
dandellion wrote: post #102

Earlier quoted context omitted.

I'd argue it's better than Boo and better than Blueprints. Maybe even JavaScript, because JS has made itself very useful as time has passed but as a small scripting language embedded in browsers it sucked. It's only benefits are native integration with the client, and guaranteed support in perpetuity, and it's easy to write, and easy to learn, and teach, it almost never surprises you in ugly ways (which is awesome),…

It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)

Those are your words, not mine. The thread was talking about ditching GDScript in favour of C# and comparing it to other engine scripting languages. You want to go with the conversation on a trip to the mountains, you go alone.

Re: The anatomy of a Godot API call

#113

Post by fidotron »

Fraterkes wrote: post #106
fidotron wrote: post #28

When I first encountered Unity it was because there were performance problems on a Japanese only version of Bejeweled built with it and they needed someone to fix it. It was a classic: creating huge numbers of new objects for particle effects hammering the gc, and the fill rate of the then cutting edge device GPUs not being a match for their screen resolutions. Unity took several years, and a huge amount of investmen…

What advantage do you think defold has over godot for 2d (apart from currently seemingly being more polished)? Theres lots of people complaining in this thread that GDscript is not serious enough as an engine language, but Godot at least has a decent c++ api. Defold only seems to support Lua (although you can extend the engine with other languages afaik).

Bluntly, getting too hung up on languages is procrastination. Lua is more than fine. (GDScript isn't actually that bad, just completely esoteric). Similarly I wouldn't get hung up on Blueprints or C++ when worrying about Unreal, partly because their C++ is so particular it's extreme.

Defold is basically a pile of interesting simple subsystems, especially around game logic, that in combination become surprisingly powerful, and the experience of the devs shows. It is one of those tools that even if you never use it again some of the ideas stay with you.

Re: The anatomy of a Godot API call

#114

Post by harpiaharpyja »

TazeTSchnitzel wrote: post #74
Narishma wrote: post #34

Earlier quoted context omitted.

Presumably because GDScript doesn't support structs.

It does support classes with strongly typed fields, though, which are the next best thing. It's just a poorly designed API, it's not a reflection of language limitations.

Exactly. Why can't it return a RaycastResult or whatever.

Re: The anatomy of a Godot API call

#115

Post by CreepGin »

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 work in Godot 4 (no backward compatibility).

That said, I'm still enjoying Godot, the only fun part in the past week.

Re: The anatomy of a Godot API call

#116

Post by krapp »

dandellion wrote: post #112
krapp wrote: post #108

Earlier quoted context omitted.

It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)

Those are your words, not mine. The thread was talking about ditching GDScript in favour of C# and comparing it to other engine scripting languages. You want to go with the conversation on a trip to the mountains, you go alone.

You're being weirdly aggressive here, and you have yet to actually address any specific point I've made in any of my comments, much less defended your own, so I'm going to call it a night.

Re: The anatomy of a Godot API call

#117

Post by amitmathew »

mdbauman wrote: post #62
gustavus wrote: post #5

The thesis of the article appears to be > However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch. If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly qu…

It's for this reason that I appreciate this article, even though it has a (playful, well-intentioned) negative tone toward Godot which is a project I donate to. This is wonderful criticism! It's thoughtful and well-researched. Hell, even I'm inspired to finally dive into Godot's internals, which I've yet to do despite following the project for several years. I hope this inspires even more contribution and constructiv…

Totally agree, that's why I submitted this article. I'm personally invested in seeing Godot become successful, but this type of constructive criticism is great for the ecosystem (even though some people get very defensive). I think it's exciting that there's so much room for improvement and shining light into Godot internals is a great way to expose what needs to be done.

Re: The anatomy of a Godot API call

#118

Post by cmovq »

jay_kyburz wrote: post #95
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'm thinking about going back to 2d. If Factorio and Slay The Spire can be smash hits in 2d, perhaps I can as well :) I'm a fan of Love but I have to admit the amount of Lua I wrote for just my prototypes did start to get a little scary. I might have a play with raylib.

Interestingly both of the games you mentioned use custom engines. I think people overestimate the difficulty of rolling out your own 2D engine.

Re: The anatomy of a Godot API call

#119

Post by jms55 »

Narishma wrote: post #105
TheMagicHorsey wrote: post #47

Curious if anyone here has tried Bevy (Rust game engine). Godot has a beautiful editor and great tooling for a free engine ... but I worry about the choice of C# and GDScript as the expected way for devs to interact with the project (what if performance is a concern or you need to develop some low-level features). Another post in this thread said the C++/native interface was not great and difficult to work with. And…

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).
Post reply on HN