SAÉ 6.A.01 - Évolution d’une application
Évolution d’un serveur de jeu.
Le projet consiste à faire évoluer un serveur de jeu existant. Pour cela le code original vous est fourni. Vous pouvez choisir de faire évoluer la base de code existante, basée sur Java et JBox2D, ou alors de ré-implémenter le serveur en utilisant d’autres technologies.
Si vous choisissez de ré-écrire le serveur dans un autre langage, cela sera pris en compte dans l’évaluation et il ne sera pas requis d’introduire de nouvelles fonctionnalités. Les contraintes de qualité de code resteront cependant les mêmes.
1. Évaluation
L’évaluation de votre travail sera faîtes sur un document de suivi de projet et une revue de code.
1.1. Document de suivi de projet
Ce document devra comporter les éléments suivants :
-
Une analyse de l’existant en terme de :
-
structure générale, architecture du code : diagrammes de classe, diagrammes de séquence pour les parties critiques,
-
qualité (lisibilité, maintenabilité, robustesse, testabilité, etc.),
-
-
Les propositions d’amélioration en terme de :
-
qualité (tests mis en place, Intégration continue ?) et
-
de fonctionnalités, quelle nouvelles fonctionnalités, comment les utiliser en tant que client ou administrateur ?
-
-
Les choix techniques argumentés (reprise de l’existant, ré-écriture, choix de bibliothèques, etc.)
Ce document devra comporter un tableau récapitulatif des tâches prévues. Il devra être mis à jour régulièrement pour refléter l’avancement du projet.
Ce tableau devra indiquer, pour chaque tâche,
-
son niveau d’avancement et
-
le niveau d'implication de chaque membre du groupe, en heures.
Un exemple de document est disponible à cette adresse.
Le texte en rouge est un exemple de ce qui pourrait être ajouté au cours de la réalisation.
Si vous souhaitez utiliser LaTeX, vous trouverez un exemple de document à cette adresse.
Le fichier devra être au format PDF ou Markdown et être à la racine de votre dépôt Git.
1.2. Revue de code
Cette revue de code sera faite en présence de vos enseignants, devant votre code et devra comporter les éléments suivants :
-
de la structure générale, des choix techniques, des fonctionnalités ajoutées.
-
des mesures prises pour améliorer ou garantir la qualité du projet.
-
Les choix techniques,
-
l’architecture,
-
les mesures de qualité mises en place,
Un exemple de présentation accompagnant la revue de code finale est disponible à cette adresse.
1.3. Échéancier
2. Existant
|
Le code du serveur de jeu utilisé dans les ressources R4.A.11 (BUT2 - Android) et R5.A.08 (Qualité de développement) vous est fourni. Il permet à plusieurs joueurs de se connecter puis de contrôler un véhicule. |
Vous trouverez le code dans cette archive.
En envoyant des messages au serveur, le joueur peut par exemple :
-
Changer la vitesse des moteurs gauche et droit.
-
Tirer un projectile.
-
Récupérer la position du joueur le plus proche.
-
…
Les commandes possibles sont listées dans la documentation du serveur
3. Amélioration de la qualité
Afin d’améliorer la qualité du logiciel existant vous devez améliorer les différents critères suivants :
-
Fiabilité (tests, gestion des erreurs, etc.)
-
Maintenabilité (Clean Code, documentation, etc.)
-
Extensibilité (Structuration, Patrons de conception, etc.)
Quelques soit vos choix de développement, y compris de réimplémenter dans d’autres langages/frameworks, le programme doit être compatible avec les clients (applications mobiles, bots) déjà développés, et proposer toutes les fonctionnalités déjà présentes.
4. Pistes d’évolutions de l’application
Vous trouverez ci-dessous des suggestions d’évolution de l’application. Vous pouvez choisir parmi ces suggestions ou proposer les vôtres.
La qualité des fonctionnalités développées (structure et lisibilité du code, documentation, tests, etc.) est plus importante que la quantité.
Pour rappel, si vous décidez de ré-écrire le serveur dans un autre langage, cela sera pris en compte dans l’évaluation et l’absence de nouvelles fonctionnalités ne sera pas pénalisée.
4.1. Évolutions basiques
-
Classer l’affichage du score.
-
Ajouter le nombre de fois où le joueur est mort.
-
Limiter le nombre de vies.
-
Limiter le nombre de munition.
-
Détecter les projectiles sans détecter les siens.
-
Lorsqu’un véhicule est "détruit", il n’est plus perçu par les autres véhicules.
-
Ajout de la gestion d’équipes (récupération de la position des )
4.2. Autres modes de jeu
-
TDM, match à mort en équipe : les points pour élimination sont comptabilisé pour l’équipe. Le friendly fire ("tir allié") peut retirer des points à l’équipe.
-
Élimination par round : mode de jeu en équipe ou un joueur éliminé ne réapparaît qu’a la prochaine partie. Un point est donnée à l’équipe qui a éliminé tous ses adversaires.
-
Capture the flag, CtF : mode de jeu par équipe ou les points sont donnés pour la capture du drapeau (soit dans la base ennemie ou au centre du terrain). L’élimination d’un adversaire ne rapporte pas de points, mais le place en suspension.
-
Coopératif : Il est possible de proposer tous les modes de jeu précédents contre une AI. Un mode coopératif dédié peut être asymétrique: les adversaires contrôlés par l’IA sont plus faibles que les joueurs mais beaucoup plus nombreux. Vous pouvez rajouter des objectifs, des boss …
-
Autres : mode course, football …
4.3. Autres types de véhicules et fonctionnalités de jeu
Les joueurs doivent pouvoir choisir des véhicules différents en termes de :
-
Vitesse de déplacement
-
Vitesse de tir
-
Points de vie
-
Boucliers
-
Perception
Potentiellement par un système de classes ou d’équipement.
Implémenter de nouvelles capacités de jeu :
-
Collecte de ressources pour l’achat de bonus (upgrade).
-
Équipement déployable en jeu, système de construction (murs, tourelles, mines, zones de réparations …).
-
Terrain destructible/modifiable.
4.4. Retour d’information depuis le serveur vers le client
-
Position des autres joueurs, avec occlusion par les obstacles.
-
Position des obstacles.
-
Position absolue du véhicule.
-
Position du flag pour CtF.
-
…
-
Streaming : L’image de la zone de jeu est renvoyée à l’appareil mobile du joueur (façon "google stadia")
-
Message de mise à jour : toutes les information pour dessiner la zone de jeu (ie: position des joueurs) sont envoyés à l’appareil mobile. Nombreuses astuces possible, attention à la triche. Quelques références : Moteur source, Quake 3.
Étudiez les différents types de protocoles réseau, certains sont plus adaptés selon le type de messages (mise à jour, administration, connexion …). Proposez un meilleur encodage des messages.
4.5. Administration du serveur et données joueurs
Proposez la gestion distante du serveur:
-
Authentification des comptes administrateurs et modérateurs
-
Commandes pour le changement de maps, de modes de jeu, soit par les admins/mods, soit par un système de vote
-
Commandes de police du serveur: kick/ban, votekick/voteban
-
Interface web pour les administrateurs, upload de contenu (Mods/Maps/…)
Proposez un système de comptes joueurs:
-
Administration du compte par le joueur par interface web
-
Statistiques de jeu, rang/grades affichable en jeu
-
Système de progression: nouvelles armes/véhicules/etc, cosmétiques. Intéressant à mettre en lien avec une fonctionnalité de personnalisation d’équipement du joueur.