सोशल गेम्स: सर्वर, क्लाइंट और साझा इवेंट बस

शुभ दोपहर
मेरे पास खाली समय था, और मैंने गलत नजरअंदाज किए गए एपीआई वर्तनी पैटर्न के बारे में एक लेख लिखने का फैसला किया। यह उपयुक्त है यदि आप और क्लाइंट और सर्वर में एक जटिल स्थिति है, और इसे सिंक्रनाइज़ करने की आवश्यकता है। मेरी राय में, सामाजिक खेल इस विवरण को पूरी तरह से फिट करते हैं। इस तथ्य के कारण कि मैं अभी तक महारत के स्तर तक नहीं पहुंच पाया हूं, जब मैं कोड के बिना प्रोग्रामिंग के बारे में लेख लिख सकता हूं, तो मैं एक उदाहरण प्रदान करने के लिए जल्दबाजी करता हूं जो इस दृष्टिकोण को प्रदर्शित करता है। आप github पर कोड देख सकते हैं: https://github.com/dbalakov/studio_game ।


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

npm install connect npm install node-uuid 

इसके अलावा, अंतर्निहित सत्रों का उपयोग करने के बजाय, यहां एक स्व-निर्मित बाइक है। डेटाबेस के साथ कोई काम नहीं है, लेकिन इस बारे में ऑनलाइन गेम में mail.ru डेटाबेस से एक अद्भुत लेख है । Allods Online से Skyforge तक , और इस परियोजना में DAO परत में प्रवेश करना आसान और दर्द रहित है।
यह परीक्षणों की पूरी कमी को ध्यान देने योग्य है, लेकिन नोडज में परीक्षण के बारे में एक अलग लेख होगा।

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

समस्या का बयान

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

पहला ध्यान

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

• init विधि जो सत्र को आरंभ करती है और क्लाइंट को गेम सेटिंग्स और अन्य तकनीकी जानकारी लौटाती है
• लॉगिन विधि जो ग्राहक को खिलाड़ी डेटा लौटाती है
• newProject विधि एक नई परियोजना का निर्माण
• sellProject विधि जो वर्तमान परियोजना को बेचती है
• startWork पद्धति परियोजना पर काम शुरू कर रही है
• पूरा काम विधि है कि परियोजना पर काम करता है और अपनी विशेषताओं को बदल रहा है

कॉफी मग और इस एपीआई पर एक सावधानीपूर्वक नज़र डालने के बाद, आप समझ सकते हैं कि यह बेमानी है: init, login और sellProject, newProject - संबंधित विधियाँ: init के बाद, लॉगिन को तुरंत कहा जाता है, और प्रोजेक्ट की बिक्री के बाद, हम तुरंत एक नया शुरू करते हैं - इसलिए हम इन्हें जोड़ सकते हैं तरीकों। उसके बाद, हमारी एपीआई कुछ इस तरह दिखती है:

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

हम सर्वर से कार्यान्वयन की शुरुआत करेंगे और निश्चित रूप से, मॉडल परत से। मुझे जो मिला वह मॉडल फ़ोल्डर में देखा जा सकता है।

दूसरा ध्यान

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

तीसरा ध्यान

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

 player.money += projectCost; 

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

निष्कर्ष

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

PS मेरी बिल्ली को लेख का पहला संस्करण पसंद नहीं आया और उसने पूरी तरह से अपठनीयता का हवाला देते हुए उसे बुरी तरह से हटा दिया। मुझे आशा है कि मैंने त्रुटियों को ध्यान में रखा और लेख स्पष्ट हो गया।