GameDev 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 देता है। अब हम a + b को वापस करने के लिए ऐड को सही तरीके से निष्पादित कर सकते हैं । टेस्ट पास होंगे। यह वर्कअराउंड की तरह लग सकता है, लेकिन इसके कई फायदे हैं:

यदि हम गलती से एड - बी लिखते हैं , तो हमारे परीक्षण काम नहीं करेंगे, और हम तुरंत सीखेंगे कि फ़ंक्शन को कैसे ठीक किया जाए। परीक्षणों के बिना, हम इस त्रुटि को नहीं पकड़ सकते हैं और एक गैर-मानक प्रतिक्रिया देख सकते हैं जो डीबग करने में समय लेगी।
हम परीक्षण जारी रख सकते हैं और कोड लिखते समय उन्हें किसी भी समय चला सकते हैं। इसका मतलब यह है कि यदि कोई अन्य प्रोग्रामर गलती से ऐड करता है , तो वह तुरंत त्रुटि को पहचान लेगा - परीक्षण फिर से विफल हो जाएंगे।

खेल देव में TDD

गेम देव में टीडीडी के साथ दो समस्याएं हैं। सबसे पहले, कई गेम फ़ंक्शन में व्यक्तिपरक लक्ष्य होते हैं जिन्हें मापा नहीं जा सकता है। और दूसरी बात, दुनिया के अंतरिक्ष की उन सभी संभावनाओं को कवर करने वाले परीक्षण लिखना कठिन है जो जटिल अंतःक्रियात्मक वस्तुओं से भरे हुए हैं। डेवलपर्स जो अपने पात्रों के आंदोलनों को "अच्छे दिखना चाहते हैं" या शारीरिक सिमुलेशन "झटकेदार नहीं दिखना चाहते हैं", इन मैट्रिक्स को निर्धारक "पारित / पारित नहीं" शर्तों के रूप में व्यक्त करना मुश्किल होगा।

हालांकि, टीडीडी तकनीक जटिल और व्यक्तिपरक विशेषताओं पर लागू होती है - उदाहरण के लिए, चरित्र आंदोलन। और खेल एलीमेनटेर्रा में हमने यह किया।

डिबग स्तर के खिलाफ यूनिट परीक्षण

अभ्यास शुरू करने से पहले, मैं एक स्वचालित इकाई परीक्षण और एक पारंपरिक "डिबग स्तर" के बीच अंतर करना चाहता हूं। कृत्रिम स्थितियों के साथ छिपे हुए स्थान बनाना, gamedev में एक सामान्य बात है। यह प्रोग्रामर और क्यूए को व्यक्तिगत घटनाओं की निगरानी करने की अनुमति देता है।


लीजेंड ऑफ ज़ेल्डा में सीक्रेट डिबगिंग स्तर: द विंड वेकर

एलिमेनटेर्रा में कई ऐसे स्तर होते हैं: एक खिलाड़ी के चरित्र के लिए समस्याग्रस्त ज्यामिति से भरा स्तर, विशेष उपयोगकर्ता इंटरफेस के साथ स्तर जो कुछ गेम स्टेट्स और अन्य को ट्रिगर करते हैं।

इकाई परीक्षणों की तरह, इन डिबगिंग स्तरों का उपयोग त्रुटियों को पुन: उत्पन्न और निदान करने के लिए किया जा सकता है। लेकिन कुछ मायनों में वे अलग हैं:

यूनिट परीक्षण भागों में सिस्टम को विभाजित करते हैं और प्रत्येक को अलग-अलग मूल्यांकन करते हैं, जबकि डिबगिंग स्तर अधिक समग्र तरीके से परीक्षण करते हैं। डिबगिंग स्तर पर त्रुटि खोजने के बाद, डेवलपर्स को अभी भी मैन्युअल रूप से त्रुटि बिंदु की खोज करने की आवश्यकता हो सकती है।
इकाई परीक्षण स्वचालित हैं और हर बार निर्धारक परिणाम देना चाहिए, जबकि कई डिबग स्तर खिलाड़ी द्वारा "नियंत्रित" होते हैं। इससे सत्रों में फर्क पड़ता है।

लेकिन इसका मतलब यह नहीं है कि यूनिट परीक्षण डिबगिंग के स्तर से बेहतर हैं। उत्तरार्द्ध अक्सर अधिक व्यावहारिक होते हैं। हालांकि, यूनिट परीक्षण का उपयोग उन प्रणालियों पर भी किया जा सकता है जहां यह परंपरागत रूप से मौजूद नहीं है।

खरगोश नरक में आपका स्वागत है

एलेमेनटेर्रा में, खिलाड़ी अंतरिक्ष के तूफान से प्रभावित प्राणियों को बचाने के लिए प्रकृति की रहस्यमय शक्तियों का उपयोग करते हैं। ऐसा ही एक बल है, जिस तरह से प्राणियों को भोजन और आश्रय की ओर ले जाने की क्षमता है। चूंकि ये रास्ते खिलाड़ियों द्वारा बनाए गए गतिशील ग्रिड हैं, इसलिए प्राणी की गति असामान्य ज्यामितीय मामलों और मनमाने ढंग से जटिल इलाके से निपटनी चाहिए।

चरित्र आंदोलन उन जटिल प्रणालियों में से एक है जहां "सब कुछ बाकी सब को प्रभावित करता है।" यदि आपने कभी ऐसा किया है, तो आप जानते हैं कि नया कोड लिखते समय, मौजूदा कार्यक्षमता को तोड़ना बहुत आसान है। क्या आपको छोटे कगार पर चढ़ने के लिए खरगोशों की आवश्यकता है? ठीक है, लेकिन अब वे ढलान पर चढ़ रहे हैं, चढ़ाई कर रहे हैं। क्या आप चाहते हैं कि छिपकली का रास्ता न खत्म हो जाए? इसने काम किया, लेकिन अब उनका विशिष्ट व्यवहार बर्बाद हो गया है।

जैसा कि व्यक्ति एआई और अधिकांश गेमप्ले कोड के लिए जिम्मेदार था, मुझे पता था कि मेरे पास आश्चर्य त्रुटियों के लिए समय नहीं था। मैं तुरंत प्रतिगमन को नोटिस करना चाहता था, इसलिए टीडीडी का उपयोग करके विकास मुझे एक अच्छा विकल्प लगा।

अगला कदम एक ऐसी प्रणाली का निर्माण था जिसमें मैं प्रत्येक आंदोलन मामले को एक नकली पास / असफल परीक्षा के रूप में आसानी से पहचान सकता था:



इस "खरगोश नरक" में 18 अलग-अलग गलियारे हैं। प्रत्येक प्राणी और अपने स्वयं के मार्ग के साथ, केवल तभी स्थानांतरित होने के लिए डिज़ाइन किया गया है जब एक निश्चित आंदोलन कार्य करता है। टेस्ट सफल माना जाता है यदि खरगोश फंसने के बिना एक लंबे समय तक असीम रूप से स्थानांतरित करने में सक्षम है। अन्यथा, असफल। ध्यान दें कि हम केवल प्राणियों के शरीर का परीक्षण करते हैं (अवास्तविक शब्दों में), कृत्रिम बुद्धिमत्ता नहीं। एलमेनटेर्रा में, जीव खा सकते हैं, सो सकते हैं, और दुनिया पर प्रतिक्रिया कर सकते हैं, लेकिन "खरगोश नरक" में उनका एकमात्र निर्देश दो बिंदुओं के बीच चलना है।

ऐसे परीक्षणों के कुछ उदाहरण इस प्रकार हैं:


1, 2, 3: मुक्त गति, स्थिर बाधाएं और गतिशील बाधाएं


8 और 9: एक समान ढलान और उबड़-खाबड़ इलाके


10: फर्श से गायब होना


13: एक बग का पुनरुत्पादन जिसमें जीव अंतहीन रूप से आस-पास के लक्ष्यों के आसपास घूमते थे


14 और 15: फ्लैट और जटिल लीड को नेविगेट करने की क्षमता

आइए मेरे कार्यान्वयन और "स्वच्छ" टीडीडी के बीच समानता और अंतर के बारे में बात करें।

मेरा सिस्टम TDD के समान था:

• मैंने परीक्षण बनाकर कार्यों पर काम करना शुरू किया, और फिर उन्हें चलाने के लिए आवश्यक कोड लिखा।
• मैंने नई विशेषताओं को जोड़ते हुए पुराने परीक्षणों को चलाना जारी रखा।
• प्रत्येक परीक्षण ने सिस्टम के ठीक एक भाग को मापा, जिसने मुझे जल्दी से समस्याओं का पता लगाने की अनुमति दी।
• टेस्ट स्वचालित थे और उन्हें खिलाड़ी इनपुट की आवश्यकता नहीं थी।

और इसमें अलग:

• परीक्षणों का मूल्यांकन करते समय, विषयवस्तु का एक तत्व था। जबकि चलती की वास्तविक गलतियों (चरित्र ए से बी तक नहीं मिला) को प्रोग्रामेटिक रूप से पता लगाया जा सकता है। यही है, उदाहरण के लिए, एक तिरछा स्थिति, एनीमेशन के तुल्यकालन की समस्याओं और घुमा आंदोलन को एक मानव मूल्यांकन की आवश्यकता थी।
• टेस्ट पूरी तरह से निर्धारक नहीं थे। फ्रेम दर में उतार-चढ़ाव जैसे यादृच्छिक कारक, छोटे विचलन का कारण बने। लेकिन सामान्य तौर पर, जीव आमतौर पर समान रास्तों का पालन करते हैं और सत्रों के बीच एक ही सफलता / विफलता होती है।

प्रतिबंध

एक एलमेनटेर्रा प्राणी को स्थानांतरित करने के लिए टीडीडी का उपयोग करना एक बहुत बड़ा धन था, लेकिन मेरे दृष्टिकोण में कई सीमाएँ थीं:

• यूनिट परीक्षणों ने आंदोलन की प्रत्येक विशेषता का व्यक्तिगत रूप से मूल्यांकन किया, इसलिए कई विशेषताओं के संयोजन के साथ त्रुटियों पर विचार नहीं किया गया। कभी-कभी पारंपरिक डिबगिंग स्तरों के साथ यूनिट परीक्षणों को पूरक करना आवश्यक था।
• एलमेनटेर्रा में चार प्रकार के जीव होते हैं, लेकिन परीक्षणों में केवल खरगोश होते हैं। यह हमारे उत्पादन कार्यक्रम की एक विशेषता है (अन्य तीन प्रकारों को विकास में बहुत बाद में जोड़ा गया)। सौभाग्य से, सभी चार में एक ही गतिशीलता है, लेकिन मोस्मोर्क के बड़े शरीर में कई समस्याएं थीं। अगली बार, मेरे पास पहले से रखे गए खरगोशों का उपयोग करने के बजाय चयनित प्रजातियों को गतिशील रूप से अंडे देना होगा।

इस मोसमर्क को खरगोश की तुलना में थोड़ी अधिक जगह की आवश्यकता होती है।

TDD आपकी पसंद है?

डेवलपर्स इकाई परीक्षण स्तरों पर बहुत अधिक प्रयास खर्च कर सकते हैं जो खिलाड़ी कभी भी सराहना नहीं करेगा। मैं इससे इनकार नहीं करता, मुझे खुद "खरगोश नरक" बनाने से बहुत खुशी मिली। इस तरह के आंतरिक कार्य समय लेने वाले और अधिक महत्वपूर्ण मील के पत्थर को खतरे में डाल सकते हैं। ऐसा होने से रोकने के लिए, ध्यान से अध्ययन करें कि इकाई परीक्षणों का उपयोग कहाँ और कब करना है। नीचे मैंने कई मानदंड पर प्रकाश डाला है जो एक एलिमेनटेरा प्राणी के आंदोलन के लिए टीडीडी को सही ठहराते हैं।

1. क्या परीक्षण कार्यों को मैन्युअल रूप से पूरा करने में लंबा समय लगेगा?

इससे पहले कि आप स्वचालित परीक्षण पर समय व्यतीत करें, आपको यह जांचने की आवश्यकता है कि क्या हम पारंपरिक गेम नियंत्रणों का उपयोग करके फ़ंक्शन का मूल्यांकन कर सकते हैं। यदि आप यह सुनिश्चित करना चाहते हैं कि आपकी चाबियाँ दरवाजों को खोलती हैं, तो चाबी को खोलें और उनके लिए दरवाजा खोलें। इस फ़ंक्शन के लिए यूनिट परीक्षण बनाना समय की बर्बादी होगी - मैन्युअल परीक्षण में केवल कुछ सेकंड लगते हैं।

2. क्या मैन्युअल रूप से परीक्षण मामलों को बनाना मुश्किल है?

स्वचालित यूनिट परीक्षण उचित हैं जब मामलों को फिर से शुरू करने के लिए जाना जाता है और मुश्किल है। "खरगोश नरक" का टेस्ट नंबर 7 यह जांचता है कि वे कैसे अगुवाई में चलते हैं - ऐसा कुछ जो एआई आमतौर पर बचने के लिए कठिन प्रयास करता है। खेल नियंत्रणों का उपयोग कर पुन: पेश करने के लिए ऐसी स्थिति मुश्किल या असंभव हो सकती है, और परीक्षण आसान हैं।

3. क्या आप जानते हैं कि वांछित परिणाम नहीं बदलेंगे?

गेम डिज़ाइन पूरी तरह से पुनरावृत्तियों पर आधारित है, इसलिए आपके गेम में बदलाव होते ही सुविधाओं के लक्ष्य बदल सकते हैं। यहां तक ​​कि छोटे परिवर्तन भी मैट्रिक्स को अमान्य कर सकते हैं जिसके द्वारा आप अपनी सुविधाओं का मूल्यांकन करते हैं, और इसलिए किसी भी इकाई परीक्षण। यदि भोजन, नींद और खिलाड़ी के साथ बातचीत के दौरान प्राणियों का व्यवहार कई बार बदल गया, तो बिंदु ए से बिंदु बी तक संक्रमण अपरिवर्तित रहा। इसलिए, आंदोलन कोड और इसकी इकाई परीक्षण पूरे विकास के दौरान प्रासंगिक रहे।

4. क्या प्रतिगमन पर किसी का ध्यान नहीं जाने की संभावना है?

क्या आपके पास एक स्थिति है जब आप गेम भेजने से पहले अंतिम कार्यों में से एक को पूरा करते हैं, और अचानक आपको एक त्रुटि मिलती है जो नियमों को तोड़ती है? और उस फ़ंक्शन में जो आपने कई साल पहले समाप्त किया था। खेल विशाल परस्पर जुड़े हुए सिस्टम हैं, और इसलिए यह स्वाभाविक है कि एक नया फ़ंक्शन B जोड़ने से पुराने फ़ंक्शन A की विफलता हो सकती है।

यह इतना बुरा नहीं है जब हर जगह एक टूटे हुए फ़ंक्शन का उपयोग किया जाता है (उदाहरण के लिए, एक कूद) - आपको तुरंत यांत्रिकी में एक टूटने का नोटिस करना चाहिए। बाद के विकास में पाई गई त्रुटियां अनुसूची को बाधित कर सकती हैं, और लॉन्च के बाद गेमप्ले को नुकसान पहुंचा सकती हैं।

5. सबसे खराब जो परीक्षण का उपयोग करते समय और उनके बिना हो सकता है?

परीक्षण बनाना जोखिम प्रबंधन का एक रूप है। कल्पना कीजिए कि आप तय करते हैं कि वाहन बीमा खरीदना है या नहीं। आपको तीन सवालों के जवाब देने की जरूरत है:

• मासिक बीमा प्रीमियम कितने हैं?
• कार के क्षतिग्रस्त होने की कितनी संभावना है?
• यदि आप बीमाकृत नहीं थे तो सबसे खराब स्थिति कितनी महंगी होगी?

टीडीडी के लिए, हम अपनी इकाई परीक्षणों की सेवा के लिए उत्पादन लागत के रूप में मासिक योगदान की कल्पना कर सकते हैं, बग की संभावना के रूप में कार को नुकसान की संभावना, और प्रतिगमन त्रुटि के लिए सबसे खराब स्थिति के रूप में कार के पूर्ण प्रतिस्थापन की लागत।

यदि सुविधा परीक्षण बनाने में बहुत समय लगता है, तो यह सरल है और इसे बदलने की संभावना नहीं है (या इसे बाद के विकास में टूट जाता है) से निपटा जा सकता है, तो इकाई परीक्षण अच्छे से अधिक समस्याएं पैदा कर सकते हैं। यदि परीक्षण करना आसान है, तो फ़ंक्शन अस्थिर और इंटरकनेक्टेड है (या इसकी त्रुटियों में बहुत समय लगेगा), तो परीक्षण मदद करेंगे।

स्वचालन सीमा

यूनिट परीक्षण त्रुटियों को खोजने और समाप्त करने के लिए एक बढ़िया अतिरिक्त हो सकता है, लेकिन वे बड़े पैमाने पर खेलों में पेशेवर गुणवत्ता नियंत्रण की आवश्यकता को प्रतिस्थापित नहीं करते हैं। क्यूए एक कला है जिसमें रचनात्मकता, व्यक्तिपरक निर्णय और उत्कृष्ट तकनीकी संचार की आवश्यकता होती है।