facebook-sporz
twitter-sporz
google+-sporz
logo-sporz

Structure des tables


Les clés primaires et le numero de partie est implicite pour chaque table

table PERSOS - liste les persos des parties de Spel
  1. noperso (clé primaire)
  2. partie (clé externe)
  3. etat (mutant ou non ou autre (si si les mutants passaif ça existe :p))
  4. genome
  5. vivant (booléen)
  6. ID_local, pour gérer les sets de l'historique
  7. divers rp (nom, description, sexe, role, ...)

table ACT_PROG - (anc. ACT_PERSO) (action programmée) liste les actions qui devront être effectuées
  1. id_act_prog, id
  2. type_daction (peut etre utile)
  3. liste_auteur (la liste des auteurs de cet action)[type SET]
  4. qui_decide (indique si le résultat de l'action doit être l'issue d'un vote ou de la décision personnel d'un joueur, ou devra être fixé par l'exécution d'une autre action(rempl bloquée))
  5. ce_qui_a_été_décidé (pointe vers l'identifiant de la table ACT_CHOIX cf plus bas) "rien" sinon
  6. phase ,phase de la nuit à laquelle l'action a lieu
  7. nuit , prochaine nuit où devra être exécuté l'action (permet surtout de savoir si on a déjà traité l'action ou non)
  8. raison, indique si c'est une action que le perso doit à son rôle ou à autre chose, comme son état, le fait qu'il porte un mouchard, de manière exceptionnelle, ... (a priori type enuméré) [pourquoi pas]

table ACT_CHOIX - liste les différentes possibilités pour une action programmée et dans le cas où elle a été choisie indique qui a été choisi et ce qu'il faut faire en général
  1. id_act_choix
  2. act_prog_ref , indique à quel action programmée elle réfère
  3. code_a_appeler indique le nom de la fonction à appeler pour traiter cette action, si l'action est spéciale on aura uen fonction qui fait rien
  4. type_de_menu, a priori soit une liste des joueurs vivants soit rien, mais il pourraient y avoir d'autres choses.
  5. choix_cible est rempli si cette action a été choisie par l'id de la cible vide sinon.
  6. message champs relatif aux différents messages (1 pour la phrase dans le menu des actions à faire 3 pour l'historique voir plus bas)type entier pointant vers une table de vocabulaire ou géré à la volée.
  7. action_vu_par (indique qui voit l'action: cible, tous le monde ...)
  8. auteur_vu_par (indique qui voit les auteurs de l'action: cible, tous le monde ...)
  9. cible_vu_par
  10. résultat_vu_par (indique qui voit le résultat de l'action: auteur, cible, tous le monde ...)
  11. espionnable,paralysable,... un champ de type set permet d'avoir 32 paramètres :)
  12. choix_possible_de_nouveau_des_la nuit_n (permet une implémentation du hacker: s'il choisi hacker le psy, le prochaine fois qu'il pourra avoir ce choix sera la nuit n, n s'incrémentant à chaque exécution de l'action)
#les derniers champs permettent de ne coder qu'un role et avoir toutes les varaiantes, le code du psy est juste de mettre l'état dans le résultat, ici on décide si la cible est au courant, si le psy est espionnable...



table HISTORIQUE - est le retour de l'éxécution d'une action comme avant quoi

  1. action (clé externe)
  2. auteurs (set of ID_local de PERSOS)
  3. cible une seule car il y aura toujours des résultats différents pour chaque cible
  4. jour (ou nuit) auquel a eu lieu l'action (int)
  5. phase (histoire que d'éviter des embrouilles)
  6. resultat : le résultat de l'action en question très souple pour accepter n'importe quoi
  7. qui_voit_l'action : indique l'ENSEMBLE DES JOUEURS qui voient l'action (à l'inverse de ACT_CHOIX) (c'est le OU des 3 suivantes donc pas forcément utile)
  8. qui_voit_auteur idem
  9. qui_voit_cible idem
  10. qui_voit_resultat idem
  11. 3 choix pour savoir quoi dire pour l'auteur, la cible, autre (pas la peine de mettre le texte entier qui sera toujours le même juste un entier vers une table de vocabulaire ou géré à la volée).

table VOTES
...

tables suffrages
...

FONCTIONS


Afficher_actions_nocturnes($joueur)-> void
  • récupérer la liste des actions à faire :
  • select raison, type_de menu, act_prog from ACT_CHOIX join ACT_PROG on act_prog_ref= id_act_prog where ce_qui_e_été_décidé = rien and nuit = $nuit and phase >= $phase and qui_decide = $joueur
  • récupérer les votes en cours
  • ...
  • trier le tout par phase
  • pour chaque action ou vote l'afficher (avec un bouton radio si c'est un choix ?)

Récupérer_une_action ($_POST,$joueur)-> void
  • vérifications de sécurité sql,
  • vérifier que la demande est correcte du point de vu du jeu:
    • select lstjoueur raison, type_de menu, act_prog from ACT_CHOIX join ACT_PROG on id_act_prog = act_prog_ref where act_prog=$action_demandée
  • insérer la décision
    • update ACT_PROG , ACT_CHOIX set ce_qui_a_ete_decide=$choixaction and choix_cible=$choixcible where id_act_choix = $choixaction
  • appeler deroule partie

Dérouler_partie(void) -> void est appelé dès que quelqu'un réalise une action

  • récupérer la liste des actions à éxécuter :
  • select * from ACT_PROG join ACT_CHOIX on id_act_choix = as ce_qui_a_été_décidé where nuit < $nuit and ce_qui_a_été_décidé != "rien" order by nuit, phase

  • foreach (lstactions as $paramaction)
    • appeler (code_a_appeler) avec la liste $paramaction récupérer le résultat
    • calculer avec auteur_vu_par, cible_vu_par,... les valeurs de qui_voit_...
    • inserer dans l'historique la ligne en question
    • réinitialiser les différents champs pour la prochaine nuit.

Afficher_historique($joueur)
  • récupere les lignes d'historique :
  • select * from historique where $joueur in_set qui_voit_l'action

  • pour chaque ligne
    • voir si le joueur est l'auteur, la cible ou autre
    • afficher le message correspondant.


Idées pour les actions spécifiques aux roles connus


paralyser: dans la table action_prog si qui décide est le joueur on fixe le champ à "imposé"
hacker: autant de choix d'action que de role hackable (initialisé en début de partie)


Liste des fonctions qui demanderont accès à la bdd:

-Afficher historique joueur :

Il faudrait que l'affichage de l'historique d'une joueur ne demande qu'une requête qui sélectionne toutes les lignes qui le concerne : a priori si un joueur est auteur d'un truc il est au courant qu'il a fait quelque chose. Par contre, on doit pouvoir facilement discerner les lignes où la cible doit être informé et celles où elle doit rien savoir.

-Afficher les menus d'actions la nuit

On peut définir des étapes de la nuit (dans laquelle il peut y avoir plusieurs actions parallèles). Pour toutes les étapes pas encore passées proposer d'enregistrer l'action. Il faudrait une table action qui dise pour chaque action à quelle étape elle est faite et par quels joueurs : il suffit alors de sélectionner les actions qui n'ont pas encore eu lieu et pour lesquels le joueur participe et de disposer des instruction quant aux menus à afficher. Une fois que l'utilisateur valide, n'agir que s'il s'agit d'une action de l'étape en cours. Tant qu'à faire, enregistrer la volonté du joueur dans cette même table d'action.
Envisager un tag : action verrouillée : le choix de l'action ne peut plus être décider par le joueur (par exemple la paralysie verrouille le choix d'un joueur sur inspecter personne idem si role volé).

-Traiter les actions des joueurs

Dès qu'une nouvelle action est validée, chercher à l'exécuter puis si toutes les actions de l'étape en cours vienne d'être éxécuté, éxécuter les actions de l'étape suivante et ainsi de suite jusqu'à faire lever le jour. Pour que le mj puisse bricoler entre deux étapes il suffit d'intercaler une action dont l'auteur est le mj.
  • Pour chaque action : Lire le type d'action, si c'est un type programmé éxécuter (inspection psy...) l'action qui en découle sinon insérer l'action dans l'historique s'il le faut (le type de l'action specifie si elle est inscrite dans l'historique ou non).
Exemple d'action a ne pas insérer : ouvrir un canal entre joueurs.

-Besoin spécifique de certaines actions :

  • Mutants : les mutants varient : dans la liste des actions toutes celles relatives aux mutants verront la liste des auteurs modifiés
  • Choix entre différentes actions : définir une seule action qui a deux comportement différent ?
  • Médecins : la liste d'action ne modifie pas les auteurs cependant l'historique précise bien qui sont les auteurs pour que le médecin paralysé ne sache pas se qu'à fait son collègue.
  • Psy,géné,info : simple
  • Espion: doit récupérer la liste des choses qui est arrivé à un joueur (mais pas forcément tout) tag espionnable pour chaque action ?
  • Hacker : peut hacker plusieurs roles : pour chaque action définir si elle peut être hacké et à quelle fréquence ?

Remarques :
Le role d'un joueur semble inutile pour le moteur du jeu : on doit pouvoir définir tous aux travers de qui fait quoi comme action (et ça permet à un joueur d'avoir plusieurs roles).
Envisager de considérer les votes de jours comme des actions collectives : permettrait de faire des parties sans mj dans les périodes creuse : si tout le monde a voté l'étape est validé et on fait tomber la nuit. L'action des mutants et des médecins pourraient aussi être un vote. On aurait des actions de type vote publique à la majorité, vote publique à l'unanimité (pour la décision des mutants), vote privé à la majorité.


Commentaires

Je trouve que mettre dans un champ une syntaxe spécifique genre ab(c|d)e risque de générer du code moche surtout que c'est généralement évitable : pour les actions simultanée par exemple (psy et géné par ex.), il suffit que chaque action ait un numéro d'étape et deux actions ont le même si elles sont à la même étape. Pour le choix des actions, on peut mettre deux champ au lieu d'un : au lieu d'une action 'muter' et une 'tuer' avoir une action 'muter/tuer' 'muter' et 'muter/tuer' 'tuer'. Le champ 'muter/tuer' est lu quand il s'agit de proposer l'interface au joueur le champ 'muter' ou 'tuer' est lu quand il s'agit de traiter l'action et aura été rempli par le perso quand il aura enregistré son action.
Je considère que pour savoir ce que doit faire un joueur la nuit, il est plus simple d'aller lire dans la table action toutes les actions qu'il peut faire plutôt que d'aller lire dans la table joueur qui soit aura une syntaxe spécifique soit un nombre limité d'action.
select * from table_actions where $auteur in set lstauteurs and etapenuit >= $etapeactuelle
Une requête de ce type permet d'avoir la liste de toutes les actions que doit faire un perso à un moment donné de la nuit.


 en haut


All content is © 2011 Editions Ladonzelle. May not be reproduced without permission.
--| Contacts - Associations - Distribution - Crédits |--