About this skill

Problem

In Godot 4.3+ projects, scripts migrated from Godot 3.x often keep patterns such as yield, old connect syntax, or export var, causing parse errors, missing node references, or frame-rate-dependent movement. This skill focuses on making individual .gd files correct, readable, and idiomatic for GDScript 2.0.

Core approach

Type first: use explicit types like var hp: int = 10 and func add(a: int, b: int) -> int:, with := for inference, so errors surface at parse time.
Lifecycle discipline: distinguish _ready(), _process(delta), and _physics_process(delta), and place movement or physics logic in the fixed physics tick.
Node references: prefer @onready for child nodes, instead of using $NodePath in _init() before the node enters the tree.
Signals and coroutines: connect signals with 4.x Callable syntax and use await instead of 3.x yield, reducing polling-style event handling.
Exported values: expose tunables with @export so designers can adjust them in the Inspector.

Boundaries

The skill is suited to writing, fixing, or migrating a single .gd script. It does not cover scene-tree design, instancing, broader signal architecture, or C#/.NET alternatives. For issues such as duplicate class_name, integer division truncation, or changed RPC annotations, apply 4.x annotation and typing rules first.

Screenshots

Use Cases

Fix Godot 4.3 parse failures by replacing 3.x yield and old connect with await and Callable connections.
Move player movement logic from _process to _physics_process so motion no longer depends on frame rate.
Expose level parameters with @export and grab child nodes with @onready instead of referencing them in _init.
Declare and connect character skill signals, using await to continue only after a timer or signal completes.

Best For

Indie game programmers maintaining Godot 4.3 projects who need to turn 3.x scripts into parseable GDScript 2.0.
Game client engineers writing character or level scripts who need consistent @export, @onready, and signal await patterns.
Engine programmers moving into Godot from C# or Unity who need to understand 4.x signal, typing, and lifecycle constraints.
Technical artists landing design values into scenes who need to expose tunables and avoid runtime reference errors.