Como necesito organizar un taller de pensamiento sistémico en un futuro cercano, necesito un juego de cerveza para comenzar.

El juego de la cerveza consta de cuatro personajes: minorista, mayorista, distribuidor y fábrica. A través de la naturaleza de retraso de tiempo de la logística para comprender la perspectiva del sistema y poder tener una mejor comprensión de los límites del sistema.

Como este es un taller de unas pocas horas, quiero que este juego de cerveza cumpla con las siguientes características.

Es un juego multijugador.

El juego de la cerveza en sí tendrá muchos participantes que desempeñarán varios roles en la cadena de suministro, pero me gustaría poder tener varias cadenas de suministro compitiendo al mismo tiempo para ver quién obtiene una puntuación más alta. De esta manera, podemos aprender sobre las estrategias de su sistema al mismo tiempo.

El anfitrión del juego debería poder ver el estado de todos.

Dado que hay varios equipos compitiendo al mismo tiempo, como anfitrión necesito poder ver cómo progresa y anota cada equipo en ese momento.

El flujo del juego tiene que ser simple y fácil de controlar el ritmo.

Como dije al principio, este es un taller corto, por lo que necesito que todos se pongan al día rápidamente y necesito poder controlar los detalles de cada ronda.

Además, aparece un temporizador en la interfaz de usuario del jugador al comienzo de cada ronda, que avanza el ritmo del juego mediante una cuenta regresiva.

Poder personalizar los personajes.

Un juego de cerveza clásico consta de cuatro personajes, pero cuantos más personajes haya, más largo será el juego. Así que me gustaría ajustar el ritmo del juego para que sea mejor tener tres personajes.

Después de buscar, descubrí que ni los proyectos de código abierto ni los proyectos que ya están en línea pueden satisfacer estos requisitos a la perfección. Así que será mejor que haga uno yo mismo.

Proyecto de juego de cerveza

https://github.com/wirelessr/beer_game

IU del host

UI del reproductor

Todo el proyecto está impulsado por el negocio, desarrollado y probado con más del 90 % de cobertura, así que no dudes en utilizarlo.

Preparación

Cree un archivo para secretos en la carpeta del proyecto. Deberías verme copiarlo en Dockerfile.

.streamlit/secrets.toml

[mongo]
uri = ""

[admin]
key = ""

[player]
key = ""

Dado que este proyecto utiliza MongoDB, debe completar el enlace con la contraseña de su cuenta. Además, admin.key y player.key corresponden a los campos clave en la interfaz de usuario.

Después de todo, estoy cargando la aplicación en la nube pública, por lo que todavía necesito un mecanismo de autenticación básico. Si está ejecutando solo localmente y la autenticación le resulta problemática, puede eliminar el código fuente correspondiente.

Instalación y uso

Este proyecto tiene un Dockerfile adjunto, por lo que se puede ejecutar directamente con Docker.

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

Para el desarrollo, además de requiremnts.txt, también se debe instalar requisitos-test.txt, que ejecuta las pruebas unitarias. Luego puede ejecutar todas las pruebas unitarias a través del Makefile.

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

Flujo del juego

Todo el juego se divide en un modo anfitrión y un modo participante, que corresponden a las opciones en la esquina superior de la interfaz de usuario.

El anfitrión primero asigna un game_id para crear el juego, y todos los participantes deben completar player_game con este id.

Todos los jugadores en la misma cadena de suministro deben usar el mismo player_id, por lo que este id también se conoce como ID de la cadena de suministro, y los participantes con el mismo player_id se separan en roles según player_role.

Puedes ver el estado en la pantalla del anfitrión cuando un participante se une.

Veamos cómo se vería una iteración completa desde el punto de vista del anfitrión.

Todos los componentes que necesitan ser manipulados están en esta imagen, y cada turno comienza presionando el botón Actualizar y termina presionando la Semana Próxima.

En cuanto a cuántos pedidos enviar a todas las cadenas de suministro en esta ronda, se activarán al realizar el pedido.

Vale la pena mencionar que Realizar pedido en sí es idempotente, por lo que está bien cambiar el número y presionarlo nuevamente, se usará el último número. El Realizar pedido de la interfaz de cada participante también será idempotente.

Una vez que el anfitrión ha realizado el pedido, el jugador de la tienda puede tomar el pedido.

De manera similar, cada rol en la cadena de suministro comienza con Actualizar y termina con Realizar pedido, donde el jugador de la tienda realiza la acción seguido por el jugador minorista, y así sucesivamente.

Finalmente, volvamos al anfitrión, quien puede presionar Actualizar nuevamente para ver todos los estados de la ronda y Próxima semana para finalizar la ronda.

Detalle del juego

Hay un par de cosas que se hacen durante la actualización.

1. reabastece el inventario desde abajo en función de los pedidos realizados hace cuatro semanas.
2. recibe pedidos desde upstream.
3. decide cuánto vender en función del inventario que puede vender.

Dado que Realizar pedido es idempotente, Refresh también lo es.

Trabajo futuro

Básicamente satisface todas mis necesidades ahora, pero se podrían hacer algunas mejoras.

Por ejemplo, aunque el anfitrión puede ver el estado de todos los participantes, sería útil tener un gráfico que muestre el cambio de inventario y la información de costos a lo largo del tiempo, lo que sería útil para revisar el juego una vez finalizado. .

También hay un problema más básico: la interfaz de usuario actual no tiene ninguna cobertura de prueba, principalmente porque el flujo actual del juego es bastante simple. Con solo unos pocos clics en la interfaz de usuario se cubrirá todo el flujo de la interfaz de usuario, por lo que no confío tanto en las pruebas automáticas. Sin embargo, si hay una modificación de la interfaz de usuario, seguirá siendo un poco tedioso, por lo que sería mejor realizar una prueba unitaria de la interfaz de usuario.

En general, estos requisitos son optimizaciones, pero su falta no afecta la funcionalidad.

Si tiene ideas adicionales, también puede enviar una solicitud de extracción; las contribuciones son bienvenidas.