Forem: Ziva

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.

The 900,000 Game Problem: Why Most Indie Games Never Get Found

Ziva — Thu, 09 Apr 2026 22:28:52 +0000

Itch.io hosts over 900,000 games as of 2026. Steam released over 14,000 new titles in 2025 alone. The math is brutal: most games never get played.

This is not a quality problem. Plenty of good games fail commercially. It is a distribution problem, and it has structural causes that developers can understand and work around.

The Numbers

According to revenue analysis of Steam data, the top Godot games earned millions (Brotato at $10.7M, Dome Keeper at $6.1M). But these are the extreme outliers. Only about 0.5% of indie games released in 2024 made over $1 million in revenue.

The difference between games that get found and games that don't is rarely the game itself. It is what happens before and around the game.

Wishlists Are the Leading Indicator

Steam wishlists are the strongest predictor of launch performance. Industry benchmarks suggest 7,000-10,000 wishlists at launch for a viable release. Top performers reach 50,000+ before day one.

The counterintuitive insight: total wishlist count matters less than wishlist velocity. Steam's discovery algorithm responds more strongly to recent momentum than long-term accumulation. A game getting 500 wishlists per day for two weeks before launch will surface more than one that accumulated 10,000 over six months.

Steam Next Fest Changed the Game

Steam Next Fest is now the single highest-leverage event for indie developers. In a single week, developers can generate thousands of wishlists through a playable demo. But preparation matters: you need a polished demo, marketing assets ready, and someone available to engage with the community during the event.

The developers who treat Next Fest as their primary marketing event (not an afterthought) consistently outperform those who rely on social media alone.

The Development Speed Advantage

Here is where tooling matters. The faster you can get to a playable prototype, the faster you can start gathering feedback and building an audience. Developers who show their game early, even in rough form, build community engagement that compounds over time.

Open source engines like Godot reduce the barrier. Zero licensing cost, a 50MB download, and a growing community of over 102,000 GitHub stars. AI tools like Ziva that generate engine-specific code can cut prototype time further.

But tooling is only one variable. The developers who succeed at discoverability share three habits:

They start marketing before the game is done. The old model of "finish the game, then market" is a recipe for invisibility in 2026.
They build in public. Devlogs, work-in-progress posts, and community engagement create an audience before launch.
They optimize for Steam's algorithm. Capsule images, descriptions, tags, and wishlisting flows are as important as the game itself.

The 2026 Reality

The market is not getting smaller. More games will release next year than this year. The developers who understand distribution as a core skill, not an afterthought, will be the ones whose games get played.

The good news: the tools for making games have never been more accessible. The challenge has shifted from "can I build this?" to "can I get anyone to find it?"

If you are building a game right now, start your Steam page today. Not next month. Not when the game is "ready." Today.

NVIDIA acaba de invertir en un motor de juegos open source. Esto es lo que importa.

Ziva — Thu, 09 Apr 2026 06:46:27 +0000

En la GDC 2026, NVIDIA hizo algo inesperado: lanzaron un fork con path tracing de Godot, el motor de juegos open source. No un plugin propietario. Un fork completo en GitHub bajo la licencia MIT.

Esto vale la pena seguir aunque nunca hayas hecho un juego.

Qué construyó NVIDIA

El fork agrega path tracing en tiempo real usando la API de Vulkan. El path tracing simula iluminación físicamente precisa rastreando cada rayo de luz. Es la misma técnica que usan las películas de Pixar, ahora corriendo en tiempo real en GPUs de consumo.

El path tracer es agnóstico de GPU porque usa Vulkan en lugar de una API propietaria. El denoiser actualmente requiere DLSS Ray Reconstruction (solo NVIDIA), pero están construyendo un segundo denoiser para AMD e Intel.

Mientras tanto, Godot 4.7 dev 1 comenzó a agregar soporte nativo de ray tracing con Vulkan, independiente del fork de NVIDIA. Dos caminos paralelos hacia la misma capacidad.

Por qué una empresa de GPUs forkea un motor open source

NVIDIA gana dinero cuando los desarrolladores construyen software que exige hardware GPU. Unreal y Unity ya tienen ray tracing, pero ambos son motores propietarios. Al invertir en Godot:

Alcanzan un mercado en crecimiento. Los juegos de Godot en Steam se duplicaron año tras año hasta 2,864 en 2025-2026. En el GMTK Game Jam 2025, Godot igualó a Unity en aproximadamente 40% cada uno.

Obtienen libertad MIT. NVIDIA puede modificar, distribuir y construir sobre Godot sin negociar términos de licencia. El fork es MIT. Cualquier desarrollador puede usarlo sin pagar regalías.

Construyen goodwill con la comunidad open source. El plan es fusionar el path tracer de vuelta a Godot vía PR. Si eso pasa, cada usuario de Godot obtiene ray tracing gratis.

Es la misma estrategia que NVIDIA usó con CUDA y frameworks de machine learning.

El ángulo open source

La mayoría de los motores comerciales tratan sus renderers como joyas de la corona. No puedes leer el código fuente de Nanite de Unreal sin una licencia de Epic. El renderer de Godot es completamente abierto.

Cuando NVIDIA agrega path tracing, ese código es inspecccionable, modificable y educativo. Un estudiante puede leer cómo funciona ray tracing de producción. Un startup puede forkearlo para visualización arquitectónica.

Linux dominó en servidores en parte porque empresas como IBM y Red Hat invirtieron en hacerlo empresarial. Godot podría seguir una trayectoria similar si empresas como NVIDIA siguen contribuyendo.

La línea de tiempo honesta

Si estás enviando un juego en 2026, el fork de NVIDIA no está listo para producción. El denoiser es solo NVIDIA. El soporte RT nativo de Godot 4.7 está en etapa temprana.

Pero la señal importa más que el estado actual. NVIDIA no invierte recursos de ingeniería en ecosistemas que espera que se contraigan.

La encuesta GDC 2026 encontró que el 47% de los desarrolladores que usan herramientas de IA las usan para asistencia de código. A medida que las pipelines de renderizado se vuelven abiertas, las herramientas de IA que entienden tanto el motor como el renderer tendrán una ventaja estructural.

Conclusión

Una empresa de $2.8 billones acaba de comprometer recursos de ingeniería para mejorar un motor de juegos open source. El código es MIT. El path tracer es agnóstico de GPU. El plan es fusionarlo upstream. Ya sea que hagas juegos o no, este es un modelo interesante de inversión empresarial en infraestructura open source.

NVIDIA investiert in eine Open-Source-Game-Engine: Was die Daten zeigen

Ziva — Thu, 09 Apr 2026 06:41:39 +0000

Auf der GDC 2026 hat NVIDIA etwas Unerwartetes getan: Sie haben einen Path-Tracing-Fork von Godot veröffentlicht. Kein proprietäres Plugin. Kein geschlossenes SDK. Ein vollständiger Fork auf GitHub unter der MIT-Lizenz.

Das ist auch für Entwickler relevant, die keine Spiele bauen.

Was NVIDIA konkret gebaut hat

Der Fork fügt Echtzeit-Path-Tracing über die Vulkan-API hinzu. Path Tracing simuliert physikalisch korrekte Beleuchtung, indem jeder Lichtstrahl verfolgt wird. Das Ergebnis: Beleuchtung, die ohne manuell platzierte Lichtquellen oder gebackene Lightmaps physikalisch korrekt aussieht.

Der Path Tracer ist GPU-agnostisch, weil er Vulkan statt einer proprietären API nutzt. Der Denoiser braucht aktuell DLSS Ray Reconstruction (nur NVIDIA), aber ein zweiter Denoiser für AMD und Intel ist in Arbeit.

Parallel dazu hat Godot 4.7 dev 1 unabhängig vom NVIDIA-Fork erste Vulkan-Ray-Tracing-Grundlagen in die Hauptversion eingebaut. Zwei parallele Wege zum selben Ziel.

Warum ein GPU-Hersteller eine Open-Source-Engine forkt

NVIDIA verdient Geld, wenn Entwickler Software bauen, die GPU-Hardware fordert. Unreal und Unity haben bereits Ray Tracing, aber beide sind proprietäre Engines. Mit Godot bekommt NVIDIA:

Zugang zu einem wachsenden Markt. Godot-Spiele auf Steam haben sich jährlich verdoppelt: von 290 (2022-23) auf 2.864 (2025-26). Beim GMTK Game Jam 2025 lag Godot mit Unity gleichauf bei je rund 40%.

MIT-Lizenz-Freiheit. NVIDIA kann Godot modifizieren, verteilen und darauf aufbauen, ohne Lizenzverhandlungen. Der Fork selbst ist MIT. Jeder Entwickler kann ihn ohne Lizenzgebühren nutzen.

Open-Source-Goodwill. Der Plan ist, den Path Tracer per PR zurück in Godot zu mergen. Wenn das passiert, bekommt jeder Godot-Nutzer Ray Tracing kostenlos.

Das ist dasselbe Vorgehen wie bei CUDA und Machine-Learning-Frameworks: In Open-Source investieren, es auf der eigenen Hardware optimal machen, das Ökosystem wachsen lassen.

Der Open-Source-Aspekt

Die meisten kommerziellen Game Engines behandeln ihren Renderer als Kronjuwelen. Den Quellcode von Unreals Nanite kann man ohne Epic-Lizenz nicht lesen. Unitys Rendering-Pipeline ist teilweise offen, die Engine aber nicht.

Godots Renderer ist vollständig offen. Wenn NVIDIA Path Tracing hinzufügt, ist der Code inspizierbar, modifizierbar und lehrreich. Studierende können lesen, wie produktionsreifes Ray Tracing funktioniert. Startups können es für Architekturvisualisierung forken.

Linux wurde auf Servern dominant, teilweise weil Unternehmen wie IBM und Red Hat in die Enterprise-Tauglichkeit investierten. Godot könnte einen ähnlichen Weg bei Game Engines nehmen, wenn Unternehmen wie NVIDIA weiter beitragen.

Die ehrliche Timeline

Wer 2026 ein Spiel ausliefert, sollte den NVIDIA-Fork nicht in Produktion einsetzen. Der Denoiser ist nur für NVIDIA. Die native Godot 4.7 RT-Unterstützung ist in einem frühen Stadium.

Aber das Signal zählt mehr als der aktuelle Stand. NVIDIA investiert keine Engineering-Ressourcen in Ökosysteme, von denen sie erwarten, dass sie schrumpfen.

Die GDC 2026-Umfrage ergab, dass 47% der Spieleentwickler, die KI-Tools nutzen, diese für Code-Unterstützung verwenden. Wenn Rendering-Pipelines offen werden, haben KI-Tools, die sowohl die Engine als auch den Renderer verstehen, einen strukturellen Vorteil.

Fazit

Ein 2,8-Billionen-Dollar-Unternehmen hat Engineering-Ressourcen in eine Open-Source-Game-Engine investiert. Der Code ist MIT-lizenziert. Der Path Tracer ist GPU-agnostisch. Der Plan ist, ihn upstream zu mergen. Das ist ein interessantes Modell dafür, wie große Unternehmen in Open-Source-Infrastruktur investieren können.

NVIDIA Is Investing in an Open Source Game Engine. Here's Why That Matters.

Ziva — Thu, 09 Apr 2026 05:29:18 +0000

At GDC 2026, NVIDIA did something unusual. They released a path tracing fork of Godot, the open source game engine. Not a proprietary plugin. Not a closed SDK. A full fork on GitHub under the MIT license.

This is worth paying attention to even if you have never made a game.

What NVIDIA shipped

The fork adds real-time path tracing to Godot using the Vulkan API. Path tracing simulates physically accurate lighting by tracing every ray of light as it bounces through a scene. It is the same rendering technique used in Pixar films, now running in real time on consumer GPUs.

The path tracer is GPU-agnostic because it uses Vulkan rather than a proprietary API. The denoiser (which cleans up the noisy raw output) currently requires NVIDIA's DLSS Ray Reconstruction, but they are actively building a second denoiser for AMD and Intel hardware.

Meanwhile, Godot 4.7 dev 1 independently started adding native Vulkan ray tracing plumbing to the mainline engine. Two parallel paths to the same capability.

Why a GPU company is forking an open source engine

NVIDIA makes money when developers build software that pushes GPU hardware. Unreal and Unity already have ray tracing support, but both are proprietary engines with licensing restrictions. By investing in Godot:

They reach a growing market. Godot games on Steam doubled year over year to 2,864 in the 2025-2026 window. At the GMTK Game Jam 2025 (the largest jam on itch.io), Godot matched Unity at roughly 40% each.

They get MIT license freedom. NVIDIA can modify, distribute, and build on Godot without negotiating license terms. The fork itself is MIT. Any developer can use it without paying royalties.

They build goodwill with open source developers. The plan is to merge the path tracer back into mainline Godot via PR. If that happens, every Godot user gets ray tracing for free.

This is the same playbook NVIDIA used with CUDA and machine learning frameworks. Invest in open source tooling, make it excellent on your hardware, and let the ecosystem grow.

The open source angle that matters

Most commercial game engines treat their renderers as crown jewels. You cannot read Unreal's Nanite source without an Epic license. Unity's rendering pipeline is partially open but the engine is not.

Godot's renderer is fully open. When NVIDIA adds path tracing to it, that code is inspectable, modifiable, and educational. A student can read exactly how production-grade ray tracing works. A startup can fork it for architectural visualization. A researcher can benchmark it against their own implementations.

This is the kind of infrastructure investment that compounds. Linux became dominant in servers partly because companies like IBM and Red Hat invested in making it enterprise-grade. Godot may follow a similar trajectory in game engines if companies like NVIDIA keep contributing.

What this does not mean (yet)

The fork is experimental. If you are shipping a game in 2026, you should not use it in production. The denoiser is NVIDIA-only for now. The mainline Godot 4.7 ray tracing support is early plumbing, not a finished feature.

But the signal matters more than the current state. NVIDIA does not invest engineering resources in ecosystems they expect to shrink.

The AI development angle

One underappreciated consequence: open source ray tracing makes AI-assisted 3D development more tractable. When the rendering pipeline is open, AI tools can reason about materials, lighting, and scene composition at the source level. Tools like Ziva that build engine-aware AI for Godot will be able to understand and generate ray-traced scenes because the rendering code is readable, not a black box.

The GDC 2026 survey found that 47% of game developers using AI tools use them for code assistance. As ray tracing becomes standard in Godot, AI tools that understand both the engine and the renderer will have a structural advantage over generic coding assistants.

The bottom line

A $2.8 trillion company just committed engineering resources to making an open source game engine render better. The code is MIT licensed. The path tracer is GPU-agnostic. The plan is to merge it upstream.

Whether you care about game development or not, this is an interesting model for how large companies can invest in open source infrastructure in a way that benefits everyone. Watch this space.

Was Web-Entwickler von Game-Engine-Architektur lernen können

Ziva — Tue, 07 Apr 2026 19:28:24 +0000

Wenn du mit React, Vue oder Angular arbeitest, nutzt du Patterns, die aus der Spieleentwicklung stammen. Nicht inspiriert davon. Direkt übernommen. Der Component Tree, den du jeden Tag baust, wurde in den 1980ern als Scene Graph erfunden, lange bevor JavaScript überhaupt existierte.

Hier sind vier Architektur-Patterns aus Game Engines, die dein Web-Development besser machen.

1. Der Scene Graph: Reacts Urgroßvater

Der Scene Graph ist eine hierarchische Baumstruktur, in der jeder Knoten Transformationen und Eigenschaften an seine Kinder vererbt. PHIGS (Programmer's Hierarchical Interactive Graphics System) wurde 1984 entwickelt und 1988 als ANSI-Standard verabschiedet. Es war die erste kommerzielle Scene-Graph-Spezifikation.

Das Prinzip: Du baust eine Szene nicht als flache Liste, sondern als Baum. Ein Raumschiff-Node enthält einen Triebwerk-Node, der enthält einen Partikel-Node. Wenn sich das Raumschiff bewegt, bewegen sich Triebwerk und Partikel automatisch mit. Kaskadierung von Eigenschaften durch die Hierarchie.

Kommt dir das bekannt vor? Reacts Component Tree funktioniert identisch. Context propagiert durch den Baum nach unten. CSS-Variablen kaskadieren. State fließt von Eltern zu Kindern. Das ist kein Zufall. Jordan Walke, der Erfinder von React, hat sich explizit von Szenegraphen und funktionaler Programmierung inspirieren lassen.

Godot macht das noch konsequenter als React. In Godots Scene Tree ist alles ein Node: UI-Elemente, Spiellogik, Physik, Audio. Kein useEffect, kein Lifecycle-Hook. Du hast _ready() (Mount), _process() (Render-Loop) und _exit_tree() (Unmount). Drei Funktionen statt 15 Hooks.

class_name Raumschiff extends CharacterBody2D

func _ready():
    # Wie componentDidMount / useEffect([], ...)
    $Triebwerk.starten()

func _process(delta):
    # Wie requestAnimationFrame, 60x pro Sekunde
    position += geschwindigkeit * delta

2. Composition over Inheritance: Die Spielebranche wusste es zuerst

Das Entity Component System (ECS) hat Composition over Inheritance nicht erfunden, aber es hat bewiesen, dass es skaliert. Thief: The Dark Project nutzte 1998 ein ECS, und der gleiche Ansatz lief später in System Shock 2.

Die Idee: Eine Spielfigur ist keine Klasse in einer Vererbungshierarchie. Sie ist eine leere Entity mit angehängten Components. Braucht sie Physik? PhysicsComponent anhängen. Braucht sie Gesundheit? HealthComponent anhängen. Braucht sie beides nicht mehr? Components entfernen.

React hat dieses Pattern 2018 mit Hooks übernommen. Statt Klassen-Vererbung (class MyComponent extends React.Component) nutzt du Composition mit useState, useEffect und Custom Hooks. Die Game-Engine-Welt hatte das gleiche Problem 20 Jahre früher gelöst.

Unity hat die Performance-Vorteile gemessen: Ihr Data-Oriented Technology Stack (DOTS) mit ECS erreicht 5x bis 50x bessere CPU-Performance als die klassische OOP-Architektur, je nach Parallelisierungsgrad. In der Megacity-Demo von 2018 renderte Unity damit eine Stadt mit 4,5 Millionen Mesh-Renderern.

Für Web-Entwickler heißt das: Wenn du merkst, dass deine Klassen-Hierarchie zu tief wird, denk wie ein Game-Engine-Architekt. Zerlege Verhalten in kleine, kombinierbare Einheiten. In React sind das Hooks. In Godot sind das Nodes. Das Prinzip ist dasselbe.

3. Signals: Observer Pattern ohne den Boilerplate

Godot hat Signals als erstklassiges Sprachfeature. Du deklarierst ein Signal, und andere Nodes verbinden sich damit. Keine Event-Bus-Bibliothek, kein Redux, kein Pub/Sub-Framework.

signal leben_verloren(neues_leben: int)

func schaden_nehmen(menge: int):
    leben -= menge
    leben_verloren.emit(leben)

func _ready():
    spieler.leben_verloren.connect(_bei_leben_verloren)

func _bei_leben_verloren(neues_leben: int):
    label.text = str(neues_leben)

Das ist das Observer Pattern in seiner reinsten Form, ohne Middleware-Layer. Die Web-Welt hat Jahre gebraucht, um an einen ähnlichen Punkt zu kommen. Solid.js Signals, Angular Signals (seit v16), Vue 3 Reactivity: Alle lösen das gleiche Problem, das Game Engines seit den 2000ern gelöst haben.

Der entscheidende Unterschied: In Game Engines sind Signals architektonisch. Sie definieren, wie Systeme kommunizieren. Im Web werden sie oft nur als State-Management-Optimierung behandelt. Game-Engine-Entwickler denken von Anfang an in entkoppelten Systemen, die über Signals kommunizieren. Web-Entwickler sollten das auch tun.

4. Object Pooling: Warum Game Engines Garbage Collection hassen

In einem Shooter entstehen pro Sekunde Dutzende Projektile. Jedes Mal new Bullet() und dann den Garbage Collector aufräumen lassen? Unspielbar. Stattdessen nutzen Game Engines Object Pools: Eine fixe Menge an Objekten wird beim Start erstellt. "Verbrauchte" Objekte werden nicht zerstört, sondern zurückgesetzt und wiederverwendet.

Web-Entwickler kennen das Prinzip als Connection Pooling bei Datenbanken. Aber es geht weiter: React 18s Concurrent Rendering recycelt Fiber-Nodes intern. Workers in Node.js Thread-Pools werden wiederverwendet. Das Pattern ist überall, nur redet im Web kaum jemand darüber.

Wenn du eine Anwendung baust, die viele kurzlebige Objekte erzeugt (Chat-Nachrichten, Tabellen-Zeilen, Animationen), frag dich: Könnte ich die recyceln statt neu zu erstellen? Die Spielebranche beantwortet diese Frage seit 30 Jahren mit Ja.

Die Zahlen hinter Game-Engine-Architektur

Die deutsche Spielebranche hat 2023 mit knapp 1.200 Unternehmen und fast 13.000 Beschäftigten über 3,9 Milliarden Euro Umsatz erwirtschaftet (Quelle: game.de Jahresreport 2025). Das sind keine Hobby-Projekte. Das sind Produktionssysteme, die unter extremen Performance-Anforderungen laufen.

Godot, die Open-Source-Engine mit über 108.000 GitHub Stars, hat beim GMTK Game Jam 2025 einen Marktanteil von 39% erreicht, mehr als dreimal so viel wie noch 2021 (13%). Tools wie Ziva helfen Godot-Entwicklern dabei, effizienter zu arbeiten, aber die Architektur der Engine selbst ist der eigentliche Lernstoff.

Fazit: Lerne von den Leuten, die 60 FPS halten müssen

Web-Entwickler optimieren für Time-to-Interactive. Game-Engine-Entwickler optimieren für 16,67 Millisekunden pro Frame, bei 60 FPS. Diese Einschränkung hat Architektur-Patterns hervorgebracht, die robuster und performanter sind als das, was die meiste Web-Architektur bietet.

Das heißt nicht, dass du deine Next.js-App wie eine Game Engine bauen sollst. Es heißt: Wenn du vor einem Architektur-Problem stehst, schau dir an, wie Godot, Unity oder Unreal es lösen. Die Chancen stehen gut, dass sie das Problem vor 10 oder 20 Jahren schon gelöst haben.

Drei konkrete Schritte:

Lies Game Programming Patterns von Robert Nystrom. Es ist kostenlos online und erklärt jedes Pattern mit konkretem Code.
Bau ein kleines Godot-Projekt. Nicht um Spiele zu entwickeln, sondern um die Architektur zu erleben. Der Scene Tree verändert, wie du über Component-Hierarchien denkst.
Hinterfrage deine Abstraktionen. Wenn du drei NPM-Pakete brauchst, um ein Problem zu lösen, das eine Game Engine in 10 Zeilen löst, stimmt etwas mit der Abstraktion nicht.

Die beste Architektur entsteht nicht in Frameworks. Sie entsteht dort, wo Performance keine Option, sondern eine harte Grenze ist.

React's Component Tree Was Invented by Game Engines 20 Years Ago

Ziva — Tue, 07 Apr 2026 17:59:27 +0000

If you build React apps, you already understand game engine architecture. You just don't know it yet.

React's core idea is a tree of composable components, each managing its own state, communicating through props down and callbacks up. This pattern feels modern because React popularized it in 2013. But game engines have been shipping production software with this exact architecture since the early 2000s.

Godot, Unity, and Unreal all use a scene tree (or scene graph) as their fundamental organizing principle. Every object in the game is a node in a tree. Nodes have children. Children inherit transforms. Communication flows through events. Sound familiar?

Here is what game engines figured out decades ago that the web is still catching up to.

1. Composition over inheritance, but for real

React developers talk about "composition over inheritance" like it is a React innovation. Game engines enforced it by design.

In Godot, you do not create a PlayerCharacter class that extends Character that extends Entity. You compose a player from independent nodes:

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
├── AnimationPlayer
├── HitboxArea (Area2D)
│   └── CollisionShape2D
└── StateMachine (Node)

Each node handles one concern. The Sprite2D handles rendering. The CollisionShape2D handles physics boundaries. The AnimationPlayer handles frame sequences. None of them know about each other.

React components work the same way, but web developers still routinely create <DashboardWithSidebarAndHeaderAndFooter> components that violate the principle. Game developers learned decades ago that a node should do exactly one thing, because in a game running at 60fps, bloated nodes cause visible frame drops.

2. Signals are the original pub/sub

React has callbacks. Redux has actions. The Context API has providers. Event buses exist in every state management library.

Godot has had signals since 2014. A signal is a typed event that a node emits without knowing who listens:

# The enemy emits a signal when it takes damage
signal health_changed(new_health: int)

func take_damage(amount: int) -> void:
    health -= amount
    health_changed.emit(health)

Any other node can connect to that signal without the enemy knowing about it. The health bar listens. The sound system listens. The achievement tracker listens. The enemy does not import, reference, or depend on any of them.

Compare this to React, where passing a callback from a great-grandparent to a great-grandchild requires prop drilling or a context provider. The game engine pattern is simpler because it was designed for systems where hundreds of objects need to communicate without tight coupling.

Svelte 5's event system and Vue's emit are closer to Godot signals than React's callback pattern. The convergence is not coincidental.

3. The scene tree solves the "where does state live?" problem

The hardest architectural question in React is: where does this state belong? Local state? Lifted state? Context? A global store?

Game engines answer this question structurally. State lives on the node that owns the behavior. A player's health lives on the player node. An enemy's patrol path lives on the enemy node. The game's score lives on a singleton autoload (Godot's equivalent of a global provider).

There is no debate because the tree structure makes ownership obvious. If a piece of data affects only one subtree, it lives at the root of that subtree. If it affects the whole game, it lives at the root of the tree.

React's server components and the shift toward "colocation" (putting data fetching next to the component that uses it) are rediscovering what game engines always did: state belongs where it is used, not in a centralized store that everything depends on.

4. Hot reloading existed in game engines first

React's hot module replacement (HMR) was a developer experience breakthrough when Dan Abramov demonstrated it in 2015. Change a component, see it update without losing state.

Godot has had live scene editing since version 2.0 in 2016. You can modify node properties, change scripts, and adjust physics while the game is running. Unlike React's HMR, which occasionally loses state on complex changes, Godot's live editing operates on the actual running scene tree through a remote debugger connection.

Unity's "Play Mode" editing predates both, shipping in Unity 3.0 in 2010. Game developers have been iterating on running applications for longer than most web frameworks have existed.

5. AI tools struggle with trees they don't understand

This is where the parallel breaks down in an interesting way. AI coding tools like GitHub Copilot and ChatGPT understand React's component tree well because React has millions of training examples. They can generate a <TodoList> with proper state management, hooks, and event handlers.

Ask the same tools to generate a Godot scene tree, and the output is usually wrong. They write monolithic scripts instead of composing nodes. They use direct function calls instead of signals. They generate Godot 3 syntax in a Godot 4 project because the training data mixes both versions.

This is the same problem React had in 2015: not enough training data for AI to learn the patterns. As Godot's adoption grows (it doubled its Steam releases year over year and now matches Unity in game jam usage), the AI tooling gap will close. Projects like Ziva are already building engine-aware AI that understands scene tree architecture natively, similar to how Copilot learned React patterns from millions of repositories.

What web developers should steal from game engines

If you are a React developer, here are three patterns from game engines worth adopting:

Use event emitters instead of prop drilling. Signals (pub/sub) scale better than callback chains when your component tree gets deep. Libraries like EventEmitter3 bring this pattern to JavaScript.

Let the tree structure determine state ownership. Instead of debating between Redux, Zustand, and Jotai, ask: "Which component is the root of the subtree that uses this data?" Put the state there. This is what game engines do, and it eliminates most state management debates.

Profile at 60fps standards. Game developers consider 16ms per frame a hard deadline. Web developers accept 100ms interactions as "fast." If you profiled your React app against game engine standards, you would find and fix performance issues you currently ignore.

The web and game dev worlds are converging. The patterns that game engines refined over two decades are the same patterns that modern web frameworks are now adopting. Understanding both makes you better at either.

El vibe coding funciona para apps web. En motores de juegos, se rompe.

Ziva — Mon, 06 Apr 2026 04:24:04 +0000

Si has probado "vibe coding" con Claude, GPT-4 o Copilot para crear una app web, probablemente te sorprendió lo bien que funciona. Describes lo que quieres, la IA genera el código, lo pegas, y funciona. Pero intenta hacer lo mismo con un motor de juegos y todo se desmorona. Aquí explico por qué.

Qué es el vibe coding

El término lo acuñó Andrej Karpathy en febrero de 2025: escribir código guiándote por la "vibra" en lugar de la lógica, dejando que la IA genere la mayor parte del código mientras tú solo diriges.

Para apps web, esto funciona sorprendentemente bien. Los LLMs tienen billones de tokens de React, Next.js, Express y Django en sus datos de entrenamiento. El patrón CRUD (crear, leer, actualizar, borrar) representa el 80% de las apps web, y la IA lo domina.

Por qué se rompe en game dev

Los motores de juegos tienen tres problemas fundamentales que los LLMs no saben resolver:

1. Formatos binarios y propietarios

Una app web es texto puro: HTML, CSS, JavaScript, JSON. Un LLM puede leer y escribir todo eso.

Un proyecto de Unity tiene archivos .prefab, .asset, .unity — formatos binarios o YAML propietario que ningún LLM entiende. Unreal usa Blueprints, que son grafos visuales almacenados en binario.

// App web: el LLM ve esto
<div className="player" style={{position: 'absolute', left: x, top: y}}>
  <img src="/sprite.png" />
</div>

// Unity: el LLM ve esto
%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!1 &4820625918942900646
GameObject:
  m_ObjectHideFlags: 0
  m_CorrespondingSourceObject: {fileID: 0}
  m_PrefabInstance: {fileID: 0}

¿Cuál de los dos puede editar un LLM? Exacto.

2. Estado del editor vs estado del código

En desarrollo web, el código ES la aplicación. Si cambias app.js, cambias la app.

En un motor de juegos, el código es solo una parte. La otra mitad es el estado del editor: posiciones de nodos, propiedades de materiales, configuración de física, TileMaps, animaciones. Todo eso vive en el editor, no en el código.

Cuando le dices a una IA "mueve al jugador a la derecha", necesita:

Saber qué nodo es el jugador
Conocer la estructura de la escena
Entender el sistema de física del motor
Modificar tanto código como propiedades del editor

Un LLM que solo genera código no puede hacer nada de esto.

3. Loops de retroalimentación visual

En web dev, puedes hacer npm run dev y ver el resultado en el navegador. La IA puede incluso tomar screenshots y corregir errores visuales.

En game dev, necesitas ejecutar el juego dentro del motor, interactuar con él en tiempo real, y evaluar si la física "se siente bien". No hay un endpoint HTTP que devuelva "la gravedad está mal". Es un juicio visual y táctil que los LLMs no pueden hacer.

La excepción: Godot

Hay un motor que no tiene estos problemas: Godot.

Problema	Unity/Unreal	Godot
Formato de escenas	Binario/YAML propietario	Texto plano (.tscn)
Lenguaje	C#, C++	GDScript (sintaxis Python)
Acceso al editor	API limitada	API abierta (MIT)
Datos de entrenamiento	Medio	Alto (Python-like)

Las escenas de Godot son archivos de texto que un LLM puede leer y escribir:

[gd_scene format=3]

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

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

Y GDScript es básicamente Python con tipos:

extends CharacterBody2D

@export var velocidad: float = 300.0

func _physics_process(delta):
    var direccion = Input.get_axis("izquierda", "derecha")
    velocity.x = direccion * velocidad

    if Input.is_action_just_pressed("saltar") and is_on_floor():
        velocity.y = -400.0

    move_and_slide()

Si sabes Python, ya sabes GDScript.

El estado actual de la IA en game dev

Según el GDC State of the Industry 2025, el 31% de los desarrolladores de juegos usan herramientas de IA. Pero la mayoría las usa para tareas aisladas: generar arte conceptual, escribir diálogos, o crear efectos de sonido.

La generación de código para juegos sigue siendo problemática porque los LLMs no entienden el contexto del motor. No saben qué nodos tienes en tu escena, qué señales están conectadas, o cómo está configurada tu física.

Esto está cambiando. Ya existen herramientas que se integran directamente en los motores para darle al LLM acceso al estado del editor. Pero por ahora, la mayoría de los desarrolladores de juegos siguen usando la IA como un asistente de búsqueda glorificado, no como un co-desarrollador real.

¿Qué significa esto para los desarrolladores hispanohablantes?

América Latina tiene una escena indie de juegos en crecimiento. Eventos como el BIG Festival en Brasil, EVA en Argentina, y la comunidad de gamedev en español muestran que hay talento y demanda.

La combinación de un motor gratuito (Godot) + herramientas de IA que entienden sus formatos reduce la barrera de entrada significativamente. Un desarrollador solo puede crear un prototipo jugable en un fin de semana, algo que hace cinco años requería un equipo de al menos tres personas.

Si trabajas en web y nunca has tocado game dev, Godot + IA es la mejor puerta de entrada que ha existido.

Cómo empezar

Descarga Godot (godotengine.org) — 100 MB, sin instalación
Haz el tutorial oficial — "Tu primer juego 2D" en ~2 horas
Usa un LLM para escribir GDScript — Claude y GPT-4 lo entienden bien
Publica en itch.io — gratis, con feedback de la comunidad

Si alguien de la comunidad DEV.to en español ya desarrolla juegos con Godot, me encantaría saber su experiencia en los comentarios.

Warum Godot 2026 die beste Engine für KI-gestützte Spieleentwicklung ist

Ziva — Mon, 06 Apr 2026 04:10:46 +0000

Wenn du als Entwickler in Deutschland, Österreich oder der Schweiz Spiele entwickeln willst, hast du wahrscheinlich schon von Unity und Unreal gehört. Aber Godot hat sich in den letzten zwei Jahren still zur besten Engine für KI-gestützte Entwicklung gemausert. Hier ist warum.

Die Ausgangslage: KI und Game Dev

Laut dem GDC State of the Industry Report 2025 nutzen mittlerweile 31% aller Spieleentwickler KI-Tools in ihrer täglichen Arbeit. Aber es gibt ein Problem: Die meisten KI-Tools sind für Web-Entwicklung optimiert, nicht für Game Engines.

Der Grund ist simpel: Game Engines haben proprietäre Dateiformate, binäre Szenen-Strukturen und geschlossene Editoren. Ein LLM kann deinen Python- oder JavaScript-Code lesen und schreiben, aber mit einer Unity .prefab-Datei oder einem Unreal Blueprint kann es wenig anfangen.

Warum Godot hier einen strukturellen Vorteil hat

Godot macht drei Dinge anders als Unity und Unreal:

1. Textbasierte Szenen-Dateien

Godots .tscn-Dateien sind reiner Text. Eine einfache Szene sieht so aus:

[gd_scene format=3]

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

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

Ein LLM kann diese Dateien lesen, verstehen und generieren. Bei Unity sind Prefabs binär oder in einem YAML-Format, das ohne den Unity-Editor kaum zu bearbeiten ist.

2. GDScript ist LLM-freundlich

GDScript basiert auf Python-Syntax. Jedes moderne LLM hat Milliarden von Python-Tokens in seinen Trainingsdaten. Das bedeutet: Code-Generierung für Godot funktioniert deutlich besser als für C# (Unity) oder C++ (Unreal).

extends CharacterBody2D

@export var geschwindigkeit: float = 300.0
@export var sprungkraft: float = -400.0

var schwerkraft = ProjectSettings.get_setting("physics/2d/default_gravity")

func _physics_process(delta):
    if not is_on_floor():
        velocity.y += schwerkraft * delta

    if Input.is_action_just_pressed("sprung") and is_on_floor():
        velocity.y = sprungkraft

    var richtung = Input.get_axis("links", "rechts")
    velocity.x = richtung * geschwindigkeit

    move_and_slide()

Wenn du Python kannst, kannst du GDScript in einer Stunde lernen.

3. Vollständig Open Source

Godot ist MIT-lizenziert. Der gesamte Quellcode, die Editor-API und alle internen Strukturen sind offen dokumentiert. Das ist entscheidend für KI-Integration, weil:

KI-Tools können auf den Editor-State zugreifen (welche Nodes existieren, welche Properties sie haben)
Plugins können den Editor erweitern, um KI-Funktionen direkt einzubetten
Keine API-Beschränkungen wie bei Unity oder Unreal

Eigenschaft	Godot	Unity	Unreal
Szenen-Format	Text (.tscn)	Binär/YAML	Binär
Skriptsprache	GDScript (Python-ähnlich)	C#	C++/Blueprints
LLM-Kompatibilität	Hoch	Mittel	Niedrig
Editor-API	Offen (MIT)	Teilweise offen	Teilweise offen
Preis	Kostenlos, keine Umsatzbeteiligung	Kostenlos bis 200K$	Kostenlos bis 1M$
Download-Größe	~100 MB	~15 GB	~60 GB

Was das praktisch bedeutet

Ein konkretes Beispiel: Du willst ein 2D-Plattformspiel mit drei Levels erstellen.

Ohne KI: Du schreibst manuell den Spieler-Controller, designst jedes Level im Editor, erstellst oder kaufst Sprites, schreibst die Level-Logik. Zeitaufwand: 2-4 Wochen.

Mit KI + Godot: Du beschreibst den Spieler-Controller in natürlicher Sprache, generierst GDScript, lässt Level-Layouts per KI erstellen (die .tscn-Dateien sind ja Text), generierst Sprites mit Bildgeneratoren. Zeitaufwand: 2-3 Tage.

Der Geschwindigkeitsvorteil kommt nicht daher, dass KI "besser" programmiert. Er kommt daher, dass Godots Architektur es KI-Tools einfach macht, mit dem Engine-Format zu arbeiten.

Die deutsche Spieleentwickler-Szene

Deutschland hat eine wachsende Indie-Szene. Die gamescom in Köln ist die weltweit größte Spielemesse, und der Deutscher Computerspielpreis fördert aktiv Indie-Entwicklung. Der Bundesverband game meldet über 900 Spieleunternehmen in Deutschland.

Trotzdem gibt es kaum deutschsprachige Ressourcen für Godot. Die meisten Tutorials sind auf Englisch. Wenn du Deutsch sprichst und Godot lernen willst, musst du dich größtenteils durch englische Dokumentation arbeiten.

Das ändert sich gerade. Die offizielle Godot-Dokumentation wird zunehmend ins Deutsche übersetzt, und die Community wächst.

Wie du anfängst

Godot herunterladen (godotengine.org) — 100 MB, keine Installation nötig
Offizielles Tutorial durcharbeiten — "Dein erstes 2D-Spiel" dauert etwa 2 Stunden
KI in den Workflow einbauen — Claude, GPT-4 oder lokale Modelle verstehen GDScript
Auf itch.io veröffentlichen — kostenlos, mit Feedback von der Community

Spieleentwicklung war noch nie so zugänglich. Die Kombination aus einer kostenlosen, offenen Engine und KI-Tools, die deren Formate nativ verstehen, senkt die Einstiegshürde auf praktisch null.

Wer in der DEV.to-Community arbeitet auch mit Godot? Würde mich über Erfahrungsberichte freuen.