The anatomy of a Godot API call

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#.<p>To be honest, if Godot embraces it becoming the Noah&#x27;s Ark for Unity developers and prioritizes C# over GDScript to improve performance, it could be good both for Godot and C# ecosystems, and more emphasis on the ability to use very rich selection of libraries written for .NET would not hurt either.

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.<p>Unity took several years, and a huge amount of investment, along with improvements in the wider ecosystem, before performance became much less of a concern for normal developers. A lot of the work they did around C# usage to achieve this is really surprisingly intense.<p>In the near future I seriously think 2D (and some subset of simple 3D) game devs would be better off looking at Defold, and if you want to make immersive 3D just bite the bullet and move to Unreal. These days cost of preparing assets drastically exceeds coding time anyway.

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.<p>Godot w&#x2F; C# however is very nice and gives you a lot of flexibility with your architecture and code.

One thing that stands out as odd to me is the small selection of really &quot;good&quot; game engines.<p>Unreal seems to have the most features and the steepest learning curve.<p>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.<p>Godot is open source (awesome!) but doesn&#x27;t seem ready for prime time. It doesn&#x27;t have as many features as the other two and the commitment to GDscript seems... odd.<p>If I were picking a game engine today, it&#x27;d be between Unreal and Godot, but I&#x27;m not sure I&#x27;d feel great about either choice.

This dictionary stuff is truly bizarre. I have been playing around with GDExtension and Rust - specifically the meshing interface. This dictionary stuff shows up there. Not only couldn&#x27;t I figure out why (the GDScript angle makes sense in hindsight), but it also makes the API virtually impossible to discover: you have to resort to reading things up in the documentation.<p>As much as I love Godot, the GDExtension interface really has no redeeming qualities and needs to go back to the drawing board.

&gt;Unity has spent the last five years working on speeding up their scripting with crazy projects such as building two custom compilers, SIMD maths libraries, custom collections and allocators, and of course the giant (and very much unfinished) ECS project. It’s been their CTO’s primary focus since 2018.<p>That would be Joachim Ante, who is no longer CTO. He&#x27;s &quot;on sabbatical&quot; and hasn&#x27;t contributed any posts to the forums for over a year. (He used to be quite active on Unity&#x27;s forums.) The entire leadership of the ECS&#x2F;DOTS team has resigned.

I didn&#x27;t read anything that indicated a hard block to creating new methods that bypass the binding layer? All the layers are open source.<p>Unity has their fair share of bolted on methods with a &quot;NonAlloc&quot; suffix. Seems obvious to prioritize raycasts &#x2F; intersection &#x2F; collision code to receive this treatment.<p>I&#x27;ve noticed a few lower lift things I&#x27;d like to submit PR&#x27;s for, just to see how&#x2F;if I can help.

Never underestimate the power of open source game developers. If we could do it with XNA, we’ll do it with Unity. If we have to tear the place down and rebuild it on a rust il-compliant vm instead of mono, we damn sure will [0]<p>[0] <a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;netcorehost" rel="nofollow noreferrer">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;netcorehost</a><p>*edit* everything in the article is on point. Function pointers as binding glue sucks. There’s tons of optimizations to be done in the engine for sure. However, having a robust C# api is on top of list since it was introduced. I do think Godot 5 should make a hard choice and just support C# instead of GDScript.

reply from Juan Linietsky (BDFL of Godot) <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;reduz&#x2F;cb05fe96079e46785f08a79ec3b0ef21" rel="nofollow noreferrer">https:&#x2F;&#x2F;gist.github.com&#x2F;reduz&#x2F;cb05fe96079e46785f08a79ec3b0ef...</a><p>discussed here <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37598985">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37598985</a>

I am so glad that Juan et al are leading Godot and not me because frankly I would be offended by all of this. It hasn’t been a week since the Unity fiasco and all I see is post after post from people complaining that Godot isn’t c# enough. This is like showing up for dinner and insulting cooking before you’ve even tasted the meal. There are definitely opportunities to improve Godot but there are more constructive ways to contribute than drawing a new floor plan for the house on the table cloth while the first course is being served.<p>Have you even made a small game with gdscript? If Godot doesn’t meet your needs then there are dozens of other game engines to choose from, some are native c#.

I tried using Godot for Web game toy projects and unfortunately the base file size is like 12MB and closer to 40MB if you use C#.<p>I think Unity was like 3MB with C#<p>Not a big deal for a lot of cases. Don’t let it deter you. But for my specific target it was a problem.<p>To be honest I’m not sure how Unity can be so small. Does it compile the C# or something avoiding the need for a beefy runtime?

So, what I&#x27;m gathering is if you&#x27;re bothered by the Unity (either a developer, publisher, gamer) developments, and wish Godot was a better alternative than it is, contributing to the project (by donating either time or money) is probably necessary to get there.

How usable is Godot&#x27;s native&#x2F;C++ API for actual game programming, akin to Unreal? (never mind the hot reloading).

If Godot has a first-class C# support then why `Godot.Collections.Dictionary` exists when there is already `System.Collections.Generic.Dictionary`?<p><a href="https:&#x2F;&#x2F;learn.unity.com&#x2F;tutorial&#x2F;lists-and-dictionaries" rel="nofollow noreferrer">https:&#x2F;&#x2F;learn.unity.com&#x2F;tutorial&#x2F;lists-and-dictionaries</a>

Response to the article from godot dev: <a href="https:&#x2F;&#x2F;reddit.com&#x2F;r&#x2F;godot&#x2F;comments&#x2F;16lti15&#x2F;godot_is_not_the_new_unity_the_anatomy_of_a_godot&#x2F;k16982q&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;reddit.com&#x2F;r&#x2F;godot&#x2F;comments&#x2F;16lti15&#x2F;godot_is_not_the...</a><p>TL;DR is that they know this &amp; working on it

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&#x2F;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&#x27;t work in Godot 4 (no backward compatibility).<p>That said, I&#x27;m still enjoying Godot, the only fun part in the past week.

&gt; That’s right, our raycast is returning an untyped dictionary.<p>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?

It&#x27;s not Godot if you don&#x27;t have to wait for something.

Curious if anyone here has tried Bevy (Rust game engine).<p>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).<p>Another post in this thread said the C++&#x2F;native interface was not great and difficult to work with. And C++ even in the best of times is not my favorite thing to work in.

When the performance of Godot&#x27;s physics engine has been mentioned before I&#x27;ve seen <a href="https:&#x2F;&#x2F;github.com&#x2F;godot-jolt&#x2F;godot-jolt">https:&#x2F;&#x2F;github.com&#x2F;godot-jolt&#x2F;godot-jolt</a> pointed to as a drop in more performant solution.<p>Haven&#x27;t tried it in a project yet myself

The thesis of the article appears to be<p>&gt; 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.<p>If there is one thing I&#x27;ve learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly quickly if people start flocking to a tool.

This matches up with what I&#x27;ve heard from people with experience in both Unity and Godot. As convenient as it would be if Godot was ready to swap in for Unity, it&#x27;s got some significant issues that would make that difficult to unfeasible for many people.

I&#x27;m not sure I understood everything here, but I think the tl;dr is that Godot has a powerful new rendering technique called &quot;foreshadowing&quot;.

Sounds a lot like Unity to me.

Funny that they have to use a custom dictionary setup when C# supports dynamic types.<p>&gt;Mixing fast and slow APIs as discussed above would leave us with headaches for decades<p>Meh. Unity has allocating and &quot;NonAlloc&quot; methods, even on the raycast API in question here. It&#x27;s a really minor issue.<p>Sounds like Godot will need more time to bake before its perfect but we already knew that.