Como preciso organizar um workshop de pensamento sistêmico em um futuro próximo, preciso de um jogo de cerveja para começar.

O jogo da cerveja em si consiste em quatro personagens: Varejista, Atacadista, Distribuidor e Fábrica. Através da natureza de atraso da logística para compreender a perspectiva do sistema, e pode ter uma melhor compreensão dos limites do sistema.

Como este é um workshop de algumas horas, quero que este jogo de cerveja cumpra os seguintes recursos.

É um jogo multijogador.

O jogo da cerveja em si terá muitos participantes desempenhando vários papéis na cadeia de abastecimento, mas eu gostaria de poder ter várias cadeias de abastecimento competindo ao mesmo tempo para ver quem pontua mais. Assim, podemos aprender sobre suas estratégias de sistema ao mesmo tempo.

O host do jogo deve ser capaz de ver o status de todos.

Como há várias equipes competindo ao mesmo tempo, como anfitrião, preciso ver como cada equipe está progredindo e pontuando no momento.

O fluxo do jogo deve ser simples e fácil de controlar o ritmo.

Como eu disse no início, este é um workshop curto, então preciso que todos se familiarizem rapidamente e preciso ser capaz de controlar os detalhes de cada rodada.

Além disso, um cronômetro aparece na interface do jogador no início de cada rodada, avançando o ritmo do jogo por meio da contagem regressiva.

Poder personalizar os personagens.

Um jogo clássico de cerveja consiste em quatro personagens, mas quanto mais personagens houver, mais longo será o jogo. Então, eu gostaria de ajustar o ritmo do jogo para que seja melhor ter três personagens.

Depois de pesquisar, descobri que nem projetos de código aberto nem projetos que já estão online podem satisfazer esses requisitos perfeitamente. Então, é melhor eu mesmo fazer um.

Projeto de jogo de cerveja

https://github.com/wirelessr/beer_game

IU do host

IU do player

Todo o projeto é orientado para os negócios, desenvolvido e testado com mais de 90% de cobertura, então sinta-se à vontade para usá-lo.

Preparação

Crie um arquivo para segredos na pasta do projeto. Você deveria me ver copiá-lo no Dockerfile.

.streamlit/secrets.toml

[mongo]
uri = ""

[admin]
key = ""

[player]
key = ""

Como este projeto está usando MongoDB, você deve preencher o link com a senha da sua conta. Além disso, admin.key e player.key correspondem aos campos-chave na IU.

Afinal, estou enviando o aplicativo para a nuvem pública, então ainda preciso de um mecanismo básico de autenticação. Se você estiver executando apenas localmente e achar a autenticação problemática, poderá remover o código-fonte correspondente.

Instalação e uso

Este projeto tem um Dockerfile anexado, portanto pode ser executado diretamente com o docker.

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

Para desenvolvimento, além do requirents.txt, também deve ser instalado o require-test.txt, que executa os testes unitários. Então você pode executar todos os testes de unidade através do Makefile.

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

Fluxo do jogo

Todo o jogo é dividido em um modo host e um modo participante, que correspondem às opções no canto superior da IU.

O anfitrião primeiro atribui um game_id para criar o jogo, e todos os participantes devem preencher o player_game com esse id.

Todos os jogadores na mesma cadeia de suprimentos precisam usar o mesmo player_id, portanto, esse ID também é conhecido como ID da cadeia de suprimentos, e os participantes com o mesmo player_id são separados em funções por player_role.

Você pode ver o status na tela do anfitrião quando um participante entra.

Vejamos como seria uma iteração completa do ponto de vista do host.

Todos os componentes que precisam ser manipulados estão nesta imagem, e cada turno começa pressionando o botão Atualizar e termina pressionando Próxima Semana.

Quanto a quantos pedidos enviar para todas as cadeias de suprimentos nesta rodada, eles serão acionados por Fazer Pedido.

Vale ressaltar que o próprio Place Order é idempotente, então não há problema em alterar o número e pressioná-lo novamente, o último número será utilizado. O pedido de colocação da interface de cada participante também será idempotente.

Depois que o anfitrião fizer o pedido, o jogador da loja poderá anotá-lo.

Da mesma forma, cada função na cadeia de suprimentos começa com Atualizar e termina com Fazer pedido, com o jogador da loja realizando a ação, seguido pelo jogador varejista, e assim por diante.

Finalmente, de volta ao anfitrião, que pode pressionar Atualizar novamente para ver todos os status da rodada e Semana Próxima para encerrar a rodada.

Detalhe do jogo

Há algumas coisas realmente feitas durante a atualização.

1. ele reabastece o estoque downstream com base nos pedidos feitos há quatro semanas.
2. ele recebe pedidos do upstream.
3. decide quanto vender com base no estoque que pode vender.

Como o Place Order é idempotente, o próprio Refresh também é idempotente.

Trabalho futuro

Basicamente atende a todas as minhas necessidades agora, mas há algumas melhorias que podem ser feitas.

Por exemplo, embora o anfitrião possa ver o status de todos os participantes, seria útil ter um gráfico para mostrar a mudança de estoque e informações de custo ao longo do tempo, o que seria útil para revisar o jogo após seu término .

Há também um problema mais básico: a UI atual não tem nenhuma cobertura de teste, principalmente porque o fluxo do jogo atual é bastante simples. Apenas alguns cliques na IU cobrirão todo o fluxo da IU, por isso não confio tanto no teste automático. No entanto, se houver uma modificação da IU, ainda será um pouco tedioso, então seria melhor fazer um teste de unidade da IU.

No geral, esses requisitos são otimizações, mas sua falta não afeta a funcionalidade.

Se você tiver ideias adicionais, também pode simplesmente enviar uma solicitação pull, contribuições são bem-vindas.