Modelisation - joueur/modérateur/admin

[Air]

Bonjour à tous,

Je réfléchis depuis quelques semaines à la conception d'un jeu.
J'en suis au tout début.
Je décris actuellement les principes de base du jeu.

Ce jeu serais une sorte de RPG en mode texte/action dans un univers futuriste. Le joueur pourrait effectuer de multiples actions (choisir un métier, concevoir des vaisseaux spatiaux, se marier pour avoir un héritier, etc...)
Je prévois l'existence de modérateur pour gérer l'ambiance, pouvoir lancer des missions.

Je pose donc la question de la meilleure modélisation pour les joueurs/modo/admin
Serait-il mieux d'avoir tout le monde dans la table en sachant que tout ces acteurs ont les mêmes attributs ou est-il préférable d'avoir 2/3 tables ?

Derrière ça tire le fonctionnement de l'authentification. Une page unique d'authentification quelques soient l'acteurs avec redirection vers la page selon le profil.
Ou deux authentifications. Une page d'authentification pour les joueurs et une autre authentification pour modo et admin ?

J'aimerais avoir votre avis sur cette question et vos partiques.

Merci d'avance.

[Xenos]

Salut,
deux authentification, c'est chiant à utiliser pour un joueur. C'est éventuellement justifié dans le cas d'appli critiques, mais là, ça va juste rebuter les gens. Le plus simple (me semble-t-il, c'est ma solution) est d'avoir une table de comptes avec la liste des droits/rôles. Soit 1 colonne ENUM('joueur', 'modo', 'admin' (ça me semble suffisant dans ton cas) soit 1 colonne par droit (can_play can_start_game, can_admin_stuff, etc), ça permet plus de combinaisons (ie: je peux admin le backend du jeu mais pas lancer de partie) mais je n'ai pas l'impression que cela te soit utile actuellement.

Sur Iamanoc, j'ai fait la gestion de droit par le biais de colonnes booléenne: can_* indique si un joueur ou un personnage (un joueur peut avoir plusieurs personnages) peut faire telle ou telle action. C'est tout simple à gérer et utiliser. Je ne me suis pas fait ch*er à créer plusieurs pages pour "modérer" un élément. Par exemple, les sales de RP peuvent être modérées par certains personnages (ceux qui ont can_moderate pour cette room). Dans ce cas, un lien vers une page d'ajout/suppression de personnages apparait dans la roleplay room et permet d'ajouter/retirer des personnages.

Je pense pas que tu ais à faire de redirection vers une page de profil pour chaque "type" de joueur: la page de gestion de son compte (email, pass, pseudo, etc) est accessible à tous (joueur, modo, admin). Certaines autres pages ne sont accessibles qu'à certains. Donc, un simple lien vers ces pages suffit (& quand t'affiches/traites cette page, n'oublies pas de vérifier que l'utilisateur a bien les droits associés; ie: ne fait pas juste "j'affiche le lien si t'es modo et une fois sur la page de modo, je ne vérifie pas que tu l'es").

[Keltaïnen]

Salut Air,

Ça dépend si les droits se cumulent d'un niveau à l'autre (i.e. le modérateur aura-t-il tous les droits d'un joueur).
Si oui, alors 1 colonne ENUM (ou TINYINT ça le fait aussi) résoudra ton soucis.
Si non je dirais qu'il faut les 3 colonnes de Xénos ou une table séparée si le nombre est amené à varier.

Dans ton cas je pense que tu as intérêt à avoir 1 table commune (quelque soit le niveau du joueur) ainsi qu'une authentification unique. Il vaut mieux que ce soit à toi de faire l'effort de gérer les niveaux de droit plutôt que tes joueurs.
Ensuite tu gère tes accès page par page pour savoir qui a accès à quoi. Ça vaut aussi pour la génération du menu s'il y en a un.

A mon avis c'est la façon la plus simple pour toi et la moins perturbante pour tes joueurs.

[Air]

Super les gars. Merci pour les conseils.
J'avais effectivement penser à avoir une colonne rôle dans la table mais pas une gestion plus fine des droits.
Pour le moment j'en ai pas un usage immédiat alors je vais me limiter au rôle.

Merci pour votre aide.

[Xenos]

Note: gaffe aux ENUM avec MySQL, car le réglage du serveur influe directement sur les valeurs autorisées. Je ne sais plus le nom de la variable de conf, mais si celle-ci n'est pas activée, alors l'ENUM contiendra la valeur vide ("") en cas d'insertion erronée. Ce qui peut mener à du if ($type == 'JOUEUR') { ... } else if ($type == 'MODO') { ...} else { ... }

Bon, ce serait sale comme check de rôle (mieux vaut faire un "else" renvoyant une exception), mais vu que c'est un soucis qu'on rencontre souvent au taff (insertion erronée qui se traduit par chaine vide dans la BDD), je préfère prévenir.

[Air]

J'ai oublié de poser une question en rapport avec la table membres.
J'ai des PNJ. Ces PNJ vont permettre de booster les caractéristique du joueur lorsque celui-ci lui sera rattaché.
Il sera possible d'incarner le PNJ lorsque la mort du personnage principal intervient.

Du coup, avec l'histoire des rôles, j'imagine toujours une seule table qui contient joueur/modo/admin/PNJ.
Les PNG aurait un rôle PNJ, jusqu'au moment de leur incarnation par joueur et du coup le personnage DCD aurait un rôle DEAD :-)

Qu'en pensez-vous ?

Autre question, vous utilisez quoi comme outil pour faire votre modèle de données ?

----
Je n'en suis pas encore au code :-) mais belle mise en garde.
Après c'est vrai que je ne suis pas un bon codeur. Je pense que j'aurais de nombreuses failles... je note l'insertion null. Merci

[Ter Rowan]

joueur différent de personnage donc pas une seule table qui mélange le tout
a partir du moment ou un joueur peut :
changer de personnage (peut importe la raison)
avoir plusieurs personnages en même temps
il faut séparer .

je dirais plutôt :

une table utilisateur

• id
  
• login,
  
• pwd, 
  
• M. / Mme.
  
• nom du joueur
  
• avatar du joueur
  
• ....
  
• role joueur (o/n)
  
• role admin (o/n)
  
• role modo (o/n)
  
• etc...
  

si trop de roles alors faire une table

• utilisateur.id
  
• role
  

une table personnage

• nom du personnage
  
• avatar
  
• age du personnage
  
• sexe du personnage
  
• ....
  

après tu peux aussi découper ta table personnage en deux PJ versus PNJ c 'est a voir, y a des points communs, mais pas forcément
et tu peux aussi avoir des tables dépendantes (ex : caractéristique de personnage, plutôt que d'avoir des colonnes dans la table personnage)

[Keltaïnen]

Pas grand chose à ajouter à Ter Rowan, c'est clair.

Vu que ton PNJ semble devenir un personnage, ça peut être la même table (toujours sur le modèle de Ter Rowan) OU une table différente avec une conversion au moment de l' "incarnation". Ca dépend si tu veux définir à l'avance ses caractéristiques qui aura à l'incarnation ou choisir à ce moment là.

PS : tout les autodidactes ont été des mauvais codeurs à un moment donné. Tant que tu sais te remettre en question et prendre ce qui il y a de bien chez les autres, tu ne pourras que devenir bon ;-)
(il y aussi une notion de "style" de développement mais c'est une autre histoire)