Bouse-Town

Jeu de gestion de ville satirique : rendre chaque choix lisible

by Équipe Bouse-Town8 min read

Un bon jeu de gestion de ville satirique ne vous demande pas seulement de cliquer plus vite. Il vous montre ce que vous gagnez, ce que vous risquez et qui paie réellement la conséquence.

La satire fonctionne quand le système reste compréhensible. Vous prenez une décision absurde, puis la ville vous présente une facture tout à fait logique. Si le jeu cache les règles ou change le résultat pour vous punir, la blague disparaît derrière l'arbitraire.

Montrer le prix avant le bouton

Le prix doit apparaître avant le bouton : chaque décision importante annonce ses ressources, son temps, son risque et les conditions déjà connues. Le joueur n'a pas besoin de connaître tout le futur, mais il doit pouvoir distinguer un pari d'une taxe certaine.

Selon les recommandations du W3C sur les libellés et instructions, une interface doit fournir les libellés ou instructions nécessaires lorsque l'utilisateur doit saisir ou choisir une information. Dans un jeu, cette règle soutient un contrat simple : nommer ce que le bouton demande avant le clic.

Une prévisualisation utile répond à quatre questions :

QuestionRéponse visible
Que vais-je dépenser ?Argent, nourriture, matériaux, énergie ou temps
Que puis-je obtenir ?Une plage de résultats ou un résultat défini
Quel risque est déjà connu ?Une probabilité, un niveau ou une explication
Qu'est-ce qui peut modifier le résultat ?Quartier, équipe, chaleur, équipement ou état sauvegardé

La surprise peut rester dans l'événement. Elle ne doit pas remplacer le contrat.

Séparer l'aléatoire de l'arbitraire

L'aléatoire produit une histoire mémorable quand le système le sépare clairement de l'arbitraire. Il devient frustrant quand le joueur ne peut pas comprendre pourquoi deux situations identiques donnent des règles différentes.

Bouse-Town utilise des flux aléatoires seedés dans son état actuel. Le même état sauvegardé peut donc résoudre un événement de manière cohérente. Le joueur conserve l'incertitude du tirage sans avoir l'impression que le jeu réécrit les dés après le clic.

Cette cohérence crée une forme de responsabilité comique : « Je savais que le marché noir chauffait le quartier, mais j'y suis retourné. » Le système n'a pas inventé votre regret. Il l'a enregistré.

Donner un coût aux raccourcis

Le coût d'un raccourci doit déplacer le problème plutôt que l'effacer. La satire peut adorer le bouton qui promet une solution immédiate, mais le système doit ensuite montrer la facture.

Un financement rapide peut augmenter la surveillance. Un logement moins cher peut réduire le confort. Une expédition rentable peut chauffer le quartier. Une amélioration spectaculaire peut consommer la ressource nécessaire au prochain palier.

Le jeu ne doit pas présenter ces échanges comme une morale universelle. Il montre une mécanique, laisse le joueur l'exploiter, puis conserve la trace du choix.

Faire rire du pouvoir, pas de la vulnérabilité

La satire du pouvoir peut viser la bureaucratie, la spéculation, les discours politiques, les tableaux de bord absurdes et les institutions qui transforment une personne en ligne de budget.

Elle ne gagne rien à utiliser la pauvreté, le handicap, l'origine, la maladie, l'addiction ou l'exclusion comme raccourci vers le mépris. Le personnage vulnérable ne doit pas devenir le décor de la blague.

Posez trois questions à chaque événement :

  1. Qui possède le pouvoir dans la scène ?
  2. Qui subit la conséquence ?
  3. La blague frappe-t-elle la règle absurde ou la personne qui la traverse ?

Si la cible reste la personne sans pouvoir, réécrivez.

Conserver les conséquences

Une conséquence doit rester visible assez longtemps pour que le joueur la relie à son choix. Gardez une trace : chaleur du quartier, dette, réputation, inventaire, état du logement, relation ou événement débloqué.

Cette trace n'a pas besoin d'être permanente. Elle doit durer assez longtemps pour que le joueur relie l'effet à sa décision.

Dans Bouse-Town, les expéditions utilisent notamment des valeurs de chaleur globale et de quartier. Répéter une action rentable dans le même endroit peut donc modifier le contexte futur. Consultez le classement des sept expéditions pour voir comment les minuteurs, les risques et la chaleur s'articulent dans le contenu actuel.

Écrire une interface qui assume l'acteur

Une interface qui assume l'acteur remplace « Action effectuée » par la décision réelle. Écrivez plutôt :

  • « J'envoie cette équipe dans le quartier. »
  • « Je dépense 12 unités de ferraille. »
  • « J'accepte ce risque. »
  • « Je reporte l'amélioration. »

Le joueur voit ce qu'il fait. Le texte peut rester drôle, mais le verbe garde le contrat clair.

Après la résolution, montrez aussi l'acteur du système : « La patrouille augmente la chaleur du quartier » explique davantage que « +25 chaleur ».

D'après les Human Interface Guidelines d'Apple sur le feedback, l'interface doit rendre la réponse à l'action perceptible et compréhensible. Bouse-Town applique ce principe à sa manière : le texte garde l'acteur et la conséquence visibles.

Utiliser l'échec pour ouvrir, pas seulement fermer

Un échec utile retire peut-être une ressource, mais il ouvre aussi une nouvelle question : faut-il changer de quartier, améliorer le camp, recruter une autre équipe ou accepter une dette ?

Le meilleur échec satirique transforme votre erreur en histoire. Le pire vous demande simplement d'attendre.

Quand un minuteur existe, il doit représenter une décision en cours, pas remplacer la décision. Le joueur doit comprendre ce qu'il a lancé et ce qui se passera à la fin.

Tester le système avec une phrase

La phrase-test vérifie le système avec le même protocole après chaque événement. Demandez au testeur de compléter :

J'ai choisi ______ parce que ______, puis le jeu a appliqué ______.

S'il ne peut pas remplir la troisième partie, la conséquence manque de lisibilité. S'il ne peut pas remplir la première, l'interface a peut-être choisi à sa place.

Selon le W3C sur l'identification cohérente, des composants qui remplissent la même fonction gagnent à rester identifiés de manière cohérente. Le protocole éditorial de cette page utilise donc la même phrase-test sur chaque événement au lieu de changer les critères en cours de route.

D'après les Xbox Accessibility Guidelines de Microsoft, le retour d'état et les informations importantes doivent rester perceptibles pour le joueur. Ce troisième contrôle complète notre méthode : contrat avant le clic, réponse après le clic, état conservé ensuite.

Bouse-Town reste un jeu satirique français en construction, destiné à iPhone et au web. Cette page décrit les principes et les systèmes confirmés dans le projet actuel ; elle ne promet pas une disponibilité publique sur l'App Store.

Une satire jouable ne cache pas tout. Elle vous tend le contrat, vous laisse signer, puis encadre soigneusement votre mauvaise décision.