2012-05-16 9 views
21

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

+5

मुझे विश्वास है कि बहुत सारे libGDX उदाहरण चरण + अभिनेता समर्थन की पूर्व-तारीख हैं, ताकि यह समझाया जा सके कि वे इसका उपयोग क्यों नहीं करते हैं। –

उत्तर

36

अभिनेताओं के लिए मुख्य पेशेवर क्रियाएं, हिट परीक्षण और स्पर्श कार्यक्रम, और अभिनेताओं के समूह हैं।

क्रियाएं आपके गेम तर्क की आवश्यकता होने पर त्वरित और आसान ट्विनिंग कर देती हैं।

आप किसी भी समय पहले अभिनेता को वापस करने के लिए stage.hit (x, y) को कॉल कर सकते हैं जो आपके द्वारा लिखे गए हिट लॉजिक (आमतौर पर एक्स, वाई, चौड़ाई, ऊंचाई के साथ सीमाओं की जांच) को सच करता है। एक अभिनेता की हिट विधियों के माध्यम से एक हिट अभिनेता की तलाश में फिर से चलने के लिए इस अभिनेता या नल को वापस लौटें। अगर कोई अभिनेता नहीं मारा जाता है तो नल वापस आ जाता है।

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

आप अभिनेताओं को एक इकाई के रूप में पूरे समूह के समूह पर क्रियाएं, स्पर्श घटनाओं आदि को एक साथ करने के लिए समूह कर सकते हैं।

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

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

+1

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

संबंधित मुद्दे