18-06-2009, 10:03 AM
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
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