Remettant tout à plat et m’inspirant de diverses discussions je revois complètement mon modèle.
Je me pose la question des « références »
J’entends par référence les « types de » (type de terrain, type de ressources, etc…)
Dans mon premier jet, tous ces types de étaient stockées dans des tables, en bdd, et étaient manipuler avec une seule classe « Ressource » par exemple pour la gestion des ressources.
En creusant et confrontant nos idées j’ai identifiés plusieurs possibilités que j’essaie d’analyser et j’aurais aimé avoir votre avis :
Le Besoin : je modélise des « ressources/objets ». Chaque objet est à un endroit ou sur un personnage stocké en base de données. En base de données on aura (c’est un exemple pour illustrer) :
- L’identifiant de l’objet
- L’identifiant du type d’objet
- Les « PV » (à 0 objet détruit par exemple)
- L’id du possesseur
Maintenant chaque objet va avoir un comportement différent en fonction de son type : Exemple 1 résultat d’événement : une fiole pleine d’explosif va exploser quand les PV seront à 0, une épée à 0 PV va se briser, un esprit familier avec 0PV va disparaître pendant 10 jours pour se ressourcer et revenir, etc…
Exemple 2 action possible : on ne peut pas attaquer avec une plume mais on peut attaquer avec une épée. Mais le résultat d’une attaque avec une épée (taille) est différent de celui d’une attaque avec une masse (écrasement)
Pour faire cela j’envisage plusieurs possibilités :
1) en base de données, j’ai une table de « type d’objets », ainsi que des tables associées puis en php, une classe générique « objet » qui avec les infos obtenues sera la seule utilisée.
Table type d’objets :
- L’identifiant du type d’objet
- Les points de vie maximum
- Le libellé (ou l’id de libellé pour du multilingue)
Table relation type d’objets événements
- L’identifiant du type d’objet
- L’événement (ex : 0PV)
- L’identifiant de l’action
Avantage : tout le modèle du jeu est en base de données
Inconvénients :
- des accès en bdd pour une info somme toute assez statique,
- un code générique certes lisible mais pas très simple à débugguer lors d’un comportement bizarre pour un objet en particulier (toujours regarder et le code et la bdd, avec des traductions entre id et action toutes les deux minutes.
- Vite une usine à gaz (rajouter des champs, des paramètres etc) quand on veut rendre un objet encore plus spécifique
2) Pas de base de données, mais tout en php avec un fichier contenant des tableaux de « type d’objets », ainsi que des tableaux associées puis une classe générique « objet » qui avec les infos obtenues sera la seule utilisée.
même principe que 1 mais sans mysql ^^
Tableau type d’objets :
- L’identifiant du type d’objet
- Les points de vie maximum
- Le libellé (ou l’id de libellé pour du multilingue)
Tableau relation type d’objets événements
- L’identifiant du type d’objet
- L’événement (ex : 0PV)
- L’identifiant de l’action
Avantage : pas d’accès en bdd
Inconvénients :
- un code générique certes lisible mais pas très simple à débugguer lors d’un comportement bizarre pour un objet en particulier (toujours regarder et le code et la bdd, avec des traductions entre id et action toutes les deux minutes.
- Vite une usine à gaz (rajouter des champs, des paramètres etc) quand on veut rendre un objet encore plus spécifique
- Du paramétrage dans du code plutôt qu’en base (a voir si c’est un bon argument)
3) Rien en base de données, tout en modélisation POO : à chaque type de ressources, je crée une classe avec potentiellement des chaines d’héritage (on trouvera une classe « épée à une main », une classe « fiole d’explosif », etc…)
Chaque classe possède les méthodes (ou en hérite) définissant des actions/événements (on0PV, onAttack, onUse)
Avantage :
- il suffit de se pencher sur la classe du type d’objet pour savoir réellement ce qui se passe
- pas de paramètre à passer sur les actions pour moduler en fonction de l’objets, seuls les paramètres de l’action sont nécessaires
Inconvénients :
- Pas de vrai code générique (mais est nécessaire vu le besoin ?)
- Tout est dans le code
- Pas de « liste du référentiel »
Voilà, j’aimerais bien avoir vos idées, arguments, réflexions, pistes par rapport à tout cela
Je me pose la question des « références »
J’entends par référence les « types de » (type de terrain, type de ressources, etc…)
Dans mon premier jet, tous ces types de étaient stockées dans des tables, en bdd, et étaient manipuler avec une seule classe « Ressource » par exemple pour la gestion des ressources.
En creusant et confrontant nos idées j’ai identifiés plusieurs possibilités que j’essaie d’analyser et j’aurais aimé avoir votre avis :
Le Besoin : je modélise des « ressources/objets ». Chaque objet est à un endroit ou sur un personnage stocké en base de données. En base de données on aura (c’est un exemple pour illustrer) :
- L’identifiant de l’objet
- L’identifiant du type d’objet
- Les « PV » (à 0 objet détruit par exemple)
- L’id du possesseur
Maintenant chaque objet va avoir un comportement différent en fonction de son type : Exemple 1 résultat d’événement : une fiole pleine d’explosif va exploser quand les PV seront à 0, une épée à 0 PV va se briser, un esprit familier avec 0PV va disparaître pendant 10 jours pour se ressourcer et revenir, etc…
Exemple 2 action possible : on ne peut pas attaquer avec une plume mais on peut attaquer avec une épée. Mais le résultat d’une attaque avec une épée (taille) est différent de celui d’une attaque avec une masse (écrasement)
Pour faire cela j’envisage plusieurs possibilités :
1) en base de données, j’ai une table de « type d’objets », ainsi que des tables associées puis en php, une classe générique « objet » qui avec les infos obtenues sera la seule utilisée.
Table type d’objets :
- L’identifiant du type d’objet
- Les points de vie maximum
- Le libellé (ou l’id de libellé pour du multilingue)
Table relation type d’objets événements
- L’identifiant du type d’objet
- L’événement (ex : 0PV)
- L’identifiant de l’action
Avantage : tout le modèle du jeu est en base de données
Inconvénients :
- des accès en bdd pour une info somme toute assez statique,
- un code générique certes lisible mais pas très simple à débugguer lors d’un comportement bizarre pour un objet en particulier (toujours regarder et le code et la bdd, avec des traductions entre id et action toutes les deux minutes.
- Vite une usine à gaz (rajouter des champs, des paramètres etc) quand on veut rendre un objet encore plus spécifique
2) Pas de base de données, mais tout en php avec un fichier contenant des tableaux de « type d’objets », ainsi que des tableaux associées puis une classe générique « objet » qui avec les infos obtenues sera la seule utilisée.
même principe que 1 mais sans mysql ^^
Tableau type d’objets :
- L’identifiant du type d’objet
- Les points de vie maximum
- Le libellé (ou l’id de libellé pour du multilingue)
Tableau relation type d’objets événements
- L’identifiant du type d’objet
- L’événement (ex : 0PV)
- L’identifiant de l’action
Avantage : pas d’accès en bdd
Inconvénients :
- un code générique certes lisible mais pas très simple à débugguer lors d’un comportement bizarre pour un objet en particulier (toujours regarder et le code et la bdd, avec des traductions entre id et action toutes les deux minutes.
- Vite une usine à gaz (rajouter des champs, des paramètres etc) quand on veut rendre un objet encore plus spécifique
- Du paramétrage dans du code plutôt qu’en base (a voir si c’est un bon argument)
3) Rien en base de données, tout en modélisation POO : à chaque type de ressources, je crée une classe avec potentiellement des chaines d’héritage (on trouvera une classe « épée à une main », une classe « fiole d’explosif », etc…)
Chaque classe possède les méthodes (ou en hérite) définissant des actions/événements (on0PV, onAttack, onUse)
Avantage :
- il suffit de se pencher sur la classe du type d’objet pour savoir réellement ce qui se passe
- pas de paramètre à passer sur les actions pour moduler en fonction de l’objets, seuls les paramètres de l’action sont nécessaires
Inconvénients :
- Pas de vrai code générique (mais est nécessaire vu le besoin ?)
- Tout est dans le code
- Pas de « liste du référentiel »
Voilà, j’aimerais bien avoir vos idées, arguments, réflexions, pistes par rapport à tout cela
