Si has seguido la serie de Unity, ya tienes tu personaje moviéndose, las animaciones funcionando y hasta una cámara que lo persigue. Enhorabuena. Pero te voy a decir algo que quizá no te guste: ahora mismo no tienes un juego, tienes una demo técnica.

Y aquí es donde se atasca el 90% de la gente. No puedes cambiar de mapa, no puedes guardar la partida, no hay un menú ni un inventario. Sin todo eso, nadie va a jugar a tu juego más de dos minutos, por muy bien que se mueva el personaje. El error no es que falten mecánicas: es que faltan los sistemas que convierten un escenario bonito en una experiencia.

La diferencia entre una demo y un juego real no está en añadir más cosas a lo loco, sino en construir esos sistemas de forma que crezcan sin romperse. Si los montas a base de parches, en dos semanas no entenderás ni tu propio código. Si los montas bien, tienes una base sobre la que seguir construyendo durante meses.

En esta segunda parte del tutorial te llevo por las cuatro piezas que dan ese salto: abrir el mundo con varios mapas conectados, un sistema de transiciones limpio y escalable, un menú profesional con pestañas e inventario, y un guardado que funciona en cualquier dispositivo. Vamos a ello.

De un mapa a un mundo: sin exploración no hay juego

El primer problema es que todo ocurre en un único mapa. Has creado una ciudad preciosa, sí, pero el jugador no puede salir de ella. No hay sensación de mundo, no hay exploración. Y si el jugador no puede descubrir nada nuevo, no tiene ningún motivo para seguir jugando. Ahí mueren la mayoría de los proyectos indie: un escenario y punto.

La solución es abrir el mundo. Creamos un segundo mapa —en este caso un bosque junto a la ciudad— pintándolo en la capa del ground del tilemap y aprovechando la técnica multicapa para que el personaje pueda pasar por detrás de los elementos y darle profundidad. Para que la cámara no se salga, definimos los límites de cada zona con un Polygon Collider 2D dentro de un objeto vacío de camera bounds, que confina la cámara de Cinemachine a cada espacio (la ciudad la bautizamos t1, de town 1).

Este tipo de decisiones de diseño 2D son justo las que trabajamos a fondo en la ruta del creador de videojuegos, donde pasas de mover un cubo a construir mundos completos.

Transiciones sin parches: waypoints y enumerados

Ya tenemos dos mapas, ciudad y bosque. Ahora viene la parte crítica: cómo pasar de uno a otro sin romper la lógica del juego. Y aquí es donde casi todo el mundo se equivoca.

• ❌ El parche rápido: hardcodear posiciones y meter condiciones manuales en el código. Cada mapa nuevo duplica la complejidad y, en dos semanas, ni tú entiendes tu propio código. Y si tú no lo entiendes, imagina los demás.
• ✅ La solución profesional: un sistema de transiciones con waypoints y enumerados para definir las direcciones (norte, sur, este, oeste). El código queda limpio, escalable y preparado para crecer sin romperse, trabajes solo o en equipo.

La mecánica es sencilla y elegante: cuando el personaje llega al borde de la ciudad, lo teletransportamos al inicio del bosque; cuando vuelve hacia la entrada de la ciudad, lo llevamos de vuelta. Todo gestionado con triggers y con un campo Polygon Collider 2D marcado como SerializeField, para arrastrarlo desde el editor de Unity sin tener que hacerlo público. Esa pequeña diferencia entre código rígido y código escalable es la que separa a un aficionado de alguien que sabe lo que hace. Si quieres dominar ese C# bien estructurado, el curso Aprende C# creando un videojuego desde cero con Unity es el punto de partida ideal.

Un menú de verdad: pausar, gestionar y dar feedback

Hasta ahora tu juego no tiene ninguna interfaz real. No puedes pausar, no puedes gestionar nada, y eso rompe por completo la experiencia. Un jugador necesita control: necesita parar, ver información, tomar decisiones. Sin eso, la inmersión se cae.

Para construirlo creamos un UI Canvas (con el render mode en Screen Space, lo recomendable para un juego así). Al hacerlo aparece de regalo el Event System, que es lo que permite clicar botones y mover sliders. Sobre ese canvas montamos un menú con pestañas —ajustes, inventario y lo que quieras añadir— que cambian de color al activarse para que el jugador sepa siempre dónde está. Y todo bien organizado en carpetas, porque mañana querrás añadir una segunda o una tercera pantalla.

El inventario vive aquí, como una pestaña más, y es una lógica que vas a querer reutilizar en casi todos tus próximos juegos. Si las interfaces son tu punto débil, el curso Domina las interfaces de usuario en Unity 6 te lleva del cero al experto en UI/UX interactiva.

Guardar la partida: el sistema que mata más juegos que cualquier bug

Piénsalo: antes te pasabas el Super Mario Bros en una tarde, pero hoy eso es impensable. Un juego sin guardado es un juego que nadie termina. Por eso esta es, de lejos, la pieza más importante de todas.

Vamos a implementar un sistema de guardado real con ficheros JSON en Unity. Guardaremos el mapa, la posición del jugador y, más adelante, cosas como el inventario. La arquitectura es limpia: un SaveController con la lógica y un SaveDataque actúa como contenedor de datos serializables, ambos en su propia carpeta dentro de los controladores. Incluso los límites de cámara se guardan como datos serializables dentro del JSON.

Y aquí entra una de mis clases favoritas: Path.Combine. Gracias a ella, la ruta del fichero de guardado se construye de forma correcta en cualquier sistema operativo, así que tu juego funcionará no solo en tu ordenador, sino en cualquier dispositivo donde lo publiques. Conectamos un botón de guardar al evento OnClick para que el jugador guarde cuando quiera, y antes de programar la carga probamos que el fichero se genera bien. Pequeños detalles, enorme diferencia. Para llegar a este nivel de arquitectura, el curso Experto en Programación Avanzada con Unity y C# es el siguiente escalón natural.

La idea clave: ya no estás siguiendo un tutorial, estás construyendo un juego en Unity

Párate un momento a mirar lo que tienes entre manos. Múltiples mapas conectados, un sistema de transiciones escalable, una UI profesional con pestañas, un inventario y un guardado que funciona en cualquier dispositivo. Esto ya no es un simple tutorial.

El antes y el después es enorme. Antes: una demo técnica preciosa donde el personaje se movía y poco más, igual que los miles de proyectos que se quedan en scripts sueltos y pruebas que nunca terminan. Después: una base real de videojuego sobre la que puedes seguir creciendo —una tercera parte, una cuarta, las funcionalidades que quieras— sin que el código se te venga abajo, porque está construido para escalar.

Esa es la verdadera diferencia entre quien sigue tutoriales y quien crea videojuegos de verdad: no las mecánicas sueltas, sino los sistemas bien pensados. Si quieres recorrer ese camino completo, con proyectos reales y un orden que de verdad te lleve a publicar, te espero en la ruta de creación de videojuegos de Frogames.

Has dejado de tener una demo. Ahora tienes un mundo. Sigue construyéndolo.

Este artículo forma parte de una serie sobre desarrollo de videojuegos en Unity. Si quieres aprender a crear un juego Top-Down 2D completo, con movimiento, inventario, NPCs, diálogos y una arquitectura escalable, echa un vistazo al curso completo.