|
desing
1】認識している前提 1.ひとつのチームは、小売、卸1、卸2、メーカーで構成される。 チーム間で勝敗を争うゲーム。 2.チームの勝敗は、37週の間の「入荷」~「出荷」を繰り返して 最終の「注残」と、各週での在庫(小売~メーカ)の 累積(37週分)で判定し、その合計が最小のチームが優勝 3.ある週の在庫および受注残は、翌週以降に繰り越す。(各チーム、各役割で繰り越す) 4.同じ週に 入荷、受注、出荷、発注、出荷 する。 前週の発注分のうち出荷可能分が「入荷」する。今週の「受注」に対して 出荷可能分を「出荷」する。出荷できなかった分が注残になる。 来週に向けて 「発注」する。これらを同週に行う。 つまり、
②今週(?)受け取った「受注」に対して 出荷可能分を「出荷」する。 ☆→この出荷は下流に翌週届く ③来週に向けて 「発注」する。 ☆→この「発注」は来週に上流に届く ①~③を同週に行う。 ネットでビールゲームを調べると、メーカでの原材料は生産に 2週間を要して製品になる。小売~卸1~卸2~メーカへの 各配送には2週間を要する。とありますが、これと今回のビール ゲームは異なると理解しています。
【2】中心的仕様 ・初期状態の設定がある ・ある週の前週(初期)在庫を把握。 ・ある週(n週)に上流から の「入荷」がある。 ・その「入荷数」を記録する。 ・n週在庫を計算。 ・同じn週に 下流からの 「受注」を受ける。 その「受注数」を記録する。 ・「受注数」と「現在受注残」を合計し、「現在在庫量」と比較して 少なければ、合計分(需要量)を「出荷」する。 合計分(需要量)が多くて在庫が足りない場合は、「現在在庫量」を 全て「出荷」する。 足りない分(受注数-出荷数)を受注残として「現在受注残」に 加算する。(翌週に繰越す) ・下流は上流からの出荷を受け取る。(「入荷」となる) これはn-2週に「発注」していたものに対する「入荷」 ・システムは在庫量、受注残を更新。 ・アクタは上流に対する「発注数」を決めて 上流に提示する。 ・上流はそれをn+1週に「受注」として受け取り,n+1週に「出荷」する。自分はそれをn+2週に受け取る(入荷)。 ・システムは週をカウントアップする。カウントアップした翌週=n+1が 37未満なら、最初に戻る。それ以外なら(37以上) この処理終了。 【3】ゲームのセットアップの仕様概略 新規ゲーム開始(生成): 新たにチームを登録する この時点では,週は関係ない。 他チームの有無は関係ないが,ゲーム名が重複してはならない。 既存ゲームへの参加: 既に登録されている1以上のチームの中から参加先を決めて参加する 1チームにプレイヤーが小売~メーカまでのroleに登録され4名揃ったら、
チームは任意に登録され、プレイヤーも任意に登録するため、 ゲームの開始もチームごとに三々五々。 ☆ある瞬間を見るとチームごとに経過週は異なる。
プレイ: 上の中心的仕様で述べたとおり。 ゲームの終了: ここ,考えてください。 勝負の判定: これ,考えてください。仕様には書かれていません。 |