organisation programmes

De façon générale, des scripts python font le moteur du jeu.

• des objets PD sont dynamiquement chargés, lieu, évènements etc
  • chaque patch sert un son en tant qu'objet parmi le tout
  • les objets ont une durée de vie, une priorité, …
  • le moteur veille sur la file d'exécution

L'ensemble des sons est mixés à travers un serveur de son jackd

A la mise sous tension, la machine joueur

• répertorie et initialise ses interfaces
• se connecte au serveur de jeu et télécharge les données des fichiers base de jeu:
  • cartographie
  • scénario
  • objets de l'histoire
• lance le moteur de jeu
• fabrique le fichier d'évènements proches

• programme général
  • lit dans un fichier d'évènements local, synchronise si connexion possible
  • scrute la position
  • ajoute/enlève des objets du fichier d'évènements proches en fonction de la position
    • tient a jour la file d'action en fonction de la position/sensibilité/état : zone d'action
    • lance l'exécution si besoin des scripts/objets autonomes actionnables
    • gère l'initiative cyborg/PNJs si existe
  • communique avec les scripts PNJ et le MJ pour exécuter des actions supplémentaires
  • tient à jour les paramètres venant des autres canaux de communications ,verbales,chat …
  • partie programme du Cyborg & PNJ(s), parties PNJ ordonnancé par la priorité, le temps, la charge machine
    • gère feuille de personnage
    • calcule des interactions en fonction de la file des actions et position
      • sons et commentaires
      • affichages , senseurs, modif événement en cours
    • trace un historique

Tous les objets du jeu sont stockés dans cette base, le scénario et le MJ en extraient ceux nécessaires pour les mettre dans le fichier des balises à l'initialisation.

Les fichiers balises, scripts, actions, sont des fichiers à plat. Le tout forme une arborescence dépendante du jeu, ce système de fichier donne l'état du jeu à un moment t. On peut la copier, s'y synchroniser, l'archiver, la commenter pour en faire de nouveaux scénarios, de nouvelles histoires racontées.

L'ensemble est stocké sur un serveur de jeu, qui peut être local pour servir une zone de jeu WIFI par exemple.

Extrait du serveur de cartographie OSM, c'est la carte à plat (xml) qui sert aux moteurs de jeu en action.C'est un fond de carte d'objets usuels en principe statiques n'intervenant que comme décor.

C'est un fichier fabriqué pour le suivi immédiat du jeu, Il contient toutes les balises connues à leur position du moment.

Des exemples d'événements.

1. ID
2. Nom
3. Caractéristiques modifiables
4. Date de naissance
5. Durée de vie
6. Actif/Passif
7. Gestion de l'activation (1 fois, jour/nuit, tant que ressource disponible, …)
8. Zone d'action (en mètre, possibilité à 0)
9. Mode de déclenchement (création, contact, …)
10. Action générée (un script est appelé)
11. Type de ressource (Lumière, Terre, Feu, Eau, …)
12. Force de la ressource (1 à …)
13. Accélération de la ressource (= transférabilité, de -255 à +255 en passant par 0)

Fichier des balises (objets du jeu)

1. ID
2. label
3. coordonnées GPS + zone d'action (= distance de sensibilité)
4. description ( type,famille,nom )
5. volume normale
6. actif O/N
7. nom du fichier d'action à exécuter
8. type : PNJ,objet simple, objet complexe

Fichier des actions

1. ID
2. label
3. coordonnées (zone où agit l'action)
4. description
5. utilisateur (jeu,root,mj)
6. priorité
7. duré de vie
8. script

Les scripts peuvent être

• du shell: administration de la machine
• du python: phases, actions de jeu
• puredata: pour l'interaction et l'évènementiel

Fichiers visibles sur le gitorious des espaces enchevêtrés

Reste à définir les actions…