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

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

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

लेख को दो भागों में विभाजित किया जाएगा:

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

कटौती के तहत gifs के बहुत सारे मेगाबाइट्स!

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

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

ईसीएस

इंजन के अंदर, हम वस्तुओं के पदानुक्रम वाले दृश्य का वर्णन करने के लिए "दुनिया" शब्द का उपयोग करते हैं।

एंटिटी-कंपोनेंट-सिस्टम टेम्प्लेट ( विकिपीडिया पर विवरण ) के अनुसार संसारे काम करते हैं:

इकाई - दृश्य के अंदर की वस्तु। यह घटकों के एक सेट के लिए एक भंडार है। वस्तुओं को घोंसला बनाया जा सकता है, दुनिया के भीतर एक पदानुक्रम का गठन;
घटक - किसी भी यांत्रिकी के संचालन के लिए आवश्यक डेटा है, और जो वस्तु के व्यवहार को निर्धारित करता है। उदाहरण के लिए, `ट्रांसफॉर्मकंपोनेंट` में ऑब्जेक्ट का परिवर्तन होता है, और` डायनामिकबॉडी कॉमपेंटेंट` में भौतिक सिमुलेशन के लिए डेटा होता है। कुछ घटकों में अतिरिक्त डेटा नहीं हो सकता है, ऑब्जेक्ट में उनकी सरल उपस्थिति इस ऑब्जेक्ट की स्थिति का वर्णन करती है। उदाहरण के लिए, बैटल प्राइम में, `अलाइवकॉमपेंटेंट` और` डेडकंपोनेंट` का उपयोग किया जाता है, जो क्रमशः जीवित और मृत पात्रों को चिह्नित करते हैं;
सिस्टम - समय-समय पर उन फ़ंक्शन का सेट जो अपने कार्य के समाधान का समर्थन करता है। प्रत्येक कॉल के साथ, सिस्टम उन वस्तुओं को संसाधित करता है जो कुछ स्थिति को संतुष्ट करते हैं (आमतौर पर घटकों का एक निश्चित सेट होता है) और, यदि आवश्यक हो, तो उन्हें संशोधित करता है। सभी गेम लॉजिक और अधिकांश इंजन सिस्टम स्तर पर कार्यान्वित किए जाते हैं। उदाहरण के लिए, इंजन के अंदर एक S लॉडसिस्टम ’होता है, जो दुनिया और अन्य डेटा में परिवर्तन के आधार पर किसी वस्तु के लिए LOD (विस्तार के स्तर) सूचकांकों की गणना करने में लगा होता है। इस सूचकांक को 'LodComponent' में समाहित किया गया है और फिर इसका उपयोग अन्य प्रणालियों द्वारा इसके कार्यों के लिए किया जाता है।

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

व्यवहार में, एक नया कार्यात्मक जोड़ना एक नए घटक (या घटकों के सेट) और एक नई प्रणाली (या सिस्टम का सेट) को कम करता है जो इस कार्यात्मक को लागू करता है। अधिकांश मामलों में, इस पैटर्न पर काम करना सुविधाजनक है।

प्रतिबिंब

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

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

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

इंजन के अंदर कई मॉड्यूल अपने स्वयं के प्रयोजनों के लिए प्रतिबिंब का उपयोग करते हैं। कुछ उदाहरण:

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

हम अपने स्वयं के कार्यान्वयन का उपयोग करते हैं, जिसका इंटरफ़ेस अन्य मौजूदा समाधानों (उदाहरण के लिए, github.com/rttrorg/rttr ) से बहुत अलग नहीं है। कैप्चरपॉइंटकम्पोनेंट (जो गेम मोड के लिए कैप्चर पॉइंट का वर्णन करता है) के उदाहरण का उपयोग करते हुए, इस प्रकार के प्रतिबिंब को इस तरह जोड़ता है:

//     class CapturePointComponent final : public Component { //            BZ_VIRTUAL_REFLECTION(Component); public: float points_to_own = 10.0f; String visible_name; // …   }; //   .cpp  BZ_VIRTUAL_REFLECTION_IMPL(CapturePointComponent) { //       ReflectionRegistrar::begin_class<CapturePointComponent>() [M<Serializable>(), M<Scriptable>(), M<DisplayName>("Capture point")] //      .field("points_to_own", &CapturePointComponent::points_to_own) [M<Serializable>(), M<DisplayName>("Points to own")] .field("visible_name", &CapturePointComponent::visible_name) [M<Serializable>(), M<DisplayName>("Name")] // …     }

मैं अभिव्यक्ति के उपयोग से घोषित किए गए प्रकारों, क्षेत्रों और विधियों के मेटाडेटा पर विशेष ध्यान देना चाहूंगा

 M<T>()

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

अवयवों का विवरण और वस्तु के लिए उनका जोड़

प्रत्येक घटक आधार वर्ग `घटक` का एक प्रवर्तक है और यह उन क्षेत्रों को प्रतिबिंबित करने में मदद कर सकता है जो इसका उपयोग करते हैं (यदि आवश्यक हो)।

इस तरह से `अवतारहारकम्पोनेंट` घोषित किया जाता है और खेल के अंदर वर्णित किया जाता है:

 /** Component that indicates avatar hit event. */ class AvatarHitComponent final : public Component { BZ_VIRTUAL_REFLECTION(Component); public: PlayerId source_id = NetConstants::INVALID_PLAYER_ID; PlayerId target_id = NetConstants::INVALID_PLAYER_ID; HitboxType hitbox_type = HitboxType::UNKNOWN; }; BZ_VIRTUAL_REFLECTION_IMPL(AvatarHitComponent) { ReflectionRegistrar::begin_class<AvatarHitComponent>() .ctor_by_pointer() .copy_ctor_by_pointer() .field("source_id", &AvatarHitComponent::source_id)[M<Replicable>()] .field("target_id", &AvatarHitComponent::target_id)[M<Replicable>()] .field("hitbox_type", &AvatarHitComponent::hitbox_type)[M<Replicable>()]; }

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

 Entity hit_entity = world->create_entity(); auto* const avatar_hit_component = hit_entity.add<AvatarHitComponent>(); avatar_hit_component->source_id = source_player_id; avatar_hit_component->target_id = target_player_id; avatar_hit_component->hitbox_type = hitbox_type; //      //      // ...

`AvatarHitComponent` के साथ ऑब्जेक्ट का उपयोग तब अलग-अलग सिस्टम द्वारा किया जाता है: खिलाड़ियों को मारने, आंकड़ों को इकट्ठा करने, खिलाड़ी की उपलब्धियों पर नज़र रखने और इतने पर।

सिस्टम और उनके काम का विवरण

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

उनके क्षेत्रों का वर्णन करने वाले घटकों के समान, प्रत्येक प्रणाली उन तरीकों का वर्णन करती है जिन्हें दुनिया द्वारा किया जाना चाहिए।

उदाहरण के लिए, विस्फोटों के लिए जिम्मेदार विस्फोटक तंत्र घोषित और वर्णित है:

 // System responsible for handling explosive components: // - tracking when they need to be exploded: by timer, trigger zone etc. // - destroying them on explosion and creating separate explosion entity class ExplosiveSystem final : public System { BZ_VIRTUAL_REFLECTION(System); public: ExplosiveSystem(World* world); private: void update(float dt); //    ,     // ... }; BZ_VIRTUAL_REFLECTION_IMPL(ExplosiveSystem) { ReflectionRegistrar::begin_class<ExplosiveSystem>()[M<SystemTags>("battle")] .ctor_by_pointer<World*>() .method("ExplosiveSystem::update", &ExplosiveSystem::update)[M<SystemTask>( TaskGroups::GAMEPLAY_END, ReadAccess::set< TimeSingleComponent, WeaponDescriptorComponent, BallisticComponent, ProjectileComponent, GrenadeComponent>(), WriteAccess::set<ExplosiveComponent>(), InitAccess::set<ExplosiveStatsComponent, LocalExplosionComponent, ServerExplosionComponent, EntityWasteComponent, ReplicationComponent, AbilityIdComponent, WeaponBaseStatsComponent, HitDamageStatsComponent, ClusterGrenadeStatsComponent>(), UpdateType::FIXED, Vector<TaskOrder>{ TaskOrder::before(FastName{ "ballistic_update" }) })]; }

निम्नलिखित डेटा सिस्टम विवरण के अंदर इंगित किया गया है:

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

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

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

 void ExplosiveSystem::update(float dt) { const auto* time_single_component = world->get<TimeSingleComponent>(); // Init new explosives for (Component* component : new_explosives_group->components) { auto* explosive_component = static_cast<ExplosiveComponent*>(component); init_explosive(explosive_component, time_single_component); } new_explosives_group->components.clear(); // Update all explosives for (ExplosiveComponent* explosive_component : explosives_group) { update_explosive(explosive_component, time_single_component, dt); } }

ऊपर दिए गए उदाहरण में समूह (`new_explosives_group` और` विस्फोटक_group`) सहायक कंटेनर हैं जो सिस्टम कार्यान्वयन को सरल बनाते हैं। new_explosives_group नई वस्तुओं के साथ एक कंटेनर है जो इस प्रणाली के लिए आवश्यक है और जिसे कभी संसाधित नहीं किया गया है, और विस्फोटक_समूह उन सभी वस्तुओं के साथ एक कंटेनर है जिसे हर फ्रेम को संसाधित करने की आवश्यकता होती है। इन कंटेनरों को भरने के लिए दुनिया सीधे तौर पर जिम्मेदार है। सिस्टम द्वारा उनकी प्राप्ति इसके निर्माता में होती है:

 ExplosiveSystem::ExplosiveSystem(World* world) : System(world) { // `explosives_group`        `ExplosiveComponent` explosives_group = world->acquire_component_group<ExplosiveComponent>(); // `new_explosives_group`        //  `ExplosiveComponent` -       new_explosives_group = explosive_group->acquire_component_group_on_add(); }

विश्व अद्यतन

दुनिया, प्रकार की एक वस्तु `World`, प्रत्येक फ्रेम कई प्रणालियों में आवश्यक तरीकों को कहता है। किस सिस्टम को कहा जाएगा यह उनके प्रकार पर निर्भर करता है।

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

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

नीचे gif में, दुनिया प्रति सेकंड 5 निश्चित अपडेट की आवृत्ति पर काम करती है। आप डब्ल्यू बटन दबाने और आंदोलन की शुरुआत के बीच देरी, साथ ही बटन को जारी करने और चरित्र की गति को रोकने के बीच देरी को नोटिस कर सकते हैं:

अगले जीआईएफ में, दुनिया प्रति सेकंड 30 निश्चित अपडेट की आवृत्ति पर काम करती है, जो काफी अधिक उत्तरदायी नियंत्रण देती है:

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

सिस्टम निष्पादन आदेश

ईसीएस के साथ काम को जटिल बनाने वाली चीजों में से एक सिस्टम को निष्पादित करने का कार्य है। संदर्भ के लिए, लेखन के समय, खिलाड़ियों के बीच लड़ाई के दौरान बैटल प्राइम क्लाइंट में 251 प्रणाली होती है और उनकी संख्या केवल बढ़ती है।

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

प्रणालियों का निष्पादन क्रम विभिन्न तरीकों से निर्धारित किया जा सकता है, उदाहरण के लिए:

स्पष्ट आदेश
प्रणाली के संख्यात्मक "प्राथमिकता" और बाद में प्राथमिकता से छंटनी का संकेत;
स्वचालित रूप से सिस्टम के बीच निर्भरता का एक ग्राफ बनाएं और उन्हें निष्पादन क्रम में सही स्थानों पर स्थापित करें।

फिलहाल, हम तीसरे विकल्प का उपयोग कर रहे हैं। प्रत्येक प्रणाली इंगित करती है कि यह पढ़ने के लिए किन घटकों का उपयोग करता है, जो लेखन के लिए, और यह किन घटकों को बनाता है। फिर, सिस्टम स्वचालित रूप से आवश्यक क्रम में आपस में व्यवस्थित होते हैं:

सिस्टम रीडिंग कंपोनेंट ए, कंपोनेंट ए के लिए सिस्टम लिखने के बाद आता है;
कंपोनेंट B लिखने या पढ़ने वाली प्रणाली कंपोनेंट B बनाने वाले सिस्टम के बाद आती है;
यदि दोनों सिस्टम घटक C पर लिखते हैं, तो ऑर्डर कोई भी हो सकता है (लेकिन यदि आवश्यक हो तो मैन्युअल रूप से निर्दिष्ट किया जा सकता है)।

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

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

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

संकेत जो लिखने या पढ़ने के लिए सिस्टम द्वारा उपयोग किए जाते हैं, भविष्य में भी समूह प्रणालियों को स्वचालित रूप से "ब्लॉक" में एक दूसरे के साथ समानांतर में निष्पादित करने की अनुमति देगा।

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

सिस्टम और उनके कॉन्फ़िगरेशन के बीच संचार

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

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

एक घटक आधारित दृष्टिकोण कुछ मामलों में असुविधाजनक हो सकता है:

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

इन समस्याओं को हल करने के लिए, हम उस दृष्टिकोण का उपयोग करते हैं, जिसे हमने ओवरवॉच डेवलपमेंट टीम - सिंगल कंपोनेंट्स से उधार लिया था।

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

फिलहाल, परियोजना (इंजन मॉड्यूल + गेम) में लगभग 120 एकल घटक हैं जो विभिन्न उद्देश्यों के लिए उपयोग किए जाते हैं - दुनिया के वैश्विक डेटा को व्यक्तिगत प्रणालियों के कॉन्फ़िगरेशन में संग्रहीत करने से।

"स्वच्छ" दृष्टिकोण

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

कम "कठोर" दृष्टिकोण के पक्ष में निम्नलिखित तर्क को रेखांकित किया जा सकता है:

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

Netkod

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

खेल परियोजना के अंदर सभी कोड तीन भागों में विभाजित हैं:

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

उपयोगकर्ता इनपुट (इनपुट)

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

खिलाड़ी से सभी इनपुट को दो प्रकारों में विभाजित किया जाता है: निम्न-स्तर और उच्च-स्तर:

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

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

तार्किक रूप से संबंधित क्रियाओं को एक साथ वर्गीकृत किया जाता है (प्रकार की वस्तुएं `ActionSet`)। यदि वर्तमान संदर्भ में उनकी आवश्यकता नहीं है तो समूहों को काट दिया जा सकता है - उदाहरण के लिए, बैटल प्राइम में कई समूह हैं, जिनमें से:

चरित्र की गति को नियंत्रित करने के लिए क्रिया,
स्वचालित हथियारों की फायरिंग के लिए कार्रवाई,
अर्ध-स्वचालित हथियारों से गोलीबारी करने की कार्रवाई।

अंतिम दो समूहों में से, केवल एक ही समय में सक्रिय है, चयनित हथियार के प्रकार पर निर्भर करता है - वे इस बात से भिन्न हैं कि FIRE कार्रवाई कैसे उत्पन्न होती है: जबकि बटन दबाया जाता है (स्वचालित हथियारों के लिए) या केवल एक बार बटन दबाए जाने पर (अर्ध-स्वचालित हथियारों के लिए) )।

इसी प्रकार, क्रियाओं के समूह को गेम में एक सिस्टम के भीतर बनाया और कॉन्फ़िगर किया गया है:

 static const Map<FastName, ActionSet> action_sets = { { //     ControlModes::CHARACTER_MOVEMENT, ActionSet { { DigitalBinding{ ActionNames::JUMP, { { InputCode::KB_SPACE, DigitalState::just_pressed() } }, nullopt }, DigitalBinding{ ActionNames::MOVE, { { InputCode::KB_W, DigitalState::pressed() } }, ActionValue{ AnalogState{0.0f, 1.0f, 0.0f} } }, //    ... }, { AnalogBinding{ ActionNames::LOOK, InputCode::MOUSE_RELATIVE_POSITION, AnalogStateType::ABSOLUTE, AnalogStateBasis::LOGICAL, {} } //    ... } } }, { //       ControlModes::AUTOMATIC_FIRE, ActionSet { { // FIRE    ,      DigitalBinding{ ActionNames::FIRE, { { InputCode::MOUSE_LBUTTON, DigitalState::pressed() } }, nullopt }, //       ... } } }, { //       ControlModes::SEMI_AUTOMATIC_FIRE, ActionSet { { // FIRE          DigitalBinding{ ActionNames::FIRE, { { InputCode::MOUSE_LBUTTON, DigitalState::just_pressed() } }, nullopt }, //       ... } } } //   ... };

बैटल प्राइम में 40 क्रियाओं का वर्णन है। उनमें से कुछ का उपयोग केवल डिबगिंग या रिकॉर्डिंग क्लिप के लिए किया जाता है।

प्रतिकृति

प्रतिकृति एक सर्वर से ग्राहकों को डेटा स्थानांतरित करने की प्रक्रिया है। सभी डेटा दुनिया में वस्तुओं के माध्यम से प्रेषित किया जाता है:

उनका निर्माण और विलोपन,
वस्तुओं पर घटकों को बनाना और हटाना,
घटक गुण बदलें।

उपयुक्त घटक का उपयोग करके प्रतिकृति को कॉन्फ़िगर किया गया है। उदाहरण के लिए, इसी तरह खेल खिलाड़ी के हथियारों की प्रतिकृति स्थापित करता है:

 auto* replication_component = weapon_entity.add<ReplicationComponent>(); replication_component->enable_replication<WeaponDescriptorComponent>(Privacy::PUBLIC); replication_component->enable_replication<WeaponBaseStatsComponent>(Privacy::PUBLIC); replication_component->enable_replication<WeaponComponent>(Privacy::PRIVATE); replication_component->enable_replication<BallisticsStatsComponent>(Privacy::PRIVATE); // ...

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

इसके विवरण के भीतर प्रत्येक घटक को इंगित करना चाहिए कि इस घटक के भीतर किन क्षेत्रों को दोहराया जाना चाहिए। उदाहरण के लिए, `WeaponComponent` के अंदर के सभी क्षेत्रों को 'प्रतिगामी' के रूप में चिह्नित किया जाता है:

 BZ_VIRTUAL_REFLECTION_IMPL(WeaponComponent) { ReflectionRegistrar::begin_class<WeaponComponent>() .ctor_by_pointer() .copy_ctor_by_pointer() .field("owner", &WeaponComponent::owner)[M<Replicable>()] .field("fire_mode", &WeaponComponent::fire_mode)[M<Replicable>()] .field("loaded_ammo", &WeaponComponent::loaded_ammo)[M<Replicable>()] .field("ammo", &WeaponComponent::ammo)[M<Replicable>()] .field("shooting_cooldown_end_ms", &WeaponComponent::shooting_cooldown_end_ms)[M<Replicable>()]; }

इस तंत्र का उपयोग करने के लिए बहुत सुविधाजनक है। उदाहरण के लिए, सर्वर सिस्टम के अंदर, जो मारे गए विरोधियों (एक विशेष गेम मोड) में टोकन को "बेदखल" करने के लिए जिम्मेदार है, यह इस तरह के टोकन पर `ReplicationComponent` को जोड़ने और कॉन्फ़िगर करने के लिए पर्याप्त है। यह इस तरह दिखता है:

 for (const Component* component : added_dead_avatars->components) { Entity kill_token_entity = world->create_entity(); //           // ... //   auto* replication_component = kill_token_entity.add<ReplicationComponent>(); replication_component->enable_replication<TransformComponent>(Privacy::PUBLIC); replication_component->enable_replication<KillTokenComponent>(Privacy::PUBLIC); }

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

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

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

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

ग्राहक की भविष्यवाणी

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

ग्राहक भविष्यवाणियां निम्नलिखित नियमों के अनुसार काम करती हैं:

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

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

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

 auto* input_packing_sc = world->get_for_write<InputPackingSingleComponent>(); input_packing_sc->packing_schema = { { ActionNames::MOVE, AnalogStatePrecision{ 8, { -1.f, 1.f }, false } }, { ActionNames::LOOK, AnalogStatePrecision{ 16, { -PI, PI }, false } }, { ActionNames::JUMP, nullopt }, // ..    action' };

काम करने के लिए क्लाइंट भविष्यवाणियों के प्रदर्शन के लिए एक महत्वपूर्ण शर्त इनपुट के लिए समय की आवश्यकता होती है ताकि जिस सर्वर से यह इनपुट संबंधित हो उस समय तक सर्वर को मिल सके। यदि इनपुट वांछित फ्रेम पर सर्वर पर आने का प्रबंधन नहीं करता है (यह उदाहरण के लिए, एक तेज पिंग जंप के साथ हो सकता है), सर्वर पिछले फ्रेम से इस क्लाइंट के इनपुट का उपयोग करने का प्रयास करेगा। यह एक बैकअप मैकेनिज्म है जो क्लाइंट को कुछ स्थितियों में गलतफहमी से छुटकारा दिलाने में मदद कर सकता है। उदाहरण के लिए, यदि कोई ग्राहक केवल एक दिशा में चलता है और उसका इनपुट अपेक्षाकृत लंबे समय तक नहीं बदलता है, तो अंतिम फ्रेम के लिए इनपुट का उपयोग सफल होगा - सर्वर इसे "अनुमानित" करेगा, और क्लाइंट और सर्वर के बीच कोई विसंगति नहीं होगी। ओवरवॉच में एक समान योजना का उपयोग किया जाता है (जीडीसी पर एक व्याख्यान में उल्लेख किया गया था:www.youtube.com/watch?v=W3aieHjyNvw )।

वर्तमान में, बैटल प्राइम क्लाइंट निम्नलिखित वस्तुओं की स्थिति की भविष्यवाणी करता है:

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

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

 // `new_local_avatars`       , //      for (Entity avatar : new_local_avatars) { auto* avatar_prediction_component = avatar.add<PredictionComponent>(); avatar_prediction_component->enable_prediction<TransformComponent>(); avatar_prediction_component->enable_prediction<CharacterControllerComponent>(); avatar_prediction_component->enable_prediction<ShooterPrivateComponent>(); avatar_prediction_component->enable_prediction<ShooterPublicComponent>(); // ...      }

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

विसंगति मानदंड डेटा के प्रकार पर निर्भर करता है। ज्यादातर मामलों में, यह `ऑपरेटर ==` के लिए सिर्फ एक कॉल है, अपवाद फ्लोट पर आधारित डेटा है - उनके लिए वर्तमान में अधिकतम स्वीकार्य त्रुटि निर्धारित है और 0.005 के बराबर है। भविष्य में, प्रत्येक घटक फ़ील्ड के लिए सटीकता को अलग से सेट करने की क्षमता को जोड़ने की इच्छा है।

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

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

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

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

गलतफहमी और नाराजगी

गलतफहमी - सर्वर और क्लाइंट सिमुलेशन के परिणामों के बीच विसंगति। रेजिमुलेशन क्लाइंट द्वारा इस विसंगति को ठीक करने की प्रक्रिया है।

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

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

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

इन बगों को खोजने में कभी-कभी एक सभ्य समय लगता है। उनकी खोज को सरल बनाने के लिए, हमने कई सहायक उपकरण बनाए - जब अनुप्रयोग चल रहा है, आप देख सकते हैं:

जटिल घटक
बदमाशों की संख्या
किस फ़्रेम पर वे हुए,
डायवर्ट किए गए घटकों में सर्वर और क्लाइंट पर क्या डेटा था,
इस फ़्रेम के लिए सर्वर और क्लाइंट पर क्या इनपुट लागू किया गया था।

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

पुनर्जीवन के संचालन का समर्थन करने के लिए, सिस्टम को एक विशिष्ट वर्ग `ResimulatableSystem` से वारिस होना चाहिए। ऐसी स्थिति में जब कोई मिसप्रिंट होता है, तो दुनिया सभी वस्तुओं को अंतिम ज्ञात सर्वर स्थिति में "रोल बैक" करती है, और फिर इस त्रुटि को ठीक करने के लिए आगे आवश्यक संख्या में सिमुलेशन बनाती है - केवल Resimulatable सिस्टम इसमें भाग लेंगे।

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

शूटिंग

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

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

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

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

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

लग मुआवजा

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

निम्नलिखित बिंदुओं को शूटिंग के दौरान अंतराल के लिए क्षतिपूर्ति करना आवश्यक है:

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

यदि हम मान लेते हैं कि खिलाड़ी सिर की ओर भाग रहा है और शॉट बटन दबा रहा है, तो निम्न चित्र प्राप्त होता है:

क्लाइंट पर: फ़्रेम N1 पर शूटर फ़्रेम N0 (N0 <N1) पर स्थित दुश्मन के सिर पर एक गोली चलाता है;
सर्वर पर: फ्रेम एन 1 पर शूटर दुश्मन के सिर पर एक शॉट फायर करता है, फ्रेम एन 1 पर भी स्थित है (सर्वर पर, सभी एक ही समय में हैं)।

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

इस समस्या से छुटकारा पाने के लिए, लैग क्षतिपूर्ति का उपयोग किया जाता है। उनके काम की योजना इस प्रकार है:

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

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

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

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

बैलिस्टिक प्रोजेक्टाइल चलते समय बाटल प्राइम से लैग क्षतिपूर्ति का उपयोग करने के उदाहरण के साथ कोड:

 // `targets_data`    , //   “”    , //    const auto compensated_action = [this](const Vector<LagCompensation::LagCompensationData>& targets_data) { process_projectile(projectile, elapsed_time); }; LagCompensation::invoke( observer, // ,       projectile_component->input_time_ms, // ,      compensated_entities, // ,    compensated_action // ,       );

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

क्षतिपूर्ति के बिना शूटिंग का एक उदाहरण - आपको दुश्मन को लगातार हिट करने के लिए आगे बढ़ने की आवश्यकता है:

और मुआवजे के साथ - आप आराम से दुश्मन पर सीधे निशाना लगा सकते हैं:

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

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

निष्कर्ष

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

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

खेल पहले से ही तुर्की और फिलीपींस में परीक्षण किया जा रहा है।

हमारे पिछले लेख निम्नलिखित लिंक पर पाए जा सकते हैं:

ब्लिट्ज इंजन और बैटल प्राइम: ECS और नेटवर्क कोड