Hay un momento en el desarrollo de un videojuego, ya sea en Unity o en cualquier otro motor,  en el que todo cambia. Hasta ese instante, tu personaje se mueve, explora, entra en la ciudad, sale al bosque y parece que el proyecto ya tiene forma. Pero si no puede recoger nada, si no puede guardar una poción, si no puede llevarse una espada o un tesoro, entonces sigue siendo un fantasma bonito con patas.

Y eso, en un RPG, en una aventura top down o en cualquier juego con sensación de progreso, es un problema serio.

La progresión no es solo subir de nivel. La progresión también es abrir la mochila y ver cómo se va llenando. Es ordenar tus objetos. Es recordar dónde dejaste esa poción de vida. Es sentir que lo que has encontrado en el mundo realmente te pertenece.

Por eso, uno de los saltos más grandes que puedes darle a tu proyecto en Unity es construir un sistema de inventario de verdad. No uno improvisado. No uno que se rompa al cambiar el tamaño de la interfaz. No uno que falle al arrastrar objetos. Sino uno robusto, escalable y con ese tacto profesional que hace que el juego se sienta vivo.

La base visual: un inventario que no explote al crecer

Uno de los errores más comunes al montar un inventario en Unity es colocar las casillas a mano, una por una, ajustando coordenadas de UI como si estuviéramos en el paleolítico del desarrollo de interfaces.

Eso funciona durante cinco minutos. En cuanto decides cambiar el tamaño de los slots, meter una fila adicional o reajustar márgenes, se convierte en un infierno.

La solución elegante pasa por usar Grid Layout Group. Con esta componente, el inventario deja de ser una colección rígida de imágenes colocadas a martillazos y pasa a ser una estructura automática de filas y columnas.

La idea es sencilla:

• Crear un contenedor para el inventario.
• Añadirle un Grid Layout Group.
• Definir tamaño de celda, espaciado y padding.
• Usar un prefab de slot en lugar de duplicar elementos manualmente.

Ese último punto es clave. Si tu slot base está prefabado, puedes reutilizarlo, modificarlo y poblar el inventario dinámicamente sin rehacer toda la interfaz. Eso es lo que separa una UI de prueba de una UI pensada para escalar.

El slot: la unidad mínima del inventario

Cada casilla del inventario necesita saber una sola cosa importante: qué objeto contiene ahora mismo.

Por eso basta con un script sencillo para el slot que mantenga una referencia al objeto actual. Nada más. Sin lógica innecesaria. Sin Update. Sin ruido.

Además, conviene preparar el slot para lo que vendrá después:

• Que sea interactuable.
• Que pueda recibir clics.
• Que sirva como destino para arrastrar y soltar objetos.

Aquí entra otra componente de Unity muy útil: Canvas Group. Permite controlar interactividad, transparencia y comportamiento visual durante el drag and drop.

El controlador del inventario: generar slots y poblarlos dinámicamente

Una vez que tienes el panel del inventario y un prefab de slot, lo correcto es que el sistema genere automáticamente tantas casillas como necesite.

Por ejemplo, si has calculado que caben 24 objetos, no tiene sentido duplicar 24 veces el mismo slot a mano. El controlador del inventario puede instanciarlos al arrancar y dejarlos listos en el Grid Layout.

Esto, además, te deja la puerta abierta a algo muy jugoso: expansiones de mochila.

Si más adelante quieres que un comerciante venda bolsas nuevas, o que el jugador desbloquee más espacio, solo tienes que aumentar el número de slots. Tu sistema ya está preparado para crecer sin romperse.

Drag and Drop: cuando el inventario deja de parecer una hoja de Excel

Un inventario donde no puedes mover objetos se siente muerto. El jugador quiere organizar sus pociones arriba, los materiales abajo y las cosas valiosas en el sitio que le dé la gana. Si le quitas esa libertad, le quitas control.

Y cuando el jugador pierde control, se desconecta.

Para construir un sistema de Drag & Drop en Unity, la mejor opción es apoyarse en las interfaces del sistema de eventos:

• IBeginDragHandler
• IDragHandler
• IEndDragHandler

La lógica general es esta:

1. Al comenzar el arrastre, guardas el slot original.
2. El objeto deja de bloquear raycasts y se vuelve semitransparente.
3. Durante el arrastre, sigue al ratón.
4. Al soltar, detectas si cae sobre un slot vacío o sobre otro objeto.
5. Si hay otro objeto, haces swap.
6. Si no hay slot válido, devuelves el ítem a su posición original.

El detalle bonito está en centrar siempre el objeto dentro del slot al terminar el movimiento. Parece una tontería, pero ese tipo de ajustes son los que hacen que la interfaz se sienta fina en lugar de torpe.

Persistencia en JSON: que los tesoros sigan ahí cuando vuelvas

No hay nada más doloroso que guardar la partida, cerrar el juego y descubrir después que el inventario ha desaparecido o que los objetos han cambiado de sitio.

Eso rompe la confianza del jugador al instante.

Si ya tienes un sistema de guardado en JSON para cosas como la posición del personaje o el mapa actual, el siguiente paso lógico es serializar también el contenido del inventario.

¿Qué necesitas guardar de cada objeto?

• El identificador del ítem
• La posición del slot donde está

Con eso es suficiente para reconstruir el inventario al cargar la partida.

La estrategia buena consiste en definir:

• Una clase Item con un ID único.
• Un diccionario de ítems que relacione ID con prefab.
• Una clase serializable tipo InventorySaveData con itemID y slotIndex.
• Métodos para leer y escribir esta información dentro del guardado general.

Y aquí hay un truco muy elegante: usar GetSiblingIndex() para saber qué posición ocupa cada slot respecto a sus hermanos dentro del panel. Así puedes guardar la ubicación exacta sin hacer cálculos raros.

Race conditions en Unity: el bug que a veces no se ve, hasta que te explota en la cara

Cuando tienes varias piezas del sistema dependiendo unas de otras, Unity puede cargarlas en un orden que no te convenga. Y eso genera las famosas race conditions.

Por ejemplo:

• El diccionario de ítems debe existir antes que el inventario.
• El inventario debe estar listo antes de cargar los datos guardados.
• El sistema de guardado no puede reconstruir nada si las dependencias aún no están inicializadas.

La solución es simple y profesional: definir el Script Execution Order en los ajustes del proyecto.

Primero cargas el diccionario, después el controlador del inventario y finalmente el sistema de guardado. Parece un detalle técnico menor, pero este tipo de decisiones es lo que convierte un proyecto frágil en uno sólido.

Recoger objetos del mundo: cuando la mochila se conecta por fin con el gameplay

Un inventario vacío y precioso sigue sin servir de nada si no hay objetos en el escenario que puedan recogerse.

Aquí es donde entra OnTriggerEnter2D.

La lógica básica es:

• El jugador tiene un script recolector.
• Cuando entra en colisión con un objeto etiquetado como ítem, lo detecta.
• El controlador del inventario intenta añadirlo al primer slot libre.
• Si hay espacio, el objeto se destruye en la escena.
• Si no lo hay, se puede mostrar un mensaje de inventario lleno.

Para que esto funcione bien, los objetos del mundo deben estar preparados:

• Con tag de ítem.
• Con un Sprite Renderer para verse en el escenario.
• Con un Collider2D marcado como trigger.

Y, por supuesto, con su información de ítem asociada para que el inventario sepa qué prefab instanciar.

Pop-ups de recogida: el pequeño detalle que dispara la sensación de calidad

Recoger un objeto y no recibir feedback claro es malísimo. El jugador pasa por encima, el ítem desaparece y durante un segundo piensa: “Vale… ¿lo he cogido o no?”

Ahí es donde un sistema de notificaciones cambia por completo la experiencia.

La idea es montar un pequeño contenedor de pop-ups en la interfaz, normalmente en una esquina de la pantalla, y cada vez que se recoge un objeto:

• Se instancia un popup.
• Se muestra el icono del objeto.
• Se muestra su nombre.
• Permanece visible unos segundos.
• Después hace fade out y desaparece.

Para apilar varios mensajes sin caos visual, lo mejor es usar:

• Un Vertical Layout Group en el contenedor.
• Una cola para gestionar los pop-ups activos.
• Una corrutina para esperar, difuminar y destruir.

Esto tiene una consecuencia fantástica: si recoges cinco objetos seguidos, no se montan unos sobre otros como un desastre. Se ordenan, se apilan y desaparecen de forma elegante. Y eso hace que recoger loot se sienta bien. Muy bien.

Un inventario profesional no es un extra, es parte del corazón del juego

Cuando unes todas estas piezas, pasa algo importante.

Tu juego deja de ser un mapa por el que caminar y se convierte en un sistema con memoria, con progresión y con interacción real. El jugador puede:

• Recoger objetos en el mundo
• Ver inmediatamente qué ha conseguido
• Ordenar su mochila como quiera
• Guardar la partida sin perder nada
• Volver más tarde y encontrarlo todo exactamente donde lo dejó

Eso ya es terreno serio. Eso ya empieza a oler a RPG de verdad.

Y lo mejor es que este sistema te deja preparado para lo siguiente: cofres, consumibles, equipamiento, crafting, vendedores, enemigos con loot y NPCs que interactúan con tu inventario.

Si quieres seguir profundizando en desarrollo de videojuegos, Unity y creación de sistemas profesionales, puedes echar un vistazo a la ruta completa de desarrollo de videojuegos, donde todo este tipo de mecánicas se trabajan con mucho más detalle y con proyectos completos.

Porque al final de eso va esto. De dejar de hacer demos vacías y empezar a construir videojuegos que se sienten vivos.