Projets 2019 en C3P

Vincent Aranega & Clément Ballabriga

#1 Seveur REST de jeu MUD-like

Le but de ce projet et de fournir un genre de terrain de jeu pour personnage via un serveur REST. Le serveur sera capable d’accepter plusieurs joueurs en même temps et de gérer les plusieurs actions du joueurs. Le protocole donné repose sur des requêtes POST/GET (donné à la fin du document)

#1 Actions utilisateur

  • la connexion du joueur (sans authentification),

  • l’observation d’une pièce (retourner son l’état),

  • le déplacement d’un joueur vers une pièce adjacente,

  • l’observation d’un autre joueur/monstre (retourner l’état d’un joueur/monstre),

  • mener une attaque vers un autre joueur si on est dans la même pièce.

#2 Client REST de jeu MUD-like

Ce projet et le complément du projet de serveur de jeu MUD-like. Il se découpe en deux parties, l’une reposant sur l’autre. La première partie est la production d’un binding vers le server de jeux qui répond à un protocole en particulier. La second partie du projet et la production d’une client utilisant ce binding et qui propose une interface simple de jeu sous forme textuelle.

#2 Actions utilisateur

  • Le protocole est le même que pour celle du serveur, seulement quelques actions sont possibles

    • se connecter au serveur (sans authentification)

    • observer une pièce dans laquelle on se trouve

    • observer un autre joueur/monstre

    • se déplacer dans un autre pièce

    • mener une attaque vers un autre joueur si on est dans la même pièce

#3 API pour la gestion de jeux de cartes

Lors de la production de plusieurs type de jeu de cartes (blackjack, poker,…​), il est nécessaire de gérer l’ensemble d’un jeu de cartes (mélange du jeu, choix du nombre de cartes…​etc). Une API-REST ouverte a été proposée pour gérer au ces éléments sans avoir à réécrire la logique de la gestion d’un jeu. La documentation est disponible à l’adresse suivante : http://deckofcardsapi.com/ .

#3 Travail demandé

On vous propose ici de créer un binding dans le langage que vous aurez choisis pour accéder et gérer un ou plusieurs jeux de cartes. Un binding vers une API représente une bibliothèque qui permet de masquer les appels à l’API et de fournir un moyen programmatique d’y accéder. Votre API devra être en mesure de créer un nouveau jeu de carte, de jeter des cartes, de tirer des cartes, bref de donner accès aux fonctionnalités proposées par l’API REST.

#3 Précision !

Même si l’API est disponible en ligne, il s’agit d’une API de démonstration, il y a fort à parier qu’elle ne supporte pas la charge. Il est donc recommandé d’installer l’API en local (c’est du Python). Pour le faire, il suffit de créer un environnement virtuel en utilisant Pipenv (comme dans les TPs Python), de rentrer dans l’environnement, puis de faire l’installation des dépendances comme indiqué sur le readme.

#4 MagiStack

MagiStack (https://esolangs.org/wiki/MagiStack) est un langage ésotérique, reposant sur une pile et créé par Connor Scialdone. Il est plus ou moins inspiré de Befunge (un langage à deux dimensions). Ce langage, à l’image de Brainfuck (https://esolangs.org/wiki/Brainfuck), est constitué de très peu d’instructions. Ces instructions représentent différentes actions qu’il est possible d’effectuer sur une pile et sur un pointeur d’instruction. Un interpréteur MagiStack est donc composé au moins d’une pile et d’un pointeur d’instruction.

#4 Travail demandé

On vous propose ici de créer un interpréteur MagiStack qui doit implémenter la dernière version du langage (v1.2). Vous proposerez des tests unitaires.

Protocol MUD

Généralités

Type du contenu des requêtes HTTP

Content-Type: application/json

Formes générales
POST <url>/connect
POST <url>/<guid>/command

Connection

code de retour
201
url
POST <url>/connect
réponse
{
 "guid": <guid>
 "totalvie": <integer>
 "salle": {
    "description": <description (string)>
    "passages": [ "N", "E", ... ]
    "entites": [ <guid1>, <guid2>, <guid3>, ...]
  }
}

Regarder salle

url
GET <url>/<guid>/regarder
reponse
{
 "description": <description (string)>
 "passages": [ "N", "E", ... ]
 "entites": [ <guid1>, <guid2>, <guid3>, ...]
}

Déplacement

url
POST <url>/<guid>/deplacement
requete
{
  "direction":  "N" | "S" | "E" | "W"
}
reponse
{
 "description": <description (string)>
 "passages": [ "N", "E", ... ]
 "entites": [ <guid1>, <guid2>, <guid3>, ...]
}

Examiner

url
GET <url>/<guidsource>/examiner/<guiddest>
reponse
{
 "description": <description>
 "type" : "JOUEUR" | "MONSTRE"
 "vie": <integer>
 "totalvie": <integer>
}

Taper

url
POST <url>/<guidsource>/taper
reponse
{
  "cible:" <guid cible (integer)>
}

Gestion d’erreurs

  • Si la requete est malformee (pas du json valide, ou bien manque des fields etc): 400

  • Si l’URL existe pas (commande inconnue, guid inconnu, etc.): 404

  • code 409 pour tout autre erreur, réponse json :

{
 "type": "MORT" | "MUR"
 "message:" string
}