I was taking 4.0 out for a spin today... it feels like all the simplicity of using a python type language feels to be all but removed. At this point it's almost easier to go GDnative than than to use the upcoming GDscript "improvements". I can deal with it, but, I am concerned..people who see godot as a friendly environment(especially new developers with little to no coding experience) will simply shrug it off and go straight to unreal or unity. I have to be honest. I would rather code in unity than to use the new features in gdscript. I know why they are there, but I feel it hinders more than it helps. AGAIN, I cannot stress this enough, it will scare off new users.(new to coding/scripting) because the visual scripting is not on the same level...not even the ui for nodes is comfortable/legible when zooming in/out.

I hope it's clear this is just my opinion. I do however see it as a problem.

Out of curiosity, what changes do you feel the new GDScript has made that makes it not as beginner friendly? I haven't really used the new GDScript beyond porting a couple scripts I needed for testing C++ code. I haven't been keeping up with the changes as much as I probably should...

One of the things I'm on the fence about with the new GDScript is the new annotation syntax. It does make it easier to tell what is an annotation keyword (@tool and @export instead of tool and export), but from a frequent-use perspective, I haven't decided if I like it or not. I guess I'll just have to play around with it some more to find out :sweat_smile: I like the ability to export almost any Godot type to the editor though, and if I remember reading correctly, there are plans to allow for custom annotations, which could be interesting? I'm not positive what the use case there would be though. I think there is also support for exporting custom, GDScript resources, which was something I've been looking forward to for awhile now. Outside of annotations though, the only other thing I know that is a fairly big change is the use of super to call overridden/base functions, and how these functions are no loner called automatically. While I think it's a little more code to manage and handle, overall I think its good because it opens up the door to more custom, GDScript driven behavior.

4.0 looks good to me, and I'm technically an artist not a programmer. With that said I haven't done any serious testing of 4.0 though so I'm judging it 'on the paper' so to speak.

yes, the @onready etc...is a small thing...but you cant directly assign some data types to variables..

var targ = null

if targ: e.g. (private) var x = targ.get_script().get_script_properties()

This spits out a null reference err, because I define targ as null at the beginning so that I can assign an object to null via linecast.

so I cast it... var targ : StaticBody3D(casting everything)#at this point it's nearly c# and I wonder if it's better to just drop gdscript and adopt c#

but a lot of terminology has changed...linecast dict result...was returning "result.collider" or "result.point"..now I have no idea... I will figure this out... like.. space_state = get_world_3d().direct_space_state Adding the "3d" / "2d" doesn't work for everything though :(

I digress...I don't think this is good for new users...but I could be wrong...there is going to be a learning curve regardless. The only change I do agree with is adding the 3D and 2D monikers....

I know this sounds like my own personal issues...they are issues for sure...not by any means out of my reach..but once more for new comers and for people who are learning on youtube or some other older content...it's going to be a nightmare.

Oh, I get what you are saying. Yeah, polymorphism is not much more limited in GDScript, since it appears that GDScript is typed by default. There definitely is a push towards typed GDScript and casting now in the new GDScript though, which I agree does move away from the Python-like roots of GDScript. It's a lot less of a dynamic language now, for better or for worse. I think from a performance perspective, it's definitely a good change, but I do agree that its going to be painful for awhile as everyone gets used to the new syntax and workflow.

Hopefully duck-typing will stick around though as a setting or something though, for migration purposes if nothing else.

@justinbarrett said: I know this sounds like my own personal issues...they are issues for sure...not by any means out of my reach..but once more for new comers and for people who are learning on youtube or some other older content...it's going to be a nightmare.

I don't think it sounds like personal issues. It's frustrating to have to migrate code forward and make big changes, and the new GDScript does have some rather major fundamental changes. I've migrated Godot 2 projects to Godot 3, and it seems likely that Godot 3 projects will need migration work before they work in Godot 4.0. I think there are plans for a migration tool to make this process easier, but I have no idea if updating GDScript scripts is going to be part of the migration tool.

It definitely doesn't hurt to discuss this type of thing, especially since it affects existing projects and old Godot content. Feedback on big changes is always good, as it can help developers find issues, fix bugs, and shape the development direction going forward.

I don't know if there is somewhere for leaving feedback on the new GDScript though, I did a quick Google search and didn't find anything. @vnen, @Calinou - Is there a discussion/thread/topic for leaving feedback on the new GDScript?

I haven't tried the new GDScript, but I wonder if it just has a learning curve and you're not used to it. For example, if people new to Godot start with 4.0 (without previous experience) would it still be confusing?

if you treat it more like c/c# it's fine. I also wondered that same thing...learn it correctly the first time is it less/more difficult than unlearning the old way...???

GDScript 4 sounds great as an option, but fatal as a replacement. I hope that GDScript 4 will be a separate language option from the current GDScript 3. The file extension for Standalone GDScript 4 scripts could be .g4 as suppose to .gd for GDScript 3.

It's really Really scary that, if GDScript 4 were to just Replace GDScript 3, every Godot Game so far would break in the new Godot 4. I'm reassured because FOSS like Godot is made by the people for the people, so there's a high possibility that the community at large will interfere.

Godot with GDScript 4 but no GDScript 3 could be a Download Option for additional portability (because portability and fast opening times are among Godot's advantages). But Godot with Both GDScript languages should still be an Option, in the same way that Godot with C# and Godot without C# are Two Available download options.

Godot doesn't seem like a real word anymore after I spellchecked this comment. I hope that this effect only lasts for 0 hours and 10 minutes and 1 second and 30 milliseconds.

To be fair, in any studio production, games don't typically switch engines like that, a project in production usually sticks to a major version and only gets the maintenance updates. Usually. The more recent 'live service' games that have a tendency to go through major reworks while already live might well be an exception to this.

So far, the breaking differences between 3 and 4 seem fairly easy to fix, and I'm behind them if they'll lead to better performance. I really don't think new programmers are even going to notice the language changes. I suspect that learning the api is more of a challenge.

The one thing that is likely to turn new programmers off of gdscript is when they read that it's so much slower than other languages. At that point, most will feel that they're wasting their time learning it, even as a stepping stone, and they'll turn to faster languages.

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++.