[Résolu] Problème effets temporaires

[MdE]

Bonsoir,

Je sollicite à nouveau votre aide pour un problème qui ne me paraît pas très compliqué à la base, mais je bloque. Je me dis que je ne suis pas forcément parti sur le bon algorithme...

Alors voilà j'ai une table indiquant les effets spéciaux d'un objet:
Du genre: L'objet avec l'id=5 augmente la force de 1 pt pendant 60 secondes.

Il y a une autre table qui indique que tel perso est sous tel effet jusqu'à telle date.

Donc quand la date est dépassée, je fais une requête pour récupérer le bonus donné, la caractéristique affectée et donc j'enlève le bonus au perso.

Jusque-là, j'ai aucun soucis.

Mais il existe des objets qui ont des bonus multiples et donc j'ai par exemple plusieurs effets pour le même objet
Du genre: L'objet avec l'id=5 augmente la force de 1 pt pendant 60 secondes. Mais aussi l'objet avec l'id=5 augmente les PV de 10 pts pendant 60 secondes.

Et là, impossible d'annuler correctement les effets de l'objet quand la date d'effet se termine

Je pars sur SELECT * FROM [Les effets en cours] LEFT JOIN [ce que font ces effets].....

Or j'ai l'impression que vu qu'il y a un seul enregistrement pour [Les effets en cours] et plusieurs enregistrements de l'autre table, la jointure se fait mal.

Donc, comment faire pour arranger cela ?

J'espère que j'ai été clair même si je crois que non :heuuu:

[OncleJames]

Les solutions qui me viennent à l'esprit.


1) Les bonus peuvent être divers et variés, les prévoir tous est impossible.
Dans ces cas la, il te faut inventer un mini langage pour stocker les effets.

Exemple : 10 pv pendant 60 secondes et attaque +20 pendant 59 secondes

Dans la table tu as un champs text avec dedans :
"pv/+/10/60.att/+/20/59"
En php tu fais simplement du explode et tu obtiens tout tes bonus, ensuite tu parse ton tableau en appliquant le bonus correspondant.

2) Elle me semble pas bonne du tout mais la voici quand même

Dans une table effet, tu stockes tout les effets possible
ID 1 - +10 pv pendant 60 secondes
ID 2 - +20 attaque pendant 59 secondes

Ensuite dans la table des objets, tu met dans un champs text la liste des ID effet.
Exemple : "1,2,5"
Et un explode pour finir



On peut poussé plus loin et je le conseil de mon point vue, c'est de traiter les bonus en php directement, prenons la solution 1.
On récupère le mini langage, puis on génère un tableau d'objet avec pour chacun un effet ensuite on parse le tableau en appelant la méthode appliquer() .
Sa évite de se balader avec des effets partout, le deuxième avantage est que tout est centraliser dans la classe et les possibilités d'effets infini.

Si cette dernière méthode t'intéresse je peux l'expliquer plus en détails.

[MdE]

J'avais pensé à la méthode du explode mais cela me paraît être du bricolage et je me dis qu'il doit y avoir une solution plus propre. Mais à défaut c'est vrai que je ferais ça.

[My Hotel]

Pour mon jeu, après pas mal de réflexion, je me sers aussi du mini language, parce que les autres solutions sont trop compliquées à utiliser, et à mettre en oeuvre.

J'ai un truc du genre : Vitesse.60.+3|Attaque.I.-2 etc

Ca marche très bien avec une bonne fonction classe pour parser tout ça, et les possibilités d'extension sont quasi-infinies

[NicoMSEvent]

dans mon cas, ce que je fais pour les bonus, j'ai une date début(sysdate ou now() pour les mysqliens), et une date de fin. Je garde une trace de ces lignes, je ne les supprime pas une fois l'effet terminé (ça permet de vérifier qui a consommé quoi et a quel moment -> système anti-bot)
Je n'applique pas aux caractéritiques du perso le bonus. (je ne modifie pas les caractéristiques de base), mais je calcule au vol la caractéritique finale (base +bonus-malus) en fonction des bonus à appliquer (now() between date_debut and date_fin).

j'ai juste une boucle qui parcourt les bonus/malus, et une variable statique que je modifie a chaque itération (rien de stocké en BDD)

Pas de mini-langage pour moi (assez complexe a mettre en oeuvre, je pense)

[wild-D]

j'aime pas ta manière de faire:
la logique voudrais que tu recalcules depuis le début. plutot que bidouiller les bonus malus à chaque fin/activation d'effet (avec un tel système si t'as un bug, tu vas trop enlever ou ajouter de manière répétée, ça risque donc de poser problème à terme).
genre tu auras :
- donc caras "naturelles"
- bonus/malus d'état (équipement, position)
- bonus/malus temporaire (la durée peut être en temps réel. ou virtuel-genre nb de tour-)
pour optimiser tu peux surement garder une version du résultat.


après c'est aussi à toi de voir en fonction de ce que tu souhaite faire; perso y a la solution explode, serialize, de code php "brut" que tu utilise avec un eval() ou un fake/proto langage; les solution manquent pas.

Faut quand même commencer par bien poser les limites de ton système (^^ perso j'ai aussi voulu un système super-effets... je commence à me dire que c'est p-e pas zemust) parce que le postulat de départ "une infinité d'effets"... (je doute qu'un perso puisse avoir une infinité d'effets appliqué en simultané, et tu n'a pas une infinité de caras, compétences sur lesquelles agir non plus).

après je rejoins oncleJames;pour moi la solution de la classe Effet est surement la plus souple (c'est pas la plus légère non plus ). Empiler tes Effets dans un "slot" du perso ça te permet d'agir librement en appliquant l'effet sur ce que tu veux (càd sur n'importe quel attributs -caras, compétences, etc...-; et à n'importe quel moment -plutot que d'avoir que des effet "initiaux" sur les caras, etc.. tu peux aussi appliquer des effets sur des "résultats" comme un jet de dès, jets d'attaques, etc...-).

je suis assez mitigé sur mon essai; je trouve finalement assez barbare, j'essaie de voir si je trouve pas une meilleure méthode; mais je te donne ce que j'ai tenté.
j'ai essayé dans ce genre de situation de pas définir UN proto langage générique ou un autre système globale. Mais de me laisser la libérté d'en utiliser "plusieurs en parallèle".
y a donc l'id, et les champs idoine (durée) systèmatiques; après j'ai un champs méthode, 2 champs arguments varchar;
ensuite grosse pseudo classe qui sert de fabrique commune: FabriqueEffet::$methode($arguments...)
l'idée étant qu'en fragmentant ainsi je m'évite la création d'un vrai parseur pour interprété un pseudo langage plus évolué (puisque là restreint à une méthode de fabrique d'effets, ça permet généralement d'avoir quelque chose de très limité, voir même simplement un entier, ou une chaine de caractère simple)...

Enfin, là je suis plus sur l'optique d'abandonner ce système "tout en un". Et d'évaluer le pour et contre:
0) le cul entre 2 chaise c'est pas si mal, je continue avec ça
1) d'un système brutal en eval() (pas besoin d'inventer un proto langage alors que y a déjà php; mais l'utilisation d'eval me met pas en confiance :/ pourtant ce serait le mieux niveau je peux imaginer tout ce que je veux)
2) ou restreindre simplement la complexcité des effets. Y a pas besoin de pouvoir tout avoir

[MdE]

En fait, je me suis rendu compte que c'était davantage une erreur de ma part qu'un réel problème d'algorithme donc c'est résolu. Alors en fait, un objet renvoie à 1 ou plusieurs effets différents, quand j'utilise un tel objet, on regarde les effets correspondant via l'id, on boucle, on met dans la table des effets temporaires CHAQUE (c'était là mon erreur) effet dans une ligne via l'id de l'effet avec sa propre date de fin et après, quand la date est périmée et bien on enlève tous les bonus.

Donc je n'ai pas de problèmes en fait et je préfère rester à ma version qu'à la version bricolage ^^ même si elle crée plus d'enregistrements.

Merci beaucoup ^^

[Morningkill]

[quote='My Hotel' pid='71692' dateline='1245306722']
Pour mon jeu, après pas mal de réflexion, je me sers aussi du mini language, parce que les autres solutions sont trop compliquées à utiliser, et à mettre en oeuvre.
[quote]
Pour mon projet de jeu, j'ai prévu que les conditions et effets soient modifiable par le designer, en C#
Autrement dit, le gars a une petite interface pour taper son source, et derriere, c'est compilé dans un objet.
Genre, le designer tape "e.vie+=20;"
Et derriere, ca genere un objet

Code :

class Effet
{
public void ApplyEffect(IEntity e)
{
      e.vie+=20;
}

(grossomodo)
En plus de permettre des choses sophistiquées sans effort de ma part (par rapport a une classe de parsage que je devrais écrire), sauver en base la version compilée me garantit de bonnes perfs.

[OncleJames]

Tu stockes le code compilé ou le texte simplifié (e.vie += 20 ) ?

[Morningkill]

Tu stockes le code compilé ou le texte simplifié (e.vie += 20 ) ?

Alors, je stocke(rai) les deux (pour pas avoir a decompiler quand le designer reviendra sur sa page de saisie )

Mais dans le moteur de jeu, je recupererai le code compilé, je l'ajouterai a l'espace d'execution en cours, et hop !