近い将来、システム思考のワークショップを開催する必要があるので、最初にビールゲームが必要です。

ビール ゲーム自体は、小売業者、卸売業者、販売業者、工場の 4 つのキャラクターで構成されています。物流の時間遅延の性質を通じて、システムの視点を理解し、システムの境界をより深く理解することができます。

数時間のワークショップなので、このビールゲームには以下の機能を満たしてほしいと思っています。

これはマルチプレイヤー ゲームです。

ビール ゲーム自体には、多くの参加者がサプライ チェーンでさまざまな役割を果たしますが、複数のサプライ チェーンを同時に競争させて、誰がより高いスコアを獲得できるかを確認できるようにしたいと考えています。したがって、彼らのシステム戦略についても同時に知ることができます。

ゲームホストは全員のステータスを確認できるはずです。

複数のチームが同時に競争しているため、ホストとして、各チームが現時点でどのように進歩し、得点しているかを確認できる必要があります。

ゲームの流れはシンプルでペースをコントロールしやすいものでなければなりません。

最初に述べたように、これは短いワークショップなので、全員をすぐに理解できるようにする必要があり、各ラウンドの詳細を制御できる必要があります。

さらに、各ラウンドの開始時にプレイヤーの UI にタイマーが表示され、カウントダウンによってゲームのペースが進みます。

文字をカスタマイズできるようになります。

古典的なビール ゲームは 4 人のキャラクターで構成されますが、キャラクターの数が増えるほど、ゲームは長くなります。なので、キャラクターを3人にした方が良いようにゲームペースを調整したいと思います。

調べてみたところ、オープンソース プロジェクトも、すでにオンラインになっているプロジェクトも、これらの要件を完全に満たすことはできないことがわかりました。だったら自分で作ったほうがいいよ。

ビールゲームプロジェクト

https://github.com/wirelessr/beer_game

ホスト UI

プレーヤー UI

プロジェクト全体はビジネス主導で開発され、90% 以上をカバーしてテストされていますので、お気軽にご利用ください。

備え

プロジェクトフォルダーにシークレット用のファイルを作成します。 Dockerfile にコピーしているのがわかるはずです。

.streamlit/secrets.toml

[mongo]
uri = ""

[admin]
key = ""

[player]
key = ""

このプロジェクトは MongoDB を使用しているため、リンクにアカウントのパスワードを入力する必要があります。また、admin.key と player.key は UI 上のキーフィールドに対応します。

結局のところ、アプリをパブリック クラウドにアップロードするので、やはり基本認証メカニズムが必要です。ローカルでのみ実行していて認証が面倒だと感じる場合は、対応するソース コードを削除できます。

インストールと使用

このプロジェクトには Dockerfile が添付されているため、docker で直接実行できます。

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

開発時には、requiremnts.txtに加えて、単体テストを実行するrequirements-test.txtもインストールする必要があります。その後、Makefile.
を通じてすべての単体テストを実行できます。

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

ゲームの流れ

ゲーム全体はホスト モードと参加者モードに分かれており、これらは UI の上隅にあるオプションに対応しています。

ホストは最初に game_id を割り当ててゲームを作成し、すべての参加者は player_game にこの ID を入力する必要があります。

同じサプライ チェーン上のすべてのプレーヤーは同じ player_id を使用する必要があるため、この ID はサプライ チェーン ID とも呼ばれ、同じ player_id を持つ参加者は player_role によってロールに分けられます。

参加者が参加すると、ホストの画面でステータスを確認できます。

ホストの観点から完全な反復がどのように見えるかを見てみましょう。

操作する必要があるすべてのコンポーネントはこの図にあり、各ターンは [更新] ボタンを押すことで開始され、[次週] を押すことで終了します。

このラウンドですべてのサプライ チェーンに送信する注文の数については、注文の実行によってトリガーされます。

Place Order 自体は冪等であるため、番号を変更してもう一度押すと、最後の番号が使用されることに注意してください。各参加者のインターフェイスの配置順序も冪等になります。

ホストが注文すると、ショップ プレイヤーは注文を受けることができます。

同様に、サプライ チェーンの各役割は更新で始まり、注文で終わります。ショップ プレーヤーがアクションを実行し、その後に小売業者プレーヤーが続きます。

最後にホストに戻ります。ホストはもう一度 [更新] を押すとラウンドのすべてのステータスを確認でき、[来週] を押すとラウンドが終了します。

ゲーム詳細

リフレッシュ中に実際に実行されることがいくつかあります。

1. 4 週間前の注文に基づいて下流から在庫を補充します。
2. 上流から注文を受け取ります。
3. 販売できる在庫に基づいて販売額を決定します。

Place Order はべき等であるため、Refresh 自体もべき等です。

今後の取り組み

これで基本的に私のニーズはすべて満たされますが、いくつかの機能強化の可能性があります。

たとえば、主催者は参加者全員のステータスを確認できますが、時間の経過に伴う在庫やコスト情報の変化をグラフで表示できると、ゲーム終了後の振り返りに役立ちます。 .

さらに基本的な問題もあります。主に現在のゲーム フローが非常に単純であるため、現在の UI にはテスト範囲がまったくありません。 UI を数回クリックするだけですべての UI フローがカバーされるため、自動テストにはあまり依存していません。ただし、UIの変更がある場合は、やはり少し面倒なので、UI単体テストを行った方が良いでしょう。

全体的に、これらの要件は最適化されていますが、それが欠けていても機能には影響しません。

追加のアイデアがある場合は、プル リクエストを送信することもできます。貢献は歓迎です。