+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Référentiel de type de ressources : BDD, fichier, ou classes ? (/showthread.php?tid=4171)
Pages :
1
2
Référentiel de type de ressources : BDD, fichier, ou classes ? - Ter Rowan - 09-07-2009
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
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - wild-D - 09-07-2009
j'ai pas d'avis tranché sur la question, cela dépend du context que tu prévois pour l'évolution du jeu.
parce que outre l'aspect technique "dev/debugage"; il y a les aspects "utilisateur/admin/animateur". Si tu veux pouvoir permettre à des admin/animateurs pas codeur de pouvoir créer à la volée le codage en dur risque de poser problème. (enfin on peut toujours imaginer un générateur de classe de type d'objet ...)
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - Ter Rowan - 09-07-2009
(09-07-2009, 12:22 PM)wild-D a écrit : j'ai pas d'avis tranché sur la question, cela dépend du context que tu prévois pour l'évolution du jeu.
parce que outre l'aspect technique "dev/debugage"; il y a les aspects "utilisateur/admin/animateur". Si tu veux pouvoir permettre à des admin/animateurs pas codeur de pouvoir créer à la volée le codage en dur risque de poser problème. (enfin on peut toujours imaginer un générateur de classe de type d'objet ...)
oui c'est vrai qu'on pourrait imaginer des générateurs ^^
mais là tu soulèves un autre sujet, pas technique mais fonctionnel, comment faire vivre un jeu, doit on identifier une équipe d'administrateurs du "modèle du jeu", etc.. ce serait bien qu'on crée un sujet en ce sens quelque part, pour confronter les avis et expériences sur les jeux déjà en ligne
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - Arius Vistoon - 09-07-2009
pour moi cela correspond a la 3 + 1
1 car cela doit etre dans une base de données (ou un fichier xml ou bd + xml)
3 car le comportement doit dépendre de l'objet (donc notion d'heritage et de surcharge...)..bref chaque chose a sa place
la 2 tu peux la virer d'emblée
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - Ter Rowan - 09-07-2009
(09-07-2009, 01:57 PM)Arius Vistoon a écrit : pour moi cela correspond a la 3 + 1
merci pour ta réponse mais j'ai du mal à comprendre ce que tu mettrais en bdd dans ce cas précis ? tout est porté par la POO ?
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - hit - 09-07-2009
Pour moi la 2 et la trois sont identiques, à part que l'une utilise la poo et l'autre non...
Mais j'utilise moi même un stockage des données sur des fichier php dont je fait appel avec des ID. Pour permettre un débugage plus rapide je me suis construit par la même occasion une interface d'administration qui permet de modifier rapidement tous les objets (Pour ceux que ça intéresse je me suis inspiré de l'éditeur d'objet Warcraft III)
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - Zamentur - 09-07-2009
Si il y a des tables statiques et pas énorme qui sont plutôt de l'ordre de la configuration ou du réglage (ce qui ressemble à la table type_objet) tu peux faire un système de cache qui met tout çà dans un array php.
Tant que tu n'as pas trop d'entrée ce sera avantageux.
Maintenant moi je suis d'avis qu'un type d'objet puisse faire l'objet d'un héritage et donc ajout de nouvelle fonctionnalité en dure.
D'autre type d'objet n'en auront peut etre pas besoin et dans ce cas seul la bdd suffit en prenant comme modèle la classe de type objet générique.
Enfin dans la classe de type objet générique il peux être astucieux de pouvoir "charger" des fonctionnalité par exemple l'invisibilité peux être une fonctionnalité rajouter à n'importe quoi même si ce n'est pas utile.
De cette façon tu pourras effectivement permettre de créer des objet à des gens qui n'y connaissent rien en programmation.
Sur Algol les objets sont créer par les joueurs eux même au travers des magasins etc... Ainsi seules les fonctionnalités sont à coder.
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - JauneLaCouleur - 09-07-2009
Dans la DB tu mets les instances de tes classes d'Item. (Je choisi " Item " plutôt qu' " Objet " pour ne pas confondre), enfin, c'est comme cela que je l'ai compris, et que je ferais.
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - Morningkill - 10-07-2009
Ta vision de la 3 me parait un peu lourde, avec une classe (definie) par objet (et non type,ou sinon, ou mets tu les données parametres ?).. Déjà, il va te falloir un générateur, et puis, je vois pas trés bien comment tu vas pouvoir instancier sans inclure le code de chaque classe...
Pour la sauvegarde d'objets, il existe peut-être en php des solutions pour sauver directement un objet de façon transparente, genre db4o (pour net/java)
RE: Référentiel de type de ressources : BDD, fichier, ou classes ? - Allwise - 10-07-2009
Pour enregistrer l'instance d'un objet, y a la serialisation en php. Pour ma part, j'utilise une table qui recense les items, au sens abstrait, pas au sens instance donc. Dans la table, il y a les champs communs à tous les objets : id, nom, description, image, le gain d'attaque / défense / vitalité.... que ça apporte au perso etc. Les instances sont stockées dans des tables intermédiaires, genre perso_items, ou ville_items, ou que sais-je encore, ça dépend de la problématique. Dans ces tables, il y a un champs "params" qui contient en vrac et en serializé, toutes les caractéristiques propres à l'item en question. Là on se situe au niveau de l'instance.
Ensuite, pour gérer le comportement des items, ça se fait en objet. Y a une classe abstraite "item", qui définit quelques propriétés / méthodes de bases, puis des sous-classes, et encore des sous-classes, et pourquoi pas encore des sous-classes. Exemple : Item => arme => Arme à deux mains => Épée => Épée qui roxe sa maman. Avec le champ libre "params", je peux ainsi stocker les infos de n'importe quel item et recréer une instance très facilement.
Je parle au présent mais tout n'a pas été implémenté, vu que j'ai plus le temps de bosser dessus... Mais c'est comme ça que je procède / comptais procéder. Pareil pour mes NPC. J'ai une classe abstraite, ensuite plusieurs sous-classes : NPC marchand, NPC bavard, NPC salopard ( là j'invente, mais c'est pour l'exemple :p )... Et les classes des dits NPC : NPC001, NPC002 etc ( où le nombre correspond à l'identifiant du NPC, le même qu'en base ).
Je pourrai pas me passer de la BDD par contre, pour faire l'inventaire des objets d'un joueur, des NPC d'une map ou autre, ce serait un peu chiant. L'inconvénient de tout mettre dans un seul champ peut être qu'on ne peut pas faire de tri sur les données qui sont dans le dit champ. Mais pour ma part ce n'est pas un problème, étant donné que si jamais je dois faire des tris, il se fera sur les colonnes principales de l'objet ( nom, type d'objet, gain de vitalité & co ).