-------------------------------------------------------------------
Page Web :
Titre provisoire
(PR*02 2010/2011 αβ)
I.A) Auteurs
I.B) Theme (voir liste des etudiants)
I.C) Resume du scenario (complet)
I.D) Plan (complet)
II, III, etc... : tout ce que vous voulez en plus
-------------------------------------------------------------------
Légende :
* = 1 ou 3S selon votre promo, α = 1 à 8 selon votre groupe,
β = A à F selon votre équipe
|
(This project is called ‘bad’ because its
implementation contains some bad design decisions, and we want to leave no doubt
that this should not be used as an example of good programming practice!)
Execute and explore the application. The project comment gives you some information about how to run it. While exploring the application, answer the following questions (and write the answers into the report) :
|
|
After you know what the whole application does, try to find out what
each individual class does.
Write down for each class the purpose of the class. You need to look at the source code to do this. Note that you might not (and need not) understand all of the source code. Often, reading through comments and looking at method headers is enough. |
|
Design your own game scenario. Do this away from the computer.
Do not think about implementation, classes, or even programming in general.
Just think about inventing an interesting game. This could be done with a group of people.
The game can be anything that has as its base structure a player moving through different locations. Here are some examples:
Try to think of many things to make the game interesting (trap doors, magic items, characters that help you only if you feed them, time limits, whatever you like). Let your imagination run wild. At this stage, do not worry about how to implement these things. |
-------------------------------------------------------------------
Rapport :
Titre provisoire + lien page web
(PR*02 2010/2011 αβ)
I.A) Auteurs
I.B) Theme (voir liste des etudiants)
I.C) Resume du scenario (complet)
I.D) Plan (complet, avec indication de la partie "reduit")
I.E) Scenario detaille (complet, avec indication de la partie "reduit"))
I.F) Detail des lieux, items, personnages
I.G) Situations gagnantes et perdantes
I.H) Eventuellement enigmes, mini-jeux, combats, etc.
II. Reponses aux exercices (autres que I.)
III, IV, etc... : tout ce que vous voulez en plus
-------------------------------------------------------------------
Ce fichier sera complété ou modifié au fur et à mesure
de l'avancement du projet.
À cette étape :
|
Open the zuul-bad project, and save it under a different name (e.g. zuul-v4).
This is the project you will use to make improvements and modifications throughout this chapter.
You can leave off the -bad suffix, since it will soon (hopefully) not be that bad anymore. As a first step, change the createRooms method in the Game class to create the rooms and exits you invented for your game. Test! |
| Implement and use a separate printLocationInfo method in your project, as discussed in this section. Test your changes. |
| Make the changes we have described to the Room and Game classes. |
| Make a similar change to the printLocationInfo method of Game so that the details of the exits are now prepared by the Room rather than the Game. Define a method in Room with the following signature public String getExitString(). |
... à faire avant le TP1.
... à faire avant le TP2.
... à faire avant le TP3.
Attention !
Le niveau de difficulté des exercices 7.44 à 7.49
est plus élevé que celui des autres exercices.
... à faire avant le TP4.
Incorporer dans le jeu une image différente
pour chaque Room. S'il en manque, fabriquer une "image de mot"
pour afficher simplement le nom du lieu
(voir rubrique Plus de technique).
Il est également possible de prévoir une
longDescription pour chaque Item ; voir quand il serait
intéressant de l'utiliser.
javadoc -d docprog -author -version -private -linksource *.java
javadoc -d docuser -author -version *.java
à partir de la ligne de commande, et rendre ces documentations
accessibles par un lien sur la page web du jeu.
(voir rubrique Plus de technique)
Remarque sur le 7.29 : c'est la classe GameEngine et non Game qui contient trop de code.
Tous les exercices de la "liste officielle" sont obligatoires
(sauf s'ils sont explicitement indiqués comme
optionnels).
Si certains s'intègrent mal dans votre scénario,
ils pourront ne pas intervenir dans ce scénario,
mais devront toutefois être implémentés
et pouvoir être testés dans le jeu.
Bien sûr, vous pouvez en faire plus, et vous êtes encouragés
à exprimer votre créativité à cette occasion.
Une trap door n'est pas une trap room.
La pièce concernée peut très bien avoir plusieurs sorties,
mais l'une d'entre-elles ne doit être franchissable que dans un seul sens.
Le téléporteur (beamer) doit pouvoir être ramassé
dans une première pièce,
peut ensuite être chargé dans une deuxième pièce,
puis déclenché dans une troisième ;
il peut éventuellement être réutilisable,
mais dans ce cas, il doit obligatoirement être rechargé.
Question à se poser : et s'il y avait plusieurs téléporteurs ?
Une pièce peut avoir certaines de ses portes ouvertes, et d'autres fermées.
Une clé doit être prise avant de pouvoir ouvrir ou fermer une porte.
Elle fonctionne des 2 côtés de la porte.
Plusieurs clés différentes doivent pouvoir être gérées,
et s'il y a plusieurs portes fermées à clé, il faut une clé
différente pour ouvrir chacune d'entre-elles.
Conseil : si vous ne l'avez pas fait pour l'exercice 7.43,
il est temps de créer une classe Door
et peut-être de reconsidérer l'exercice 7.43.
- alea string : mémorise la string pour pouvoir
l'utiliser lors du prochain tirage aléatoire
- alea : vide la string pour permettre au prochain tirage d'être
réellement aléatoire
Cette commande ne devrait pouvoir être utilisée qu'en mode test
(sauf peut-être pendant les phases de mise au point du programme).
Tout recompiler (reconstruire le paquetage) : il ne doit subsister aucun avertissement.
Cet exercice doit être bien compris par TOUS les membres de l'équipe.
Ensuite, peu de modifications structurelles devraient avoir lieu ;
il est donc possible de commencer à introduire dans son jeu tous les
éléments du scénario complet (lieux, items, images, suppléments, ...).
Cet exercice peut également vous inspirer pour la gestion de différents
types de pièces, d'items, de personnages, ...
Contraintes :
1) la classe Game doit rester hors de tout paquetage
2) le nom de chaque paquetage doit commencer par pkg_
3) le nombre minimum de paquetages est 2
4) le nombre minimum de classes par paquetage est 2
tout recompiler : il ne doit y avoir aucun warning.
javadoc -d docprog -author -version -private -linksource pkg_* *.java
javadoc -d docuser -author -version pkg_* *.java
à partir de la ligne de commande, et
les mettre à jour sur la page web du jeu.
Plus d'autres exercices, mais encore du travail ...