نادرا ما يستخدم TDD في تطوير اللعبة. عادة ما يكون توظيف اختبار أسهل من تخصيص مطور لكتابة الاختبارات - وهذا يوفر الموارد والوقت. لذلك ، يصبح كل استخدام ناجح لـ TDD أكثر إثارة للاهتمام. تحت القص ، ترجمة المادة ، حيث تم استخدام تقنية التطوير هذه لإنشاء حركة الشخصيات في لعبة ElemenTerra.
إن التطوير القائم على الاختبار أو TDD (التطوير من خلال الاختبار) هو تقنية لتطوير البرمجيات يتم فيها تقسيم العملية بأكملها إلى العديد من الدورات الصغيرة. تتم كتابة اختبارات الوحدة ، ثم يتم كتابة التعليمات البرمجية التي تجتاز هذه الاختبارات ، ثم تتم إعادة التسكين. والخوارزمية يكرر.
أساسيات TDD
لنفترض أننا نكتب وظيفة تضيف رقمين. في سير العمل العادي ، نكتبها فقط. ولكن لاستخدام TDD ، يجب أن تبدأ بإنشاء وظيفة عنصر نائب واختبارات وحدة:
// Placeholder-, : int add(int a, int b){ return -1; } // Unit-, , add : void runTests(){ if (add(1, 1) is not equal to 2) throw error; if (add(2, 2) is not equal to 4) throw error; }
في البداية ، لن تعمل اختبارات الوحدة الخاصة بنا ، لأن دالة العنصر النائب ترجع -1 لكل إدخال. الآن يمكننا تنفيذ
الإضافة بشكل صحيح لإرجاع
+ ب . سيتم تمرير الاختبارات. قد يبدو هذا كحل بديل ، ولكن هناك العديد من المزايا:
إذا كتبنا عن طريق الخطأ
add add a a b ، فلن تنجح اختباراتنا ، وسنتعلم على الفور كيفية إصلاح الوظيفة. بدون اختبارات ، لا يمكننا التقاط هذا الخطأ ورؤية رد فعل غير قياسي سيستغرق تصحيحه وقتًا.
يمكننا متابعة الاختبارات وتشغيلها في أي وقت أثناء كتابة الرمز. هذا يعني أنه إذا تغير مبرمج آخر عن غير قصد ، فسوف يتعرف على الفور على الخطأ - ستفشل الاختبارات مرة أخرى.
TDD في ديف اللعبة
هناك مشكلتان مع TDD في تطوير اللعبة. أولاً ، العديد من وظائف اللعبة لها أهداف ذاتية لا يمكن قياسها. وثانياً ، من الصعب كتابة اختبارات تغطي جميع إمكانيات مساحة العوالم المليئة بالكائنات المتفاعلة المعقدة. سيجد المطورون الذين يريدون حركات شخصياتهم "لتبدو جيدة" أو المحاكاة المادية "لا تبدو متشنجة" صعوبة في التعبير عن هذه المقاييس كشروط "مرت / غير مرتقبة" حتمية.
ومع ذلك ، فإن تقنية TDD قابلة للتطبيق على الميزات المعقدة والذاتية - على سبيل المثال ، حركة الأحرف. وفي لعبة ElemenTerra فعلنا ذلك.
اختبارات وحدة ضد مستويات التصحيح
قبل البدء في التدريب ، أريد التمييز بين اختبار الوحدة التلقائي و "مستوى تصحيح الأخطاء" التقليدي. إنشاء مواقع مخفية بظروف اصطناعية أمر شائع في gamedev. هذا يسمح للمبرمجين و QAs بمراقبة الأحداث الفردية.
مستوى تصحيح الأخطاء السري في The Legend of Zelda: The Wind Wakerلدى ElemenTerra العديد من هذه المستويات: مستوى مليء بالهندسة الإشكالية لشخصية اللاعب ، ومستويات مع واجهات المستخدم الخاصة التي تؤدي إلى حالات لعبة معينة وغيرها.
مثل اختبارات الوحدة ، يمكن استخدام مستويات تصحيح الأخطاء هذه لإعادة إنتاج الأخطاء وتشخيصها. ولكن في بعض النواحي تختلف:
تقوم اختبارات الوحدة بتقسيم الأنظمة إلى أجزاء وتقييم كل منها على حدة ، بينما تجري مستويات تصحيح الأخطاء اختبارات بطريقة أكثر شمولية. بعد العثور على الخطأ على مستوى تصحيح الأخطاء ، ربما لا يزال على المطورين البحث يدويًا عن نقطة الخطأ.
اختبارات الوحدة مؤتمتة ويجب أن تعطي في كل مرة نتائج حتمية ، بينما يتم التحكم في العديد من مستويات التصحيح من قبل اللاعب. هذا يحدث فرقا في الجلسات.
ولكن هذا لا يعني أن اختبارات الوحدة أفضل من مستويات تصحيح الأخطاء. الأخيرة غالبا ما تكون أكثر عملية. ومع ذلك ، يمكن استخدام اختبار الوحدة على الأنظمة التي لم تكن موجودة تقليديًا.
مرحبا بكم في أرنب الجحيم
في ElemenTerra ، يستخدم اللاعبون قوى الطبيعة الصوفية لإنقاذ المخلوقات المتأثرة بعاصفة فضائية. واحدة من هذه القوة هي القدرة على تمهيد الطريق الذي يؤدي المخلوقات إلى الغذاء والمأوى. نظرًا لأن هذه المسارات عبارة عن شبكات ديناميكية أنشأها اللاعبون ، يجب أن تتعامل حركة المخلوق مع حالات هندسية غير عادية وتضاريس معقدة بشكل تعسفي.
حركة الأحرف هي واحدة من تلك الأنظمة المعقدة حيث "يؤثر كل شيء على كل شيء آخر." إذا كنت قد فعلت هذا من قبل ، فأنت تعلم أنه عند كتابة التعليمات البرمجية الجديدة ، من السهل جدًا كسر الوظائف الحالية. هل تحتاج إلى أرانب لتسلق الحواف الصغيرة؟ حسنًا ، لكنهم الآن يرتجفون ويصعدون المنحدرات. هل تريد أن تتقاطع مسارات السحلية؟ لقد نجحت ، لكن الآن تم تدمير سلوكهم المعتاد.
بصفتي الشخص المسؤول عن الذكاء الاصطناعى ومعظم كود اللعب ، عرفت أنه لم يكن لدي وقت لأخطاء مفاجئة. أردت أن ألاحظ على الفور الانحدار ، لذا بدا لي أن التطوير باستخدام TDD كان خيارًا جيدًا بالنسبة لي.
كانت الخطوة التالية هي إنشاء نظام يمكنني من خلاله تحديد كل حالة حركة بسهولة في شكل اختبار اجتياز / فشل محاكي:
يتكون هذا "الجحيم الأرنب" من 18 ممرًا معزولًا. كل منها له مخلوق وطريقه الخاص ، مصمم للحركة فقط إذا كانت وظيفة حركة معينة تعمل. تعتبر الاختبارات ناجحة إذا كان الأرنب قادرًا على التحرك لفترة زمنية طويلة بلا حدود دون التعرض للعجز. خلاف ذلك ، غير ناجحة. لاحظ أننا نختبر فقط مجموعة الكائنات (البيدق بعبارات غير حقيقية) ، وليس الذكاء الاصطناعي. في ElemenTerra ، تستطيع المخلوقات أن تأكل وتنام وتتفاعل مع العالم ، ولكن في "جحيم الأرانب" ، فإن تعليماتها الوحيدة هي الركض بين نقطتين.
فيما يلي بعض الأمثلة لهذه الاختبارات:
1 ، 2 ، 3: حرية الحركة ، العقبات الساكنة والعقبات الديناميكية
8 و 9: المنحدرات الموحدة والتضاريس الوعرة
10: اختفاء الكلمة
13: إعادة إنتاج الخلل الذي تدور فيه المخلوقات بلا نهاية حول الأهداف القريبة
14 و 15: القدرة على التنقل الحواف المسطحة والمعقدة
دعونا نتحدث عن أوجه التشابه والاختلاف بين تطبيقي و TDD "النظيف".
كان نظامي مشابهًا لنظام TDD في هذا:
- بدأت العمل على الوظائف عن طريق إنشاء اختبارات ، ثم كتبت الرمز المطلوب لتشغيلها.
- واصلت تشغيل الاختبارات القديمة ، مضيفة ميزات جديدة.
- يقيس كل اختبار جزءًا واحدًا من النظام ، مما سمح لي بالعثور على المشكلات بسرعة.
- كانت الاختبارات تلقائية ولم تتطلب إدخال اللاعب.
و اختلف في هذا:
- عند تقييم الاختبارات ، كان هناك عنصر الذاتية. بينما يمكن اكتشاف الأخطاء الحقيقية في الحركة (لم تحصل الشخصية من A إلى B) بشكل برمجي. هذا هو ، على سبيل المثال ، موقف منحرف ، ومشاكل تزامن الحركة والارتعاش تتطلب تقييما بشريا.
- الاختبارات لم تكن حتمية تماما. عوامل عشوائية ، مثل التقلبات في معدل الإطار ، تسببت في انحرافات صغيرة. ولكن بشكل عام ، تتبع الكائنات عادة نفس المسارات وتتمتع بنفس النجاح / الفشل بين الدورات.
قيود
كان استخدام TDD لتحريك مخلوق ElemenTerra ميزة إضافية ضخمة ، لكن مقاربي كانت لها عدة قيود:
- قامت اختبارات الوحدة بتقييم كل ميزة للحركة بشكل فردي ، لذلك لم يتم النظر في الأخطاء مع مجموعات من عدة ميزات. في بعض الأحيان كان من الضروري تكملة اختبارات الوحدة بمستويات تصحيح الأخطاء التقليدية.
- لدى ElemenTerra أربعة أنواع من المخلوقات ، لكن الاختبارات تحتوي على أرانب فقط. هذه سمة من سمات جدول الإنتاج لدينا (تمت إضافة الأنواع الثلاثة الأخرى لاحقًا في مرحلة التطوير). لحسن الحظ ، يتمتع الأربعة جميعًا بنفس القدرة على الحركة ، لكن جسم موسمورك الكبير تسبب في العديد من المشكلات. في المرة القادمة ، أود إجراء اختبارات ديناميكية لتفرخ الأنواع المحددة بدلاً من استخدام الأرانب الموضوعة مسبقًا.
هذا Mossmork يتطلب مساحة أكبر قليلا من الأرنب.TDD هو اختيارك؟
قد يبذل المطورون الكثير من الجهد على مستويات اختبار الوحدة التي لن يقدرها اللاعب أبدًا. أنا لا أنكر ذلك ، تلقيت نفسي الكثير من السرور من خلق "جحيم الأرانب". يمكن أن تستغرق هذه الوظائف الداخلية وقتًا طويلاً وتعرض معالم هامة أخرى للخطر. لمنع حدوث ذلك ، ادرس بعناية أين ومتى تستخدم اختبارات الوحدة. فيما يلي ، أبرزت العديد من المعايير التي تبرر TDD لحركة مخلوق ElemenTerra.
1. هل يستغرق إكمال مهام الاختبار يدويًا وقتًا طويلاً؟
قبل أن تقضي وقتًا في الاختبار الآلي ، تحتاج إلى التحقق مما إذا كان يمكننا تقييم الوظيفة باستخدام أدوات التحكم التقليدية في اللعبة. إذا كنت تريد التأكد من أن مفاتيحك تفتح الأبواب ، تفرخ المفتاح وتفتح الباب أمامها. سيكون إنشاء اختبارات وحدة لهذه الوظيفة مضيعة للوقت - يستغرق الاختبار اليدوي بضع ثوانٍ فقط.
2. هل من الصعب إنشاء حالات الاختبار يدويًا؟
يتم تبرير اختبارات الوحدة الآلية عندما تكون هناك حالات معروفة وصعبة التكاثر. يتحقق الاختبار رقم 7 من "جحيم الأرانب" من كيفية السير على طول الحواف - وهو أمر يصعب على منظمة العفو الدولية تجنبه عادة. قد يكون من الصعب أو المستحيل تكرار مثل هذا الموقف باستخدام أدوات التحكم في اللعبة ، وتكون الاختبارات سهلة.
3. هل تعلم أن النتائج المرجوة لن تتغير؟
يعتمد تصميم اللعبة بالكامل على التكرارات ، وبالتالي يمكن أن تتغير أهداف الميزات مع تغير اللعبة. حتى التغييرات الصغيرة يمكن أن تبطل المقاييس التي تقيم بها ميزاتك ، وبالتالي أي اختبارات وحدة. إذا تغير سلوك الكائنات أثناء الطعام والنوم والتفاعل مع اللاعب عدة مرات ، فإن الانتقال من النقطة A إلى النقطة B لم يتغير. لذلك ، بقيت رمز الحركة واختبارات الوحدة ذات صلة طوال عملية التطوير.
4. هل من المرجح أن تمر الانحدارات دون أن يلاحظها أحد؟
هل كان لديك موقف عندما أكملت إحدى المهام الأخيرة قبل إرسال اللعبة ، وفجأة وجدت خطأً يخرق القواعد؟ وفي الوظيفة التي انتهيت منها منذ عدة سنوات. الألعاب هي أنظمة عملاقة مترابطة ، وبالتالي من الطبيعي أن تؤدي إضافة وظيفة جديدة B إلى فشل الوظيفة القديمة أ.
ليس بالأمر السيء عند استخدام وظيفة مكسورة في كل مكان (على سبيل المثال ، قفزة) - يجب أن تلاحظ على الفور حدوث انهيار في الميكانيكا. يمكن للأخطاء التي تم اكتشافها في تطور لاحق تعطيل الجدول ، وبعد الإطلاق يمكن أن يضر اللعبة.
5. أسوأ ما يمكن أن يحدث عند استخدام الاختبارات وبدونها؟
إنشاء الاختبارات هو أحد أشكال إدارة المخاطر. تخيل أنك تقرر ما إذا كنت تريد شراء التأمين على السيارات. تحتاج إلى إجابة ثلاثة أسئلة:
- كم تبلغ أقساط التأمين الشهرية؟
- ما مدى احتمالية تلف السيارة؟
- كم سيكون سعر السيناريو الأسوأ إذا لم تكن مؤمن عليك؟
بالنسبة إلى TDD ، يمكننا أن نتخيل مساهمات شهرية في شكل تكاليف الإنتاج لخدمة اختبارات وحدتنا ، واحتمال تلف السيارة في شكل احتمالية حدوث خلل ، وتكلفة الاستبدال الكامل للسيارة باعتبارها أسوأ سيناريو لخطأ الانحدار.
إذا استغرق إنشاء اختبار للميزات وقتًا طويلاً ، فسيكون تغييره أمرًا بسيطًا وغير مرجح (أو يمكن معالجته في حالة توقفه في التطوير اللاحق) ، ثم قد تتسبب اختبارات الوحدة في حدوث مشكلات أكثر من جيدة. إذا كان من السهل إجراء الاختبارات ، فإن الوظيفة غير مستقرة ومترابطة (أو ستحتاج أخطاءها إلى الكثير من الوقت) ، فإن الاختبارات ستساعد.
حدود الأتمتة
يمكن أن تكون اختبارات الوحدات إضافة رائعة لإيجاد الأخطاء والقضاء عليها ، ولكنها لا تحل محل الحاجة إلى مراقبة الجودة الاحترافية في الألعاب واسعة النطاق. ضمان الجودة هو فن يتطلب الإبداع والحكم الذاتي والتواصل التقني الممتاز.