ربما يكون نظام قدرة الشخصية هو الأكثر مرونة في اللعبة. من المستحيل التنبؤ في مرحلة التصميم بالتعديلات التي ستظهر في الإصدار النهائي أو في التحديثات اللاحقة. سيكون هذا المنشور حول كيفية تجريد عملية أداء القدرات.
القدرة نفسها ليست أكثر من مجموعة من الإجراءات. تتكون واجهة الحد الأدنى من القدرة من طريقة واحدة: "تطبيق" ، ولكن ليس بهذه البساطة حول الصعوبات التي تواجهها عملية القطع.
تبدأ كل قدرة بسلسلة من الاختبارات لمعرفة ما إذا كان يمكن تطبيقها. من بينها تلك العادية ، مثل التحقق من التغذية ، وتوافر مانا ، والتحقق من المسافة وغيرها. من الواضح بالفعل هنا أنه لا يلزم إجراء جميع عمليات الفحص بواسطة جميع القدرات. على سبيل المثال ، هناك قدرات مطبقة في أي مسافة. وهذا هو ، تتطلب قدرات مختلفة مجموعات مختلفة من الشيكات قبل التنفيذ. ومع ذلك ، فمن الواضح أن العديد من عمليات الفحص ستتكرر ، وغالبًا ما تتطلب العديد من القدرات نفس مجموعة الشيكات.
في المجموع ، سيتم تكرار جزء من عمليات الفحص منطقياً ، مما يعني أنه يجب تغييرها كما هو متفق عليه ، أي على الفور في جميع الأماكن. علاوة على ذلك ، فإن مجموعات أجزاء الشيكات في الحالة العامة ستكون مختلفة.
إذا تم تحديد أجزاء من الشيكات في كائنات منفصلة تنفذ واجهة واحدة ومضمنة في قائمة مرتبطة منفردة ، فسنحصل على سلسلة من مسؤوليات القوالب.
في حالة نجاح عملية التحقق في الرابط ، سيبدأ التحقق في الرابط التالي ، إذا لم يكن هناك رابط التالي ، يمكن اعتبار الفحص بأكمله ناجحًا. بالإضافة إلى التحقق نفسه ، قد يحتوي الرابط أيضًا على معالج خطأ. على سبيل المثال ، عند التحقق من mana ، اتضح أنه لا يكفي ، ثم يمكن للرابط أن يخطر اللاعب بذلك.
باستخدام سلسلة الواجبات ، من أجل القدرة [لقطة قوية] ، يمكننا بسهولة إدخال رابط إضافي ، والتحقق مما إذا كانت الشخصية ترتدي القوس أو الرابط ، والتحقق من أن الشخصية لديها مستوى صحي أقل من 30 ٪ ، من أجل القدرة [Wind Second].
دعنا نعود ونتذكر أن هناك سلاسل من الشيكات هي نفسها بالنسبة للعديد من القدرات. دعنا نسلط الضوء على جوهر طلب استيفاء القدرات ووصف كل نوع من أنواع سلاسل الاختبار بفئتها.
الطلب مطلوب فقط لوضع سلسلة من الواجبات وإطلاقها وإلغاءها عندما يعطي اللاعب الأمر المناسب.
سنجعل سلاسل في تطبيقات الاستعلام بالفعل.
في الوقت الحالي ، تعلمنا بالفعل كيفية إجراء اختبارات مرنة للقدرة على أداء القدرات. الآن ، إذا نجح الاختبار ، فلا تزال بحاجة إلى تحقيق هذه القدرة.
لقد فضلت القيام بذلك دون تغيير الواجهات ، مع إضافة الرابط الناجح دائمًا الذي تؤديه القدرة كأثر جانبي. فيما يلي مثال لتنفيذ ذلك:
public class TerminalChecker: ICastChecker { CastChecker next { get; set; } ISkill skill; public TerminalChecker(ISkill skill) { this.skill = skill; } public bool check() { skill.cast(); return true; } }
يتيح لنا هذا التطبيق تقديم طلبات غير متزامنة. هذا مفيد عندما نحتاج إلى معلومات إضافية من المستخدم. على سبيل المثال ، يجب تطبيق القدرة على بعض المناطق التي يحددها اللاعب باستخدام الماوس. بالطبع ، لا يمكنك إيقاف اللعبة في هذا الوقت.
الآن نحن بحاجة إلى مطابقة الطلبات مع القدرات. سنفعل ذلك ، بالطبع ، باستخدام تعدد الأشكال عن طريق إضافة خاصية إلى واجهة القدرة. في هذه المرحلة ، وسعنا القدرة على هذه الواجهة:
بعد كل العمل المنجز ، دعونا نفكر في ما هي القدرة. في التطبيق الحالي ، هذه مجموعة من الإجراءات التي تسبقها سلسلة من الاختبارات. لاحظ أنه على مستوى عالٍ ، لا نعتمد بأي حال على منطق لعبة معين. من خلال الفكرة الأولية لوصف نظام القدرات كما هو مطبق على التعاويذ ، حصلنا على نظام ، وفقًا لقواعد معينة ، يمنحنا أو لا يسمحان لنا بتنفيذ إجراءات تعسفية.
بسبب هذه الخاصية ، يمكن لهذا النظام وصف أي تعديل لعالم اللعبة. على سبيل المثال ، صفقة مبيعات أو بناء فريق البناء.
دعونا نلقي نظرة على كل شيء بشكل عام مرة أخرى
في هذا المثال ، تعد قدرة Sprint قدرة عادية بدون هدف ؛ والفئة التي تنفذ طلب هذه القدرات هي NontargetCastRequest ، والتي بدورها تشكل سلسلة من الاختبارات من ManaChecker و CooldownChecker و TerminalChecker.
لا يعتمد رمز الاتصال على تفاصيل تنفيذ هذا النظام ، أي أننا لن نكسر منطق اللعبة بإضافة أو تغيير القدرة.
هذا هو نظام قدرات الشخصية في الحد الأدنى من الأشكال. يفتقر هذا النموذج إلى وسائل تنبيه رمز الاتصال ونقل القدرات إلى واجهة المستخدم والتفاصيل الأخرى للحياة. يمكنك التفكير فيها بنفسك.