This is excellent news! I have been waiting for Godot (hehe) to release this.
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.
Yeah it is via GDExtension, note most languages do need to build some level of interface to take advantage of it. Rust already has one though I dunno just how clean the 4.0 version is yet (last looked months ago when they openly said it was a work in progress).
Been using Godot the past couple months. It's simply a joy to work with. From the single (relatively) lightweight executable model, to the dogfooding of implementing the UI with the engine itself, to the design of GDScript, etc etc. They definitely implement a lot in-house, but reuse existing software where it makes sense.
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.
How does sharing or not sharing widgets with blender make this “another graphics app reinventing the wheel”? Godot is a game engine, not [just] a graphics app.
But yes, Godot 4 directly translates interfaces with .blend files.
> dogfooding of implementing the UI with the engine itself
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.
Personally as a beginner it's nice to have GDScript built-in. You can literally install Godot as a single executable and everything is self contained which vastly simplifies getting started versus Unreal where you have to install Visual Studio. (I have no experience with Unity but I'm assuming you similarly have to install some C# dependencies.)
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.
Well nobody forces you to use it. You can mix it with other languages, even more so in Godot 4 where languages can be GDExtensions.
You can write one script in GDScript and another in C# if you want.
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.
I'm a heavy-duty C++ programmer professionally, but I find GDScript really nice to work with. It's very well natively supported in the Godot editor, and it inherits the syntactic simplicity of Python that makes it very easy to write small programs in it without having to think much about the details of the language.
Unity-based dev here. This is looking really strong. Impressed with their focus and speed of development.
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.
I've been working with it for a few weeks. Developer but no gamedev background. I love it. Very easy, documentation is extensive, good support on the forums. I will agree with others in this thread who've said they don't like GDScript. For me it's not necessarily a problem with the language (although it's not immediately clear how script execution works - each script is attached to a tree node), but rather that it's another thing to learn. Given that, I've used custom modules (module compiled into engine) and GDExtension (module compiled as a shared library). GDExtension is what I wanted, and I can write a game in C++, and have it build quickly.
They have a looooooong way to go to make it an appropriate tool for large teams, but they are taking all the right steps to reach that hopeful future.
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.
I'm sure it's great for a lot of things. I've just been using Unity for a super long time and it still has a lot more "batteries included" features. But I'm jealous AF about realtime global illumination.
Been using the Godot 4 beta and RC for my latest project. The new features (especially lambdas) in GDscript have been killer. Congratulations to the Godot team.
Probably helps that the core devs are in Argentina IIRC. They don't need to pay themselves as much as developers in the states or western Europe (though hopefully their compensation is still more than adequate).
A bit like LibreOffice, actually - donation-sustained, ecosystem includes commercial companies which use the tech with modifications/extensions, who donate money, new features, bug fixes etc.
Godot has always had native module support; the reason it is not more popular is because it is more or less impossible to support a stable C++ ABI across compilers and operating systems. So you have to build Godot yourself for your dev platform and every platform you ship to. That is what GDExtension and the official C++ bindings solve. Once you set up your builds native modules are totally decent, but personally I find it saps productivity compared to GDScsript, and if you only need it for performance critical code then GDExtension is probably fine (I haven’t used it or GDNative, but I did write native modules before those other options existed).
In my experience, most devs dislike working in C++. (I'm an industry engineer in games. Even the people who like C++ hate C++.)
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.
GDScript is basically Python syntax with some sugar.
* 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 don't doubt that I can learn it. Learning a language is pretty easy.
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.)
>I also can't write my backends and supporting services in GDScript.
I mean technically you can. Godot has a headless mode for servers, etc. I certainly wouldn't pick it as my first choice for all the other reasons you listed though.
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.
Not the OP but I can pitch in that, for me, it is important (and I'd add: efficient) to invest my scarce time in a language that can be used in several contexts
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.
From my experience it's a lot easier to learn another language than to learn a new model of operation or new concepts entirely. And if you'll want to work with Godot, that will likely be the main barrier, and the main thing that will not be transferable to other contexts. The language however, can only make working with the concepts easier or harder. Godot team has decided that having their own language designed for dealing with the concepts of the engine makes it easier to use and results in less work than trying to adapt some existing language to the concepts of the engine. I've dealt with this a couple times, where a language was transformed so much by the context it was used in, it felt like an entirely different language.
On your last point, even just a language like JavaScript (or even Java) has, over long enough periods of time, evolved to accumulate enough new features and common idioms that if you look at typical code from the 90s vs now in those languages, it's not hard to picture entirely different languages. And engineers are expected to just learn the new changes and keep on, much as they're expected to just learn algorithms, libraries, test frameworks, other domain specific frameworks that come and go, database stuff, profiling and other monitoring methods, security concerns, how not to violate the GDPR, ....
But suggest a different language or a DSL for something, no matter how much sense it makes (sometimes getting simple SQL in places is a political struggle, and it's unfortunate when teams develop a "regex expert" even though all the regexes are simple), even one that is already super similar to one they already know like GDScript and so is rather trivial to learn (no one's asking you to learn something on the order of complexity and different-to-others like Haskell here), and devs start putting their foot down and saying "Of all the things, I"m not learning that!"
It's a toy language with almost zero open source library support. And trying to hire someone to work in it and implicitly agree that they don't care about their CV and future hireability is a tough sell.
I've no horse in this race, but want to point out that a lot of the criticism here seems to be from folks who haven't actually worked with GDScript, whether in a production, or even at all.
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?
It is inasmuch as you can modify the engine source if you would like to program your game like that. Most engines maintain a distinction between the engine implementation language (usually C++) and scripting (game implementation) language, and Godot is no different.
It has at the same level as Unreal, via extensions.
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.
If you just want the basics they have a tutorial on site[0], this covers 2d and 3d. The 4.0 Tutorial scene is still pretty barren on youtube, and some of the existing ones may be invalid because of changes that happened over the alphas and betas.
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).
I've been working exclusively with 4.0, but most of tutorials built for 3.5 are pretty easy to carry over. I like HeartBeast's videos, as well as Brando's.
I'm on a team that's currently shipping a Godot 3.5.1 game across Linux, macOS (universal), and Windows.
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.
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.