Vous pouvez utiliser les modèles de conception Model View Controller (MVC) et Model View Presenter (MVP) pour séparer les données et la logique de votre application de la manière dont elles sont présentées. Ces modèles appliquent les principes de la "séparation des préoccupations", ce qui peut améliorer la flexibilité et la maintenabilité de votre base de code.

Dans le développement de jeux Unity, vous pouvez utiliser ces modèles pour séparer la logique d'un jeu en composants distincts, comme les données (modèle), la représentation visuelle (vue) et la logique qui contrôle l'interaction entre les deux (contrôleur ou présentateur).

MVC est une famille de modèles de conception couramment utilisés lors du développement d'interfaces utilisateur dans les applications logicielles.

L'idée générale de MVC est de séparer la partie logique de votre logiciel des données et de la présentation. Cela permet de réduire les dépendances inutiles et, éventuellement, le code spaghetti.

Comme son nom l'indique, le modèle MVC divise votre application en trois couches :

Le modèle stocke les données : Le modèle est strictement un conteneur de données qui contient des valeurs. Il n'effectue pas de logique de jeu ni de calculs.

La vue est l'interface : La vue met en forme et rend une présentation graphique de vos données à l'écran.

Le contrôleur s'occupe de la logique : Il s'agit en quelque sorte du cerveau. Il traite les données du jeu et calcule comment les valeurs changent au cours de l'exécution.

Cette séparation des préoccupations définit également de manière spécifique la manière dont ces trois parties interagissent les unes avec les autres. Le modèle gère les données de l'application, tandis que la vue affiche ces données à l'utilisateur. Le contrôleur gère les entrées et prend les décisions ou effectue les calculs sur les données du jeu. Il renvoie ensuite les résultats au modèle.

Le contrôleur ne contient pas de données de jeu en lui-même. Le View non plus. La conception MVC limite ce que fait chaque couche. Une partie contient les données, une autre traite les données et la dernière affiche ces données à l'utilisateur.

À première vue, on peut considérer qu'il s'agit d'une extension du principe de responsabilité unique. Chaque partie fait une chose et la fait bien, ce qui est le principal avantage de l'architecture MVC.

Lors du développement d'un projet Unity avec MVC, le cadre d'interface utilisateur existant (UI Toolkit ou Unity UI) fonctionne naturellement comme la vue. Comme le moteur vous offre une implémentation complète de l'interface utilisateur, vous n'aurez pas besoin de développer des composants d'interface utilisateur individuels à partir de zéro.

Cependant, si l'on suit le modèle MVC traditionnel, il faudrait que le code spécifique à la vue soit à l'écoute de toute modification des données du modèle au moment de l'exécution.

Bien qu'il s'agisse d'une approche valable, de nombreux développeurs Unity optent pour une variante de MVC dans laquelle le contrôleur joue le rôle d'intermédiaire. Ici, la vue n'observe pas directement le modèle. Au lieu de cela, il fait quelque chose comme dans le diagramme ci-dessus.

Cette variante de MVC est appelée conception Modèle-Vue-Présentateur (Model View Presenter) ou MVP. Le MVP préserve toujours la séparation des préoccupations avec trois couches d'application distinctes. Cependant, elle modifie légèrement les responsabilités de chaque partie.

Dans le MVP, le présentateur (appelé contrôleur dans le MVC) sert d'intermédiaire entre les autres couches. Il récupère les données du modèle et les met en forme pour les afficher dans la vue. Le MVP détermine la couche qui traite l'entrée. Plutôt que le contrôleur, c'est la vue qui est chargée de gérer les entrées de l'utilisateur.

Remarquez comment les événements et le modèle de l'observateur s'intègrent dans cette conception. L'utilisateur peut interagir avec les composants Bouton, Bascule et Curseur d'Unity UI. La couche de visualisation renvoie ces données au présentateur par l'intermédiaire des événements de l'interface utilisateur, et le présentateur, à son tour, manipule le modèle. Un événement de changement d'état du modèle indique au présentateur que les données ont été mises à jour. Le présentateur transmet les données modifiées à la vue, qui actualise l'interface utilisateur.

Un exemple de projet est disponible sur Github. Il présente différents modèles de programmation, y compris un exemple de mise en œuvre d'une variante du MVP.

L'exemple MVP consiste en un système simple qui indique l'état de santé d'un personnage ou d'un objet. Cet exemple contient tout dans une classe qui mélange les données et l'interface utilisateur, mais cela ne serait pas adapté à des productions réelles. L'ajout de fonctionnalités supplémentaires deviendrait plus compliqué au fur et à mesure de leur extension. En outre, les tests et le remaniement entraîneraient de nombreux frais généraux.

Au lieu de cela, vous pouvez réécrire vos composants de santé d'une manière plus centrée sur le MVP, en commençant par diviser vos scripts en un Health (santé) et un HealthPresenter (présentateur de santé).

Dans le projet d'exemple, vous pouvez cliquer pour endommager l'objet cible représenté par un disque de tir(ClickDamage.cs), ou réinitialiser la santé à l'aide du bouton. Ces événements informent le HealthPresenter (qui invoque Damage ou Reset) plutôt que de modifier directement l'état de santé. Le texte et le curseur de l'interface utilisateur sont mis à jour lorsque l'état de santé déclenche un événement et informe le HealthPresenter que ses valeurs ont changé.

Voyons plus en détail à quoi pourrait ressembler une composante " santé ". Dans cette version, la santé sert de modèle. Il stocke la valeur réelle de la santé et invoque un événement, HealthChanged, chaque fois que cette valeur change. Health ne contient pas de logique de jeu, seulement des méthodes pour incrémenter et décrémenter les données.

Cela permet d'établir une distinction claire entre les données, la façon dont elles sont présentées et la façon dont elles sont contrôlées.

Le MVP (et le MVC) sont particulièrement adaptés aux applications logicielles de grande taille et à forte interface utilisateur, mais ils ne se limitent pas à ces cas d'utilisation. Si le développement de votre jeu nécessite une équipe importante et que vous prévoyez de le maintenir pendant une longue période après son lancement, vous pourriez bénéficier des avantages suivants :

Répartition harmonieuse des tâches : Comme vous avez séparé la vue du présentateur, le développement et la mise à jour de votre interface utilisateur peuvent se faire presque indépendamment du reste de la base de code, ce qui vous permet de répartir votre travail entre des développeurs spécialisés. Votre équipe compte-t-elle des développeurs frontaux experts ? Laissez-les s'occuper de la vue.

Tests unitaires simplifiés avec MVP et MVC : Ces modèles de conception séparent la logique du jeu de l'interface utilisateur. Ainsi, vous pouvez simuler des objets pour travailler avec votre code sans avoir besoin d'entrer en mode lecture dans l'éditeur. Cela permet de gagner un temps considérable.

Un code lisible qui peut être maintenu : Avec ce modèle de conception, vous aurez tendance à créer des classes plus petites, ce qui les rendra plus faciles à lire. Moins de dépendances signifie généralement moins d'endroits où votre logiciel peut se casser, moins d'endroits où peuvent se cacher des bogues, et des tests plus faciles.

Bien que MVC et MVP soient très répandus dans le développement de sites web ou de logiciels d'entreprise, leurs avantages ne sont souvent apparents que lorsque l'application atteint une taille et une complexité suffisantes. Vous devrez prendre en compte les éléments suivants avant d'implémenter l'un ou l'autre de ces modèles dans votre projet Unity :

Vous devez planifier à l'avance : MVC et MVP sont des modèles architecturaux plus vastes. Pour utiliser l'une d'entre elles, vous devrez répartir vos classes par responsabilité, ce qui demande un peu d'organisation et plus de travail en amont. Les modèles de conception sont mieux utilisés de manière cohérente, vous devez donc établir une pratique pour organiser votre interface utilisateur et vous assurer que votre équipe est d'accord.

Tous les éléments de votre projet Unity ne correspondront pas au modèle : Dans une implémentation MVC ou MVP "pure", tout ce qui est rendu à l'écran fait vraiment partie de la vue. Tous les composants Unity ne sont pas facilement divisibles entre les données, la logique et l'interface (par exemple, un MeshRenderer). De même, les scripts simples peuvent ne pas tirer beaucoup d'avantages de MVC/MVP.

Vous devez déterminer où vous pouvez tirer le meilleur parti du modèle. En général, vous pouvez vous laisser guider par les tests unitaires. Si MVC/MVP peuvent faciliter les tests, envisagez-les pour cet aspect de l'application. Sinon, n'essayez pas d'imposer le motif à votre projet.

Vous trouverez de nombreux autres conseils sur la façon d'utiliser les modèles de conception dans vos applications Unity, ainsi que les principes SOLID, dans l'e-book gratuit suivant Améliorez votre code avec des modèles de programmation de jeux.

Si vous souhaitez obtenir des instructions plus détaillées sur l'utilisation d'Unity UI et d'UI Toolkit, consultez le guide complet, Conception et mise en œuvre de l'interface utilisateur dans Unity rédigé par des professionnels de l'interface utilisateur.

Vous pouvez trouver tous les livres électroniques et articles techniques avancés sur Unity dans le centre des meilleures pratiques. Les livres électroniques sont également disponibles sur la page des meilleures pratiques avancées dans la documentation.