Organización y Arquitectura en Godot: Un enfoque desde el desarrollo de software

Como desarrollador de software que se adentra en el mundo del gamedev con Godot 4, una de las primeras dudas que me asaltan al empezar un proyecto es: “¿Cómo organizo todo esto para que no se convierta en un caos inmanejable en un par de semanas?”.

En el desarrollo web o de aplicaciones solemos tener patrones muy estandarizados, pero en el desarrollo de videojuegos he visto que, especialmente al principio, es fácil dejarse llevar y acabar con una maraña de Scenes, Scripts y Assets mezclados.

No pretendo sentar cátedra ni decir que exista una “verdad absoluta” en esto, pero repasando mis notas de formación en Godot (mientras trasteaba con un Action-Adventure 2D), he identificado dos enfoques principales. Curiosamente, uno de ellos me resulta muy familiar por mi background profesional.

1. Organización por Tipo de Archivo (La estructura clásica)

Esta es la estructura que más suelo encontrar en tutoriales o proyectos pequeños. Consiste en agrupar los ficheros basándose puramente en su extensión o tipo.

📁 res://
├── 📁 scenes/
│   ├── player.tscn
│   ├── enemy.tscn
│   └── main_menu.tscn
├── 📁 scripts/
│   ├── player.gd
│   └── enemy.gd
└── 📁 assets/
    ├── 📁 sprites/
    └── 📁 audio/

¿Cuándo creo que tiene sentido? Me cuadra para proyectos pequeños, game jams o prototipos muy rápidos. Es súper intuitivo al principio, pero le veo un problema de escalabilidad: si quieres modificar al jugador, tienes que saltar entre tres o cuatro carpetas distintas buscando su escena, su script y sus sprites. Para mí, se pierde cohesión y degrada la developer experience.

2. Organización por Sistemas de Juego (El enfoque del desarrollador)

Aquí es donde me sentí identificado con mi día a día como desarrollador. Organizar por Game Systems significa agrupar todos los ficheros relacionados con una misma feature o dominio en un único lugar.

Si te dedicas al desarrollo de software convencional, esto te sonará mucho: es el equivalente al Vertical Slicing de una Arquitectura Hexagonal o a los Bounded Contexts de Domain-Driven Design (DDD).

📁 res://
├── 📁 entities/
│   ├── 📁 player/
│   │   ├── player.tscn
│   │   ├── player.gd
│   │   └── player_spritesheet.png
│   └── 📁 enemy_goblin/
├── 📁 systems/
│   ├── 📁 combat/
│   │   ├── hitbox.tscn
│   │   └── damage_manager.gd
│   └── 📁 dialogue/
└── 📁 ui/

¿Por qué me resulta más cómodo a largo plazo?

• Alta cohesión: Todo lo que el Player necesita para funcionar (su escena, su lógica y su arte) vive bajo el mismo techo.
• Aislamiento: Me da la sensación de tener un mayor dominio sobre cómo funciona el juego. Si decido eliminar la carpeta dialogue, elimino todo el sistema de diálogo de golpe, sin dejar scripts o sprites huérfanos perdidos por el proyecto.
• Modularidad: Creo que facilita mucho aislar partes de tu juego para convertirlas en plugins o llevarte un sistema entero a otro proyecto de Godot en el futuro.

Profundidad de directorios: ¿Flat o Deep?

Además de decidir cómo agrupar, en el módulo de la formación se mencionaba un factor que me pareció muy interesante: la profundidad del árbol de directorios.

• Flat structure (Estructura plana): Pocos niveles de carpetas, pero muchos archivos dentro de cada una. Facilita la búsqueda visual rápida, pero puede ser abrumador si un sistema crece demasiado.
• Deep structure (Estructura profunda): Muchos niveles de subcarpetas (ej. res://entities/enemies/bosses/stage1/). Mantiene las carpetas muy limpias, pero te obliga a hacer una barbaridad de clics para llegar al script que necesitas.

Mi conclusión personal

Sabiendo que cada proyecto es un mundo, para mi viaje de aprendizaje con Godot 4 voy a apostar por la organización por sistemas de juego, intentando mantener una estructura relativamente plana.

Aplicar un poco de la mentalidad de desarrollo de software modular al árbol de nodos de Godot no solo me da más tranquilidad mental, sino que me da la confianza de que el proyecto podrá crecer sin colapsar sobre su propio peso. Al menos, esa es la teoría; veremos qué tal se da en la práctica.