Comme je dois organiser un atelier de réflexion systémique dans un avenir proche, j'ai besoin d'un jeu de bière pour le démarrer.

Le jeu de la bière lui-même se compose de quatre personnages : détaillant, grossiste, distributeur et usine. Grâce à la nature différée de la logistique, comprendre la perspective du système et mieux comprendre les limites du système.

Comme il s'agit d'un atelier de quelques heures, je souhaite que ce jeu de bière remplisse les fonctionnalités suivantes.

C'est un jeu multijoueur.

Le jeu de la bière lui-même verra de nombreux participants jouer différents rôles dans la chaîne d'approvisionnement, mais j'aimerais pouvoir avoir plusieurs chaînes d'approvisionnement en compétition en même temps pour voir qui obtient le meilleur score. Ainsi, nous pouvons en même temps en apprendre davantage sur leurs stratégies système.

L'hôte du jeu devrait pouvoir voir le statut de chacun.

Comme plusieurs équipes s'affrontent en même temps, en tant qu'hôte, je dois être en mesure de voir comment chaque équipe progresse et marque en ce moment.

Le déroulement du jeu doit être simple et facile à contrôler le rythme.

Comme je l'ai dit au début, il s'agit d'un atelier court, je dois donc mettre tout le monde au courant rapidement et je dois être capable de contrôler les détails de chaque tour.

De plus, un chronomètre apparaît dans l'interface utilisateur du joueur au début de chaque tour, faisant avancer le rythme du jeu en décompte.

Pouvoir personnaliser les personnages.

Un jeu de bière classique se compose de quatre personnages, mais plus il y a de personnages, plus le jeu sera long. J'aimerais donc ajuster le rythme du jeu pour qu'il soit préférable d'avoir trois personnages.

Après avoir cherché, j'ai découvert que ni les projets open source ni les projets déjà en ligne ne peuvent répondre parfaitement à ces exigences. Alors, je ferais mieux d'en fabriquer un moi-même.

Projet de jeu de bière

https://github.com/wirelessr/beer_game

Interface utilisateur de l'hôte

Interface utilisateur du joueur

L'ensemble du projet est développé et testé par les entreprises avec une couverture de plus de 90 %, alors n'hésitez pas à l'utiliser.

Préparation

Créez un fichier pour les secrets dans le dossier du projet. Vous devriez me voir le copier dans le Dockerfile.

.streamlit/secrets.toml

[mongo]
uri = ""

[admin]
key = ""

[player]
key = ""

Puisque ce projet utilise MongoDB, vous devez remplir le lien avec le mot de passe de votre compte. De plus, admin.key et player.key correspondent aux champs clés de l'interface utilisateur.

Après tout, je télécharge l'application sur le cloud public, j'ai donc toujours besoin d'un mécanisme d'authentification de base. Si vous utilisez uniquement localement et que l'authentification pose problème, vous pouvez supprimer le code source correspondant.

Installation et utilisation

Ce projet est associé à un Dockerfile, il peut donc être exécuté directement avec Docker.

docker build -t beer_game .
docker run --rm --name beer -p 8501:8501 beer_game

Pour le développement, en plus de requiremnts.txt, Requirements-test.txt, qui exécute les tests unitaires, doit également être installé. Ensuite, vous pouvez exécuter tous les tests unitaires via le Makefile.

pip install -r requiremnts.txt
pip install -r requirements-test.txt
make test

Flux de jeu

L'ensemble du jeu est divisé en un mode hôte et un mode participant, qui correspondent aux options dans le coin supérieur de l'interface utilisateur.

L'hôte attribue d'abord un game_id pour créer le jeu, et tous les participants doivent remplir le player_game avec cet identifiant.

Tous les acteurs de la même chaîne d'approvisionnement doivent utiliser le même player_id, cet identifiant est donc également connu sous le nom d'ID de la chaîne d'approvisionnement, et les participants avec le même player_id sont séparés en rôles par player_role.

Vous pouvez voir le statut sur l'écran de l'hôte lorsqu'un participant rejoint.

Regardons à quoi ressemblerait une itération complète du point de vue de l'hôte.

Tous les composants qui doivent être manipulés sont dans cette image, et chaque tour commence en appuyant sur le bouton Actualiser et se termine en appuyant sur la semaine suivante.

Quant au nombre de commandes à envoyer à toutes les chaînes d'approvisionnement au cours de ce cycle, elles seront déclenchées par la commande.

Il convient de mentionner que le lieu de commande lui-même est idempotent, vous pouvez donc modifier le numéro et appuyer à nouveau dessus, le dernier numéro sera utilisé. L'ordre de passage de l'interface de chaque participant sera également idempotent.

Une fois que l'hôte a passé la commande, le joueur de la boutique peut prendre la commande.

De même, chaque rôle dans la chaîne d'approvisionnement commence par Actualiser et se termine par Passer la commande, le joueur du magasin effectuant l'action suivi par le joueur du détaillant, et ainsi de suite.

Enfin, revenons à l'hôte, qui peut appuyer à nouveau sur Actualiser pour voir tous les statuts du tour, et sur Semaine prochaine pour terminer le tour.

Détail du jeu

Plusieurs choses sont réellement effectuées pendant l'actualisation.

1. il réapprovisionne l'inventaire en aval en fonction des commandes passées il y a quatre semaines.
2. il reçoit les commandes de l'amont.
3. décide combien vendre en fonction de l'inventaire qu'il peut vendre.

Puisque Place Order est idempotent, Refresh lui-même est également idempotent.

Travaux futurs

Il répond désormais à tous mes besoins, mais certaines améliorations pourraient être apportées.

Par exemple, bien que l'hôte puisse voir le statut de tous les participants, il serait utile d'avoir un graphique pour montrer l'évolution de l'inventaire et les informations sur les coûts au fil du temps, ce qui serait utile pour revoir le jeu une fois terminé. .

Il y a aussi un problème plus fondamental : l'interface utilisateur actuelle n'a aucune couverture de test, principalement parce que le déroulement du jeu actuel est assez simple. Quelques clics sur l'interface utilisateur couvriront tout le flux de l'interface utilisateur, je ne m'appuie donc pas autant sur les tests automatiques. Cependant, s'il y a une modification de l'UI, cela sera encore un peu fastidieux, il serait donc préférable de faire un test unitaire de l'UI.

Dans l'ensemble, ces exigences sont des optimisations, mais leur absence n'affecte pas la fonctionnalité.

Si vous avez des idées supplémentaires, vous pouvez également simplement soumettre une pull request, les contributions sont les bienvenues.