Logique des actions : comment les implémenter ?

[rachids]

Bonjour !

Je développe présentement un petit jeu coopératif et compétitif à la fois, et les personnages doivent être capable de passer plusieurs actions.
Je souhaite utiliser les meilleures façons de faire car j'aimerais apprendre à quitter le monde du séquentiel pour pleinement rentrer dans l'univers orienté objet.

J'utilise le framework Laravel.

J'ai donc pensé à développer les actions dans des traits, classés selon le type.

L'avantage étant que j'ai un dossier "Ordres" avec à l'intérieur, un trait pour chaque type d'ordres.
(exemple : RencontresTrait dispose de tous les ordres liés aux rencontres : discuter, voler, donner etc.)

L'ennui c'est que pour les loader dans mon contrôleur je dois tous les lister, de plus j'aimerais pouvoir les instancier (comme pour le trait de Rencontre, j'aimerais pouvoir l'instancier avec le personnage qui passe l'ordre et celui qui le reçoit), or c'est déconseillé et pénible à faire avec un trait.

Je suis persuadé qu'il existe une solution simple à mettre en place, mais je ne suis pas assez à l'aise pour la mettre sur papier.

Auriez vous des idées ?

[Xenos]

Salut,

je n'ai rien compris à la problématique

En revanche, les traits, je trouve que c'est franchement peu pratique à utiliser (souvent, autant avoir une classe dédié et faire de la composition).

"Passer plusieurs actions", cela veut dire quoi? Que tu as des actions, qu'elles s'enchainent et que tu veux permettre au joueur de "zapper" l'action suivante pour passer directement à celle d'après? Si oui, pour moi, il y a 1 classe par type d'action, 1 instance de classe par action, 1 classe "ChainableAction" qui permet de chainer des objets (chain of responsibility pattern), en l’occurrence, des actions (donc, ChainableAction prend en paramètre une action dans son constructeur et un ou plusieurs ChainableAction: l'action est l'action courante de ce ChainableAction, et les autres ChainableActions sont les actions qui suivront). Du coup, le zapping d'une action est du ressort de ChainableAction (ça sépare cette responsabilité des classes d'Action).

Mais bon, je ne suis pas sûr d'avoir compris le but du truc...

[rachids]

Salut Xenos !

Mes excuses, j'ai de la difficulté à être clair ^^

En réalité c'est plus simple que ça, j'ai juste tout plein d'actions disponibles pour le joueur, elles ne s'enchaînent pas.
C'est au joueur de passer l'action qu'il souhaite passer.

Ce que je souhaite comprendre, c'est comment implanter toute la logique qui soutient les mécanismes.

Par exemple, un personnage rencontre un autre personnage et il veut passer l'action "discuter". Au clic sur discuter, j'appelle une méthode d'un contrôleur et à partir de là j'appelle mon trait RencontreTrait et je passe la méthode discuter().

Sauf qu'en amont, j'aimerais vérifier d'abord que les deux personnages soient sur la même case, qu'aucun d'eux n'est caché, que celui qui passe l'action ait encore du temps etc.

Et c'est donc la logique de tout ça qui m'échappe, je ne trouve pas de solution simple et maintenable. :S

J'espère avoir pu démystifier mon premier message.

[Xenos]

"passer" l'action... le joueur veut que le jeu "exécute" une action donnée?

A mon avis, si les checks peuvent être "croisés" entre différentes actions (ie, les checks de l'action "Discuter" sont similaires à ceux de "Acheter"), alors il faut 1 classe par check (avec, au besoin, des classes composites, aka une classe qui utilise d'autres classes de Check pour faire son check). Ensuite, il ne reste plus qu'à instancier les checks "qui vont bien" pour la requête donnée.
Au besoin, une nouvelle classe "CheckedAction" peut être créée, et prendre en paramètre 1 classe Check et 1 classe Action (ne passe pas par des traits: fait 1 interface "IAction", implémentée dans différentes classes, chacune représentant une action). Cette classe aura alors à appeler le Check (pareil, 1 interface "ICheck" implémentée par chacun des checks), et en fonction de son résultat, elle exécute ou non l'IAction.

A mon avis, avec des schéma et du code, je comprendrai mieux ton soucis

[rachids]

C'est pas mal l'idée de ce que je voudrais réaliser !

Effectivement les checks peuvent se croiser selon les actions (on voudra toujours vérifier qu'un bâtiment se trouve à la fois dans la même ville ET dans la même case que le personnage, peu importe l'action entreprise dans ce bâtiment)

Ce que j'ai commencé à faire c'est de développer directement les actions dans les contrôleurs Laravel.
Je n'ai pas encore le niveau suffisant pour penser objet Va falloir que je me retape le tutoriel sur openclassrooms.

Mais je vais coder les checks dans des middlewares que j'appellerai pour les fonctions qui en ont besoins

Merci Xenos pour ton aide

[niahoo]

Les middlewares est là pour gérer la partie HTTP et communication entre le serveur et le client : requête, autorisation, réponse, etc … Perso ce genre de chose j'ai plutot tendance à le mettre dans du code purement « métier » qui va fonctionner quel que soit le framework utilisé.

[rachids]

J'avais regardé du côté des services providers aussi car il me semble que c'est un bon endroit pour développer du code métier.

Mais je me sens vraiment perdu dès qu'il est question d'architecture logicielle

[niahoo]

Essaie de penser sans Laravel. Le service provider permettra justement à lier le code de ton jeu et celui du framework en ouvrant plusieurs services. Par exemple pour un jeu de morpion en multijoueur, tu pourras exposer des services tels que Création de partie, Matchmaking, IA pour les parties en solo, etc.

Ça ne t'empêche pas ensuite de garder ce que propose Laravel pour le reste : Les joueurs et les parties sont des modèles Eloquent, une partie a une URL qui charge le modèle et affiche la partie via une vue Blade, etc : ici, on utilise Eloquent en tant que librairie et on profite de son intégration dans le framework pour se simplifier la tache, mais note bien qu'on pourrait toujours utiliser Eloquent sans le reste de Laravel dans ces cas précis. On a donc un couplage limité.

[rachids]

Super niahoo ! Merci pour l'explication et surtout l'exemple

Je comprends bien mieux comment aborder les Service Providers maintenant !
Je vais faire des tests sur mon petit jeu bac a sable