Am I wasting my time with GDScript?

Question

For the past year now I've been teaching myself how to make a game in Godot and script using it's language as I was told it was a good starting place. I've never touched programming or other scripts ever.

I have an intermediate grasp on the subject. However, looking over the introduction for gdscript, It talks about how it has lower performance than statically type languages.

How much will using GDScript effected the overall performance of my game and what issues does it face performance wise? Is it just longer load times potentially? Or is there a general lag for games that need more fast pace nuance?

Comments

I've seen this one enter link description here. Imao we need GDScript for easy use. For algoriithms that takes time and Data-oriented Design, I think GDNative is the best option.

---

This is a bad example. The person that posted that video used their own custom implementation of path-finding. If they used a Navigation node or an AStarNode node, I'm 99% certain the path-finding is done in c++ even if you code the implementation in GDScript.

Path-finding is also one of the most computationally expensive things you can do on the fly in a game so comparing its performance difference is not indicative of typical performance differences. E.g. you're not likely to get a 9x speed increase calling add_child() in GDNative vs in GDScript.

---

I got a bad example here sorry. haha.. But when someone need to implement things that is not already in Godot, GDNative would be the choiceable one.

---

ps. I just stumbled over a nice quote that made me recall this question. It's from the Alex Martelli at Google explaining their tech stack mantra:

“Python where we can, C++ where we must.”

You can substitute "python" for "gdscript" for the purpose of this discussion:

Answer 1

Short answer: no.

There are two types of performance in dev: computational performance (how quickly a computer can run the programme) and then there's human performance (how quickly you the coder can write the game).

There's a trade off between these two types of performance and all computer languages sit somewhere on the spectrum.

x86 Assembly is at one end, if you write it well it can be very performant and it will take you an eternity to code the smallest thing. C is similar but less extreme, performant but with low coder productivity.

On the end we have Python which interprets on the fly, it's much slower than gdscript. Guess which the most successful language is?

It seems that the industry has spoken, developer time matters more than computer time.

The reality is that modern computers are crazy powerful and, as long as you don't do anything silly, today's dev has enough computational overhead not to worry about optimisation and instead to focus on their own productivity. When optimisation is needed, the dev can multithread, make chunks, use LOD, etc (things available in gdscript). If a script is so computationally expensive it's bottlenecking your game then just rewrite that particular script in C++. Why rewrite something that's only called every five minutes?

My advice, focus on your own personal productivity. When there's a pressing need to optimise, identify the expensive scripts, rewrite them in a faster language, and leave everything else in gdscript.

Because you can have the most optimised game in existence, but if dev takes so long you never finish it, what's the point?

Comments

This is the right answer. Newbies tend to focus so much on performance that they lose the forest through the trees. You'll save many hours in compilation time and resolving compilation related errors alone by writing in GDScript over GDNative. Not to mention all the time you'll save by being able to reload/alter scripts in real time while your game is running to test how different variable values affect the game play.