C# has faster execution speed compared to GDScript, but Godot needs to marshal data when communicating between the core engine and the C# runtime, which can negatively affect performance if you don't keep it in mind when writing your code.

But ultimately I'd argue compilation speed is waaay more important than execution speed when it comes to creating games (which require rapid iteration and testing). There's only a small amount of code in a codebase where squeezing out the maximum performance is required, and those important bottlenecks can be refactored or rewritten in a more performant language if needed.

I mean you can go both ways. If godot fell behind then it would be argued that it's not it's primary language. IE I'm not a huge expert on how the languages work. but I'd imagine godot would be less efficiant when using the languages that it supports, but wasn't built for.

That's like competing in a reading contest with your second language, versus an opponent who only speaks the language.

Unity, including Unity Hub and related components, required roughly 21GB of storage, while Godot Engine needed only around 164MB

It really is astounding how bloated Unity has become over the last decade. It was never a lightweight engine, but 20GB+ just to install the editor is nuts.

I'm guessing it's due to Unity firing up a full modern toolchain during compilation versus GDScript's simpler bespoke compiler.

It would have been a better comparison if he'd used C# for both games, given Godot supports it as an alternate to GDScript.

In Grové’s tests, Unity took 15.4 seconds to compile scripts, while Godot Engine took just 0.31 seconds, which is a significant gap. This is likely due to Unity’s standard use of the compiled language C#, whereas Godot uses its interpreted in-house language GDScript, allowing for much faster iteration times.

Both C# and GDScript are (typically) compiled to bytecode, so they are probably more similar than they are different when it comes to the compilation step. (C# does get compiled to native machine code by the .NET runtime, the GDScript bytecode is likely still running in an optimized interpreter.) There is no excuse why Unity should be taking that long to compile its scripts. Certainly that's not a failure of the language used.

Hot take: nobody should start a project in C++ in 2026.

You're right, thank you

your link is wrong, should be https://github.com/jarrydac/gl_relativity/

This is extremely interesting to see. I'll eventually download it and see what people make

Was shocked to see that, despite valve giving them money, they don't seem to support the deck / steamos.

This feels like it would be a great game for the platform, but no support means it likely doesn't work.

Thou're

You're*

God damn, the devs opening that project like their Indiana Jones. Cobwebs and shit.

No prob!

Full disclosure: I've not used it yet myself, your post here spurred me to do some web searching.

I know there also like uh... Terrain3D, not sure if MTerrain is still sctively developed but I think it is... and then there's uh... shoot I forget the name, but theres a well done addon for making basically linked and tweakable roads.

Granted, thats all geared toward large scale, more outdoors focused maps, but... yeah generally, it is kind of annoying that Godot could do a bit better in the map design/editor department.

There are though a number of different kinds of approaches to 'solving' that problem, some in engine, others kinda lile this Meridian doohickey where it is basically: use another program as the editor and make the pipeline actually work.

Like uh, for rigging character models and such, ReGodotIfy is pretty good for Blender -> Godot for setting up characters, and I think it would well handle just static/dynamic objects as well.

Theres also Gaea, which looks to be pretty solid foundation for a kind of, plug in, 2d procedural map gen type thing... theoretically you could take what it outputs snd then basically treat it as layers of a cake that comprises a 3d map, something like that?

I've been off and on tinkering with a somewhat similar concept... maybr if I ever finish it (to my liking) I'll post it here.

Thanks for sharing. I'll def. check this out.

Not as a standalone tool you say?

https://youtube.com/watch?v=00FtMPPAZog

https://naxela.github.io/Meridian_Web/

Just wanna throw out that I've managed to decompile Source engine maps and then at least semi successfully import them into Godot.

BSPSource ->

GodotVMF ->

Most of the 'brushes' are at least in the right places, lol, sometimes the textures even work correctly!

I imagine this would go a good deal more smoothly if you had the actual proper VMF to start with.

Good question. These programs have worked for a lot of people, but they just didn't click for me. To try and put it into words, they feel like they're one layer of abstraction away from where I need them to be.

Compare it to Paint.net and Photoshop. By the time Photoshop has booted, and loaded the image - I've already done what I want in Paint.net. It's not that Photoshop is bad, or Paint.net is better. It's just for 99% of image editing paint.net is good enough.

There exists a niche for a paint.net of map editors. It would be designed around creating a scene that you could import and finish in blender. Some ideas:

• GLTF Material Managing ( Resolutions, maps, folders, maybe tie-ins to existing programs like PS and Aseprite. )
• CSG To another level of abstraction, but would bake to a mesh with UV's prior to blender import. Think modifiers built around game design and not just 3d modelling.
• Automatically handle naming of objects for importing purposes in Godot or other engines.
• Provide an anchor point for blend file assets, to decrease linking and appending complexity, while also keeping assets separate.
• Extend all this into some form of version control

This all basically exists in some form or another, but not as a standalone tool. I think the idea is neat, but most people get by with all the programs they use just fine. Something like this is really gratuitous and only serves people who struggle. If I ever get good enough I may try making it myself.

What's wrong with using Hammer? I've even used Trenchbroom before in Godot.

I guess the better question is: what do you consider to be sensible for creating video game content?

Thanks for the reply. Clunky would be the word I use. I would say it's perfect for finishing a level, for all the reasons you mentioned. However, I feel like there could be something even simpler. For example, those crazies that use Hammer to make Godot maps, like that but in a more sensible direction.

Making levels in Blender feels a little backwards

Why? That's a perfectly valid way to do it, and it's generally the approach "power users" take. The feature set in an engine's level editor can't really compete with dedicated tools. For example, in Blender you can make use of geometry nodes for creating procedural content. Big (or at least funded) studios typically use Houdini.

For Godot, read through this section of the docs to leaen how to import collisions

Link : https://shakrdev.itch.io/puzzle-of-box

It's not a video it's a picture, thank you for attention me

I'm sorry, the video on the page just had gray boxes. That's why I thought it was a joke. Maybe you need a better presentation because the elements aren't very distinguishable.

No, it's a real . But I'm forgot to add a mute icon, i will add it today