This tutorial aims to be a quick reference for how to use GDScript more
efficiently. It focuses on common cases specific to the language, but
also covers a lot of information on dynamically typed languages.

It’s meant to be especially useful for programmers with little or no previous
experience with dynamically typed languages.

GDScript is a Dynamically Typed language. As such, its main advantages
are that:

The language is simple and easy to learn.

Most code can be written and changed quickly and without hassle.

Less code written means less errors & mistakes to fix.

Easier to read the code (less clutter).

No compilation is required to test.

Runtime is tiny.

Duck-typing and polymorphism by nature.

While the main disadvantages are:

Less performance than statically typed languages.

More difficult to refactor (symbols can’t be traced)

Some errors that would typically be detected at compile time in
statically typed languages only appear while running the code
(because expression parsing is more strict).

Less flexibility for code-completion (some variable types are only
known at run-time).

This, translated to reality, means that Godot+GDScript are a combination
designed to create games quickly and efficiently. For games that are very
computationally intensive and can’t benefit from the engine built-in
tools (such as the Vector types, Physics Engine, Math library, etc), the
possibility of using C++ is present too. This allows you to still create most of the
game in GDScript and add small bits of C++ in the areas that need
a performance boost.

In static languages, such as C or C++ (and to some extent Java and C#),
there is a distinction between a variable and a pointer/reference to a
variable. The latter allows the object to be modified by other functions
by passing a reference to the original one.

In C# or Java, everything not a built-in type (int, float, sometimes
String) is always a pointer or a reference. References are also
garbage-collected automatically, which means they are erased when no
longer used. Dynamically typed languages tend to use this memory model,
too. Some Examples:

C++:

voiduse_class(SomeClass*instance){instance->use();}voiddo_something(){SomeClass*instance=newSomeClass;// Created as pointer.use_class(instance);// Passed as pointer.deleteinstance;// Otherwise it will leak memory.}

Java:

@Overridepublicfinalvoiduse_class(SomeClassinstance){instance.use();}publicfinalvoiddo_something(){SomeClassinstance=newSomeClass();// Created as reference.use_class(instance);// Passed as reference.// Garbage collector will get rid of it when not in// use and freeze your game randomly for a second.}

GDScript:

funcuse_class(instance):# Does not care about class typeinstance.use()# Will work with any class that has a ".use()" method.funcdo_something():varinstance=SomeClass.new()# Created as reference.use_class(instance)# Passed as reference.# Will be unreferenced and deleted.

In GDScript, only base types (int, float, string and the vector types)
are passed by value to functions (value is copied). Everything else
(instances, arrays, dictionaries, etc) is passed as reference. Classes
that inherit Reference (the default if nothing is specified)
will be freed when not used, but manual memory management is allowed too
if inheriting manually from Object.

Dictionaries are a powerful tool in dynamically typed languages.
Most programmers that come from statically typed languages (such as C++
or C#) ignore their existence and make their life unnecessarily more
difficult. This datatype is generally not present in such languages (or
only in limited form).

Dictionaries can map any value to any other value with complete
disregard for the datatype used as either key or value. Contrary to
popular belief, they are efficient because they can be implemented
with hash tables. They are, in fact, so efficient that some languages
will go as far as implementing arrays as dictionaries.

Dictionaries can also be used as data markup or quick structures. While
GDScript’s dictionaries resemble python dictionaries, it also supports Lua
style syntax and indexing, which makes it useful for writing initial
states and quick structs:

# Same example, lua-style support.# This syntax is a lot more readable and usable.# Like any GDScript identifier, keys written in this form cannot start# with a digit.vard={name="John",age=22}print("Name: ",d.name," Age: ",d.age)# Used "." based indexing.# Indexingd["mother"]="Rebecca"d.mother="Caroline"# This would work too to create a new key.

constchar*strings=newconstchar*[50];[..]for(inti=0;i<50;i++){printf("Value: %s\n",i,strings[i]);}// Even in STL:for(std::list<std::string>::const_iteratorit=strings.begin();it!=strings.end();it++){std::cout<<*it<<std::endl;}

One of the most difficult concepts to grasp when moving from a
statically typed language to a dynamic one is duck typing. Duck typing
makes overall code design much simpler and straightforward to write, but
it’s not obvious how it works.

As an example, imagine a situation where a big rock is falling down a
tunnel, smashing everything on its way. The code for the rock, in a
statically typed language would be something like:

voidBigRollingRock::on_object_hit(Smashable*entity){entity->smash();}

This way, everything that can be smashed by a rock would have to
inherit Smashable. If a character, enemy, piece of furniture, small rock
were all smashable, they would need to inherit from the class Smashable,
possibly requiring multiple inheritance. If multiple inheritance was
undesired, then they would have to inherit a common class like Entity.
Yet, it would not be very elegant to add a virtual method smash() to
Entity only if a few of them can be smashed.

With dynamically typed languages, this is not a problem. Duck typing
makes sure you only have to define a smash() function where required
and that’s it. No need to consider inheritance, base classes, etc.

func_on_object_hit(object):object.smash()

And that’s it. If the object that hit the big rock has a smash() method,
it will be called. No need for inheritance or polymorphism. Dynamically
typed languages only care about the instance having the desired method
or member, not what it inherits or the class type. The definition of
Duck Typing should make this clearer:

“When I see a bird that walks like a duck and swims like a duck and
quacks like a duck, I call that bird a duck”

In this case, it translates to:

“If the object can be smashed, don’t care what it is, just smash it.”

Yes, we should call it Hulk typing instead.

It’s possible that the object being hit doesn’t have a smash() function.
Some dynamically typed languages simply ignore a method call when it
doesn’t exist (like Objective C), but GDScript is stricter, so
checking if the function exists is desirable: