Guide du langage · GardenScript 0.6 / farm.v1
GardenScript : une stratégie que l’on peut lire, tester et rejouer.
GardenScript est le langage de règles de GardenArena. Il décrit quoi faire selon l’état d’une ferme simulée : récolter, arroser, préserver les réserves ou préparer les matériaux. Un joueur ou son assistant écrit la politique une fois ; le moteur Rust la compile et l’exécute sans rappeler une IA chaque jour.
Tu n’as pas besoin de programmer pour commencer. La ferme inclut trois politiques et des réglages sans code. Ce guide permet ensuite de comprendre ce que ces règles font réellement, ou de transmettre une mission précise à ton propre assistant.
Six décisions pour préparer la journée
Le profil de ferme possède six canaux, évalués dans cet ordre. Chaque canal choisit une intention depuis le même instantané du matin. Les travaux sont ensuite exécutés avec les ressources encore disponibles.
| Canal | Question de gestion | Exemple d’intention |
|---|---|---|
care | Faut-il réapprovisionner les animaux ? | stock_up |
harvest | Quelles productions disponibles récolter ? | all_ready |
irrigation | Quand intervenir sur les cultures ? | dry_only |
reserves | Acheter des provisions, de l’eau ou attendre ? | buy_food |
materials | Préparer les tuteurs ou le compost ? | tomato_stakes |
kitchen | Moudre, cuisiner ou préparer la prochaine culture ? | resow |
La première condition vraie d’un canal l’emporte. otherwise prévoit le cas restant. Une intention n’est pas une promesse de réussite : sans cible disponible ou sans ressources, le travail peut ne pas avoir lieu. Le rapport conserve les actions acceptées et refusées.
Un programme complet, validé par Rust
Voici « La Prévoyante », une politique incluse par GardenArena. Ce n’est ni une stratégie attribuée à un fournisseur d’IA, ni une solution optimale. Le texte ci-dessous est exactement celui utilisé dans notre comparaison d’arrosage publiée.
garden "La Prevoyante" version 0.6
domain farm
ruleset: farm.v1
decide care:
when resource.drinking_water_ml < 16000ml => stock_up
when resource.feed_g < 2500g => stock_up
when sheep.hay_g < 2000g => stock_up
otherwise => maintain
decide harvest:
otherwise => all_ready
decide irrigation:
otherwise => dry_only
decide reserves:
when pantry.reserve_days < 3day => buy_food
when resource.irrigation_l < 100L => buy_water
otherwise => keep
decide materials:
when garden.tomato_stakes_count == 0count => tomato_stakes
when compost.raw_g >= 500g => compost
otherwise => keep
decide kitchen:
when grain.unsown_count > 0count => resow
when kitchen.flour_g >= 200g and kitchen.raspberries_g >= 300g and kitchen.table_eggs_count >= 2count => bake
when grain.wheat_g >= 600g and kitchen.flour_g < 200g => mill
otherwise => keep
Dans reserves, la première règle demande des provisions si la réserve alimentaire du matin est inférieure à trois jours. Si cette règle s’applique, la règle d’achat d’eau de ce même canal ne sera pas choisie ce matin-là. Cet ordre crée un arbitrage, pas deux achats indépendants.
stock_up peut regrouper plusieurs réapprovisionnements : il ne se limite pas nécessairement au seul stock qui a déclenché la règle. Les intentions sont décrites plus précisément par le catalogue du moteur.
Pourquoi une règle différente ne change-t-elle parfois rien ?
La règle choisit une intention ; l’état de la ferme détermine les travaux possibles. Dans notre exemple, remplacer dry_only par comfort change l’intention dès le départ, mais les commandes et l’état simulé à J3 restent identiques. Le premier travail différent apparaît pendant la préparation de J4.
Lire l’exemple : une règle, quatre arrosages et 78 litres d’écart →
Un langage fermé, pas du code libre
Le profil 0.6 accepte des conditions avec and et les comparateurs < <= > >= ==. Il ne propose pas de boucle, de variable mutable, d’appel réseau, d’accès aux fichiers ou de code Python. Le or des autres profils n’est pas accepté dans ce profil de ferme.
Chaque source est limitée à 16 Kio ASCII, avec six canaux obligatoires et un budget de 512 unités de machine virtuelle. Le catalogue décrit 29 capteurs avec leurs unités et leurs bornes. Le texte exact est lié à une empreinte SHA-256 ; modifier son commentaire change cette empreinte de source, sans nécessairement changer les décisions du programme compilé.
Un essai applique les règles pendant une à sept journées, avec un plafond d’achats de jeu. Il peut s’arrêter plus tôt après une difficulté ou une limite. La politique n’accède pas aux observations futures et ne revient pas effacer une mauvaise journée.
Joueur, assistant, MCP et API : qui fait quoi ?
- Le joueur choisit une ferme, un objectif et une période limitée.
- Lui-même ou son assistant prépare les règles.
- Rust vérifie le programme et calcule les conséquences.
- Le joueur lit le rapport, exporte et choisit explicitement la suite de sa partie.
Le MCP public expose farm_policy_get, farm_policy_validate et farm_policy_run. L’API Pro privée propose un autre transport pour les intégrations, avec clés et jobs. Ni l’un ni l’autre n’est un modèle d’IA supplémentaire. Les éventuels frais de ton assistant sont distincts des calculs du site.
Pour le protocole complet : devoir de ferme pour un assistant, sources et compilation du noyau. Les duels végétaux, poulailler et bambou conservent leurs versions propres : ce profil 0.6 ne réécrit pas les saisons historiques.