La brigade

La correction la plus importante

La brigade doit dépasser le joueur

Ma première version posait comme règle qu'un employé reste toujours plus lent que le joueur. C'est faux, et ça tuait le genre. La courbe visée est celle des jeux d'accumulation : au début, faire le travail soi-même est nettement plus rapide ; à terme, la brigade est plus rapide de plusieurs ordres de grandeur.

Concrètement, à maturité : tu veux livrer une assiette, le serveur t'a déjà doublé. Tu ouvres le menu de recettes, le cuisinier a déjà posé deux plats sur l'étagère. Tu peux toujours mettre la main à la pâte, et ça ne gêne jamais — mais ça cesse d'être ce qui fait tourner la boutique.

Le joueur qui contribue reste un choix valable dans les premières heures. Ensuite sa vraie contribution est ailleurs : il plonge, il rapporte des ingrédients, il achète des postes et des gens.

Le point structurant

L'ardoise avant tout le reste

Aujourd'hui une commande n'existe nulle part. Elle est un champ sur le client, lisible seulement à proximité, et qui s'efface de sa mémoire après order_memory_seconds. C'est de la mémorisation, pas une file de travail. Un cuisinier automatique n'a rien à lire, un serveur n'a nulle part où écrire.

Ce qu'une ligne contient

{
  "table": 3,              // un tabouret par table: l'indice désigne le client
  "recipe": "pepper_scramble",
  "state": "pending",      // pending → cooking → ready
  "station": "",          // poste qui l'a prise, vide tant que personne
  "superior": false,       // passé par l'épicerie
  "written_at": 812.4
}

Comment une ligne s'écrit

Repérer une commande l'inscrit. Une fois l'ardoise débarrée, le geste de lecture actuel — s'approcher assez d'un client qui attend — écrit directement la ligne. Plus de mémorisation, plus d'effacement au bout de huit secondes : ce qui a été vu une fois est acquis.

Le serveur fait exactement la même chose, à sa propre distance de repérage. C'est le même code, appelé par deux acteurs différents.

Trois règles qui évitent les conflits :

• Un client qui n'a été vu par personne n'est pas sur l'ardoise. C'est ce qui donne un métier au serveur, et ce qui garde le geste du joueur utile.
• Un poste réserve sa ligne en passant en cooking : deux cuisiniers ne se disputent jamais la même commande, et le joueur non plus.
• L'ardoise est persistante, comme les assiettes et les convives.

Statistique associée : order_board_slots (base 6). Une ardoise pleine empêche d'inscrire une commande de plus — c'est le levier qui empêche la brigade de tourner à vide.

Les lieux

Un poste, pas un fourneau

Le restaurant n'a qu'une cuisson à la fois : cooking_recipe et cooking_remaining sont des champs uniques sur la scène. Un deuxième four est impossible tant que c'est le cas. La généralisation suit le précédent des tables : une liste de postes, un compte par statistique, aucune position écrite à la main.

L'épicerie : la fonction de raffinage

C'est le meilleur des trois postes, parce qu'il ne fait pas la même chose que les autres. Il ne cuisine pas : il reprend un plat déjà cuit et lui ajoute une étape, au terme de laquelle le plat devient supérieur — pas au hasard, à coup sûr.

fourneau → assiette normale → épicerie → assiette supérieure → service

prix de vente = prix de base × superior_payout   // base 1.5

Une seule statistique, superior_payout, dit ce que vaut le raffinage. Une branche d'upgrades la monte : 1.5, puis 1.8, puis 2.2. C'est une progression qui ne demande aucun contenu neuf, seulement du réglage — le genre de levier qui vieillit bien.

Le coût est du temps et un poste occupé. À toi de décider si ça vaut le coup, et cette décision change avec le nombre de cuisiniers : à un cuisinier, raffiner c'est perdre du débit ; à quatre, c'est de la marge gratuite.

Le comptoir takeout : une cuisine sur la rue

Le comptoir est adossé au mur nord, plus près du trottoir que l'ancien comptoir à boissons. Il ne vend plus un article abstrait : le joueur choisit une recette maître parmi les vrais plats, puis la cuisine en série. Chaque exemplaire consomme les ingrédients de la recette et rejoint une réserve bornée.

Deux files, deux décisions

evaluate_takeout_join() est indépendant de evaluate_queue_join(). Un passant intéressé par la recette maître rejoint la file extérieure du comptoir; il ne franchit jamais la porte, ne réserve aucune table et ne crée aucune vaisselle.

Le joueur ou un cuisinier produit; le comptoir sert

Le joueur peut tenir le poste exactement comme un four. Un cuisinier oisif compare la priorité takeout à celle de l'ardoise, réserve le comptoir et le maintient jusqu'au plafond. Son rendement combine craft, station_affinity.takeout, son affinité de recette et la vitesse propre au comptoir.

Le service au client reste automatique : le délai dépend de takeout_service_speed. Ce partage garde un geste de cuisine intéressant sans transformer chaque vente de rue en corvée. Le manque de stock ne retire pas de réputation; le passant continue sa route.

Ventes pendant une plongée

Le stock déjà cuisiné peut se vendre hors scène selon sidewalk_traffic, l'attrait et la vitesse de service. Aucun plat n'est produit magiquement pendant l'absence. Le compte rendu indique les plats vendus, les pièces encaissées et la rupture éventuelle.

• Aucune vaisselle. Le plat takeout part avec le client et ne touche jamais l'étagère ni le lave-vaisselle.
• File distincte. Elle part de la rue vers le comptoir, loin de la file d'entrée du restaurant.
• Stock garanti. Chaque personne admise dans la file est couverte par un plat déjà fini.
• Affinité dédiée. takeout appartient au vocabulaire des postes dans Godot, PHP et l'éditeur.
• Sauvegarde 10. Une ancienne quantité de boissons est migrée vers le stock de la recette maître au chargement.

Ce que ça change dans le code existant

Les trois champs de cuisson deviennent une entrée dans un tableau de postes. player_is_tending_stove() devient tended_station() : rester appuyé sur l'action près d'un poste accélère ce poste. Une recette gagne un champ station (défaut stove) ; une recette dont le poste manque disparaît du menu et des commandes toute seule, sans code dédié.

Nouveau

La console de gestion

Choisir le menu du jour depuis le fourneau n'a déjà plus tellement de sens ; avec une brigade, ça n'en aura plus du tout — le joueur ne sera plus celui qui cuisine. Un meuble à part, dans un coin de la salle :

• Le menu du jour : quelles recettes sont proposées, dans la limite de menu_slots. C'est l'écran qui existe déjà, déplacé.
• Ouverture et fermeture : un interrupteur explicite. Aujourd'hui la fermeture est subie — plus d'ingrédients, le magasin ferme. Pouvoir fermer volontairement, c'est pouvoir réapprovisionner sans qu'une file s'accumule dehors.
• L'état de la brigade : qui est employé, à quel poste, et ce que ça produit. C'est aussi là qu'on embauche.
• Le débit réel : repas par minute sur la fenêtre récente. La donnée existe déjà (served_rate()), elle n'est visible nulle part — et c'est précisément le chiffre qui doit rendre lisible chaque achat de brigade.

À construire en phase 2, avec les postes : c'est la même refonte, et le fourneau doit de toute façon être touché.

Nouveau

L'étagère

Avec plusieurs cuisiniers qui posent des plats et plusieurs serveurs qui les prennent, l'étagère devient le point de rencontre de tout le restaurant. Elle ne peut pas rester un compteur.

• Des emplacements, pas une capacité. Statistique shelf_slots, dessinés comme les tables — une grille dont on ne montre que les cases ouvertes.
• Chaque emplacement montre son plat : la silhouette de la recette, sa couleur, et un liseré si l'assiette est supérieure. Ce que le joueur s'apprête à ramasser doit être sans équivoque.
• Le plus proche gagne. Le ramassage vise l'emplacement le plus proche du joueur, avec un halo sur celui qui est visé. Pas de menu, pas d'ambiguïté.
• Le takeout n'emploie pas l'étagère : ses plats finis vivent dans leur réserve propre et ne deviennent jamais des assiettes de salle.

Les gens

Un employé est une donnée d'auteur

Nouvelle collection employees, du même rang que enemies ou recipes, avec sa racine d'adressage, ses compteurs vivants et ses crochets.

employees.chef_marguerite.total_dishes_cooked   // compteur vivant
employees.pablo.hired                          // valeur calculée
employees.pablo.on_hired                       // crochet

Les modifiers travaillent gratuitement. Un employé embauché pose ses modificateurs sous une source nommée, comme un équipement ; le renvoyer appelle remove_modifiers_by_source(). Tout ce qui se traduit en statistique existante ne demande aucun code neuf.

Les slots, et le prix de la fidélité

server_count   base 0   // 1, puis 2, puis 3 par upgrades
cook_count     base 0

Les nœuds first_server, second_server… ajoutent +1. Aucun code ne connaît leurs noms — la leçon des tables, où second_table et third_table étaient codés en dur et ont dû être défaits.

Un employé de portée dimension est perdu au changement de dimension et se rachète au prix fort, alors que le slot, lui, est acquis. C'est la seule dépense récurrente du système, et elle est volontaire : rien ne t'oblige à reprendre le même. Un employé meta reste, et son prix d'embauche doit refléter ça.

Le vocabulaire

Les compétences

Vocabulaire fixe déclaré dans un constant, comme ROOM_BEHAVIOURS. Toutes multiplicatives : c'est ce qui permet à la brigade de finir des ordres de grandeur devant le joueur.

Communes

Serveurs

Cuisiniers

Les boucles

Ce que fait vraiment un employé

Le serveur

OISIF → la tâche la plus prioritaire dans son rayon
  1. un client assis sans commande inscrite  → repérer, écrire sur l'ardoise
  2. une assiette ready sur l'étagère            → porter jusqu'à la table
  3. une assiette sale sur une table         → ramasser, laver
  4. quelqu'un dans la file, un verre prêt   → offrir, rendre de la patience
  rien                                       → retour au poste d'attente

L'ordre est pondéré par ses compétences : tidiness élevée remonte le débarrassage, attentiveness la prise de commande. Deux serveurs opposés se répartissent le travail sans qu'aucun code ne les coordonne.

Le cuisinier

OISIF → un poste libre de son genre + une ligne pending qu'il peut faire ?
  oui → réserve la ligne (cooking), occupe le poste, cuit
        à la fin: pose sur l'étagère, passe la ligne en ready
  non → attend au poste

« Qu'il peut faire » veut dire : ingrédients présents, vaisselle disponible, poste requis libre. Le choix entre plusieurs lignes possibles est le seul endroit où nose intervient. Un cuisinier affecté à l'épicerie reprend les assiettes normales de l'étagère au lieu de lire l'ardoise.

Le vrai enjeu

Le magasin qui tourne sans toi

GameState garde encore l'échafaudage du futur restaurant entièrement autonome :

restaurant_operations = {
  "automated_cooking": false,
  "automated_service": false,
  "automated_cleanup": false,
  "automated_supply": false,
  "pending_simulation_seconds": 0.0,
}

Ces quatre drapeaux ne sont pas encore allumés par la brigade. Le takeout possède toutefois une voie plus stricte et déjà active : des secondes s'accumulent hors scène seulement lorsqu'un stock fini peut réellement se vendre.

• automated_cooking : futur calcul des recettes et ingrédients hors scène;
• automated_service : futur débit de la salle;
• automated_cleanup : future gestion de la vaisselle;
• automated_supply : futur réapprovisionnement.

Au retour de plongée, le takeout convertit ces secondes en ventes selon le trafic, l'attrait et la vitesse de service, puis borne le résultat par takeout_stock. Les cuisiniers ne fabriquent rien en l'absence du joueur : le compte rendu montre uniquement ce qui était prêt et a trouvé preneur.

Tranché

Les décisions

charisma perd son contrepoids en supprimant le salaire : sans part prélevée, le pourboire est du gain pur. Il faudra que le charisme coûte à l'embauche plutôt qu'au service — un serveur charismatique doit être nettement plus cher qu'un serveur rapide.

La route

Huit phases

Chaque phase est jouable et testable seule. Aucune ne laisse le jeu à moitié.

1. L'ardoise

   Le tableau, ses lignes, sa persistance, son affichage. Repérer un client inscrit sa commande. Fin de la mémorisation. Aucun employé, et déjà un gain net.

2. Les postes et la console

   La cuisson unique devient une liste de postes pilotée par stove_count. Deuxième four. La console de gestion prend le menu et l'ouverture. Le gros de la refonte est ici, sans concept neuf.

3. L'étagère

   Emplacements visibles, plat identifiable, ramassage sans ambiguïté. Petite phase, mais tout ce qui suit passe par là.

4. L'épicerie

   Genre de poste spices, drapeau supérieur sur l'assiette, superior_payout et sa branche d'upgrades. Aucune recette neuve : ce sont les mêmes plats, mieux vendus.

5. Le comptoir takeout

   Poste takeout contre le mur nord, recette maître, réserve bornée et seconde file depuis la rue. Le joueur peut le tenir immédiatement; les cuisiniers le prennent ensuite selon takeout_priority. Le service automatique ne dépend ni des tables ni de la vaisselle.

6. Les employés en données

   Collection employees, page de gestion, vocabulaire de compétences, embauche, slots par statistique. Les modifiers s'appliquent dès cette phase : un employé embauché est déjà un bonus avant même de bouger.

7. Les serveurs

   L'agent qui marche : repérage, écriture, service, débarrassage, priorités pondérées. La phase la plus longue et la plus visible.

8. Les cuisiniers

   L'agent aux postes : lecture de l'ardoise, réservation, cuisson, dressage. Les affinités entrent en jeu. C'est ici que la courbe exponentielle commence à se voir.

9. Le magasin autonome

   Les quatre drapeaux s'allument selon la brigade, pending_simulation_seconds se dépense au retour de plongée, la réserve devient la seule limite. La phase qui donne rétroactivement un sens à toutes les autres.

Neuf phases donc, le takeout s'insérant après l'épicerie : il réutilise les recettes et le travail continu, mais garde son stock et sa clientèle séparés.

Le coût

Ce que ça demande au schéma

Trois montées de version, pas une : 16 pour l'ardoise, les postes et l'étagère, 17 pour l'épicerie et le champ station, 18 pour les employés. Grouper serait plus rapide à écrire et beaucoup plus difficile à déboguer.

Le smoke test couvre aussi le takeout de bout en bout : sélection du plat, cuisson joueur, remplissage autonome par un cuisinier, plafond de stock, file séparée, délai de service, vente sans vaisselle, sérialisation et ventes d'absence.

Il reste deux détails

Feuille de réponse

B1  recette maître            : une      (pas de mélange dans la réserve)
B2  production                : joueur ou cuisinier
B3  service au passant        : automatique, selon le débit
B4  refus au comptoir         : aucune pénalité

Ces choix sont maintenant construits et couverts par le smoke test. Les réglages d'équilibrage restent dans les sept statistiques takeout_*, sans modifier la boucle.