Organiza tu proyecto: carpetas, nombres y estructura

Por qué importa desde el día uno#

Un proyecto de 20 archivos se aguanta de cualquier forma. Uno de 2.000, no. La diferencia entre terminar un juego y ahogarte en él pasa mucho por la organización. Establece una estructura desde el principio: cambiarla después es doloroso.

Estructura de carpetas#

Una convención sencilla y probada para la carpeta Assets:

texto

Assets/
├── _Project/          (opcional, para separar lo tuyo de assets externos)
├── Art/
│   ├── Sprites/
│   ├── Models/
│   └── Materials/
├── Audio/
│   ├── Music/
│   └── SFX/
├── Prefabs/
├── Scenes/
├── Scripts/
│   ├── Player/
│   ├── Enemies/
│   ├── UI/
│   └── Systems/
├── ScriptableObjects/
└── Settings/

Separa lo tuyo de lo importado

Los assets de la Asset Store traen sus propias carpetas y ensucian la raíz. Mete tu trabajo en una carpeta con un prefijo que quede arriba (por ejemplo _Project/ o _Game/): así lo tuyo siempre está junto y separado de lo externo.

Organiza por tipo o por función, pero sé consistente

Hay dos escuelas: por tipo (todos los scripts juntos, todos los prefabs juntos) o por función/feature (una carpeta Player con su script, su prefab y su arte dentro). Ambas valen. Lo que hunde un proyecto es mezclarlas sin criterio. Elige una y respétala en todo el proyecto.

Convenciones de nombres#

Consistencia > perfección: elige un estilo y aplícalo siempre.
Nombres descriptivos: PlayerHealth, no Script1 ni Health2.
Clases y archivos en PascalCase y coincidiendo (la clase PlayerHealth en PlayerHealth.cs).
Prefabs y assets con nombres claros; evita "Nuevo material (3)".
Un prefijo o sufijo por tipo si te ayuda (PlayerData_SO para ScriptableObjects, UI_MainMenu).

Un script, una responsabilidad#

Si un script hace diez cosas (mueve, dispara, gestiona vida, guarda partida...), divídelo. Scripts pequeños y enfocados son más fáciles de leer, reutilizar y depurar. Es el principio de responsabilidad única, y encaja con separar lógica de presentación: que el sistema de vida no sepa de UI, y que la barra de vida solo escuche eventos.

Namespaces y Assembly Definitions#

Para proyectos que crecen

Namespaces: agrupan tus clases y evitan choques de nombres (MiJuego.Player, MiJuego.UI). Recomendable en proyectos medianos y grandes.
Assembly Definitions (.asmdef): dividen tu código en módulos que compilan por separado. Ventaja enorme: al cambiar un script, Unity recompila solo su módulo, no todo el proyecto, y los tiempos de compilación bajan mucho. Además fuerzan una arquitectura con dependencias claras.

Escala: piensa en el futuro#

🛠️ Decisión de ingeniería

Prototipo / game jam → una estructura mínima basta; no te obsesiones
Proyecto de meses en solitario → carpetas claras + convenciones + namespaces
Equipo / proyecto grande → todo lo anterior + Assembly Definitions + separación estricta lógica/presentación + control de versiones

Errores frecuentes#

Dejar todo en la raíz de Assets hasta que es inmanejable.
Mezclar organización por tipo y por función sin criterio.
Nombres genéricos (Script1, Nuevo material) imposibles de encontrar luego.
Scripts monstruo que hacen de todo.
Reorganizar tarde: mover carpetas rompe referencias si no lo haces dentro de Unity (Unity mantiene los enlaces; moverlas desde fuera del editor los rompe).

Resumen#

Define desde el principio una estructura de carpetas clara (por tipo o por función, pero consistente), separa tu trabajo de los assets importados, usa nombres descriptivos y coherentes, y aplica un script = una responsabilidad. En proyectos grandes, añade namespaces y Assembly Definitions para acelerar la compilación y forzar dependencias limpias. Acompáñalo de control de versiones.