Ou stocker les conditions pour améliorer les batiments ?

[Argorate]

Ton exemple est super pour perdre de la place^^
Personnellement, je pense que si tu prévois un arbre Tech avant sur papier, tu as plus à changer quoi que se soit après, et pour les rare fois ou tu changes tu remets toute la séquence, ça ne pose pas grand soucis.
Pour traiter les données ce n'est pas l'idéal c'est sur, mais c'est très économe quand on prévoit un grand arbre technologique. Car remplir ta bdd de centaines d'entrées pour ça, je trouve que tu perds de la place pour rien, sans compter que tu perds également du temps en traitement les données dernières, pour trouver la bonne entré parmi toutes, et même pire, tu dois trouver tous les tuples concernant l'ID du bâtiment que tu test, alors qu'avec l'autre méthode, un tuples, un champ, terminer.
(C'est bien beau d'avoir plein d'infos en BDD, mais le serveur a ces limites, plus on perd du temps a faire plein de requêtes et a transférer plein de données provenant du serveur, plus on a de risque qu'un jour le serveur plante [ou meme des ralantissement, ça énerve -a juste titre- tres vite les joueurs], car il n'arrive plus a suivre ; C'est dans cette optique là que je propose cette alternative en tout cas.).

Bref, il faut voir le jeu en question, s'il n'y a pas beaucoup de bâtiment ni de relation entre eux c'est préférable de faire une table rien que pour cela, mais si il y en a trop, je ne suis pas sur que se soit le plus optimisé des systèmes (bien qu'il marche très bien).

[QuentinC]

Rien n'empêche d'utiliser cett technique couplée à du cache dans un fichier. A mon avis c'est très efficace, car on modifie facilement les données et on peut ne faire l'update du cache que sur demande explicite.

[Satevis]

@Argorate > Ce que tu dis est absolument absurde; attention ne prends pas cela pour une attaque; voici pourquoi.

Utilisez une base de données et ce servir d'un champ dans lequel tu concatènes les pré-requis est un non sens, tu y perds la philosophie d'une base de données qui se veut être une structuration atomique de tes données. De plus, tu perds plus en pratiquant cette technique qu'en utilisant la base de données telle qu'elle doit l'être.

Une modélisation correct de ta base de données, te permet en une seule requête de récupérer des données structurées. Hors là, avec cette technique tu es obligé de traiter une nouvelle fois les données pour en retirer la quintescence. C'est une perte en temps et en ressources.

Donc plutôt que de faire de la concaténation, il faut une table qui contient autant d'entrée que nécessaire pour les prérequis d'une construction.

Voici un exemple :
Un bâtiment : Réservoir de Gazoil
Ses prérequis : Puit de pétrole niveau 1, Pipeline niveau 1

Supposons que le Réservoir de Gazoil possède l'identifiant 50, le Puit de pétrole possède l'identifiant 15 et le Pipeline possède l'identifiant 24.

La table des prérequis contiendra 2 entrées structurées comme ci-suit :
prerequis(id_construction, id_construction_requise, niveau_construction_requise);
prerequis(50, 15, 1);
prerequis(50, 24, 1);

Ainsi, il est plus aisé au travers de requête, sous-requête de savoir si il est possible de créer ce dit bâtiment.

Ton exemple est super pour perdre de la place^^
Personnellement, je pense que si tu prévois un arbre Tech avant sur papier, tu as plus à changer quoi que se soit après, et pour les rare fois ou tu changes tu remets toute la séquence, ça ne pose pas grand soucis.
Pour traiter les données ce n'est pas l'idéal c'est sur, mais c'est très économe quand on prévoit un grand arbre technologique. Car remplir ta bdd de centaines d'entrées pour ça, je trouve que tu perds de la place pour rien, sans compter que tu perds également du temps en traitement les données dernières, pour trouver la bonne entré parmi toutes, et même pire, tu dois trouver tous les tuples concernant l'ID du bâtiment que tu test, alors qu'avec l'autre méthode, un tuples, un champ, terminer.
(C'est bien beau d'avoir plein d'infos en BDD, mais le serveur a ces limites, plus on perd du temps a faire plein de requêtes et a transférer plein de données provenant du serveur, plus on a de risque qu'un jour le serveur plante [ou meme des ralantissement, ça énerve -a juste titre- tres vite les joueurs], car il n'arrive plus a suivre ; C'est dans cette optique là que je propose cette alternative en tout cas.).

Bref, il faut voir le jeu en question, s'il n'y a pas beaucoup de bâtiment ni de relation entre eux c'est préférable de faire une table rien que pour cela, mais si il y en a trop, je ne suis pas sur que se soit le plus optimisé des systèmes (bien qu'il marche très bien).

Ouais c'est pas vraiment l'espace disque qui coute le plus cher .
En générale ça te coute plus cher de recréer tes informations utiles avec en PHP que de les sortir de la BDD déjà rangées et formatées surtout que plus ton arbre sera développer plus ton champs sera long et donc plus la fonction prendra de temps a découper la chaîne.
Un avantage à la méthode de z3d est qu'avec une requête tu peux vérifier si le joueur à accès ou non à tel bâtiment ou telle technologie sans avoir à split et allez récupérer les infos du joueurs et les comparer mais ce n'est utile que si ton arbre de développement est caché au joueur et qu'il ne connait que ce dont il à accés .

Mais par contre j'ai une petite question sur comment vous gérer les pré-requis de vos pré-requis, particulièrement sur la méthode de z3d car autant du récursif en PHP y a pas de problème autant en SQL je suis pas sûr que ce soit possible (pas vraiment chercher non plus faut dire), vous mettez TOUT les pré-requis c'est à dire toutes les conditions qui doivent être satisfaites pour que le bâtiments soit accessible ou seulement les pré-requis et ensuite vous allez chercher les pré-requis et ainsi de suite ?

Sinon que pensez vous d'un script PHP qui parserait (sur demande ou aprés vérification de la date de modification) un fichier XML (facile à modifier) contenant toutes les informations nécessaires et qui générerait un tableau à plusieurs dimensions dans un fichier qui serait ensuite inclus au besoin.
Le gros points négatif à cette solution est je pense la consommation mémoire puisque on va a chaque fois charger tout l'arbre technologique et je suis pas sûr qu'on y gagne en vitesse d'exécution puisque il y a tout le tableau a initialiser.

[manip]

Personnellement j'utilise un système plus simple (a mon avis), je détermine un coup en temps et en ressource pour chaque bâtiment (stocker dans un seul fichier inclu facile à gérer) qui va varier avec son niveau. Ainsi je n'ai qu'a récupere le niveau depuis la base et faire un petit calcule.

Pour les conditions j'ajoute simple en if dans l'affichage avec ce que je dois verifier.

exemple : if ($batimet_a > 10) echo $batiment_b

Voilà j'espère que ça aidera quelqu'un

[Cartman34]

manip -> il te faut le vérifier aussi quand le joueur a cliqué sur ton formulaire ou lien.
De plus, on utilises généralement ">=" au lieu de ">" car cela correspond au premier niveau atteint par le batiment A où le batiment B est visible/"achetable".
Enfin, on utilise généralement des boucles et des tableaux pour gérer cela(même en POO à mon avis...), je sais pas si tu le fais car ton exemple est général mais je le dis au cas où.

Satevis -> je conseille l'utilisation de la méthode JSON plutot qu'un fichier XML car c'est encore plus pratique et il parait que c'est plus rapide que le XML.

[manip]

manip -> il te faut le vérifier aussi quand le joueur a cliqué sur ton formulaire ou lien.
De plus, on utilises généralement ">=" au lieu de ">" car cela correspond au premier niveau atteint par le batiment A où le batiment B est visible/"achetable".
Enfin, on utilise généralement des boucles et des tableaux pour gérer cela(même en POO à mon avis...), je sais pas si tu le fais car ton exemple est général mais je le dis au cas où.

C'est tout à fait le cas, dans mon dernier message, je me suis contenter d'afficher le strict minimum

[Satevis]

Satevis -> je conseille l'utilisation de la méthode JSON plutot qu'un fichier XML car c'est encore plus pratique et il parait que c'est plus rapide que le XML.

Oui effectivement ça à l'air bien plus pratique .