Forem: Ziva

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.

Warum Slay the Spire 2 auf Godot setzt (und was das für Entwickler bedeutet)

Ziva — Mon, 13 Apr 2026 21:39:17 +0000

Slay the Spire 2 hat am 5. März 2026 574.638 gleichzeitige Spieler auf Steam erreicht. Gebaut auf Godot. Nicht Unity. Nicht Unreal. Das Open-Source-Projekt, das viele noch vor drei Jahren als Hobby-Engine abgetan haben.

Das ist kein Einzelfall. Die Daten zeigen einen klaren Trend.

Was passiert ist

Mega Crit hatte über zwei Jahre an Slay the Spire 2 in Unity gearbeitet. Im September 2023 kündigte Unity die Runtime-Gebühr an. Mega Crits Reaktion war ein offener Brief: "That is how badly you fucked up."

Unity ruderte zurück. Der CEO trat zurück. Mega Crit wechselte trotzdem zu Godot und baute das Spiel komplett neu auf.

Das Ergebnis: fast 575.000 gleichzeitige Spieler, knapp unter dem Silksong-Rekord von 587.150. Mega Crit ist inzwischen Platinum-Sponsor der Godot Foundation mit 36.000 Euro pro Jahr.

Die Umsatzzahlen der größten Godot-Spiele

Slay the Spire 2 ist noch im Early Access, daher fehlen verlässliche Umsatzschätzungen. Aber die anderen kommerziellen Godot-Erfolge sprechen für sich:

Spiel	Geschätzter Umsatz	Reviews	Bewertung
Brotato	10,7 Mio. $	102.051	96,6 %
Buckshot Roulette	6,9 Mio. $	102.849	95,7 %
Dome Keeper	6,1 Mio. $	17.173	92,3 %
Backpack Battles	5,2 Mio. $	17.455	91,1 %
Cassette Beasts	4,1 Mio. $	9.772	94,7 %
Halls of Torment	3,4 Mio. $	29.767	95,7 %

Zusammen über 48 Millionen Dollar geschätzter Umsatz. Jedes Spiel hat eine Bewertung über 91 %.

Warum Godot wächst

Drei Faktoren treiben das Wachstum:

1. MIT-Lizenz ohne Einschränkungen. Keine Runtime-Gebühren, keine Umsatzbeteiligung. Godot kostet nichts, egal wie erfolgreich dein Spiel wird. Nach Unitys Preisänderung ist das kein technisches Detail mehr, sondern ein Geschäftsrisiko, das Godot eliminiert.

2. Textbasierte Szenendateien. Godot speichert Szenen als .tscn-Dateien im Klartext. Git-Diffs funktionieren, KI-Tools können Szenen lesen und generieren, und Standard-Unix-Tools sind einsetzbar. Unity-Szenen sind binär. Dieser Unterschied wird immer wichtiger, je mehr Entwickler KI-Tools in ihren Workflow integrieren. Tools wie Ziva nutzen dieses Format direkt, um Szenen aus natürlicher Sprache zu generieren.

3. Kleine Teams dominieren. Buckshot Roulette wurde von einem einzelnen Entwickler aus Estland gebaut. Road to Vostok von einem Solo-Entwickler aus Finnland, der am 7. April 2026 die Steam Top 10 erreichte. Godots Editor ist 120 MB groß und braucht kein Konto, keine Lizenz und keine Internetverbindung.

Die Zahlen zum Wachstum

Godot-Spiele auf Steam pro Jahr:

2020: 47
2021: 97
2022: 195
2023: 389
2024: 618
2025: über 1.500

Das ist eine Verdopplung pro Jahr. 5 % aller Steam-Veröffentlichungen in 2024 nutzten Godot. Beim GMTK Game Jam 2025 lag Godots Anteil bei 39 %, gegenüber 13 % vier Jahre zuvor.

Was das für deutsche Spieleentwickler bedeutet

Deutschland ist der größte Spielemarkt Europas. Die Bundesregierung fördert Spieleentwicklung mit über 50 Millionen Euro jährlich. Gleichzeitig setzen viele deutsche Studios auf Unity oder Unreal.

Für kleine Studios und Solo-Entwickler lohnt sich ein Blick auf Godot. Die Einstiegshürde ist niedrig (120 MB Download, GDScript liest sich wie Python), die Lizenzkosten sind null, und die kommerzielle Erfolgsbilanz wächst mit jedem Quartal.

574.638 gleichzeitige Spieler sind kein Argument, das man leicht ignorieren kann.

5 Engineering Decisions That Made Godot the Fastest-Growing Game Engine

Ziva — Mon, 13 Apr 2026 21:26:04 +0000

Godot went from 47 game releases on Steam in 2020 to over 1,500 in 2025. Slay the Spire 2, built on Godot after Mega Crit scrapped two years of Unity development, hit 574,638 concurrent players on Steam. Five percent of all games released on Steam in 2024 used Godot.

That growth did not happen because of marketing. Godot has no venture capital, no sales team, no enterprise contracts. It grew because of five architectural decisions that compounded over time. If you build developer tools of any kind, these decisions are worth studying.

1. MIT license, no exceptions

Godot uses the MIT license. Not "free with conditions." Not "free until you make money." MIT.

Unity charges a runtime fee above certain revenue thresholds. Unreal takes 5% of gross revenue above $1 million. Godot takes nothing. Ever.

This matters more than it seems. When Unity announced its per-install fee in September 2023, studios with years of development invested had to evaluate whether to absorb the cost or switch engines. Mega Crit chose to rewrite. Mike Klubnika, creator of Buckshot Roulette (8 million copies sold), switched to Godot and said: "I really liked the fact that Godot was open source."

The web development world learned this lesson with open-core tools that changed pricing. Godot cannot change pricing because there is no pricing to change. The MIT license is a binding commitment to developers, and it removes a category of business risk entirely.

2. Text-based scene files

Godot scenes are stored as .tscn files. They are plain text. You can open one in any editor and read it:

[gd_scene format=3]

[node name="Player" type="CharacterBody2D"]
position = Vector2(100, 200)

[node name="Sprite" type="Sprite2D" parent="."]
texture = ExtResource("1_abc12")

Unity scenes are binary by default. Unreal Blueprints are binary. This means:

Version control works. Git diffs show exactly what changed in a scene. No "just merge the binary and pray."
AI can read and write scenes. An AI tool can generate a complete scene file from a text description and inject it into a project without any binary serialization layer. Tools like Ziva use this directly to generate scenes from natural language prompts.
Automation is trivial. Grep a scene for a node type. Sed-replace a resource path. Write a CI check that validates scene structure. All standard Unix tools work.

Web developers take this for granted. HTML, CSS, and JavaScript are all plain text. The idea of a binary-first UI description format feels alien. Game engines accepted binary scenes as normal for decades. Godot proved they did not have to.

3. A domain-specific language instead of a general-purpose one

GDScript is not Python. It looks like Python, but it is a purpose-built language for game logic. A typical GDScript file is 30-80 lines. The equivalent C# in Unity is 100-300 lines.

extends CharacterBody2D

@export var speed := 200.0

func _physics_process(delta: float) -> void:
    var direction := Input.get_vector("left", "right", "up", "down")
    velocity = direction * speed
    move_and_slide()

That is a complete player movement controller. Six lines. The engine handles collision resolution, delta timing, and physics integration. The developer writes game logic, not framework plumbing.

The tradeoff is real. GDScript is slower than C# for raw computation. If you need tight loops processing millions of elements, C# or C++ via GDExtension is better. But for the 90% of game code that is event handling, state transitions, and scene manipulation, GDScript's brevity means less code to write, less code to debug, and less context for AI tools to manage.

The parallel in web development: Tailwind CSS is "worse" than raw CSS in the same way GDScript is "worse" than C#. It is constrained by design. Those constraints are the point.

4. A 120 MB download that runs everywhere

The Godot editor is a single binary. 120 MB. It runs on Windows, macOS, Linux, and even in a browser via WebAssembly. No installer, no account creation, no license key, no phone-home telemetry.

Unity's editor is over 10 GB installed. Unreal is 30+ GB. Both require accounts. Both require internet connections for licensing.

This has second-order effects:

Game jams. A developer can download Godot, create a project, and have a playable prototype in under an hour. At the GMTK Game Jam, Godot went from 13% to 39% of entries in four years.
Education. A teacher can put Godot on a USB drive and hand it to students. No IT department needed.
CI/CD. Godot headless exports run on any Linux box. No need to license a build server.

The lesson for tool builders: if your tool requires an account to evaluate, you are losing users who would have become advocates.

5. Composition over inheritance via the node tree

Godot's scene system uses composition. Every object in a game is a tree of nodes. A player character is a CharacterBody2D with child nodes for Sprite2D, CollisionShape2D, AnimationPlayer, and whatever else it needs. You add behavior by adding nodes, not by subclassing.

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
├── AnimationPlayer
└── HealthComponent (custom)

This is the same pattern as React's component tree, which borrowed the concept from scene graphs that game engines used decades earlier. If you understand React components, you already understand Godot's node tree.

The practical benefit: scenes are reusable. You can build a "HealthComponent" scene and instance it on any entity. You can nest scenes inside scenes. The composition is unlimited and does not require inheritance hierarchies that become brittle at scale.

The compound effect

None of these decisions is unique in isolation. Plenty of tools are MIT-licensed. Plenty use text formats. Plenty are small. But the combination produces a developer experience where:

You download a 120 MB binary (no account)
You write 30-line scripts in a language designed for the domain
Your scenes are text files that work with git and AI tools
You ship to any platform with no runtime fees
You own every line of source code

That combination is why Godot went from a niche curiosity to an engine that ships games earning over $10 million on Steam. It is also why the growth is accelerating: each new commercial success validates the architecture for the next wave of developers.

If you are evaluating game engines in 2026, or just interested in how architectural decisions compound into ecosystem growth, Godot is the case study.

Cómo hacer tu primer juego en Godot con IA en un fin de semana

Ziva — Sun, 12 Apr 2026 23:23:13 +0000

Godot Engine tiene 95,000 estrellas en GitHub y es completamente gratis. No hay licencias, no hay royalties, no hay letra chica. Si nunca hiciste un juego pero sabés programar, este es el mejor momento para empezar.

Esta guía cubre cómo armar un juego 2D funcional en Godot 4 usando herramientas de IA para acelerar las partes tediosas: generar código boilerplate, debuggear errores, y prototipar mecánicas rápido.

Día 1 (sábado): Setup y mecánicas base

Instalar Godot

Bajá Godot 4.x desde la página oficial. No necesitás instalar nada: es un ejecutable portable. En Linux, macOS y Windows funciona igual.

Creá un proyecto nuevo y elegí el renderer Compatibility (OpenGL). Es el más estable para juegos 2D y funciona en la mayor cantidad de hardware.

Entender la arquitectura

Godot usa un sistema de nodos organizados en un árbol de escenas. Todo es un nodo: tu personaje, los enemigos, el piso, la cámara, la interfaz. Los nodos se combinan en escenas reutilizables.

# Un nodo CharacterBody2D básico
extends CharacterBody2D

var speed = 200.0

func _physics_process(delta):
    var direction = Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")
    velocity = direction * speed
    move_and_slide()

Este script mueve un personaje con las flechas del teclado. En Godot, _physics_process se ejecuta 60 veces por segundo y move_and_slide() maneja las colisiones automáticamente.

Dónde usar IA (y dónde no)

Usá IA para:

Generar scripts boilerplate (movimiento, colisiones, spawners)
Diagnosticar errores de GDScript desde el stack trace
Prototipar mecánicas que no conocés (sistema de inventario, diálogos, pathfinding)

No uses IA para:

Game design (las decisiones de diseño son tuyas)
Arte final (los modelos generan assets inconsistentes)
Código que no entendés (si no podés leerlo, no podés debuggearlo)

Herramientas como Ziva, que corren dentro del editor de Godot, son útiles porque entienden la estructura de tu proyecto. También podés usar ChatGPT o Claude pegando código, pero perdés el contexto del proyecto.

Según la encuesta GDC 2026, el 47% de los desarrolladores que usan IA la usan para asistencia de código. Solo el 5% la usa para features que el jugador ve directamente.

Día 1 (tarde): Enemigos y colisiones

Crear enemigos

Creá una nueva escena con un nodo Area2D como raíz. Agregá un Sprite2D y un CollisionShape2D.

# enemigo.gd
extends Area2D

var speed = 100.0
var direction = Vector2.LEFT

func _process(delta):
    position += direction * speed * delta

func _on_visible_on_screen_notifier_2d_screen_exited():
    queue_free()  # Se borra cuando sale de la pantalla

Detectar colisiones

Conectá la señal body_entered del Area2D del enemigo al jugador:

# En el script del enemigo
func _on_body_entered(body):
    if body.is_in_group("player"):
        body.take_damage(1)
        queue_free()

Las señales son el sistema de eventos de Godot. Son como callbacks tipados: cuando algo pasa (colisión, timer, animación termina), se emite una señal y los nodos conectados reaccionan.

Día 2 (domingo): UI, sonido y exportación

Interfaz de usuario

Para mostrar puntaje y vidas, usá nodos Label dentro de un CanvasLayer (se renderiza encima del juego):

# hud.gd
extends CanvasLayer

@onready var score_label = $ScoreLabel
@onready var lives_label = $LivesLabel

func update_score(value):
    score_label.text = "Puntaje: %d" % value

func update_lives(value):
    lives_label.text = "Vidas: %d" % value

El decorator @onready asigna la referencia al nodo cuando la escena está lista. Es el equivalente de GetComponent<>() en Unity o FindNode en otros motores.

Sonido

Agregá nodos AudioStreamPlayer a la escena. Godot soporta .ogg y .wav nativamente.

# Reproducir sonido al recibir daño
$HitSound.play()

Para música de fondo, usá un AudioStreamPlayer en un Autoload (singleton global) para que siga sonando entre escenas.

Exportar

Para compartir tu juego, exportá a Web (HTML5). Es la forma más rápida de que alguien lo pruebe:

Bajá los export templates desde Editor > Manage Export Templates
Agregá un preset de Web en Project > Export
Exportá a una carpeta
Subí los archivos a itch.io (gratis, sin aprobación)

Tu juego está online en menos de 10 minutos.

Recursos para seguir

Documentación oficial de Godot (también disponible en español)
GDQuest en YouTube (tutoriales paso a paso)
r/godot en Reddit (comunidad activa que responde preguntas)
Godot en español (cada vez hay más contenido en español)

El punto no es hacer un juego perfecto en un fin de semana. Es hacer uno que funcione, subirlo a itch.io, y tener algo concreto que mostrar. El primer juego siempre es malo, y eso está bien.

52% of Game Developers Think AI Is Hurting Their Industry. 36% Use It Anyway.

Ziva — Sun, 12 Apr 2026 23:04:05 +0000

The GDC 2026 State of the Industry survey asked 2,300 game professionals what they think about generative AI. The results are contradictory in a way that tells you more about the state of AI tooling than any product launch or benchmark ever could.

52% said AI is bad for the game industry. That number was 30% last year and 18% the year before. Only 7% called it positive, down from 13%.

In the same survey, 36% said they use AI tools at work. Among those users, 81% use AI for research and brainstorming, and 47% use it for code assistance.

Developers are increasingly convinced AI is harmful. They're also increasingly using it. What's going on?

The sentiment split isn't random

The GDC 2026 report breaks down who hates AI and who uses it, and the pattern is clear.

Negative sentiment by discipline:

Role	"AI is bad for the industry"
Visual / technical art	64%
Game design / narrative	63%
Programming	59%

AI adoption by seniority:

Level	Uses AI at work
Upper management	47%
Lower-level employees	29%
Publishing / support firms	58%
Game studios	30%

The people who think AI is bad are mostly the people whose work AI threatens to replace: artists and writers. The people using AI the most are managers and publishing staff who use it for emails, reports, and brainstorming. These are largely different groups having different experiences.

One surveyed developer put it plainly: "Why would I replace human creativity with a regurgitated amalgamation of everything that's come before?"

What developers actually use AI for

The use case breakdown from the same survey is revealing:

Use case	% of AI users
Research / brainstorming	81%
Daily tasks (emails, code)	47%
Asset generation	19%
Procedural generation	10%
Player-facing features	5%

The overwhelming majority use AI for research and code. Almost nobody ships AI-generated content to players. The industry has collectively decided that AI is a backstage tool, not a front-of-house feature.

This matches what most developers I've seen in forums and postmortems describe: AI is useful for scaffolding code, debugging, and getting past blank-page paralysis. It falls apart when you need pixel-perfect art consistency or narrative voice.

The tool preferences are lopsided

ChatGPT dominates at 74% adoption among AI-using developers. Google Gemini sits at 37%, Microsoft Copilot at 22%. Text-to-image tools lag far behind: Midjourney at 17%, Adobe Generative Fill at 13%.

The gap between LLM adoption (74%) and image generation adoption (17%) tells you where AI actually delivers value in game dev. Writing and debugging code with a language model works well enough to become habitual. Generating game art that fits a specific style, pipeline, and resolution requirement is much harder.

This is also why tools that understand game engine context specifically (like Ziva for Godot, or the various MCP-based tools connecting Claude to game editors) have found a niche. A general-purpose LLM generates generic code. A tool that reads your scene tree and project structure generates code that fits.

28% lost their jobs in two years

The AI sentiment doesn't exist in a vacuum. The GDC survey found that 28% of respondents lost their job in the past two years. 74% of students said they're concerned about their future job prospects.

When over a quarter of your colleagues have been laid off and AI is being positioned as the reason companies can "do more with less," negative sentiment isn't irrational. It's self-preservation. The developers who view AI most negatively (artists at 64%, designers at 63%) are the ones whose roles are most visibly threatened by generative models.

Where this leaves us

The data paints a picture of an industry with two parallel realities. In one, developers quietly use AI to brainstorm, scaffold code, and automate repetitive tasks. In the other, the same developers watch their colleagues get laid off while executives pitch AI as a cost-cutting measure.

Both realities are true simultaneously. AI tools do save time on specific tasks. AI rhetoric is also being used to justify smaller teams and lower budgets. The 52% who view AI negatively aren't technophobes. They're reacting to how AI is being deployed as a labor strategy, not just a productivity tool.

For developers building AI-assisted tooling (and I work on one), the takeaway is straightforward: the tools that survive will be the ones that make individual developers faster without making their employers think they're replaceable. That means augmenting decisions, not automating them. It means context-aware assistance within the editor, not "AI generates your game for you" marketing.

The 36% who use AI tools despite the backlash aren't hypocrites. They've found narrow, specific tasks where AI actually helps. The 52% who view AI negatively aren't wrong either. They're responding to a real threat that has nothing to do with the technology and everything to do with how companies choose to use it.