गेम इंजन और डेटा संचालित डिज़ाइन


21

मैंने डेटा संचालित डिज़ाइन के बारे में सुना है और कुछ समय से इसके बारे में शोध कर रहा हूँ। इसलिए, मैंने अवधारणाओं को प्राप्त करने के लिए कई लेख पढ़े हैं।

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

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

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

इसलिए, इस सब के बाद, मैं बस यह सत्यापित करना चाहता हूं कि इन विचारों (डेटा संचालित, प्रोग्रामर ड्राइव, स्क्रिप्टिंग आदि ...) के बारे में मेरी समझ में कोई दोष है?


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

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

जवाबों:


25

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

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

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

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

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

अपने विशिष्ट प्रश्नों के लिए:

क्या यह सच है कि गेम इंजन कैसा होना चाहिए?

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

इसलिए, इस सब के बाद, मैं बस यह सत्यापित करना चाहता हूं कि इन विचारों (डेटा संचालित, प्रोग्रामर ड्राइव, स्क्रिप्टिंग आदि ...) के बारे में मेरी समझ में कोई दोष है?

आप सही पाठ्यक्रम पर अधिक या कम लग रहे हैं, हालांकि आप शायद अधिक जटिल हैं कि डेटा-आधारित डिज़ाइन और विकास को घटक-आधारित सिस्टम के साथ भ्रमित करके क्या है।


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

1
@Amumu अपने जावा प्रोजेक्ट्स के लिए चींटी का उपयोग करना शुरू करते हैं और आप वही देखेंगे (नेटबाइन्स चींटी स्वचालित रूप से चींटी का उपयोग करता है) जिसे आप देखते हैं।
pek

2
+1 "एक प्रोग्रामर को एक डिजाइनर की नौकरी के लिए पुनरावृति पाश में मौजूद होने के लिए मजबूर करना" बिल्कुल! प्रोग्रामर कोड, डिजाइनर डिजाइन। जितना अधिक आप इन नौकरियों को अलग करते हैं, उतने ही समानांतर वे (और इस प्रकार विकास के समय को कम करते हैं)।
pek

6

दूसरे पोस्ट के लेखक के रूप में, मैं कुछ बिंदुओं को स्पष्ट करना चाहूंगा।

  1. जैसा कि जोश पेट्री ने सुझाव दिया, अपने कोड को केवल हार्ड कोडिंग के बजाय डेटा का उपयोग करने के लिए संरचित करना हमेशा एक जीत है। मैं अन्यथा सुझाव नहीं दे रहा था। मैं इंगित कर रहा था कि डिजाइनर पर सब कुछ धकेलना एक अच्छा विचार नहीं है। शब्द "डेटा चालित डिजाइन" का अर्थ अलग-अलग लोगों के लिए अलग-अलग चीजें हैं, इसलिए मुझे मूल लेख लिखने पर संभवतः अधिक विशिष्ट होना चाहिए था।
  2. मेरे द्वारा काम किए गए प्रत्येक स्थान पर, हम डेटा संरचनाएँ बनाते हैं जो इंजन में ट्विकेबल हैं। एक परिवर्तन करने के लिए, हमें खेल को फिर से स्थापित करने की आवश्यकता नहीं है। हम रनटाइम पर संख्या को गतिशील रूप से बदल सकते हैं। डेटा संरचनाओं को अक्सर कोड में संग्रहीत किया जाता है, लेकिन जो उन्हें बदल रहा है, उसके आधार पर उन्हें आसानी से "डेटा फ़ाइल" से लोड किया जा सकता है।
  3. अधिकांश विकास वातावरण सी / सी ++ के लिए किसी न किसी रूप में संपादन और जारी रखने या मॉड्यूल पुनः लोड करने का समर्थन करते हैं।
  4. अधिकांश गेम डेवलपमेंट स्टूडियो में गेमप्ले प्रोग्रामर होते हैं। उनके काम अक्सर एक मजेदार अनुभव बनाने में डिजाइनर के साथ काम करना होता है। उनकी मुख्य चिंता तकनीकी चुनौतियां नहीं हैं, बल्कि कोड से मौज मस्ती करना है। मैंने कई वर्षों तक गेमप्ले प्रोग्रामर के रूप में काम किया है, और मुझे यह तकनीकी चुनौतियों को हल करने की कोशिश से अधिक दिलचस्प लगता है। मेरी ज़िम्मेदारियाँ अलग-अलग हैं, लेकिन मैंने अपने काम को तब पूरा किया है जब मैं कार्यान्वयन का प्रभारी हूं और मैं डिजाइनरों के साथ कुछ शांत करने पर काम करता हूं। डिजाइनरों की कोडिंग या स्क्रिप्टिंग के साथ समस्या यह है कि प्रोग्रामर को अक्सर बग्स को सुलझाना पड़ता है, जो कि प्रोग्रामर के रूप में आप कर सकते हैं सबसे कम मजेदार चीजों में से एक है।
  5. एक स्टूडियो के लिए सबसे अच्छा काम क्या खेल पर निर्भर करता है। यदि आपके पास एक गेम बनाने के लिए एक लंबा समय है, और आप अपने गेम लेग को मॉड समुदाय के लिए देना चाहते हैं और स्कोप में कुछ बड़ा करना चाहते हैं, तो एक गेम बनाना जो पूरी तरह से डेटा संचालित है, समझ में आता है। बहुत सारे खेलों में वह लक्ष्य नहीं होता है। उन्हें दो साल में एक नया खेल शुरू करना होगा, और जब तक उनके पास एक हिट फ्रैंचाइज़ी नहीं होगी, यह संभवतः उनके काम के लिए एक अलग प्रकार का खेल है
  6. एक "डिजाइनर" जो स्टूडियो से स्टूडियो तक भिन्न हो सकता है। मैंने एक विकास स्टूडियो के बारे में सुना है जो अन्य स्टूडियो के गेमप्ले प्रोग्रामर को काम पर रखता है, उन्हें डिजाइनर कहता है, और उन्हें गेम के व्यवहार की स्क्रिप्ट देता है। यह उन लोगों की समस्या को दूर करता है जो प्रोग्रामिंग कोडिंग / स्क्रिप्टिंग में प्रशिक्षित नहीं हैं।
  7. हमेशा गेम लॉजिक कोड और इंजन कोड के बीच एक परिसीमन होना चाहिए। साथ ही, आप सामान्य रूप से ऑब्जेक्ट प्लेसमेंट के लिए किसी प्रकार का विज़ुअल एडिटर रखना चाहते हैं। मैंने कभी ऐसे स्टूडियो में काम नहीं किया है जहाँ दुश्मन के स्थानों को हार्ड कोड किया गया हो। उन्हें एक संपादक में रखा गया है। मुझे इस बारे में एक उदाहरण देने का प्रस्ताव है कि मैं किस बारे में बात कर रहा हूं। मान लीजिए कि डिजाइनर एक दुश्मन के बारे में सोचता है। क्या डिजाइनर इस नए दुश्मन के प्रकार की स्क्रिप्ट की तुलना में है? यही कारण है कि मैं डेटा संचालित डिजाइन पर विचार करता हूं (टिम मॉस ने इसके बारे में क्या लिखा है)। जिस तरह से मैं प्रस्ताव कर रहा हूं, प्रोग्रामर डिजाइनर के साथ काम करता है, वे एक मजेदार शत्रु बनाते हैं शायद ट्वीकेबल मापदंडों के साथ, और फिर उन्हें स्तर में रखा जाता है।
  8. प्रोग्रामर द्वारा लिखा गया मूल कोड प्रोग्रामर द्वारा लिखी गई स्क्रिप्ट की तुलना में रनटाइम पर तेजी से निष्पादित करने वाला है, जो कम तकनीकी समझ रखने वाले व्यक्ति द्वारा लिखी गई स्क्रिप्ट की तुलना में तेजी से निष्पादित करेगा। यह प्रदर्शन आपके लिए किस प्रकार का खेल बना रहा है और आप क्या कर रहे हैं, इसके आधार पर महत्वपूर्ण हो सकता है, लेकिन यह विचार करने के लिए कुछ है।
  9. आप चाहे जो भी तरीका चुनें, आप गेम के बीच गेम कोड साझा कर सकते हैं। मुझे वास्तव में यकीन नहीं है कि आप इस बिंदु पर क्या कर रहे हैं। यहां तक ​​कि अगर आप कुछ व्यवहारों को परिभाषित करने के लिए एक स्क्रिप्टिंग भाषा या दृश्य उपकरण का उपयोग नहीं कर रहे हैं, तो आपको अपने गेमप्ले कोड को पुन: प्रयोज्य घटकों में जितना संभव हो उतना संभव बनाना चाहिए। वहाँ हमेशा सामान होगा जो आपके अगले गेम पर लागू नहीं होता है, लेकिन मैंने जिस जगह पर कभी काम किया है, जब हम अगला गेम शुरू करते हैं, तो हम पिछले से कोडबेस के साथ शुरू करते हैं - भले ही यह अगली कड़ी न हो। हम तब सामान रखते हैं जो समझ में आता है और खेल विशिष्ट सामान को हटा देता है।

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

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

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


1

आपको बिटक्वाइड टेक इंजन देखना चाहिए । यह डीओडी अवधारणाओं का उपयोग करके बनाया गया है। Niklas Frykholm का ब्लॉग बहुत दिलचस्प है। यह इंजन कैसे डिज़ाइन किया गया है, इस पर कई लेख हैं।

जीडीसी 2011 में, निकल्स ने डेटा ड्रिवेन रेंडरर के बारे में एक प्रस्तुति दी है ।


3
DOD डेटा-ओरिएंटेड डिज़ाइन है , यह समानता और कैशिंग का लाभ उठाने के लिए स्मृति में कार्य डेटा को व्यवस्थित करने के आधार पर तकनीकी वास्तुकला का मूल्यांकन करने का एक तरीका है। डेटा-संचालित डिज़ाइन एक वर्कफ़्लो प्रतिमान है जो किसी विशेष सॉफ़्टवेयर एजेंडा का अर्थ है, लेकिन किसी विशेष कार्यान्वयन का नहीं।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.