My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
desing  
Updated Dec 15, 2009 by stay1ni...@gmail.com

1】認識している前提

1.ひとつのチームは、小売、卸1、卸2、メーカーで構成される。

  チーム間で勝敗を争うゲーム。

2.チームの勝敗は、37週の間の「入荷」~「出荷」を繰り返して

  最終の「注残」と、各週での在庫(小売~メーカ)の

  累積(37週分)で判定し、その合計が最小のチームが優勝

3.ある週の在庫および受注残は、翌週以降に繰り越す。(各チーム、各役割で繰り越す)

4.同じ週に 入荷、受注、出荷、発注、出荷 する。

  前週の発注分のうち出荷可能分が「入荷」する。今週の「受注」に対して 出荷可能分を「出荷」する。出荷できなかった分が注残になる。

  来週に向けて 「発注」する。これらを同週に行う。

  つまり、

  1. 週の発注分の出荷可能分が上流から「入荷」する。

  ②今週(?)受け取った「受注」に対して 出荷可能分を「出荷」する。

   ☆→この出荷は下流に翌週届く

  ③来週に向けて 「発注」する。

   ☆→この「発注」は来週に上流に届く

  ①~③を同週に行う。

  ネットでビールゲームを調べると、メーカでの原材料は生産に

  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名揃ったら、

  1. 目からゲームが開始される。初期値が設定される。

 チームは任意に登録され、プレイヤーも任意に登録するため、

 ゲームの開始もチームごとに三々五々。

☆ある瞬間を見るとチームごとに経過週は異なる。

 

プレイ:

 上の中心的仕様で述べたとおり。

ゲームの終了:

 ここ,考えてください。

勝負の判定:

 これ,考えてください。仕様には書かれていません。

Powered by Google Project Hosting