The new Vulkan backend is exciting for 3D projects and I am excited to try to dig into the new 2d tilemapping after work.
As well, gotta love experimental Rust support:
> With Godot 4, we introduce a new system called GDExtension. By design, it takes the best parts of creating GDNative extensions and writing custom engine modules using high performance languages such as C, C++ or Rust.
Anyhoo, kudos to the team for shipping. Building a generic game engine for the global audience is a massive undertaking.
Every once in a while I use a program where I just feel the authors think about software similarly to the way I do. Godot is one of those.
But yes, Godot 4 directly translates interfaces with .blend files.
It's been pretty common in the past for every pro graphics app to build its own x-platform GUI widgets library. Was hoping this could come to an end, as it is a waste of time.
They should have used C#.
Their motivations in creating GDScript are explained here: https://docs.godotengine.org/en/stable/about/faq.html#what-w...
As a programming language it's pretty reasonable. The built-in editor has auto completion and documentation, you can resume from errors. The syntax is basically Python with optional type annotations. Comparing the Godot vs C# examples in the documentation makes me shudder at how much more verbose C# is in comparison.
As others have pointed out you can use C# if you want to. They provide a separate download for it.
I personally like to use it. It's not perfect but it's a language that's tailored for the task it's doing, namely driving the high level logic of a game engine.
And most importantly it's beginner friendly, so it's pretty nice for people who want to get into programming.
They did...
If I were putting together a small-ish team with 1-3 people today, I'd be more likely to consider jumping onto Godot vs Unity. Godot is closing the gap.
The founders creating a commercial arm of the engine is critical. As a real studio, you need to be able to support consoles and you need to be able to pay someone money to fix broken shit in the engine when you have a scary deadline looming.
Does Unity not have this? I thought Unity was much more advanced in graphics than Godot, even accounting for the 4.0 release.
How is this sustainable through donations alone?
https://www.numbeo.com/cost-of-living/country_result.jsp?cou...
Maintaining C++ support is expensive for an engine, just like maintaining any language binding. IMO, they should optimize for the most approachable/developer ergonomic language, which C++ definitely is not.
That said, I strongly disagree with their decision to simply build their own language. I think there are many languages that already exist that make better candidates for game development either because they are well known, well supported, or easily portable.
* Well known: Python is well known. GDScript is thus familiar. * Well supported: it's a first class citizen in Godot, that's all that matters * Easily portable: portable to what? it runs on the Godot engine. That's all the portability it needs.
I think they built their own language because of the integration with their Editor. It's not Lua or JavaScript or Python, but it works well enough for Godot in my experience.
I doubt that I'll have rich tooling and libraries to draw from when I need them.
If I build a game in C#, for instance, I have editors that can lint my code, perform intellisense, automate test generation, and a rich set of libraries I can draw from. If I don't want to write my own Hierarchical Task Network planner, I can use FluidHTN. Likewise, I can pull out my code from my project and modularize it for other engines/games -- maybe I've got a great state machine implementation or something I want to share. GDScript limits my reach.
The knowledge is also not particularly useful outside of working with Godot. Picking up C# from working with Unity, for example, translates to other domains easily if I want to change careers.
I also can't write my backends and supporting services in GDScript. If I wanted to , I could make my entire codebase in C# for both front end and back end code, simplifying my tooling and knowledge needs.
I don't want to be too down on it. I'm sure there are ways that it would save time. My use cases are much more about setting a high bar for ergonomics and engineering excellence for larger projects. I think that in my case, they've provided the Extensions and C# support route. (Though it sounds like getting those to work on all platforms is non-trivial today.)
In my case the main issue with GDScript is the tooling, or lack of thereof. No symbol aware rename, no go to definition/usages, poor autocomplete, cryptic errors. Also static typing that's kinda but not entirely there, which exacerbates the tooling issues.
Good tooling is an enormous undertaking, so the way I see it, GDScript is forever doomed to feel like someone's impressive hobby project.
e.g.: Using python, I can do games, scientific/bio work, math, web backends etc. The same time investment in GDScript will only net me experience with GDScript which right now only exists in Godot.
It's likely due to being cross platform. What's happening is they're bundling the scripts and assets with a pre-built binary. If you're writing all c++ you're likely going to link in the engine instead, not the paradigm they support. That said I know you can extend the game engine, and there is some kind of plugin support for building native code, but you've got to do compile time support yourself? It even supports Rust now apparently?
Turns out most people doing the actual scripting don't use C or C++, rather tooling designed for game designers, level editors, scripting developers,....
Professional studios rarelly do everything in C++ for the last 20 years.
I'm talking introductory materials and an overview of the bigger ideas, not (yet) the nuanced details.
GDQuest is working on updating his content to 4.0 but even with the half off discount that stuff may be a bit pricey if you aren't sure you want to dive into the Godot world (his full compilation of Tutorials was like $379 before discount and individual ones are like $150 before discount).
[1] https://www.youtube.com/channel/UCrHQNOyU1q6BFEfkNq2CYMA [2] https://www.youtube.com/@BrannoDev
It's very easy to create simple toys with Godot, because it has a Python-like scripting and good UI.
After sorting out a couple minor snags in the build process (particularly around getting cross-compilation to work on Linux in GitHub Actions, and library validation entitlements for code signing), the finished builds work wonderfully on the M1 machines we've tested with.
