अभिनेताओं के रूप में स्प्रिट


12

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

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

कि एक खेल के लिए समझ में आता है? यह इस तरह से किया जा रहा है? आखिरकार, यह जेवीएम पर चलेगा, हालांकि आजकल कोई समस्या नहीं होनी चाहिए।

संपादित करें:

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

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

मुझे जो दूसरा फायदा दिख रहा है, वह यह है कि स्काला में, आपके पास RemoteActorsएक ही तरह से इलाज किया जा सकता है, लेकिन दूसरे कंप्यूटर पर चलाया जा सकता है। तो शायद यह नेटवर्क गेमिंग को भी सरल बना सकता है।

मैं जल्द से जल्द अपने स्काला 2 डी इंजन में निर्माण करना चाहता हूं।


मुझे यह जानने में बहुत दिलचस्पी होगी कि यह कैसे होता है। मैंने स्काला को एक दो बार देखा है, लेकिन पहले कभी इसमें कुछ नहीं किया।
डेवि

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

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

जवाबों:


7

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

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

मुझे लगता है कि आप यहाँ क्या जरूरत है एक बहुत हल्के मल्टीटास्किंग के कुछ प्रकार है, और कोई संदेश बिल्कुल नहीं गुजर रहा है। अपने खुद के अभिनेता की तरह कार्यान्वयन में रोल करना, जो निष्पक्षता सुनिश्चित करता है कि अगर आप यह सुनिश्चित करना चाहते हैं तो यह सबसे अच्छा तरीका है, लेकिन यह बहुत कम लाभ के लिए बहुत अधिक काम है। देखने के लिए एक और चीज कार्यात्मक प्रतिक्रियाशील प्रोग्रामिंग है और scala.react, मेरा मानना ​​है कि इस उपयोग के मामले के लिए एक बेहतर मैच है।

मैंने Scala में 2d isometric गेम इंजन लागू किया है। मैंने केवल दिखाई देने वाले स्प्राइट्स को अपडेट करने के लिए 1 वैश्विक अभिनेता का उपयोग किया है जो एनिमेटेड थे।

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

फिर भी, अगर मैं आप थे, तो मैं कोशिश करूँगा, बस यह देखने के लिए कि क्या होता है।


1

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

क्या घटना होगी जो उन्हें ले जाती है?

क्या यह एक ऐसी घटना होगी जो आप प्रति फ्रेम एक बार उत्सर्जित करते हैं?

और यदि हां, तो इस प्रणाली को किसी भी व्यावहारिक तरीके से कैसे बदल दिया गया है?

मूल रूप से C ++ के संदर्भ में ऑब्जेक्ट-ओरिएंटेशन का अध्ययन करते समय, मुझे पता चला कि कुछ लोगों को एक कथन के बारे में सोचना पसंद था, जैसे xyz.doThis(x)कि अर्थ 'doThis संदेश को xyz (x के पेलोड के साथ) भेजें और तत्काल प्रतिक्रिया का इंतजार करें'। जब इस स्तर पर देखा जाता है, तो एक घटना या संदेश आधारित प्रणाली और एक सामान्य प्रक्रियात्मक के बीच कोई आंतरिक अंतर नहीं होता है।


अभिनेता एक बहु-सूत्रीय समाधान हैं। संचार समकालिक नहीं हैं। स्काला एक्टर्स (एरलैंग से अवधारणा) आसान मल्टी कोर प्रोग्राम की अनुमति देते हैं।
एलिस

आपके पास वहां एक बिंदु है, लेकिन यहां अंतर यह होगा कि अभिनेता-आधारित स्प्राइट कार्रवाई करते समय गेम लूप को ब्लॉक नहीं करता है, जबकि विधि-दृष्टिकोण इंतजार करता xyz.doThis(x)है। मुझे लगता है कि इससे गेम लॉजिक को तेज करने में मदद मिल सकती है, खासकर मल्टी-कोर सिस्टम पर।
लैंबो

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

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

हाँ, लेकिन समस्या अपडेट के ट्रिगर की तरह नहीं है, यह सुनिश्चित कर रहा है कि संदेश प्राप्त करने वाले के पास इस पर कार्य करने के लिए आवश्यक सभी जानकारी हो।
काइलोटन

0

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

मुख्य प्रश्न जो मेरे दिमाग में बसंत हैं: आप यह कैसे प्रबंधित करते हैं कि कुछ गेम ऑब्जेक्ट कितनी बार दूसरों के विरुद्ध अपडेट होते हैं? क्या आपको बहुत सारे चक्र लेने वाले स्प्राइट अभिनेताओं के बारे में चिंता करने की आवश्यकता होगी जैसे कि रेंडरिंग सिस्टम के पास हर 1/60 वां। 30 वां | 24 सेकंड का समय निकालने का समय नहीं है?

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


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

वहाँ सावधान रहें, मुझे नहीं लगता कि प्रत्येक स्प्राइट में ड्रा विधि या घटना उपयोगी होगी, सिवाय एक ध्वज के रूप में, दृश्यता को टॉगल करने के लिए। गेम लूप के रेंडर चरण में, जिस क्रम में स्प्राइट्स को स्क्रीन पर प्रस्तुत किया जाता है उसका परिणाम पर बड़ा प्रभाव पड़ता है। यदि आपके पास एक स्प्राइट है जो दूसरे के सामने स्थित है (आयाम मॉनिटर की ओर हो रहा है), तो आप चाहते हैं कि एक को खींचा जाए। मुझे लगता है कि स्काला के अभिनेता गेम लूप के अपडेट / लॉजिक भाग के लिए उपयोगी हैं।
michael.bartnett

आमतौर पर, आपके पास केवल एक ड्रॉ विधि होती है, इसलिए इसे लागू करने से स्प्राइट्स से निपटने के सामान्य तरीके में बहुत अंतर नहीं होना चाहिए।
लैंबो

आह ठीक है, मैं गलत समझा कि तुम क्या वर्णन कर रहे थे। मैं किसी भी तरह स्प्रिट का प्रतिपादन कर रहा था जब भी और हालांकि वे कृपया। आइये जानते हैं कि यह कैसे होता है!
michael.bartnett

0

ठीक है, मैं प्रोग्रामर का उतना हिस्सा नहीं हूं, लेकिन मुझे आपके प्रस्ताव पर कोई समस्या नहीं है। मैंने ऐसे एक्टर्स के विकास के बारे में सोचा भी नहीं था।

यह काफी चुनौती भरा हो सकता है, क्योंकि IA को सटीक व्यवहार से बचना है, लेकिन इसके अलावा, मुझे लगता है कि यह काफी अच्छा प्रस्ताव है


0

अगर प्रेत द्वारा आप खेल इकाई मतलब है तो सुनिश्चित करें।

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

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

मैं एक स्काला डेवलपर नहीं हूं, लेकिन मैंने एरलंग के साथ काफी काम किया है। इसलिए यदि मेरी कुछ स्काला शब्दावली गलत है, तो कृपया मुझे क्षमा करें।

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