بما أنني بحاجة إلى تنظيم ورشة عمل حول التفكير النظمي في المستقبل القريب، فأنا بحاجة إلى لعبة بيرة للبدء بها.

تتكون لعبة البيرة نفسها من أربع شخصيات: بائع التجزئة وتاجر الجملة والموزع والمصنع. من خلال طبيعة التأخير الزمني للخدمات اللوجستية لفهم منظور النظام، ويمكن أن يكون لديك فهم أفضل لحدود النظام.

نظرًا لأن هذه ورشة عمل تستغرق بضع ساعات، أريد أن تحقق لعبة البيرة هذه الميزات التالية.

إنها لعبة متعددة اللاعبين.

ستضم لعبة البيرة نفسها العديد من المشاركين الذين يلعبون أدوارًا مختلفة في سلسلة التوريد، ولكني أود أن أكون قادرًا على أن تكون هناك سلاسل توريد متعددة تتنافس في نفس الوقت لمعرفة من الذي سيحقق أعلى النتائج. وبالتالي، يمكننا التعرف على استراتيجيات النظام الخاصة بهم في نفس الوقت.

يجب أن يكون مضيف اللعبة قادرًا على رؤية حالة الجميع.

نظرًا لوجود فرق متعددة تتنافس في نفس الوقت، كمضيف، أحتاج إلى أن أكون قادرًا على رؤية كيفية تقدم كل فريق وتسجيله في الوقت الحالي.

يجب أن يكون سير اللعبة بسيطًا وسهل التحكم في الوتيرة.

كما قلت في البداية، هذه ورشة عمل قصيرة، لذا أحتاج إلى إطلاع الجميع على كل ما هو جديد بسرعة وأحتاج إلى أن أكون قادرًا على التحكم في تفاصيل كل جولة.

علاوة على ذلك، يظهر مؤقت في واجهة المستخدم الخاصة باللاعب في بداية كل جولة، مما يعزز وتيرة اللعبة عن طريق العد التنازلي.

التمكن من تخصيص الشخصيات.

تتكون لعبة البيرة الكلاسيكية من أربعة أحرف، ولكن كلما زاد عدد الشخصيات، زادت مدة اللعبة. لذلك أود تعديل وتيرة اللعبة بحيث يكون من الأفضل أن يكون لديك ثلاثة أحرف.

بعد البحث، وجدت أنه لا المشاريع مفتوحة المصدر ولا المشاريع الموجودة بالفعل على الإنترنت يمكنها تلبية هذه المتطلبات بشكل مثالي. لذا، من الأفضل أن أصنع واحدة بنفسي.

مشروع لعبة البيرة

https://github.com/wirelessr/beer_game

واجهة المستخدم المضيفة

واجهة مستخدم المشغل

تم تطوير المشروع بأكمله واختباره بتغطية تزيد عن 90%، لذا فلا تتردد في استخدامه.

الاستعداد

إنشاء ملف للأسرار في مجلد المشروع. يجب أن تراني أنسخه في ملف Dockerfile.

.streamlit/secrets.toml

[mongo]
uri = ""

[admin]
key = ""

[player]
key = ""

نظرًا لأن هذا المشروع يستخدم MongoDB، فيجب عليك ملء الرابط بكلمة مرور حسابك. بالإضافة إلى ذلك، يتوافق admin.key وplayer.key مع الحقول الرئيسية في واجهة المستخدم.

بعد كل شيء، أقوم بتحميل التطبيق على السحابة العامة، لذلك ما زلت بحاجة إلى آلية مصادقة أساسية. إذا كنت تعمل محليًا فقط وتجد أن المصادقة مزعجة، فيمكنك إزالة كود المصدر المقابل.

التثبيت والاستخدام

يحتوي هذا المشروع على ملف Dockerfile مرفق، بحيث يمكن تشغيله مباشرة باستخدام عامل الإرساء.

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

تدفق اللعبة

تنقسم اللعبة بأكملها إلى وضع المضيف ووضع المشارك، والذي يتوافق مع الخيارات الموجودة في الزاوية العلوية من واجهة المستخدم.

يقوم المضيف أولاً بتعيين game_id لإنشاء اللعبة، ويجب على جميع المشاركين ملء player_game بهذا المعرف.

يحتاج جميع اللاعبين في نفس سلسلة التوريد إلى استخدام نفس player_id، لذلك يُعرف هذا المعرف أيضًا باسم معرف سلسلة التوريد، ويتم فصل المشاركين الذين لديهم نفس player_id إلى أدوار حسب player_role.

يمكنك رؤية الحالة على شاشة المضيف عند انضمام أحد المشاركين.

دعونا نلقي نظرة على الشكل الذي سيبدو عليه التكرار الكامل من وجهة نظر المضيف.

جميع المكونات التي تحتاج إلى التلاعب موجودة في هذه الصورة، وكل دورة تبدأ بالضغط على زر التحديث وتنتهي بالضغط على Next Week.

أما بالنسبة لعدد الطلبات التي سيتم إرسالها إلى جميع سلاسل التوريد في هذه الجولة، فسيتم تشغيلها عن طريق تقديم الطلب.

من الجدير بالذكر أن أمر المكان نفسه غير فعال، لذا لا بأس بتغيير الرقم والضغط عليه مرة أخرى، وسيتم استخدام الرقم الأخير. سيكون الترتيب المكاني لواجهة كل مشارك غير فعال أيضًا.

بمجرد قيام المضيف بتقديم الطلب، يمكن للاعب المتجر تلقي الطلب.

وبالمثل، يبدأ كل دور في سلسلة التوريد بالتحديث وينتهي بتقديم الطلب، حيث يتخذ لاعب المتجر الإجراء متبوعًا بلاعب بائع التجزئة، وهكذا.

أخيرًا، العودة إلى المضيف، الذي يمكنه الضغط على "تحديث" مرة أخرى لرؤية جميع حالات الجولة، والأسبوع التالي لإنهاء الجولة.

تفاصيل اللعبة

هناك بعض الأشياء التي تم إجراؤها بالفعل أثناء التحديث.

1. يقوم بإعادة ملء المخزون من المصب بناءً على الطلبات المقدمة قبل أربعة أسابيع.
2. يتلقى الطلبات من المنبع.
3. يقرر مقدار البيع بناءً على المخزون الذي يمكنه بيعه.

نظرًا لأن ترتيب المكان غير فعال، فإن التحديث نفسه غير فعال أيضًا.

العمل المستقبلي

يلبي بشكل أساسي جميع احتياجاتي الآن، ولكن هناك بعض التحسينات التي يمكن إجراؤها.

على سبيل المثال، على الرغم من أن المضيف يمكنه رؤية حالة جميع المشاركين، إلا أنه سيكون من المفيد أن يكون لديك رسم بياني لإظهار التغير في معلومات المخزون والتكلفة بمرور الوقت، وهو ما سيكون مفيدًا لمراجعة اللعبة بعد انتهائها. .

هناك أيضًا مشكلة أساسية أكثر: واجهة المستخدم الحالية لا تحتوي على تغطية اختبارية على الإطلاق، ويرجع ذلك أساسًا إلى أن تدفق اللعبة الحالي بسيط للغاية. ستغطي بضع نقرات فقط على واجهة المستخدم كل تدفق واجهة المستخدم، لذلك لا أعتمد كثيرًا على الاختبار التلقائي. ومع ذلك، إذا كان هناك تعديل لواجهة المستخدم، فسيظل الأمر مملاً بعض الشيء، لذا سيكون من الأفضل إجراء اختبار وحدة واجهة المستخدم.

بشكل عام، هذه المتطلبات عبارة عن تحسينات، لكن عدم وجودها لا يؤثر على الوظيفة.

إذا كانت لديك أفكار إضافية، يمكنك أيضًا إرسال طلب سحب، ونرحب بالمساهمات.