Tipizzazione statica in GDScript

In questa guida imparerai:

  • Come usare i tipi in GDScript
  • Che la tipizzazione statica può aiutarti a evitare bug

Dove e come usi questa nuova funzione del linguaggio è completamente a tua scelta: puoi usarla solo in qualche importante file GDScript, dappertutto o puoi scrivere codice come hai sempre fatto!

La tipizzazione statica può essere usata su variabili, costanti, funzioni, parametri e tipi ritornati.

Nota

GDScript tipizzato è disponibile a partire da Godot 3.1.

Un breve sguardo alla tipizzazione statica

Con la tipizzazione di GDScript, Godot può rilevare ancora più errori mentre scrivi codice! Fornisce a te e ai tuoi compagni di squadra maggiori informazioni mentre lavorate poiché i tipi degli argomenti appaiono quando chiamate un metodo.

Immagina di programmare un sistema di inventario. Progetti un nodo Item, poi un nodo Inventory. Per aggiungere elementi all'inventario, le persone che lavorano con il tuo codice devono sempre passare un oggetto di tipo Item``al metodo ``Inventory.add. Con la tipizzazione puoi imporre questa regola così:

# In 'Item.gd'.
class_name Item
# In 'Inventory.gd'.
class_name Inventory


func add(reference: Item, amount: int = 1):
    var item = find_item(reference)
    if not item:
        item = _instance_item_from_db(reference)

    item.amount += amount

Un altro vantaggio significativo della tipizzazione di GDScript è il nuovo warning system. Dalla versione 3.1, Godot emette warning mentre scrivi il tuo codice: l'engine identifica sezioni del tuo codice che potrebbero causare problemi in fase di esecuzione ma lascia a te decidere se mantenere il codice così com'è. Dettagli più avanti.

Static types also give you better code completion options. Below, you can see the difference between a dynamic and a static typed completion options for a class called PlayerController.

Probabilmente hai già assegnato un nodo ad una variabile in precedenza e digitato un punto per poi scoprire di non avere suggerimenti di autocompletamento:

code completion options for dynamic

Questo è per via della tipizzazione dinamica. Godot non può sapere quale nodo o tipo stai passando alla funzione. Al contrario se dichiari il tipo esplicitamente, otterrai tutti i metodi pubblici e le variabili del nodo:

code completion options for typed

In futuro la tipizzazione di GDScript aumenterà le prestazioni del codice: la compilazione Just-In-Time e altre ottimizzazioni del compilatore sono già nella roadmap!

Overall, typed programming gives you a more structured experience. It helps prevent errors and improves the self-documenting aspect of your scripts. This is especially helpful when you're working in a team or on a long-term project: studies have shown that developers spend most of their time reading other people's code, or scripts they wrote in the past and forgot about. The clearer and the more structured the code, the faster it is to understand, the faster you can move forward.

Come usare la tipizzazione statica

To define the type of a variable or a constant, write a colon after the variable's name, followed by its type. E.g. var health: int. This forces the variable's type to always stay the same:

var damage: float = 10.5
const MOVE_SPEED: float = 50.0

Godot proverà ad inferire il tipo se scrivi due punti e ometti il tipo:

var life_points := 4
var damage := 10.5
var motion := Vector2()

Al momento puoi usare tre tipologie di... tipi:

  1. Built-in
  2. Core classes and nodes (Object, Node, Area2D, Camera2D, etc.)
  3. Your own, custom classes. Look at the new class_name feature to register types in the editor.

Nota

You don't need to write type hints for constants, as Godot sets it automatically from the assigned value. But you can still do so to make the intent of your code clearer.

Custom variable types

You can use any class, including your custom classes, as types. There are two ways to use them in scripts. The first method is to preload the script you want to use as a type in a constant:

const Rifle = preload("res://player/weapons/Rifle.gd")
var my_rifle: Rifle

The second method is to use the class_name keyword when you create. For the example above, your Rifle.gd would look like this:

extends Node2D
class_name Rifle

If you use class_name, Godot registers the Rifle type globally in the editor, and you can use it anywhere, without having to preload it into a constant:

var my_rifle: Rifle

Variable casting

Type casting is a key concept in typed languages. Casting is the conversion of a value from one type to another.

Imagine an Enemy in your game, that extends Area2D. You want it to collide with the Player, a KinematicBody2D with a script called PlayerController attached to it. You use the on_body_entered signal to detect the collision. With typed code, the body you detect is going to be a generic PhysicsBody2D, and not your PlayerController on the _on_body_entered callback.

You can check if this PhysicsBody2D is your Player with the as casting keyword, and using the colon : again to force the variable to use this type. This forces the variable to stick to the PlayerController type:

func _on_body_entered(body: PhysicsBody2D) -> void:
    var player := body as PlayerController
    if not player:
        return

    player.damage()

As we're dealing with a custom type, if the body doesn't extend PlayerController, the playervariable will be set to null. We can use this to check if the body is the player or not. We will also get full autocompletion on the player variable thanks to that cast.

Nota

If you try to cast with a built-in type and it fails, Godot will throw an error.

Safe lines

You can also use casting to ensure safe lines. Safe lines are a new tool in Godot 3.1 to tell you when ambiguous lines of code are type-safe. As you can mix and match typed and dynamic code, at times, Godot doesn't have enough information to know if an instruction will trigger an error or not at runtime.

This happens when you get a child node. Let's take a timer for example: with dynamic code, you can get the node with $Timer. GDScript supports duck-typing, so even if your timer is of type Timer, it is also a Node and an Object, two classes it extends. With dynamic GDScript, you also don't care about the node's type as long as it has the methods you need to call.

You can use casting to tell Godot the type you expect when you get a node: ($Timer as Timer), ($Player as KinematicBody2D), etc. Godot will ensure the type works and if so, the line number will turn green at the left of the script editor.

Unsafe vs Safe Line

Unsafe line (line 7) vs Safe Lines (line 6 and 8)

Nota

You can turn off safe lines or change their color in the editor settings.

Definisci il tipo ritornato da una funzione con la freccia ->

To define the return type of a function, write a dash and a right angle bracket -> after its declaration, followed by the return type:

func _process(delta: float) -> void:
    pass

The type void means the function does not return anything. You can use any type, as with variables:

func hit(damage: float) -> bool:
    health_points -= damage
    return health_points <= 0

You can also use your own nodes as return types:

# Inventory.gd

# Adds an item to the inventory and returns it.
func add(reference: Item, amount: int) -> Item:
    var item: Item = find_item(reference)
    if not item:
        item = ItemDatabase.get_instance(reference)

    item.amount += amount
    return item

Tipizzazione statica o dinamica: attieniti ad un unico stile

Typed GDScript and dynamic GDScript can coexist in the same project. But I recommend to stick to either style for consistency in your codebase, and for your peers. It's easier for everyone to work together if you follow the same guidelines, and faster to read and understand other people's code.

Typed code takes a little more writing, but you get the benefits we discussed above. Here's an example of the same, empty script, in a dynamic style:

extends Node


func _ready():
    pass


func _process(delta):
    pass

E con la tipizzazione statica:

extends Node


func _ready() -> void:
    pass


func _process(delta: float) -> void:
    pass

As you can see, you can also use types with the engine's virtual methods. Signal callbacks, like any methods, can also use types. Here's a body_entered signal in a dynamic style:

func _on_Area2D_body_entered(body):
    pass

And the same callback, with type hints:

func _on_area_entered(area: CollisionObject2D) -> void:
    pass

You're free to replace, e.g. the CollisionObject2D, with your own type, to cast parameters automatically:

func _on_area_entered(bullet: Bullet) -> void:
    if not bullet:
        return

    take_damage(bullet.damage)

The bullet variable could hold any CollisionObject2D here, but we make sure it is our Bullet, a node we created for our project. If it's anything else, like an Area2D, or any node that doesn't extend Bullet, the bullet variable will be null.

Warning system

Nota

Documentation about the GDScript warning system has been moved to GDScript warning system.

Cases where you can't specify types

To wrap up this introduction, let's cover a few cases where you can't use type hints. All the examples below will trigger errors.

You can't use Enums as types:

enum MoveDirection {UP, DOWN, LEFT, RIGHT}
var current_direction: MoveDirection

You can't specify the type of individual members in an array. This will give you an error:

var enemies: Array = [$Goblin: Enemy, $Zombie: Enemy]

You can't force the assignment of types in a for loop, as each element the for keyword loops over already has a different type. So you cannot write:

var names = ["John", "Marta", "Samantha", "Jimmy"]
for name: String in names:
    pass

Two scripts can't depend on each other in a cyclic fashion:

# Player.gd

extends Area2D
class_name Player


var rifle: Rifle
# Rifle.gd

extends Area2D
class_name Rifle


var player: Player

Summary

Typed GDScript is a powerful tool. Available as of version 3.1 of Godot, it helps you write more structured code, avoid common errors, and create scalable systems. In the future, static types will also bring you a nice performance boost thanks to upcoming compiler optimizations.