भौतिकी इंजन नेटवर्क परत

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


हम आपको इस विषय पर ब्लॉग देखने की सलाह देते हैं - http://gafferongames.com/game-physics/ । खेलों के संबंध में टीसीपी और यूडीपी की एक उत्कृष्ट तुलना है।

एडोब सिरस

प्रारंभ में, एडोब सिरस को भौतिकी इंजन के लिए नेटवर्क ट्रांसपोर्ट के रूप में चुना गया था, एक अन्य तरीके से RTMFP (रियल टाइम मीडिया फ्लो प्रोटोकॉल)। प्रौद्योगिकी को कम विलंबता, पी 2 पी टोपोलॉजी, सुरक्षा और मापनीयता द्वारा विशेषता प्रोटोकॉल के रूप में तैनात किया गया है और कई उपयोगकर्ताओं की बातचीत के साथ वास्तविक समय के अनुप्रयोगों को विकसित करने के लिए सबसे उपयुक्त है।
नेटवर्क ट्रैफ़िक के मामले में गहन अनुप्रयोग के लिए, P2p समर्थन एक बड़ा प्लस था। ऑनलाइन फाइटिंग गेम के लिए वादा किए गए कम पिंग्स बहुत उपयोगी होंगे।

RTMPF UDP पर एक प्रोटोकॉल है। फ्लैश अनुप्रयोगों के लिए यूडीपी समर्थन लेखन के समय (09/08/2011) पेश नहीं किया गया था। डेटाग्राम सॉकेट क्लास बीटा परीक्षण में है और केवल हवा से उपलब्ध है।

RTMPF को udp के रूप में संदर्भित करना गलत है। विभिन्न ऑपरेटिंग मोड में, RTMFP में UDP के साथ भिन्न समानताएं और अंतर हैं। शीर्ष क्रचा खेलों के लिए DIRECT_CONNECTIONS मोड की पसंद की पुष्टि करता है (
www.flashrealtime.com/building-p2p-multICE-games-at-adobe-max-2010 )। इस मोड में, सिरस गारंटी संदेश प्रदान करता है, अर्थात। छोटे पिंग का लाभ खो जाता है। विभिन्न ऑपरेटिंग मोड और डेटा प्रकारों के लिए प्रोटोकॉल विशेषताओं को एक ही प्रस्तुति के पीडीएफ स्लाइड में पाया जा सकता है। इस लेख में, "पिंग" एक ग्राहक से दूसरे ग्राहक को संदेश देने में लगने वाले समय को संदर्भित करता है। व्यवहार में, यह पिंग छोटे, अक्सर अस्थिर और उच्च लैग से दूर होता है।

भौतिक दुनिया की वस्तुओं का सिंक्रनाइज़ेशन

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

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

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

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

सिंक पैकेज

केवल दिशाओं और गति के अनुसार भौतिकी की स्थिति को सिंक्रनाइज़ करना संभव नहीं होगा। फ्लोटिंग-पॉइंट ऑपरेशंस में त्रुटियों के कारण, ऑब्जेक्ट बहुत तेज़ी से सिंक से बाहर हो जाते हैं (अलग-अलग क्लाइंट्स पर अलग-अलग पॉइंट्स पर एक ही ऑब्जेक्ट)।

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

rival.applyState(targetState); ... void applyState(State targetState) { this.x = targetState.x; this.y = targetState.y; } 

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

 void applyState(State targetState) { this.x = (this.x + targetState.x)*0.5; this.y = (this.y + targetState.y)*0.5; } 

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

 void applyState(State targetState) { targetX = (this.x + targetState.x)*0.5; targetY = (this.y + targetState.y)*0.5; errorX = targetX - this.x; errorY = targetY - this.y; this.applyForce(k*errorX, k*errorY); } 

k सुधार की "कठोरता" है। इस मामले में, सुधारात्मक बल पदों के बेमेल के लिए आनुपातिक हैं, जो वस्तुओं को कुछ वसंत देता है। बल के उपयोग से पहले सामान्यीकरण (errorX, errorY) के साथ एक वैकल्पिक विकल्प असफल परिणाम दिखाते हैं - यह बड़ी विसंगतियों के साथ अच्छी तरह से सामना नहीं करता था।

हालांकि, कभी-कभी कुछ सेकंड के लिए अंतराल होते हैं। ऐसे मामलों में, applyState का नवीनतम कार्यान्वयन बहुत धीमा है और ध्यान देने योग्य उतार-चढ़ाव हो सकता है। हम ऐसे मामलों को अलग-अलग करते हैं, लक्ष्य की स्थिति के लिए मजबूर करते हैं (पदों को प्रक्षेपित किए बिना):

 void applyState(State targetState) { targetX = (this.x + targetState.x)*0.5; targetY = (this.y + targetState.y)*0.5; errorX = targetX - this.x; errorY = targetY - this.y; if(len(errorX,errorY)<MAX_SOFT_CORRECTION_ERROR) { this.applyForce(k*errorX, k*errorY); } else { this.x = (this.x + targetState.x)*0.5; this.y = (this.y + targetState.y)*0.5; } } 

इसके अलावा, वस्तुओं (हमलों, विस्फोटों, दुर्घटना) की बड़ी तेजी के साथ, हम अस्थायी रूप से मजबूर पदों के साथ सुधार पर स्विच करते हैं।

पैकेज वितरण या पैकेजों के संभावित दोहराव के अनुचित आदेश के मामले में, पैकेट भेजने के समय ग्राहक को भेजने के समय पर मुहर लगाना और उसे प्राप्त करने की प्रक्रिया में शामिल करना पर्याप्त है:

 long recentProcessedTimestamp; void onStateReceived(State state) { if(state.timestamp <= recentProcessedTimestamp) { //        return; } else if(currentLocalTimestamp()-state.timestamp > MAX_PERMISSIBLE_DELAY) { //   return; } else { recentProcessedTimestamp = state.timestamp; process(state); } } 

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

गैप का पता लगाने और संचार गुणवत्ता परीक्षण

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

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

टीसीपी / आईपी का उपयोग करना

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

Tcp / ip की समस्याएं गारंटीकृत डिलीवरी में निहित हैं। पैकेट को बार-बार अग्रेषित करने से, यहां तक ​​कि एक देरी से पैकेट सभी काम को बाधित करता है। समस्याग्रस्त पैकेज को संसाधित करते समय, अन्य लोग आते हैं। नतीजतन, पिंग्स कई सेकंड तक बढ़ सकते हैं और एक कनेक्शन ब्रेक होता है। हालांकि, सिरस ब्रेक अधिक बार होता है।

मुख्य खोज

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

आवेदन के लिए लिंक http://vkontakte.ru/app2316895

विकासशील खेलों में शुभकामनाएँ!