wiki:InsiaProgPerlProjetBomberStep3

Projet Perl Bomberman

Projet Perl - Bomberman réseau

Réalisation (3) - Protocole réseau

Ressources:

Principe du jeu en réseau

Quand un jeu fait intervenir plusieurs participant via le réseau, il faut désigner un arbitre. Il s'agit en général d'une machine dédiée, le "serveur". Cela veut dire qu'aucun client ne peut prendre de décision sans en demander la permission au serveur, cela concerne en particulier les mouvements autorisés !

En pratique, cela veut dire que le "client" se transforme en simple terminal graphique:

  • Tous les événements claviers sont interprétés en tant que commande (aller à gauche, poser une bombe) et immédiatement envoyés au serveur
  • Tous les éléments d'affichage (mises à jour) sont envoyées par le serveur: déplacer tel joueur (y compris le client lui-même), déclencher une explosion, etc.

D'un point de vue technique, cela veut dire qu'en plus des événements clavier, il va falloir traiter un nouveau type d'événement - dit réseau - pour réagir dès que le serveur nous envoie des informations.

Notez que pendant le jeu la communication est totalement asynchrone: les évenements de sortie (envoie d'action vers le serveur) et d'entrée (réception d'ordre du serveur) ont lieu de manière indépendante. Cependant lors de l'initialisation, pour des raisons de simplicité, nous resterons synchrone (simple ping-pong entre le client et le serveur).

Programmation du protocole

Pour concevoir un protocole réseau, le plus simple est de se baser sur la façon d'un humain (comprendre "administrateur système"!) communique avec une machine. C'est à dire un ordre ou une information par ligne, en général en anglais et suffisamment explicite. Ainsi la programmation et le débogage se font naturellement.

Nous utiliserons le protocole de transport TCP, celui-ci se prêtant bien à une utilisation en LAN où les conditions sont en générales bonnes (congestion, RTT). L'utilisation d'UDP est plus complexe car il faut programmer une logique d'arbitration plus sophistiquée prenant en compte le séquencement arbitraire et la non-vérification d'arrivée des paquets. Ceci n'est en général souhaitable que pour les jeux où l'arbitration demande une forte précision temporelle (shoot them'up).

En Perl, les accès au réseau se font comme avec un fichier (<> et print), donc nous pourrons tout naturellement lire ou écrire une ligne à l'aide des fonctions et opérateurs habituels. Seul l'établissement de la connexion demandera un (petit) effort supplémentaire.

Plaçons nous du point de vue du client. Pour simplifier le débogage, chaque message (émis par le client ou reçu du serveur) sera affiché sur la console en le préfixant par C ou S pour déterminer son origine. Exemple:

$server = new IO::Socket::INET(...);

sub send_to_server {
  my $msg = shift;
  print "C $msg\n";
  print $server "$msg\n";
}

sub receive_from_server {
  my $msg = <SERVER>;
  if (defined $msg) {
    chomp $msg;
    print "S $msg\n";
  }
  return $msg;
}

Note: pendant le jeu (hors initialisation donc) la méthode de lecture est dite en mode polling, c'est-à-dire qu'elle peut ne rien renvoyer (cad. qu'il n'y a pas de message reçu en attente de traitement). Ce cas est représenté par le retour d'une valeur indéfinie (undef).

Description du protocole

Une fois la connexion établie, c'est au client de démarrer la discussion (en rejoignant la partie).

Rejoindre une partie

Pour le moment nous considérons qu'il y a une seule partie globale, donc nous parlerons de "la partie":

  • le client doit envoyer le message JOIN <player name>
  • le serveur envoie une réponse JOIN-STATUS <OK | ERROR> <reason>
  • si l'entrée dans la partie est acceptée, le serveur envoie la configuration du niveau en diffusant le contenu au format "standard" (cf. source:/insia/perl/bomberman/level.txt) en préfixant chaque ligne avec LEVEL.
  • En fin de configuration, le serveur envoie le message LEVEL-DONE

Exemple:

C JOIN madmax
S JOIN-STATUS OK Welcome madmax
S LEVEL name BomberINSIA 1
S LEVEL width 20
S LEVEL height 14
S LEVEL row  ********************
S LEVEL row    *..................*
S LEVEL-DONE

Le reste de l'initialisation sera géré par les messages d'état des joueurs pour leur placement initial.

Position et état des joueurs

Afin que le client puisse positionner correctement les joueurs, y compris son propre avatar, il reçoit des informations de position et d'état du serveur qu'il doit immédiatement interpréter (comme s'il avait reçu un événement clavier):

  • PLAYER-STATUS <name> <UP|DOWN|LEFT|RIGHT> <col> <row>
  • PLAYER-KILL <name>

Exemple:

S PLAYER-STATUS madmax UP 4 11
S PLAYER-STATUS billy LEFT 7 10
S PLAYER-KILL billy

Note: il n'y a pas de message associé à l'apparition d'un joueur dans la partie, ceci étant simplement détecté par le client par son premier message PLAYER-STATUS.

Gestion des bombes

Il ya deux événément distincts signalés par le serveur, le premier pour annoncer qu'une bombe vient d'être posée (avec sa position), le second pour annoncer l'explosion d'une bombe existante:

  • BOMB-DROP <id> <col> <row>
  • BOMB-FIRE <id>

Les bombes sont identifiées par un simple numéro (id) que le serveur choisit arbitrairement. Exemple:

S BOMB-DROP 33 5 11
...
S BOMB-FIRE 33
S PLAYER-KILL padbol
S PLAYER-KILL madmax

Gestion de la destruction des briques

Les éléments de type "brique" peuvent être détruits par l'explosion des bombes. Dans ce cas, le serveur annonce quelles briques sont détruites, et les clients doivent modifier leur représentation du plateau de jeu en remplaçant les briques "cassées" par un élément de "sol". Le message serveur est:

  • BRICK-BREAK <col> <row>

Exemple:

S BOMB-FIRE 42
S BRICK-BREAK 10 6
S BRICK-BREAK 10 7

Gestion de l'entrée client

Le client envoie de simple intentions concernant son joueur: se déplacer, poser une bombe. Si le serveur décide que ces ordres sont acceptables, il renverra les messages PLAYER-STATUS ou BOMB-DROP appropriés. Les messages possibles sont donc:

  • MOVE <UP|DOWN|LEFT|RIGHT>
  • BOMB-DROP

Exemple (où tous les mouvements et le dépot de bombes sont autorisés):

C MOVE LEFT
S PLAYER-STATUS madmax LEFT 5 6
C MOVE UP
S PLAYER-STATUS madmax UP 5 5
C BOMB-DROP
S BOMB-DROP 34 5 5

Note: nous ne gérons qu'un joueur par client, donc le serveur sait déjà quel est notre nom quand nous envoyons nos intentions.

Last modified 13 years ago Last modified on Apr 27, 2007, 12:10:59 AM