近い将来、システム思考のワークショップを開催する必要があるので、最初にビールゲームが必要です。
ビール ゲーム自体は、小売業者、卸売業者、販売業者、工場の 4 つのキャラクターで構成されています。物流の時間遅延の性質を通じてシステムの視点を理解し、システムの境界をより深く理解することができます。
これは数時間のワークショップであるため、このビールゲームは次の機能を満たすようにしたいと思います。
これはマルチプレイヤー ゲームです。
ビール ゲーム自体には、多くの参加者がサプライ チェーン内でさまざまな役割を果たしますが、複数のサプライ チェーンを同時に競争させて、誰がより高いスコアを獲得できるかを確認できるようにしたいと考えています。したがって、私たちは彼らのシステム戦略についても同時に知ることができます。
ゲームホストは全員のステータスを確認できる必要があります。
複数のチームが同時に競争しているため、ホストとして、各チームが現時点でどのように進歩し、得点しているかを確認できる必要があります。
ゲームの流れはシンプルでペースをコントロールしやすいものでなければなりません。
最初に述べたように、これは短いワークショップなので、全員をすぐに理解できるようにする必要があり、各ラウンドの詳細を制御できる必要があります。
さらに、各ラウンドの開始時にプレイヤーの UI にタイマーが表示され、カウントダウンによってゲームのペースが進みます。
キャラクターをカスタマイズできる。
古典的なビール ゲームは 4 人のキャラクターで構成されますが、キャラクターの数が増えるほど、ゲームは長くなります。なので、キャラクターを3人にした方が良いようにゲームペースを調整したいと思います。
調べてみたところ、オープンソース プロジェクトも、すでにオンラインになっているプロジェクトも、これらの要件を完全に満たすことはできないことがわかりました。だったら自分で作ったほうがいいです
https://github.com/wirelessr/beer_game
ホスト UI
プレーヤー UI
プロジェクト全体はビジネス主導で開発され、90% 以上をカバーしてテストされていますので、お気軽にご利用ください。
プロジェクトフォルダーにシークレット用のファイルを作成します。これを Dockerfile にコピーするのがわかります。
.streamlit/secrets.toml
[mongo] uri = "<your mongo connection>" [admin] key = "<your admin key>" [player] key = "<your 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 を割り当て、すべての参加者はこの ID を player_game に入力する必要があります。
同じサプライ チェーン上のすべてのプレーヤーは同じ player_id を使用する必要があるため、この ID はサプライ チェーン ID とも呼ばれ、同じ player_id を持つ参加者は player_role によってロールに分けられます。
参加者が参加すると、ホストの画面でステータスを確認できます。
ホストの観点から完全な反復がどのように見えるかを見てみましょう。
操作する必要があるすべてのコンポーネントはこの図にあり、各ターンは [更新] ボタンを押すことで開始され、[次週] を押すことで終了します。
このラウンドですべてのサプライチェーンに送信する注文の数については、注文の実行によってトリガーされます。
Place Order 自体は冪等であるため、番号を変更してもう一度押すと、最後の番号が使用されることに注意してください。各参加者のインターフェースの配置順序も冪等になります。
ホストが注文すると、ショッププレイヤーは注文を受けることができます。
同様に、サプライチェーンの各役割は、「更新」で始まり、「注文」で終わります。ショッププレーヤーがアクションを実行し、その後に小売業者プレーヤーが続きます。
最後にホストに戻り、もう一度 [更新] を押すとラウンドのすべてのステータスが表示され、[来週] を押すとラウンドが終了します。
リフレッシュ中に実際に実行されることがいくつかあります。
Place Order はべき等であるため、Refresh 自体もべき等です。
基本的には現時点での私のニーズをすべて満たしていますが、いくつかの機能強化の可能性があります。
たとえば、主催者は参加者全員のステータスを確認できますが、時間の経過に伴う在庫とコスト情報の変化を示すグラフがあれば、ゲーム終了後の振り返りに役立ちます。 .
さらに基本的な問題もあります。主に現在のゲーム フローが非常に単純であるため、現在の UI にはテスト範囲がまったくありません。 UI を数回クリックするだけですべての UI フローがカバーされるため、自動テストにはあまり依存していません。ただし、UI の変更がある場合は、やはり少し面倒なので、UI 単体テストを行った方がよいでしょう。
全体として、これらの要件は最適化されていますが、要件が欠けていても機能には影響しません。
追加のアイデアがある場合は、プル リクエストを送信することもできます。貢献は歓迎です。
以上がターン制マルチプレイヤービールゲームの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。