******************* * Men Are Ants * ******************* [ API ] Dernière modification: $Id$ Sommaire: 1) Principe du jeu 2) Protocole 3) Particularités des commandes de positions 4) Modes 5) PLS 6) Etat d'une partie 7) Intelligence Artificielle 8) Entités Conteneurs 9) Meta serveur 1) Principe du jeu 2) Protocole a) Client -> Server - Général IAM :je me présente LSP :lister les parties CRE :créé une partie JOI [|.] [$] :joindre une partie ('$' signifie "créer le chan") mettre '.' comme nom créé une mission STAT :request stats BYE :au revoir ADMIN [arg] :commande en temps qu'admin - Dans une pré-partie SET [params] :met un paramètre (voir section 4. Modes) JIA :Créé une IA (par l'owner) KICK [raison] :l'owner peut kicker LEA :partir GO! :l'owner lance le jeu MSG :envoie un message à tous les joueurs AMSG :envoie un message à ses alliés SMAP :envoie une map EOSMAP :fin du SMAP - En cours de jeu ARM [+] [%] :modifier le status d'une armée [/] [>] [^] [v] [<] [*] BP <+|-> [message] :rajoute un breakpoint sur la carte, montré uniquement à ses alliés SAVE :faire une sauvegarde (reception d'un fichier) b) Serveur -> Client - Général HEL :welcome AIM :confirmation du IAM MOTD :motd EOM :fin du motd STAT :stats sur le serveur LSP <+/-> :liste une partie [map] EOL :fin de la liste MAJ <+|-> :le client (ou le serveur) n'est pas à jour BYE [raison] :au revoir USED :pseudo déjà utilisé REJOIN :l'user est invité à rejoindre une partie à laquelle il a été déconnecté ADMIN :l'user est bien loggé comme admin - Dans une pré-partie ER1 :ne peut pas joindre ER2 :le pseudo de l'IA a déjà été pris ou il y a trop de monde ER3 :trop de connexions sur ce serveur ER4 :impossible de créer la partie car il y en a déjà trop PLS [...] :liste des joueurs (voir 5. PLS) LSM :envoie la liste des cartes EOMAP :fin de la liste des maps : JOI :un user join : SET :un user met un paramètre (voir section 4. Modes) : LEA :un user part (ou a été kické) : MSG :message reçue : KICK [raison] :un user est kické SMAP :envoie la map EOSMAP :fin du SMAP - En cours de jeu INFO :message envoyé par le serveur qui s'affiche à l'écran des joueurs :! ARM [+] [*]:montre le changement d'une armée [%] [<] [-] [.] [=,,] : BP <+|-> [message] :montre un nouveau breakpoint - Lors des scores : SCO :score d'un joueur 3) Particularités des commandes de positions Voici les arguments server -> client : + :ajoute des unités (donne le nombre final) % :définit le type de l'armée =,, :change la position (on indique l'user dans le cas d'un * qui prendrait plusieurs senders) ,<[>][v][<][^]> * :attaque < :retour - :suppression de l'armée . :lock { :deploiement } :reploiement ) :s'envoyer dans une unité de conteneur (voir 8. Entités Conteneurs) ( :sortir d'une unité conteneur (voir 8. Entités Conteneurs) & :la ligne n'est pas l'action principale (bien qu'elle soit la première envoyée) ~, :envoie une donnée particulière à l'entité, et qui doit donc etre interprétée par elle (RecvData). U :upgrade @ :investit | :changement de niveau de l'unité Et client -> server : > :déplacement de un à droite v :déplacement de un vers le bas < :déplacement de un à gauche ^ :déplacement de un vers le haut * :attaque une position ! :lors d'une attaque, force la case + :création d'une entité = : |- position de départ % : `- définit le type # :deploiement. ) :s'envoyer dans une unité conteneur (voir 8. Entités Conteneurs) ( :sortir d'une unité conteneur (voir 8. Entités Conteneurs) U :upgrader C :annuler les déplacements $ :vendre une unité 4) Modes La commande SET nécessite l'utilisation de modes, semblables à l'IRC. Voici la liste : Mode pour le chan: +l :paramètre la limite (serveur -> user uniquement) +o :met op un user +m :définie la map du jeu +b :l'argent de départ pour chaque joueur +r :partie rapide +W :pré-partie (WAITING) +S :envoie des infos (SENDING) +P :jeu (PLAYING) +A :animation (ANIMING) +Q :attente d'un joueur qui a perdu la connexion (PINGING) +E :fin du jeu (SCORING) +t :temps par tours maximum pour jouer +s :compte les scores pour le meta-serveur Mode pour un user: +c :l'user se définie sa couleur +p :l'user définie sa position +n :l'user définie sa nation +! :le joueur est READY +_ :le joueur a perdu +$ :l'argent du joueur (serveur -> user uniquement) +@ :l'user possède maintenant la terre +a :définie un user comme allié de lui +w :ce joueur a été déconnecté et on attend qu'il se reconnecte +v [nb] :vote pour virer un user, pas besoin de nombre pour cl->serv, mais pour serv->cl +d :donner de l'argent à un de ses alliés +e :donner une country à un de ses alliés 5) PLS La commande PLS a la particularité d'avoir une syntaxe plutot complexe et pas compréhensible sans document. C'est pourquoi je consacre ce cours paragraphe dans l'unique but de la détailler: PLS [@][!],,, [...] [*] :le joueur est owner [@] :le joueur est op [!] :le joueur est pret (Ready) :la position du joueur sur la carte :la couleur :la nation :le pseudo du joueur 6) Êtat d'une partie WAITING :c'est la pré-partie SENDING :le client créé la map physiquement et prépare toutes les données PLAYING :les joueurs doivent jouer jusqu'à ce que tout le monde soit READY ANIMING :animations commandées par le serveur 7) Intelligence Artificielle L'intelligence artificielle est implémentée dans le serveur de la manière suivante : - Son pseudo commence, pour la distinction, par IA_CHAR, définie dans lib/Channels.h, par default '&', étant un caractère non inclus dans NICK_CHARS. - Elle est considérée comme un client normal par le serveur qui ne fait quasiment pas la distinction - Chaque sendrpl() vers ce client est interprété ensuite par l'IA qui parse le message et le traite. - Chaque message que l'IA veut envoyer est en fait redirigé vers son parsemsg(). - Maintenant, les IA s'allient entre elles au début de la partie, et quand un des joueurs humain s'allie avec une IA, celle ci se des-allie avec ses alliées IA, puis s'allie avec l'humain. Ensuite donc un nombre variable d'humains peuvent s'allier avec l'IA, mais quand plus aucun humain n'est allié avec l'IA, celle ci s'allie avec toutes les IA qui n'ont pas d'alliés humains. La problematique est la suivante: * Dans plusieurs fonctions ???Command::Exec() executées par une commande d'un client, il y a des messages envoyés aux joueurs en prenant en compte le fait qu'aucun traitement d'un éventuel message de retour ne sera effectué avant la fin de cette fonction. Le problème est que l'IA elle, lorsqu'elle reçoit le message qui a été envoyé avant la fin de la fonction en question, peut interagire et répondre tout de suite, ce qui entraine un autre traitement qui coupe le traitement en cours. * Pour remédier à ce problème, un système de "lock" a été trouvé du coté de l'IA. Ainsi, lorsqu'elle est positionée comme étant "locké", tous les messages reçus sont ajoutés dans une queue qui, une fois "delocké", sera traité d'un coup. 8) Entités Conteneurs Les unités conteneurs peuvent transporter une autre unité. * Le protocole pour la mise dans une unité est le suivant : - PLAYING: > ARM AA )AB < :NICK!AA ARM )NICK!AB =NICK!AA,x,y,< - ANIMING: < :NICK!AA ARM )NICK!AB =NICK!AA,x,y,< * Le protocole pour extraire une unité est le suivant: - PLAYING: > ARM AB (x+1,y < :NICK!AA ARM (NICK!AB =NICK!AA,x,y,> - ANIMING: < :NICK!AA ARM (NICK!AB =NICK!AA,x,y,> Concrètement, une classe de base EConteneur aurrait une variable avec un pointeur vers l'entité. * Lorsqu'on met dans le conteneur, l'unité est supprimée de la liste globale des unités et de celle des joueurs, et stockée dans l'unité ECounteneur. Les clients en font de même et stockent également dans EConteneur. * Lors d'une attaque d'un conteneur avec une unité, l'unité conteneur appelle celle contenue pour se battre. * Lors de l'extraction, l'unité est remise en bien commun et vidé du conteneur, et les clients la ressortent également. Il faut que le conteneur gère le fait que si celui ci bouge il faut que son contenu bouge aussi (seulement son pointeur case et non se mettre dans la liste des entités d'une case, vu qu'elle ne doit plsu exister). Il faut également que la taille maximale à contenir soit proportionnel au "nombre" du conteneur. 9) Meta serveur Le meta-server permet de constituer une liste des serveurs lancés. Chaque serveur au démarrage se connecte au meta-serveur et le restera jusqu'à son extinction. A chaque evenement il envoie des informations, tels que le nombre de joueurs connectés, le nom de la carte, etc. Le client, quant à lui, se connecte au meta-serveur pour obtenir cette liste. a) Meta-server -> Serveur HEL :Dit bonjour, s'informe sur son type et sa version de protocole LOGGED :L'infnorme qu'il est loggé comme serveur officiel b) Serveur -> Meta-server IAM :Donne son nom, son prog et sa version SET [ ..] :Change un paramètre +p :- nombre de players actuellement +P :- max players +g :- nombre de jeux +G :- max jeux +w :- nombre de jeux en attente +v :- version du protocole +V :- version du serveur +i :- port +r :- tel user peut rejoindre tel chan +u :- uptime USET [ ..] :Paramètres d'un account +k :- unités tués +d :- unités perdues +s :- score +c :- créations +v :- victoire JOI :Anonce la création d'une partie (servira à prévenir les services d'events, style un bot IRC) type=1=mission, type=2=escarmouche, type=3=multi LEA :Anonce la fin d'une partie avec les gagnants et les perdants c) Meta-server <-> Client > HEL :Dit bonjour, s'informe sur son type et sa version de protocole < IAM [cookie|pass] :Donne son nom, son prog et sa version > STAT :Statistiques > LSP <+/-> :liste un serveur > EOL :fin du listing < SCORE > SCORE :score > ERR NICKUSED :pseudo déjà utilisé > REJOIN :le joueur peut rejoindre une partie > ERR REGNICK :le pseudo est enregistré < LOGIN :login < REGNICK :s'enregistrer > ERR LOGGED :loggé d) Meta-server <-> IRC Bot > HEL < IAM IRCBOT < STAT :afficher les stats < LSP :afficher la liste des serveurs > REGNICK :event quand un user a reg son nick > MSG_IA_JOIN :creation de partie > JOIN :evenements concernant les maps type=1=mission, type=2=escarmouche, type=3=multi > LEA :Anonce la fin d'une partie avec les gagnants et les perdants