ऑब्जेक्ट-ओरिएंटेड वीडियोगेम कैसे हैं? [बन्द है]


18

मैंने हमेशा सोचा है कि वीडियोगेम, विशेष रूप से विशाल 3 डी परियोजनाओं द्वारा किस हद तक ऑब्जेक्ट ओरिएंटेशन का उपयोग किया जाता है। मुझे लगता है यह शांत है कि दोनों होगा trollऔर werewolfसे उसके गुण विरासत में मिला है enemyऔर उनमें से कुछ अधिलेखित कर दिया। लेकिन शायद कक्षाएं व्यावहारिक होने के लिए बहुत भारी हैं, मुझे नहीं पता ...


2
ऑब्जेक्ट-ओरिएंटेशन कैसे करता है? क्या आप मेयर्स या डाहल-न्यागार्ड में जवाब चाहते हैं?

स्पष्ट रूप से वे इतने भारी हैं कि एक भारी OO आधारित भाषा उद्योग मानक है।
कम्युनिस्ट डक

4
यदि आप C ++ से मतलब रखते हैं, तो इसे इसलिए चुना गया क्योंकि यह गति-सचेत तरीके से टाइप-सुरक्षित जेनेरिक प्रोग्रामिंग की खोज के लिए एक अच्छी भाषा है; कुछ OOP विशेषताएँ स्पष्ट रूप से एक दुर्भाग्यपूर्ण दुर्दशा है जो केवल पश्च-संगतता के लिए रखी गई हैं। ;)

जवाबों:


20

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

छोटे वीडियोगेम में एंटिटीज को ज्यादातर अलग-अलग वर्गों द्वारा परिभाषित किया जाता है, बड़े गेम्स में वे अक्सर फाइलों में परिभाषित होते हैं। पालन ​​करने के लिए दो सामान्य दृष्टिकोण हैं:

विस्तार : आपके उदाहरण में Trollऔर Werewolfविस्तारित होगा Enemy, जो विस्तार करता है EntityEntityआंदोलन, स्वास्थ्य आदि जैसी बुनियादी चीजों का ध्यान रखता है, जबकि Enemyउप-वर्ग को दुश्मनों के रूप में बताता है और अन्य चीजें करता है (Minecraft इस दृष्टिकोण का अनुसरण करता है)।

घटक आधारित : दूसरा दृष्टिकोण (और मेरा पसंदीदा) एक Entityवर्ग है, जिसमें घटक हैं। एक घटक Moveableया हो सकता है Enemy। ये घटक आंदोलन या भौतिकी जैसी एक चीज़ का ध्यान रखते हैं । यह विधि लंबी एक्सटेंशन श्रृंखलाओं को तोड़ती है और संघर्ष में चलने के जोखिम को कम करती है। उदाहरण के लिए: यदि आप एक जंगम चरित्र से विरासत में लेते हैं, तो आप गैर-जंगम दुश्मन कैसे बना सकते हैं?

Warcraft या Starcraft 2 की दुनिया जैसे बड़े वीडियोगेम में, Entities कक्षाएं नहीं हैं, लेकिन डेटा के सेट, जो संपूर्ण इकाई को निर्दिष्ट करते हैं। स्क्रिप्टिंग भी महत्वपूर्ण है, क्योंकि आप परिभाषित करते हैं कि एंटिटी एक कक्षा में नहीं है, लेकिन एक स्क्रिप्ट में (यदि यह अद्वितीय है, तो चलती चीजें नहीं हैं)।

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


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

एक घटक एक इकाई है जिसके पास एकल कार्यक्षमता के लिए जिम्मेदारी है। घटक-आधारित इकाई का एक घटक होगा (यदि मामला है) तो यह उससे प्राप्त नहीं होगा। स्वामित्व का तात्पर्य है कि एक इकाई अपने व्यवहार को बदलने वाले अपने घटकों में से एक को निष्क्रिय कर सकती है। क्लासिक एक्सटेंशन प्रतिमान में व्यवहार "एक सुपर-क्लास" से संबंधित है। एक इकाई एक घटक हो सकती है और एक घटक को वर्ग के रूप में या यदि आप चाहें तो एक संरचना के रूप में तैयार किया जा सकता है।
21

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

2
मैंने खेल विकास के बारे में एक ब्लॉग शुरू किया और इस बारे में अपनी पहली ब्लॉग प्रविष्टि लिखी। कुछ भी नया नहीं है, लेकिन कोड के एक बिट के साथ: jagamedev.wordpress.com/2011/06/26/…
मार्को

23

मुझे लगता है कि यह अच्छा होगा कि ट्रोल और वेयरवोल्फ दोनों ने दुश्मन से अपनी विशेषताओं को विरासत में लिया और उनमें से कुछ को उखाड़ फेंका।

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

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

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

लेकिन शायद कक्षाएं व्यावहारिक होने के लिए बहुत भारी हैं, मुझे नहीं पता ...

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


3
इस उत्तर से प्यार करें :)
Czarek Tomczak

8

मुझे यकीन नहीं है कि आप "बहुत भारी" से क्या मतलब है, लेकिन C ++ / OOP समान विकास के लिए खेल के विकास का लिंगुआ फ्रेंका है जो इसे कहीं और इस्तेमाल किया जाता है।

कैश उड़ाने की बात एक डिज़ाइन मुद्दा है, न कि एक भाषा सुविधा। C ++ बहुत बुरा नहीं हो सकता क्योंकि इसका उपयोग पिछले 15-20 वर्षों से खेलों में किया जा रहा है। जावा बहुत खराब नहीं हो सकता क्योंकि यह स्मार्ट फोन के बहुत तंग समय के वातावरण में उपयोग किया जाता है।

अब असली सवाल पर: कई वर्षों के लिए वर्ग पदानुक्रम गहरे हो गए और इससे संबंधित समस्याओं से पीड़ित होने लगे। हाल के समय में वर्ग पदानुक्रम चपटा हुआ है और तर्क-संचालित विरासत के बजाय संरचना और अन्य डेटा-संचालित डिज़ाइन किए जा रहे हैं।

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


2

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


विभिन्न पॉलीमोर्फिक प्रकारों के बीच डिस्पैचिंग एक तरह से किया जाता है जो खराब मेमोरी लोकलिटी देता है। यहां तक ​​कि C ++ vtables या Objective-C IMP कैशिंग जैसे हल्के वजन वाले कार्यान्वयन में, यदि आप वास्तव में विभिन्न प्रकार की वस्तुओं से निपटने के लिए बहुरूपता का उपयोग करते हैं , तो आप अपने कैश को उड़ा देंगे। बेशक अगर आप पॉलीमॉर्फिज्म का इस्तेमाल नहीं करते हैं तो आपके कैश में वाइबट रहने या आईएमपी कैश्ड मैसेज सही जगह जाता है, लेकिन फिर परेशान क्यों? और जावा या सी # में लागत भारी है, और जावास्क्रिप्ट या अजगर में लागत अभी भी भारी है।

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

1

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

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

IOS / Mac के लिए Objective-C में समान हैं, लेकिन मैसेजिंग स्कीम (यहां तक ​​कि फैंसी कैशिंग सामान के साथ) के साथ भी बदतर समस्याएं ...


0

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


3
हे क्रिस। अपने अनुभव और योजनाओं को साझा करते समय यह बहुत अच्छा है, यह वास्तव में सीधे सवाल का जवाब नहीं है। मुझे लगता है कि यह सवाल अधिक है कि ये चीजें आम तौर पर कैसे होती हैं, जहां आप जवाब दे रहे हैं कि आप इसे करने की योजना कैसे बना रहे हैं । वे समान प्रश्न हैं, लेकिन वास्तव में समान नहीं हैं।
MichaelHouse
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.