+- 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ésolu] Structure des tables pour un Ogame-like (/showthread.php?tid=4581)
RE: Structure des tables pour un ogame-like - QuentinC - 12-02-2010
Citation :Les données propres aux modèles de bâtiment, tu seras de toute manière amené à les récupérer, rien que pour la sécurité : est-ce que le bâtiment que Robert cherche à contenir existe bien ?Quand ça se trouve dans des tableaux php, il n'y a rien à récupérer, c'est déjà là. OU alors tu entendais autre chose qu'interroger la base par « récupérer ».
Citation :De plus, si tu souhaites interroger ta base de données depuis une autre application (par exemple un site externe comme World of Warcraft et son armurerie) ? Comment tu fais ? Tu vas parser tes fichiers PHP ?IL y a peu de chance que ça arrive. Mais effectivement si ça devait se faire, tu as raison : ce serait la m****.
Tout compte fait, je crois bien que je vais aussi adopter ta structure utilisant des « modèles ». Ca fait « pro » d'avoir un panel d'admin pour changer les coûts et autres. Merci pour le conseil.
Une dernière question cependant : si j'ai 5 types de ressources primaires, est-ce que je peux quand même les stocker selon modèle n°1 sans détruire tous mes efforts ? Parce que sinon c'est une jointure et 5 update à chaque refresh, obligatoire. ET il ne pourra jamais y avoir une sixième ressource, ça changerait tout le gameplay (c'est des ressources figées du genre métal/cristal/deutérium, bien sûr chez moi c'est autre chose)
RE: Structure des tables pour un ogame-like - Sephi-Chan - 12-02-2010
Ça facilite surtout la maintenance et augmente la robustesse de l'application.
Tant que les ressources n'ont pas besoin d'être identifiées individuellement, une simple colonne numérique convient parfaitement : un montant de pièces d'or, par exemple. Ce serait même une erreur que de faire autre chose.
En l'occurrence, tu as tout intérêt à avoir tes 5 colonnes (metal_count, crystal_count, etc.).
Sephi-Chan
RE: Structure des tables pour un ogame-like - QuentinC - 12-02-2010
Merci beaucoup pour vos réponses.
Du coup, vous me faites douter sur quelque chose d'autre.... Comme on dit, une réponse amène une nouvelle question.
Pour la table des évènements, j'avais prévu ce genre de structure.
Code :
create table Events (
id int unsigned auto_increment,
type enum(....),
player1 int,
player2 int,
-- ....
data text, -- données sérialisées
primary key(id));1/c'était judicieux ou s'il serait mieux de passer par une structure en relation n:m avec une table de liaison (eventId+playerId sans champ custom), sachant qu'un évènement ne pourra jamais concerner plus de deux joueurs, et que la majorité des évènements ne concerne qu'un seul joueur (dans ce cas player2=0)
et 2/si je conserve cette structure, laquelle des deux requêtes suivantes serait la meilleure pour récupérer les évènements concernant le joueur id=7 :
a. select * from Events where player1=7 or player2=7
b. select * from Events where player1=7 union select * from Events where player2=7
Note : Si je mets des index sur player1 et player2, la première requête ne semble pas vouloir les prendre en compte.... mais les unions c'est mal
RE: Structure des tables pour un ogame-like - christouphe - 12-02-2010
est ce que tu mettras les évènement du style construction/amélioration ? Si oui, je pense que ta table n'est pas adaptée, enfin c'est mon avis, hein
Exemple là:
http://archive.jeuweb.org/resolution-de-ma-liste-daction-t-6242.html
RE: Structure des tables pour un ogame-like - Anthor - 12-02-2010
(12-02-2010, 09:58 AM)christouphe a écrit : est ce que tu mettras les évènement du style construction/amélioration ? Si oui, je pense que ta table n'est pas adaptée, enfin c'est mon avis, hein
Exemple là:
http://archive.jeuweb.org/resolution-de-ma-liste-daction-t-6242.html
J'utilise cette stucture :
Code PHP :
<?php
CREATE TABLE IF NOT EXISTS `events` (
`id` int(255) unsigned NOT NULL AUTO_INCREMENT,
`refArea` int(255) unsigned NOT NULL,
`type` varchar(64) NOT NULL,
`params` text NOT NULL,
`dateStart` datetime NOT NULL,
`dateEnd` datetime NOT NULL,
`status` tinyint(1) NOT NULL,
PRIMARY KEY (`id`),
KEY `refArea` (`refArea`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
C'est globalement la même, c'est amplement suffisant. Mon type lance la classe adaptée, construite avec ses params. Le reste n'a rien à faire dedans, et je vois pas ce qu'on pourrait y mettre de plus d'ailleurs.
RE: Structure des tables pour un ogame-like - My Hotel - 12-02-2010
Désolé, je remet mon lien : ici
Et le paragraphe :
Citation :Commençons les sélections de base :
Imaginions que nous souhaitons sélectionner tous les champs de la table membres où le pseudo est 'webmaster'. La requête sera la suivante :
SELECT pseudo,passe,mail FROM membres WHERE pseudo='webmaster'
On aurait pu aussi faire ceci (pour sélectionner tous les champs). Ceci est à titre d'exemple, ne l'utilisez pas sur votre serveur mysql car vous perdriez en performances :
SELECT * FROM membres WHERE pseudo='webmaster'
J'ai aussi entendu pas mal de développeurs dire que le * c'était le mal, alors j'ai arrêté. Mais ça change peut-être effectivement rien, ou alors ça touche que certaines requêtes?
Quelqu'un en sait-il plus?
Bye
RE: Structure des tables pour un ogame-like - Anthor - 12-02-2010
Fais du profiling, tu verras, c'est mieux qu'une phrase vide de sens.
Tiens par exemple :
1. [1.55 ms] connect
2. [2.03 ms] DESCRIBE `users`
3. [0.24 ms] SELECT `users`.* FROM `users` WHERE (((`users`.`id` = 1)))
4. [2.56 ms] DESCRIBE `areas`
5. [0.29 ms] SELECT `areas`.* FROM `areas` WHERE (((`areas`.`id` = 1)))
Alors à ce niveau, c'est plus qu'acceptable. ^^
RE: Structure des tables pour un ogame-like - QuentinC - 12-02-2010
Citation :est ce que tu mettras les évènement du style construction/amélioration ? Si oui, je pense que ta table n'est pas adaptée, enfin c'est mon avis, heinBien sür que oui. Le but est de tout regrouper, j'y vois un énorme avantage :
1 - On select les évènements qui concerne le joueur connecté, plus précisément la ville actuellement sélectionnée, ou bien une de ses armées. C'est là qu'il faut que je trouve comment être efficace et simple à la fois, et c'est là que j'ai du mal à voir quelle structure exacte adopter.
2 - On créer des objets correspondant aux types d'évènements. Type contient toujours un nom de classe existant, d'Oû une enum, mieux que varchar. P.ex. Construction, Recruit, Battle, ...
3 - On traite tout à la suite sans effort, merci le polymorpisme
4 - On delete ce qui est fini et on update ce qui est en cours de progression, ça devrait pouvoir se faire en 2 requêtes (un delete ... where id in, et un replace into)
@Anthor > tiens, bizarre, le plus long c'est encore le connect si on ne tient pas compte des describe qui ne servent de toute façon à rien en prod
RE: Structure des tables pour un ogame-like - Sephi-Chan - 12-02-2010
La connexion à la base est connue pour être longue et coûteuse.
Pour ton système d'évènement générique, je te conseiller d'appliquer le principe de STI (Single Table Inheritence) utilisé par les grands frameworks et qui fonctionne au poil.
Cela consiste à créer une table qui contient les colonnes nécessaire à tous les types d'événements ainsi qu'une colonne "type" qui contient le nom de la classe à instancier.
Tu auras donc une classe Event, ainsi que des classes filles BuildingEvent, UpgradeEvent, etc. Ensuite tu n'as plus qu'à créer une classe EventFactory qui instanciera les classes qui conviennent.
Sephi-Chan
RE: Structure des tables pour un ogame-like - Ter Rowan - 12-02-2010
y a des choses que je trouve incohérentes dans le fil de discussion
quelle est la différence entre un batiment et une ressource ?
Citation :En l'occurrence, tu as tout intérêt à avoir tes 5 colonnes (metal_count, crystal_count, etc.)
les ressources ça sert à [traitement informatique] des bâtiments
les bâtiments ça sert à [traitement informatique] des cités
il n'y a aucune raison pour qu'on fasse une différence de modélisation sur les termes "batiments" et "ressources"
Pour moi le sujet est plutôt variation/nombre de type/utilisation
Si il n'y a que trois types de [bâtiments/ressources] dans le jeu et que cela n'évoluera pas et que la seule utilisation est le comptage de [bâtiments/ressources] => je pense que le mieux est trois colonnes
Si il y a 50 types de [bâtiments/ressources] dans le jeu ou que les types évoluent ou qu'on utilise de plusieurs manières ==> je pense que le mieux est une nouvelle table
Exemple : un jeu où il n'y comme ressource que "blé" "fer" "or" "cristal"
on peut se dire ce sont des colonnes
maintenant si dans le jeu les ressources peuvent s'auto détruire (le blé qui pourrit si il reste trop longtemps non consommé, le fer qui s'oxyde, etc... donc il faut compter avec le "vieillissement" de la ressource, etc...), il sera plus pertinent de passer à un modèle à deux tables, même si il n'y a que quatre ressources
ce n'est pas le terme ressource ou bâtiment qui justifie d'être en colonne ou en ligne, c'est l'utilisation/gameplay du terme. Dans tel jeu telle notion pourrait être plus pertinente en colonne, dans telle autre non.
Maintenant je suis aussi partagé sur le côté tout en table rien en fichier (pauvre Sephi, je reprends tous tes arguments, mais je n'ai rien contre toi :p )
- est ce que tout le monde met les fichiers de traduction en table ? après tout les traductions, ce n'est rien d'autre que de la donnée
- est ce que les fichiers xml ou les fichiers de configuration devraient être tous en bdd, après tout ce sont des données
- est ce que développer des classes avec des comportements, voire des données initialisées en dur dans les classes c'est mal ? Imaginons la classe grenier qui hérite de la classe batiment (bon pas sûr que l'exemple soit terrible ^^).
- en quoi un tableau est plus coûteux qu'une requête (qui rappelons le, donne un résultat sous forme de tableau) ?
je pense que là encore tout dépend du contexte. Si les coûts évoluent autant qu'une configuration, je ne vois rien de choquant à les conserver sous forme de tableau
Quant à l'aspect interrogation des données par une application tiers, ma vision du découpage en couches fait que, finalement, peu importe les applications tiers, l'accès aux données ne doit être développé qu'une fois donc si pour le jeu on sait gérer les coûts via tableau, alors on sait les restituer à une autre application
maintenant je ne suis pas architecte, jamais vraiment été formé sur ce sujet, et suis prêt à entendre les critiques la dessus
A noter, dans MA représentation d'un jeu, ma démarche non réfléchie serait de tout mettre sur le modèle trois tables (que ce soit ressources et bâtiments) parce que j'imagine un jeu à interaction importante sur ces éléments, maintenant si l'un de ses éléments est prétexte et donc simple (genre y a de l'or et des pierres et puis c'est tout) je prendrais plut^to l'option colonne mais ce n'est pas MA représentation "innée" d'un jeu