Si ya tienes NPCs que caminan, se paran, te miran con cara de saber cosas y además te sueltan sus frases de diálogo por pantalla, enhorabuena. Tu RPG empieza a parecer un RPG de verdad. Pero hay un momento en el que uno mira su código y piensa: esto funciona, sí, pero como siga creciendo un poco más, explota.

Ese era exactamente el problema. Los NPCs estaban haciendo demasiado trabajo. No solo se encargaban de moverse o de lanzar sus líneas de diálogo, sino también de gestionar paneles de interfaz, nombres, retratos, texto y botones. Y eso, aunque arranque bien en una demo pequeña, se convierte en un festival del caos en cuanto quieres escalar.

La solución pasa por dos ideas muy potentes: refactorizar la lógica del diálogo con un Dialogue Controller y crear un sistema de elecciones ramificadas para que el jugador no se limite a leer, sino que pueda contestar y alterar el flujo de la conversación.

El primer paso: sacar la UI fuera del NPC

Un NPC no debería saber nada sobre paneles, cajas de texto o retratos en pantalla. Su responsabilidad es mucho más simple: tener información y desencadenar una conversación. Todo lo relacionado con la interfaz debería vivir en otro sitio.

Aquí entra en juego el Dialogue Controller, un controlador centralizado que se ocupa exclusivamente de la UI del sistema de diálogos. Este patrón tiene muchísimas ventajas:

• Evita duplicar referencias a paneles y textos en cada NPC.
• Reduce el acoplamiento entre lógica de juego e interfaz.
• Hace que el sistema sea más limpio, más mantenible y más escalable.
• Permite reutilizar el mismo flujo para cualquier personaje del juego.

La idea es muy simple. En vez de que el NPC escriba directamente en la caja de diálogo, ahora le dice al Dialogue Controller algo como: muestra este panel, pon este nombre, usa este retrato y escribe este texto.

Como además interesa que exista una sola instancia compartida en toda la escena, este controlador se monta como singleton. Así cualquier NPC puede acceder a él desde cualquier punto sin necesidad de arrastrar referencias por todas partes.

Qué métodos necesita un Dialogue Controller

Una vez separas responsabilidades, el controlador del diálogo no necesita ser especialmente complejo. De hecho, con unos pocos métodos bien pensados ya tienes la base resuelta:

• Mostrar u ocultar la UI del diálogo.
• Asignar nombre e imagen del NPC.
• Escribir una línea completa.
• Añadir letras una a una para el efecto máquina de escribir.
• Resetear el texto cuando empieza o termina una conversación.

Aquí hay un detalle elegante: puedes usar sobrecarga de métodos para que el mismo nombre sirva para varias variantes del texto. Por ejemplo, una versión para escribir una cadena completa, otra para añadir solo un carácter y otra para vaciar la caja. Eso hace que el código sea más expresivo y mucho más fácil de leer.

Además, al marcar las referencias de UI como privadas y serializables, mantienes el encapsulamiento sin perder comodidad dentro del editor de Unity.

Convertir NPCs en prefabs para no morir creando personajes

Cuando el sistema de diálogo ya no depende de referencias manuales dentro de cada NPC, por fin puedes hacer lo que de verdad interesa en un RPG: crear personajes nuevos sin repetir trabajo absurdo.

La mejor forma de hacerlo es convertir tu NPC base en un prefab. Así puedes clonarlo, cambiar su sprite library, sus datos de diálogo, sus waypoints y listo. Tienes un personaje nuevo funcionando en segundos.

Esto acelera muchísimo el desarrollo. Ya no estás rehaciendo la misma configuración una y otra vez. Solo instancias, ajustas y sigues avanzando.

Si estás montando un proyecto de este estilo y quieres una guía más completa paso a paso, aquí tienes el curso completo de RPG top down 2D en Unity, donde todo este sistema encaja dentro de una progresión mucho más amplia.

El bug clásico del botón de cerrar diálogo

En cuanto empiezas a duplicar NPCs, aparece un fallo muy típico. El botón de cerrar la ventana del diálogo estaba ligado a un NPC concreto. Mientras solo había uno, no pasaba nada. En cuanto lo eliminas, lo conviertes en prefab o aparecen varios personajes, la referencia deja de tener sentido.

La solución buena no es volver a enlazarlo a mano cada vez. La solución buena es hacer que el Dialogue Controller sepa qué NPC ha iniciado la conversación actual.

Así, cuando empieza un diálogo, se guarda la referencia al NPC activo. Y cuando se pulsa la X, el controlador llama al método de finalización del personaje correcto. Con eso se restablecen estados, se paran corrutinas, se limpia el texto y se cierra todo sin depender de un objeto fijo de la escena.

Es una mejora pequeña en apariencia, pero convierte el sistema en algo realmente robusto.

Dar voz al jugador con Dialogue Choice

Hasta aquí los NPCs hablan muy bien, pero el jugador sigue siendo poco más que una estatua educada. Lee, asiente y ya. En un RPG eso sabe a poco.

Para introducir decisiones, hace falta una nueva estructura de datos. En este caso, una clase como Dialogue Choice permite definir, desde el inspector, tres cosas:

• En qué línea del diálogo aparecen las opciones.
• Qué respuestas puede elegir el jugador.
• A qué línea debe saltar la conversación después de cada respuesta.

Con eso ya tienes la base de un árbol de conversaciones. Algunas líneas seguirán un flujo secuencial normal y otras bifurcarán en función de la respuesta elegida.

Por ejemplo, una frase como “¿Me puedes ayudar?” puede ofrecer dos botones: sí o no. Si eliges sí, el NPC responde una cosa. Si eliges no, responde otra distinta. Y cada rama puede terminar ahí o seguir desarrollándose.

Marcar qué líneas terminan la conversación

Cuando dejas de trabajar con diálogos lineales, necesitas una forma clara de indicar qué líneas son terminales. Si no, el sistema intentará seguir avanzando aunque conceptualmente la charla ya se haya acabado.

La solución es añadir un array booleano que marque qué líneas finalizan el diálogo. Así el sistema puede comprobar, al terminar una frase, si debe cerrar la conversación, mostrar opciones o pasar a la siguiente línea.

Esto parece un detalle técnico menor, pero en realidad es lo que permite mezclar frases lineales, bifurcaciones y finales de conversación sin perder el control.

Diseñar la interfaz de elecciones en el Canvas

Una vez existe la lógica, toca hacer que el jugador vea las opciones en pantalla. Para eso basta con añadir dentro del panel de diálogo un subpanel dedicado a las respuestas.

Ese panel puede organizarse con un Vertical Layout Group para que los botones se apilen automáticamente uno debajo del otro. De esta forma, si una conversación tiene dos respuestas aparecen dos botones. Si tiene cuatro, aparecen cuatro.

Lo más práctico es diseñar un único choice button con el estilo visual que te guste y convertirlo en prefab. Luego el código lo instanciará dinámicamente tantas veces como haga falta.

Esto mantiene la estética consistente y evita tener botones “fantasma” puestos a mano que luego hay que activar y desactivar.

UnityAction y callbacks para conectar cada botón con su consecuencia

Aquí llega una de esas partes que al principio parecen magia negra, pero en cuanto entiendes el patrón ya no hay vuelta atrás.

Cada botón necesita dos cosas:

• El texto que va a mostrar.
• La acción que debe ejecutarse al pulsarlo.

Para eso viene de maravilla trabajar con UnityAction y callbacks. El Dialogue Controller crea el botón, le cambia el texto y le añade un listener al evento onClick. Ese listener ejecuta una función que cambia el índice del diálogo actual al índice correspondiente de la rama elegida.

Dicho de forma menos técnica: pulsas una opción y el sistema sabe exactamente a qué frase debe saltar después.

Antes de mostrar nuevas opciones, además, conviene limpiar las anteriores para no arrastrar botones de conversaciones previas. Ese pequeño gesto evita muchos errores visuales y de lógica.

Conversaciones ramificadas, bucles y más complejidad

Lo bonito de esta arquitectura es que no se limita a un sí o no básico. También puedes hacer conversaciones más complejas con varias ramas, reacciones distintas e incluso bucles.

Eso significa que un personaje puede hacer una pregunta, recibir una respuesta ambigua y volver a insistir. O redirigir al jugador a una línea anterior hasta que tome una decisión clara. Todo eso se consigue sin tocar la estructura del sistema, solo configurando correctamente los índices de salto.

Y ese es precisamente el momento en el que el proyecto pega un salto de calidad enorme. Ya no tienes personajes que recitan frases. Tienes NPCs que interactúan.

Por qué este sistema merece la pena

Montar un sistema de decisiones de diálogo en Unity 2D no es solo una mejora visual o narrativa. Es una inversión en arquitectura.

Con este enfoque consigues:

• Código más limpio al separar NPC y UI.
• Escalabilidad real para añadir docenas de personajes.
• Conversaciones ramificadas sin reescribir lógica cada vez.
• Mayor inmersión al dar voz al jugador.
• Una base perfecta para futuras quests y misiones.

Y eso es lo importante. No se trata solo de que funcione hoy. Se trata de que dentro de varias semanas, cuando tengas más NPCs, más mapas y más sistemas encima, el proyecto siga siendo manejable.

Si estás aprendiendo desarrollo de videojuegos y te interesa profundizar en Unity, puedes echar un vistazo a la sección de cursos de Unity o explorar la ruta de desarrollo de videojuegos para seguir construyendo sistemas cada vez más completos.

El siguiente nivel

Con esto ya tienes un sistema de diálogos digno de un RPG indie muy serio. Y lo mejor es que la base está puesta para seguir creciendo. A partir de aquí resulta natural conectar elecciones con misiones, recompensas, estados del mundo o condiciones según inventario.

Cuando llegas a este punto, el juego deja de ser una demo con muñequitos moviéndose y empieza a convertirse en un mundo con intención. Y esa diferencia se nota muchísimo.

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.