في هذا الجزء ، سنقوم بحل مشكلة الوضع الأمثل للأسلحة على الدبابة ، والترتيب المكاني لأجهزة النقل عن بعد في لعبة MMORPG وتحقيق التوازن بين معارك الفئات الأربعة من شخصيات RPG.
مهام وضع الكائن
يمكن تنزيل جداول البيانات الخاصة بهذا الجزء من هنا: ( SuperTank ) ( الناقلات عن بعد ، الجزء 1 ) ( الناقلات عن بعد ، الجزء 2 )SuperTank: تم حل المشكلة!
في
المقالة الأولى من السلسلة ، تحدثنا عن مثال لمهمة لعبة تسمى SuperTank. في الجزء الثاني ، تعرّفنا على المفاهيم الأساسية لنمذجة القرار وتحدثت عن حل مثال بسيط باستخدام أداة "البحث عن حلول" في Excel.
الآن يمكننا تطبيق المعرفة المكتسبة في الجزء الثاني على مشكلة SuperTank ، وإثبات أنه بمساعدتهم يمكن حل هذه المشكلة بسهولة وبسرعة. قم بتحديث ذاكرتك: SuperTank هي لعبة يمكنك القتال فيها على دبابة مخصصة.
يبدو الناقل العملاق مثل هذا:
يمكن أن يكون لكل دبابة عملاقة أي عدد من البنادق من خمسة أنواع مختلفة:
يمكن أن يصل حجم الخزان الفائق إلى 50 طنًا من الأسلحة ، ويمكن للاعب أن ينفق 100 رصيد. بالإضافة إلى ذلك ، يمتلك الناقل العملاق 3 "فتحات حرجة" ، حيث يتم وضع مسدسات خاصة مثل MegaRocket و UltraLaser.
يمكن تنزيل جدول البيانات لهذا المثال
هنا .
الهدف هو التقاط الأسلحة التي تزيد من الضرر الذي تسببه الدبابة الفائقة ، دون تجاوز حدود 50 طنًا و 100 رصيد و 3 فتحات حرجة. نفترض أيضًا أن هذا الجدول يحتوي على جميع المعلومات اللازمة ، وأن عوامل مثل النطاق والتردد والدقة ليست ذات صلة أو تم أخذها بالفعل في الاعتبار في معلمة الضرر للسلاح المقابل.
لتحسين هذا المخطط ، نقوم أولاً بإدخال هذه البيانات في جدول البيانات. أسفله مباشرة ، سنضيف جدولًا آخر ، حيث سيكون هناك مجموعة من 5 خلايا "كمية" للإشارة إلى كمية كل نوع من أنواع الأسلحة الخمسة.
حتى ندخل قيمة 1 في هذه الخلايا ، فقط لاختبار عملهم ، لكن هذه ستكون خلايا القرار لدينا - سنطلب من أداة Solver العثور على القيم الصحيحة لهذه الخلايا. من الممكن أن نفهم أن هذه خلايا قرار باللون الأصفر ، لأننا نواصل اتباع قواعد التنسيق الموضحة في الجزء الثاني. على يمين الخلايا "الكمية" ، سنضيف خلايا حسابية تضرب قيم الكمية في خلايا القرار في قيم الأضرار والوزن والتكلفة والفتحات الحرجة من الجدول أعلاه. وبالتالي ، سيعرض كل صف من هذا الجدول بشكل صحيح الضرر والوزن والسعر والفتحات الحرجة المطلوبة لجميع الأسلحة المستخدمة في جميع فئات الأسلحة.
سننشئ أيضًا قسمًا أدناه ، يلخص جميع قيم الكمية والوزن والتكلفة والفتحات الحرجة من الجدول أعلاه ، ويقارن بالقيم القصوى للوزن والتكلفة والفتحات الحرجة المحددة في شروط المهمة (50 و 100 و 3 على التوالي).
وفقًا لقواعد التنسيق من الجزء الثاني من المقالة ، فإن الخلايا الزرقاء في الجزء العلوي هي المعايير من شروط المشكلة. الخلايا الرمادية هي خلايا حسابية تمثل الوزن الإجمالي والتكلفة والفتحات الحرجة بناءً على الجمع من جدول الكمية (أي القيم الإجمالية للأعمدة الوزن × الكمية والتكلفة × الكمية والفتحات الحرجة × الكمية). أخيرًا ، تمثل الخلية البرتقالية إجمالي الضرر الذي لحق بخزاننا الفائق الذي تم تلقيه بناءً على إجمالي الضرر لعمود الضرر × الكمية من الجدول أعلاه.
قبل البدء ، دعنا نجعل جدول البيانات أكثر سهولة في الاستخدام. سننتهز فرصة Excel لتخصيص اسم لكل خلية وإعطاء أسماء واضحة لسبع خلايا في جدول الحساب الأخير. هذا اختياري ، ولكنه سيجعل جدول البيانات يبدو أكثر وضوحًا على المدى الطويل (على سبيل المثال ، إذا كانت الخلية بدلاً من $ F $ 21 ستسمى MaxCriticalSlots). للقيام بذلك ، ما عليك سوى تحديد خلية والانتقال إلى حقل إدخال الاسم على يسار حقل الصيغة ، وإدخال اسم جديد.
الآن أخيرًا ، دعنا نذهب إلى Excel Solver ونجد حلاً (انتقل إلى الجانب الأيمن من علامة التبويب Data وحدد Solver. إذا لم تشاهده ، فانتقل إلى خيارات Excel ، حدد فئة الوظائف الإضافية ("الوظائف الإضافية") ، تأكد من تحديد وظائف Excel الإضافية في القائمة المنسدلة "إدارة" ، انقر فوق انتقال ("اذهب ...") وتأكد تم تحديد خانة الاختيار Solver الوظيفة الإضافية.
في حقل تعيين الهدف ("تحسين وظيفة الهدف") ، سنحدد الخلية البرتقالية للهدف ، ثم نضغط على زر الاختيار Max (الحد الأقصى). في حقل By Changing Variable Cells ، حدد خلايا القرار (الخلايا الصفراء في عمود الكمية في الجدول الثاني). أدناه ، انقر فوق الزر "إضافة" لإضافة القيود التالية:
- يجب أن تكون قيم خلايا القرار في النطاق من 0 إلى حد أقصى معقول (اخترنا 50 ، على الرغم من أن هذه ربما تكون قيمة حد أكبر بكثير من الضرورة). من الضروري أيضًا تعيين كل خلية حل على تقييد "= عدد صحيح" ، لأنه لا يمكن أن يكون لدينا جزء كسري من التسلح ، ويعتبر Excel Solver أن كل متغير هو رقم حقيقي افتراضيًا ، ما لم يُذكر خلاف ذلك.
- نحتاج أيضًا إلى قصر قيم التكلفة الإجمالية والوزن الإجمالي والعدد الإجمالي للفتحات الحرجة على القيم من ظروف المشكلة. تُظهر صورة مربع الحوار أن لديهم الآن أسماء ملائمة قمنا بإضافتها إلى الجدول السفلي ، مما يجعل قراءة مربع الحوار أسهل.
الآن نضغط على زر "حل" ("البحث عن حل") وبعد انتظار قصير ، سيقوم Solver بملء قيم الكمية ، والتي ستمنحنا ما يلي:
- 1 رشاش
- 3 صواريخ
- 2 ميجا ريج
- 1 ليزر
- 1 UltraLaser
كل هذا يعطينا ضررًا إجماليًا يبلغ 83 وحدة ويأخذ 50 طنًا بالضبط و 100 رصيد و 3 فتحات حرجة. يمكنك أن ترى أن أفضل حل لا يتغير مع وقت تشغيل Solver. إذا قمت بإعادة تعيين هذه القيم وقمت بإجراء تحسين ثانٍ ، أو انتقلت إلى خيارات وقم بتغيير المصنف ، فسوف نحصل على نفس القيم. لا يمكننا أن نكون على يقين بنسبة 100٪ من أن هذا الحل هو الأمثل ، ولكن مع الأخذ في الاعتبار حقيقة أن Solver لم يتمكن من تحسينه بعد مرور العديد من عمليات التحسين ، فمن المحتمل جدًا أنه مثالي حقًا ، وليس مجرد حد أقصى محلي.
تم حل المشكلة!
استخدامات إضافية
الشيء الرائع هو أننا لم نحل المشكلة بسرعة أكبر بكثير مما يمكننا معالجتها يدويًا فحسب ، بل قمنا أيضًا بإعدادها بطريقة تسمح لنا باختبار الأسلحة في لعبة SuperTank التي ستكون مفيدة للغاية مع معلمات مختلفة (الوزن والتكلفة والفتحات الحرجة). هذا يعني أنه يمكننا بسهولة نسبياً تغيير تأثير التغييرات المختلفة في هذه المعلمات على لعبة SuperTank ، وإذا أردنا إضافة نموذج دبابة سوبر بديل جديد سيكون أخف وزناً أو أثقل أو يحتوي على عدد مختلف من الفتحات الحرجة ، فيمكن القيام بذلك ببساطة شديدة.
من خلال تغيير جميع هذه المعلمات ، يمكننا أيضًا اكتساب فهم للفائدة النسبية لكل سلاح من هذه الأسلحة ، وتحديد أي منها مفيد جدًا ، وليس مفيدًا بما يكفي ، وله سعر غير مناسب لوزنه وتلفه ، وما إلى ذلك.
مرة أخرى ، النقطة هي أن هذه الأداة تسمح لنا بالبحث في مساحة التصميم بشكل أسرع بكثير مما يمكننا يدويًا. يوفر لنا فرصة مناسبة لتقييم تأثير مثل هذه التغييرات لأي حل تصميمي إضافي يمكننا التوصل إليه ، سواء كان ذلك من خلال تغيير معلمات السلاح أو الدبابة الفائقة نفسها ، وإضافة أسلحة أو نماذج جديدة من الدبابات الفائقة ، بالإضافة إلى إضافة معلمات جديدة (لنفترض أن حد الحجم بالمتر المكعب).
لفهم ما أعنيه ، انتقل إلى خلية "التكلفة القصوى" الزرقاء وقم بتغيير قيمتها من 100 إلى 99. الآن قم بتشغيل Solver مرة أخرى وستحصل على تخطيط سلاح مختلف تمامًا:
- 0 رشاشات
- 2 صاروخ
- 3 ميغا آر جي
- 3 ليزر
- 0 UltraLasers
يعطي هذا المخطط مؤشر تلف أقل قليلاً (82 بدلاً من 83) ، ولكنه يختلف جذريًا عن السابق.
إذا قمت بتعيين قيمة التكلفة القصوى إلى 101 أو 102 ، وقمت بإجراء الحساب مرة أخرى ، فهناك احتمال أن نحصل على تكوين مماثل للتكوين الأول أو يتزامن معه ؛ ومع ذلك ، سيظل الضرر مساوياً لـ 83 (يمكن أن تتغير المخططات ، لأنه في مثل هذه الحالات هناك العديد من المخططات المثلى). ومع ذلك ، إذا قمت بتعيين التكلفة القصوى على 103 ، يجب أن تحصل على ما يلي:
- 1 رشاش
- 4 صواريخ
- 2 ميجا ريج
- 0 ليزر
- 1 UltraLaser
مما يزيد إجمالي الضرر إلى 84.
هذا مثير للاهتمام: يختلف ترتيب الأسلحة هذا تمامًا عن الأولين.
كما ترى ، نحصل على نتيجة غير متوقعة: الاختيار الأمثل للأسلحة في مخططنا يعتمد بشدة على معلمات الدبابة الفائقة ويمكن أن يختلف بشكل كبير حتى مع التغييرات الصغيرة في هذه المعلمات. بالإضافة إلى ذلك ، يقدم لنا جميع أنواع المعلومات المفيدة: جميع الأنواع الخمسة من الأسلحة مفيدة في اثنين على الأقل من إعدادات الدبابات الثلاثة الفائقة ، ومن الواضح أن Rockets و MegaRockets مفيدة في جميع الأنواع الثلاثة. يبدو أن هذا يخبرنا أن جميع أنواع الأسلحة الخمسة متوازنة بشكل جيد ، وهذا مفيد بالنسبة لبعضها البعض ، وفي نفس الوقت تظل فريدة.
وكما تلاحظ أيضًا ، فإن نمذجة الحلول وتحسينها توفر لنا فرصة ممتازة لإجراء عمليات بحث بسرعة في حي محلي وإعادة التحسين. بالنسبة لبعض أنواع المهام ، سيسمح لنا باكتشاف الاستراتيجيات والمآثر المسيطرة للاعبين التي يصعب أو يستحيل العثور عليها بأي طريقة أخرى.
الانتقال الآني - الثقوب الدودية
بالنظر إلى المثالين الأخيرين (مثال معدلات الضرائب في لعبة استراتيجية و SuperTank) ، قد تعتقد أن هذه التقنيات قابلة للتطبيق فقط في الحالات التي يتعامل فيها المستخدمون مع الأرقام. لكنك ستكون مخطئا تماما! كما سنرى ، هناك العديد من الأمثلة على كيفية الحصول على مزايا تحسين عناصر التصميم التي لا تبدو فقط كأرقام للمستخدمين ، ولكنها لا تبدو عليها على الإطلاق!
قد تعتقد أيضًا أن نموذج القرار ينطبق فقط على القرارات التي يمكن للاعبين اتخاذها في الألعاب. هذا غير صحيح أيضًا: في بعض الحالات يمكن استخدامها للنمذجة من أجل تحسين حلولك الخاصة كمصمم.
افترض أنك تعمل على لعبة MMORPG في الفضاء. في أحد الأيام ، يأتيك مصممك الرئيسي بقلق مرئي على وجهه. يقول: "نحن نكمل إعادة تصميم قطاع أوميغا". "وكانت لدينا مشكلة. نحن نخطط لإضافة عدد قليل من الناقلات عن بعد "في هذا الجزء من العالم ، ولكن لا يمكننا الاتفاق على مكان وضعهم."
تسأل "كم عدد الناقلات؟"
"نحن لا نعرف حتى الآن. ربما ثلاثة ، ولكن يمكن أن يكون هناك من اثنين إلى أربعة. لسنا متأكدين بعد. " ثم يعرض عليك خريطة تبدو كالتالي:
"ما هذا؟" تسأل.
"هذه خريطة لقطاع أوميغا. أو على الأقل أنظمة النجوم التي يمكن للاعب زيارتها في هذا الربع. نحن بحاجة إلى تحديد الخلايا التي يجب أن تكون فيها الثقوب الدودية. "
"حسنًا ، وبأي قواعد يتم وضعها؟ هل من الممكن وضع الثقب الدودي في ربع واحد مع نظام النجوم؟ "
"نريدك أن تضع الثقوب الدودية بطريقة تقلل المسافة من أي نظام نجمي إلى أقرب ثقب دودي. ونعم ، يمكنك وضعها في نفس ربع النظام النجمي ؛ إنهم مجرد نقليات صغيرة معلقة في الفضاء ، بحيث يمكن وضعها في أي مكان. وتذكر أننا لم نقرر بعد عدد الأماكن التي يجب أن تكون موجودة ، لذا أعطني حلولًا للفتحات 2 و 3 و 4 ".
كيف تصيغ هذه المشكلة وكيف تحلها؟
تحسين الناقلات!
لنبدأ بإعداد خلايا الحل. نشير إلى أن الانتقال الآني الأربعة هو A و B و C و D. نحن نعلم أن كل انتقال فوري هو في الأساس ليس سوى الإحداثيات (س ، ص) على الخريطة النجمية لقطاع أوميغا. نحن نعلم أيضًا أننا سنحتاج إلى طريقة ما للإشارة إلى عدد عمليات النقل عن بُعد النشطة ، لذلك سنضيف خلية تسمح لك بتعيين عدد عمليات النقل عن بُعد. نستخدم فقط الانتقال الفوري D عند استخدام 4 ثقوب دودية ، و C فقط عندما يكون لدينا 3 أو أكثر.
أدناه سنقوم بإعداد جدول لحساب المسافة من كل نظام نجمي إلى أقرب محطة اتصالات برقية. يبدو هذا الجدول كما يلي:
يُظهر اللون الأزرق الأيسر إحداثيات كل نظام نجمي على الخريطة. كل صف هو نظام نجمة واحدة. قمنا ببساطة بنقلها من خريطة قطاع أوميغا ، والتي قدمها لنا المصمم الرائد.
على اليمين ، نحسب المسافة لكل من الناقلات عن بعد الأربعة. هذه مجرد نظرية فيثاغورس. تُحسب المسافة على أنها الجذر التربيعي للمسافات الأفقية والرأسية بين النظام النجمي والنقل الفضائي:
= SQRT (($ B14-Axe) ^ 2 + ($ C14-Ay) ^ 2)
(لا تقلق - أعدك أن هذه هي أصعب الرياضيات التي سنلتقي بها في السلسلة!)
نأخذ الإحداثيات X و Y لكل نظام نجمي من الخلايا الزرقاء في الجدول أعلاه ، والإحداثيات X و Y لكل انتقال فوري (خلايا تحمل أسماء Ax و Ay للنقل الفوري A في دالة SQRT () الموضحة أعلاه) من خلايا المحلول الأصفر في الأعلى.
أخيرًا ، نأخذ الحد الأدنى من هذه القيم الأربع في العمود Dist to Closest ، أي أننا ببساطة نستخدم الدالة MIN () لتحديد الحد الأدنى للقيم الأربع على اليسار. ثم نلخص العمود بأكمله أدناه ؛ المجموع هو الخلية المستهدفة.
ربما لاحظت أنه في لقطة الشاشة ، تم تعيين جميع الخلايا على Dist إلى D. والسبب هو أننا نستخدم خلية "عدد أجهزة النقل عن بعد؟" في القسم العلوي من نموذج الحل ، والذي يسمح لك بتكوين عدد عمليات النقل عن بُعد التي تم أخذها في الاعتبار. إذا كان عدد الناقلات عن بعد 2 ، فإننا نستخدم القيمة 99 في كل من Dist إلى C و Dist to D ، وإذا كان 3 ، فسيتم استخدام القيمة 99 فقط في العمود Dist إلى D. وبالتالي ، فإن كل نظام نجمي سيتجاهل جميع أجهزة النقل عن بُعد غير الضرورية عند حساب المسافة إلى أقرب محطة للنقل الفضائي في حالة وجود 2 أو 3 محطات اتصالات أرضية.
الآن سنطلق Solver:
الخلية الهدف هي مجموع أسفل العمود Dist إلى Closest. لاحظ أنه بخلاف الأمثلة الأخرى ، نريد هنا استخدام زر الاختيار "To: Min" لأننا نحتاج إلى حد أدنى من المسافة بين جميع أنظمة النجوم وأجهزة النقل عن بُعد ، وليس كحد أقصى.
أدناه ، سنشير إلى ثماني خلايا صفراء لحل إحداثيات X و Y من الثقوب الدودية A و B و C و D كخلايا للحلول (عن طريق تغيير الخلايا المتغيرة). في قسم القيود ، سنحدد كل من الإحداثيات كقيمة صحيحة في النطاق من 0 إلى 12. لاحظ أننا نستخدم قيدًا صحيحًا لخلايا الحل هذه ، لأننا نعني أن المصمم الرئيسي يريد فقط معرفة الخلية التي سيكون فيها كل انتقال عن بعد ، ولكن يمكننا بسهولة تخطي هذا التقييد إذا احتاج المصمم إلى إحداثيات مادية.
إذا طلبنا "عدد الناقلات؟" القيم 2 و 3 و 4 ، وبالتسلسل سنطلق Solver عند كل قيمة ، سنحصل على التكوينات التالية:
بالحصول على هذه المعلومات ، يمكننا الاقتراب من المصمم الرائد وإظهاره المواقع المثلى لموقع أي عدد من الناقلات عن بُعد في النطاق من 2 إلى 4. هذه هي الطريقة التي تبدو بها المواقع المثلى لـ "الثقوب الدودية" لـ 2 و 3 و 4 عن بعد على الخريطة (كما هو موضح باللون الأخضر).
يمكن تنزيل جدول البيانات لهذا المثال
من هنا .
هل تحدثت عن النينجا؟
يقول المصمم الرئيسي: "مذهل" ، لكنك ترى المعاناة على وجهه. "آه ، لكن نسيت أن أخبرك أن بعض هذه الأنظمة يسكنها نينجا الفضاء. ونريد أن تكون الأنظمة مع النينجا بعيدة عن "الثقوب الدودية" حتى لا يشعر اللاعبون بالتهديد المفرط.
"رائع. هذا يغير القضية تماما ".
"حق. بالإضافة إلى ذلك ، في بعض أنظمة النجوم لا توجد مستعمرة واحدة بل مستعمرتان ، أي أنها ضعف أهمية كونها قريبة من الناقلات عن بعد. أو أنه من المهم مضاعفة ذلك إذا كان نظامًا يحتوي على مستعمرتين من نينجا الفضاء. إليك ما تبدو عليه الخريطة الآن: "
ويتابع: "كل رقم سالب هو مستعمرة النينجا الفضائية. يحتوي النظام ذو الرقم 2 على مستعمرتين بشريتين ، ومع الرقم -2 يحتوي على مستعمرتين من النينجا. هل يمكنك إخباري بمكان وضع الناقلات عن بعد في هذه الحالة؟ "
"قل لي ، لقد قررت بالفعل على الأقل عدد المواصلات البعيدة: 2 أو 3 أو 4؟" ، تسأل ساخرًا.
"أنا خائفة ليس بعد."
نحل مع مراعاة النينجا
لحل هذه المشكلة ، نحتاج إلى إضافة عمود جديد إلى الجدول يشير إلى وزن الجدول. سنطلق عليه "المضاعف". سنقوم ببساطة بضرب هذه القيمة في القيمة في العمود Dist to Closest.
عندما نقوم بذلك ، يغير Dist to Closest معناه قليلاً. الآن هذه ليست المسافة إلى أقرب نظام نجمي ، لأن أنظمة النينجا ستار تتغير القيمة -1 مرة. إنها تشبه "نقاط" أكثر عمومية (النتيجة) ، لذلك دعونا نطلق عليها ذلك.
وبالتالي ، تشير النقاط الآن إلى القيمة التراكمية. من خلال تقليله ، نجعل Solver يسعى ليكون قريبًا جدًا من الأنظمة ذات المستعمرات البشرية قدر الإمكان وفي نفس الوقت بعيدًا قدر الإمكان عن أنظمة النينجا المأهولة.
الآن نحصل على النتائج التالية:
كما ترون ، هذا يعطينا تكوين الناقلات ، في كل حالة مختلفة تمامًا عن الإصدارات الأبسط بدون النينجا.
يمكن تنزيل جدول البيانات الخاص بهذا الإصدار الموسع من مثال الانتقال الفوري
من هنا .
كما ترى ، كان نموذج الحل الخاص بنا قادرًا على حل هذه المهمة غير التافهة بسرعة كبيرة ، ويمكننا تكييفها مع المتطلبات المتغيرة.
تنتمي هذه المهمة إلى فئة المهام المسماة "مهام تخصيص الكائنات" ، والتي يتم دراستها جيدًا في مجال الإدارة التشغيلية. ولكن كما ترى ، يمكن استخدامها في تصميم اللعبة ، وكذلك في تصميم المستوى ، والحل بسيط (إن لم يكن تافهًا) في Excel.
Player-vs-Player
: في الأجزاء الثلاثة السابقة من سلسلة المقالات هذه ، قدمنا أنفسنا لمفهوم النمذجة وتحسين الحلول ، بالإضافة إلى أداة "Solver" لحزمة Excel. لقد أظهرنا كيف يمكن استخدامها لحساب معدلات الضرائب المثلى للمدينة في استراتيجية 4X ، لتحديد الوضع الأمثل للناقلات عن بعد في لعبة الفضاء ، وتحديد تخطيط السلاح الأمثل لمهمة الدبابة الفائقة الموصوفة في الجزء الأول.يطرح سؤال طبيعي: ماذا عن موازنة اللعبة؟ هل من الممكن تطبيق تقنيات مماثلة على جميع أنواع مهام الموازنة المعقدة الموجودة في العديد من أنواع الألعاب المختلفة ، على وجه الخصوص ، في الإستراتيجيات و RPG و MMORPG؟الإجابة على هذا السؤال هي نعم بالطبع ولكن مع الكثير من التحفظات. تحتوي جداول البيانات على وجه الخصوص على العديد من القيود ، لأنها في معظم الحالات غير التافهة لا تصف اللعبة بدقة. لذلك ، سيكون من الصعب علينا إجراء موازنة موثوقة باستخدام تقنيات التحسين ؛ ستكون مهام الموازنة الحقيقية للغالبية العظمى من الألعاب أبعد بكثير مما يمكننا تصميمه في جدول بيانات. عادةً ما تكون محاكاة اللعبة نفسها معقدة للغاية ، وتحتوي على الكثير من "الأجزاء المتحركة" وغالبًا ما يتم تنفيذها في الوقت الفعلي ، عندما نحاول محاكاة المحاكاة المنفصلة ، يمكننا مواجهة جميع أنواع المشاكل.لذلك ، إذا أردنا استخدام تقنيات مماثلة لموازنة الطبقات في MMORPGs مثل WildStar أو في الألعاب الاستراتيجية مثلإبادة الكواكب ، ثم لضمان بعض الدقة والفائدة على الأقل ، سيكون علينا دمجها في محاكاة اللعبة نفسها.بالإضافة إلى ذلك ، الحقيقة هي أنه لا يمكن أتمتة بعض جوانب التوازن ؛ كما أوضحنا في الجزء الأول من المقالة ، من المستحيل تعديل تجربة اللعبة تلقائيًا.لذلك ، فإن أفضل ما يجب أن نأمله هو عرض مثال بسيط يوضح النهج العام للمهام من هذا النوع: مع مثال بسيط في Excel ، سنتعلم كيفية التعامل مع صياغة هذا النوع من مشاكل التوازن وتحسينها. سنوضح أنه ، على الأقل كمثال على معركة بسيطة ، يمكن لـ Solver أن يوازن العديد من فئات RPG بالنسبة لبعضها البعض. ثم يمكنك استخدام هذا الهيكل الأساسي كأساس لحل مشكلات التحسين هذه مع مخطط أكثر تعقيدًا وأكثر اندماجًا في محاكاة اللعبة.نأمل أن تتعلم معنا جميع الحيل ونرى ما يمكن أن يقدمه لنا هذا المثال البسيط.غير متوازن
لا يوجد تعريف واحد مقبول بشكل عام لكلمة "موازنة". لها العديد من المعاني ، وعادة ما يعتمد صحيح على سياق اللعبة المعنية. في ظروف مختلفة ، يمكن أن ترتبط الموازنة بإعداد عدة فئات من الشخصيات من أجل مساواة قدراتهم في لعبة لعب الأدوار ، مع عدد قوى الخصوم الذين يقاتلون بعضهم البعض في لعبة استراتيجية ، أو مع تعديل تكلفة الوحدات أو الموارد المختلفة وفقًا لفائدتها.يعتمد أفضل تعريف "للموازنة" عادةً على أهداف تصميم اللعبة المعنية ، ولكن نظرًا لأن هذه الأهداف يمكن أن تكون أي هدف ، فمن المستحيل تحديد بداهة ما يعنيه التوازن حقًا للألعاب بشكل عام.يميل بعض اللاعبين إلى الاعتقاد بأن الموازنة في المعركة تعني الضرر المتساوي. هذا ينطبق بشكل خاص على ألعاب MMORPG ، حيث يشتكي اللاعبون غالبًا من أن الضرر في الثانية (DPS) لفئة واحدة صغير جدًا أو كبير جدًا بالنسبة للفئات الأخرى.بالطبع ، لا يمكن الموازنة بين الصفوف بواسطة DPS فقط ؛ من المقبول أن يكون لفئة واحدة DPS أكبر من فئة أخرى ، ولكن يجب أن يقابلها عوامل أخرى تحد من الفائدة الإجمالية للفئة ، على سبيل المثال ، انخفاض البقاء على قيد الحياة أو DPS على المدى الطويل مقارنة مع DPS على المدى القصير.MMO صغيرة
تخيل أننا ننشئ مشروعًا جديدًا ، وهي لعبة متعددة الأدوار مبسطة للغاية متعددة اللاعبين عبر الإنترنت تسمى "Tiny MMO". كجزء من تطوير التصميم ، نسعى جاهدين لتحقيق التوازن بين الفئات الأربعة لمعارك لاعب إلى لاعب (PVP) بحيث تكون جميع الفئات الأربعة متساوية نسبيًا في المعركة ضد بعضها البعض ، وأنه لا توجد فئة واضحة "أفضل" أو "أسوأ" يمكنك محاربة الطبقات الأخرى.على الرغم من أن Tiny MMO هي لعبة في الوقت الفعلي ، فإن عمل كل لاعب يستمر 3 ثوانٍ بالضبط ، لذا يمكننا تقسيمها من خلال تقديمها على أنها لعبة قائمة على الأدوار ، حيث يكون كل دور عبارة عن حصة بثلاث ثوانٍ من اللعب.يمكن للاعبين في هذه اللعبة اختيار واحدة من أربع فئات للشخصيات:- المحارب يفعل أكبر ضرر.
- يلقي ماجى نوبات من مسافة بعيدة ولديه أطول مدى من الهجمات من جميع الفئات الأربع
- يتم علاج المعالج (المعالج) تلقائيًا ، مع استعادة جزء معين من صحته لكل دور
- البربرية (البربرية) هي الأكثر صحة
هذا كل ما نعرفه عن هذه الفئات الأربعة ، ونحتاج إلى تعيين المعلمات الأولية للصحة (HP) والأضرار والشفاء ومجموعة الهجمات لجميع الفئات الأربعة. نحن بحاجة إلى موازنتهم بطريقة تجعل كل فئة فريدة وخصائصها تختلف اختلافًا كبيرًا عن جميع الفئات الأخرى ، ولكن نتيجة لذلك تتحول كل فئة إلى "متوازنة" قدر الإمكان فيما يتعلق بالفئات الثلاثة الأخرى.بعبارة أخرى ، نحن نسعى جاهدين لتحسين الجدول التالي:بينما نستخدم قيمًا مؤقتة ونفترض أن كل فئة تبدأ بـ 50 حصانًا ، تتسبب في 10 ضرر في كل دور ، وتشفى 0 حصان في كل دور ولها نطاق هجوم 40 مترًا. كل شخصية تتحرك بسرعة 10 أمتار في كل دور. نظرًا لأن التصميم يشير إلى أن جميع الفئات الأربعة من الأحرف يمكن أن تتحرك بنفس السرعة ، فسوف نعتبر هذه القيمة ثابتة ، ولن ندخل سرعة الحركة في جدول متغيرات القرار.من الواضح أن هذه دراسة حالة مع نموذج ضرر مبسط للغاية. هذا هو متوسط قيمة الضرر المستمر في الثانية ، والذي يتجاهل الفرق بين الضرر النبضي والأضرار طويلة المدى ، وكذلك المانا والميكانيكا الأخرى التي تعدل القدرات الهجومية للفئات. سيكون لدينا نوع واحد فقط من الضرر ، وهو غير واقعي تمامًا ، لأن معظم الفئات لديها عشرات أنواع الضرر ، وسنحتاج إلى تنفيذ نظام AI يقوم بتحديد الهجوم في كل دور. بالإضافة إلى ذلك ، في معظم الألعاب ، يكون للضرر عنصر عشوائي ، ولكن في الوقت الحالي سنقوم بحذف هذا ونفترض أن تنوع الضرر ليس كبيرًا لدرجة أنه يؤثر بشكل كبير على نتيجة المعركة بين الفئتين.بالطبع ، من غير المحتمل أن تكون أي موازنة تتم في Excel مثالية أو متسقة مع التوازن النهائي للعبة ؛ سيتعين عليها أن تمر بالعديد من التكرارات لاختبار اللعب. ولكن إذا استغرقنا ساعة أو ساعتين للحصول على خيار أول جيد للعبتنا في Excel ، فمن المرجح أن نقترب على الأقل من المعلمات النوعية للرصيد الأولي ، مما سيقربنا من الرصيد النهائي الذي نريد الحصول عليه.طاولة النصر
نحن بحاجة إلى تحقيق التوازن بين أربع فصول مع بعضها البعض في معركة فردية. نظرًا لأن لدينا 4 فصول فقط (Warrior و Mage و Healer و Barbarian) ، هناك 6 مجموعات ممكنة من الفئات المختلفة:- المحارب - ماجى
- المحارب - المعالج
- محارب - بربري
- ماجى - المعالج
- ماجى - البربرية
- المعالج - البربري
يمكن أن يكون هذا التوازن معقدًا للغاية. حتى في حالتنا البسيطة نوعًا ما مع أربع فصول ، حصلنا على ست علاقات بين الفئات ، تمامًا كما يمكننا رسم ستة خطوط بين أربع نقاط من المربع.في كل مرة نريد أن نجعل حتى تغيير طفيف في واحدة من المعلمات من أي من الفئات، وهذا التغيير يؤثر أيضا على حماية الأصناف النباتية التوازن بين هذا الزوج من الطبقات، و الآخر فئتين. لن ينمو هذا الترابط بين قانون السلطة إلا مع زيادة عدد الفئات ، ويمكن أن تصبح القرارات المتعلقة بموازنة حماية الأصناف النباتية بين أي زوج من الفئات التي يتم إجراؤها "في فراغ" ، دون مراعاة جميع التفاعلات الأخرى ، أمرًا خطيرًا للغاية.من الناحية المثالية ، نود إنشاء نوع من طاولة النصرمثل تلك المبينة أدناه. إذا استطعنا محاكاة معركة بين كل من هذه الأزواج الستة في جدول بيانات ، فسنتمكن من إنشاء متغير "نقاط" معين لكل زوج من الأزواج الستة. كلما زاد عدد النقاط ، كان ذلك أفضل ، حتى نتمكن من الجمع بين جميع هذه النقاط الست لإنشاء دالة هدف.لاحظ أنه في الجدول أعلاه ، تكون الخلايا على طول الأقطار صفرًا ، لأنها تشير إلى أزواج من نفس الفئة التي سيتم موازنتها بالتعريف. بالإضافة إلى ذلك ، تكون الخلايا الموجودة في الركن الأيمن العلوي صفرًا أيضًا ، لأنها تشير إلى نفس الأزواج تمامًا كما في الخلايا الموجودة في أسفل اليسار.الآن دعنا نجهز النموذج للمعركة بين فئتين مختلفتين."محاكاة معركة"
سنرتب كل زوج من الفصول على مسافة 100 متر من بعضها البعض. كل شخصية لديها 3 ثوان للهجوم ، لذلك يمكننا أن نتخيل هذا على أنه محاكاة مبنية على الدوران حيث تعني كل "حركة" 3 ثوان. في كل "حركة" ، يهاجم كل شخص الآخر ، إذا كان في نطاق الهجوم ، أو يواصل التحرك لتقليل المسافة.تبدو المحاكاة كما يلي:أعلاه زوج من الشخصيات دخلوا المعركة: في هذه الحالة ، Mage (class 1) و Healer (class 2). يعرض العمود الأيسر المسافة الحالية بين الحرفين المحاكيين.بالنسبة لكل حرف ، ستكون الأعمدة:- Max Range : , . .
- Healing : , .
- HP : . HP , . , .
- Damage : , , . , 0.
- هجمات؟ : يتحقق هذا العمود مما إذا كان الحرف ضمن نطاق الهجوم. إذا كان الأمر كذلك ، فهذا يعني أن الشخصية تهاجم في المنعطف الحالي ؛ إذا لم يكن الأمر كذلك ، فإن الشخصية تقترب للوصول إلى شخصية أخرى.
وهكذا ، يبدأ كلا الشخصين في التحرك تجاه بعضهما البعض ، ثم يهاجمان حتى يموت أحدهما أو كلاهما. كل حرف يتحرك لكل 3 ثوانٍ 5 أمتار (5 أمتار لكل "دور"). عندما يتحرك كلا الحرفين تجاه بعضهما البعض ، سيتغير النطاق في كل دور بمقدار 10 وحدات ، وب 5 وحدات إذا تحركت وحدة واحدة فقط. اللعبة نفسها منظمة بحيث يمكن للشخصين البدء في التحرك في وقت واحد ، وبعد ذلك يُسمح بالحركة في نفس الوقت ، لذلك من الممكن أن يموت الشخصان في نفس الوقت.
بعد ذلك ، نحتاج إلى إعداد النقاط لهذا الجدول وإنشاء قيمة رقمية تشير إلى مدى جودة "المعركة" ؛ وبعبارة أخرى ، ما مدى قربنا من تحقيق أهداف التصميم لدينا.
من الواضح أننا نريد أن كلا الشخصين قد ماتا بحلول نهاية المعركة ، أو على الأقل أن يكونا قريبين من الموت قدر الإمكان. إذا كانت المعركة متوازنة ، فيجب أن تقلل كلا الطبقتين من صحة العدو في نهاية المعركة.
ومع ذلك ، هذا وحده لا يكفي. إذا قمنا بتنظيم التسجيل بهذه الطريقة ، فسيقوم المُحسِّن ببساطة بزيادة قيم الضرر إلى الحد الأقصى بحيث يقتل كل من الطرفين الآخر على الفور! (إذا كنت مهتمًا ، فحاول تغيير جدول البيانات المرفق بالمقال لترى بنفسك.) من الواضح أننا لا نهدف إلى الموت الفوري: نحتاج إلى أن تكون كلتا الشخصيتين ميتتين أو شبه ميتتين بحلول نهاية المعركة ، ولكن
في نفس الوقت نريد أن يستمر القتال لفترة زمنية معقولة.
وبعبارة أخرى ، نحن لا نسعى فقط لضمان توازن متساوٍ نسبيًا بين جميع الطبقات ضد بعضها البعض ؛ نريد أيضًا أن نجعل التوازن
مثيرًا للاهتمام ، بما في ذلك القتال الذي يدوم لفترة مناسبة من الوقت.
لإنشاء تقدير التوازن هذا ، نحتاج إلى إنشاء عدة خلايا على يمين كل جدول. تشير
المدة إلى مدة المعركة ؛ هي تحسب عدد الصفوف في الجدول التي لا تزال فيها
كلتا الشخصيتين على قيد الحياة. يحسب
Total HP إجمالي نقاط الضرب للشخصين المتبقيين. من الناحية المثالية ، يجب أن تكون 0 ، أي أنه عندما تنتهي المعركة ، يموت الشخصان.
وأخيرًا ، تجمع النتيجة المدة والمجموع الكلي لنقاط النتيجة في النموذج (المدة / (1 + إجمالي نقاط الصحة)). لاحظ أننا أضفنا 1 إلى المقسوم ، لأن Total HP يمكن أن يكون 0 ، وفي هذه الحالة سنحصل على القسمة على صفر خطأ. بهذه الطريقة ، يمكننا أن نضمن أننا نكافئ المحسن لإيجاد الحد الأقصى لمدة المعركة والحد الأدنى لقيمة مجموع نقاط الضرب.
(لاحظ أنه نظرًا لأن لدينا 17 خطًا في كل "محاكاة" للقتال من فئة إلى أخرى ، وهذا يعني أننا اتخذنا قرارًا أساسيًا بأن القتال يجب أن يستمر حوالي 17 جولة. إذا أردنا أن تكون المعركة أقصر أو لفترة أطول ، يمكنك تغيير عدد الصفوف ، وتعديل الصيغة لحساب النتيجة ، وإجراء تحسين ثاني وفقًا لذلك.)
أخيرًا ، نأخذ قيم النقاط الست هذه (واحدة لكل جدول) ونستخدمها في جدول النصر أعلاه لإظهار نتائج المعركة بين كل زوج من الفئات.
يمكنك ببساطة تلخيص قيم النقاط الست هذه واستخدام النتيجة كقيمة النتيجة النهائية. ومع ذلك ، إذا فعلنا ذلك ، فلن يتمكن Solver على الأرجح من إيجاد توازن جيد بين أعلى وأدنى تقييمات للمعارك الفردية ، وسيتلقى أيضًا تقييمات عالية جدًا لبعض أزواج الصفوف وتصنيفات منخفضة للآخرين. هذا ليس ما نريده: نحن بحاجة إلى أن تكون
جميع العلامات عالية ونكافح لرفعها جميعًا. لإصلاح ذلك ، نضرب مجموع الدرجات في
أصغر درجة في المجموعة (باستخدام وظيفة Excel MIN ()) لجعل تركيز Solver على الدرجات ذات القيمة الأقل.
أضف قيودًا
لم ننتهي بعد. إذا قمت بتحسين نموذج حل بالمعلمات الحالية ، فمن المرجح أنه لن يتم تكوين الفئات بشكل صحيح - في الواقع ، من المحتمل جدًا أن يكتب النموذج نفس قيم HP و Damage و Healing و Range إلى جدول متغيرات القرار.
ونريد بالطبع أن يكون لكل فصل شخصيته الخاصة. نحن بحاجة إلى المحارب للقيام بأكبر قدر من الضرر ، ولدى Mage أكبر مجموعة ، وللمعالج الحد الأقصى لقيمة الشفاء ، وللبربري أعلى نقاط الصحة. نريد أيضًا ألا تكون هذه الاختلافات صغيرة جدًا - نحتاج إلى أن تكون هذه الفصول مختلفة تمامًا عن بعضها البعض.
للقيام بذلك ، سنقوم بإنشاء جدول صغير من القيود. يضمن هذا الجدول أن كل فئة من الفئات الأربع سيكون لها سمة مقابلة ، ثم تعطي درجة 0 أو 1 ، اعتمادًا على ما إذا كان شرط القيد مستوفى.
يوضح الاختلاف الأدنى في الجدول على اليسار الحد الأدنى للاختلاف لكل سمة من سمات الفئة بالنسبة لجميع الفئات الأخرى. بمعنى آخر ، يجب أن يكون لدى المحارب ضرر أكبر بمقدار 4 نقاط قوة على الأقل من جميع الفئات الأخرى ، ويجب أن يكون لدى Mage نطاق هجوم لا يقل عن 10 ، وهكذا.
الآن بعد أن أضفنا هذه القيود الخاصة ، حان الوقت لتحسين!
ابحث عن حلول
الآن يمكننا تشغيل أداة Solver ("Finding Solutions") المضمنة في Excel لمحاولة تحسين المعلمات الأولية. بصفتنا الخلية المستهدفة ، سنحدد خلية النتيجة ، والتي تجمع نتائج جميع البطولات الست. قمنا بتعيين متغيرات القرار لتضمين جميع الخلايا الـ 16 في جدول متغيرات القرار الأصفر الذي أنشأناه في البداية.
نقوم أيضًا بتعيين القيود (في حقل الموضوع إلى القيود) على النحو التالي:
- يجب أن تكون جميع خلايا القرار عددًا صحيحًا بحد أدنى للقيمة 0.
- يجب أن تكون قيمة جميع الخلايا في عمود HP بحد أقصى 200 وحد أدنى 30.
- تصل قيمة جميع الخلايا في عمود الضرر إلى 20.
- الحد الأقصى لقيمة كل الخلايا في عمود الشفاء هو 15.
- الحد الأقصى لقيمة جميع الخلايا في عمود النطاق هو 100.
- بالإضافة إلى ذلك ، يجب تعيين جميع الخلايا الأربع في قسم القيود الخاصة على 1 لاستيفاء شروطها الخاصة.
أخيرًا ، اضبط طريقة الحل على تطوري وقم بتشغيل Solver. يرجى ملاحظة أنه نظرًا لأن هذه خوارزمية تطورية ، فهناك فرصة لتحسين الحل الذي تم العثور عليه أثناء تشغيل Solver الثاني أو الثالث ، أو بعد تعيين المعلمات (زر الخيارات) للتحسين التطوري.
نتيجة لذلك ، يجب أن نحصل على شيء مماثل:
... وكما لو كان السحر ، أعطانا Solver تكوينًا أوليًا جيدًا للرصيد.
كما ترون ، فإن Warrior يتسبب الآن بأكبر قدر من الضرر ، Mage لديه أكبر مجموعة ، Healer يشفي بشكل أفضل ، و Barbarian لديه أكثر HP. بالإضافة إلى ذلك ، يمكنك الانتقال إلى نتائج البطولات الفردية "فئة ضد فئة" ورؤية كيف أظهرت الطبقات نفسها في معركة مع بعضها البعض. كما ترون ، فإن معظمهم متوازنون بشكل متساوٍ للغاية - في نهاية المعركة يموت كلا الطبقتين ، أو أن أحدهما بالكاد ينجو. بالإضافة إلى ذلك ، تستمر جميع البطولات لفترة طويلة بما فيه الكفاية ، ولا يمكن لأي فصل من الصفوف أن "يتراجع" عن الآخر.
ليس سيئًا لبضع ساعات من العمل ، أليس كذلك؟
الخلاصة
في هذا المثال ، أنشأنا مهمة موازنة بسيطة وأثبتنا أنه في الواقع يمكننا حلها بمساعدة المحاكاة والتحسين. على الرغم من أنه من الواضح أن هذا مثال بسيط ، إلا أنه يوضح لنا قوة تقنيات النمذجة وتحسين القرار. بالإضافة إلى ذلك ، يمكن أن تصبح مصدر إلهام يمكن استخدامه في أدوات الموازنة الأكثر تعقيدًا ، والمدمجة بإحكام في محاكاة اللعبة. نأمل أن تتمكن من استخدام هذا المثال كدليل لصياغة مثل هذه المهام في الممارسة العملية.
في الجزأين التاليين من السلسلة ، سنتعمق في مجال مهام المهمة ، والتي ترتبط باختيار التعيينات المثلى من مجموعتين أو أكثر من الكيانات. سنوضح كيفية حل هذه الأنواع من المشاكل ونوضح كيف استخدمنا هذا النهج لإنشاء تصميم برج في لعبة إستراتيجيتنا لنظامي iOS / Android
City Conquest .