Discussion :

[PilloBuenaGente]

Bonjour

Etant débutant et n'ayant jamais créé de jeu, je n'ai aucun recul.
Mais il me semble que Klaim, dans ce post, indiquait ne pas se servir de l'héritage pour définir les comportements.

Je ne m'y suis que très peu intéressé, mais le "Component-based game entity system" semble être une bonne base pour garantir une certaine flexibilité.

[Bousk]

Effectivement, les grosses architectures, héritage sexy partout, traits etc ne sont pas légion. (pour ne pas dire quasi inexistante)
Le code du jeu doit être data-driven, afin que les GD/LD/Graph puissent modifier le rendu/comportement avec un minimum d'action du programmeur.

Dans les faits, tu auras 1 classe Arme, avec une multitude d'attributs, définis de concert avec le GD typiquement. GD qui crée des fichiers de données (Xml) : EpeeFeu, Lance, ... pour créer le contenu du jeu.

[Kaamui]

Que toutes les constantes soit définies dans un fichier qui ne nécessitent pas d'action du programmeur est tout à fait intéressante effectivement, mais je ne vois pas en quoi c'est incompatible avec une archi à "héritage sexy"

Une archi en béton avec héritage basé sur le comportement ou les services, et le contenu du jeu chargé ou lu à partir de fichiers plats ou de base de données (pour les MMO par exemple) est ce que personnellement je trouve le plus propre.

[MrPchoun]

Hello,

Si je ne m'abuse, la solution proposée par Kaamui ressemble à peu près à ce que j'avais fait. En tous cas, chaque arme serait en fait une seule classe/structure, dont on ne ferait qu'une seule instance. Si une telle manière de coder peut être envisagée, c'est au top Mais du coup, faire une classe d'effets ne serait plus très pertinent vu que chaque arme aura son comportement propre. Déjà qu'on ferait une classe d'arme par arme, pourquoi faire une classe d'effet en plus par arme ? Je pose juste des questions, ne le prends surtout pas mal Kaamui

Les visitor pattern, je suis dessus depuis hier soir, et j'ai sans doute compris les grandes lignes du machinchose, mais dès qu'il s'agit de l'implémenter je suis perdu, et comme le disait Kaamui, le code devient beaucoup moins visible

Je rebondis sur ce que vient de dire foetus : effectivement, chaque arme ou personnage est constitué d'un ensemble de caractéristiques. Et moi j'envisageais les choses de la manière suivante : on a une structure (qui ne serait jamais utilisée comme ça, elle devra être dérivée) ActiveItem, qui contient une liste de caractéristiques, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
struct ActiveItem
   int force  
   int dextérité
   ...
   int vitesse

Un personnage, par exemple, peut dériver de cette structure, et puis il a quelques méthodes, du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
struct Player : ActiveItem
   seDéplacer(Point point)
   attaquer(Player &ennemy)

Et puis finalement, si on envisage les effets d'une arme comme un ensemble de caractéristiques qu'on modifie chez l'ennemi, on peut aussi très bien écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
struct Weapon : ActiveItem
   ...

Du coup, dans le cas d'une arme qui ralenti l'adversaire, il suffit de créer une instance de Weapon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Weapon batonDuTonnerre;
batonDuTonerre.vitesse = -2;

Voilà... Moi j'envisageais les choses comme ça, je ne sais pas ce que vous en pensez ?

Cordialement,

[Kaamui]

Rien ne peut me faire plus plaisir que d'essayer d'aider et de répondre à des questions de personnes passant exactement par où je suis passé ^^

Pour les effets, effectivement pas sur que les deux ne soient pas redondants, là le choix devient surtout une question de contexte (celui de ton jeu). Si tu es sur quelque chose de très travaillé comme le sont les exemples de Loïc Joly, il vaut peut-être mieux choisir son idée. Les questions de conception, c'est aussi une question de ... conception (vision des choses).

Une classe par arme, une classe par effet, mais pas une classe effet par arme

Le but, aussi, c'est de faire le découpage le plus atomique possible, pour ne pas avoir plus de responsabilité pour une classe donnée qu'elle ne devrait. Si tu regarde dans le post cité de Klaim, il y a juste au dessus une intervention très pertinente de Koala01 qui montre l'importance de ne pas faire son radin avec les interfaces

[JolyLoic]

J'adore la solution de Trademark (vu que j'aurais surement fait la même chose), mais ton idée me semble tout aussi intéressante, même si j'ai un peu de mal à visualiser. Est-ce qu'il n'y a pas moyen de coupler la vision de Trademark qui est plus "conceptuelle (assembliste ? je ne sais pas trop comment appeler ça)" avec ta vision plus "comportementale" ?

Je pense que les deux ne se situent en effet pas au même niveau. Par exemple, on pourrait imaginer que la stratégie qui prend en compte les caractéristiques de l'adversaire soit implémentée à l'aide d'un visiteur.

Là où je dit que j'ai un doute, c'est que pour que ça serve à quelque-chose, il faut déjà que les adversaires soient organisés en hiérarchie d'héritage, ce qui est peu probable (il risque de n'y avoir qu'une seule classe, avec des valeurs numériques ou des stratégies dépendant du personnage). L'autre critère pour que le visiteur soit intéressant c'est que la hiérarchie à visité soit stable (et que les opérations à effectuer soient instables). Or là, même si on partait sur une hiérarchie d'adversaire, elle aurait toute les chances d'évoluer sans cesse. C'est ce qui fait que la lourdeur du visiteur est rarement justifiée à mon sens. Un des rares cas est quand on écrit un compilateur, et je pense qu'à cause du prestige de ce cas, ce design pattern est survendu...

[foetus]

Je suis en train de regarder la conception "Entity Component System" (ECS) et c'est ....

Parce que chacun fait sa tambouille.

Dans l'état de l'art il y a 5 types: Engine, Entity, Component, System, Node.

*) Un objet de type Entity c'est juste un ID et une liste d'objets de type Component

*) Un objet de type Component c'est juste une structure avec des attributs.
Par exemple: PositionComponent c'est un X, Y, Z. HealthComponent c'est un entier health. PhysicalComponent c'est la vitesse et la vélocité et ainsi de suite.

Si je ne me trompe pas, on peut voir chaque Component comme une table de base de donnée ou un tableau associatif et on va accéder aux données grâce à l'ID de l'objet


*) Un objet de type System c'est une liste d'objets de type Node et une méthode virtuelle update qui est la logique du système.


*) Un objet de type Node c'est une liste d'objets de type Component
L'idée: Une partie d'un objet (type Component) peut-être partagée entre différents systèmes.
Par exemple le RenderSystem et le MotionSystem vont avoir besoin de la partie PositionComponent d'un objet.

*) Un objet de type Engine c'est une liste d'objets de type Entity et une liste d'objets de type System.


L'idée de l'initialisation du jeu: on va créer un objet de type Entity, lui ajouter des Component et ensuite ajouter cet objet dans le moteur. Et c'est le moteur qui se charge d'ajouter au moins les Component de l'objet dans les systèmes qui vont bien.


Pour faire la boucle de jeu, le moteur va appeler la méthode update de chaque système.
Évidemment les systèmes semblent être priorisés ou ordonnés au niveau du moteur
On voit bien la séparation données et logique et même, on peut "séparer" les données/ logiques pour la programmation multithreadée.


Là ou je n'arrive pas encore à voir le truc c'est l’interaction entre les systèmes: c'est la "foire à tout"
Un exemple: le EventSystem transforme la touche tapée en message, message qui doit être transmis au MotionSystem avant le ColliderSystem.

• Il y a un système de messages qui est mis en place. Mais je trouve lourd que le EventSystem envoie un message au moteur qui le redistribue à tous les systèmes (que celui ou ceux intéressés le traite)
• À moins que le EventSystem contient la liste des systèmes qui l'intéresse
• Le Component contient la liste des Node qui l'utilisent et peut prévenir les systèmes en remontant comme un saumon. Ceci implique de la logique dans les objets Component
• Le Component contient un lien avec son objet l'appartenant et ce dernier peut prévenir les systèmes qui l'utilisent (comment??? via le moteur c'est lourd). Ceci implique de la logique dans les objets Entity
• De tout manière, il semble qu'un état soit ajouté dans certains objets Entity. Pourtant on devrait créer un type StatutComponent
• Je ne sais même pas si les objets de type Node existent.
• Pour un jeu 2D on avait un tableau (qui représente le terrain ou le plateau) pour faire des tests de collisions avec l’environnement. Donc là il faudra rajouter des murs, des pierres des lacs... Dans un sens c'est logique si on veut les afficher on n'a pas trop le choix. Le nombre d'objet devra être suivi de près.

[Trademark]

C'est ce qui fait que la lourdeur du visiteur est rarement justifiée à mon sens. Un des rares cas est quand on écrit un compilateur, et je pense qu'à cause du prestige de ce cas, ce design pattern est survendu...

Ça pose même des problèmes dans les compilateurs vu qu'un langage ne cesse d'évoluer... Il suffit de regarder le C++. Mais en orienté-objet ça reste le seul moyen d'ajouter des traitements à une hiérarchie de classes sans modifier lesdites classes.

[Kaamui]

Tu veux dire que le pattern visitor est le seul moyen de respecter l'OCP dans une hiérarchie de classes ? (si oui, je ne suis pas d'accord mais pas sûr que c'est ce que tu voulais dire)

[JolyLoic]

Ça pose même des problèmes dans les compilateurs vu qu'un langage ne cesse d'évoluer... Il suffit de regarder le C++. Mais en orienté-objet ça reste le seul moyen d'ajouter des traitements à une hiérarchie de classes sans modifier lesdites classes.

Oui, elle évolue, mais généralement moins vite que les traitements que l'on fait dessus.

[Trademark]

Tu veux dire que le pattern visitor est le seul moyen de respecter l'OCP dans une hiérarchie de classes ? (si oui, je ne suis pas d'accord mais pas sûr que c'est ce que tu voulais dire)

Dans une collection hétérogène de classe comment peux-tu respecter OCP sinon ? Évidemment sans parler des solutions impliquant le RTTI.

[Kaamui]

Avec un découpage atomique des responsabilités de chaque classe, ta collection hétérogène est ouverte à l'extension naturellement. J'allais presque dire que pour respecter OCP il faut respecter OCP

Plus sérieusement, pour moi c'est justement ce qu'offre SOLID, et particulièrement OCP, cette flexibilité/réutilisabilité/atomicité des classes qui fait qu'on a pas besoin de passer par des patterns comme visitor. Loïc Joly et toi y voyez un intérêt, et même si je sais très bien que si vous deux y voyez un intérêt, c'est que ça doit pas être dénué de sens, pour moi ce pattern est un modèle qui va à l'encontre de SOLID, voire de l'OO de manière générale. Il est donc pour moi même indispensable de ne pas utiliser visitor pour respecter OCP, puisque visitor t'ouvre à la modification.


EDIT : pourquoi écartes-tu la résolution des types à l’exécution au fait ?

[foetus]

Je reviens sur l'architecture "Entity Component System" (ECS)

Intel a fait un papier dessus avec du multhreading
ECS un peu modifié parce qu'Intel parle, par exemple, d'extensions mais ce sont les types Component, et il fait une séparation entre Object et Scene.

Ce n'est pas très précis pour certains trucs (surtout je pense que c'est au codage que tu vas trouver tous les problèmes ) ... mais c'est