Clean Unity - Le problème du pattern Controller-Manager

En tant que développeur Unity 3D, vous reconnaissez-vous dans l'une des situations suivantes ?

- Vous travaillez sur votre tout nouveau projet Unity et vous ne savez pas par où commencer ?
- Vos classes Controller deviennent-elles massives et difficiles à comprendre ou à faire évoluer ?
- Vous avez l'impression que ce que vous prévoyez de faire se traduira par un code spaghetti dès que vous voudrez faire quelques modifications ?
- Vous passez un temps considérable à faire du bugfix ?
- L'ajout d'une nouvelle fonctionnalité implique souvent une régression ou une refonte massive ?
- Votre application est constituée d'un ensemble de modules étroitement couplés ?
- Vous ne savez pas pourquoi votre classe Player est maintenant étroitement liée à la classe Enemy ?
- Vous avez l'impression que le compromis effort/bénéfice avec l'application du TDD sur Unity n'en vaut pas la peine ?

Vous pourriez adopter une approche de développement logiciel plus robuste dès maintenant. Vous n'êtes pas obligé de vous en tenir à MVC et aux classes massives MonoBehaviour. Il existe de meilleurs moyens de développer des features Unity 3D.

Le problème de l'architecture Controller-Manager

Vous savez que MVC n'est pas suffisant pour les grands projets Unity. Au fur et à mesure que votre application grandit, vous vous retrouvez avec de grandes classes et votre vue est liée à vos modèles de données. Vous n'avez aucune possibilité de réutilisation, vous ne savez même pas comment la tester tant il y a de couplage.

Vous avez donc essayé de consulter des projets Unity pertinents, des exemples de code, etc., mais le processus est trop lent et vous ne recueillez que quelques petites astuces et non des lignes directrices générales sur l'architecture des applications Unity.

Imaginez que vous puissiez savoir rapidement et exactement où en sont les choses, corriger facilement les bugs et ajouter de nouvelles fonctionnalités sans casser le code existant. Imaginez que vous puissiez ajouter une nouvelle fonctionnalité et indiquer très précisément le temps nécessaire à sa mise en œuvre.

Imaginez que vous puissiez convaincre vos clients d'opter pour le développement piloté par les tests et leur montrer que c'est un investissement est rentable sur le long terme.

Une bonne architecture facilite les tests.

Consultez le post Clean Unity Architecture pour obtenir des détails une manière d'appliquer la Clean Architecture dans vos projets Unity 3D.
Ce post démontre les concepts en utilisant l'exemple d'un système d'objectifs génériques qui permet au joueur de valider les objectifs généraux du jeu et les objectifs de niveau, et de suivre l'état d'avancement de ces objectifs.
Il vous explique également comment utiliser les templates C# fournis pour générer les composants nécessaires à l'application de l'architecture Clean Unity.

Ceci est une brève description du produit complet qui détaille comment implémenter un système d'objectifs génériques qui sera réutilisable dans tous vos jeux, et facile à étendre !

J’accède à la formation vidéo !

Vous apprendrez comment :

• Appliquer Clean Unity et le cycle VIP pour concevoir des modules réutilisables dans Unity
• Separate concerns in view controller, interactor, worker and presenter modules
• Write fast and maintainable tests with confidence to make changes
• Write unit tests to ensure your application will be open to changes
• Deep dive into each Clean Unity component
• How does Clean Unity perform in a large project
• Extraire la logique complexe des Interactors dans des classes Worker lorsque c'est nécessaire