नेटवर्क कोड की आयु सीमाएं: 1,500 तीरंदाज प्रति 28.8 kbps मॉडेम

अनुवादक का ध्यान दें: यह लेख पहले से ही 17 साल पुराना है, और यह केवल एक ऐतिहासिक दृष्टिकोण से दिलचस्प है। यह सीखना दिलचस्प है कि डेवलपर्स ने 28.8k मॉडेम और पहले पेंटियम के युग में एक चिकनी ऑनलाइन गेम कैसे हासिल किया।

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

मल्टीप्लेयर एज ऑफ़ एम्पायर: स्ट्रक्चर रिक्वायरमेंट्स

1996 में मल्टीप्लेयर कोड एज ऑफ एम्पायर्स पर काम की शुरुआत में, हमने आवश्यक गेमप्ले के कार्यान्वयन के लिए खुद को बहुत विशिष्ट लक्ष्य निर्धारित किए।

• कई अलग-अलग सैन्य इकाइयों के साथ बड़े पैमाने पर और महाकाव्य ऐतिहासिक लड़ाई
• मल्टीप्लेयर मोड में 8 खिलाड़ियों तक का समर्थन
• इंटरनेट पर सीधे मॉडेम कनेक्शन और इंटरनेट के माध्यम से लैन पर चिकनी गेमप्ले सिमुलेशन
• लक्ष्य प्लेटफ़ॉर्म समर्थन: पेंटियम 90 16 एमबी रैम और 28.8 केबीपीएस मॉडेम के साथ
• संचार प्रणाली को मौजूदा इंजन (जिन्न) के साथ काम करना चाहिए
• न्यूनतम कॉन्फ़िगरेशन वाली मशीनों पर प्रति सेकंड 15 फ्रेम स्थिर

जिनी इंजन पहले से ही तैयार था, और सिंगल-यूज़र मोड में गेमप्ले ने इसके रूप लेना शुरू कर दिया। जिनी इंजन एक दो-आयामी एकल-थ्रेडेड गेम लूप इंजन है। टाइल से बने दुनिया में स्प्रिट को 256 रंगों में प्रस्तुत किया जाता है। बेतरतीब ढंग से बनाए गए नक्शे हजारों वस्तुओं से भरे हुए हैं: उन पेड़ों से जिन्हें काटकर गज़लें बनाई जा सकती हैं। इंजन कार्यों के प्रदर्शन के लिए समय के अनुमानित टूटने (अनुकूलन के बाद): ग्राफिक्स प्रतिपादन के लिए 30%, एआई के लिए 30% और रास्तों का पता लगाने, सिमुलेशन और आधिकारिक कार्यों के प्रदर्शन के लिए 30%।

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

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

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

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

एक साथ सिमुलेशन

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

प्रारंभ में, इस तरह के एक मुश्किल सिंक्रनाइज़ेशन को लागू करना मुश्किल था, लेकिन परिणामस्वरूप, यह अन्य क्षेत्रों में अप्रत्याशित लाभ लाया।

बुनियादी मॉडल में वृद्धि

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

चूँकि इस दृष्टिकोण के साथ एक साथ सैकड़ों या हजारों वस्तुओं को स्थानांतरित करने की जिम्मेदारी लेनी चाहिए, सिस्टम को 20 से 1000 मिलीसेकेंड के विलंब उतार-चढ़ाव के साथ भी व्यवहार्य रहना चाहिए और फ्रेम प्रसंस्करण के दौरान परिवर्तनों को संसाधित करने का प्रबंधन करना चाहिए।

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

मार्क [टेरानो] ने भविष्य में दो "डेटा एक्सचेंज चाल" के माध्यम से निष्पादित की जाने वाली आदेशों को चिह्नित करने के लिए एक प्रणाली का इस्तेमाल किया ( एओई में डेटा एक्सचेंज चालें स्वयं रेंडरिंग फ्रेम से अलग हो गईं)।

यही है, पाठ्यक्रम 1000 के दौरान दिए गए आदेशों को पाठ्यक्रम 1002 के दौरान निष्पादित किया जाना है (चित्र 1 देखें)। 1001 के पाठ्यक्रम में, 0999 के दौरान दिए गए आदेशों को निष्पादित किया जाता है। इससे हमें प्रसंस्करण के लिए संदेश प्राप्त करने, पुष्टि करने और संदेश तैयार करने की अनुमति मिलती है, जबकि खेल एनिमेशन बनाना और सिमुलेशन करना जारी रखता है।


चित्र 1. दो "डेटा एक्सचेंज चाल" के माध्यम से निष्पादित होने वाले आदेशों का मार्कअप।

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

"गति नियंत्रण"

चित्रा 2. गति नियंत्रण।

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

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

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

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

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


चित्रा 3. विशिष्ट डेटा विनिमय प्रवाह।


चित्रा 4. सामान्य मशीन गति पर इंटरनेट पर उच्च विलंबता डेटा संचरण।


चित्रा 5. सामान्य डेटा हस्तांतरण में देरी के साथ कम मशीन की गति।

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

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

गारंटी वितरण

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

छिपे हुए लाभ

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

छिपी हुई समस्या

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

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

सबक सीखा

एज ऑफ एम्पायर के नेटवर्क पार्ट को विकसित करते समय , हमें कई सबक मिले जो किसी भी गेमिंग मल्टी-यूजर सिस्टम के विकास पर लागू किए जा सकते हैं।

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

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

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

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

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

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

सामान्य तौर पर, निगरानी करने वाले उपयोगकर्ता आपको इसकी अनुमति देंगे:

• गेम की देरी के बारे में उपयोगकर्ता की उम्मीदों का पता लगाएं
• विकास के शुरुआती चरणों में प्रोटोटाइप मल्टीप्लेयर पहलुओं
• ऐसा व्यवहार देखें जो बहु-उपयोगकर्ता मोड की गति के लिए हानिकारक हो।

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

पाठ: एओई में डेटा के आदान-प्रदान की समस्या का एक हिस्सा तब सामने आया जब मार्क ने मैट्रिक्स को बहुत जल्दी घटा दिया, और अंतिम कोड तैयार करने के बाद फिर से संदेश के स्तर (लंबाई और आवृत्ति) की जांच नहीं की। एआई के बीच बेतरतीब दौड़, पथ की गणना के लिए कठिन और खराब संरचित कमांड पैकेज जैसी अप्रत्याशित चीजें भारी प्रदर्शन की समस्या पैदा कर सकती हैं, तब भी जब सिस्टम अन्यथा अच्छी तरह से काम कर रहा हो।

सिस्टम को यह सुनिश्चित करने के लिए परीक्षकों और डेवलपर्स को सूचित करें कि यह सीमा स्थितियों की अधिकता है - प्रोग्रामर और परीक्षक विकास प्रक्रिया में देखेंगे कि कौन से कार्य सिस्टम को लोड करते हैं; यह उनकी घटना के शुरुआती चरणों में समस्याओं को हल करेगा।

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

सामान्य तौर पर, मैट्रिक्स में निम्नलिखित गुण होने चाहिए:

• परीक्षकों के लिए मानव पठनीय और समझने योग्य हो
• अड़चनें, ब्रेक और समस्याओं को इंगित करें
• निष्पादन पर थोड़ा प्रभाव और लगातार लॉन्च किया जा रहा है।

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

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

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

सिमुलेशन अनुप्रयोगों और तनाव परीक्षण सिमुलेटर बनाने के लिए तैयार हो जाओ। अंत में, हमने व्यक्तिगत और महत्वपूर्ण समस्याओं का अध्ययन करने के लिए उपयोग किए जाने वाले तीन अलग-अलग न्यूनतम परीक्षण एप्लिकेशन बनाए: कनेक्शन बाढ़, विरोधियों का चयन करते समय एक साथ कनेक्शन की समस्याएं और गारंटीकृत पैकेज खो गए।

जितनी जल्दी हो सके मोडेम के साथ परीक्षण (और, भाग्य के साथ, मॉडेम सिमुलेटर के साथ); विकास प्रक्रिया के दौरान मॉडेम परीक्षण जारी रखें (चाहे कितना भी दर्दनाक क्यों न हो)। ( — , , , , - ?), dialup-, LAN. , LAN.

Age of Empires 2

Age of Empires 2: The Age of Kings , , The Zone. , DirectPlay , , Age of Empires .

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

() The Zone Age of Empires . Age of Kings , . , , , . . The Zone , . - The Zone.

RTS3:

RTS3 — Ensemble (. .: Age of Mythology) . RTS3 , Age of Empires, .

• Age of Empires 1 2 . , , , .
• 3D: RTS3 — .
• — .
• TCP/IP: — - TCP/IP 56 /.
• — , NAT.

RTS3 , Age of Empires 1 2 — — RTS3 . AOE/AOK DirectPlay, RTS3 , .

, . , , . Genie , — BANG! , .

Age of Kings , , . , , .

RTS3

6. - RTS3.

- . RTS3 - (. 6). -, , , .

. . , (, , -). ( Channels, TimeSync ..) , .

. Genie peer-to-peer, «». RTS3 , .

«» ( 7). . Age 1 2 .


7. «» .

Peer-to-peer:

• «-» «--».
• कोई केंद्रीय कमजोर लिंक नहीं है - यदि क्लाइंट (यहां तक ​​कि मेजबान) सत्र से डिस्कनेक्ट करता है, तो खेल जारी रह सकता है।

पीयर-टू-पीयर नुकसान:

• सिस्टम में अधिक सक्रिय यौगिक (n = 0 से k-1 (n) तक), यानी अधिक संभावित कमजोर लिंक और उच्च संभावित विलंब।
• ऐसी योजना में कुछ NAT विन्यासों का समर्थन करने में असमर्थता।

Net.lib. RTS3 , , , , . , , , , , .


चित्र 8. हमारे नेटवर्क मॉडल में सेवाओं की चार परतें।

RTS3 हमारे BANG इंजन पर आधारित है! एक नई पीढ़ी जो घटक पुस्तकालयों जैसे ध्वनि, प्रतिपादन, और नेटवर्किंग के साथ मॉड्यूलर वास्तुकला का उपयोग करती है। नेटवर्क सबसिस्टम यहाँ एक घटक के रूप में एकीकृत है, लेकिन BANG इंजन से जुड़ा है! (साथ ही विभिन्न इन-हाउस टूल के साथ)। हमारे नेटवर्क मॉडल को चार सेवा परतों में विभाजित किया गया है, जो लगभग पूरी तरह से हैं, लेकिन पूरी तरह से नहीं, खेल में उपयोग किए जाने वाले ओएसआई नेटवर्क मॉडल के समान नहीं हैं (चित्र 8 देखें)।

मोजे स्तर 1

, Socks, API C. . . Socks .

Link, 2

2, Link, . , Link, Listener, NetworkAddress Packet, , (. 9).

• Packet (): — , / ( ) .
• Link (): . , . send receive , , void*.
• Listener (): . .
• Data stream ( ): , , , .
• Net Address ( ): , .
• Ping: . , .
• 
  
  9. Link.

Multiplayer, 3
— , API net.lib. , RTS3 , / — , .

BANG! , . API , , .

• Client (): . () ( ). , .
• Session (): , , , . . host() join(), , , . / , .
• Channel Ordered Channel: . . TimeSync, .
• Shared Data: . , , .
• Time Sync: .

Game Communications, 4

RTS3. , , . , , .

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

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

RTS3 में सिंक्रोनाइज़ेशन चेक मैक्रोज़ के दो सेटों का उपयोग करके किया जाता है:

#define syncRandCode(userinfo)
gSync->addCodeSync(cRandSync, userinfo, __FILE__, __LINE__)


#define syncRandData(userinfo,
v) gSync->addDataSync(cRandSync, v, userinfo, __FILE__, __LINE__)

इन दोनों मैक्रोज़ को स्ट्रिंग पैरामीटर userinfo प्राप्त होता है, जो एक विशिष्ट सिंक्रनाइज़ तत्व का नाम या संकेत है। उदाहरण के लिए, एक सिंक्रनाइज़ेशन कॉल इस तरह दिख सकती है:

syncRandCode("syncing the random seed", seed);

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

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

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

संक्षेप में देना

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