Outils pour utilisateurs

Outils du site


code:orga

Organisation des codes et des données

il existe

  • sur le reseau une BD mondes ou tout les objets qui existent sont référencés
  • sur le reseau une BD géographique qui défini l'ensemble du ou des jeux en cours ( qui utilise les objets de BD monde )
  • locale une BD géographique , monde des faits , jeu en cours présente sur le joueur
  • locale une BD feuille de perso , carac etc et objets
  • locale une BD connaissance du perso ( c'est un peu aussi l'histoire, la culture du perso )
  • locale dupliquée au depart une BD de regles
  • locale puis sur le reseau des fichiers trace et log du systeme de jeu pour les MJ (ou par extraction, la communication inter-joueur)

différents modules en daemon:

  • ZOU :zou geolocalisation et declenchement d'evennement cartographiés immédiatement résolvables
    • interroge le GPS et le compas (OSC)
    • lit dans une base geo ( base locale )
    • filtre les données présentes
      • no de jeu correspondant ( on peut gerer plusieurs jeux)
      • destinataire ( le destinataire peut etre un groupe, un pnj , gérés aussi par la machine )
    • extrait un script
      • scripte pour le système (shell)
      • scripte pour le jeu, commandes MJ, maj PNJ et objets non joeur
      • événement pour le jouer
      • discute avec YAKA
    • trace pour Mouche (log systeme, historiques perso et traces au MJ)

Questions. faire la BD avec OpenStreetMap ou autre ? Informe6/7 ?

  • TOUÇA touça Base de données
  • YAKA yaka
    • gère les evenements pour jack et SONIC
    • ordonnance les ordres à SONIC
  • Chronos gére les actions temporelles mises en place ou non par Zou
    • se base sur cron et at
    • gere une priorité
    • scriptes
  • KOI koi résout l'action venant de Zou et de Chronos, il est déconnecté et autonome
  • interroge une BD de connaissance / règle et en déduit une action
  • maj perso
  • actionne un événement en le transmettant à ZOU
  • modifie quelque chose
  • TEKI teki charger des communications extérieures
  • routage et proxy des paquets OSC
  • établi les connexions entre les appli
  • Mouche(s) ( chacun pourrait avoir cette fonction de log )
    • trace et met en forme ce qui se passe
    • le poste au MJ
    • le stock en historique
  • Perso Gestion du personnage
    • gère une feuille de perso, interroge et la lit
      • carac
      • conpétences/historique
      • liste d'objet
    • gere une interaction
      • question et commande vocale? / boutons
        • action locale, modif param
        • action
  • VOX vox synthèse sonore
    • stream la voix avec certains param
    • envoi à TAKA l'odre d'ouvrir le stream
  • SONIC sonic , partie son et spatialisation, supercollider
    • écoute en OSC
    • reçoit les ordres de lecture sonore
      • à lire en directe , ambiance lointaine
      • à spatialiser
      • en synthèse vocale : vox
  • MANO interfaces les interfaces, boutons, afficheurs etc
    • ouvre ou ferme, gère des flux OSC
    • connecte les interfaces aux flux
  • compas2OSC compas2OSC passe l'angle au N sur OSC
  • gps2OSC gps2OSC passe la position en OSC
  • lancement lance le jeu
    • position-init
    • jackd
  • position-init initialise gps et compas et lance compas2OSC.py et gps2OSC.py

Messages OSC

port 9001

  • /pos/gps/ latitude longitude altitude erreur
    • latitude décimale ex 47.271238
    • longitude décimale ex -2.212748
    • altitude en m
    • erreur en m (err latitude)
  • /pos/compas/“ angle (heading) en deg horaire au N

ex : dump_osc 9001

 /pos/gps/ ,fffd 47.2713851929 -2.21259832382 22 9.102
 /pos/compas ,i 109

Un objet sonore:

  • ID
  • type
    • fichier son à spacialiser une fois
    • son en déplacement
    • texte à causer entrée par stream / ou afficher
    • son directe sans spacialiser
  • priorité , kill eventuel
  • nom de fichier (mono)
  • volume relatif
  • position angulaire
  • distance ( si distance= -1 > lecture directe hors VBAP )
  • boucle de lecture 0=toujours
  • durée max
  • chemin? ( suite de position , vitesse de transition )
  • vox patch de synthèse vocale stream
    • nom du texte a lire
    • nom de la voix
    • paramètres de lecture ( mbrola ou picotts )
    • filtre ladspa supplémentaire
    • boucle
    • durée max

notes

recup http://wiki.enchevetres.org/ancien/doku.php?id=tek:organigrammeprog&s[]=personnage

cf aussi http://histoires.enchevetres.org/doku.php/ombres:mj:d_ombres_et_d_eau_1

Genre d'écriture qu'on pourrait implémenter pour décrire les situations

en x,y entrer dans une tres grande piece aux murs mates : un filtre d'écho sur des surfaces mates donnat l'impression d'une grande salle vide est chargé

en x,y Raoul LeBegue raconte en suivant : “ablablablabbalaba”, 2 fois , puis s'en va au nords doucement et dit “blblblll”, et fait corne_de_brune_batiste :

  • le texte “ablab…” est lu par la synthèse sonore avec un personnage défini ailleurs, (voix mbrola, vitesse, hauteur et filtre supplementaire ),
  • 2 fois.
  • Il est normalement à coté de façon fixe, posé dans l'espace, mais suit le joueur.
  • Puis le meme perso,
    • en écoute posé au sol, se deplace vers le nord
    • et en lisant le texte “blibl..”
    • et le scripte corne_de_brune_batiste est déclenché

à 15h12 si souffle_de_Jean.inventaire alors Cloches_bleu au loin et execute script1.souffle_de_Jean + en x2, y si Abeille_Jaune2.inventaire alors carac2.Joueur=-1 et entendre Abeille_petite tourne 0 pendant 10 hasard,hasard avec filtre_passe_bas 5,3 :

  • le progamme chronos(cron ici) à déclenche le scripte, test de la presence dans le fichier invenaire de Abeille_Jaune2,
  • si oui, le programme Perso met a jour une carac, ce qui entraine peut etre une action,
  • et le son Abeille_petite est lu par Sonneur, il crée une instance de lecture avec les parametres donnés.

Brouillonage (dans la vase)

Codage avec une base de fait

en supplément du déclenchement directe d’événement autonome, on peut définir des faits exploitables. Cela permet de définir des PNJ légés, (ce ne sont pas des programmes)

  • rue-du-bac = x,y;x1,y1;… suite de positions ( ou de noeud cf OSM ?)
  • promenade-de-Marcel-22 = x,y;x1,y1;…
  • à 15h Marcel-22 bouge sur promenade-de-Marcel-22 a 10 min, rencontre forte
    • a 15 le perso Marcel-22 commence sur le chemin promenade-de-Marcel-22
    • il avance de 10 m en 10 min ( en tenant compte du chemin promenade-de-Marcel-22 )
    • la probabilité de le croiser est forte (4/5)
      • une rencontre se fait a 10 min et a 10 m prêt

delcenchement a partir de l'heure ou du croisement du chemin ?

langages MJ(Prise en main FLEX/BISON)

Zoulang:

un parser bison + un scanner flex (tout dans le namespace Zoulang): C'est dans ce langage qu'on fait la description de scenes (je commence a faire ça):

  • “Jouer SYMBOL” (ou SYMBOL est un symbole référencé dans MJlang (fichier ou patch ou parole))
  • “attendre TEMPS”
  • “si QUELQUE_CHOSE alors AUTRE_CHOSE”

2 modes de fonctionnements :

  • normal : c'est lié statiquement a zou et utilisé par lui dans ce mode.
  • test : c'est utilisé pas MJlang (en dessous) quand c'est une description de scène qu'on lui passe

MJlang:

un parser bison + un scanner flex (tout dans le namespace MJlang) : C'est dans ce langage que le MJ travail, ça range dans la BDD les objets, en collant verbatim les scènes qui seront interpretés par zou (mais ce qui peut être testé l'est : références a des symboles existants, grammaire correcte).

  • SYMBOL est zone : \[(x1,y1);(x2,y2);(x3,y3)\]. SYMBOL.SYMBOL.SYMBOL. (les 3 derniers symboles sont des scènes)
  • SYMBOL est une scene : { <les actions (voir Zoulang)> }.
  • SYMBOL est un fichier sonore.

Les Makefile.am et le configure.ac sont à regarder. (marchent)

Quand on voudra une grammaire plus riche il faudra transformer celle de zoulang en parser de “bytecode” et augmenter le boulot de MJlang. Je fais comme ça pour l'instant parce que c'est plus straightforward.

EDIT: Les 2 parseurs sont maintenant en mode C++, ce sont donc des parseurs réentrant : 2 triplets Scanner-Driver-Parser. L'ensemble Zou compile avec make (en ayant au préalable autoreconf -if && ./configure). Y'a plus qu'à faire la gestion/récupération d'erreurs de syntaxes et tester/augmenter les actions. Plusieurs classes sont déjà définies. Ces classes dépendent de la classe Brique correspondante(dans Zoulang ou MJlang, les 2 dossiers des deux parseurs). Brique à une méthode virtuelle string compile(). C'est cette méthode qu'il faut implémenter pour effectuer les actions. Les différentes classes sont des classes composites. Un symbole plus général du langage contient des symboles/tokens plus particuliers et le plus générale effectue les actions (envoi osc, …).

mjlang

zoulang

code/orga.txt · Dernière modification : 2024/02/09 16:26 de 127.0.0.1