29-04-2009, 01:57 PM
Une base de donnée devrait contenir le strict et le nécessaire de tes données. Éviter les redondances, éviter d'avoir un manque d'information
Hou la bonne question ^^.
En fait pour ce point j'ai un peu improvisé. Et je t'encourage à faire mieux que moi ... c'est totalement faisable.
J'ai une table position contenant X et Y et un mystérieux id_lieu.
Puis un système de conversion étrange.
Remarques :
- dans mon jeu, les X et Y ne sont utiles dans mon cas que pour les déplacements en dehors des villes.
- L'information "rue" est stockée en variable de session. Toutes les rues sont accessibles à tout moment du moment qu'on est en ville. Un hackage de l'id_rue est faisable, mais totalement inutile. A la connexion on apparait donc sur la rue "par défaut" (souvent la place du village), ce qui est dans mon jeu, totalement acceptable.
Ce système complexe est très moche. Je te décourage d'en faire un aussi laid ^^.
L'avantage que je trouve à ce système, c'est qu'il recouvre mes besoins en termes fonctionnels (j'aurais jamais plus de 1000 villes, j'ai la possibilité d'avoir une infinité de rue, de donjons, de lieux, de parcelles ...).
De plus, il me permet d'avoir un système sans possible collision. Malgré un plantage de base de donnée, un personnage ne peut être qu'à un endroit.
Dans ton système, tu peux gérer une table position en fonction de tous tes champs :
Table position : id_position, id_region, id_lieux, id_parcelle, id_batiment
Si l'un des id_lieux, id_parcelle, id_batiment est égale à 0, alors le joueur est dans le container au dessus;
id_region = 2, id_lieux = 80, id_parcelle = 12, id_batiment = 0
indiquera que ton joueur est dans la parcelle 12, dans le lieux 80 de la région 2.
Cependant ce système me dérange un peu dans la mesure où des cas (non-souhaité bien sur) peuvent avoir lieu.
Le système de créer un "type de positionnement" par table ... peut avoir son intérêt si tu comptes employer des coordonnées X et Y pour chacun de tes régions, lieux, parcelle, batiment. Sinon, je trouve le système plutôt lourd ...
Il y a surement un système miracle, mais je l'ai pas trouvé.
Pour le reste, dès que tu as choisis ton modèle de donnée, je t'encourage à faire très vite une couche abstraction de ton modèle de donnée. En POO, en fonction, ou n'importe, mais que tu aies à disposition des méthodes simples pour : rentrer dans la région, sortir de la région, rentrer dans lieux, sortir du lieux, rentrer dans parcelle, sortir de parcelle ... + des fonctions de cohérences + des fonctions d'agrégation de données (lister les joueurs d'une région par exemple ...) + fonctions de zones (liste des régions accessible par une autre + fonctions de calcul de chemin (pour aller d'un batiment à un autre, quel chemin ? le plus court ? le moins dangereux ? le plus empreinté ? le plus accessible sans compétence d'escalade, de natation ...) + d'autres fonctions propre à ton jeu...
En te souhaitant maintenant bon courage,
kéké
PS : la POO semble tout indiqué pour ce type de problèmatique, mais je suis pas le mieux placé pour parler de ça.
(29-04-2009, 11:56 AM)comg a écrit : Keke : Comment tu connais la position de tes joueurs ? Pour chaquun tu stocke une valeur rendant à chaque table ?
Hou la bonne question ^^.
En fait pour ce point j'ai un peu improvisé. Et je t'encourage à faire mieux que moi ... c'est totalement faisable.
J'ai une table position contenant X et Y et un mystérieux id_lieu.
Puis un système de conversion étrange.
Code :
Ainsi, id_lieu = 0. Le X et Y représente les coordonnées sur la carte générale.
Si le id_lieu est négatif, le X et Y représente les coordonnées sur la carte détail dont l'id est égale à -id_lieu (qui devient donc une valeur positive).
Si le id_lieu est compris entre 0 et 1000, le joueur est dans une ville. Il se déplacera sur la rue "par défaut" en cas de besoin.
Si le id_lieu > 1000, le joueur est dans la parcelle dont l'id est (id_lieu - 1000). S'il y a un batiment a cet endroit, il rentre dedans. S'il n'y a pas de batiment à cet endroit, il est simplement sur la parcelle.Remarques :
- dans mon jeu, les X et Y ne sont utiles dans mon cas que pour les déplacements en dehors des villes.
- L'information "rue" est stockée en variable de session. Toutes les rues sont accessibles à tout moment du moment qu'on est en ville. Un hackage de l'id_rue est faisable, mais totalement inutile. A la connexion on apparait donc sur la rue "par défaut" (souvent la place du village), ce qui est dans mon jeu, totalement acceptable.
Ce système complexe est très moche. Je te décourage d'en faire un aussi laid ^^.
L'avantage que je trouve à ce système, c'est qu'il recouvre mes besoins en termes fonctionnels (j'aurais jamais plus de 1000 villes, j'ai la possibilité d'avoir une infinité de rue, de donjons, de lieux, de parcelles ...).
De plus, il me permet d'avoir un système sans possible collision. Malgré un plantage de base de donnée, un personnage ne peut être qu'à un endroit.
Dans ton système, tu peux gérer une table position en fonction de tous tes champs :
Table position : id_position, id_region, id_lieux, id_parcelle, id_batiment
Si l'un des id_lieux, id_parcelle, id_batiment est égale à 0, alors le joueur est dans le container au dessus;
id_region = 2, id_lieux = 80, id_parcelle = 12, id_batiment = 0
indiquera que ton joueur est dans la parcelle 12, dans le lieux 80 de la région 2.
Cependant ce système me dérange un peu dans la mesure où des cas (non-souhaité bien sur) peuvent avoir lieu.
Le système de créer un "type de positionnement" par table ... peut avoir son intérêt si tu comptes employer des coordonnées X et Y pour chacun de tes régions, lieux, parcelle, batiment. Sinon, je trouve le système plutôt lourd ...
Il y a surement un système miracle, mais je l'ai pas trouvé.
Pour le reste, dès que tu as choisis ton modèle de donnée, je t'encourage à faire très vite une couche abstraction de ton modèle de donnée. En POO, en fonction, ou n'importe, mais que tu aies à disposition des méthodes simples pour : rentrer dans la région, sortir de la région, rentrer dans lieux, sortir du lieux, rentrer dans parcelle, sortir de parcelle ... + des fonctions de cohérences + des fonctions d'agrégation de données (lister les joueurs d'une région par exemple ...) + fonctions de zones (liste des régions accessible par une autre + fonctions de calcul de chemin (pour aller d'un batiment à un autre, quel chemin ? le plus court ? le moins dangereux ? le plus empreinté ? le plus accessible sans compétence d'escalade, de natation ...) + d'autres fonctions propre à ton jeu...
En te souhaitant maintenant bon courage,
kéké
PS : la POO semble tout indiqué pour ce type de problèmatique, mais je suis pas le mieux placé pour parler de ça.