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.