Projet “Tamagotchi Terminal”

Contexte#

Tu adoptes une créature virtuelle qui vit dans le terminal. Elle a faim, se fatigue, s’ennuie. À toi d’analyser le besoin, de modéliser proprement et de coder une version jouable en PHP. Pas d’ésotérisme : on vise simple, lisible, fun.

Objectifs d’apprentissage#

• Transformer un texte en diagramme de classes UML clair.

• Concevoir une boucle de jeu avec un temps simulé.

• Gérer une petite persistance sur disque pour reprendre une partie.

• Produire une interface CLI minimale et compréhensible.

Fonctionnalités attendues#

1. Caractéristiques

   • La créature possède au moins 3 valeurs numériques (ex. faim, énergie, amusement).

   • Les valeurs doivent rester dans une plage raisonnable (par ex. 0–100).

2. Temps simulé (tick)

   • À chaque tour/tick, les valeurs évoluent (au moins une monte, au moins une descend).

   • Définir au moins un état final qui met fin à la partie (ex. “game over” si faim trop haute).

3. Actions utilisateur

   • Au moins 3 actions différentes (ex. nourrir, jouer, dormir) qui modifient les valeurs.

   • Certaines actions peuvent devenir indisponibles selon la situation (ex. impossible de jouer si trop fatigué).

4. Boucle de jeu & menu

   • Au lancement, afficher un menu :

     • Reprendre une partie si une sauvegarde existe.

     • Nouvelle partie (réinitialise).

     • Quitter.

   • Pendant le jeu : proposer les actions disponibles, appliquer l’action, avancer le temps, réafficher l’état.

5. Persistance

   • Sauvegarde automatique ou manuelle dans un fichier local (format libre : JSON, CSV, ou texte simple).

   • La sauvegarde doit contenir tout le nécessaire pour reprendre (valeurs, nom, progression, etc.).

6. Affichage minimal (CLI)

   • Afficher le nom de la créature, ses valeurs et un état/humeur (une étiquette ou un petit émoji ASCII).

   • Une représentation simple type barres ou nombres suffit (pas de chef-d’œuvre ASCII requis).

7. Fin de partie

   • Quand la condition de fin est atteinte, afficher un court bilan (ex. nombre de tours, dernière action) et proposer de revenir au menu.

Livrables#

• Diagramme de classes UML (image) montrant les classes principales, attributs importants, et liens pertinents.

• Code PHP (plusieurs fichiers .php ; pas d’arborescence imposée).

Scénarios d’acceptation (à couvrir en démo)#

• Démarrage : menu affiché ; si un fichier de sauvegarde existe, la reprise fonctionne.

• Cycle de jeu : enchaîner plusieurs actions fait évoluer les valeurs conformément à votre description.

• Sauvegarde/Reprise : quitter puis relancer permet de retrouver la partie au même état.

• Fin de partie : la condition choisie déclenche bien l’arrêt et le bilan.

Contraintes techniques#

• PHP en exécution CLI (≥ 8.x).

• Entrées/sorties standard (lecture clavier, affichage texte).

• Fichier de sauvegarde dans le même dossier que le script, nom libre (ex. save.json).

Libertés & extensions (optionnel)#

• Magasin avec items (jouets, nourriture, potions…) achetés avec une monnaie simple :

  • Un catalogue d’items, un inventaire, des effets sur les valeurs.

  • Prix fixes ; pas de persistance complexe nécessaire au-delà de l’inventaire.

• Difficulté qui augmente avec le temps (ex. faim qui grimpe plus vite).

• Skin d’humeur : visage ASCII qui change selon la situation.

Conseils de clarté (courts)#

• Décrivez en 5–10 lignes vos règles (évolution par tick + effets de chaque action).

• Gardez des noms explicites et un fichier de sauvegarde lisible.

• Si ça devient confus, réduisez : mieux vaut 3 règles propres que 10 bancales.