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

81–90 of 195 posts

Re: The anatomy of a Godot API call

#81

Post by badsectoracula »

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…

> community might dislike a performance-friendly change which will break the parity in favour of C#.

The community will dislike a change that will drop GDScript, check the Godot subreddit submission (linked by the article), a ton of comments were pro-GDScript and how easy and fast (development-wise) it is to use.

If that change can happen without affecting GDScript i doubt anyone would have any negative thoughts. There have been a couple of suggestions in the subreddit post on how that could happen and the Godot developers seem to be thinking about it.

Re: The anatomy of a Godot API call

#82

Post by lainga »

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…

It feels like a breath of fresh air to me. Yes, random people, come in and start using Godot, the more eyes are on this project the better. They're articulating gripes I have had but couldn't express. It would be great if, like JS, all the attention became an impetus to make Godot really fast.

Re: The anatomy of a Godot API call

#84

Post by TazeTSchnitzel »

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

Re: The anatomy of a Godot API call

#85

Post by debacle »

hiccuphippo wrote: post #11
anothernewdude wrote: post #3

Sounds a lot like Unity to me.

Yes, I was under the impression that Unity was also slow and people who use it don't particularly care because it's still fast enough for their purposes. But with so many eyes on Godot now, I can only see it getting better.

Unity just released first class support for ECS which will greatly speed up the engine for most users.

Re: The anatomy of a Godot API call

#86

Post by talloaktrees »

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

I think this is correct... you can even go with Rust instead of C++

Re: The anatomy of a Godot API call

#87

Post by headcanon »

droptablemain wrote: post #44

I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project. Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.

I too found it a bit cumbersome past a certain code size. A lot of games don't necessarily need a lot of raw or complex code to run though, so the 1st class benefits of GDScript start to shine, like the native debugger, autocomplete, Godot-specific accessor syntactic sugar.

Its hard to compete with an almost 25 year old battle-tested language, but given the domain and the team size, its a good product and worth pursuing IMO. With that said, I wouldn't want to give up the ability to have C# interop when I need it, and I imagine many games would need to be rewritten in C# after a certain point.

Re: The anatomy of a Godot API call

#88

Post by dandellion »

Lucasoato wrote: post #60
droptablemain wrote: post #44

I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project. Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.

They should remember that even Unity had to deprecate the Boo language to go forward :)

Not sure Unity is a good role model...

Also, having used both Boo back in the day and GDScript in Godot more recently, I'd say that one big difference between the two is that Boo was really bad, and GDScript is actually pretty good.

Re: The anatomy of a Godot API call

#89

Post by eddythompson80 »

gustavus wrote: post #80
droptablemain wrote: post #44

I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project. Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.

> but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, We are talking about GDScript not JavaScript.... Oh wait, the parallels are remarkable Simple language designed to be easy to learn: Check Turns large codebases into a tangled lovecraftian mess of spaghetti code: Check Likely to be someone's first introduction to programming languages: Check Honestl…

As others have mentioned, JavaScript also has had over 20 years of serious investment from the best minds in the industry to improve it. We now have V8, TypeScript and plethora of tools that make writing serious applications possible or even preferable. I seriously would take TypeScript over most languages any day.

How likely would you say the same effort is gonna go into GDScript?

Re: The anatomy of a Godot API call

#90

Post by badsectoracula »

zerr wrote: post #2

How usable is Godot's native/C++ API for actual game programming, akin to Unreal? (never mind the hot reloading).

TBH if i was making a game using Godot i'd just be modifying the engine itself to add any "heavy" functionality (the nodes system would most likely help here) and expose custom high level APIs to GDScript. IMO scripting languages should be used to script the behavior of a game: i.e. tell the engine what to do, not how to do it (which should be written in native code).

From the subreddit submission about this blog post (linked in the post itself) it seems this is something some people already do.

The GDExtension API seems something to use only if you want to write C++ extensions/plugins to be usable by other people, but i don't see much of a point in restricting yourself to it if you are making your own games.

Post reply on HN