I absolutely love this format, especially for more "professional" tips. I have no problem using documentation or searching the web for a solution to a problem, but it can be kind of hard to find "the best" or "the simplest" way to do something. Getting a short introduction to features I did not know about then enables me to dig further and use them for my game. Great stuff, long story short: more of this please! On a related note: I am still waiting for a good tutorial explaining godots UI system, I just cannot get around how anchors work or should be used. I would love if you could someday make a tutorial about that. :)
Anchors are used to resize the child Control when the parent Control resizes. The position and size of a Control is determined by its anchors and margins from those anchors. I’ll use (⬆, ➡, ⬇, ⬅) order for this explanation. If the anchors are (0, 0, 0, 0), the control is pinned to the top left, since the reference is pinned to the top left corner. If the anchors are (1, 1, 1, 1), the control is pinned to the bottom right. If the anchors are (0, 0, 1, 1), the control is made fullscreen, possibly with a margin from the edges. It resizes when you resize the parent. Anchors can be fractional too. If the anchors are (0.5, 0.5, 0.5, 0.5), the Control stays the same size and pinned to the center of the screen. You can mix and match too. To add a toolbar at the center top of the screen with a constant height, but make it span the whole width of the screen, you can make the anchors (0, 1, 0, 0).
Custom iterators looks interesting, though I didn't fully understood it yet. Gonna have to give it a try. Btw I like this new style of editing, feels very engaging to watch.
These are some really amazing tips! Although I personally disagree with the statement of "Only optimize something if it starts to slow down your game" because there is always room for optimization and improvement. Object Pooling not only counters having to re-instantiate objects but also dynamic memory which is often painful thing within hardware and operating systems. Having a pre-determined range of memory will greatly increase performance on also slower devices which do not benefit from memory units running at a few thousands of Mhz. These are some really solid tips though!
The reason we say "Only optimize something if it starts to slow down your game" is because when you make videos online like that, most people watching aren't necessarily pros or doing commercial games. The thing people do the most is optimizing useless things, without measurements. I have countless examples from students, like putting ifs everywhere thinking that's faster than constantly running calculations and other similar assumptions. A team of pro devs making a commercial title should know where to pool, use built-in pooled array types, enabler nodes, or direct calls to the servers. All of that makes your code more complex, so you have to know when to do it - for that, we teach people to always test their game against their slowest target hardware. As a result, looking for slowdowns is a good rule of thumb to find really valuable optimizations.
I don't know if this is different in Game Development, but in programming the general rule of thumb is to optimize _at the end!_ Otherwise you end up getting lost in weird workarounds and clever code spaghetti, that IS faster, but also completely unreadable.
Thought about that for this video, but I wasn't sure it was good to recommend saving with resources. I need more time to experiment with them: resources still have some quirks with how they run their init function and bake the values in the file that can lead to unexpected issues. You can also put code in there which you might not want to let the players do. Same security issue as .tscn, players could perhaps share malicious save files.
Im so confused. Ive been using Godot for so long didnt realize relative path loading from a scripts directory was a thing🤯. Awesome video. Still learning even more everyday 😅
Great tips! I was surprised with the saving system. I will have to deal with save/ load at some point and I'm happy I don't have to deal with json files. Thank you
Such a nice tutorial, as always. Just one little details, ind the Save part you didn't mentioned that SAVE_FILE_PATH as a constant to the path where the file must be saved. But I totally understood here, thanks for this solution.
Awesome video. I just didn't quite get the last tip. How was a custom iterator used in drawing the ships? What was problematic to do it without a custom iterator exactly?
YES! WE NEED MORE ADVANCED VIDEOS ON GODOT/GDS! I have a pretty strong feeling that MOST of videos you find on Godot are introductions and such. We already have a pretty strong learning base but not much complex or advanced stuff.
Waiting for godot 4 courses, this time please create something which teaches about graphics in general like mathe, gpu optimisation techniques, also keep posting good references books, research papers etc. That can be great help for students.
I'm confused, custom iterator is interesting but its unclear how to use it, how it works... you are not calling in any of the iterator code that video shows. is it a built in function that can be overwritten, when you use 'for point in room' iterator for example? Or it's just an iterator logic that is simply that and you use it by calling another custom iteration loop class? is there any documentation for this available ?
Custom iterators allow to put custom classes in for loops. I will give you an example. Even though I didn't do that in GDScript, the idea is the same. I needed to make my own type of array and so I made a custom class which suited my needs. But there was an inconvenience I stumbled upon: how do I plug my custom class in a for loop? How will the loop know what to yield from my variable? And so I found out about custom iterators. Basically with their help you can tell your class how to behave when used in a for loop. In my case I told my class to yield all the stored elements one by one. But you are not really limited to just that generic use. You can do pretty much anything. Say you have a Room.gd class which has a custom iterator which returns all of the data associated with one room (like position, content in it, etc.). You can then plug your room instance variable in a for loop and get all the data that way. Hope my answer clears it for you.
im glad theres videos like this, i heard the usual godot beginner tutorials are simple and self-explanatory but at the cost of not being very efficient, so im trying to read up on this stuff before i work on my first game
I assumed that using a Vector for a dictionary key would use the reference ID of the vector but no, it is like you say using the value. I am not sure if this is a good idea since, should the Vector value change, then you just lost sync.
"1. You don'[t need pooling." Sorry I failed to understand the point that there is no pooling required. Can someone explain? Sounded like he was saying object instantiation isn't very impactful so just try not to instantiate too many objects. That doesn't make sense to me, in that example it seems like pooling is necessary if you have 2000 fire rate.
1. *In most games* made with Godot, you don't need to worry about pooling. In most projects, people instantiate few objects and never get close to 2000 per second - or even more than a handful per second. The main reason people use pooling is in garbage-collected languages like C# as instantiating and deleting objects does not free them from memory instantly. Instead, the garbage collector registers them and at a later time, it runs a complex algorithm to clean up the memory, typically freezing your game. GDScript isn't a garbage-collected language, so it doesn't have this problem. You can use pooling if you instantiate objects a lot in Godot, of course. There's always a performance gain. But you want to be sure it makes a difference first.
#1 There are thousands of bullet instances being reused inside the pool, that is to say, the array. #2 then you do check what you save before saving, you can validate the data you add to your dictionary before calling var2str #3 thanks!
If you're asking if you could keep track of loading progress with preload, then I think so, yes. The main difference between preload and load is when the loading happens: with preload, it's when the compiler reads a script (for example, when loading a scene, the compiler reads its script files), while with load it's when you call the function.
I feel like custom iterator tip was too short compared to other tips, I didn't understand what is it for or what are its advantages over for and while ?
Making an object an iterator allows you to use "for" on it, which you otherwise can't. As to when you do it... well, in the example game in the video, we created a room object. We made it a custom iterator such that if you use the for keyword on it, you iterate over all the grid cells inside the room, regardless of its size or the data structure behind it. The iterator returns each grid cell inside the room from top-left to bottom-right.
@@Gdquest Just looking at what's in the video, it's not clear at all how the CustomIterator class is being used. I saw nothing that suggested it was connected to any other object in any way except the visual example of it working. How is it working with your room object? Is it "included" or "loaded" or what? It's confusing. It's possible I'm missing something obvious, but it's just not coming clear to me, and I'll bet for some of the same reasons it confused Krzysztof Swierzy. Though, I am only speaking for myself. I have come up with 2 or 3 different ways of doing what you showed happening in your example, and none of them use a CustomIterator class. Instead, I have defined a dictionary with Vector2() keys as x, y indices and Vector2() values as the coordinates for the grid squares. The way you do it with CustomIterator seems less error prone, so I'd love to see how it actually works in detail.
As many have commented I also don't fully understand how the custom itrators are linked to the rooms. Do the rooms need to be created as type CustomIterator? What if I want my rooms to be of type Room with their own logic, then I need to add those 4 functions in my Room type? Also in this example the point is a vector2, how does GDscript knows what points are in the Rooms. We are really missing information to understand the example.
Hi. I downloaded your guide, but I have a question. I found out that KinematicBody2D supports multiple CollisionShape2Ds. Is it possible to assign different collision layers for different CollisionShape2Ds? I can do this by placing another KinematicBody2D inside the KinematicBody2D, but it seems inconvenient to me ...
Looking at the actual output of var2str, that just sounds like JSON with extra steps. The advantage over writing JSON yourself is obvious, but how is this not just a convenient way to convert objects to JSON (which btw JSON is meant for)?
I know this is a bit old I'm wondering: in the non-pooling bullet example how are those bullets being removed once they are off screen? I'm assuming they aren't just accumulating indefinitely, does bullet.tscn maybe have a timer that calls queue_free or remove_child or something?
what's with the walrus := operator everywhere ? Is it used same as Python ? Edit: So it's not same as in Python at all. It's inferred type in GDScript.
I'm new to Godot, but by mastering these pro tips first, I'll be able to bypass all the beginner tutorials and am likely to release the first of many critically acclaimed games in a matter of days.
1st *says* you don't need pooling while showing an example of exactly why you *may* need pooling? smh... Nobody looking for "Pro Tips" is going to think they need pooling and likely won't even know what it is until they encounter the very reason that they need it, which you just showcased.
"JSON can only store floats and no vectors"...sorry but that is WRONG...JSON can also store ARRAYs...and what is an ARRAY of 3 floats other than a vector ? ;)
It's compared to Godot's native formats. Godot's formats directly serialize and load all built-in engine types, including Vector2, Vector3, Transform, etc. So you'd better use them instead of JSON except for web queries and interchange exports.
Best GDScript Tip: Don‘t use it and go for C# or one of the GDNative languages instead. It‘s a bad path to choose. They should just remove it like other engines have done with their engine-specific scripting languages.
the unreal engine ships with a scripting visual language most users work with (blueprints) and the company is working on a scripting language like GDScript.
@@Gdquest And that makes GDScript a better choice than C# or C++ because …? I don‘t know what Epic is doing behind the scenes, but they droped Unreal Script in favor of C++ when they transitioned from UE3 to UE4 for the very reasons why i think GDScript is bad.
Epic is re-adding a scripting language to future releases of the unreal engine yes. They didn't remove high level languages in unreal 3 and 4: they invested in visual programming. And now they're re-adding something like the unreal script they used to have on top of that. GDScript is a front end, domain specific language. Its whole point is to work within a specific domain, gameplay and tool programming inside Godot. You're supposed to use it for gameplay programming tasks, calling engine methods etc., as it's very efficient at that. And use a different language, e.g. c++, for anything that requires more flexibility or performance. It's just so much faster to write and iterate over GDScript for gameplay code - fairly easy to maintain too if you use it to that end. And pretty quick to port to C++ in the infrequent cases you realize you need to turn some front end code.into backend stuff. Of course you're welcome to use whatever you prefer and works for you.
I absolutely love this format, especially for more "professional" tips. I have no problem using documentation or searching the web for a solution to a problem, but it can be kind of hard to find "the best" or "the simplest" way to do something. Getting a short introduction to features I did not know about then enables me to dig further and use them for my game. Great stuff, long story short: more of this please!
On a related note: I am still waiting for a good tutorial explaining godots UI system, I just cannot get around how anchors work or should be used. I would love if you could someday make a tutorial about that. :)
Anchors are used to resize the child Control when the parent Control resizes. The position and size of a Control is determined by its anchors and margins from those anchors.
I’ll use (⬆, ➡, ⬇, ⬅) order for this explanation.
If the anchors are (0, 0, 0, 0), the control is pinned to the top left, since the reference is pinned to the top left corner.
If the anchors are (1, 1, 1, 1), the control is pinned to the bottom right.
If the anchors are (0, 0, 1, 1), the control is made fullscreen, possibly with a margin from the edges. It resizes when you resize the parent.
Anchors can be fractional too. If the anchors are (0.5, 0.5, 0.5, 0.5), the Control stays the same size and pinned to the center of the screen.
You can mix and match too. To add a toolbar at the center top of the screen with a constant height, but make it span the whole width of the screen, you can make the anchors (0, 1, 0, 0).
Happy to see some free series coming back :P
Great video!! For some reason I love when you say the word: "Here"
I'm really liking this new editing style and commetary. You seem a bit more confident
Custom iterators looks interesting, though I didn't fully understood it yet. Gonna have to give it a try.
Btw I like this new style of editing, feels very engaging to watch.
These are some really amazing tips! Although I personally disagree with the statement of "Only optimize something if it starts to slow down your game" because there is always room for optimization and improvement. Object Pooling not only counters having to re-instantiate objects but also dynamic memory which is often painful thing within hardware and operating systems. Having a pre-determined range of memory will greatly increase performance on also slower devices which do not benefit from memory units running at a few thousands of Mhz.
These are some really solid tips though!
The reason we say "Only optimize something if it starts to slow down your game" is because when you make videos online like that, most people watching aren't necessarily pros or doing commercial games. The thing people do the most is optimizing useless things, without measurements. I have countless examples from students, like putting ifs everywhere thinking that's faster than constantly running calculations and other similar assumptions.
A team of pro devs making a commercial title should know where to pool, use built-in pooled array types, enabler nodes, or direct calls to the servers. All of that makes your code more complex, so you have to know when to do it - for that, we teach people to always test their game against their slowest target hardware. As a result, looking for slowdowns is a good rule of thumb to find really valuable optimizations.
@@Gdquest in that case I can see where you're coming from! Didn't even think of that, silly me. Great video as always and keep up the amazing work!
I don't know if this is different in Game Development, but in programming the general rule of thumb is to optimize _at the end!_ Otherwise you end up getting lost in weird workarounds and clever code spaghetti, that IS faster, but also completely unreadable.
Bookmarked! Excellent GDScript tips that I'll begin incorporating into my future projects.
It's probably even simpler to implement saving and loading with custom resource class and resource saver/loader.
Thought about that for this video, but I wasn't sure it was good to recommend saving with resources. I need more time to experiment with them: resources still have some quirks with how they run their init function and bake the values in the file that can lead to unexpected issues. You can also put code in there which you might not want to let the players do. Same security issue as .tscn, players could perhaps share malicious save files.
@@Gdquest I like how you gave a tip that will help so many people with a few lines of code vs something complicated for the video.
Im so confused. Ive been using Godot for so long didnt realize relative path loading from a scripts directory was a thing🤯. Awesome video. Still learning even more everyday 😅
I got so used to exporting a PackedScene variable to get its full path.
Great tips! I was surprised with the saving system. I will have to deal with save/ load at some point and I'm happy I don't have to deal with json files. Thank you
Can you share the "tactics game movement" example?
Awesome tips!! Thank you GDquest.
Great tips! Thanks for the great video!
Using a dictionary for tile based games is genius! And the var2string/string2var saving is the best
I wish I had known about that Save/Load tip so long ago. I spent so much time dealing with JSON when I could have just used this tip. Thanks so much!!
Such a nice tutorial, as always. Just one little details, ind the Save part you didn't mentioned that SAVE_FILE_PATH as a constant to the path where the file must be saved. But I totally understood here, thanks for this solution.
i really love you guys, seriously
more of this please this was very helpful
The save/load thing was just awesome. - Yann
Went through your Godot course on Udemy, you are a great teacher, thanks!
I enjoyed this, Thanks for sharing!
Awesome video.
I just didn't quite get the last tip. How was a custom iterator used in drawing the ships? What was problematic to do it without a custom iterator exactly?
9:45 That "i" got me.
Thank you! Wow, this was extremely helpful.
every day is nice to learn something new :)
Nice video!
This is great. I love the more advanced or pro tips!
10:54 Bro just reinvented Faster than Light
Great and informative video !
Super good vieo format! More please!
Love this content, more please.
Cool video, I consider myself a pretty good godot game dev but I had no idea about preloading relative paths, will be using that in my next project.
Amazing video, this is very useful!
Hope to see more godot video in future
2:37 hard disagree with this. You should strive to make fast code to begin with. Otherwise you'll lose performance everywhere and it adds up to a lot
great video bro keep it on, i'm learning new things each time. Is there a way to get relative node path automatically each time a scene is changed?
I like this video format. Less cookbook and more focused tips about useful features.
wow that was really cool 👍
parse and stringify but w/o json - haha too ez - thanks Nathan!
YES!
WE NEED MORE ADVANCED VIDEOS ON GODOT/GDS!
I have a pretty strong feeling that MOST of videos you find on Godot are introductions and such.
We already have a pretty strong learning base but not much complex or advanced stuff.
Waiting for godot 4 courses, this time please create something which teaches about graphics in general like mathe, gpu optimisation techniques, also keep posting good references books, research papers etc. That can be great help for students.
So helpful! Thank you very much!!
Regarding the save files, one could also use ConfigFile (also supports sections).
nice i didn't know about custom iterators
I'm confused, custom iterator is interesting but its unclear how to use it, how it works...
you are not calling in any of the iterator code that video shows. is it a built in function that can be overwritten, when you use 'for point in room' iterator for example?
Or it's just an iterator logic that is simply that and you use it by calling another custom iteration loop class? is there any documentation for this available ?
you can checkout the documentation here :
docs.godotengine.org/en/stable/getting_started/scripting/gdscript/gdscript_advanced.html#custom-iterators
Custom iterators allow to put custom classes in for loops. I will give you an example. Even though I didn't do that in GDScript, the idea is the same. I needed to make my own type of array and so I made a custom class which suited my needs. But there was an inconvenience I stumbled upon: how do I plug my custom class in a for loop? How will the loop know what to yield from my variable? And so I found out about custom iterators. Basically with their help you can tell your class how to behave when used in a for loop. In my case I told my class to yield all the stored elements one by one. But you are not really limited to just that generic use. You can do pretty much anything. Say you have a Room.gd class which has a custom iterator which returns all of the data associated with one room (like position, content in it, etc.). You can then plug your room instance variable in a for loop and get all the data that way. Hope my answer clears it for you.
Amazing tips
I knew you could save Resources in GDScript, but the str2var is way simpler for a lot of things, gotta keep that in mind!
Wow that object pooling thing was awesome!
Very nice! See you later iterator
11:45 why is there := operator used near the variables, if there is no expression after it just a single value?
im glad theres videos like this, i heard the usual godot beginner tutorials are simple and self-explanatory but at the cost of not being very efficient, so im trying to read up on this stuff before i work on my first game
Cool, cool, please continue :-)
Nice!
Thank you
I assumed that using a Vector for a dictionary key would use the reference ID of the vector but no, it is like you say using the value. I am not sure if this is a good idea since, should the Vector value change, then you just lost sync.
"1. You don'[t need pooling."
Sorry I failed to understand the point that there is no pooling required. Can someone explain?
Sounded like he was saying object instantiation isn't very impactful so just try not to instantiate too many objects.
That doesn't make sense to me, in that example it seems like pooling is necessary if you have 2000 fire rate.
1. *In most games* made with Godot, you don't need to worry about pooling. In most projects, people instantiate few objects and never get close to 2000 per second - or even more than a handful per second.
The main reason people use pooling is in garbage-collected languages like C# as instantiating and deleting objects does not free them from memory instantly. Instead, the garbage collector registers them and at a later time, it runs a complex algorithm to clean up the memory, typically freezing your game.
GDScript isn't a garbage-collected language, so it doesn't have this problem.
You can use pooling if you instantiate objects a lot in Godot, of course. There's always a performance gain. But you want to be sure it makes a difference first.
Having a beginners tutorial how the pathfinding and arrowdrawing works would be nice
Great video
thats great content! is there any step by step tutorial on how to save/load files this way?
Finally
Goodbye, JSON.
Hello
Awesome
Thanks. cool tips
#1 If you are going to only use 1 sprite, Why make to an array?
#2 But If I want to check what I save?
#3 Also, you can use preload("dir").instance()
#1 There are thousands of bullet instances being reused inside the pool, that is to say, the array.
#2 then you do check what you save before saving, you can validate the data you add to your dictionary before calling var2str
#3 thanks!
Superb video :) maybe the advantages of preload was not too clear though; can we still make a progress bar with preload?
If you're asking if you could keep track of loading progress with preload, then I think so, yes. The main difference between preload and load is when the loading happens: with preload, it's when the compiler reads a script (for example, when loading a scene, the compiler reads its script files), while with load it's when you call the function.
Nice
I feel like custom iterator tip was too short compared to other tips, I didn't understand what is it for or what are its advantages over for and while ?
Making an object an iterator allows you to use "for" on it, which you otherwise can't. As to when you do it... well, in the example game in the video, we created a room object. We made it a custom iterator such that if you use the for keyword on it, you iterate over all the grid cells inside the room, regardless of its size or the data structure behind it. The iterator returns each grid cell inside the room from top-left to bottom-right.
@@Gdquest Just looking at what's in the video, it's not clear at all how the CustomIterator class is being used. I saw nothing that suggested it was connected to any other object in any way except the visual example of it working. How is it working with your room object? Is it "included" or "loaded" or what? It's confusing. It's possible I'm missing something obvious, but it's just not coming clear to me, and I'll bet for some of the same reasons it confused Krzysztof Swierzy. Though, I am only speaking for myself.
I have come up with 2 or 3 different ways of doing what you showed happening in your example, and none of them use a CustomIterator class. Instead, I have defined a dictionary with Vector2() keys as x, y indices and Vector2() values as the coordinates for the grid squares. The way you do it with CustomIterator seems less error prone, so I'd love to see how it actually works in detail.
niceee ;D
As many have commented I also don't fully understand how the custom itrators are linked to the rooms. Do the rooms need to be created as type CustomIterator? What if I want my rooms to be of type Room with their own logic, then I need to add those 4 functions in my Room type? Also in this example the point is a vector2, how does GDscript knows what points are in the Rooms. We are really missing information to understand the example.
Do this video again once Godot 4 comes out
Aside from some little syntax changes, I think this one should be about the same.
So for the Tip#1, there's no need for gdscript to do object pooling if I'm not mistaken?
Can be even simpler savegames. If godot has a node for that.
Hi. I downloaded your guide, but I have a question. I found out that KinematicBody2D supports multiple CollisionShape2Ds. Is it possible to assign different collision layers for different CollisionShape2Ds?
I can do this by placing another KinematicBody2D inside the KinematicBody2D, but it seems inconvenient to me ...
like it
Looking at the actual output of var2str, that just sounds like JSON with extra steps. The advantage over writing JSON yourself is obvious, but how is this not just a convenient way to convert objects to JSON (which btw JSON is meant for)?
saving and loading with gdscript it's Incredible!. Can this work for RPG mechanics? like saving player position, gear, items in inventory, stats, etc?
I know this is a bit old I'm wondering: in the non-pooling bullet example how are those bullets being removed once they are off screen? I'm assuming they aren't just accumulating indefinitely, does bullet.tscn maybe have a timer that calls queue_free or remove_child or something?
Yes they get freed when they leave the screen. I don't remember what they use exactly - most likely a timer.
@@Gdquest Ah, a belated thank you for the answer! Thanks much ^^
More!
Great now I have to remake the save system
what's with the walrus := operator everywhere ? Is it used same as Python ?
Edit:
So it's not same as in Python at all. It's inferred type in GDScript.
So basically godot has unity PlayerPrefs but for godot? As a unity user, i might actually switch
Do I need internet connection to run godot ?
No
@@shwetanksingh2156 ok,thanks for info
@@applepieslice23 every game engine runs without internet unless you are using the web version
Will Godot support c# in the future?
It does already and always will, it's an official language
@@Gdquest Alright, glad to hear that
when 2nd part?
Are these tips still viable?
Thanks for the tips but I will have to pass your advice in not using json. The alternative you showed Is just too much more complicated.
Why is it considered a Pro tip not to constantly recreate objects and using a cache instead?
"Only do something if the game starts to get slow" 😭😭😭
Those dislikes are from people who use C#
Are those examples you showed here available as code? Would be awsome to see how they work under the hood.
I'm new to Godot, but by mastering these pro tips first, I'll be able to bypass all the beginner tutorials and am likely to release the first of many critically acclaimed games in a matter of days.
GD skrip its a Eazy code
It's weird seeing an FTL clone in the examples.
1st *says* you don't need pooling while showing an example of exactly why you *may* need pooling? smh... Nobody looking for "Pro Tips" is going to think they need pooling and likely won't even know what it is until they encounter the very reason that they need it, which you just showcased.
"JSON can only store floats and no vectors"...sorry but that is WRONG...JSON can also store ARRAYs...and what is an ARRAY of 3 floats other than a vector ? ;)
It's compared to Godot's native formats. Godot's formats directly serialize and load all built-in engine types, including Vector2, Vector3, Transform, etc. So you'd better use them instead of JSON except for web queries and interchange exports.
Best GDScript Tip: Don‘t use it and go for C# or one of the GDNative languages instead. It‘s a bad path to choose. They should just remove it like other engines have done with their engine-specific scripting languages.
the unreal engine ships with a scripting visual language most users work with (blueprints) and the company is working on a scripting language like GDScript.
@@Gdquest And that makes GDScript a better choice than C# or C++ because …? I don‘t know what Epic is doing behind the scenes, but they droped Unreal Script in favor of C++ when they transitioned from UE3 to UE4 for the very reasons why i think GDScript is bad.
Epic is re-adding a scripting language to future releases of the unreal engine yes. They didn't remove high level languages in unreal 3 and 4: they invested in visual programming. And now they're re-adding something like the unreal script they used to have on top of that.
GDScript is a front end, domain specific language. Its whole point is to work within a specific domain, gameplay and tool programming inside Godot. You're supposed to use it for gameplay programming tasks, calling engine methods etc., as it's very efficient at that. And use a different language, e.g. c++, for anything that requires more flexibility or performance.
It's just so much faster to write and iterate over GDScript for gameplay code - fairly easy to maintain too if you use it to that end. And pretty quick to port to C++ in the infrequent cases you realize you need to turn some front end code.into backend stuff.
Of course you're welcome to use whatever you prefer and works for you.
This is really useful! Thank you!