क्विकपॉन्ग - ट्विस्टेड फ्रेमवर्क पर आधारित नेटवर्क गेम का विकास

Quickpong.com डोमेन पर विकसित और लॉन्च किया गया खेल पोंग का एक ऑनलाइन संस्करण है। गेम में (डिज़ाइन द्वारा), केवल मल्टीप्लेयर मोड को लागू किया जाता है, अर्थात, गेम कृत्रिम बुद्धिमत्ता के खिलाफ नहीं है, बल्कि किसी अन्य व्यक्ति के खिलाफ है।

गेम एक क्लाइंट-सर्वर एप्लिकेशन है, सर्वर हिस्सा ट्विस्टेड पायथन फ्रेमवर्क में लिखा गया है, और क्लाइंट हिस्सा फ्लैशपंक फ्लैश फ्रेमवर्क में लिखा गया है।

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

गेमप्ले के बारे में दो शब्द

खेल के मैदान पर, बाएं और दाएं 2 बोर्ड हैं जो लंबवत रूप से आगे बढ़ सकते हैं। प्रत्येक बोर्ड एक व्यक्ति द्वारा नियंत्रित किया जाता है। बोर्डों के बीच, एक गेंद चलती है, खेल के मैदान और बोर्डों की दीवारों से उछलती है। खिलाड़ी का कार्य गेंद को उस दीवार के बाहर गिरने से रोकना है जिसके पास उसका बोर्ड स्थित है।

प्रयुक्त तकनीकों का चयन

नई प्रौद्योगिकियों और उपकरणों में महारत हासिल करते समय, सक्षम विस्तृत प्रलेखन की उपलब्धता एक बड़ी भूमिका निभाती है। जब एक सर्वर फ्रेमवर्क चुनते हैं, तो मैंने पायथन के ट्विस्टेड, टॉर्नेडो और Node.js. को देखा।

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

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

क्लाइंट-सर्वर इंटरैक्शन एल्गोरिदम

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

इस तरह के अनुप्रयोगों में मुख्य कठिनाई क्लाइंट का सिंक्रनाइज़ेशन है; एक ग्राहक को एक समय में एक तस्वीर देखने की अनुमति नहीं दे सकता है, और दूसरा ग्राहक दूसरे को देखने के लिए।

इसके अलावा, मैं ग्राहकों की ओर से धोखाधड़ी से बचना चाहूंगा: यदि वांछित और कौशल है, तो ग्राहक swf को संशोधित किया जा सकता है और सर्वर को धोखा डेटा भेज सकता है।

इस प्रकार, एल्गोरिथ्म के पहले संस्करण में, मैंने इस तरह से कार्य करने का निर्णय लिया:

1. प्रत्येक ग्राहक अपने खेल की दुनिया की स्थिति (गेंद की स्थिति, अपने बोर्ड और प्रतिद्वंद्वी के बोर्ड) की गणना करता है,
2. प्रत्येक ग्राहक 20 बार प्रति सेकंड अपने बोर्ड की स्थिति में परिवर्तन और उसके खेल की दुनिया में गेंद (निर्देशांक, सदिश, गति) के मापदंडों के बारे में जानकारी सर्वर तक पहुंचाता है,
3. सर्वर प्रत्येक खिलाड़ी को प्रतिद्वंद्वी के बोर्ड की स्थिति के बारे में जानकारी भेजता है,
4. सर्वर ही खेल की दुनिया की वर्तमान स्थिति की गणना करता है और ग्राहकों (2 बिंदु) से प्राप्त आंकड़ों के साथ इसकी तुलना करता है। यदि क्लाइंट और सर्वर द्वारा गणना की गई अवस्थाओं के बीच कोई desync है, तो सर्वर क्लाइंट को उस स्थिति में जबरन वापस कर देता है जिसे वह सही मानता है।

एल्गोरिथ्म निष्क्रिय हो गया। वह केवल तभी काम कर सकता है जब डेटा एक्सचेंज में सभी 3 प्रतिभागियों का एक ही राज्य होगा। व्यवहार में, 100% मामलों में एक desync था और इसे खेलना असंभव था।

एल्गोरिथ्म के दूसरे संस्करण में, मैंने सर्वर पर खेल की दुनिया की स्थिति की गणना करने से - एक लिंक से छुटकारा पाने का फैसला किया:

1. प्रत्येक क्लाइंट गेंद और बोर्ड के निर्देशांक की गणना करने से पहले और सर्वर पर उसके राज्य के बारे में डेटा प्रसारित करता है:
2. सर्वर ने ग्राहकों की स्थिति की तुलना की और यदि वे अलग-अलग थे, तो जबरन ग्राहकों में से एक को दूसरे की स्थिति में लौटा दिया।

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

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

Googling, मुझे यहाँ ऐसे दिलचस्प लिंक मिले:

• stackoverflow.com/questions/1411745/multiplayer-game-synchronization
• www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php
• www.kirupa.com/forum/showthread.php?297510-Synchronizing-Realtime-Multiplayer-games
• developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

अंतिम लिंक में वर्णित एल्गोरिथ्म मेरे द्वारा इस परियोजना के लिए लिया गया था। इसका सार इस प्रकार है:

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

कार्यान्वयन

मैंने सर्वर और क्लाइंट के स्रोत को Github पर पोस्ट किया है:

• github.com/romka/quickpong ,
• github.com/romka/quickpong_flash_client

यह आरेख: quickpong.com/images/quickpong.png क्लाइंट और सर्वर इंटरैक्शन का तर्क दिखाता है।

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

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

क्विकपॉन्गप्रोटोकॉल क्लास की वस्तु में ग्राहक से / के लिए डेटा प्राप्त करने और संचारित करने के लिए केवल विधियाँ हैं।

क्लाइंट के कार्यान्वयन के साथ, सब कुछ भी सरल है, केवल दिलचस्प बिंदु निम्नलिखित था। FlashPunk का उपयोग करके मैं चित्र ताज़ा दर (FPS) सेट कर सकता हूं, जबकि FlashPunk गारंटी दे सकता है कि यह N फ्रेम प्रति सेकंड आकर्षित करेगा, लेकिन यह गारंटी नहीं दे सकता कि प्रत्येक फ़्रेम 1 / N के दूसरे में खींची जाएगी। यही है, एफपीएस 50 के साथ, आदर्श मामले में, प्रत्येक फ्रेम को 20 एमएस में खींचा जाना चाहिए, वास्तविक मामले में, एक फ्रेम 15 एमएस में और दूसरा 25 एमएस में खींचा जा सकता है। यदि गेंद एक स्थिर गति से चलती है, उदाहरण के लिए 10 पिक्सल प्रति सेकंड, और प्रत्येक डेटा फ़्रेम का प्रतिपादन फ्लैशपंक फ़्रेम के प्रतिपादन के साथ होता है, तो गेंद असमान रूप से, झटका से चलेगी, क्योंकि एक मामले में यह 15 एमएस में 10 पिक्सेल और दूसरे में स्थानांतरित होगा। 25 के लिए।

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

परीक्षण और निगरानी

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

परीक्षण एक आभासी मशीन में आयोजित किया गया था, जिसके तहत 1 Intel® Xeon® CPU E31275 @ 3.40GHz कोर आवंटित किया गया था।

उसी ट्विस्टेड का उपयोग करते हुए, मैंने पोर्ट 10082 पर एक वेब सर्वर को लटका दिया, जो ऑनलाइन उपयोगकर्ताओं की अल्प-पृथक संख्या और सक्रिय गेम की संख्या प्रदर्शित करता है। इस जानकारी के आधार पर, साथ ही साथ पाइथन लाइब्रेरी psutil और rrdtool + py-rrdtool बंडल का उपयोग करते हुए , मैंने ऐसी स्क्रिप्ट्स लिखीं , जो ऑनलाइन उपयोगकर्ताओं और संसाधनों की वर्तमान संख्या के बारे में जानकारी को पचाने योग्य रूप में उपयोग की गई जानकारी दिखाती हैं : quickpong.com/stats.html (चित्र एक बार अपडेट किए जाते हैं) मिनट)।

5,000 (5 हजार) खिलाड़ियों के साथ, कार्यक्रम लगभग 100 एमबी रैम खाता है, सीपीयू को औसतन 30-40% तक लोड करता है।

रोडमैप

ऐसे विचार जो असत्य बने हुए हैं:

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

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

• github.com/romka/quickpong ,
• github.com/romka/quickpong_flash_client