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

151–160 of 195 posts

Re: The anatomy of a Godot API call

#151

Post by johnnyanmac »

__loam wrote: post #97
badsectoracula wrote: post #81

Earlier quoted context omitted.

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

I understand it. it was built a certain way to support ease of use above almost anything else.

That ease of use is important, but also may be holding back Godot's true 3d capabilities. From a cursory glance as someone wanting to work on a decent scale 3D game, I'd need to treat GDSCript as I do Unreal's Blueprints as of now: miniize use only to high level scripting and maybe UI/Shader code. That's not me saying that GDScript nor blueprints is bad, just that it gets in the way of my specific use case.

If I can help speed up the engine underneath as a whole in the process: wonderful. I don't necessarily want to disrupt GDScript for my convenience either, but like any refactor some breakage is inevitable.

Re: The anatomy of a Godot API call

#152

Post by Kiuhrly1 »

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 ?

I would bet that it doesn't matter for 99% of scripts. By the numbers, Godot's primary use case so far has effectively just been game jams.

Re: The anatomy of a Godot API call

#153

Post by generichuman »

johnnyanmac wrote: post #149
dandellion wrote: post #69

Earlier quoted context omitted.

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

>if I ever need performance I'll probably just go straight for C++. if that's my go to solution, why am I using Godot instead of Unreal? Or even a more mature C++ renderer framework like bgfx, or even Ogre3D? In the context of a decent 3D game, I'll need that performance the lion's share of the time, only scripting to move GO's/Actors around the scene.

> if that's my go to solution, why am I using Godot instead of Unreal?

No revenue split would probably the biggest reason. Also Unreal could still pull a Unity since it is not FOSS (unlikely, but still).

Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.

> even a more mature C++ renderer framework like bgfx, or even Ogre3D?

IMO this is actually the way to go & it is probably the way I'd do it if I had the time to build editor-like tools by myself. But these days content is the hard & time-consuming part of building games. Which means you want non-coder gamedev to be able to do as much as they can, which implies a powerful editor. Godot & Unity have the advantage of pushing the game development to the editor instead of the code.

Re: The anatomy of a Godot API call

#154

Post by TazeTSchnitzel »

jayd16 wrote: post #133
TazeTSchnitzel wrote: post #84

Earlier quoted context omitted.

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.

If they targeted the .NET VM they'd be able to make use of a lot of that investment. But they don't really need to. There's a lot of low-hanging-fruit for performance, and narrowing the gap is more important than outright parity.

Re: The anatomy of a Godot API call

#155

Post by johnnyanmac »

generichuman wrote: post #153
johnnyanmac wrote: post #149

Earlier quoted context omitted.

>if I ever need performance I'll probably just go straight for C++. if that's my go to solution, why am I using Godot instead of Unreal? Or even a more mature C++ renderer framework like bgfx, or even Ogre3D? In the context of a decent 3D game, I'll need that performance the lion's share of the time, only scripting to move GO's/Actors around the scene.

> if that's my go to solution, why am I using Godot instead of Unreal? No revenue split would probably the biggest reason. Also Unreal could still pull a Unity since it is not FOSS (unlikely, but still). Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release. > even a more mature C++ renderer framework like bgfx, or even Ogre3D? IMO this…

>Godot & Unity have the advantage of pushing the game development to the editor instead of the code.

Indeed, but even Unity isn't known for its high performance 3D titles. It COULD viable do them, but not without a lot of work.

That was supposed to be something that DOTS would address, to take out "a lot of work" and make that performance almost be taken for granted. But... well, I don't want to go on that rant again. You can excuse some performance and optimize later, but the sounds of things from this article (with general sentiments even from diehard Godot fans that Godot isn't ready or serious 3D development) makes it sound like that optimizing will in fact exceed the content creation time.

I've seen enough of the guts to know that Godot will likely never make its own DOTS. At least, not its own Burst compiler to get around the c# issues. Likely not IL2CPP either. Fortunately, you don't need that and can get maybe 80% of the performance by simply following some data oriented principles. More than enough for all but the most lofty AAA games (think GTA6 levels of scale).

----

>Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.

that's good to hear, and I get it (Unity rushed out tons of features itself. Including DOTS). I hope I can one day contribute to that effort myself. Would make my future game dev life much easier and would be a good way to give back.

Re: The anatomy of a Godot API call

#156

Post by johnnyanmac »

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…

>and if you want to make immersive 3D just bite the bullet and move to Unreal

Since Godot is right there, I'd rather try and bring up a current up and coming engine to somewhat parity rather than give up to Epic.

Also, iteration is godawful in Unreal. Not everyone is trying to make Gears 6, so I wouldn't mind a more lean 3D engine to work with if I have low-poly or simply not-dense scenes to manage.

>These days cost of preparing assets drastically exceeds coding time anyway.

Only if performance isn't a concern. There's a reason engineers are still paid more than the equivalent artist at studios. That performance is still hard to work with or around, even in Unreal Engine

Re: The anatomy of a Godot API call

#157

Post by johnnyanmac »

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?

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

Hard to predict. We're still in the web 1.0 phase of Godot and dealing with questions like why we made a tag. We could get serious talent addressing the binding layers, we could simply have a few key bottlenecks addressed, or we accept GDScript as the slow path and diverge. It could also simply fade away, but many don't want that, and I'm also not too interested in deprecating something many have used to launch full games.

Personally, my goal is less about making a scripting language perform as well as c++ and more about having options to make sure people can port from GDScript to some faster binding if/when they run into performance bottlenecks. At worst, maybe a migration tool may be needed. Hard, but more doable than any of the above overhauls.

Re: The anatomy of a Godot API call

#158

Post by johnnyanmac »

dandellion wrote: post #102
krapp wrote: post #91

Earlier quoted context omitted.

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…

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),…

>its library pretty much covers what you need to make your average indie game

Hey, if GDScript could run my idea for a 3D Open hub Action RPG at 60fps with little concerns for performance, I'd have no issue.

But alas, my desire for a proper binding or directly tapping into the c++ comes out of necessity, not some pride as a "real game developer". It's not impossible for GDScript to one day become the WebASM of Godot, but we both know that WebASM was, and still is, decades in the making. I imagine it's simply faster to forge a fast path API and let the slow path work for non-performance intensive games.

Re: The anatomy of a Godot API call

#159

Post by johnnyanmac »

eddythompson80 wrote: post #92
dandellion wrote: post #88

Earlier quoted context omitted.

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?

Unity got a stigma for delivering half baked features and dropping support for existing features without a replacement. The epitome of this was where in Netcode, where I believe they had no officially supported solution despite the engine having 2 different packages which were both half-baked, all while the DOTS variant was far from release.

I don't think Godot should go that route.

Re: The anatomy of a Godot API call

#160

Post by johnnyanmac »

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…

>One thing that stands out as odd to me is the small selection of really "good" game engines.

not much odd about it. 3d game engines are a large endeavor, somewhere between making a Large desktop application and making a full blown OS. I'd say the largest ones are comparable to making a web browser engine or even a full blown IDE suite.

There's also some slight snide in that there is no truly "good" game engine. Just ones that teams put up with enough to get across the finish line. The sheer scale of the engines and the nature of them being developer suites means running into edge cases is inevitable.

There are several mature 3D solutions out there, but the ones mentioned have the 3 largest communities and are strongly supported. But to throw out a few others

- Open3dEngine (O3D3), and fork off Lumberyard, which is a fork off CryEngine, is probably the biggest off-the-shelf competitor to UE when it comes to delivering AAA level games.

- Stride is an engine mentioned often in discussions, and it has a similar feel to Unity. But it simply isn't as mature as Godot and lacks some platform support like Mac

- UPBGE is the spiritual successor to the defunct Blender Game Engine, with a similar pitch: create your game without ever leaving your modeling suite.

-Finally, while not a fully featured game engine, I do want to give some note to Ogre3D. It's one of the oldest and most battle-tested graphics libraries out there, is MIT open sources, and is there for the kinds of developers who rolled their own engine/framework and simply used Unity as a rendering backend. Ogre doesn't include physics nor input (nor an editor), but it's really good at throwing your hand rolled game logic and giving it something visual. I could make similar other recommendations for stuff like Raylib and BGFX, but Ogre still being supported after over 20 years is admirable.

There aren't tons of choices, but there are choices out there if you are willing to get your hands dirty.

Post reply on HN