Gestion des objets utilisables - Version imprimable +- 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 : Gestion des objets utilisables (/showthread.php?tid=6671) |
Gestion des objets utilisables - Kurapika0 - 26-02-2013 Salut à tous, Je viens exposer mon problème, je commence à réfléchir au système que j'utiliserais pour les objets utilisables dans mon jeu, je compte donc mettre en place un inventaire dans lequel se trouveront tous les objets, que ce soit équipements, armes, munitions, consommables... bref tout, cependant à cause de la grande variété d'effet des objets (Ouverture d'un terminal permettant de faire l'action X, augmente les caractéristiques du perso, soigne un malus, arme pour le combat etc...), je me demande comment gérer tout ça, je me suis demandé si ça vaudrait le coup de créer d'abord en POO une classe Item commune pour que chaque objet aille dans l'inventaire, pour supprimer un objet, le déplacer etc..., puis en suite de faire une classe globale pour les consommables par exemple, puis de faire une classe par objet restant, avec une fonction use() qui contiendrait toutes les actions que l'objet engendre lorsqu'il est utilisé, aussi diverses soient elles. Pensez vous que cette méthode soit bonne ou pensez vous avoir de meilleures solutions? A vrai dire cette idée m'est venu après avoir fait quelques mods minecraft car le créateur avait une classe pour chaque blocs, donc je me suis dis pourquoi pas pour un jeu web avec les objets, cependant j’émets un gros doute sur l'utilité d'une telle manière de faire. Merci d'avance pour vos précieux conseils RE: Gestion des objets utilisables - Xenos - 26-02-2013 Salut, une classe par type d'objet, je trouve ca parfaitement logique. Si plusieurs objets sont similaires, faire un héritage de classe me semble parfaitement approprié. Avoir un diagramme du type suivant: Véhicule - Route -- Voiture --- Electrique --- Essence --- Air comprimé -- Camion - Aerien - Naval Me semble plus clair que d'avoir une seule classe "véhicule" avec un variable du genre "$type_de_véhicule = voiture;". De plus, cela ne me semble pas génant d'avoir une classe "vide", au sens: Code PHP :
Atouts: - Clareté de code ("new Lada()" est assez explicite et instancie une Lada, alors que new Voiture() ne permet pas de savoir grand chose sur cette voiture) - Extensibilité (si on veut que la lada puisse perdre une portière dans un virage, c'est facile d'ajouter la méthode dans la classe "Lada") - Facilité de relecture Inconvénients: - Un peu lourd à coder (faut ajouter des classes vides) - Un peu lourd à la documentation (classes vides qui semblent "parasiter" le code) Donc, oui, une classe par objet me semble parfait. PS: le code est en PHP (le fait que tu parles de "use()" qui n'existe pas en PHP me fait penser que tu ne code peut-être pas dans ce langage), mais l'idée est la même pour tout langage OO ou pseudo-OO. RE: Gestion des objets utilisables - niahoo - 26-02-2013 Je ne suis pas convaincu que le code soit le meilleur moyen de modéliser des données. Mais effectivement, si tous tes objets peuvent-être manipulés de façon identique dans l'inventaire, ils devraient faire partie de la même entité de données. Comme le propose Xenos tu pourras ensuite faire une classe Item, puis pour les bagnoles une classe Voiture qui héritera de la classe Item, puis une classe Lada, etc. Tu peux également faire des classes différentes mais implémenter une interface Item pour pouvoir être manipulés dans l'inventaire sans hériter d'une classe Item. Les fonctions use() en PHP sont des fonctions lambda et les variables déclarées dans le use() sont appelées des closures. Par extension, closure désigne aussi les fonction lambda qui contiennent des closures. Mais ça ne te servira pas à grand chose dans ce cas là. De plus tu ne peux pas combiner ça avec les méthodes d'une classe. Le truc chiant avec ce système c'est que quand tu lis l'inventaire du type, tu te dis, tiens, il a 5 exemplaires de l'objet #45. Et là il te faut aller checher quelque part que l'ID 45 correspond à la classe Lada ... Comme je le disais il vaut mieux modéliser sur le papier, pas avec du code. RE: Gestion des objets utilisables - Ter Rowan - 26-02-2013 on règle la génération de la classe de l'objet toto par le pattern factory non ? par contre je pense qu'avoir dans la classe une propriété nom/type de l'objet (ex lada) est pertinent : ça rend inutile la création de classe "vide" ==> j'ai une classe véhicule, j'instancie l'objet classe véhicule avec le nom lada, car lada a le même comportement que ferrari (donc la même classe) ça reste évolutif : le jour où j'ai besoin d'une classe lada au comportement différent de la classe véhicule, mon design pattern factory me permet sans effort de basculer RE: Gestion des objets utilisables - niahoo - 26-02-2013 Oui mieux vaut arrêter la hiérarchie d'objets aux entités présentant les mêmes caractéristiques. RE: Gestion des objets utilisables - Kurapika0 - 26-02-2013 En fait je me suis mal fait comprendre, quand je parlais de fonction use() je voulais parler d'une méthode de la classe Item, qui est est appelé pour utiliser l'objet en question, je code bien en php du coup. ^^ J'ai une autre petite question, quand vous parlez de pattern factory, qu'est ce que c'est exactement? Sinon pour voir quel id d'objet correspond à quelle classe, avec un tableau devrait faire l'affaire non? RE: Gestion des objets utilisables - Xenos - 26-02-2013 Les design patterns sont des idées de structures informatiques décrites il y a quelques années par... je sais plus quels auteurs, dans un bouquin célèbre ("Design Patterns"? je sais plus le titre non plus... Ma réponse est super-constructive!) Le pattern factory consiste à "encapsuler" plusieurs classes en une, ce qui permet à l'utilisateur (celui qui utilise le "new") de ne pas se préoccuper de la classe exacte qu'il instancie. RE: Gestion des objets utilisables - Ter Rowan - 26-02-2013 (26-02-2013, 09:01 PM)Kurapika0 a écrit : Sinon pour voir quel id d'objet correspond à quelle classe, avec un tableau devrait faire l'affaire non? Non pour chaque objet, en plus de son id, tu vas stocker un type. C est ce type qui va permettre a la factory d identifier la classe de l objet (26-02-2013, 10:45 PM)Xenos a écrit : Les design patterns sont des idées de structures informatiques décrites il y a quelques années par... je sais plus quels auteurs, dans un bouquin célèbre ("Design Patterns"? je sais plus le titre non plus... Ma réponse est super-constructive!) RE: Gestion des objets utilisables - Kurapika0 - 27-02-2013 Merci pour les précision sur les design patterns Mais si je créé un tableau du type : Code PHP :
Et que chaque classe porte le même nom que l'objet associé [nom_objet].class.php (Potion.class.php par exemple), alors je peux facilement instancier un objet de la classe Potion si je sais que l'id de l'objet que je cherche à instancier est 1 (et que donc la classe à appeler est Potion et se trouve dans le fichier Potion.class.php sauf si je met toutes les classes d'objets dans le même fichier). C'est ça que tu entends par stocker le type, ou alors je n'y suis pas du tout? RE: Gestion des objets utilisables - Ter Rowan - 27-02-2013 (27-02-2013, 02:22 PM)Kurapika0 a écrit : Merci pour les précision sur les design patterns ça veut dire que dans ta table objet tu as (par exemple) : id objet, id type, quantité, propriétaire 1, 1, 3, Ter Rowan 2, 1, 5, Kurapika0 3, 2, 1, toto 4, 2, 1, tutu 5, 4, 1, titi l'objet d'id 1 est de type 1 à savoir potion ==> Ter Rowan a trois potions l'objet d'id 2 est de type 1 à savoir potion ==> Kurapika0 a 5 potion l'objet d'id 5 est de type 4 à savoir voiture ==> titi possède une voiture après tu suis ton raisonnement mais sur le type un truc du genre (avec toutes les précautions à prendre de vérification, etc...) pour l'enregistrement $data que tu auras récupéré de la lecture de la table
|