The anatomy of a Godot API call • Hacker News Board

Re: The anatomy of a Godot API call

#91

Post by krapp » Mon, Sep 18, 2023, 10:32 PM UTC

dandellion wrote: post #78

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

GDScript not a great scripting language. It's an adequate scripting language whose only benefit is native integration with the client, and guaranteed support in perpetuity. But there is nothing about it that's better than any other scripting language. No one would choose to use GDScript as a general purpose programming language.

Other scripting languages are also easy to learn. Vanilla Javascript is much easier than GDScript. And so is Lua. Kids learn coding in Lua. Even Python isn't that difficult compared to C#.

Re: The anatomy of a Godot API call

#92

Post by eddythompson80 » Mon, Sep 18, 2023, 10:32 PM UTC

dandellion wrote: post #88

Lucasoato wrote: post #60

Earlier quoted context omitted.

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.

What's wrong with Unity from a technical prospective not marketing/business prospective?

Re: The anatomy of a Godot API call

#93

Post by gustavus » Mon, Sep 18, 2023, 10:34 PM UTC

eddythompson80 wrote: post #89

gustavus wrote: post #80

Earlier quoted context omitted.

> 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?

Well that's a point a lot of other people have raised and is the one I am trying to make, Godot and the associated ecosystem could become like the next generations Javascript. Companies didn't start investing an enormous amount of time and effort into improving JS because they wanted to, they did it because they adopted it and then ran into cases where they needed the performance.

My point being that a lot of the concerns are not foundational to Godot and GDScript and can be improved if there is an investment. But that investment will come with adoption, not the other way around.

Re: The anatomy of a Godot API call

#94

Post by dandellion » Mon, Sep 18, 2023, 10:35 PM UTC

headcanon wrote: post #87

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 pursu…

It's probably not ideal for large projects, but it adds huge value for small ones, and for people who are learning, and I'd expect probably even in larger projects if combined with C++, C# or Rust. It's miles better than the joke Unity had that was called Boo. I also like it a lot better than Blueprints in Unreal while still remaining extremely simple, although I can see how Blueprints can be better for more visual people.

Re: The anatomy of a Godot API call

#95

Post by jay_kyburz » Mon, Sep 18, 2023, 10:37 PM UTC

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.

Re: The anatomy of a Godot API call

#96

Post by syntheweave » Mon, Sep 18, 2023, 10:39 PM UTC

jay_kyburz wrote: post #30

bakugo wrote: post #24

> That’s right, our raycast is returning an untyped dictionary. This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?

There are red flags everywhere. I think Godot has this really nice looking editor, and the nodes look nice, but the engineering foundations are just not there. I think a lot of people start Godot projects but not many finish them because they run into these WTF issues.

Godot has always made a point of prioritizing features and simplicity of modification over speed. In a lot of instances it does just ignore low-hanging opportunities for performance because the simple thing works and needs less code, which isn't always useful, but means it's easier to replace.

Like, my reaction to the blogpost is, "oh, OK, if raycasting nodes are fast, and I need a lot of raycasts, then worst case, I will introduce a custom node designed to do 300 raycasts in one call or whatever."

The corresponding WTF in Unity tends to be "sorry, no code access, SOL" so the inclination of a Unity dev is that they need as direct an API as possible and it needs to be as fast as possible. There are tremendous numbers of shipped Unity games that don't trust the engine to do what it's supposed to and just use it as a HAL, and so there's a culture clash in approach which makes Godot the wrong tool for a dev that wants that kind of system.

Re: The anatomy of a Godot API call

#97

Post by __loam » Mon, Sep 18, 2023, 10:39 PM UTC

badsectoracula wrote: post #81

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. The…

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.

Re: The anatomy of a Godot API call

#98

Post by Jensson » Mon, Sep 18, 2023, 10:41 PM UTC

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…

Python is still slow today. I've worked with performance sensitive python at Google, there is no way to make it fast no matter what tool you use except to rewrite it in a lower level language.

Javascript is fast since it is such a simple language that is easy to optimize, more complex runtimes wont see nearly the same amount of gain from optimization efforts.

Re: The anatomy of a Godot API call

#99

Post by shmerl » Mon, Sep 18, 2023, 10:41 PM UTC

meepmorp wrote: post #49

shmerl wrote: post #40

Earlier quoted context omitted.

What about other bindings, like with Rust?

Apparently (per the article) the C++ bindings use the same API as c# and GDScript. Presumably rust would have the same limitations, unless you wrote a whole new API just for it.

Sounds like something they can improve then.

Re: The anatomy of a Godot API call

#100

Post by krapp » Mon, Sep 18, 2023, 10:42 PM UTC

gustavus wrote: post #93

eddythompson80 wrote: post #89

Earlier quoted context omitted.

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?

Well that's a point a lot of other people have raised and is the one I am trying to make, Godot and the associated ecosystem could become like the next generations Javascript. Companies didn't start investing an enormous amount of time and effort into improving JS because they wanted to, they did it because they adopted it and then ran into cases where they needed the performance. My point being that a lot of the con…

Javascript only got the investment it did because it was the only language that would run in a web browser, when the web suddenly became a billion dollar business and javascript developers were a dime a dozen. Godot is able to support multiple languages. The goal should be improving and expanding language support, not repeating the necessary evil of making Javascript the One True Programming Language.