जेएस लड़ाई: मैंने अपना प्रमाण कैसे लिखा ()

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

इस बार विकास को सप्ताह नहीं, बल्कि सप्ताह हुए, लेकिन दिलचस्प चुनौतियों के बिना वैसे भी यह नहीं हो सका। उन डेवलपर्स के लिए भी खेल को सुविधाजनक कैसे बनाएं, जिन्होंने पहले जावास्क्रिप्ट को नहीं छुआ है? किसी गेम को आउटसोर्स करने के सरल तरीकों से खुद को कैसे बचाएं?



नतीजतन, अलेक्जेंडर ने फिर से होल्जस पर एक रिपोर्ट बनाई, और हम (सम्मेलन के आयोजकों) ने फिर से हैबर के लिए एक पाठ संस्करण तैयार किया।


मेरा नाम अलेक्जेंडर कोरोटाएव है, मैं टिंकॉफोव पर काम करता हूं, मैं फ्रंट-एंड में लगा हुआ हूं। इसके अलावा, Spb-frontend समुदाय के हिस्से के रूप में, मैं mitaps को व्यवस्थित करने में मदद करता हूं। मैं ड्रिंककास्ट पॉडकास्ट करता हूं, हम दिलचस्प लोगों को आमंत्रित करते हैं और विभिन्न विषयों पर चर्चा करते हैं।

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

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

इस प्रकार, आप देख सकते हैं कि दो स्क्रिप्ट, दो लॉजिक्स, दो एल्गोरिदम एक दूसरे से कैसे लड़ते हैं। मैं हमेशा से कुछ ऐसा करना चाहता था, और अब आखिरकार इसे लागू कर दिया गया।

कार्रवाई में, यह सब इस तरह दिखता है:


और इस पर काम क्या दिखता है? बहुत सारे काम प्रलेखन में चले गए। जब खिलाड़ी लैपटॉप पर बैठता है, तो वह प्रलेखन देखता है, जिसमें सब कुछ काफी विस्तार से वर्णित है।

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



हमारी कंपनी में हमारा एक बड़ा टूर्नामेंट था, जिसमें वस्तुतः कोई भी प्रोग्रामर जिसमें हमने भाग लिया था।

प्रौद्योगिकी से, मैंने जेएस - फेजर की दुनिया से सबसे लोकप्रिय गेम इंजन का उपयोग किया। सबसे बड़ा और सबसे अधिक इस्तेमाल किया जाने वाला ऐस संपादक। यह वेब पर एक संपादक है, बहुत ही उदात्त या VSCode के समान है, इसे एक वेब पेज में एम्बेड किया जा सकता है। मैंने html को रेंडर करने के लिए RxJS का उपयोग विभिन्न उपयोगकर्ताओं के अतुल्यकालिक इंटरैक्शन और Preact के साथ काम करने के लिए भी किया। देशी प्रौद्योगिकियों में से, उन्होंने विशेष रूप से श्रमिकों और वेबसोकेट के साथ काम किया।

---

प्रोग्रामर के लिए खेल

सामान्य तौर पर प्रोग्रामर के लिए खेल क्या हैं? मेरी राय में, ये ऐसे खेल हैं जहां आपको कोड करने की आवश्यकता है, फिर कुछ मज़ेदार परिणाम प्राप्त करें जिनकी तुलना किसी के साथ की जा सकती है, यह एक लड़ाई है। इन उपलब्ध ऑनलाइन गेमों में, मुझे पता है कि "लिफ्ट सागा" - आप कुछ मापदंडों के अनुसार लिफ्ट के लिए स्क्रिप्ट लिखते हैं। "चिंराट" - जीव विज्ञान, अणुओं के बारे में, उनके लिए स्क्रिप्ट लिखें।

ऐसे खिलौने भी हैं जो कभी-कभी सम्मेलनों में होते हैं। उनमें से सबसे लोकप्रिय "कोड इन द डार्क" है, हमने इसे आज भी प्रस्तुत किया है। वैसे, "कोड इन द डार्क" ने मुझे कुछ मायनों में प्रेरित किया।



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

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



यह पहले संस्करण में कैसे दिखता था। यह खिलाड़ियों के लिए एक मुख्य स्क्रीन और दो लैपटॉप थे। इस सब ने सर्वर से संपर्क किया, सर्वर ने स्टेट को स्टोर किया और सभी कनेक्टेड क्लाइंट के बीच इसे अफवाह बना दिया। प्रत्येक स्क्रीन एक कनेक्टेड क्लाइंट थी। खिलाड़ियों के लैपटॉप इंटरैक्टिव स्क्रीन थे, जिनसे इस राज्य को बदला जा सकता था। स्क्रीन सख्ती से एक सर्वर से जुड़ी हैं।

समय की कहानी का अभाव

इस विकास में मुझे जो पहली कहानी मिली, वह कहानी है कि मेरे पास बहुत कम समय था। वास्तव में पाँच मिनट में एक विचार आया, पाँच सेकंड में एक नाम का आविष्कार किया गया था जब इसे GHHub पर एक रिपॉजिटरी बनाने की आवश्यकता थी। मैं शाम को सिर्फ चार घंटे बिता सकता था, उन्हें अपनी पत्नी से भी दूर ले जा सकता था। नतीजतन, मेरे पास सम्मेलन से पहले केवल तीन सप्ताह का समय बचा था, कम से कम किसी तरह यह महसूस करने के लिए। यह सब इसलिए शुरू हुआ कि एक मंथन के ढांचे के भीतर एक विचार के साथ आना जरूरी था, पांच मिनट में यह विचार पैदा हुआ: "जेएस में आरपीजी के लिए किसी प्रकार की कृत्रिम बुद्धि लिखें"। यह शांत है, मजेदार है, मैं इसे लागू कर सकता हूं।



पहले कार्यान्वयन में, स्क्रीन में एक कोड संपादक और एक लड़ाई स्क्रीन थी, जिस पर लड़ाई ही थी। Phaser, Ace Editor, और शुद्ध Node.js को बिना किसी फ्रेमवर्क के सर्वर के रूप में उपयोग किया गया था। हालांकि बाद में मुझे पछतावा हुआ, लेकिन तब सर्वर से कुछ खास नहीं चाहिए था।



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

सैंडबॉक्स

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



सैंडबॉक्स क्या करना चाहिए?

सबसे पहले, जैसा कि मैंने कहा, कोड को अलग करें। यह एक ऐसी दुनिया होनी चाहिए, जिसमें से कोई बाहर नहीं निकल सकता है।

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



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



आप निश्चित रूप से, सबसे अच्छे तरीके से जा सकते हैं और एसिंक्स / वेट सिंटैक्स ले सकते हैं। [स्लाइड 8:57] लेकिन क्या आप यह भी कल्पना कर सकते हैं कि गैर-जावास्क्रिप्ट प्रोग्रामर कैसे समझा सकते हैं कि आपको लगभग हर लाइन से पहले इंतजार करने की ज़रूरत है? नतीजतन, अतुल्यकालिक के साथ काम करने का सबसे अच्छा तरीका यह है कि इसका उपयोग न करें।



लगभग किसी भी प्रोग्रामिंग लैंग्वेज की तरह ही सबसे सिंक्रोनस कोड और सबसे सिंपल API बनाएं। हम न केवल जेएस में लिखने वाले लोगों के लिए एक खिलौना बनाते हैं, हम इसे उन सभी के लिए सुलभ बनाना चाहते हैं जो कोड करना जानते हैं।



हम सभी को इसे शुरू करने की जरूरत है। उपयोगकर्ता कोड लिखता है, और हमें इसे निष्पादित करने की आवश्यकता है, नक्शे पर इकाइयों को स्थानांतरित करें। पहली बात जो मन में आती है वह यह है कि हमें eval की आवश्यकता है () इसके अलावा कथन के साथ अनुशंसित नहीं है, जो MDN पर उपयोग के लिए अनुशंसित नहीं है । यह काम करेगा, लेकिन समस्याएं हैं।



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

eval () बुराई है

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



लेकिन क्या होगा अगर मैं आपको बताऊं, [स्टीव जॉब्स की आवाज़ में] कि हमने फिर से अविष्कार () किया?

हमने अन्य तकनीकों पर eval () किया, यह लगभग उसी eval () के समान है जो हमारे पास पहले से है। वास्तव में, मेरे पास अपने कोड में एक eval () फ़ंक्शन है, लेकिन वर्कर्स, स्टेटमेंट और प्रॉक्सी के उपयोग से कार्यान्वित किया गया है।



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



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



मुझे URL.createObjectURL () का उपयोग करने का एक तरीका मिला। हम एक ब्लॉक बनाते हैं और इसे src कार्यकर्ता को खिलाते हैं। इस प्रकार, यह हमारे कोड को सीधे लाइन से अनलोड करता है। वैसे, यह तरीका DOM में किसी भी ऑब्जेक्ट के साथ काम करता है जिनके पास src - छवि इस तरह से काम करती है, उदाहरण के लिए, और यहां तक ​​कि एक iframe में आप इसे स्ट्रिंग से उत्पन्न करके html को लोड कर सकते हैं। बहुत अच्छा और लचीला, मुझे लगता है। हम कार्यकर्ता को केवल URL से हमारी विशेष रूप से जेनरेट की गई वस्तु को पास करके भी प्रबंधित कर सकते हैं। हम इसे समाप्त भी कर सकते हैं और यह पहले से ही आवश्यकतानुसार काम करता है, और हमने पहला सैंडबॉक्स बनाया।



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



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



यहाँ सब कुछ बहुत सरल है। हमारा कोड घोषित हो जाता है, अतुल्यकालिकता की जटिलता कहीं जाती है। मुख्य बात यह है कि इन ऑपरेटरों को सीखना है।



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



[स्लाइड १५:२०] समाधान स्वयं बताता है कि यह सब कथन के साथ बहुत निषिद्ध हो सकता है। आइए समझते हैं कि क्यों मना किया जाता है।

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


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



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

वास्तव में, यह कुछ भी अलग नहीं करता है, यह सिर्फ हमारे लिए अमूर्तता की एक नई परत जोड़ता है, एक नया वैश्विक दायरा। लेकिन हम इस व्यवहार को प्रॉक्सी के साथ बदल सकते हैं।



तथ्य यह है कि प्रॉक्सी हमारे सभी कॉल को नए एपीआई के माध्यम से अनुमानित ऑब्जेक्ट पर दिखता है, और हम नियंत्रित कर सकते हैं कि इस ऑब्जेक्ट में नए डेटा अनुरोध कैसे व्यवहार करते हैं।



वास्तव में, काफी सरलता से काम करता है। जब हम उसे किसी प्रकार का चर खिलाते हैं, तो वह हुड के नीचे जांचता है कि क्या यह चर वस्तु में है (यह ऑपरेटर में निष्पादित होता है), और यदि ऐसा है, तो वह इसे ऑब्जेक्ट में निष्पादित करता है, और यदि नहीं, तो यह ऊपरी दायरे में निष्पादित होता है, हमारा मामला वैश्विक है। यह यहाँ बहुत सरल है। मुख्य बात जो प्रॉक्सी हमारी मदद करती है वह यह है कि हम इस व्यवहार को ओवरराइड कर सकते हैं।



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



यदि हम eval () चलाने की कोशिश करते हैं, तो वह पहले पूछेगा कि क्या यह eval () UnitApi में है, वे "हां" का जवाब देंगे और "अपरिभाषित एक फ़ंक्शन नहीं है" प्राप्त करेंगे। यह पहली बार लगता है कि मैं इस त्रुटि से खुश हूं! यह गलती ठीक वैसी ही है जैसी हमें मिलनी चाहिए थी। हमने इसे लिया और उपयोगकर्ता से कहा: "क्षमा करें, विंडो ऑब्जेक्ट के बारे में जो कुछ भी आप जानते थे, उसके बारे में भूल जाओ, यह अब और नहीं है।" हम पहले से ही कुछ समस्याओं को छोड़ चुके हैं, लेकिन यह सब नहीं है।



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



यह हमारे लिए महत्वपूर्ण नहीं है, हमारे लिए यह महत्वपूर्ण है कि उपयोगकर्ता valueOf () को निष्पादित कर सकता है और हमारे सभी सैंडबॉक्स प्राप्त कर सकता है। सीधे ले लो और उठाओ, देखें कि इसमें क्या है। मैं ऐसा नहीं चाहता था, इसलिए एक दिलचस्प बात विनिर्देश में पेश की गई थी: Symbol.unscopables। यही है, प्रतीकों के लिए नए विनिर्देश में, Symbol.unscopables विशेष रूप से कथन के साथ पेश किया गया था, जो निषिद्ध है। क्योंकि उनका मानना ​​है कि कोई और इसका इस्तेमाल कर रहा है। उदाहरण के लिए, मुझे!



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



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



मुझे बस यह सब करना और साफ करना था। हम सभी चाबियों से गुजरते हैं और इसे साफ करते हैं।



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



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

हमें कंसोल और कई अन्य उपयोगितावादी कार्यों की भी आवश्यकता है जो किसी भी विनाशकारी कार्य को नहीं करते हैं। हम अपने एपीआई के लिए एक समय सूची बनाते हैं।यह अच्छा है, क्योंकि यदि हमने एक ब्लैकलिस्ट बनाया, तो हम किसी भी ब्राउज़र अपडेट पर निर्भर होंगे जो हमारे ज्ञान के बिना होता है।



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



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

, , - . , . , webpack .



patchMethod(), , postMessage(). postMessage() console log, error, warn, info. , . , <div>, , , , , .



, . : - - — , , - . , , promises. , actions, .



actions. , real-time ? , real-time workers , worker, . - , . , , . , , . .



workers, . workers , . , . , , ( , ), . : — .

---

Math.random()

, , , . Math.random().

, , , . , Math.random() - .



, , ( ), JS , . .



, , , . , - .

, . , random(), .



, random() — « » , . , - , random() , . - , . , , random() .



. , , random() . - seed ( , , ).


, . , random(). , random() -.

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

---

राज्य साझाकरण: RxJS, सर्वर और क्लाइंट

इसलिए हमें लगा कि ग्राहक के पास क्या है। अब हम राज्य के बंटवारे के बारे में बात करते हैं कि इसकी आवश्यकता क्यों है और यह कैसे आयोजित किया गया था। हमारे पास सर्वर पर संग्रहित स्थिति है, सर्वर को जुड़े हुए ग्राहकों के साथ इसे बंद करना चाहिए। [स्लाइड 28:48]

हमारे पास विभिन्न क्लाइंट्स की चार भूमिकाएं हैं जो सर्वर से जुड़ सकते हैं: "लेफ्ट यूजर", "राइट यूजर", एक दर्शक जो मुख्य स्क्रीन पर दिखता है, और एक प्रशासक जो कुछ भी कर सकता है।

बाईं स्क्रीन सही खिलाड़ी की स्थिति नहीं बदल सकती है, दर्शक कुछ भी नहीं बदल सकता है, और व्यवस्थापक सब कुछ कर सकता है।



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



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



हम फिर से थ्रेड्स के साथ काम कर रहे हैं, सॉकेट से एक धारा है, जिसे सॉकेट कहा जाता है। एक धागा बनाने के लिए जो केवल बाएं खिलाड़ी की निगरानी करता है, हम बस इस सॉकेट से संदेश ले जाते हैं और बाएं खिलाड़ी द्वारा फ़िल्टर करते हैं (और इसी तरह सही वाले के साथ)। फिर हम उन्हें forJJoin () ऑपरेटर का उपयोग करके जोड़ सकते हैं, जो Promise.all () की तरह काम करता है और इसका एनालॉग है। हम इन दोनों क्रियाओं की प्रतीक्षा करते हैं और सेटस्टेट () पद्धति को कहते हैं, जो हमारे राज्य को "तैयार" करती है। यह पता चला है कि हम दोनों खिलाड़ियों की प्रतीक्षा कर रहे हैं और सर्वर की स्थिति बदल रहे हैं। RxJS पर, यह यथासंभव घोषणा के रूप में सामने आता है, यही वजह है कि मैंने इसका इस्तेमाल किया।

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



उनके पास सर्वर के साथ खिलाड़ी के संचार का मूल तर्क होगा, और प्रत्येक विशेष वर्ग में डेटा को फ़िल्टर करने के लिए उसका कस्टम तर्क होगा।

क्लाइंट वास्तव में कनेक्शन, ग्राहकों के साथ कनेक्शन का एक पूल है।



वह बस उन्हें संग्रहीत करता है और उसके पास onUnsafeMessage स्ट्रीम है, जो पूरी तरह से असुरक्षित है: उस पर भरोसा नहीं किया जा सकता है, ये उपयोगकर्ता द्वारा प्राप्त किए गए कच्चे संदेश हैं। हम इन कच्चे संदेशों को स्ट्रीम में लिखते हैं।

इसके अलावा, किसी विशिष्ट खिलाड़ी को लागू करते समय, हम इसे ऑन-ऑन कैफे मेसेज करते हैं और इसे फ़िल्टर करते हैं।



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



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

आरएक्सजेएस का उपयोग क्लाइंट पर भी किया जाता है, यह रिवर्स साइड पर सॉकेट से जुड़ा होता है, घटनाओं का उत्सर्जन करता है और उन्हें हर तरह से पुनर्निर्देशित करता है।

इस मामले में, मैं एक उदाहरण बनाना चाहूंगा जब मुझे सही विरोधी की सेना को बदलने की आवश्यकता होगी।



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

और जब कुछ स्ट्रीम से पहले ही आ चुका होता है, तो हम setState () फ़ंक्शन को कॉल करते हैं। यह काफी सरल है, बहुत ही दृष्टिकोण जो हमें पारदर्शी और घोषित रूप से सब कुछ करने की अनुमति देता है। बहुत सी चीज जिसके लिए मैंने RxJS प्रोजेक्ट लिया और इसमें मुझे बहुत मदद मिली।



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

इतिहास: एकल खिलाड़ी से मल्टीप्लेयर तक

तो, मेरे खिलौने का पहला संस्करण लिखा गया था। हम कह सकते हैं कि यह एक एकल खिलाड़ी था, क्योंकि केवल दो खिलाड़ी ही इसे खेल सकते थे, जुड़े हुए ग्राहकों की संख्या तय थी। हमारे पास एक बाएं खिलाड़ी, एक सही खिलाड़ी और पीछे स्क्रीन, यह सब सीधे सर्वर से जुड़ा था। सब कुछ हार्डकॉकेट किया गया था, फिर भी तीन हफ्तों में यह किया गया था।

मुझे एक नया प्रस्ताव मिला: कंपनी में सभी प्रोग्रामर के लिए खिलौने का विस्तार करने के लिए ताकि वे इसे अपने कंप्यूटर पर खोल सकें और खेल सकें। ताकि हम नेताओं, मल्टीप्लेयर की एक सूची प्राप्त करें ताकि वे एक साथ खेल सकें। तब मुझे महसूस हुआ कि मेरे पास बहुत कुछ है।



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



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

जेएस गामदेव और उनकी समस्याएं

इस प्रकार, मैं JS-gamedev से अधिक गंभीरता से परिचित हो गया। मैंने पिछले प्रोजेक्ट के बारे में तीन साल तक समय-समय पर आराम किया। और यहाँ मैं तीन सप्ताह के लिए दोनों समय था। हर दिन मैं शाम को बैठकर कुछ करता।

जेएस पर विकासशील खेलों में क्या समस्याएं हैं? सब कुछ हमारे व्यावसायिक अनुप्रयोगों से अलग है, जहां यह खरोंच से कुछ लिखने की समस्या नहीं है। इसके अलावा, इसका बहुत स्वागत भी किया जाता है: हम अपनी बात करेंगे, एनपीएम के साथ कहानियों को याद करेंगे और खुद को बाएं-पैड करेंगे।



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



... और मेरे लिए नए जोड़े गए: एक बंडल में 5 मेगाबाइट। और इसके बारे में कुछ भी नहीं किया जा सकता है, वह नहीं जानता कि पेड़ लगाना क्या है। इसके अलावा, फेजर का केवल नवीनतम संस्करण वेबपैक और बंडलों के साथ काम कर सकता है। इससे पहले, फेजर स्क्रिप्ट के html टैग में ही जुड़ा था, यह मेरे लिए अजीब था।

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

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



PixiJS एक बेहतरीन लाइब्रेरी है जो वेबलॉग या फिर कैनवस पर रेंडर कर सकती है। इसके अलावा, आप यहां तक ​​कि कैनवस के लिए भी कोड लिख सकते हैं, और यह WebGL में रेंडर करेगा। यह लाइब्रेरी 2D को बहुत जल्दी प्रस्तुत कर सकती है। मुख्य बात यह जानना है कि यह मेमोरी के साथ कैसे काम करता है, ताकि मेमोरी खत्म होने की स्थिति में न आए।

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

मैं आपको सलाह भी देता हूं कि फेज़र का एक ही प्रसिद्ध एनीमेशन इंजन tween.js लें, जो आपको घोषणात्मक एनिमेशन बनाने की अनुमति देता है जो सीएसएस एनिमेशन के समान हैं: हम राज्यों के बीच एक संक्रमण करते हैं, और tween.js हमारे लिए वास्तव में निर्णय लेते हैं कि ऑब्जेक्ट को कैसे स्थानांतरित किया जाए।

खिलाड़ियों के प्रकार: वे कौन हैं और उनसे दोस्ती कैसे करें

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

जब आपका खिलौना तैयार हो जाता है, तो आप बहुत अच्छी तरह से प्राप्त कर सकते हैं, या पिचफोर्क और टॉर्च के साथ। सभी लोग खेल से किसी तरह के प्रशंसक के लिए इंतजार कर रहे हैं, उस खुशी का इंतजार कर रहे हैं जो आप उन्हें देंगे। और आप उन्हें कुछ ऐसा देते हैं जो बिल्कुल भी काम नहीं करता है, हालांकि यह आपके लिए काम करता है। जब आपके पास एक ऑनलाइन खिलौना होता है, तो ऐसे और भी कीड़े होते हैं।

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

साधारण खिलाड़ी हैं जो पूरी तरह से प्रशंसक के लिए आते हैं। वे कभी-कभी कीड़े को नोटिस भी नहीं कर सकते हैं, किसी तरह से उनके पास खुशी के रास्ते पर फिसल रहे हैं।

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

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

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

इसलिए खेल के विकास में, मैं आपको केवल डेमो करने की सलाह दे सकता हूं: वे सभी को प्रसन्न करते हैं, बहुत समय की आवश्यकता नहीं होती है, और कोई भी वास्तव में डेमो से कुछ भी उम्मीद नहीं करता है। खेलों को समाप्त करना एक उबाऊ प्रक्रिया है, लेकिन शुरुआत करना बहुत अच्छा है।

अंत में, मैं आपको लिंक छोड़ता हूं:

• एक गेम के साथ रिपॉजिटरी और लॉन्च करने के निर्देश (यदि आपको कीड़े मिलते हैं तो मुझे पूल के अनुरोधों पर खुशी होगी)
• Phaser
• भयानक-pixijs
• कोलियस मल्टीप्लेयर गेम सर्वर (मैंने खुद मल्टीप्लेयर लिखा और फिर मैंने कमरों के साथ एक तैयार सर्वर देखा)
• ऐस संपादक
• इस रिपोर्ट की प्रस्तुति
• रूसी-भाषा सम्मेलन जिसमें आप एक रिपोर्ट प्रस्तुत कर सकते हैं

पवित्र डेवलपर्स के लिए एक सम्मेलन पवित्रजेएस 2019 पाइटर , 24-25 मई को सेंट पीटर्सबर्ग में आयोजित किया जाएगा। पहले स्पीकर पहले ही साइट पर दिखाई दे चुके हैं।
आप एक रिपोर्ट के लिए भी आवेदन कर सकते हैं, कॉल फॉर पेपर्स 11 मार्च तक खुला है।
टिकट की कीमतें 1 फरवरी को बढ़ेंगी।