Cette application nécessite l'activation de Javascript.
Apprenez comment activer Javascript dans votre navigateur.
Vous n'êtes pas connecté.
Connexion
Ma Page
Changements Récents
Outils
Aide
Pages récentes
Projet 2017-2018
Accueil
Frédéric Mallet
Programmation Avan...
Projet 2012-2013
Projet 2013-2014
Projet 2014-2015
Projet 2016-2017
Projet 2017-2018
Projets 2015-2016
SMZG11 - 2012/2013
SMZG11 - 2013/2014
TD1 - Entrées/Sortie...
TD2 - Introspection ...
TD3 - Chargement dy...
TD4 - Annotations
Modifier
la page
Nouvelle
page
Imprimer
la page
Plus
Page modifiée à
12:34, 12 Jan 2018
par
FabriceHuet
0
Préférences d'impression
Voir la Table des Matières
Montrer les infos de modification
Montrer les notes finales en lien
Projet 2017-2018
De $1
Table des matières
1.1.
Modalités
2.
Pour le projet, des groupes aléatoires de 3 ou 4 étudiants ont été constitués. L'utilisation d'un gestionnaire de source GIT est obligatoire(GitHub ou BitBucket). Il doit être accessible par le chargé de TPs et les logs de commit seront évalués pour la notation finale. L'URL du repository est à envoyer par email à miage.m1@gmail.com avec le sujet "[PA2017] Repo GIT" dès le début du projet. Le projet sera évalué en fonction des critères suivants : fonctionnalité mécanisme de gestion de plugins et de chargement dynamique persistance (sauvegarde de l'état des plugins) modularité et dépendances documentation / gestion du projet Chacun de ces critères comptant pour 20% de la note de rendu du projet. Cette note sera commune à tout le groupe sauf si il existe une différence trop importante dans le travail fourni entre les membres. Les projets seront à déposer sur Jalon au plus tard le vendredi 12 janvier sous forme de fichier ZIP contenant les informations suivantes: Une archive contenant les sources du projet (un projet Eclipse ou NetBeans), pas les binaires ! Un rapport (10 pages mininum, 12 pages maximum) qui décrit La participation de chacun des membres de l'équipe ; La procédure à suivre pour tester votre projet ; Un calendrier des grandes étapes du projet (par membre) ; Pour chacun des 5 points énoncés au début (fonctionnalité, chargement dynamique, persistance, modularité, suivi), la façon dont ils ont été adressés ou pas et les aspects remarquables. La procédure pour créer de nouveaux plugins Plusieurs exemples de plugins (au moins 6) avec une courte description (10 lignes maximum) de ce qu'ils font. Le code lui-même sera dans le projet ; La description des plugins pourra être mise dans le rapport ; Une soutenance orale (par groupe) aura lieu la semaine du 8 janvier selon un ordre de passage annoncé ultérieurement. Cette présentation orale de 15 minutes aura pour but de montrer le fonctionnement de l'application et mettre en lumière la contribution individuelle de chaque membre du groupe. Cette note de soutenance sera individuelle. La note finale de projet sera calculée en faisant la moyenne de la note de rendu de projet (50%) et la note de soutenance (50%). Les groupes de 4 étudiants devront fournir un travail plus conséquent que les groupes de 3
2.1.
Sujet
3.
Le but de ce projet est de construire un jeu de combat virtuel de type RobotWar Dans une arêne de combat en 2D, vue de dessus, des robots s'affrontent, gérés par une IA relativement basique. Le comportement ainsi que le graphisme des robots est décidé par des plugins. Un robot est actif tant que sa vie n'a pas atteint 0 et le gagnant est le dernier robot actif. À chaque robot est associé une quantité d'énergie et chaque action consomme une partie de celle-ci. L'énergie remonte régulièrement tant qu'elle n'a pas atteint la valeur maximale. Le mécanisme de plugins devra utiliser les annotations comme vu dans le TP4 (pas de classes ou interfaces pour marquer les plugins).
3.1.1.
Plugins graphisme
4.
Ces plugins servent à la représentation graphique des robots et de leurs armes. Le jeu devra contenir de base un plugin qui représente les robots par un carré de couleur alératoire. D'autres plugins possibles sont par exemple une animation, la visualisation des barres de vie et d'énergie... Ces plugins ne consomment pas d'énergie.
4.1.1.
Plugins de déplacement
5.
Ces plugins servent à décider du déplacement du robot. Le plugin le plus simple consiste en un déplacement aléatoire mais d'autres plus compliqués peuvent être implémentés. Par exemple dans le cas d'un robot avec une arme de courte portée, un déplacement vers un autre robot sera utile. On peut aussi avoir un déplacement dont la vitesse dépend de la barre de vie ou de la quantité d'énergie restante. Ces plugins consomment de l'énergie.
5.1.1.
Plugins d'attaque
6.
Ces plugins servent à décider attaquer les autres robots et à diminuer leur barre de vie. Chaque attaque sera définie par une portée et un graphisme. De base un plugin implémentant une attaque de courte portée sera proposé. Ces plugins consomment de l'énergie.
6.1.1.
Remarques
7.
Vous pouvez supposer que les robots ont 100 d'énergie à chaque tour et activer les plugins jusqu'à consommer ces points. Si il n'y a plus de points, alors un plugin ne fera aucune action. Ne perdez pas de vue que l'objectif est de faire une architecture à plugin, donc ne passez pas trop de temps à rendre votre jeu intéressant/amusant, ce n'est pas le but. Il faut par contre avoir un nombre significatif de plugins. Des plugins complexes (nécessitant par exemple une interaction avec d'autres plugins) rapporteront plus de points.
7.1.1.
7.1.2.
Scénario pour l'évaluation
8.
Afin d'évaluer vos projets, voici un ensemble d'étapes effectuées par le correcteur. Vous devez vous assurer que ce scénario marche sur n'importe quelle machine. Le projet sera testé sur un Linux ou un Mac avec un Java 8. Compilation du projet avec maven Génération d'un jar exécutable avec maven Création d'une arborescence contenant des plugins de base chargés dés le lancement de l'application Création d'une arborescence séparée contenant des plugins que l'utilisateur pourra ajouter à l'application (i.e. pas dans le classpath initial) Ce projet maven devra donc utiliser des modules (https://maven.apache.org/guides/mini...e-modules.html) Démarrage de l'application avec java -jar ... ou maven Déplacement dans l'arborescence, ajout/suppression de plugins... Le but de cette évaluation est d'avoir un aperçu rapide de votre programme afin de préparer la présentation orale.
9.
« 50 précédents
50 suivants »
Sélectionnez les versions à comparer et cliquez sur 'Comparaison versions'.
Comparer
Date de révision
Modifié par
Résumé des modifications
Voir la version
12:34, 12 Jan 2018
FabriceHuet
21 mots ajoutés
Voir la version
13:52, 18 Déc 2017
FabriceHuet
12 mots ajoutés, 1 mots supprimés
Voir la version
08:45, 4 Déc 2017
FabriceHuet
page créée, 913 mots ajoutés
« 50 précédents
50 suivants »
Powered by
MindTouch Deki Open Source Edition
v.8.08
Flux RSS
Utilisateurs
Modèles
Plan du site
Pages populaires
A propos
Surveiller
Attacher fichier ou image
Accès restreint
Déplacer
Supprimer
Mots clés
Envoyer la page
Propriétés de la page
Page de discussion
Table des matières
1.1.
Modalités
2.
Pour le projet, des groupes aléatoires de 3 ou 4 étudiants ont été constitués. L'utilisation d'un gestionnaire de source GIT est obligatoire(GitHub ou BitBucket). Il doit être accessible par le chargé de TPs et les logs de commit seront évalués pour la notation finale. L'URL du repository est à envoyer par email à miage.m1@gmail.com avec le sujet "[PA2017] Repo GIT" dès le début du projet. Le projet sera évalué en fonction des critères suivants : fonctionnalité mécanisme de gestion de plugins et de chargement dynamique persistance (sauvegarde de l'état des plugins) modularité et dépendances documentation / gestion du projet Chacun de ces critères comptant pour 20% de la note de rendu du projet. Cette note sera commune à tout le groupe sauf si il existe une différence trop importante dans le travail fourni entre les membres. Les projets seront à déposer sur Jalon au plus tard le vendredi 12 janvier sous forme de fichier ZIP contenant les informations suivantes: Une archive contenant les sources du projet (un projet Eclipse ou NetBeans), pas les binaires ! Un rapport (10 pages mininum, 12 pages maximum) qui décrit La participation de chacun des membres de l'équipe ; La procédure à suivre pour tester votre projet ; Un calendrier des grandes étapes du projet (par membre) ; Pour chacun des 5 points énoncés au début (fonctionnalité, chargement dynamique, persistance, modularité, suivi), la façon dont ils ont été adressés ou pas et les aspects remarquables. La procédure pour créer de nouveaux plugins Plusieurs exemples de plugins (au moins 6) avec une courte description (10 lignes maximum) de ce qu'ils font. Le code lui-même sera dans le projet ; La description des plugins pourra être mise dans le rapport ; Une soutenance orale (par groupe) aura lieu la semaine du 8 janvier selon un ordre de passage annoncé ultérieurement. Cette présentation orale de 15 minutes aura pour but de montrer le fonctionnement de l'application et mettre en lumière la contribution individuelle de chaque membre du groupe. Cette note de soutenance sera individuelle. La note finale de projet sera calculée en faisant la moyenne de la note de rendu de projet (50%) et la note de soutenance (50%). Les groupes de 4 étudiants devront fournir un travail plus conséquent que les groupes de 3
2.1.
Sujet
3.
Le but de ce projet est de construire un jeu de combat virtuel de type RobotWar Dans une arêne de combat en 2D, vue de dessus, des robots s'affrontent, gérés par une IA relativement basique. Le comportement ainsi que le graphisme des robots est décidé par des plugins. Un robot est actif tant que sa vie n'a pas atteint 0 et le gagnant est le dernier robot actif. À chaque robot est associé une quantité d'énergie et chaque action consomme une partie de celle-ci. L'énergie remonte régulièrement tant qu'elle n'a pas atteint la valeur maximale. Le mécanisme de plugins devra utiliser les annotations comme vu dans le TP4 (pas de classes ou interfaces pour marquer les plugins).
3.1.1.
Plugins graphisme
4.
Ces plugins servent à la représentation graphique des robots et de leurs armes. Le jeu devra contenir de base un plugin qui représente les robots par un carré de couleur alératoire. D'autres plugins possibles sont par exemple une animation, la visualisation des barres de vie et d'énergie... Ces plugins ne consomment pas d'énergie.
4.1.1.
Plugins de déplacement
5.
Ces plugins servent à décider du déplacement du robot. Le plugin le plus simple consiste en un déplacement aléatoire mais d'autres plus compliqués peuvent être implémentés. Par exemple dans le cas d'un robot avec une arme de courte portée, un déplacement vers un autre robot sera utile. On peut aussi avoir un déplacement dont la vitesse dépend de la barre de vie ou de la quantité d'énergie restante. Ces plugins consomment de l'énergie.
5.1.1.
Plugins d'attaque
6.
Ces plugins servent à décider attaquer les autres robots et à diminuer leur barre de vie. Chaque attaque sera définie par une portée et un graphisme. De base un plugin implémentant une attaque de courte portée sera proposé. Ces plugins consomment de l'énergie.
6.1.1.
Remarques
7.
Vous pouvez supposer que les robots ont 100 d'énergie à chaque tour et activer les plugins jusqu'à consommer ces points. Si il n'y a plus de points, alors un plugin ne fera aucune action. Ne perdez pas de vue que l'objectif est de faire une architecture à plugin, donc ne passez pas trop de temps à rendre votre jeu intéressant/amusant, ce n'est pas le but. Il faut par contre avoir un nombre significatif de plugins. Des plugins complexes (nécessitant par exemple une interaction avec d'autres plugins) rapporteront plus de points.
7.1.1.
7.1.2.
Scénario pour l'évaluation
8.
Afin d'évaluer vos projets, voici un ensemble d'étapes effectuées par le correcteur. Vous devez vous assurer que ce scénario marche sur n'importe quelle machine. Le projet sera testé sur un Linux ou un Mac avec un Java 8. Compilation du projet avec maven Génération d'un jar exécutable avec maven Création d'une arborescence contenant des plugins de base chargés dés le lancement de l'application Création d'une arborescence séparée contenant des plugins que l'utilisateur pourra ajouter à l'application (i.e. pas dans le classpath initial) Ce projet maven devra donc utiliser des modules (https://maven.apache.org/guides/mini...e-modules.html) Démarrage de l'application avec java -jar ... ou maven Déplacement dans l'arborescence, ajout/suppression de plugins... Le but de cette évaluation est d'avoir un aperçu rapide de votre programme afin de préparer la présentation orale.
9.
effacer le message
voir détails
Ce message disparaitra dans
secondes
Le temporisateur de message a été arrêté
Affichage Détails: