La implementación de patrones de diseño de programación de juegos comunes en su proyecto Unity puede ayudarle a construir y mantener de manera eficiente una base de código limpia, organizada y legible. Los patrones de diseño reducen el tiempo de refactorización y pruebas, aceleran los procesos de desarrollo y contribuyen a crear una base sólida para hacer crecer su juego, su equipo y su negocio.
Piense en los patrones de diseño no como soluciones acabadas que puede copiar y pegar en su código, sino como herramientas adicionales que pueden ayudarle a crear aplicaciones más grandes y escalables.
Esta página explica los patrones de diseño Modelo Vista Controlador (MVC) y Modelo Vista Presentador (MVP).
El contenido se basa en el libro electrónico gratuito, Mejora tu código con patrones de programación de juegos.
Echa un vistazo a más artículos de la serie de patrones de diseño de programación de juegos Unity en el centro de mejores prácticas de Unity o a través de estos enlaces:
Puede utilizar los patrones de diseño Modelo Vista Controlador (MVC) y Modelo Vista Presentador (MVP) para separar los datos y la lógica de su aplicación de la forma en que se presentan. Estos patrones aplican los principios de "separación de preocupaciones", que pueden mejorar la flexibilidad y la capacidad de mantenimiento de su código base.
En el desarrollo de juegos Unity, puedes utilizar estos patrones para separar la lógica de un juego en componentes distintos, como los datos (Modelo), la representación visual (Vista) y la lógica que controla la interacción entre ambos (Controlador o Presentador).
MVC es una familia de patrones de diseño comúnmente utilizados en el desarrollo de interfaces de usuario en aplicaciones de software.
La idea general detrás de MVC es separar la parte lógica de su software de los datos y la presentación. Esto ayuda a reducir las dependencias innecesarias y a reducir potencialmente el código espagueti.
Como su nombre indica, el patrón MVC divide su aplicación en tres capas:
El Modelo almacena datos: El Modelo es estrictamente un contenedor de datos que contiene valores. No realiza lógica de juego ni ejecuta cálculos.
La Vista es la interfaz: La vista formatea y muestra una presentación gráfica de los datos en pantalla.
El controlador se encarga de la lógica: Piensa en esto como en el cerebro. Procesa los datos del juego y calcula cómo cambian los valores en tiempo de ejecución.
Esta separación de intereses también define específicamente cómo interactúan estas tres partes entre sí. El Modelo gestiona los datos de la aplicación, mientras que la Vista muestra esos datos al usuario. El controlador gestiona las entradas y realiza cualquier decisión o cálculo sobre los datos del juego. A continuación, envía los resultados al Modelo.
El controlador no contiene datos de juego en sí mismo. Tampoco el View. El diseño MVC limita lo que hace cada capa. Una parte almacena los datos, otra los procesa y la última los muestra al usuario.
A primera vista, puede considerarse una extensión del principio de responsabilidad única. Cada parte hace una cosa y la hace bien, que es la ventaja clave de la arquitectura MVC.
Cuando se desarrolla un proyecto Unity con MVC, el framework UI existente (ya sea el UI Toolkit o Unity UI) naturalmente funciona como la Vista. Dado que el motor le proporciona una implementación completa de la interfaz de usuario, no tendrá que desarrollar componentes de interfaz de usuario individuales desde cero.
Sin embargo, seguir el patrón MVC tradicional requeriría código específico de la Vista para escuchar cualquier cambio en los datos del Modelo en tiempo de ejecución.
Si bien este es un enfoque válido, muchos desarrolladores de Unity optan por utilizar una variación de MVC donde el Controlador actúa como intermediario. Aquí, la Vista no observa directamente el Modelo. En su lugar, hace algo como en el diagrama anterior.
Esta variación de MVC se denomina diseño Modelo Vista Presentador, o MVP. MVP sigue conservando la separación de preocupaciones con tres capas de aplicación distintas. Sin embargo, cambia ligeramente las responsabilidades de cada parte.
En MVP, el Presentador (llamado Controlador en MVC) actúa como intermediario para las otras capas. Recupera los datos del Modelo y los formatea para su visualización en la Vista. MVP cambia la capa que gestiona la entrada. En lugar del Controlador, la Vista es responsable de manejar la entrada del usuario.
Fíjese en cómo los eventos y el patrón del observador figuran en este diseño. El usuario puede interactuar con los componentes Button, Toggle y Slider de Unity UI. La capa de visualización envía esta información al presentador a través de eventos de interfaz de usuario, y el presentador, a su vez, manipula el modelo. Un evento de cambio de estado del Modelo indica al Presentador que los datos han sido actualizados. El presentador pasa los datos modificados a la vista, que actualiza la interfaz de usuario.
En Github hay disponible un proyecto de muestra que demuestra diferentes patrones de diseño de programación, incluido un ejemplo de cómo implementar una variación del MVP.
El ejemplo de MVP consiste en un sistema sencillo que muestra la salud de un personaje o un objeto. Este ejemplo tiene todo en una sola clase que mezcla los datos y la interfaz de usuario, pero eso no se adaptaría bien a las producciones del mundo real. Añadir más funcionalidades sería más complicado a medida que necesitara ampliarlo. Además, las pruebas y la refactorización supondrían una gran sobrecarga.
En su lugar, puede reescribir sus componentes de salud de una forma más centrada en el MVP, empezando por dividir sus scripts en Health y HealthPresenter.
En el proyecto de ejemplo, puede hacer clic para dañar el objeto objetivo representado por un disco de disparo(ClickDamage.cs), o restablecer la salud con el botón. Estos eventos informan al HealthPresenter (que invoca Damage o Reset) en lugar de cambiar la Salud directamente. El Texto y el Deslizador de la Interfaz de Usuario se actualizan cuando el Health lanza un evento y notifica al HealthPresenter que sus valores han cambiado.
Profundicemos en lo que podría ser un componente de Salud. En esta versión, Salud sirve de Modelo. Almacena el valor real de salud e invoca un evento, HealthChanged, cada vez que ese valor cambia. Health no contiene lógica de juego, sólo métodos para incrementar y decrementar los datos.
Esto permite distinguir claramente entre los datos, la forma de presentarlos y la forma de controlarlos.
MVP (y MVC) realmente brillan para aplicaciones de software más grandes y con IU pesada, pero no se limita a esos casos de uso. Si el desarrollo de tu juego requiere un equipo considerable y esperas mantenerlo durante mucho tiempo después de su lanzamiento, podrías obtener las siguientes ventajas:
División fluida del trabajo: Al separar la vista del presentador, el desarrollo y la actualización de la interfaz de usuario pueden realizarse de forma casi independiente del resto del código base, lo que permite dividir el trabajo entre desarrolladores especializados. ¿Cuenta en su equipo con desarrolladores expertos en front-end? Que se ocupen de la Vista.
Pruebas unitarias simplificadas con MVP y MVC: Estos patrones de diseño separan la lógica del juego de la interfaz de usuario. De este modo, puede simular objetos para trabajar con su código sin necesidad de entrar en el modo Play del Editor. Esto puede ahorrar mucho tiempo.
Código legible que pueda mantenerse: Con este patrón de diseño se tiende a crear clases más pequeñas, lo que facilita su lectura. Menos dependencias suele significar menos puntos de rotura del software, menos lugares que puedan esconder errores y pruebas más sencillas.
Aunque MVC y MVP están muy extendidos en el desarrollo web o de software empresarial, a menudo, los beneficios no serán evidentes hasta que su aplicación alcance un tamaño y complejidad suficientes. Deberá tener en cuenta lo siguiente antes de implementar cualquiera de los patrones en su proyecto Unity:
Hay que planificar con antelación: MVC y MVP son patrones arquitectónicos más amplios. Para utilizar uno de ellos, tendrá que dividir sus clases por responsabilidad, lo que requiere cierta organización y más trabajo previo. Los patrones de diseño se utilizan mejor de forma coherente, por lo que conviene establecer una práctica para organizar la interfaz de usuario y asegurarse de que el equipo está al tanto.
No todo en su proyecto Unity se ajustará al patrón: En una implementación MVC o MVP "pura", todo lo que se renderiza en pantalla es realmente parte de la Vista. No todos los componentes de Unity se dividen fácilmente entre datos, lógica e interfaz (por ejemplo, un MeshRenderer). Además, los scripts sencillos pueden no obtener muchos beneficios de MVC/MVP.
Tendrás que juzgar dónde puedes beneficiarte más del patrón. Normalmente, puede dejarse guiar por las pruebas unitarias. Si MVC/MVP pueden facilitar las pruebas, considérelos para ese aspecto de la aplicación. De lo contrario, no intente forzar el patrón en su proyecto.
Encontrarás muchos más consejos sobre cómo utilizar patrones de diseño en tus aplicaciones Unity, así como los principios SOLID, en el libro electrónico gratuito Mejora tu código con patrones de programación de juegos.
Si desea instrucciones más detalladas sobre el uso de Unity UI y UI Toolkit, consulte la extensa guía, Diseño e implementación de interfaces de usuario en Unity escrita por profesionales de la interfaz de usuario.
Puede encontrar todos los libros electrónicos y artículos técnicos avanzados de Unity en el centro de mejores prácticas. Los libros electrónicos también están disponibles en la página de mejores prácticas avanzadas de la documentación.