Introduction
Les jeux vidéo en mode texte
Un jeu vidéo en mode texte (text-based game en anglais) est un jeu vidéo sur écran dans lequel le joueur est plongé dans un univers fictif et doit résoudre des énigmes pour progresser dans l’histoire. Le joueur interagit avec le jeu en tapant des commandes dans un terminal. Le jeu répond en affichant du texte. Le jeu est donc très proche d’un jeu de rôle papier, mais avec un ordinateur pour gérer les règles et l’univers. Le jeu n’utilise pas de graphisme, mais uniquement des phrases (texte, des questions et des réponses).
Pour avancer dans un jeu textuel, le joueur est invité à entrer des actions (se baisser pour ramasser une clé, examiner un tronc d’arbre, marcher vers le sud, tuer un monstre, etc.) en fonction du contexte et lieu où il se trouve. Ce lieu est décrit par le programme (vous vous trouvez devant le porche de la maison, vous êtes dans la forêt face à un orc, etc…) . De multiples autres critères entrent parfois en compte (vie, arme, état du personnage, etc.).
Les jeux textuels sont souvent des jeux de rôle, mais il existe aussi des jeux de stratégie, de gestion, de simulation, etc.
Un exemple : Zork
Zork I: The Great Underground Empire est un jeu vidéo d’aventure textuel développé à l’origine en 1977 par un groupe d’étudiants du MIT, connu sous le nom de « Dynamic Modeling Group ». Il est considéré comme l’un des jeux les plus emblématiques de l’histoire des jeux vidéo et a contribué à populariser le genre des jeux d’aventure textuels.
Dans Zork I, le joueur incarne un aventurier qui explore les profondeurs d’un empire souterrain, où il doit résoudre des énigmes, trouver des trésors et vaincre des ennemis pour progresser. Le jeu se déroule entièrement par le biais de descriptions textuelles et de commandes tapées au clavier. Le joueur doit utiliser son imagination et sa logique pour résoudre les énigmes et progresser dans l’aventure.
Le jeu a connu un grand succès dans les années 1980 et a inspiré de nombreux autres jeux d’aventure textuels ainsi que des adaptations pour d’autres supports, tels que des romans et des bandes dessinées.
On peut y jouer en ligne ici.
Voici quelques pas dans le jeu
West of House
You are standing in an open field west of a white house, with a boarded front door.
There is a small mailbox here.
>open mailbox
Opening the small mailbox reveals a leaflet.
>read leaflet
(Taken)
"WELCOME TO ZORK!
ZORK is a game of adventure, danger, and low cunning. In it you will explore some of the most amazing territory ever seen by mortals. No computer should be without one!"
>drop leaflet
Dropped.
>go south
South of House
You are facing the south side of a white house. There is no door here, and all the windows are boarded.
>go east
Behind House
You are behind the white house. A path leads into the forest to the east. In one corner of the house there is a small window which is slightly ajar.
>open window
With great effort, you open the window far enough to allow entry.
>enter house
Kitchen
You are in the kitchen of the white house. A table seems to have been used recently for the preparation of food. A passage leads to the west and a dark staircase can be seen leading upward. A dark chimney leads down and to the east is a small window which is open.
On the table is an elongated brown sack, smelling of hot peppers.
A bottle is sitting on the table.
The glass bottle contains:
A quantity of water
Objectifs
L’objectif est de créer un jeu vidéo en mode texte (beaucoup plus modeste que Zork !), en utilisant le langage Python.
Une première partie du travail consiste à définir l’univers du jeu : le lieu où se déroule l’action, les personnages, les objets, etc. Une fois l’univers défini, il faut définir les règles du jeu : comment le joueur interagit avec l’univers, comment l’univers réagit aux actions du joueur, etc. Enfin, il faut écrire le code qui implémente ces règles.
Dans sa première version, la communication entre le joueur et la machine se fera uniquement en mode texte dans un terminal.
Comme il est assez facile de le porter dans un environnement graphique, dans une seconde version, les élèves les plus avancés pourront le porter vers une interface graphique qui améliorera la jouabilité.
Organisation
Le mini projet est réalisé en binôme, dont la constitution est libre. Il est préférable de constituer les binomes à partir d’élèves du même groupe pédagogique. Il est demandé de remplir ce formulaire pour renseigner :
les membres du binôme ;
le contexte du jeu ;
l’URL du repo git (cf ci dessous).
Avertissement
Au delà du mercredi 20 novembre, les élèves qui n’ont pas répondu au formulaire ci dessus seront aléatoirement regroupés en binomes.
Suivi de la progression
Avant une date limite, il est demandé à chaque binome de faire valider à l’enseignant le travail demandé sous forme d’exercice.
Avertissement
Les exercices ne peuvent être présentés qu’une seule fois. Assurez vous qu’ils sont bien opérationnels avant de les soumettre à l’enseignant.
Une première version (lundi 25 novembre)
Passage interdit
Sens unique
Commande vide
Votre propre univers (lundi 2 décembre)
Ajouter des lieux
Gestion direction inconnue
Ajouter un historique (lundi 9 décembre)
Construire un historique
Revenir en arrière
Ajouter des objets (lundi 16 décembre)
Ajouter un inventaire (joueur)
Ajouter un inventaire (lieu)
Observer l’environnement
Prendre / reposer un item
Vérifier son inventaire
Ajouter des PNJ (lundi 13 janvier)
Créer un PNJ
Intégrer les PNJ à la map
Déplacer les PNJ
Interagir avec les PNJ
Chacun des exercices recevra un grade parmi:
ok : tout fonctionne comme prévu
en cours : la fonctionnalité a été implémentée mais elle n’est pas pleinement opérationnelle
pas fait : valeur par défaut
Remise du travail
La date limite de remise du travail est précisée sur la page d’accueil de l’unité.
Le projet est développé dans un environnement Github, dans le repo dont vous avez renseigné l’URL via le formulaire ci dessus.
Astuce
Aucune démarche de remise du projet n’est nécessaire, votre projet sera cloné à partir du dépôt pour évaluation une fois la date de remise du travail dépassée.
Avertissement
La date du dernier commit fera foi. NE SURTOUT PAS MODIFIER VOTRE PROJET AU DELA DE LA DATE LIMITE. Voir la page d’accueil de l’unité pour les conditions de bonus/malus.
Structure du dépôt
Votre dépôt doit être structuré et contenir les seuls fichiers strictement nécessaires pour exécuter le code (et uniquement ceux là).
Un exemple
my_TBA_project
|
|-- README.md
|-- actions.py # classe Actions : les interactions
|-- character.py # classe Character : les PNJ
|-- command.py # classe Command : la structure d'une commande
|-- config.py # fichier de configuration
|-- game.py # classe Game : la classe principale
|-- item.py # classe Item : les objets
|-- player.py # classe Player : le joueur
|-- room.py # classe Room : les lieux
|-- test.py # classe Test : les tests automatisés
|-- video.mp4 # vidéo de présentation au format MP4
|-- win.py # classe Win : les conditions de victoire, de défaite
Le fichier principal game.py permet de lancer le jeu avec la commande
$ python game.py
Le fichier config.py contient les paramètres de configuration du jeu (description des lieux, des items, des PNJ, etc.).
Le fichier README.md décrit entièrement le projet. Il doit être rédigé en Markdown et structuré en sections :
le guide utilisateur : comment installer votre jeu, sa description (l’univers, les conditions de victoire, les commandes, la quête, etc.), comment y jouer, etc. ;
le guide développeur : le diagramme de classes. Mermaid est un outil pratique pour générer des diagrammes à partir de représentation textuelles ;
les perspectives de développement (ce que vous imaginez pour améliorer votre jeu) ;
La vidéo (3 mn max) doit montrer la map du jeu, les personnages, les objets, un parcours gagnant et un parcours perdant. Elle doit être commentée. OBS Studio est une solution open source performante pour réaliser cette vidéo.
Important
L’activité du dépôt sera analysée pour identifier le travail de chacun. Les commits doivent être réguliers et équilibrés entre les membres du binôme.
Evaluation
Le projet sera évalué sur la base des critères suivants :
la fonctionnalité du code ;
0 : il y a une erreur à l’exécution ;
1 : une erreur se produit parfois ;
2 : le code fonctionne.
la qualité du code (évaluée avec des outils tels que Pylint, Ruff, etc…) ;
1 : le travail est trop loin des attentes ;
2 : il y a quelques améliorations à apporter ;
3 : le travail correspond à ce qui est attendu ;
4 : le travail est supérieur à ce qui est attendu ;
la qualité du jeu (jouabilité, intérêt, etc.) ;
1 : le travail est trop loin des attentes ;
2 : il y a quelques améliorations à apporter ;
3 : le travail correspond à ce qui est attendu ;
4 : le travail est supérieur à ce qui est attendu ;
la qualité du dépôt ;
1 : le travail est trop loin des attentes ;
2 : il y a quelques améliorations à apporter ;
3 : le travail correspond à ce qui est attendu ;
4 : le travail est supérieur à ce qui est attendu ;
la qualité de la vidéo de présentation.
1 : le travail est trop loin des attentes ;
2 : il y a quelques améliorations à apporter ;
3 : le travail correspond à ce qui est attendu ;
4 : le travail est supérieur à ce qui est attendu ;