When not all strings are Strings. Detect bugs in your GDscript more easily with static typing

One of the benefits of working with Godot Engine is that GDScript allows one to operate high level. GDScript is dynamically typed, so not even variable types have to be specified, but I would strongly recommend using static typing wherever possible. It can help with performance but primarily adds clarity when trying to follow the flow of a script.

var name = "Adam"
print(name)

In this case, name is a String, but in a more complex code base that could change:

var name = "Adam"
name = 42 # yoink
print(name)

This flexibility can lead to confusion, especially once multiple nodes and scripts are involved, passing data back and forth. By forcing a data type, you can be sure the data type doesn’t flip on you later:

var name: String = "Adam"
name = 42 # will throw an error
print(name)

This helps reduce cognitive load while working with the code because the developer doesn’t have to keep track of what a variable might be. And the editor’s static analysis tooling can help point out these static type mismatches:

It doesn’t help avoid all Pitfalls – curveball incoming

It’s quite helpful to be familiar with the data types, especially some of the more specialty types that Godot supports.

Here’s an instance where static typing indirectly saved my bacon: I was prototyping a multiplayer component and wanted to reduce the overhead of sending node paths across the network. Rather than sending strings, I built lookup tables (arrays) with the paths of game objects, which can then be addressed by their index in the lookup table. So rather than sending "/root/World/TileMap/NPC-22" , it would just send something like “3”. An ID over an entire node path adds up, especially at scale.

However, at the time I was not yet cognizant of the fact that Godot Engine doesn’t just use String s to keep track of node paths, it uses a particular data type: NodePath .

My implementation required a lookup table that kept track of which nodes the other side is already aware of. My initial naïve implementation used this lookup table:

var lut: Array = []

You may already see where this is going. I expected an array of strings, but since Node.get_node() returns a NodePath , that’s what I got instead. What would you expect to happen when you add static typing?

var lut: Array[String] = []

If you try to add a NodePath object to this lut array, it will silently drop it. This is slightly worse than what happens when you pass a NodePath to a method that requires a string parameter.

Try it for yourself. Create a new scene with a simple Node , attach a script, and paste in these contents:

extends Node

var lut: Array = []

func _ready() -> void:
	var path = node_path_builder()
	lut.append(path)
	string_receiver(path)
	print(lut)


func node_path_builder():
	var path = get_path()
	print("node_path_builder(): %s (type: %s)" % [path, typeof(path)])
	return path


func string_receiver(path: String):
	print("string_receiver(%s) (type: %s)" % [path, typeof(path)])

If you run the scene you should get something similar to the following output:

--- Debugging process started ---
Godot Engine v4.0.beta2.official.f8745f2f7 - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1070 Ti

node_path_builder(): /root/Node (type: 22)
string_receiver(/root/Node) (type: 4)
[^"/root/Node"]
--- Debugging process stopped ---

The path that is constructed in node_path_builder() is of type 22 ( NodePath ), whereas when it gets passed to the string_receiver() method, it’s auto-typed to String .

Printing out the lut shows that little caret (^) character before the "/root/Node" path, to indicate that it’s not just a plain String.

Now change line 3 so it’s typed to Array[String] , and run the scene again:

--- Debugging process started ---
Godot Engine v4.0.beta2.official.f8745f2f7 - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1070 Ti

node_path_builder(): /root/Node (type: 22)
string_receiver(/root/Node) (type: 4)
[]
--- Debugging process stopped ---

Nothing was added to the array. It’s a bit of an odd scenario. Static typing probably shouldn’t result in things getting dropped or auto-converted silently, but I think the intent was to optimize the performance when dealing with node paths, but trying to abstract it away from the developer, so it ended up in this “things are not as they appear, nor are they otherwise” state.

In my case, the array ended up being a mix of String and NodePath data types, and comparisons would fail. Once I added static typing to the array, more stuff broke, and I took a closer look and noticed this discrepancy. Just being aware and knowing how Godot operates internally helps when encountering these types of things.

The more static typing there is in place, the more opportunity for static analysis tooling to find easily overlooked issues. The idea that you can just hide the data type and automate it away is great, but there’s usually a runtime performance penalty associated with it. There’s also less clarity for the developer of what something is or does.

Whenever possible I recommend specifying variable types, method arguments, and return types in order to build more robust code and interfaces.