आधुनिक सी ++ और खेल के विकास पर विचार

गेम डेवलपर्स के लिए नया साल आलोचना की एक लहर के साथ शुरू हुआ जो आधुनिक सी ++ के बारे में अरास प्राणकेविच की शिकायतों के प्रकाशन के बाद सी ++ मानकीकरण समिति पर गिर गया। एक गंभीर सवाल उठता है: क्या मानक समिति वास्तव में वास्तविकता से संपर्क नहीं खोती है, या क्या यह दूसरा तरीका है, और क्या ये गेम डेवलपर्स बाकी सी ++ समुदाय से अलग हो रहे हैं?

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

TL; DR: C ++ मानकीकरण समिति के पास खेल डेवलपर्स की जरूरतों को अनदेखा करने का कोई छिपा हुआ लक्ष्य नहीं है, और "आधुनिक" C ++ "डीबग्ड" भाषा नहीं बनने जा रही है।

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

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

एक शुरुआत के लिए - इतिहास में थोड़ा विषयांतर।

कई C ++ गेम डेवलपर Microsoft Visual C ++ में काम करते हैं। ऐतिहासिक रूप से, खेलों के लिए एक बड़ा बाजार माइक्रोसॉफ्ट प्लेटफार्मों के आसपास बना है, और इसने एक सामान्य गेम प्रोग्रामर के विशिष्ट अनुभव को प्रभावित किया है। 90 और 2000 के दशक में, अधिकांश खेल इन परिस्थितियों को ध्यान में रखकर लिखे गए थे। यहां तक ​​कि अन्य निर्माताओं से कंसोल के आगमन और मोबाइल गेम की बढ़ती लोकप्रियता के साथ, कई एएए-स्टूडियो और कई गेम प्रोग्रामर की संपत्ति आज माइक्रोसॉफ्ट द्वारा बनाए गए उपकरण हैं।

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

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

अवसर संख्या 1: प्रकार

हम संकलन के समय कीड़े के पूरे वर्गों को खत्म करने के लिए आवश्यक मजबूत टाइपिंग का उपयोग कर सकते हैं। मजबूत टाइपिंग, एक शक के बिना, सी ++ के हाल के विकास ने हमें प्रदान किया है; उदाहरण के लिए, C ++ 11 से शुरू होकर, हम पाने में कामयाब रहे:

• type traits का महत्वपूर्ण विस्तार;
• सी विरासत का मुकाबला करने के लिए nullptr और scoped enum जैसे नवाचार - कमजोर टाइपिंग;
• जीएसएल और सहायक उपकरण;
• C ++ 20 में अवधारणाएं ।

आप में से कुछ टेम्पलेट मेटाप्रोग्रामिंग पसंद नहीं कर सकते हैं; अन्य कोडिंग शैली को पसंद नहीं कर सकते हैं जो लगभग सार्वभौमिक रूप से auto का उपयोग करता है। इन प्राथमिकताओं के बावजूद, C ++ में सूचीबद्ध शैलियों का उपयोग करने का मुख्य उद्देश्य यहां स्पष्ट रूप से पता लगाया गया है - यह संकलक की मदद करने की इच्छा है ताकि यह बदले में, हमारी मदद कर सके, उसी समय का उपयोग करके जो यह सबसे अच्छा जानता है: प्रकार प्रणाली।

अगर हम गेम प्रोग्रामिंग के बारे में बात करते हैं, तो यहां मजबूत टाइपिंग अनुसंधान के लिए एक विस्तृत क्षेत्र है, और यह सक्रिय रूप से मेरे लिए परिचित गेम प्रोग्रामर द्वारा उपयोग किया जाता है, जो अभ्यास में C ++ का उपयोग करके अपने कौशल में सुधार करने में रुचि रखते हैं। दो महत्वपूर्ण बातें यहाँ चिंता का विषय हैं: संकलन समय पर प्रभाव, और कोड पठनीयता पर प्रभाव।

सच कहूँ तो, आप आसानी से संकलन के समय को अनदेखा कर सकते हैं - लेकिन केवल इस शर्त पर कि आप एक बहुत बड़ी कंपनी में प्रोग्रामर हैं जो गेम नहीं खेलता है और किसी भी कोड को संकलित करने के लिए एक स्थापित आंतरिक अवसंरचना और अंतहीन कंप्यूटिंग शक्ति है जो आप लिख सकते हैं । इतनी बड़ी कंपनियां संकलन की लागत के बारे में चिंतित हैं - इसलिए वे मॉड्यूल का उपयोग करते हैं - लेकिन, एक नियम के रूप में, यह व्यक्तिगत डेवलपर्स के लिए दर्द का कारण नहीं बनता है। उसी समय, अधिकांश गेम प्रोग्रामर के लिए यह मामला नहीं है। इंडी डेवलपर्स के पास निर्माण के लिए खेत नहीं हैं; AAA गेम डेवलपर्स अक्सर Incredibuild जैसी किसी चीज़ का उपयोग करते हैं, लेकिन इस तथ्य को देखते हुए कि वे आसानी से एक कोडबेस के साथ काम कर सकते हैं जो 10 साल या उससे अधिक पुराना है, निर्माण की प्रक्रिया में अभी भी 15-20 मिनट लग सकते हैं।

हम हार्डवेयर को प्रोग्रामर के समय की लागत के सापेक्ष लागत के बारे में तर्क दे सकते हैं, और मैं इस दृष्टिकोण से सहमत हूं कि हार्डवेयर सस्ता है, हालांकि:

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

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

अवसर नंबर 2: उपकरण

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

मेरा अनुभव है कि गेम डेवलपर जहाँ भी संभव हो इन उपकरणों का उपयोग करते हैं, लेकिन यहाँ उद्योग के रूप में कई समस्याएं हैं:

• ये उपकरण गैर-Microsoft प्लेटफार्मों पर बेहतर काम करते हैं - और, जैसा कि पहले उल्लेख किया गया है, यह एक सामान्य गेम डेवलपमेंट परिदृश्य नहीं है।
• इनमें से अधिकांश उपकरण "मानक" C ++ के साथ काम करने के उद्देश्य से हैं। वे बॉक्स समर्थन std::vector , लेकिन एक काल्पनिक इंजन से मेरे स्व-लिखित वर्ग CStaticVector नहीं। बेशक, उपकरण को दोष देना बेकार है, लेकिन यह अभी भी उनके उपयोग में आने वाली बाधाओं में से एक है जिसे डेवलपर्स को दूर करना होगा।
• एक सीआई श्रृंखला बनाने और बनाए रखने के लिए जो इन सभी उपकरणों को चलाएगा, रिलीज इंजीनियरों की उपस्थिति की आवश्यकता है - और, जैसा कि पहले उल्लेख किया गया है, इंजीनियरिंग नौकरियों के लिए लोगों को काम पर रखना जो सीधे गेम से संबंधित नहीं हैं गेमिंग उद्योग के लिए एक प्रणालीगत समस्या है।

इसलिए, चूंकि ये उपकरण मानक C ++ के साथ इतनी अच्छी तरह से काम करते हैं, तो फिर गेम डेवलपर्स STL का उपयोग क्यों नहीं करते हैं?

इस प्रश्न का उत्तर कहाँ से शुरू करें? शायद, खेल के विकास के इतिहास में अगले भ्रमण से:

• 90 के दशक की शुरुआत तक, हमें सी कंपाइलरों पर भरोसा नहीं था, इसलिए हमने असेंबलर में गेम लिखा।
• शुरुआत से लेकर 90 के दशक के मध्य तक, हमने सी कंपाइलरों पर भरोसा करना शुरू किया, लेकिन हमें अभी भी सी ++ कंपाइलर्स पर भरोसा नहीं था। हमारा कोड C था, जिसमें C ++ शैली टिप्पणियों का उपयोग किया गया था, और हमें अब हर समय अपनी संरचनाओं के लिए लिखने की आवश्यकता नहीं थी।
• 2000 के आसपास, गेमिंग विकास की दुनिया में C ++ क्रांति हुई। यह डिजाइन पैटर्न और बड़े वर्ग के पदानुक्रम का युग था। उस समय, कंसोल पर एसटीएल समर्थन वांछित होने के लिए बहुत कुछ बचा था, और कंसोल ने तब दुनिया पर शासन किया। PS2 पर, हम हमेशा के लिए GCC 2.95 के साथ फंस गए हैं।
• 2010 के आसपास, दो और क्रांतियों का शुभारंभ किया गया। बड़े वर्ग के पदानुक्रम का उपयोग करने के दर्द ने कोड के लिए एक घटक दृष्टिकोण के विकास को प्रेरित किया। यह परिवर्तन आज इकाई-घटक-प्रणाली आर्किटेक्चर के रूप में अपने विकास को जारी रखता है। इसके साथ हाथ में दूसरी क्रांति थी - मल्टीप्रोसेसर आर्किटेक्चर का लाभ उठाने का प्रयास।

इन प्रतिमान बदलावों के दौरान, गेम डेवलपमेंट प्लेटफ़ॉर्म स्वयं लगातार बदल रहे थे, और वे गंभीरता से बदल रहे थे। खंडित मेमोरी ने एक फ्लैट एड्रेस स्पेस का रास्ता दिया है। प्लेटफ़ॉर्म मल्टीप्रोसेसर, सममित और बहुत नहीं बन गए हैं। गेम डेवलपर्स, जो इंटेल आर्किटेक्चर के साथ काम करने के आदी हैं, उन्हें MIPS (Playstation), फिर विषम सीपीयू (PS2) के साथ एक विशेष हार्डवेयर, उसके बाद PowerPC (XBox 360), फिर उससे भी अधिक विषमता (PS3) का उपयोग करना पड़ा ... प्रत्येक नया प्लेटफॉर्म प्रोसेसर, मेमोरी और ड्राइव के लिए नए प्रदर्शन सुविधाओं के साथ आया है। यदि आप इष्टतम प्रदर्शन प्राप्त करना चाहते हैं, तो आपको अपने पुराने कोड को फिर से लिखने के लिए मजबूर किया गया था, और कई और अक्सर। मैं यह भी उल्लेख नहीं करूंगा कि इंटरनेट की लोकप्रियता के उद्भव और विकास के साथ खेल कितना प्रभावित थे, साथ ही साथ प्लेटफॉर्म धारकों द्वारा डेवलपर्स पर लगाए गए प्रतिबंध भी।

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

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

इसके अलावा, C ++ गेम्स उद्योग में "यहां आविष्कार नहीं किया गया" सिंड्रोम वाले रोगियों का एक समृद्ध इतिहास है। इस उद्योग से उम्मीद की जानी चाहिए, जो एकल उत्साही लोगों के साथ शुरू हुआ जिन्होंने पूरी तरह से नए उपकरणों के साथ अपनी चीजें बनाईं और उनके पास कोई अन्य विकल्प नहीं था। गेमिंग उद्योग, अन्य बातों के अलावा, केवल वही है जहाँ प्रोग्रामर क्रेडिट में बिना किसी विशेष क्रम में इंगित किए जाते हैं। विभिन्न प्रकार की चीजें लिखना मजेदार है, और यह आपके करियर में मदद करता है! रेडी-मेड खरीदने की तुलना में अपना खुद का कुछ बनाना बेहतर है! और चूंकि हम प्रदर्शन के बारे में बहुत चिंतित हैं, इसलिए हम अपने समाधान को इस तरह से अनुकूलित कर सकते हैं कि यह विशेष रूप से हमारी परियोजना के लिए उपयुक्त है - सामान्यीकृत समाधान लेने के बजाय जो कि उपलब्ध संसाधनों को ध्यानपूर्वक बर्बाद कर रहा है। बूस्ट से दुश्मनी इस बात का मुख्य उदाहरण है कि इस तरह की सोच खेल के विकास में कैसे प्रकट होती है। मैंने उन परियोजनाओं पर काम किया जो निम्नलिखित तरीके से हुईं:

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

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

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

यह std::map एक बेहतर विकल्प खोजने के लिए बुद्धिमान है , या std::vector में छोटे बफर ऑप्टिमाइज़ेशन को लागू std::vector । यह algorithms या type traits अपने स्वयं के कार्यान्वयन का समर्थन करने के लिए बर्बाद होने के लिए बहुत कम स्वीकार्य type traits , जो थोड़ा अच्छा करेगा। मेरे लिए, यह अफसोस की बात है कि अधिकांश डेवलपर्स के लिए, एसटीएल सिर्फ कंटेनर हैं। शुरुआत में एसटीएल सीखने के बाद से, उन्हें एसटीएल की बात करते हुए, बस सिखाया जाता है, सबसे स्पष्ट रूप से std::vector - हालांकि वास्तव में उन्हें std::find_if बारे में सोचना चाहिए std::find_if ।

अवसर संख्या 3: टेस्ट

यह तर्क दिया जाता है कि व्यापक परीक्षण किया जाना चाहिए, टीडीडी और / या बीडीडी को कवर किए जाने वाले सभी कोड को कवर करना चाहिए, और नए परीक्षणों को लिखकर बग को संबोधित किया जाना चाहिए।

इसलिए, आइए परीक्षण के विषय पर चर्चा करें।

मेरे अनुभव से देखते हुए, गेमिंग उद्योग में स्वचालित परीक्षण का व्यावहारिक रूप से उपयोग नहीं किया जाता है। क्यों?

1. क्योंकि शुद्धता इतनी महत्वपूर्ण नहीं है , लेकिन कोई वास्तविक विनिर्देश नहीं है

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

2. क्योंकि यह कठिन है

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

3. क्योंकि सामग्री शामिल है

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

4. क्योंकि हम इसका अभ्यास नहीं करते हैं

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

5. चूंकि [कंपनी] स्वचालित परीक्षण की आवश्यकता को नहीं देखती है

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

6. क्योंकि सामान्य तौर पर, खेलों में परीक्षण को दूसरे दर्जे की गतिविधि के रूप में वर्गीकृत किया जाता है

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

मुझे यह सुनिश्चित करने के लिए लगभग हमेशा संघर्ष करना पड़ा कि वे मेरी टीम में बने रहें।

AAA-, , QA — , . , . , .

, , , . «» , , QA , , , .

. , . QA-, , API , « ». , , .

. , , , — .

. . , , « .» « Y.». QA- — , , .

, , ; , — , , — QA , , , , QA .

, , , QA-, . . . , , .

— , API , , ( ) — , .

, , C++.

, . , , , , , . , - , , .

, , , , . , , — , . , ( data breakpoints ) , , — , , ? , , , , , , , , , ( soak testing )?

. , . , ; ; ; ; ; , ; , , .

, «», . , , , — . , — , . - , .

« ++» , . ; , ; , . « C++» , — , , STL _ _, STL . , STL « », ; , , , .

, , « C++» — , . — , .

, C++ , . , . , . copy elision ( ) , . . , , NRVO , , . , C++ .

: ++

, C++, .

1.

, C++, , . , . , , — .

, . C++98, , - , .

, , , . , C++-, «» C++. — , C C++98. , , , – , . ?

2.

, GDC, CppCon , , . ; ; . , , — , .

C++ . , SG14, SG7, SG15 — , — isocpp.org . — , , 200 ? «» «» .

, , , , Twitter Reddit. , — .