क्या सरल खेल के लिए गेम लूप अनिवार्य है?


10

मैं खेल विकास के लिए नया हूं। सीखने के लिए मैं Android प्लेटफॉर्म पर इस गेम को फिर से बना रहा हूं । आप उपरोक्त लिंक पर गेम-प्ले वीडियो देख सकते हैं। यह एक सरल खेल है।

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



यकीन नहीं होता कि यह एक डुप्लिकेट है, क्योंकि यह एंड्रॉइड के बारे में है। जावा-आधारित प्लेटफॉर्म में थ्रेडिंग के बारे में कुछ अन्य विचार हैं जो उस प्रश्न से अलग हैं।
सीन मिडिलिचच

जवाबों:


8

एक गेम लूप की सिफारिश आमतौर पर की जाती है क्योंकि यह सरल है । लगभग किसी भी खेल को एक लूप का उपयोग करके ठीक से विकसित और चलाया जा सकता है, और अधिकांश खेलों में एक को ठीक से काम करने की आवश्यकता होती है।

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

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

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


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

तो आप यह नहीं पूछ रहे हैं कि क्या एक लूप की आवश्यकता है? आपकी मुख्य चिंता यह है कि क्या इसे अलग धागे पर होना चाहिए, सही?
AturSams

1
सही बात। मेरा प्रश्न थ्रेड के बारे में है लूप नहीं है। इस तरह के सरल खेल के लिए (हालांकि मैं इस तरह के खेल को बनाने में सक्षम होने के लिए भाग्यशाली रहूंगा) क्या मुझे एक नया धागा स्पॉन करने की आवश्यकता है या मुख्य धागे पर सब कुछ किया जा सकता है?
जिन

1
नहीं यह जरूरी नहीं है। जब तक आपके पास एक लूप है , तब तक दूसरा लूप बनाने की कोई आवश्यकता नहीं है ।

@ आपको वास्तव में शीर्षक बदलना चाहिए और फिर आप अपना प्रश्न कैसे लिखेंगे।
vallentin

5

नहीं , एक अलग धागे की आवश्यकता नहीं है। यदि आप कुछ भी तीव्र नहीं कर रहे हैं (जो कि आपके द्वारा दिखाए गए गेम में ऐसा नहीं है), तो सब कुछ मुख्य धागे पर किया जा सकता है।

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


मूल प्रश्न "क्या एक पाश आवश्यक है" का उत्तर देना।

नहीं , लेकिन विकल्प अधिक जटिल हैं, लागू करने के लिए कठिन और शायद ही कभी उपयोग किया जाता है।

गेम्स इंटरएक्टिव इंटरएक्टिव हैं। न्यूनतम पर, वह इनपुट पर प्रतीक्षा कर रहा है और आउटपुट अपडेट कर रहा है। ऐसा करने का सबसे सरल तरीका एक लूप है। इसके लिए एक नए सूत्र की आवश्यकता नहीं है।

भले ही आपने जिस गेम का उल्लेख किया है वह सरल प्रतीत होता है, इसमें इंटरेक्टिव विजुअल्स और साउंड्स हैं और यह लगातार उपयोगकर्ता आधारित इनपुट को अपडेट करता है।

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


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

2

वास्तविक प्रश्न का उत्तर (क्या एक गेम लूप को एक अलग धागे में होना चाहिए):

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

अलग थ्रेड्स में कोड रखने का एक अन्य कारण कोड मॉड्यूलर और सरल रखना है। एक साथ मिश्रित कोड के दो असंबंधित टुकड़े होने से अक्सर कोड कम पठनीय हो सकता है और लंबे समय में बनाए रखा जा सकता है।

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

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

कुछ फ्रेमवर्क आपको ActionScript3.0 जैसी आधारित प्रणाली का उपयोग करने और ईवेंट / बाधित करने के लिए प्रोत्साहित / प्रोत्साहित करते हैं। उन मामलों में लूप कोड सामान्य रूप से OnEnterFrameघटना या कुछ समान होगा जो 20 - 60 या 120 बार प्रति सेकंड होता है।


मूल प्रश्न का उत्तर दें (क्या मुझे मुख्य लूप चाहिए):

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

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

तो अपने पिछले प्रश्न का उत्तर देने के लिए, क्या आपको एक लूप की आवश्यकता है? हाँ आप कीजिए।


1
जहाँ तक मुझे पता है, AS3 की तरह, घटना आधारित रूपरेखाएँ, अभी भी एक गेम लूप चल रहा है। मैं निचले स्तर के व्यवधान के बारे में बात कर रहा हूं, न कि एक फ्रेमवर्क जो एक ईवेंट सिस्टम को लागू करता है।
MichaelHouse

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

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

मैं @ बाइट 56 के साथ सहमत हूं, यह एक लूप में उबलता है, जब तक कि हम कर्नेल स्तर की घटनाओं के बारे में बात नहीं कर रहे हैं जो आईओ इंटरप्ट का उपयोग करते हैं।
15 दिसंबर को अवधारणा

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

0

बस कुछ अन्य लोगों के उत्तरों को यहां जोड़ने के लिए, ऐसा कुछ जिसे किसी ने स्पष्ट रूप से उल्लेख नहीं किया है: यदि आप अपने गेम लूप को दूसरे थ्रेड में चलाने का जोखिम उठाते हैं और यह अनुत्तरदायी हो जाता है, तो आप ओएस को अपने आवेदन को समाप्त करने का जोखिम उठाते हैं। इसलिए एक अलग धागे का उपयोग करने की सिफारिश की जाती है। इसलिए (उदाहरण के लिए) NDK काnative_app_glue.c / .hआपके लूप के लिए एक अलग थ्रेड बनाता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.