DEV Community: Ziva

Multijugador en Godot 4: Guía práctica con MultiplayerSpawner

Ziva — Fri, 08 May 2026 18:38:43 +0000

El sistema multijugador de Godot 4 cambió mucho desde Godot 3. Si vienes de la versión anterior o de Unity, vas a ver nodos nuevos como MultiplayerSpawner y MultiplayerSynchronizer que hacen casi todo el trabajo pesado por ti. Lo bueno: bien usados, ahorran cientos de líneas de código. Lo malo: la documentación oficial los explica mal, y la mayoría de los tutoriales en YouTube están desactualizados.

Esta guía cubre lo que sí funciona en Godot 4.4+ para multijugador peer-to-peer simple, los errores más comunes y dónde la IA generativa todavía falla cuando la pides escribir código de red.

Qué viene incluido en Godot 4

Godot 4 trae un stack de red completo:

ENetMultiplayerPeer: capa de transporte UDP confiable. Funciona en LAN, WAN y a través de NAT (con port forwarding).
WebSocketMultiplayerPeer: alternativa para builds web/HTML5.
WebRTCMultiplayerPeer: peer-to-peer real con NAT traversal automático, pero requiere un signaling server.
MultiplayerSpawner: replica nodos automáticamente cuando se spawnean en el host.
MultiplayerSynchronizer: replica propiedades específicas (posición, salud, etc.) en cada frame.
RPCs (@rpc): llamadas remotas a funciones, con tres modos de autoridad.

Para la mayoría de los juegos indie, la combinación es: ENet + Spawner + Synchronizer + algunos RPCs. El resto (lobbies, matchmaking, autenticación) lo escribes tú o lo delegas a un servicio externo.

Configurando una sala simple

Vamos a hacer una sala donde el primer jugador es el host y los demás se conectan a él. El código mínimo es sorprendentemente corto.

extends Node

const PORT = 7777
const MAX_PLAYERS = 8

func host_game() -> void:
    var peer = ENetMultiplayerPeer.new()
    var error = peer.create_server(PORT, MAX_PLAYERS)
    if error != OK:
        push_error("No se pudo crear el servidor: " + str(error))
        return
    multiplayer.multiplayer_peer = peer
    print("Servidor escuchando en el puerto ", PORT)

func join_game(address: String) -> void:
    var peer = ENetMultiplayerPeer.new()
    var error = peer.create_client(address, PORT)
    if error != OK:
        push_error("No se pudo conectar: " + str(error))
        return
    multiplayer.multiplayer_peer = peer
    print("Conectando a ", address)

func _on_peer_connected(id: int) -> void:
    print("Jugador conectado: ", id)

func _on_peer_disconnected(id: int) -> void:
    print("Jugador desconectado: ", id)

func _ready() -> void:
    multiplayer.peer_connected.connect(_on_peer_connected)
    multiplayer.peer_disconnected.connect(_on_peer_disconnected)

Eso es todo. El host llama a host_game(), los clientes llaman a join_game("192.168.1.42"). Las señales peer_connected y peer_disconnected te avisan cuando alguien entra o sale.

Replicando jugadores con MultiplayerSpawner

El nodo MultiplayerSpawner es la forma idiomática en Godot 4 de spawnear personajes. Reemplaza el viejo patrón de Godot 3 donde tenías que llamar rpc("spawn_player", id) y replicar manualmente.

Configuración:

En tu escena de juego, añade un nodo MultiplayerSpawner.
En el inspector, asigna su propiedad spawn_path a un Node2D o Node3D donde van los jugadores (algo como $Players).
Añade tu escena de jugador (player.tscn) a la lista auto_spawn_list.
Cuando el host instancie un jugador como hijo del nodo Players, el Spawner replica automáticamente esa instancia en todos los clientes.

# En el host, despues de que un peer se conecta:
func _on_peer_connected(id: int) -> void:
    if not multiplayer.is_server():
        return
    var player = preload("res://scenes/player.tscn").instantiate()
    player.name = str(id)  # importante: el name debe ser el id del peer
    $Players.add_child(player)

El detalle clave es que el nombre del nodo (player.name) debe ser el ID del peer. Esto le dice a Godot a quién pertenece ese nodo. Si no lo haces, los inputs del jugador 1 controlarán a todos los personajes a la vez.

MultiplayerSynchronizer para movimiento

El Synchronizer replica propiedades específicas de un nodo. Para un personaje que se mueve, querrás replicar position y quizás rotation.

Dentro de tu escena de jugador, añade un MultiplayerSynchronizer.
En el inspector, abre el editor de Replication.
Añade position (replicado en cada frame) y rotation si aplica.
Configura replication_interval a 0 para movimiento crítico, o a 0.05 (20 Hz) para reducir tráfico de red.

El Synchronizer hace lo siguiente: en cada tick, el peer que tiene autoridad sobre el nodo envía las propiedades replicadas a todos los demás peers, que las aplican localmente. La autoridad por defecto es el host (peer ID 1), pero puedes cambiarla:

# En _ready() del nodo player:
func _ready() -> void:
    # Cada jugador es dueno de su propio personaje
    var peer_id = name.to_int()
    set_multiplayer_authority(peer_id)

Con esto, cada jugador controla su personaje y el host no tiene que procesar los inputs de todos.

RPCs para acciones puntuales

Para cosas que pasan ocasionalmente (disparos, daño, chat) usa RPCs:

@rpc("any_peer", "call_local", "reliable")
func chat_message(text: String) -> void:
    print("[", multiplayer.get_remote_sender_id(), "]: ", text)

# Llamar desde cualquier peer:
chat_message.rpc("Hola a todos")

Las tres anotaciones importantes son:

"any_peer" o "authority": quién puede llamar la función. authority es solo el dueño del nodo; any_peer permite que cualquiera la llame.
"call_local" o "call_remote": si el llamante también ejecuta la función localmente. Para chat sí, para movimiento no.
"reliable" o "unreliable": TCP-style o UDP-style. Acciones críticas usan reliable; movimiento puro usa unreliable_ordered.

Donde la IA generativa todavía falla

He pedido código multiplayer a varios LLMs y los errores se repiten:

1. Mezcla de APIs Godot 3 y Godot 4. Los modelos generales fueron entrenados con muchos tutoriales viejos, así que te darán código con rpc("function_name") en lugar de function_name.rpc(), o set_network_master() en vez de set_multiplayer_authority(). El primero compila pero no hace lo correcto; el segundo ya ni existe en Godot 4.

2. RPC sin anotaciones. Olvidan poner @rpc("any_peer") y luego no entienden por qué el cliente no puede llamar la función. Por defecto, los RPCs son authority-only.

3. Authority mal configurada. Los clientes intentan modificar nodos de los que no son autoridad, las modificaciones se sobrescriben en el siguiente sync, y el código parece "casi funcionar".

Herramientas como Ziva que conocen específicamente la API de Godot 4 evitan estos tres problemas porque consultan la base de clases del editor en tiempo real, no patrones aprendidos de tutoriales viejos. Para multiplayer en particular, donde el modo authority + el tipo de RPC + el reliable/unreliable importan mucho, esto es la diferencia entre "compila" y "funciona en producción".

Errores comunes y cómo depurarlos

El cliente conecta pero no se ve el otro jugador. Casi siempre es porque el MultiplayerSpawner no tiene la escena en su auto_spawn_list, o porque el nombre del nodo no coincide con el peer ID.

Los inputs del jugador 1 controlan a todos. Te falta set_multiplayer_authority() en _ready() del personaje.

Cliente y host se desincronizan. Probablemente estás modificando una propiedad replicada en ambos lados a la vez. Solo la autoridad debe modificar las propiedades sincronizadas.

Lag visible aún en LAN. Sube replication_interval a 0 (cada frame) o usa interpolación del lado del cliente.

Cuándo usar otra cosa

ENet con MultiplayerSpawner funciona para:

Co-op de hasta ~8 jugadores
Juegos PvP simples sin matchmaking complejo
Juegos donde el host puede ser un jugador (sin servidor dedicado)

No es la opción correcta para:

MMOs (necesitas servidores autoritarios escalables)
Juegos competitivos con anti-cheat (necesitas servidor dedicado, no peer authority)
Browser builds (usa WebRTC + signaling server)
Cross-platform mobile (PlayFab, Photon o Nakama suelen ser mejores)

Recursos para profundizar

La documentación oficial de Godot Multiplayer cubre todo lo anterior con más profundidad, aunque tiende a saltar entre Godot 3 y Godot 4 sin marcarlo. Lee dos veces antes de implementar.

Si estás empezando con multiplayer en Godot, este código alcanza para un proyecto pequeño funcional en una tarde. Las complicaciones reales (matchmaking, anti-cheat, persistencia) vienen después y se resuelven con servicios externos, no con más código de Godot.

Godot 4 für Web-Spiele: Export, WASM und Browser-Performance

Ziva — Fri, 08 May 2026 18:33:55 +0000

Godot 4 kann seit Version 4.3 wieder zuverlässig in den Browser exportieren. Wer 2023 mit dem Web-Export gekämpft hat, sollte sich die aktuelle Version anschauen. Das Threading-Modell wurde überarbeitet, die Build-Größe ist gesunken, und auf modernen Browsern läuft die Performance brauchbar.

Dieser Artikel ist eine praktische Übersicht: was funktioniert, was nicht, und wie du den Web-Export sauber einrichtest.

Status quo: was geht in Godot 4.4+ wirklich

Der Web-Export von Godot kompiliert zu WebAssembly (WASM) und nutzt WebGL 2 als Renderer. In der aktuellen Stable (4.4) und Beta (4.7) sind die folgenden Punkte gelöst, die bis vor zwei Jahren noch Probleme gemacht haben:

Threading. Godot nutzt jetzt SharedArrayBuffer mit den korrekten COOP/COEP-Headern. Das ist Pflicht, ohne entsprechend konfigurierten Server bricht der Export beim Start ab.
Build-Größe. Ein leeres Godot-4.4-Projekt liefert ungefähr 35 MB komprimierter WASM-Code aus. Mit Asset-Pack-Stripping kannst du das auf etwa 25 MB reduzieren. Vergleiche das mit Unity WebGL bei rund 12-15 MB für ein Mini-Projekt: Godot ist größer, aber nicht mehr inakzeptabel.
Audio. Web Audio funktioniert. Latenz liegt bei ~80-150 ms, was für die meisten Casual Games reicht. Für rhythmische Spiele bleibt es ein Kompromiss.

Was 2026 immer noch nicht klappt:

3D-Spiele mit komplexen Shadern. WebGL 2 ist nicht WebGPU. Wenn dein Spiel Compute Shader oder Forward+ Rendering nutzt, vergiss den Browser.
Saves über Local Storage hinaus. Browser-Quotas sind unzuverlässig. Plan ein, dass Spielerdaten verloren gehen können.
Mobile Browser auf iOS. Safari hat lange WASM-Probleme gehabt. Aktuell läuft es, aber Bug-Reports kommen häufiger als auf Desktop.

Die Server-Konfiguration: hier scheitern die meisten

Das größte Problem beim Web-Export ist nicht der Build, sondern das Hosting. Godot benötigt zwei spezifische HTTP-Header:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Ohne diese Header lädt der Browser keinen SharedArrayBuffer, und Godot bricht mit einem Threading-Fehler ab. Auf itch.io sind die Header standardmäßig gesetzt; auf einem eigenen Server musst du sie konfigurieren.

Für Nginx:

location /spiel/ {
    add_header Cross-Origin-Embedder-Policy require-corp;
    add_header Cross-Origin-Opener-Policy same-origin;
}

Für Apache:

<Location "/spiel/">
    Header set Cross-Origin-Embedder-Policy "require-corp"
    Header set Cross-Origin-Opener-Policy "same-origin"
</Location>

GitHub Pages, Vercel und Netlify unterstützen diese Header über Konfigurationsdateien (_headers-Datei bzw. vercel.json). Cloudflare Pages braucht ein zusätzliches Worker-Skript.

Den Web-Export einrichten

Schritt 1: Im Godot-Editor unter Project > Export den Web-Export hinzufügen. Falls die Export-Templates fehlen, lade sie über Editor > Manage Export Templates herunter.

Schritt 2: Im Export-Dialog die folgenden Optionen prüfen:

Variant: Threads (empfohlen). Singlethreaded läuft auch ohne COOP/COEP-Header, ist aber deutlich langsamer.
VRAM Texture Compression: ETC2 für mobile Browser, BPTC/S3TC für Desktop. Beide aktivieren, wenn du beides bedienst.
Custom HTML Shell: leer lassen, falls du keine eigene Shell hast. Die Default-Shell macht alles, was du brauchst.

Schritt 3: Export Project und einen Ordner wählen. Godot erzeugt fünf Dateien: index.html, index.js, index.wasm, index.pck (das Asset-Pack) und index.audio.worklet.js.

Schritt 4: Lokal testen mit einem CORS-fähigen Server. Der Python-Einzeiler reicht nicht, weil die Header fehlen. Stattdessen:

from http.server import SimpleHTTPRequestHandler, HTTPServer

class CrossOriginIsolatedHandler(SimpleHTTPRequestHandler):
    def end_headers(self):
        self.send_header('Cross-Origin-Embedder-Policy', 'require-corp')
        self.send_header('Cross-Origin-Opener-Policy', 'same-origin')
        super().end_headers()

HTTPServer(('localhost', 8000), CrossOriginIsolatedHandler).serve_forever()

Speichern als serve.py, im Export-Ordner ausführen, dann http://localhost:8000 im Browser öffnen.

Performance-Tipps für den Browser

Der Browser ist nicht der Desktop. Was auf dem Editor mit 60 FPS läuft, kann im Browser auf 25 FPS einbrechen, wenn du nicht aufpasst.

1. Texturen reduzieren. WebGL 2 hat begrenzten VRAM auf mobilen Geräten. 4K-Texturen sind im Browser selten sinnvoll. Skaliere Assets auf 1024x1024 oder kleiner, wo möglich.

2. Polygon-Anzahl beobachten. Browser-WebGL ist langsamer als nativer OpenGL-Treiber. Eine 100.000-Polygon-Szene, die nativ flüssig läuft, ruckelt im Browser. Halte die sichtbare Polygon-Zahl unter 50.000.

3. Audio-Streams limitieren. Jeder gleichzeitig spielende AudioStreamPlayer kostet im Browser mehr als auf Desktop. Maximal 8-10 simultane Streams für Casual Games, weniger für Mobile.

4. _process minimieren. Jede Frame-Logik in _process kostet im Browser mehr. Nutze Signale für ereignisgesteuerte Logik statt jeden Frame zu pollen.

5. Pre-loading testen. Der Browser lädt das .pck-File komplett, bevor das Spiel startet. Bei 100 MB Assets sind das 30-60 Sekunden Wartezeit auf langsamen Verbindungen. Asset-Splitting via PCK Embedding kann helfen, ist aber mit Aufwand verbunden.

Hosting-Optionen im Vergleich

Plattform	Setup	Bandbreite	Custom Domain	Preis
itch.io	1 Klick	unbegrenzt	nein	gratis
GitHub Pages	mittel	100 GB/Monat	ja	gratis
Vercel	mittel	100 GB/Monat	ja	gratis Tier
Cloudflare Pages	hoch (Worker nötig)	unbegrenzt	ja	gratis Tier
Netlify	mittel	100 GB/Monat	ja	gratis Tier
Eigener Server	hoch	je nach Provider	ja	variabel

Für Game Jams und Demos: itch.io. Für eine eigene Marke mit Custom Domain und Analytics: Vercel oder Netlify. Für Produktion mit hohem Traffic: Cloudflare Pages, weil die Bandbreite nicht limitiert ist.

Fallstricke, die ich gesehen habe

iOS Safari Audio. iOS verlangt eine Nutzeraktion (Klick), bevor Audio abspielt. Wenn dein Spiel Audio im _ready() startet, hörst du auf iOS nichts. Workaround: einen "Start"-Button anzeigen, Audio erst nach dem Klick initialisieren.

Gamepad-Inputs. Der Browser-Gamepad-API ist standardisiert, aber Godot mappt nicht alle Buttons konsistent. Teste mit echten Controllern, nicht nur Tastatur-Emulation.

Memory Leaks. Lange Web-Sessions können Speicher leaken, weil die WASM-Heap nicht so aggressiv aufgeräumt wird wie der native Heap. Für Spiele unter 30 Minuten Spielzeit kein Problem; für Endless-Games solltest du den RAM-Verbrauch im DevTools-Performance-Tab überwachen.

WebGL-Kontext-Verlust. Bei Tab-Wechsel oder Mobile-Hintergrund kann der WebGL-Kontext verloren gehen. Godot fängt das in den meisten Fällen ab, aber Texturen müssen neu geladen werden. Plan ein paar Sekunden Reload-Pause ein.

Wann Web-Export sinnvoll ist und wann nicht

Sinnvoll:

2D-Casual-Games für Game Jams
Demos und Trailer-Versionen, die direkt im Browser laufen
Kleine Puzzle- und Strategiespiele
Educational Games für den Schulkontext

Nicht sinnvoll:

3D-AAA-artige Projekte
Spiele mit echten Multiplayer-Anforderungen (WebSockets gehen, aber Latenz ist höher)
Große Open-World-Spiele
Alles mit Compute-Shader-Bedarf

Fazit

Der Web-Export von Godot 4 ist 2026 brauchbar geworden, wenn du die Einschränkungen kennst. Die Server-Konfiguration ist die häufigste Fehlerquelle. Wenn du einmal saubere COOP/COEP-Header eingerichtet hast, wirst du nicht mehr daran scheitern.

Für Game Jams und Demos lohnt es sich. Für Vollpreis-Releases im Browser bist du wahrscheinlich besser bei Steam oder einem nativen Mobile-Build aufgehoben.

Wer mehr zur offiziellen Godot-Dokumentation auf Deutsch sucht, findet dort die meisten Web-Export-Themen ausführlich behandelt.

Static Typing in GDScript: The 30 Minutes That Saved Me 30 Hours

Ziva — Fri, 08 May 2026 18:11:27 +0000

Last month I spent an evening adding type hints to a 4,000-line GDScript codebase that had been running fine for a year. I expected nothing. By the time I finished, the editor had flagged 12 latent bugs I had never noticed: wrong return types, methods called with stale signatures, a Vector2 being passed where the function expected Vector3. Every single one of those would have eventually crashed in production.

Three of them already had: I just blamed them on something else when the bug reports came in.

Static typing in GDScript is one of those features that sounds boring on the docs page and turns out to be the biggest quality-of-life upgrade you can make to a Godot 4 project. It is faster too. Independent benchmarks put the gain at 28-59% on hot paths, driven by the engine bypassing Variant dispatch when types are known at compile time.

This post is the case for using type hints everywhere, including the gotchas I hit, and how to retrofit a typed style into a codebase that does not have it.

What static typing actually catches

Static typing in GDScript is opt-in per declaration. You can mix typed and untyped code freely in the same file. The type system catches:

Wrong type to a function: move_to(player.position_string) when position_string does not exist on player.
Wrong return type: a function declared -> int that returns a String somewhere down a branch.
Misspelled property names: player.helath instead of player.health.
Stale method signatures: you renamed attack(target) to attack(target, damage) six months ago and the editor finds the one call site you missed.
Null misuses: assigning a null to a non-nullable typed variable.

The first three I catch every time I run the project. The last two I never catch in dynamic GDScript because they only blow up under specific game state.

I added types using the official syntax:

# Before (untyped, "I'll figure it out at runtime")
var hp = 100
var enemies = []

func damage(amount, multiplier):
    hp -= amount * multiplier
    return hp <= 0

# After (typed)
var hp: int = 100
var enemies: Array[Enemy] = []

func damage(amount: int, multiplier: float = 1.0) -> bool:
    hp -= int(amount * multiplier)
    return hp <= 0

Note the Array[Enemy]. Typed arrays are a Godot 4 feature and they catch passing the wrong kind of array into a function that expects Array[Player]. This single check found four bugs in my project where I had been silently mixing entity types.

The performance angle

I would argue for typing on bug-catching grounds alone. The performance angle is a free bonus that turns out to be substantial.

The beep.blog benchmark ran 1 billion iterations across common GDScript operations on an M2 Max:

Operation	Untyped (ns)	Typed (ns)	Speedup
Integer addition	22	14	1.57x
Vector2 add	62	30	2.07x
Method call	47	33	1.42x
Engine API call	73	51	1.43x

The speedup comes from typed GDScript generating optimized opcodes that skip Variant unwrapping. In dynamic GDScript, every operation has to: check the type tag, dispatch to the right operator, perform the operation, wrap the result back in a Variant. Typed code knows the types ahead of time and just does the operation.

The biggest wins are in vector math and engine API calls, which is exactly what game code does in _process and _physics_process. If your game has any per-frame work, typing the hot loops is a free 30%+ speedup with no algorithm changes.

The catch with AI-generated code

I run a lot of code through LLMs while working in Godot. The pattern I have noticed: most cloud LLMs default to dynamic GDScript even when the surrounding file is typed. They generate this:

func get_nearest_enemy(pos):
    var closest = null
    var closest_dist = 999999
    for e in enemies:
        if e.position.distance_to(pos) < closest_dist:
            closest = e
            closest_dist = e.position.distance_to(pos)
    return closest

When the rest of the file looks like this:

func get_nearest_enemy(pos: Vector2) -> Enemy:
    var closest: Enemy = null
    var closest_dist: float = INF
    for e: Enemy in enemies:
        var d: float = e.position.distance_to(pos)
        if d < closest_dist:
            closest = e
            closest_dist = d
    return closest

The dynamic version compiles. It even runs. But it skips every benefit you set up the typed style for: no IDE autocomplete on the return value, no type-mismatch checks, no opcode optimization. Worse, the next person editing the file has to mentally track which variables are which type.

This is one reason game-dev-specific tools beat generic chat assistants. Tools like Ziva (an AI agent built into the Godot editor) read your existing code style before generating new code, so a typed file gets typed completions. Generic assistants train on whatever GDScript samples were on the open web at scrape time, which skews dynamic.

If you are using a generic assistant, the workaround is to put the typed signature in the prompt: "write get_nearest_enemy(pos: Vector2) -> Enemy: that does X". The constraint is enough to flip the generation style.

How to enforce typing in your project

Godot has a project setting for warnings on untyped declarations. Turn the relevant ones on:

Project Settings -> Debug -> GDScript:
  - "Untyped Declaration": Warn
  - "Inferred Declaration": Warn
  - "Unsafe Method Access": Error
  - "Return Value Discarded": Warn

Set "Treat Warnings as Errors" if you want hard enforcement. I treat untyped declarations as warnings only because mixing typed and untyped is occasionally pragmatic. You might want a generic helper that takes any value. But unsafe method access on untyped variables (the kind that crashes at runtime) is always an error.

Allen Pestaluky has a deeper guide on each warning and what to set it to.

What I changed in my workflow

After the typing audit I made three habit changes:

Every new function declaration starts with a return type. Even -> void. The editor refuses to autocomplete properly without it.
Every var either gets a type annotation or uses := for inference. Bare var x = ... is now a code smell I look for in PRs.
Class members at the top of a script always have explicit types. Inference inside functions is fine; inference on class state means the next reader has to scroll to the assignment to figure out what the type is.

The cost of these habits is roughly one extra word per declaration. The benefit is a compiler that finds bugs before I do.

If you maintain a Godot 4 project that has not had a typing pass, give it one evening. The bugs you find will pay for the time. The performance will be a nice surprise.

How to Profile GDScript Performance in Godot 4: A 2026 Guide

Ziva — Thu, 07 May 2026 14:52:28 +0000

Profiling GDScript is one of those things every Godot developer eventually learns the hard way. The first time you ship a build that drops to 22 fps on a mid-tier laptop, you discover the profiler exists, you open it, and the numbers stare back at you with no obvious next step.

This is the guide I wish I had when I started. It covers what changed in Godot 4.6's unified docking, how to use the built-in profiler properly, when to reach for external tracing profilers like Tracy, and the four common GDScript bottlenecks that cause most of the frame-time damage.

Three things I got wrong before I read the docs

Profiling in the editor. The Godot editor adds overhead to every frame, so the numbers you see when you press F6 inside the editor are not the numbers your players see. Godot's own docs are explicit about this: "for accurate performance numbers, profile an exported build". Half the optimizations I "made" in 2024 were undoing imaginary problems.

Treating frame time as one number. Frame time has at least three layers: CPU work in your scripts, CPU work in the engine, and GPU work in the renderer. The Monitor tab gives you a single FPS number that mashes all three together. The Profiler tab is what splits it.

Not enabling typed code. The single largest source of GDScript performance complaints I see on the forums is untyped code. From the Godot performance docs on CPU optimization: "Untyped variables require the runtime to determine the type and dispatch the correct operation on every operation, while typed variables skip this resolution." Same for arrays. If your hot loops use var arr = [] instead of var arr: Array[int] = [], that is your low-hanging fruit before you ever touch the profiler.

Step 1: Open the right panel

The profiling tools live in the Debugger panel at the bottom of the editor. With Godot 4.6, the Debugger is now a regular dock that can be moved or floated, which is useful if you have a vertical monitor and want the profiler in a side column.

Three tabs matter for performance:

Profiler. Per-script function call timings, sorted by self time or total time. This is where you find the slow function.
Monitors. Live graphs of FPS, memory, draw calls, physics steps, and more. Good for catching trends over a play session.
Visual Profiler. Per-frame breakdown of the renderer cost. Godot 4.7 dev 4 added folding support to the Visual Profiler tree, which makes it usable on complex frames.

The Profiler does not record by default. You have to click "Start" before you reproduce the slow scenario, and "Stop" when you are done. The docs note that profiling is performance-intensive because it instruments every frame, so leaving it on the whole session will distort the readings of the very thing you are measuring.

Step 2: Find the slow function

Sort the Profiler results by Self Time first, not Total Time. Self Time is what the function itself does, excluding everything it calls. Total Time can be misleading: a function that calls a slow library will show high Total Time but the fix is downstream.

Common patterns I see in real Godot 4 projects:

A _process callback that runs get_tree().get_nodes_in_group(...) every frame.
A _physics_process doing string concatenation for debug output that ships in release builds.
A loop that calls Vector2.distance_to instead of distance_squared_to for a comparison check.
A signal connected in _ready that fires multiple times per frame because it was also connected in _enter_tree.

The profiler tells you which function. Reading the function tells you which of these patterns it is.

Step 3: Use custom monitors for things the built-in graphs miss

The built-in Monitors tab has roughly 30 metrics. None of them know what your game does. If you want to track "active enemies on screen" or "outstanding network requests" or "items in the loot pool," you have to add a custom monitor.

The API is straightforward. From the custom performance monitors docs:

extends Node

func _ready() -> void:
    Performance.add_custom_monitor("game/active_enemies", _count_enemies)
    Performance.add_custom_monitor("game/loot_drops_per_minute", _loot_rate)

func _count_enemies() -> int:
    return get_tree().get_nodes_in_group("enemies").size()

func _loot_rate() -> float:
    return loot_log.size() / max(0.01, time_played_minutes)

The metric appears under your category in the Monitors tab next session. Custom monitors are the cheapest way to validate that what you think your game is doing matches what it actually does.

Step 4: Reach for external tracers when the built-in profiler isn't enough

Godot 4.6 added support for tracing profilers like Tracy, Perfetto, and Apple Instruments. These give you per-frame, per-thread, microsecond-level visibility into the engine internals, useful when the bottleneck is in the renderer or physics step rather than your script.

When to reach for external profilers:

Symptom	Try first
Slow function in your code	Built-in Profiler tab
FPS drops on specific scenes	Visual Profiler tab
Stutters that don't show up in script timings	Tracy or Perfetto
Mac-specific performance problem	Apple Instruments
Frame pacing or VRR issues	RenderDoc or PIX (per platform)

Tracy is the one most commonly reported as worth the setup cost for indie projects. The build needs to be compiled with the Tracy hooks enabled, which is heavier than the built-in tools, but the resolution is in a different league.

Step 5: Fix the four GDScript patterns that account for most of the damage

After you have a profiler trace and you know which function is slow, the fix is usually one of four things.

Untyped variables and arrays. Add types. var hp: int = 100 is faster than var hp = 100. var enemies: Array[Enemy] = [] is faster than var enemies = []. The cost is one annotation per declaration. The benefit is the runtime skipping the type-resolve step on every access.

get_node, get_tree, get_nodes_in_group in hot loops. These walk the scene tree on every call. Cache the result in _ready and store it as @onready var hud: HUD = $UI/HUD. Same for get_tree().get_root() and group lookups.

String operations in _process. str(x) + " " + str(y) allocates two strings per frame. Use "%d %d" % [x, y] if you need formatting, or move the string work behind an if Engine.is_editor_hint() so it only runs in debug.

Signal duplication. connect() does not deduplicate. If _ready and _enter_tree both connect to the same signal, the slot fires twice per emit. The fix is to check is_connected() first, or only connect in one lifecycle hook.

Step 6: Read the profile, not the code, for confirmation

The discipline that took me longest to internalize: do not optimize from intuition. Profile, change one thing, profile again, confirm the number moved in the direction you expected. Half the "optimizations" that look obvious in code do nothing for frame time, and a few make it worse.

If you have an AI assistant in your editor, this is one of the few places where it can pull weight without making things worse. Ask it to read the profiler dump and the slow function side by side and propose a hypothesis. Tools like Ziva that run inside Godot can read the actual scene tree and the actual project structure, which matters here because most GDScript performance problems are about how a script interacts with the rest of the project, not about the script in isolation. Generic chat tools that only see the script text miss the cross-cutting issues.

What to skip

A few things are not worth your time at the start:

Premature static typing of every single variable in your codebase. Type the hot loops first.
Refactoring Vector2 math to use a custom struct. The engine version is fine; your bottleneck is elsewhere.
Replacing GDScript with C# for "performance." GDScript and C# benchmarks are competitive in Godot 4 for most game logic. C# helps when you have CPU-bound math kernels. It does not help when your problem is get_nodes_in_group in _process.

The two-line summary: profile exported builds, type your hot loops, cache scene tree lookups in _ready, and use external tracers only after the built-in profiler tells you the bottleneck is not in your code. Most performance problems in shipped Godot projects are one of these four things, and the profiler will tell you which one if you let it.

VirtualJoystick in Godot 4.7: Endlich ein nativer Touchscreen-Stick

Ziva — Fri, 01 May 2026 17:41:44 +0000

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:

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.
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.

Generación procedural en Godot 4: guía práctica con GDScript

Ziva — Tue, 28 Apr 2026 23:46:37 +0000

La generación procedural es una de las características que más diferencia un juego indie en Steam de un juego de portfolio. Roguelikes, sandboxes, dungeon crawlers, todos dependen de algún sistema procedural. En Godot 4 hay tres patrones que cubren el 80 por ciento de los casos de uso, y aún así hay sutilezas que la mayoría de tutoriales pasan por alto.

Voy a recorrer los tres patrones, las trampas reales que aparecen al implementarlos, y por qué los asistentes de IA tienden a generar código procedural que parece correcto pero produce mundos rotos.

Patrón 1: Generación basada en ruido (Perlin/Simplex)

Godot 4 incluye FastNoiseLite con varios tipos de ruido (Perlin, Simplex, Value, Cellular). Es el camino más corto para generar terrenos, mapas de calor, distribuciones de recursos.

@onready var noise := FastNoiseLite.new()

func _ready():
    noise.noise_type = FastNoiseLite.TYPE_SIMPLEX_SMOOTH
    noise.seed = randi()
    noise.frequency = 0.05

func get_height(x: int, y: int) -> float:
    return noise.get_noise_2d(x, y)

La trampa principal: la frecuencia. Demasiado baja (0.001) y obtienes una superficie casi plana. Demasiado alta (0.5) y obtienes ruido aleatorio sin estructura. La mayoría de problemas de "mi terreno se ve raro" son problemas de frecuencia mal calibrada.

Otra trampa común: usar randi() como seed sin guardarla. Si quieres reproducibilidad (necesario para multiplayer y depuración), guarda la seed que usaste.

Patrón 2: Generación basada en celdas (cellular automata)

Para cuevas, islas, distribuciones orgánicas, los autómatas celulares son superiores al ruido. El algoritmo clásico:

Llena una grilla aleatoriamente con piedra (1) y aire (0).
Para N iteraciones: para cada celda, cuenta sus vecinos. Si tiene >= 4 vecinos sólidos, se vuelve sólida. Si no, se vuelve aire.
Después de 4-5 iteraciones, los grupos pequeños desaparecen y emergen cuevas naturales.

func cellular_step(grid: Array) -> Array:
    var new_grid = grid.duplicate(true)
    for x in grid.size():
        for y in grid[0].size():
            var neighbors = count_neighbors(grid, x, y)
            new_grid[x][y] = 1 if neighbors >= 4 else 0
    return new_grid

Trampa: la primera iteración necesita cuidado en los bordes. Si tu count_neighbors no maneja los bordes correctamente, las cuevas pegadas al borde del mapa se rompen.

Patrón 3: BSP (Binary Space Partitioning)

Para mazmorras estructuradas con habitaciones y pasillos, BSP es el estándar de la industria. Divides el mapa recursivamente en dos, paras cuando los rectángulos son del tamaño de una habitación, colocas una habitación en cada hoja, y conectas habitaciones con pasillos siguiendo la jerarquía del árbol.

Este es el patrón más complicado de los tres, porque combina recursión, geometría 2D, y un grafo de conectividad. Es también donde más fallan los asistentes de IA.

Por qué la IA genera código procedural roto

Cuando le pides a ChatGPT, Claude o Cursor que genere un sistema procedural en GDScript, suele producir código que compila y ejecuta, pero genera mundos visiblemente rotos. Las razones recurrentes:

Frecuencias de ruido sin calibrar. El modelo elige un valor "estándar" (0.1) que solo funciona para escalas específicas. Si tu mapa es de 1000x1000 tiles, no va a verse bien con esa frecuencia.

Bucles sin guardas. El cellular automata necesita un número fijo de iteraciones. La IA a veces escribe while not stable: sin definir bien stable, y el bucle nunca termina o termina muy pronto.

Manejo de bordes inconsistente. Wrap, clamp, o ignorar son tres opciones válidas según el tipo de mundo. La IA mezcla las tres en el mismo proyecto.

Seed no guardada. El código genera un mundo bonito una vez y luego nunca puedes reproducirlo. La IA omite el almacenamiento de la seed por defecto.

Esto encaja con el patrón general de fallos silenciosos en código generado por IA. El reporte Sonarsource State of Code 2026 reporta que el 60 por ciento de los fallos en código generado por IA son "fallos silenciosos": código que compila, parece correcto, y produce resultados incorrectos. La generación procedural es un caso particularmente afectado, porque el "resultado correcto" es subjetivo (un mundo visualmente plausible) y no hay test unitario que lo capture.

Cómo verificar generación procedural

Tres reglas prácticas:

Visualiza siempre. No confíes en que un mundo "se ve bien" porque el código corre. Genera 10 mundos, mira los 10. Las trampas de calibración aparecen como "mundos demasiado parecidos" o "mundos demasiado caóticos."

Guarda la seed que produjo el bug. Cuando un mundo procedural se vea raro, copia la seed que lo generó al portapapeles. Sin la seed, no puedes reproducir el bug.

Usa herramientas que ejecuten el código en Godot. Una clase emergente de herramientas (proyectos como Ziva específicamente para Godot) ejecuta el código generado dentro del editor, observa el resultado, y reacciona cuando el mundo se ve roto. Eso cierra el bucle entre "el código compila" y "el código produce un mundo jugable."

Conclusión

Los tres patrones (ruido, celular, BSP) cubren la mayoría de necesidades procedurales en juegos indie. Cada uno tiene trampas que la IA tiende a pasar por alto. La defensa más fuerte es siempre la misma: ejecuta el código en Godot, observa el resultado, no confíes en que "el código compila" significa "el mundo está bien."

Para tu próximo proyecto procedural en Godot, empieza con FastNoiseLite y calibra la frecuencia visualmente. Cuando necesites estructura (habitaciones, conectividad), pasa a BSP. Para orgánicos, autómatas celulares. Y guarda esa seed.

KI-Tools in Godot 2026: Was funktioniert, was scheitert

Ziva — Tue, 28 Apr 2026 23:44:04 +0000

Wer 2026 mit Godot anfängt und nach KI-Hilfe sucht, stößt auf ein Problem, das in Tutorials selten erwähnt wird: ChatGPT und Claude können GDScript zwar gut schreiben, aber sie wissen nicht, wie das Godot-Projekt strukturiert ist, das du gerade aufbaust. Sie raten. Manchmal richtig, oft daneben.

Ich nutze KI-Tools seit Jahren beim Webentwicklung und seit etwa 8 Monaten in Godot. Die Erfahrung ist deutlich anders. Hier eine ehrliche Übersicht, was 2026 in Godot mit KI funktioniert und was nicht.

Was funktioniert

Boilerplate für gängige Patterns. Ein Player-Controller mit CharacterBody2D, Eingabebehandlung über Input.get_axis(), Sprung-Logik mit Coyote-Time, all das schreiben generische KI-Tools korrekt. Wenn du ein Standard-Pattern willst, ist das schneller als selbst tippen.

Erklärung von Engine-Features. Wenn du nicht verstehst, was _physics_process vs _process macht, oder wann du queue_free() statt free() verwendest, sind LLMs eine sinnvolle Lernhilfe. Die Grundkonzepte sitzen ausreichend gut im Trainingsmaterial.

GDScript-Syntax und Typen. Godot 4.x Typing (var hp: int = 100) wird korrekt gehandhabt. @export-Annotationen, @onready, das funktioniert in 95 Prozent der Fälle.

Refactoring von eigenen Skripten. Ein vorhandenes Skript in mehrere Klassen aufteilen, Magic Numbers extrahieren, Funktionen umbenennen, das macht generische KI gut.

Was nicht funktioniert

Signale, die zur Laufzeit gebunden werden. Die KI sieht nur den Quellcode. Sie kann nicht überprüfen, ob ein connect()-Aufruf zum Zeitpunkt der Emission noch gültig ist, ob der Receiver freigegeben wurde, ob die Verbindung doppelt existiert. Ein Großteil der "fast richtigen" Godot-Bugs sind Signal-Bugs.

AnimationTree-Verkabelung. Der parameters/playback-Pfad ist ein String. Generische KI tippt diese Strings souverän falsch ab und merkt es nicht. Die Animation läuft einfach nicht. Kein Fehler.

Szenenpfade in load(). Die KI nimmt an, dein Projekt sei strukturiert wie das erste Tutorial, das sie gelernt hat. Wenn deine Player.tscn woanders liegt, gibt load() null zurück, und die KI merkt es nicht.

Autoload-Referenzen. AudioManager.play("hit") setzt voraus, dass AudioManager als Autoload registriert ist. KI-generierte Code überspringt diesen Check standardmäßig. Du bekommst NIL-Errors zur Laufzeit.

Plattform-spezifischer Export-Code. Web-Export, Mobile-Export, Konsolen-Build-Konfigurationen sind in den Trainingsdaten unterrepräsentiert. Hier rät die KI sehr.

Warum das passiert

Der zugrundeliegende Grund ist einfach: 60 Prozent der Fehler in KI-generiertem Code sind laut Sonarsource State of Code Report 2026 "stille Fehler". Code, der kompiliert, plausibel aussieht und in der Produktion das Falsche tut. In Godot ist "Produktion" der erste Druck auf F5.

Die Stack Overflow Developer Survey 2025 zeigt zudem: 84 Prozent der Entwickler nutzen KI, nur 29 Prozent vertrauen den Ergebnissen. Bei Godot-Devs ist das Vertrauensniveau noch niedriger, weil die Fehler stiller sind.

Was 2026 hilft

Drei praktische Tipps, die wirklich Zeit sparen:

Run-then-paste statt paste-then-run. Lass die KI Code generieren, paste ihn ein, drücke F5 BEVOR du committest. Das Output-Panel von Godot zeigt die meisten stillen Fehler innerhalb von Sekunden.

is_connected()-Guards bei disconnect(). Das ist die billigste Defensiv-Praxis, die du KI-Code hinzufügen kannst. Sie verhindert eine ganze Klasse von "signal not connected"-Fehlern beim Szenenwechsel.

Engine-bewusste KI-Tools, wo möglich. Eine kleine, aber wachsende Klasse von Tools (Projekte wie Ziva für Godot speziell) integriert sich direkt in den Godot-Editor. Der Agent kann die Szene laden, F5 drücken, die Ausgabe lesen, und reagieren, wenn das Signal nicht gefeuert hat. Das schließt die Lücke zwischen "Code sieht richtig aus" und "Code funktioniert."

Fazit für deutsche Godot-Entwickler

Generische KI-Tools sind 2026 nicht überflüssig, aber sie sind nicht das Endgame. Die nächste Generation von Godot-Tools ist engine-aware, kennt die Szenenhierarchie, kann F5 drücken. Wenn du gerade mit KI-gestützter Godot-Entwicklung anfängst, würde ich empfehlen:

Generische LLMs für Konzepte und GDScript-Syntax verwenden.
Kritische Engine-Pfade (Signale, AnimationTree, Autoloads) IMMER manuell testen.
Ein engine-aware Tool ausprobieren, wenn du regelmäßig Godot-Code schreibst.

Die Stunden, die du beim Debuggen "fast richtigen" KI-Codes sparst, summieren sich schnell. Was ich als Faustregel gelernt habe: KI-Code, der nicht in der Engine ausgeführt wurde, ist KI-Code, dem du nicht trauen solltest.

Testing Godot Code Is Harder Than Testing a Webapp. Here's What Helps.

Ziva — Tue, 28 Apr 2026 23:23:26 +0000

If you've come from web development, you have muscle memory for testing. Spin up Jest, mock the database, hit the route, assert. Or use Playwright to drive a headless browser through a flow. CI runs the suite on every PR. You know the loop.

Then you open a Godot project. The web testing playbook breaks in five places before you finish your morning coffee.

I'm writing this because the gap between "AI wrote my Godot code" and "the code actually works" is mostly testing, and most of the testing tooling for Godot is one or two layers behind what web devs are used to. Here's what's different and what currently helps.

Godot doesn't have a default headless test mode that just works

A web project ships with a test framework on day one. Jest is built into Create React App. Vitest is the Vite default. You inherit a working test runner before you've written a line of business logic.

A Godot project ships with the editor and _ready(). There is no default test framework. The community standard, GUT (Godot Unit Testing), is a third-party plugin you install yourself. It's good. It's also one of those "obvious in hindsight, surprising on day one" gaps when you arrive from a webdev background.

There's also GodotTestDriver for integration tests, and Godot does support a --headless mode for running scenes without a window. But none of this is wired up out of the box, and the headless mode has quirks: rendering-dependent code (anything that uses Viewport.get_texture(), for example) silently produces empty results.

The state of your scene tree is invisible to most test runners

Web tests deal with three kinds of state: the DOM, your store, and the database. All three are introspectable. You can screen.getByRole('button'), you can read Redux state, you can SELECT * from the test DB.

Godot has a fourth kind: the scene tree. Nodes have parents. Signals connect nodes to other nodes. The active StateMachine state is buried inside an AnimationTree's parameters/playback property. None of this surfaces in a stack trace. None of it is in a test database. You can write a unit test that verifies your signal-emitting function fires the signal, and still have a broken game because the receiving node was freed two frames earlier.

This is the failure mode that bit me hardest moving from web to Godot: tests that pass in isolation, gameplay that breaks at runtime because the test runner doesn't know what the scene tree looked like when the bug happened.

GodotTestDriver helps here by providing a Fixture class that owns scene nodes during a test and tears them down cleanly. But you have to write integration tests that exercise actual scene behavior, not just unit tests that exercise pure functions. Most game logic is not pure functions.

Most AI-generated Godot code never gets run before it ships

The 2026 Sonarsource State of Code report found that 60% of faults in AI-generated code are "silent failures." Code that compiles, looks right, and produces wrong results in production. The 2025 Stack Overflow Developer Survey shows trust in AI output dropped from 40% to 29%, with 66% of devs citing "almost-right" code as their top frustration.

For a webdev, this hurts a little. Type-check catches some of it. Failing test catches more. The user-visible failure mode is a 500 error and a Sentry alert.

For a Godot dev, the same code can ship without anything obvious going wrong. The build succeeds. The editor doesn't complain. You press Play, the scene loads, your character moves around. Then you realize the death animation isn't playing because the signal was connected to a node that gets freed before the signal fires. There's no exception. There's no log line. The gameplay is just slightly wrong.

Pasting AI-generated code into Godot without running it in the engine first is the equivalent of merging an untested PR straight to production. Web devs would never do that. Godot devs do it constantly, because the tooling makes it the path of least resistance.

What helps

A few things narrow the gap.

Run a smoke test scene before pasting AI output. Open the project, open the scene, press F5. If the AI's change broke node references or signal wiring, you'll see it in the output panel within seconds. This sounds obvious. It's also the thing most people skip because the dev/AI/dev/AI loop has too many context switches.

Add GUT and write integration tests for systems that touch the scene tree. Pure-function tests are not enough for Godot. You need tests that load a scene, fire input, advance the frame, and assert on the resulting state. GUT supports this with add_child_autofree() and the await keyword for waiting on signals.

Use AI tools that integrate with the engine, not just the editor. Most AI coding tools edit text files and stop. They have no view into the scene tree, no way to press Play, no read access to the Godot output panel. A small but growing class of tools (projects like Ziva for Godot specifically) wire the AI agent to the engine itself, so the same model that writes the code can run the scene, watch the output, and react when a signal didn't fire. That's the part of the loop that closes the gap between "code looks right" and "code works."

Treat headless CI as a goal, not a starting point. You will not have headless CI on day one of a Godot project. That's fine. Get to the point where you can press Play and watch a smoke test scene first. Build up to running tests on a CI runner with --headless later. Web devs are used to that order being reversed; in Godot it's almost always smoke-test-first.

The honest summary

Game dev testing is harder than webapp testing in 2026. The frameworks are younger. The state model is more complex. The default failure mode is silent. AI-generated code raises the floor for syntax correctness and lowers the floor for runtime correctness in ways that are particularly bad for game projects, because game projects already had a runtime correctness problem.

If you're a web dev experimenting with Godot and you're confused why your AI-assisted prototype keeps almost-but-not-quite working, this is most of the answer. The fix is upstream of the AI: better integration between the model writing the code and the engine running the code. The community is figuring this out in real time, and the tooling is improving fast.

In the meantime, press Play before you commit.

Domain-Specific AI Beats General AI on Niche Code. Here is Why.

Ziva — Fri, 24 Apr 2026 21:34:02 +0000

If your AI coding assistant is great at React but keeps hallucinating on your Django ORM, or fine with Python but useless on your Rust lifetimes, or solid with webdev but writes broken Godot scripts, this post is for you. The pattern is consistent across domains: general-purpose AI coding tools have a frontier they do well inside, and everything outside that frontier gets progressively worse.

This post is about why, what to do about it, and when staying with a general tool is still the right call.

The symptom

You ask a general AI assistant to write code for a framework or engine that is not in the top 20 most-discussed on Stack Overflow. The code looks plausible. It compiles sometimes. When it runs, it breaks in ways that make you question your sanity because the error message points somewhere unrelated to the actual bug.

You paste the error back. The AI apologizes and writes a different wrong version. Forty minutes in, you give up and do it yourself.

Claude Code, GitHub Copilot, and Cursor all hit this wall. It is not about which model is better. It is about the distribution of training data and the lack of runtime context for the specific project you are working on.

Why it happens

Three overlapping causes.

Training data frequency. LLMs get better at code patterns that appear often in their training corpus. A framework with 100K GitHub repos gets way more attention than one with 1K. This is why React code is almost always right and Godot GDScript code is often half wrong. DEV.to's community analysis of gamedev engagement shows the gap: gamedev posts get 10 to 20 reactions while webdev posts regularly clear 200.

Context window limits plus "lost in the middle". Context windows grew to 200K, 1M, and beyond over 2024-2026, which sounded like it would fix everything. It did not. Studies of long-context retrieval found that information buried in the middle of a large context window is retrieved worse than information at the start or end. Paste your whole codebase, and the model will happily ignore the autoload registration on line 11,000 that breaks everything.

No runtime state. A pasted codebase is static. The actual project has scene trees, registered globals, input maps, environment variables, database schemas, and build outputs that the AI cannot see through pasting alone. For niche frameworks where the runtime state matters a lot, the AI is guessing at half of the problem.

What "domain-specific" actually means

There are three tiers of AI coding tool, and the names get confusing.

Tier	Example	What it knows
General-purpose	ChatGPT, Claude, basic Copilot	Syntax, patterns, public docs
IDE-integrated	Cursor, Claude Code, full Copilot	Syntax plus your codebase
Domain-specific	Tools like Ziva for Godot, framework-specific helpers	Syntax, codebase, and runtime state for one ecosystem

The third tier is what this post is about. A domain-specific AI is one whose training, retrieval, and context gathering are built around a single ecosystem. It reads the framework's current release notes, the runtime state of your specific project, and the niche APIs that general AI glosses over.

The narrow bet is: on the domain it covers, it outperforms general AI. Off-domain, it does nothing.

When general AI is still the right call

Domain-specific tools are a tradeoff. If your work spans 5 different stacks on a given week, you do not want 5 different AI assistants. The context switching and subscription overhead kills the win.

General AI is the right call when:

Your code is in a high-training-frequency ecosystem (React, Django, Rails, Spring, Express).
You work across many stacks and need one tool that handles all of them.
The niche parts of your work are small and you can fix them yourself.

Domain-specific AI starts earning its keep when:

You spend the majority of your week in one ecosystem.
That ecosystem has framework-specific patterns the AI keeps getting wrong.
You have hit the "AI wrote 40 lines of confident-looking garbage" wall more than once.

The practical test

Before committing to a domain-specific tool, run this test. Take three tasks you did this week in your niche framework. Hand them to a general AI with the full relevant file pasted in. Measure:

Did the generated code compile or run on the first attempt?
Did it use APIs that actually exist in your framework version?
Did it reference existing project structures (globals, singletons, shared resources) correctly?

If you get two out of three, you are fine. General AI is working for you.

If you are below that, the cost of a specialized tool is probably worth it. At that point, you are paying in compounding time loss, not just single-task friction.

What this looks like in practice

For Godot specifically, tools like Ziva that run inside the editor and read project state directly get the autoload, scene-tree, and signal context that a chat-based AI cannot. For Rust, tools that understand borrow-check state across your project do better than generic completion. For Django, ORM-aware tools outperform generic ones on query optimization.

The pattern holds across ecosystems. The bet is the same: narrow your AI's surface area so the context it has is actually useful, and accept that it does not work outside that surface.

What I would not do

Do not buy a specialized AI for every framework you touch. The tradeoff only makes sense when the time you save exceeds the time you lose to juggling tools.

Do not expect a domain-specific AI to fix a problem that is not domain-specific. If your issue is bad code architecture or unclear requirements, a better AI will not save you.

Do not assume "domain-specific" means better. It means narrow. On the ecosystem it covers, it should outperform general AI. Off the ecosystem, it does nothing. Measure before you switch, and measure after.

The short version

General AI is great at code patterns that show up a lot in its training data. It gets progressively worse on niche frameworks, version-specific features, and anything that requires runtime project state. Bigger context windows do not fix this. Domain-specific tools exist for the cases where the gap is costing you time.

Whether you need one depends on how much of your week is in the niche. Run the three-task test before you decide.

Cómo llegar a 1000 wishlists en Steam con tu juego de Godot

Ziva — Tue, 21 Apr 2026 00:14:58 +0000

Si estás desarrollando tu primer juego en Godot y apuntas a Steam, el número que más importa no es cuánto dinero vas a hacer. Es cuántas wishlists acumulas antes del lanzamiento. La data de 2026 es clara: las wishlists pre-lanzamiento correlacionan con las ventas de la primera semana a r = 0.825, según el survey de Chris Zukowski de 182 desarrolladores que participaron en Steam Next Fest de febrero 2026.

El problema es que la mediana de un Next Fest suma 806 wishlists. Si entras con cero seguidores, el resultado más probable es que termines con 322 wishlists sumadas en toda la semana. Eso no alcanza.

Te voy a contar lo que funciona para llegar a 1000 wishlists antes del lanzamiento, basado en lo que los devs que shipearon en Godot en 2025-2026 realmente hicieron.

Subí la página de Steam lo antes posible

El algoritmo de Steam premia velocidad, no acumulación. Un juego que lleva 3 meses con la página viva acumulando 10 wishlists por día (900 wishlists al final) termina con mejor señal algorítmica que uno que acumuló 900 wishlists en una sola semana viral.

Esto significa subir la Coming Soon page antes de tener el trailer final. Antes de tener la demo. El costo de equivocarse (actualizar capsules después) es mucho menor que el costo de empezar tarde.

Apuntá a 50 reviews, no a 10,000 wishlists

Una observación incómoda de los datos de 2026: Steam empieza a mostrar tu juego en superficies orgánicas (Popular Upcoming, Trending, More Like This) recién cuando cruzás las 50 reviews. Antes de eso sos invisible, sin importar si tenés 5,000 o 10,000 wishlists.

Esto cambia la estrategia. No necesitás 10,000 wishlists para lanzar. Necesitás suficiente audiencia para generar 50 reviews la primera semana. La aritmética: si tu conversion rate wishlist-to-buyer es 20% (normal para indie) y el 10% de compradores deja review, necesitás 2,500 wishlists para 50 reviews garantizadas. Por debajo de 2,500 estás apostando.

La demo temprano supera a la demo de último momento

Los juegos que lanzaron demo meses antes de Next Fest sumaron 2.5x más wishlists que los que lanzaron la demo durante el fest, según el mismo survey. La correlación no es gigante (r = -0.205) pero la dirección es consistente en tres ediciones de Next Fest seguidas.

Cairn, de The Game Bakers, lanzó su demo en diciembre 2024 y entró a Next Fest en octubre 2025. 16 meses de runway. Al momento del fest, la demo ya tenía 200,000+ downloads y el juego acumulaba 32,000 wishlists.

Para un dev solo en LatAm, la lección: no guardes la demo para "cuando esté perfecta". Lanzá a los 6 meses de desarrollo, aunque tengas solo 20 minutos jugables. Lo que buscás es tiempo en el algoritmo, no perfección en la demo.

Godot es el engine correcto para iterar rápido

Acá es donde la elección del engine importa. Godot 4.5 compila cambios en menos de 5 segundos en hardware mediano. Los archivos de escena son texto plano, así que podés usar git real sin los problemas del YAML de Unity. El shader baker de 4.5 te da 20x mejor load time en Metal y D3D12.

Para iteración semanal (que es lo que importa cuando estás respondiendo a feedback de tu Discord de 100 personas), Godot te saca como 15 minutos de cada ciclo comparado con Unity. Eso en 6 meses son ~30 horas de trabajo recuperadas.

Si estás usando una IA para generar código GDScript, herramientas como Ziva corren el código que generan contra el editor de Godot en vivo, lo que te evita el problema de que la IA alucine funciones de Godot 3 que ya no existen en 4.5. No es que sea mejor que escribir a mano, es que reduce el costo de "lo probé y no compila" a cero.

Marketing concentrado: 5 YouTubers, no 50

La distribución en español de Godot está concentrada. Hay 4-5 creators en YouTube y Twitch que cubren prácticamente toda la comunidad hispanohablante. Si tu demo es buena, no necesitás mandarles email a 200 influencers. Necesitás que 3 de esos 5 la mencionen. Eso te llega al 80% de tu audiencia hispanohablante potencial. La distribución concentrada en un engine chico es, desde el punto de vista de marketing indie, mejor que la distribución fragmentada de Unity.

Checklist de 6 meses

Si empezás hoy y apuntás a lanzar en 6 meses:

Mes 1-2: Subí la Coming Soon page. Capsules básicas, trailer de 30 segundos. Empezá a hacer devlog semanal en YouTube o TikTok.

Mes 3: Lanzá una demo de 15-20 minutos. No esperes a tener todo perfecto. La demo va a iterar.

Mes 4-5: Revisá las reviews de la demo semanalmente. Subí patches. Construí una comunidad de Discord de 50+ personas activas.

Mes 6: Entrá a Steam Next Fest de junio u octubre con una demo mejorada y ~3,000 wishlists acumuladas. El Next Fest te va a sumar 1,500-3,000 más si hiciste bien los meses anteriores.

Lanzá al mes 7 con ~5,000-7,000 wishlists. Primera semana: ~500 ventas, ~50 reviews. A partir de ahí, Steam empieza a trabajar a favor tuyo.

Ninguna de estas cifras garantiza éxito. El 91.5% de los juegos indie en Steam no pasan los $100K en ingresos brutos. Pero apuntar a 1,000 wishlists antes de lanzar con un plan claro es la diferencia entre tener una chance real y no tenerla.

7 Godot 4 API Calls Your AI Assistant Still Gets Wrong

Ziva — Mon, 20 Apr 2026 23:57:36 +0000

If you have asked Copilot, Claude, or ChatGPT to write Godot code in the last six months, you have hit this: the generated code looks reasonable, compiles clean, and then fails at runtime because the function name does not exist. Godot 4 shipped in March 2023 with a completely rewritten GDScript and dozens of renamed APIs. Training data for most LLMs still overrepresents Godot 3 tutorials. The result is an asymmetric failure mode: the code looks right, even to a reviewer who has not touched Godot 3, and you only find out it is broken when you run the game.

Here are seven of the most common API calls where AI assistants hallucinate the Godot 3 version, with the Godot 4 replacement and a short note on why each one specifically keeps tripping up the models.

1. `deg2rad` → `deg_to_rad`

The old name, deg2rad(angle), still appears all over Reddit and StackOverflow posts from 2020 to 2022. In Godot 4 it is deg_to_rad with underscores. Same for rad2deg → rad_to_deg.

This is the single most-hallucinated function in my experience. The numeric "2" in the old name is legacy from the C++ style used in older Godot versions, and the rename to a readable verb was one of the first things the Godot 4 style guide pushed. LLMs still reach for the short form because it is shorter and because the training data is denser.

2. `KinematicBody2D` → `CharacterBody2D`

Godot 3 had KinematicBody2D and KinematicBody (for 3D). Godot 4 renamed both to CharacterBody2D and CharacterBody3D. The internal semantics also changed: move_and_slide() no longer takes a velocity argument; you set velocity as a property first, then call the method.

AI assistants get the class rename right about half the time. Where they fail consistently is the call signature. You will see generated code like move_and_slide(velocity, Vector2.UP) which is valid Godot 3 and a runtime error in Godot 4.

3. `set_shader_param` → `set_shader_parameter`

ShaderMaterial.set_shader_param(name, value) became set_shader_parameter(name, value). The get_shader_param pair also renamed.

This one is tricky because shader workflow tutorials from the Godot 3 era are high-quality and heavily SEO-optimized. When an AI reaches for shader code, it reaches for the tutorial it was trained on, and that tutorial says set_shader_param.

4. `BUTTON_LEFT` → `MOUSE_BUTTON_LEFT`

Mouse button constants got a prefix. BUTTON_LEFT, BUTTON_RIGHT, BUTTON_MIDDLE, and the wheel constants are now MOUSE_BUTTON_*.

Why it matters: this is a runtime-only failure. If your input handler checks event.button_index == BUTTON_LEFT, the comparison never matches because BUTTON_LEFT resolves to a different numeric value (or doesn't exist at all, depending on how the constant is scoped).

5. `rand_range` → `randf_range` / `randi_range`

Godot 3's rand_range(min, max) returned a float. Godot 4 splits this into randf_range (float) and randi_range (int). The type-explicit naming is good. The fact that every AI assistant still generates rand_range is not.

6. `yield()` → `await`

Godot 3 used a custom yield() function for coroutines: yield(get_tree().create_timer(1.0), "timeout"). Godot 4 replaced this with standard await: await get_tree().create_timer(1.0).timeout.

This is the largest syntactic shift in the list, and the one where AI code breaks most visibly. yield() in Godot 4 is a Python-style function that does not exist. You get an immediate parse error, which at least makes it easy to catch. Compare that to the mouse button case, which silently fails forever.

7. `Directory` → `DirAccess` / `FileAccess`

The global Directory class, and its pair File, were both removed in Godot 4. The replacement is DirAccess and FileAccess, both with static factory methods: DirAccess.open(path) and FileAccess.open(path, FileAccess.READ).

The old class-based API used var f = File.new() followed by f.open(path, File.READ). AI assistants still reach for this because File I/O is one of the most commonly documented patterns and the old one was in wide circulation for years.

Why this keeps happening

Two forces make Godot particularly prone to this failure mode:

Training data density favors Godot 3. Godot 4 launched in March 2023. The bulk of high-quality community tutorials, Reddit answers, and StackOverflow posts were written before that. When an LLM computes "what is the most likely next token after shader_," the frequency of param in the training corpus still dominates parameter.

Godot 4 minor versions keep changing signatures. The Godot 4.5 release notes mention variadic function signature changes that broke compatibility with 4.3 and 4.4. Even a model with training data that ends in late 2025 has not seen enough 4.5 examples to correctly weight them.

The result: the newer your Godot version, the worse any general-purpose coding assistant performs. This is not a problem that gets solved by a bigger context window. It gets solved by giving the model the current API, either through retrieval-augmented generation against Godot's docs or through a purpose-built plugin that can run the code and test the output.

How to work around it

Three things help:

Paste the Godot 4.x breaking changes list into your system prompt. It is a short file maintained by a Godot contributor and it catches most of the renames. A 2-page addendum to the system prompt is worth more than any clever reasoning you can add.
Use an agent that runs the code it generates. A parse error catches yield(). A runtime test catches BUTTON_LEFT. The mouse button case specifically cannot be caught by any static linter because the comparison is syntactically valid. Tools like Ziva solve this by running the generated code against a live Godot editor and surfacing runtime errors back to the model, but any setup that executes the code will catch the silent-failure cases that matter most.
Prefer static typing. Godot 4 supports var velocity: Vector2. Typed variables turn some of these hallucinations into editor errors. It does not help with constants or function names, but it catches a surprising number of incompatible signature cases.

If you are shipping a Godot game in 2026 and letting AI generate scripts, the practical move is to pair any generation step with an execution step. "Does it compile" is not the right test. The right test is "does the node still behave correctly when you run the scene." Everything else is theater.

Godot 4.4 Added .uid Files Everywhere. Here's What They Actually Do.

Ziva — Mon, 20 Apr 2026 00:38:57 +0000

If you upgraded a Godot project from 4.3 to 4.4 and suddenly saw a wave of new .uid files next to every .gd and .gdshader, you were not alone. Every GitHub thread I found from early 2025 had someone asking whether to delete them, gitignore them, or commit them.

The answer is: commit them. They are not noise. They fix a real problem Godot has had since day one, and understanding them is the difference between a clean refactor and a broken scene tree the next morning.

The problem the .uid files solve

Before 4.4, Godot referenced every resource by its file path. If you moved res://scripts/player.gd to res://entities/player/player.gd without doing it through the editor, every scene that referenced that script would break. The typical workflow for a larger team looked like:

Refactor the folder structure outside the editor (in VS Code or the terminal)
Reopen Godot
Watch half your scenes fail to load
Manually re-link every broken reference in the inspector

Godot already used UIDs for scenes and most imported resources. But scripts and shaders were excluded because they are plain text files with no place to store engine metadata. You moved player.gd and Godot had no way to know it was still the same script.

The 4.4 release solves that with sidecar files. player.gd now ships with player.gd.uid alongside it. The .uid file contains a single line: a UID like uid://c82j4l3r4k4n2. Every scene that references that script stores the UID, not the path. Move the file to another folder, and Godot finds it through the UID.

What file types got .uid files

The Godot blog post is explicit about which types are affected:

Source file	Sidecar file
`.gd` (GDScript)	`.gd.uid`
`.cs` (C#)	`.cs.uid`
`.gdshader` (shader)	`.gdshader.uid`
`.gdshaderinc`	`.gdshaderinc.uid`

Scenes (.tscn) and most imported resources already had UIDs stored in their own headers since earlier versions, so they did not need sidecars. This change is specifically for the plain-text formats that previously had no UID hook.

The .gitignore mistake

The single biggest footgun with the new system is treating .uid files like build artifacts and adding them to .gitignore. I have seen this in multiple public Godot repos since the 4.4 release. If you gitignore .uid, every clone of your repo generates fresh UIDs, and every scene that references your scripts points at UIDs that exist only on the original author's machine. The project opens, the scripts technically load, but the scene-to-script links are now broken for every collaborator.

The correct answer, per the Godot team: commit the .uid files to version control. They are part of your project state, not generated output.

What this means for external refactoring

The part I like most is that moving files outside the editor is now officially supported. Before 4.4, the unwritten rule was "always do refactors inside Godot." Now you can:

Close Godot
Run git mv or mv on any script or shader, together with its .uid sidecar
Reopen Godot

The editor looks up the UID, finds the file in its new location, and updates the path in any referencing scene when you save. Nothing breaks. This is the kind of affordance that only matters when your project is large enough that "refactor inside the editor" becomes tedious, but at that point it matters a lot.

One gotcha: the UID cache can lag

There is a known bug where renaming a scene file externally does not immediately update the UID cache, which can cause temporary stale references. The fix is to reopen the project so Godot rescans the filesystem. The bug is open as of writing and affects the 4.4 line; the 4.6 release did not mark it as fixed. If you hit it, reopening the project clears it.

What this has to do with AI coding tools

Every AI assistant trained on pre-4.4 Godot does not know what a .uid file is. Ask ChatGPT or a generic coding assistant to refactor your Godot project's folder structure, and it will happily suggest moving scripts without moving their .uid sidecars. You run the suggested commands, reopen the editor, and watch your scenes break in the exact way the UID system was designed to prevent.

Tools that run natively inside the Godot editor (there are a handful now, Ziva being one of them) have a structural advantage here: they can read the current UID index directly, know which sidecar belongs to which source file, and keep them together on any file operation. The generic chatbot approach cannot do this. It can only suggest; it cannot see.

If you are evaluating AI tooling for Godot work, this is the kind of thing to test. Ask your candidate tool to move player.gd from one folder to another and see whether it touches the .uid file. If not, expect broken scenes.

Practical migration checklist

If you are upgrading a Godot 4.3 project to 4.4 or later today, three things make the transition painless:

Open the project in 4.4 and re-save every scene. The editor regenerates UID references in each scene file, which is what makes the sidecars useful. This is a one-time cleanup.
Remove any *.uid entry from your .gitignore if it exists. Commit the files. They are ~30 bytes each and they are part of the project.
When moving files externally, always move the .uid alongside. git mv player.gd entities/player/player.gd && git mv player.gd.uid entities/player/player.gd.uid is the pattern.

The UID system is one of the Godot 4.x changes that feels invisible until it saves you an afternoon of re-linking references. Treat the sidecar files the way you treat package-lock.json or Cargo.lock: commit them and forget about them.