English
Español
Català
Sistema de menús para Unity
Menús declarativos, temas de UI compartidos y navegación predecible, configurados como assets en vez de cableados a mano sobre GameObjects.
Para qué sirve este sistema
La mayoría de proyectos de Unity empiezan con un par de botones en un Canvas y acaban convertidos en una maraña de escenas, variantes de prefab y referencias directas. Menús de pausa, ajustes, selección de nivel y diálogos de confirmación acaban cada uno con su propio cableado a medida. El resultado es código de UI frágil que cuesta localizar, retematizar o ampliar.
El Sistema de Menús de Serenity describe los menús como datos. Cada menú es un asset de definición con sus opciones, transiciones y reglas de presentación. Un único servicio consume esas definiciones en tiempo de ejecución, dirige las vistas y emite las señales adecuadas cuando el jugador selecciona algo. Configuras menús en lugar de coser prefabs.
El problema en Unity
Los menús de Unity crecen por tres caminos dolorosos a la vez. Visualmente, cada pantalla nueva copia un prefab y se va separando del resto de la UI. En cuanto al comportamiento, los OnClick de los botones referencian objetos de escena, managers y singletons que pueden o no existir al cargar la escena. Estructuralmente, el mismo código se duplica entre el menú principal, el de pausa y cualquier overlay del juego.
Además, los menús son la superficie donde se cruzan localización, temas, input, feedback de audio y persistencia de ajustes. Si alguno de esos sistemas está cableado a medida, cada menú se convierte en un foco de bugs. Las etiquetas localizadas se desincronizan, los temas se cuecen dentro del prefab, la navegación con gamepad se rompe en ciertos paneles y los diálogos de confirmación se reinventan tres veces en el mismo proyecto.
Cómo lo aborda Serenity
Serenity trata cada menú como una unidad de configuración. Una definición de ajustes de menú declara las opciones, las vistas disponibles y los datos que cada opción necesita. Un servicio de menú lee esas definiciones y expone un conjunto pequeño de casos de uso: seleccionar una opción, cambiar su valor, confirmar o cancelar. Las vistas se enganchan a través de presenters y view models, así que la capa visual nunca es dueña del estado de navegación.
Cuando el jugador interactúa con la UI, el servicio emite señales tipadas a través del Event Dispatcher. El resto del proyecto reacciona a esas señales en vez de llamar al prefab del menú directamente. Puedes cambiar el prefab, retematizar la pantalla o cambiar el orden de navegación sin tocar el código de juego que responde a las confirmaciones.
Las transiciones entre vistas de menú se describen con su propio caso de uso, así que abrir un submenú, volver atrás o saltar a una vista hermana deja de ser un script a medida por pantalla. La misma definición puede alimentar el menú principal, el de pausa o cualquier overlay porque las reglas viven en los datos, no en el prefab.
Cómo encaja en Serenity
El Sistema de Menús pertenece a la capa de Aplicación dentro del namespace Serenity.Menu y usa interfaces de Dominio como IMenuSettingsDefinition para describir la configuración. La capa de Infraestructura aporta las implementaciones Unity del servicio, las factorías de vistas y los presenters. Un instalador dedicado lo registra todo para que el resto del proyecto resuelva los menús a través de interfaces.
Los menús no viven aislados. Dependen del sistema de Temas de UI para los visuales y el feedback sonoro compartidos, de Localización para las etiquetas, del Sistema de Input para la navegación, del Event Dispatcher para las señales salientes y del Sistema de Modales para los diálogos de confirmación. Las transiciones de Game Mode pueden abrir o cerrar menús cuando el juego entra o sale de un estado. El código del menú se centra en seleccionar y transicionar; la presentación, el input y el idioma vienen de sistemas ya conectados.
Como cada capa se describe con interfaces, cambiar cualquier pieza consiste en registrar una implementación distinta en el instalador. Puedes sustituir la factoría de vistas para introducir un renderizado a medida, sustituir el presenter para añadir analítica o reemplazar el servicio entero en tests. Los assets de configuración no cambian, así que las definiciones de menú existentes siguen funcionando cuando cambia la implementación.
Flujo de trabajo práctico
- Crea un asset de definición de menú para la pantalla que quieres construir, por ejemplo un menú de pausa o uno de ajustes.
- Añade las opciones, valores por defecto y vistas o transiciones objetivo dentro de la definición.
- Asigna el prefab de vista del menú y conéctalo al tema de UI compartido que usa el resto de la interfaz.
- Deja que el instalador de menús registre el servicio y las factorías durante la pipeline de inicialización.
- Reacciona a las señales salientes como OnMenuSubmitOptionSignal en los sistemas que deben responder a las elecciones del jugador.
- Itera sobre opciones, orden y visuales desde el asset de definición sin tocar el cableado de la escena.
Qué incluye
- Definiciones de menú declarativas como assets basados en ScriptableObject
- Casos de uso para seleccionar, cambiar valor, confirmar y cancelar opciones
- Caso de uso de transición MenuTransitionateToView para moverte entre subvistas
- Señales salientes como OnMenuSubmitOptionSignal encaminadas por el Event Dispatcher
- Factorías de vista, presenter y view model que mantienen la capa visual reemplazable
- Factoría de servicio IMenuServiceFactory para poder sustituir el propio servicio de menú
- Integración con el tema de UI compartido para no duplicar estilos visuales
- Integración con Localización para etiquetas y textos de opciones
- Compatible con el Sistema de Input para navegación con teclado, gamepad y puntero
- Instaladores que registran el sistema una sola vez en todo el proyecto
- Separación limpia entre las capas de Dominio, Aplicación e Infraestructura
Cuándo usarlo
- Proyectos con más de una pantalla de menú que necesitan coherencia visual y de comportamiento entre ellas.
- Equipos que quieren localizar y retematizar los menús sin editar prefabs de escena.
- Juegos donde los menús de pausa, ajustes y los del juego deben compartir las mismas convenciones de input, audio y tema.
- Bases de código que se mueven del cableado directo con UnityEvent a un flujo basado en señales tipadas.
- Proyectos donde la navegación de menús debe ser testeable de forma aislada respecto a las escenas de Unity.
Sistemas relacionados
Usa Serenity cuando quieras un sistema de menús que ya habla con temas, localización, input y eventos, pero que sigue siendo configurable desde tu propio proyecto de Unity.