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


10

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é.


2
Je peux dire qu'une conception populaire pour les jeux est une architecture de composants. Une nouvelle conception qui fait jouer à la pointe des moteurs de jeux est la conception orientée données (signifie simplement que la façon dont les données sont placées en mémoire est vraiment la plus grande préoccupation de conception). Mais je ne peux pas parler de Domain Driven Design dans les jeux vidéo .. donc donc, juste un commentaire.
James

Les jeux ne sont pas des applications commerciales. L'architecture sonore dans une application métier (DDD / CQRS) n'est certainement pas saine dans un jeu, et vice-versa. Pourquoi ne pas rechercher le modèle de décorateur ou le modèle de composant? Celles-ci sont "bonnes" pour les jeux et atténueraient votre problème de singleton - même en disant que les singletons sont généralement bien dans les jeux; surtout si vous faites du développement indépendant. Concentrez-vous sur la finition de quelque chose, sinon vous atterrirez comme moi avec une grande architecture, mais pas de jeu.
Jonathan Dickinson

Merci pour la suggestion. Je vais lire sur la conception des composants. Je vais finir le jeu sur lequel je travaille même si son design n'est pas si bon. J'ai une date limite ce novembre lol. J'ai supprimé le concept de Singleton et j'injecte des modules aux objets qui en ont besoin. Je suppose que ce sera suffisant pour le moment mais je dois en savoir plus.
Sylpheed

Réponses:


12

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.


D'accord, permettez-moi de changer un peu la question. Y a-t-il une différence entre les modèles de domaine et la conception pilotée par domaine? Mon idée sur les modèles de domaine est qu'une classe devrait être capable de se gérer sans s'appuyer autant que possible sur un contrôleur / gestionnaire. Ma conception actuelle va à l'encontre de cet objectif. Je peux mal comprendre quelque chose. Donc, dans un jeu RPG, ma classe de joueur a son propre domaine et est composée de différents domaines comme les compétences, les objets, etc.
Sylpheed

Oui, une classe devrait être capable de se gérer sans s'appuyer autant que possible sur un contrôleur / gestionnaire, mais cela n'a rien à voir avec les modèles de domaine et n'est qu'une approche standard de la programmation orientée objet. Ce n'est pas clair ce que vous pourriez mal comprendre parce que je ne sais pas pourquoi vous avez ces classes de manager.
Kylotan

Je ne vois pas comment faire fonctionner mon module sans un gestionnaire ou une classe qui interroge mon objet. Par exemple, j'ai un module pour les quêtes. Pour que j'accède à la bonne quête, je dois interroger le manager. Alors, comment puis-je passer par là sans gestionnaire?
Sylpheed

Quelle est la «bonne» quête? Comment le gestionnaire sait-il ce qui est bien? Je suppose que la logique qui prend de telles décisions s'appuie sur d'autres objets pour les prendre, et ces autres objets sont de meilleurs candidats pour cette fonctionnalité.
Kylotan

Eh bien, en ce moment, mon gestionnaire agit comme un référentiel après un nettoyage. Par exemple, j'ai 10 quêtes en direct. J'accède à ces quêtes via ID pour une récupération plus facile. Mon joueur a donc un composant pour les quêtes (le manager) et j'y accéderai à partir de là. C'est toujours le joueur qui contrôle quelle quête il peut avoir. Est-ce une mauvaise idée?
Sylpheed

6

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.


1
Merci pour la perspicacité. Je l'avais compris il y a peut-être 3 ou 4 ans. J'étais naïf à l'époque (il y a 5 ans) car j'essaie toujours d'adapter le «modèle de conception» à tous mes problèmes. L'apprentissage de ces «modèles» et de l'architecture m'a aidé car cela m'a donné plus d'options. Je m'en tiens toujours à l'abstrait de parties de mon code "juste assez" pour que ce soit facile pour les concepteurs (très important), les tests unitaires et la future mécanique. Trop sur l'architecture, il était difficile de travailler avec et j'ai appris cela à la dure. À l'heure actuelle, j'ai déjà exploité l'architecture basée sur les composants pour s'adapter à mon style de codage. Ftw SOLIDE.
Sylpheed

3

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.


1
+1 pour "réellement concevoir et coder votre propre application". ces modèles sont des lignes directrices et des provocateurs pour moi - rien de plus. Changer un problème pour qu'il s'intègre dans une solution n'est pas la bonne chose à faire.
Jonathan Dickinson

-1

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


Vous voudrez peut-être développer un peu votre réponse (couvrir la partie principale de la réponse), car en ce moment, il s'agit d'une réponse de lien uniquement (même si elle pointe vers un autre site d'échange de pile).
Vaillancourt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.