création d'un nouveau joueur

[xanthius]

Bonjour,
j'aimerais récolter un peu d'informations concernant la procédure d'inscription sur vos sites.
Quand pour un nouveau joueur vous devez le renseigner sur plusieurs tables différentes vous vous y prenez comment ?
Du style pour un nouveau joueur, vous devez le faire rentrer sur la table A,B,C
Pour ma part j'utilise l'auto increment pour mes id chose qui m'avait été conseillé pour éviter que le système s'emballe lors de l'inscription de plusieurs joueurs à la fois mais j'ai peur que ça me pète entre les doigts ^^

[didawin]

Bonjour,
j'aimerais récolter un peu d'informations concernant la procédure d'inscription sur vos sites.
Quand pour un nouveau joueur vous devez le renseigner sur plusieurs tables différentes vous vous y prenez comment ?
Du style pour un nouveau joueur, vous devez le faire rentrer sur la table A,B,C
Pour ma part j'utilise l'auto increment pour mes id chose qui m'avait été conseillé pour éviter que le système s'emballe lors de l'inscription de plusieurs joueurs à la fois mais j'ai peur que ça me pète entre les doigts ^^

Voila ma manière de faire (qui n'est peut être pas la meilleure, mais elle fonctionne ):

J'ai par exemple une table user (liste les joueurs) et une table qui liste TOUTES les stats de tout les objets de mon jeu (un objet étant ici, un monstre, un joueur, une arme, un item, etc..).
Le joueur doit donc exister dans la table user et dans la table de stat afin d'avoir des points d'attaques/défence,etc....)

J'ai construit ma table user comme cela :
ID,username,password,......
Ici l'ID est en autoIncrement, ce seras l'ID utiliser partout pour lier le joueur.

Sur ma table de stat j'ai :
ID, ENTITY_ID, ENTITY_TYPE.
ID est en autoIncrement, il ne sert pas fonctionnellement dans le jeu. Il est ici uniquement pour respecter l'index unique. (Un objet ne peut avoir qu'une seule valeur pour une stat).
ENTITY_ID reprend ici l'ID de la table user (si on parle d'une stat, ce champs reprendrais l'ID de la table stat, et ainsi de suite)
ENTITY_TYPE détermine s'il s'agit d'un joueur,objet,arme,etc....

Ce qui veux dire que si un nouveau joueur est créée, j'insert la ligne dans ma table user. Je récupère l'ID généré et je l'insert dans toutes mes tables ou le joueur doit être référencé. (ce qui veux dire que je ne tient pas compte du champ ID autoIncrement des autres tables)

Donc pour conclure, de base, le champ ID de toutes mes tables sont en autoIncrement. l'ID des tables de fait (user,monstre,etc...) sert de référence, c'est ce ID qu'on utilise partout. l'ID des tables de dimension (stat, position, inventaire,...) servent de contrainte pour l'index unique.

Je ne sait pas si j'ai était assez clair ou si ça répond à ta question, n'hésite pas à me dire si tu veux plus d'infos

[Thêta Tau Tau]

Pour ma part j'utilise l'auto increment pour mes id chose qui m'avait été conseillé pour éviter que le système s'emballe lors de l'inscription de plusieurs joueurs à la fois mais j'ai peur que ça me pète entre les doigts ^^

Oui, c'est un bon conseil, parce que faire l'increment dans php (en plus de ne servir à rien d'autre que de faire une requête en plus) risque de faire échouer l'insertion si deux joueurs s'inscrivent en même temps, donc autant laisser la bdd gérer ce genre de choses.

Après, on peut aussi utiliser des strings aléatoires comme id (regarde par exemple les url de youtube), ce qui est notamment très utile pour les gros sites dont la bdd est distribuée et où il aurait fallu synchroniser l'autoincrement entre plusieurs serveurs et/ou pour éviter qu'un bot ne parcoure l'intégralité d'un site en incrémentant une id dans une url. Mais bon je ne pense pas qu'on ait ce genre de problèmes dans un jeu web.


Sinon, j'envisage pour mon jeu de séparer compte utilisateur (email, mot de passe, id utilisée sur le forum et dans la messagerie...) et compte de jeu (id utilisée dans le jeu +  d'autres trucs). Avec une relation n-n entre les deux tables, ça permet qu'un joueur ait plusieurs comptes de jeu (par exemple sur plusieurs "serveurs") et qu'un compte puisse être accédé par plusieurs joueurs (babysitting de compte par exemple).


@didawin: Je ne comprends pas trop l'intérêt de ta table "stats". Certes ça marche comme ça, mais qu'est ce qu'on y gagne par rapport à l'utilisation de l'id du joueur directement?

[didawin]

@didawin: Je ne comprends pas trop l'intérêt de ta table "stats". Certes ça marche comme ça, mais qu'est ce qu'on y gagne par rapport à l'utilisation de l'id du joueur directement?

Enfaite, dans ma table que j'appelle ici STATS, je n'ai pas uniquement des stats de joueurs  mais aussi d'items,arme,monstre,etc...
La colonne ENTITY_ID est remplie par les ID (auto-incrémenté) des tables de référence (ref_joueur,ref_monstre,ref_item,etc...)
en utilisant l'ID cela me permet par une seule fonction php commune pour tous mes objets de récupérer les stats que je veux.

l’intérêt n'est pas vraiment sur l'utilisation de l'id du joueur directement, l'intérêt est d'utiliser la même logique sur mes différents objets, cette table utilise donc 1 seul champ (ID) commun à tous et implémenté de la même façon, ça évite de construire une requête pour chaque objet (cherche l'attaque d'un joueur, l'attaque du monstre etc...  ).
Une simple recherche sur PEUT_IMPORTE.ID = STATS.ID me récupère la stat de PEU_IMPORTE.

[xanthius]

Bon je vois qu'on utilise à peu près le même système j'espère que ça ne se cassera pas la gueule ^^
car si une ligne foire tout part en cacahuète

[didawin]

Bon je vois qu'on utilise à peu près le même système j'espère que ça ne se cassera pas la gueule ^^
car si une ligne foire tout part en cacahuète

Je ne comprend pas :/
si une ligne foire -> que veut tu dire par la ?
tout part en cacahuète -> qu'entend tu par "tout" ?

Je prend un exemple pour illustrer ma vision :
Admettons que je supprime une ligne de la table des joueurs, aucun problème pour les autres joueurs puisque la relation se fait sur leurs ID.
Si je supprime une ligne de la table des stats, un seul joueur seras affecté (celui qui est lié à cette ligne par son ID). Les autres ne seront pas affecté puisque je n'utilise pas l'ID auto-incrémenté, il n'y auras pas de décalage

[xanthius]

En gros quand un joueur s'inscrit je ne fais qu'une insertion dans les tables, je ne m'occupe pas de l'ID je laisse à la BDD cette gestion. D'où l'auto incrément.
Si par exemple dans les tables A, B, C on est à la ligne 18 et qu'un joueur vient à s'inscrit alors automatiquement il aura l'id 19 dans les tables A,B,C.
Quand je parle de la possibilité d'un plantage j'ai cette exemple en tête :
Dans ma BDD, les tables qui seront utilisées pour l'inscription sont à la ligne 20, toi et moi nous nous inscrivons sur le jeu pratiquement au même moment, dans les conditions normales tu devrais avoir l'id 21 sur toutes les tables (A,B,C) et moi l'id 22 ou inversement mais imaginons un instant que le système pour une raison x ou y s'emballent
... ...
Ah mais je viens de comprendre .. ça peut pas s'emballer en fait fin si, si j'oubli de supprimer un champs dans une table et dans ce cas et dans cet unique cas, tout partira en cacahuète. Bref, Je n'ai rien dis ..

[didawin]

En gros quand un joueur s'inscrit je ne fais qu'une insertion dans les tables, je ne m'occupe pas de l'ID je laisse à la BDD cette gestion. D'où l'auto incrément.
Si par exemple dans les tables A, B, C on est à la ligne 18 et qu'un joueur vient à s'inscrit alors automatiquement il aura l'id 19 dans les tables A,B,C.
Quand je parle de la possibilité d'un plantage j'ai cette exemple en tête :
Dans ma BDD, les tables qui seront utilisées pour l'inscription sont à la ligne 20, toi et moi nous nous inscrivons sur le jeu pratiquement au même moment, dans les conditions normales tu devrais avoir l'id 21 sur toutes les tables (A,B,C) et moi l'id 22 ou inversement mais imaginons un instant que le système pour une raison x ou y s'emballent
... ...
Ah mais je viens de comprendre .. ça peut pas s'emballer en fait fin si, si j'oubli de supprimer un champs dans une table et dans ce cas et dans cet unique cas, tout partira en cacahuète. Bref, Je n'ai rien dis ..

C'est pour cela que dans ta table B et C, personnellement, je mettrais un champ supplémentaire qui servirait de référence à l'ID de la table A.
Ainsi, même si deux personnes s'inscrivent en même temps, je reprend ton exemple :
J'arrive avec l'ID 21 toi l'ID 22 dans la table A.
Ma connexion échoue, je n'ai pas eu le temps d'être inscrit sur les tables B et C (admettons).
On se retrouve avec cette structure si tu n'utilise que des ID auto-incrementé :

Table A:
ID  |  champ_1  |  champ_2
21  |  moi  |  foo
22  |  toi  |  foo

Table B:
ID  |  c1  |  c2
20  |  1  |  2
21  |  1  |  2

Je vois donc 2 problème :
Si ma connexion échoue, j'imagine que je reçois une erreur alors que je pourrais techniquement me connecté et avoir mes infos dans table B.
Toi par contre, tu n'auras aucune donnée dans table B...
Imagine un système de rpg ou le joueur choisis ça classe, je choisi mage tu choisi guerrier, on s'inscris en même temps, imagine ma frustration si en me connectant j'obtiens la classe guerrier lol

La méthode que j'utilise ferais la relation sur ENTITY_ID:

Table A:

ID  |  champ_1  |  champ_2
21  |  moi  |  foo
22  |  toi  |  foo

Table B:
ID  |  c1  |  c2  |  ENTITY_ID
20  |  1  |  2  |  20
21  |  1  |  2  |  22

Puisque même s'il y as un gap sur l'ID, l'entity_id pointeras sur l'ID de Table A.
Parceque si quelqu'un s'inscrit maintenant tu aurais :

Table A:

ID  |  champ_1  |  champ_2
21  |  moi  |  foo
22  |  toi  |  foo
22  |  inconnu|  foo

Table B:

ID  |  c1  |  c2  |  ENTITY_ID
20  |  1  |  2  |  20
21  |  1  |  2  |  22
22  |  1  |  2  |  23

[Xenos]

Sinon, j'envisage pour mon jeu de séparer compte utilisateur (email, mot de passe, id utilisée sur le forum et dans la messagerie...) et compte de jeu (id utilisée dans le jeu + d'autres trucs)

Pareil, car séparer la façon de se connecter et le compte de jeu offre de l'extensibilité.


T'as la notion de clef étrangère qui permet d'assurer, niveau BDD, que la valeur d'une colonne d'une ligne d'une table fait bien référence à la valeur d'une colonne d'une ligne d'une autre table.


Tu as aussi les transactions, pour éviter d'avoir des "bouts" de données sauvés (tu veux faire 3 requêtes et que les 3 marchent au aucune des 3).


L'auto-incrément est une facilité d'usage (on pourrait locker la table, récupérer le MAX(id)+1, insérer dans la table, le tout dans une transaction, mais c'est chiant: c'est pour illustrer). Il devient encore plus utile quand il porte sur plusieurs colonnes.


Et pour en revenir à la façon de faire, je ne sais plus sur Eclerd v0, mais je prévois (pour les autres projets): 1 table donnant les infos de connexion (mail, pass, login), 1 table des comptes de jeu (pseudo, nom du pays, etc) qui est référencée par la table de connexion (1-1 pour le moment, entrent en jeu les clef étrangères) et pour le moment, les stats, je m'en fiche. A l'inscription (via login & pass), création de l'entrée dans la table des comptes & création de l'entrée dans la table de connexion, le tout dans une transaction. Avec unicité sur le login et une sur le mail (& une sur le pseudo IG, une sur le nom de pays, etc)

---

J'arrive avec l'ID 21 toi l'ID 22 dans la table A.
Ma connexion échoue, je n'ai pas eu le temps d'être inscrit sur les tables B et C (admettons).

Ca, tu le règles en faisant des transactions: ne bricole pas un truc à ta sauce car cela ne marchera pas et sera impossible à maintenir. Le principe de la transaction est alors d'assurer que soit tout a été fait, soit rien n'a été touché.

[xanthius]

C'est cette histoire de coupure involontaire qui me fait peur..
Car tout est lié même si les données ne sont pas importantes. En gros s'il y a un écart de ligne entre les 3 tables tout foire toutes les tables doivent avoir le même nombre de ligne à un instant T ..
Donc ton concept serait une sécurité en soit, pour éviter tout dérapage dans la procédure..
Du coup, il faudrait faire quelque chose comme ça :
- Insertion de l'utilisateur dans la table A, utilisation de l'auto incrément.
- Connexion de l'utilisateur, on vérifie s'il est présent dans les tables B et C si ce n'est pas le cas on insert dans ces tables les lignes nécessaire. On utilise l'auto incrément pour l'ID de chacune des nouvelles lignes mais on y placera dans entity id, l'id du joueur provenant de la table A

c'est bien cela que tu préconise ?