वर्चुअल पेट गेम लूप में आइडल और इंटरैक्टिव स्टेट्स को कैसे अलग करें

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

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

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

वेब गेम के लिए, requestAnimationFrame फिर से पेंट करने से पहले कार्यों को शेड्यूल करता है और एक टाइमस्टैम्प प्रदान करता है जिसका उपयोग आप बीते हुए समय को मापने के लिए कर सकते हैं। ब्राउज़र आमतौर पर छिपे हुए (हिडन) टैब में इन कॉलबैक को रोक देते हैं, इसलिए यह न मान लें कि गेम बैकग्राउंड में होने पर भी वे एक विश्वसनीय वॉल क्लॉक की तरह चलते रहते हैं। Window.requestAnimationFrame(), MDN

रॉ इनपुट को एक छोटे कमांड में बदलें जैसे कि start_play, stop_play, या pet_tap। एक कमांड हैंडलर यह जांचता है कि क्या एक्शन वर्तमान मोड के लिए मान्य है, साझा मॉडल को एक बार अपडेट करता है, और परिणामी प्रेजेंटेशन संकेत उत्सर्जित करता है। इससे बटन कॉलबैक, एनिमेशन कॉलबैक और आइडल रूटीन में एक ही समय पर एक्शन लॉजिक डालने से बचाव होता है।

उदाहरण के लिए, यदि कोई खिलाड़ी उस समय टैप करता है जब पेट पहले से ही खेल रहा हो, तो परिणाम को सोच-समझकर परिभाषित करें: टैप को अनदेखा करें, कोई भिन्न गतिविधि चुनें, या गतिविधि को रोक दें। आइडल चयनकर्ता और टैप हैंडलर दोनों को एक ही अपडेट के दौरान एक नई गतिविधि असाइन करने की अनुमति देने से बचें। इवेंट प्रोपेगेशन वाले इंजनों में, उपयुक्त चरण में गेमप्ले इनपुट को संभालें और UI खपत का ध्यान रखें; गोडोट का Node दस्तावेज़ नोट करता है कि जब GUI नियंत्रणों को प्राथमिकता की आवश्यकता होती है, तो गेमप्ले के लिए अनहैंडल्ड इनपुट आमतौर पर बेहतर विकल्प होता है। Node class, Godot documentation

ऐसे व्यवहार के लिए जो किसी दृश्यमान सत्र के दौरान लगातार आगे बढ़ना चाहिए, बीते हुए सिमुलेशन समय को संचित (एकत्र) करें और इसका अंतराल पूरा होने पर एक आइडल निर्णय को ट्रिगर करें। फ़्रेम न गिनें: फ़्रेम की आवृत्ति बदलती रहती है। गोडोट में, _process(delta) पिछले आइडल फ़्रेम के बाद का समय प्राप्त करता है, जबकि _physics_process(delta) फ़िज़िक्स टिक्स का पालन करता है; दस्तावेज़ यह भी नोट करता है कि कुछ स्थितियों में संचित डेल्टा वास्तविक दुनिया के सेकंड से भिन्न हो सकता है। Node class, Godot documentation

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

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

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

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

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

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

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

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

• Game Loop, Game Programming Patterns
• Window.requestAnimationFrame(), MDN
• Node class, Godot documentation
• FixedUpdate(), Unity documentation
• Input event queue, Unity Input System