VirtualJoystick in Godot 4.7: Endlich ein nativer Touchscreen-Stick

Bis vor kurzem hattest du in Godot zwei Optionen, wenn du einen virtuellen Joystick auf dem Smartphone wolltest: Plugin installieren oder selbst bauen. Beides hatte den gleichen Effekt: Edge Cases mit Multitouch, Resolution-Scaling von Hand, und am Ende eine Klasse mit 200 Zeilen, die du bei jedem Engine-Update neu testen musstest.

Mit Godot 4.7 beta 1 (24. April 2026) ist das vorbei. Der neue VirtualJoystick-Knoten ist Teil der Engine, hat drei Modi und fügt sich sauber ins Action-Mapping-System ein.

Das Problem, das TouchScreenButton nicht gelöst hat

Godot hatte schon vorher einen Knoten namens TouchScreenButton für mobile Steuerungen. Das Problem: Er erbt von Node2D. Das klingt harmlos, ist es aber nicht. Es bedeutet, dass der Button keine Anchors verwenden kann, also nicht relativ zum Bildschirmrand positioniert werden kann.

Der Reviewer Calinou hat es im Pull Request knapp formuliert: "TouchScreenButton inherits from Node2D, which means it can't make use of anchors." Für ein Element, das auf jedem Display-Format ordentlich aussehen soll, ist das ein Showstopper.

Im ursprünglichen Proposal stand es so:

"When creating a mobile game, you often need a virtual joystick so the player can move around. However, this is nontrivial to implement correctly."

Das Resultat: Jedes mobile Godot-Projekt hatte entweder eine Asset-Library-Abhängigkeit oder eine selbst geschriebene Joystick-Klasse, die in vielen Fällen ein paar Edge Cases falsch handhabte. Multitouch-Tracking, Resolution-Scaling und das Verhalten beim Verlassen des Sticks sind die häufigsten Stolpersteine.

Was der neue VirtualJoystick ist

VirtualJoystick erbt von Control. Damit funktionieren Anchors, size_flags, theme_override, alles was Control-Nodes können. Das ist der wichtige Unterschied zum alten TouchScreenButton.

Der Knoten zeichnet sich prozedural, also nicht als Bitmap. Das bedeutet: Egal ob 1080p oder 4K-Tablet, der Stick sieht identisch scharf aus. Der Look lässt sich über Theme-Properties anpassen (Hintergrund, Knopf, Farben).

Hinzu kommen vier Signale, die du im Editor verbinden kannst:

• tapped: losgelassen, ohne dass der Stick bewegt wurde
• released: der Finger hat den Bildschirm verlassen
• flicked: der Stick wurde aus der Deadzone heraus bewegt
• flick_canceled: ein Flick wurde initiiert, aber wieder zurückgezogen

Das ist mehr als die meisten Plugin-Implementierungen anbieten. Vor allem tapped ist nützlich: Damit lässt sich der Joystick auch als Action-Button verwenden, wenn der Spieler nur kurz tippt statt zu schieben.

Die drei Modi: Fixed, Dynamic, Following

Hier ist der Punkt, an dem die meisten Tutorials oberflächlich werden. Die drei Modi bestimmen, wie sich der Stick beim Berühren verhält.

JOYSTICK_FIXED

Der Stick bleibt da, wo du ihn platziert hast. Klassisch, simpel, vorhersehbar. Wenn der Spieler nicht direkt auf den Stick tippt, passiert nichts.

Use Case: Action-Spiele mit fester UI, bei denen der Stick immer sichtbar ist. Spieler gewöhnen sich an die Position.

JOYSTICK_DYNAMIC

Tippt der Spieler in den Bereich des Sticks (also die size-Region des Control-Nodes), springt der Knopf zur Berührungsposition. Der Stick selbst bewegt sich nicht weiter über den Berührungspunkt hinaus.

Use Case: Mehr Komfort als FIXED, weil man nicht millimetergenau treffen muss. Gut für Mobile-Ports von Joypad-Spielen.

JOYSTICK_FOLLOWING

Wie DYNAMIC, aber der Stick folgt dem Finger auch über die ursprüngliche Bounding-Box hinaus. Beim Loslassen springt er zurück.

Use Case: Twin-Stick-Shooter und alles, wo der Spieler den Daumen wandern lässt. Das fühlt sich auf großen Displays am natürlichsten an.

Modus	Stick-Position	Bewegung über Bounds	Typischer Einsatz
JOYSTICK_FIXED	unverändert	nein	klassische UI
JOYSTICK_DYNAMIC	springt zur Berührung	nein	Mobile-Ports
JOYSTICK_FOLLOWING	springt zur Berührung	ja	Twin-Stick

Praktischer Setup-Code

Im Editor legst du den VirtualJoystick als Kind eines CanvasLayer an, damit er nicht mit der Welt-Kamera scrollt. Dann mappst du die Richtungen auf Input-Actions und liest die Werte wie gewohnt aus.

extends CharacterBody2D

@export var move_speed: float = 200.0

func _physics_process(_delta: float) -> void:
    var input_dir := Input.get_vector(
        "move_left",
        "move_right",
        "move_up",
        "move_down"
    )
    velocity = input_dir * move_speed
    move_and_slide()

Das ist alles. Im VirtualJoystick-Inspector trägst du move_left, move_right, move_up und move_down als Action-Properties ein. Der Knoten triggert die Actions automatisch mit der entsprechenden Stärke (zwischen 0.0 und 1.0). Dein Spiel-Code muss nichts vom Joystick wissen, das ist plattform-agnostisch und funktioniert auch mit Gamepad oder Tastatur.

Was nicht drin ist (und warum)

Bewusst weggelassen wurden zwei Features, die viele Plugins haben:

1. Deadzone-Konfiguration im Knoten selbst. Die Deadzone gehört zur Input-Action, nicht zum Joystick. Godot hat dafür schon ein Feld in den Project Settings unter "Input Map". Doppelte Konfiguration wäre nur eine Quelle für Bugs.

2. Clamp-Zone. Eine Zone, in der der Stick "gefangen" bleibt. Im Original-Proposal als optional markiert, in der finalen Version dann doch rausgeflogen.

Beides sind Design-Entscheidungen, keine Lücken, die später gefüllt werden. Wenn du das brauchst, kannst du den Knoten beerben und es selbst hinzufügen, aber im Standard-Workflow ist es nicht notwendig.

Vor 4.7 vs. ab 4.7

Wenn du schon Mobile-Spiele in Godot baust, hast du wahrscheinlich eine eigene VirtualJoystick.gd-Klasse oder ein Asset aus der Library. Die meisten dieser Implementierungen liegen bei 100 bis 300 Zeilen Code, abhängig davon, wie viele Edge Cases sie abdecken.

Die Godot Asset Library listet aktuell 20 konkurrierende Joystick-Plugins. Genau das ist das Problem, das eine native Lösung beendet: Du musst nicht mehr entscheiden, welches Plugin am wenigsten Bugs hat oder welches noch zu Godot 4.6 kompatibel ist. Der Knoten ist da, gewartet vom Engine-Team, und verschwindet beim nächsten Update nicht.

Lohnt sich der Umstieg für Mobile-Projekte?

Wenn dein Spiel auf Touchscreen zielt, ja. Mobile Games erzielten 2024 in Deutschland Rekord-Umsätze von 3 Milliarden Euro, 63 Prozent mehr als 2019, und das Smartphone ist seit Jahren die meistgenutzte Gaming-Plattform hierzulande. Viele Indie-Studios machen einen Hybrid-Ansatz: Desktop-Release zuerst, dann Mobile-Port. Genau in diesem Mobile-Port-Schritt war Touchscreen-Steuerung bisher ein Tag Handarbeit.

4.7 ist gerade in der Beta-Phase, der stabile Release wird in etwa zwei Monaten erwartet. Wenn du an einem Mobile-Spiel arbeitest, lohnt sich der Sprung früh genug, um den Joystick vor dem Launch zu testen. Klein, aber konkret.