Clients & Commandes

Cette page décrit en détail le fonctionnement des clients et de leurs commandes dans SnackAnarchy.
Elle s’appuie principalement sur les modules :

• game/client.py
• game/dishes.py
• game/state.py

Apparition des clients

Les clients sont gérés par l’état global du jeu (GameState) et apparaissent selon plusieurs facteurs :

• la réputation des deux restaurants (tacos / kebab),
• le nombre de clients déjà présents sur la carte,
• des paramètres de timing et de probabilité définis dans config.py.

Dans GameState.spawn_client() :

• un nouveau client est créé avec :
  • une zone de départ (souvent la rue, zone="street"),
  • une cible ("tacos" ou "kebab") choisie en fonction de la réputation,
  • un chemin vers la porte de son restaurant,
  • des timers internes (patience, temps avant fuite, etc.) ;
• certains clients peuvent être baladeurs (sans restaurant cible) et errer dans la rue.

Chaque client possède notamment :

• une position sur la carte,
• un état (en file, servi, parti, en colère, mort…),
• une commande (un ou plusieurs plats),
• des valeurs de patience et de satisfaction.

Génération des commandes

Les commandes sont décrites via les structures de game/dishes.py.
Un plat typique contient :

• un nom (ex. Tacos XXL, Kebab),
• une liste d’ingrédients,
• parfois un temps de préparation ou des étapes spéciales.

Lorsqu’un client atteint la zone de commande de son restaurant :

1. GameState lui assigne une commande à partir de la liste de plats disponibles.
2. Le plat est stocké sur le client (par ex. client.dish).
3. L’UI de commande et les bulles de pensée affichent le plat demandé.

Servir un client

Le service d’un client suit en général ce flux (simplifié) :

1. Le joueur prépare le plat dans son restaurant (voir les systèmes d’inventaire, d’équipements et de mini‑jeux).
2. Quand il est prêt, il se place à portée du client.
3. Dans GameState.handle_interaction() :
   • on vérifie que le joueur est bien dans son propre restaurant (player.current_zone == owns_restaurant) ;
   • si un client est à portée et ciblé, un mini‑jeu de service est lancé (MiniGame(client.dish.name)).
4. À l’issue du mini‑jeu :
   • si le mini‑jeu est réussi et que le stock est suffisant :
     • les ingrédients requis sont consommés (can_serve_dish + use_recipe),
     • le client passe à l’état servi,
     • le joueur gagne de l’argent et de la réputation ;
   • si le mini‑jeu est réussi mais stock insuffisant :
     • le jeu affiche une rupture de stock,
     • pas de pénalité directe de réputation mais le client peut s’énerver en attendant ;
   • si le mini‑jeu est raté :
     • le client reste en attente, ce qui augmente le risque qu’il perde patience.

Patience, colère et fuite

Chaque client possède un timer de patience décrémenté régulièrement dans GameState.update() :

• tant que la patience est positive, le client affiche une humeur neutre ou satisfaite ;
• en dessous de certains seuils, il passe en pré‑colère puis colère (changement de sprite ou d’icône) ;
• si la patience tombe à zéro :
  • le client quitte la file ou le restaurant,
  • l’état devient parti en colère,
  • le restaurant concerné perd de la réputation.

La vitesse de décroissance de la patience peut dépendre de :

• la longueur de la file,
• certains sabotages (ex. ralentissements),
• des événements globaux.

Impact sur le score et la réputation

Les règles de scoring liées aux clients sont centralisées dans game/state.py.
Elles peuvent varier selon la version du jeu, mais suivent généralement ces principes :

• Client servi correctement et dans les temps :
  • +20€ pour le joueur qui sert,
  • +2% de réputation pour son restaurant.
• Client parti en colère :
  • -1% de réputation pour le propriétaire du restaurant ciblé.
• Client tué dans son propre restaurant :
  • -5% de réputation pour ce restaurant.
• Client tué dans le restaurant adverse :
  • -1% de réputation pour le propriétaire,
  • feedback visuel de sabotage pour l’attaquant.

Plus la réputation d’un restaurant est élevée, plus il attire de nouveaux clients :
spawn_client() utilise cette réputation pour biaiser la probabilité qu’un client choisisse le tacos ou le kebab.

Résumé : cycle de vie d’un client

1. GameState.spawn_client() crée un nouveau client (zone de départ, cible, timers).
2. Le client marche vers la file de son restaurant.
3. Une commande lui est générée via dishes.py.
4. Le joueur prépare et tente de servir le plat (mini‑jeu + vérification de stock).
5. Selon le résultat :
   • le client est servi → argent + réputation ;
   • il attend trop → colère, puis fuite → perte de réputation ;
   • il est tué → grosse pénalité de réputation.

Ce système relie directement la qualité du service (rapidité, exactitude) à la réputation et donc au flux futur de clients.