I just went and read the blog post again (here if you haven't seen it): https://godotengine.org/article/gdscript-progress-report-new-gdscript-now-merged

Now I think I would say I agree that the changes to seem to make the language a bit more confusing. GDScript was very easy to learn and use, so I can see how making it more complex can be an issue. That said, the new syntax is a welcome addition in many cases.

So I think it is an improvement, and if it helps performance, and code completion, and type safety, etc. then I think the change is for the better. And new users don't need to use all the features right away, so I don't think it will be a huge concern.

I would think in this case, making GDscript a little more complex will be worth it if the performance improvements are as large as advertised.

I have been tinkering with GDscript in a recent build of version 4. Many of the tentpole features like the getNode() function and signals are still there. I do agree it could be more complex for newcomers, but I would think visual scripting removes some of the pressure in keeping GDscript as Python-like as possible (even to the point of sacrificing performance). Now I don't think the goal should be C++ or even C# levels of complexity though.

Right. If it gets too complex, then why not just use C++ or C# to begin with.

@cybereality said: Right. If it gets too complex, then why not just use C++ or C# to begin with.

And that is kinda one of my points. It's difficult to keep in mind most of us are prepared to deal with this minor complexity bump. I still feel it will dissuade young and "brand new" to game dev users...and not to kick a dead horse but documentation has a lot to be desired. I've already updated most code(in a new separate project) but there are still a few errors I simply cannot find documentation/reference for..like the linecasting.

@duane said: So far, the breaking differences between 3 and 4 seem fairly easy to fix

But how easy it is doesn't say how long it takes. Of course I'd want to continue developing my Godot 3 game in Godot 4, but the more GDScript 3 code it has, the longer it takes to translate it into GDScript 4.

If Godot 4 would remove GDScript 3 entirely, it'd become increasingly more risky to upgrade to Godot 4, the more GDScript 3 code the game has. However, if Godot 4 keeps GDScript 3 while adding GDScript 4, everyone has an opportunity to transition smoothly and prepare for a possible removal of GDScript 3 in Godot 5.

I suspect that most of the breaking changes could be automated away with a bit of scripting. However, I'm not sure why anyone feels they have to upgrade. I'm running multiple versions of godot now. If I had a big investment in a game and didn't feel that making all the necessary fixes for v4 was worthwhile, I could keep using v3 for a long time before library changes made it impossible (which might never be the case for some platforms).

Keeping multiple versions of gdscript running sounds like a development/documentation nightmare. I don't know how the developers manage to keep three languages supported, let alone more. Even if there were people willing to go that extra mile, I'd rather they devoted their time to other things.

Yeah, having 2 versions of the same language both running would be crazy. I hope they don't do that. Even with the changes, they are not drastic. What would it take, a few days at most to port a game? Seems like it would be worth the effort considering the other benefits Godot 4 will bring.

These are really great counter-arguments:

Now I know that Running 2 versions of the same language will break much more things than breaking the code by replacing the language with a newer version.

Thanks very much! This is very helpful, Now I hope that the Godot Developers read this discussion.

8 days later

The key part for me and my wife to use Godot over Unreal or Unity was to NOT have to work with C++ or C#. GDScript might be slower, but we don't care for that. If performance is an issue and you are fond or C++ why do you use Godot anyway? For the selftought game dev GDScript is one of the key values to use Godot. For the pro dev there are lots of other options. If they change GDScript to something different and more complex, they might loose quite some contributers (not only cashwise) I will look it up and follow it for some time. If I don't like it ... well, I only pay for things I like. The current GDScript is nice. Don't change it too much. If you need more performance go play with C. It's already there.

@Goemoe said: If performance is an issue and you are fond or C++ why do you use Godot anyway? Those who really like C++ and want to use godot probably do use C++ either on the source level or as script via the GDNative API.

@Goemoe said: For the selftought game dev GDScript is one of the key values to use Godot. For the pro dev there are lots of other options. If they change GDScript to something different and more complex, they might loose quite some contributers (not only cashwise) I will look it up and follow it for some time. If I don't like it ... well, I only pay for things I like. The current GDScript is nice. Don't change it too much. If you need more performance go play with C. It's already there.

While it might become a bit more complex it isn't that much, really. For someone with zero programming experience it might seem a bigger change than it really is. Though there is an iterative trend towards more complexity over multiple releases to be sure.

Performance is the main complaint that users of GDScript have since most want to use it also for more complex things beyond just what it originally was intended for. I.E writing complex new nodes implementing whole new functionality rather than just scripting gameplay logic alone and implementing and contributing the more complex nodes to the source in C++.

The very first project I tried in godot was a port of a little game I'd made in love2d. It had a lot of entities that had to find paths to other entities. In lua, it was trivial. In gdscript, it was unacceptably slow. I tried godot's built-in pathfinding, but it was even slower for this case. I got around it, but it took some ingenuity. I'm not sure I would have found a solution as a new programmer.

I've worked in C/C++ before, but I don't like C-like languages. I get a lot more done with python and lua, so C# is not an appealing option to me.

Talking about this has really got me eager to see the new changes. Unfortunately, the master branch has still got so many bugs (on my system, at least), that I can't make much progress. So far, I haven't had to change much of the code in the project I'm trying to update (but I haven't got it to run yet, either).