मुझे हार्ड-कोड डेटा बनाम बाहरी डेटा कब लोड करना चाहिए?


36

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

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

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

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


10
आप जिस शब्द की तलाश कर रहे हैं, वह "डेटा ड्रिवेन" है और हाँ, एक्सएमएल के साथ नए स्टेशन और जहाज बनाने के लिए लंबे समय में यह बहुत तेज़ है (या वास्तव में JSON जैसा कोई प्रारूप) फ़ाइलों की तुलना में आप एक छोटे प्रोजेक्ट पर क्या कर रहे हैं। । साथ ही बाद में आप दूसरी बार की बचत के लिए, कोड और पुन: स्पर्श करने के बिना हटा सकते हैं और संपादित कर सकते हैं।
पैट्रिक ह्यूजेस

@PatrickHughes मेरा जवाब टाइप करते हुए, आपने पहले ही टिप्पणी में डाल दिया!
मार्टिनटेगा

1
यदि हम "सॉफ्ट-कोडिंग" को एक वास्तविक शब्द के रूप में वैध बनाने की कोशिश कर रहे हैं, तो मैं "हार्ड-कोडेड इनपुट को सॉफ्ट-कोडेड डेटा मैट्रिक्स का उपयोग करके" फर्म-कोडिंग के रूप में प्रस्तावित करता हूं।
सीन मिडिलिच्ड

1
@ Singular1ty यह साइट कुछ अन्य एसई की तुलना में चर्चा की अधिक क्षमा है। मुझे लगता है कि आपका प्रश्न "अच्छी चर्चा" स्थिति के लिए योग्य है।
सेठ बट्टिन

2
@ Singular1ty आह, यह यहाँ है। जब मैंने अपनी पहली टिप्पणी पोस्ट की, तो यह नहीं मिली। blog.stackoverflow.com/2010/09/good-subjective-bad-subjective
सेठ

जवाबों:


62

हाँ। आपको अपने मुख्य इंजन के बाहर सामग्री लोड करने के लिए एक प्रणाली लागू करनी चाहिए।

संक्षिप्त जवाब के लिए हेड।

नहीं। यह बहुत अधिक समय का उपभोग नहीं करता है।

मुझे लगता है कि यह सवाल है कि क्या यह आपके सीमित समय का वैध आवंटन है; भले ही केवल इस तथ्य के लिए कि यह कुल परियोजना समय का एक छोटा सा हिस्सा होगा।

आप एक गेम प्रोजेक्ट पर सैकड़ों (हजारों) घंटे खर्च करेंगे जिसे आप पूरा करने के लिए लेते हैं। शायद पोंग क्लोन पर नहीं, लेकिन निश्चित रूप से आपके जटिल अंतरिक्ष खेल के लिए। इसकी तुलना एक फाइल फाइल रीडर से करें। XML को आपके मुख्य कंस्ट्रक्टर में पाइप करने के लिए एक सिस्टम को लागू करना, और बाद में गेम प्रक्रिया को फिर से शुरू करना, शायद 10 या 20 घंटे लगेंगे । यहां तक ​​कि अगर यह आपको 50 या 100 लेता है, तो यह कुल परियोजना समय का एक छोटा अंश होगा।

इससे समय की बचत होगी

यह समय का खर्च नहीं है; यह एक समय का निवेश है। और यह भुगतान करेगा।

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

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

एक सदस्यीय टीमों को सबसे ज्यादा फायदा होता है

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

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

अपने आप से ऐसा मत करो। उपकरण बनाएं, और आपके पास गेम बनाने के लिए अधिक समय होगा।


3
वाह, एक और शानदार जवाब! बहुत बहुत धन्यवाद। मैं निश्चित रूप से मूल्यों को जल्दी से बदलने की क्षमता से सहमत हूं - और बग-शिकार पर भी। एक या दो छोटी चीजों को भूल जाना जल्दी से दुःस्वप्न में बदल जाता है, और मैं चाहता हूं कि जो कुछ भी आवश्यक हो, कोड की समान पंक्तियों को केवल गठबंधन, नाम और पतवार / हथियार मूल्यों के बीच मामूली बदलाव के साथ दोहराने पर करें।
Singular1ty

सेठ, आपके नए विशेषाधिकार स्तर पर आपका स्वागत है। अपने करीबी और वोटों को फिर से उपयोग करें!
MichaelHouse

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

10

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

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

लक्ष्य कुछ समाप्त करने के लिए है, और यदि आप एक महान प्रणाली बनाने में फंस गए हैं, तो लक्ष्य आगे बढ़ जाएगा और आप प्रेरणा खो देंगे। कुछ परिस्थितियों में हार्ड-कोडिंग सामान ठीक है, लेकिन आपको इसे करने के प्रभावों को समझना चाहिए। यहाँ कुछ कारण बताए गए हैं कि हार्डकोडिंग एक बुरा विचार क्यों है:

  • आप सोच सकते हैं कि आपका प्रोजेक्ट छोटा है, लेकिन यह संभव है कि जैसे-जैसे आप अधिक सुविधाएँ जोड़ने का निर्णय लेते हैं, यह बढ़ता जाता है। यदि आप हार्डकोडिंग शुरू करते हैं, तो एक समय आने वाला है जब इसे बनाए रखने के लिए आवश्यक ऊर्जा (नए सामान के साथ अपडेट करना और अपरिहार्य बगों के असंख्य को ठीक करना) प्रारंभिक लाभ को गंभीरता से पछाड़ना शुरू कर देगा।

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

  • आप इस समय अकेले काम कर रहे होंगे, लेकिन एक समय ऐसा भी आ सकता है जब आप किसी और को प्रोजेक्ट पर लाना चाहें। क्या आप अपने घृणित उपहास प्रणाली की व्याख्या करने और इसके लिए प्रलेखन लिखने के लिए समय निकालने जा रहे हैं?

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

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

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


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

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

8

आप जिस बारे में बात कर रहे हैं वह डेटा-संचालित प्रोग्रामिंग है

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

हालांकि, डेटा संचालित प्रोग्रामिंग को लागू करना बहुत आसान हो सकता है। यदि आप इसके बारे में गंभीर हैं, तो आपको संभवतः XML, JSON, या YAML का उपयोग करना चाहिए, लेकिन आप सादे पाठ फ़ाइलों का भी उपयोग कर सकते हैं।

डेटा-संचालित प्रोग्रामिंग

पेशेवरों

  1. डिजाइनरों को प्रोग्रामिंग ज्ञान के बिना गेम डेटा तक पहुंचने और संशोधित करने की अनुमति देता है
  2. आप recompile की आवश्यकता के बिना खेल में संशोधन कर सकते हैं । इसे कम करके नहीं आंका जाना चाहिए, क्योंकि आप इस तरह से बहुत तेजी से खेल विकसित कर सकते हैं। कई पुनरावृत्तियों के बाद अच्छे खेल आते हैं।

विपक्ष

  1. इसे लागू करने में समय और मेहनत लगती है।
  2. यह कार्यक्रम की जटिलता को बढ़ा सकता है।

ये केवल कुछ पेशेवरों और विपक्ष हैं जिनके बारे में मैं अभी सोच सकता हूं; मुझे पता है अगर आप और अधिक लगता है!
निक कैपलिंगर

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