Salut, Avant-propos : ce gros email présente les résultats d'un brain-storming avec Damien sur Boombastic, et en seconde partie j'expose le premier jet que j'ai écrit.
---
Après une mure réflexion sur Boombastic avec Damien ce week-end, nous
avons réussi à nous mettre d'accord sur plusieurs points sur la
conception de cette réécriture de Wormux.
server, input & view
====================
Bon, là c'est moi qui insiste lourdement. C'est surtout pour rendre
l'intégration du réseau dans le jeu quasiment transparente.
Le jeu sera découpé en trois parties : server, input et view. Bon, je
pense qu'une vue sera toujours associée à une gestion des entrées. Mais
on pourrait aussi imaginer une vue "spectateur" pour visionner une
partie sur grand écran ;-) (lors d'un tournoi mondial à New York bien
sûr)
Les parties communiquent de cette manière :
input -> server
server -> view
Bon, server va aussi envoyer quelques infos à input, comme l'état du jeu
pour déterminer quelles sont les entrées acceptées. Mais ça reste
vraiment très léger comme communication. En codant, j'ai réalisé que le
plus simple est d'utiliser deux ports différents pour vraiment séparer
les deux types de canaux de transmission (4000 pour view et 4001 pour
input par exemple).
J'ai codé ce modèle, et je trouve qu'il fonctionne plutôt bien.
L'avantage est aussi qu'on peut fixer la vitesse à laquelle chaque
partie va s'exécuter (input : 20 Hz, server : 100 Hz, view : 50 Hz, par
exemple).
Note: Dans le cas où les trois parties sont exécutées en local, des
sockets locales (Unix) sont utilisées. Selon Damien, ça va très vite, il
n'y a aucun soucis à se faire.
Découpage par agents (SMA)
==========================
SMA, Système Multi-Agents
Damien ayant découvert un concept très intéressant durant un de ses
derniers cours, il veut absolument le réutiliser :-D (je te taquine
Damien) En fait, ce que j'avais en tête se raproche pas mal du concept
des agents. Pour faire simple, un agent est un tout petit morceau du jeu
qui gêre un point bien précis (exemples : un personnage, une arme,
l'état du jeu actuel, une équipe, etc.). Un agent est aveugle (un
personnage ne saura même pas qu'il appartient à une équipe !).
Par contre, le point crucial est justement la communication entre les
agents. Ils peuvent s'échanger des "messages".
Exemple (1) : quand on presse la touche TAB, l'agent Equipe va envoyer
deux messages, l'un pour désactiver le perso actif, et un autre pour
activer le personnage suivant.
Exemple (2) : lorsqu'une arme explose, le message "explosion" sera
envoyé à tous les personnages (qui perdront peut-être des points de vie)
et au terrain (qui creuse un trou).
Le truc GENIAL, c'est que ce système est très souple. Pour reprendre
l'exemple (2), si l'on décide d'ajouter le bruit d'une explosion : et
bien le système sonore n'a plus qu'à dire "hey, moi aussi je veux
recevoir le message explosion !". Et lorsqu'il recevra ce message, il
s'occupera de jouer un effet sonore. Idem pour l'affichage qui pourra
ajouter une animation graphique supplémentaire. J'ai encore pensé à
plein de petites choses, comme des noix de cocos qui tombent d'un
palmier, des oiseaux qui s'envolent à cause du bruit, ...
Les agents sont vraiment très pratique pour écrire des joueurs
articifiels ou des éléments interactifs dans le jeu (ils proviennent de
recherches en intelligence artificielle).
---
Bon, là où je me tate encore, c'est pour envoyer un message à travers le
réseau. Le message "explosion" pourrait être *demandé* par le système
sonore par exemple. L'avantage est que le serveur ne sait même pas que
le jeu peut mettre des effets sonores ! Le soucis étant qu'il faut faire
passer le message par le réseau. Il faut alors soit le transformer entre
temps, soit garder un système multi-agents (SMA) à l'autre bout. J'ai
opté pour la seconde solution (deux SMA : un sur le serveur, un chez le
client) pour l'instant. Mais j'ai peur que ce soit trop lourd. Bon, les
messages n'iraient que dans le sens serveur -> vue. Ce qui limite déjà
pas mal les communications.
Serveur centralisé
==================
Ce que je n'ai pas dit, c'est qu'en fait c'est un serveur unique qui va
faire tous les calculs. L'avantage est qu'un client Boombastic sera très
léger (je parle d'un client qui n'a pas de serveur sur le même PC), car
il se contentera de dessiner des sprites à l'écran. L'autre avantage est
que l'on n'a pas à se soucier des problèmes de synchronisation
temporelle, car il y a un seul serveur de temps (et non pas comme dans
Wormux où chaque instance du jeu a son horloge -> ce qui m'a bloqué).
J'ai discuté avec un mec sur #pygame, et il m'a dit que son jeu
fonctionne comme ça, et que ça ne pose aucun problème.
------------------------------------------------------------------------
Je met en pièce jointe un premier jet de Boombastic. C'est un brouillon
pour voir si le découpage en trois parties a un sens, et si le système
multi-agent est pratique ou non.
Le système est fonctionnel (par le réseau en plus), mais ne comporte que
trois agents sur le serveur : un bot qui s'amuse à générer des nombres
aléatoire, un compteur modifiable au clavier, et un agent qui gêre
l'état du jeu (en fait il ne sert ici qu'à arrêter le serveur). La vue
est en mode console. Le truc sympa est que seul les agents pouvant être
représenté dans une vue sont vraiment créer. On peut imaginer un mode
"configuration légère" où une partie du décor est omise.
Bon, le gros défaut de la version actuelle, c'est qu'il faut lancer
trois programmes séparément (trois xterm), dans l'ordre :
1) python server.py
2) python view.py
3) python input.py
TODO (1) : view.py et input.py devraient être capable d'attendre le
serveur s'il n'est pas prêt.
TODO (2) : le serveur devrait supporter l'absence d'entrée et/ou de de
vue, mais également supporter plusieurs entrées / vues simultanées.
Le serveur ne reconnait que trois commandes : "+" (augmenter le nombre
de l'agent), "-" (diminuer ce nombre) et "quit" (quitter le serveur).
Je me suis débrouillé pour que le serveur ferme la vue quand il quitte.
Désolé si le code est "cracra" à certains endroits, mais ce n'est qu'un
brouillon.
---
Voilà pour ce gros email qui intéressera, je l'espère, des curieux.
@+ Haypo
netdeux.tar.gz
Description: application/compressed-tar
