La conception pilotée par domaine est-elle bonne pour les jeux?

Je viens de lire sur les modèles de domaine et cela m'a éclairé depuis que je développe un jeu qui a une classe qui ne contient que des données (peu de comportements / méthodes). J'ai confié la tâche de gérer ces cours aux managers ... et maintenant mon manager semble ressembler à un objet divin. Mon objet de jeu censé gérer la logique n'est qu'un modèle de domaine anémique.

Mon modèle de conception actuel est à Singleton et je veux faire un recodage pour sortir ce truc. Je n'ai jamais vu de DDD sur les jeux (pour l'instant) mais est-ce une bonne approche? Je suis juste un programmeur débutant (enclin au développement de jeux), donc je veux en savoir plus sur la bonne architecture avant que le jeu ne soit trop gonflé pour être repensé.

Je n'avais jamais entendu parler de conception pilotée par domaine avant votre publication. Un rapide coup d'œil à quelques références - ici et ici - semble suggérer que ce n'est qu'un nom de fantaisie pour la méthode traditionnelle des années 90 de programmation orientée objet que j'ai appris à l'université, où vous essayez d'écrire des cours pour chaque nom qui apparaît dans la situation que vous essayez de modéliser avec un logiciel, de sorte que la structure du logiciel semble suivre la structure du concept du monde réel.

En tant que tel, ma réponse à cela est que ce n'est pas "bon". C'est généralement un point de départ raisonnable mais s'avère insuffisant au fur et à mesure. Vous avez rarement un seul domaine mais plusieurs domaines différents au sein d'un même logiciel - par exemple, vous pouvez avoir le domaine du jeu (le monde, les personnages, les éléments), le domaine du moteur de rendu (les shaders, les maillages, les matériaux), le domaine d'entrée (le système de fichiers, le réseau, le clavier et la souris) et les problèmes surviennent là où les domaines se chevauchent et s'influencent mutuellement. Souvent, au cours de la jonction de 2 domaines, vous vous rendez compte qu'il existe en fait une dépendance qui nécessite un changement, ce qui signifie qu'une de vos représentations devient plus un fardeau qu'une aide.

Un vague exemple pourrait être une bibliothèque de mathématiques sur une console et vos personnages dans le jeu. Votre bibliothèque de mathématiques aimera avoir une grande liste de données, puis 1 instruction à exécuter sur cette liste, pour fonctionner efficacement. Vos personnages dans le jeu auront chacun leur propre ensemble de données de vertex pour le rendu et l'animation, etc. Maintenant, comment obtenir une longue liste de toutes les données de vertex de chacun de vos personnages pour pouvoir les gérer en une seule fois? Vous pouvez effectuer une opération de copie lente, ou à la place, vous pouvez refactoriser vos personnages afin que leurs données soient plus susceptibles d'être traitées par la bibliothèque de mathématiques - mais alors l'un de vos domaines se décompose pour en favoriser un autre.

Personnellement, je me méfie de tout label qui ressemble à "Wthing-Driven-Design". Le logiciel est à la fois trop large et trop complexe pour qu'il y ait une approche unique pour le créer. Au lieu de cela, lorsque j'essaie d'écrire le meilleur logiciel possible, j'essaie de me rabattre sur les principes SOLID . Ceux-ci vous donnent une bonne idée de la qualité de votre code, sans promettre une panacée d'une méthode que vous pouvez suivre et arriver par magie à un bon code. Malheureusement, sans une telle méthodologie, il faut beaucoup d'expérience avant d'apprendre à se conformer à ces directives, ce qui explique probablement pourquoi tant de gens aiment les méthodologies.

En ce qui concerne votre problème d'avoir des classes anémiques et des objets de gestionnaire, c'est généralement quelque chose qui est couvert dans les leçons d'introduction aux objets et qui ne vous oblige pas vraiment à adhérer à une méthodologie spéciale pour le `` réparer ''. (Vous voudrez peut-être prendre un livre sur la programmation orientée objet si vous débutez.) Une classe est un couplage d'état et de comportement, où le comportement modifie cet état, et cela s'appelle l'encapsulation. Généralement, vous essayez d'encapsuler autant que possible, ce qui signifie que l'état doit être manipulé par l'objet lui-même (et uniquement par cet objet). Ce n'est que pour un comportement qui ne peut pas être modélisé au sein de la classe que vous déléguez à une classe externe, comme un gestionnaire, c'est pourquoi l'existence de classes de gestionnaire est souvent considérée comme un signe de code orienté objet mal écrit.

Mon modèle de conception actuel est à Singleton et je veux faire un recodage pour sortir ce truc.

Je ne sais pas ce que vous entendez par cette ligne. Un modèle de conception est une façon bien connue d'écrire une petite partie de votre programme. Vous n'auriez pas de modèle de conception «actuel», ni ne façonnerait le reste de votre programme. Pour les débutants, ces modèles sont utiles pour vous mettre sur la bonne voie, tandis que pour les experts, ils sont plutôt un moyen de communiquer sur les situations de code courantes. Une chose est importante cependant: les singletons sont presque toujours une mauvaise idée, et vous devriez les éviter autant que possible. Vous pouvez trouver de nombreuses opinions sur les singletons sur ce site et plus sur Stack Overflow, mais voici une question pratique avec des réponses qui vous aident à éviter d'en avoir besoin.

Paradigme

Au moment où cette réponse a été écrite, les autres réponses affichées ici sont toutes fausses.

Au lieu de demander si la conception pilotée par domaine est bonne pour les jeux. Vous devez vous demander si la "modélisation de domaine" est bonne pour les jeux.

La modélisation de domaine est-elle bonne pour les jeux?

La réponse est: parfois, c'est absolument fabuleux. Cependant, si vous créez un jeu en temps réel tel qu'un jeu de plateforme ou FPS ou autre (BEAUCOUP DE NOMBREUX types de jeux), alors non. Ce n'est pas nécessairement bien adapté à ces systèmes. Cependant, il peut y avoir des systèmes dans ces jeux dans lesquels la mise en œuvre du modèle de modèle de domaine est efficace.

Comme d'autres l'ont mentionné ici, les cadres de composants-entités ont tendance à être très populaires, et pour cause. Cependant, dans la culture de développement de jeux, il semble y avoir un manque net d'architectures en couches. Encore une fois, c'est pour une bonne raison car la plupart des jeux que les gens vont développer ne font que muter l'état sur les entités et laisser les conséquences émergentes être le jeu.

TOUS LES LOGICIELS NE SONT PAS LES LOGICIELS QUE VOUS ÉCRIVEZ. Certains sont assez différents des autres.

Des exemples de domaines dans lesquels la modélisation de domaine fonctionne bien sont les jeux de cartes, les jeux de société et d'autres types de systèmes pilotés par les événements.

Les jeux qui fonctionnent à une fréquence d'images X avec des mouvements, etc. déterminés par des deltas temporels en tant que concepts de domaine de base ne sont probablement pas un bon choix. Dans ce cas, notre "domaine" est souvent si simple qu'il n'y a pas besoin de modélisation de domaine. La détection des collisions, l'apparition de nouvelles entités, l'influence des forces sur les entités existantes, etc. ont tendance à couvrir la plupart des gameplay.

Cependant, à mesure que les choses deviennent complexes, vous commencez à voir des développeurs implémenter des modèles de domaine au sein de leurs entités pour gérer certains types de comportement et de calcul.

Modèle de modèle de domaine dans les architectures de jeu

Votre moteur de jeu (par exemple, Unity3D) est souvent orienté entité-composant. Dans un jeu de plateforme, vous pouvez avoir une entité pour votre personnage et son état est constamment modifié pour mettre à jour la position, etc.

Cependant, dans un jeu plus axé sur les événements, il est plus probable que le rôle de l'infrastructure de composant-entité soit simplement d'exister en tant qu'interface utilisateur. Vous vous retrouvez avec une architecture en couches.

L'interface utilisateur rend l'état du jeu à l'utilisateur. L'utilisateur interagit avec l'interface utilisateur, déclenchant des commandes dans la couche de service. La couche de service interagit avec les objets de domaine. Les objets de domaine ont déclenché des événements de domaine. Les écouteurs d'événements entendent les événements et déclenchent des modifications dans l'interface utilisateur.

UI> Service Layer> Modèle de domaine

En bref, finissez avec model-view-controller avec une implémentation de la couche service.

En utilisant cette architecture, vous disposez d'un noyau de jeu entièrement testable par unité (une rareté dans la culture de développement de jeux, et cela se voit) avec une interface événementielle.

Ok maintenant, qu'est-ce que DDD?

La conception pilotée par le domaine est spécifiquement une culture / un mouvement mettant l'accent sur les modèles analytiques qui sont utilisés pour en savoir plus sur le domaine, afin que vous construisiez réellement la bonne chose, puis des modèles d'implémentation qui vous permettent d'implémenter une couche de modèle qui représente le concepts dans le modèle de domaine en utilisant l'idiome de votre langue. DDD est issu d'une communauté qui travaille avec des domaines complexes et est toujours à la recherche de moyens de gérer une complexité élevée dans leurs applications en se concentrant sur la modélisation de domaine.

DDD ne fonctionne pas si bien si votre objectif est de simplement commencer à coder, de jouer avec le système, puis de comprendre ce que vous voulez construire plus tard, etc. Il suppose qu'il existe plus ou moins un domaine. Donc, si vous n'avez aucune idée de ce que sera votre jeu .. Alors, ça ne marchera pas.

Non, je ne pense pas que DDD, ou toute autre architecture "buzzword" soit vraiment bon pour les jeux. A l'exception peut-être du "système de composants", qui semble vraiment populaire ici.

Lorsque j'entends des questions et des discussions comme celle-ci, je me souviens de ce site. Réfléchir à divers mots à la mode d'architecture vous fera généralement moins de bien que de concevoir et de coder votre propre application.

Oui, mais vous devriez vous adapter.

En utilisant DDD, vous obtiendrez la modularité et la responsabilité unique de chaque domaine. Mais tout le reste ne fait que compliquer les choses.

Voir ma réponse ici