कोड में कूदने से पहले यह योजना के लायक है?


17

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

EDIT: मैं इस प्रोजेक्ट पर अकेले काम कर रहा हूं।

तो मेरा सवाल है: यह कोड में कूदने से पहले योजना बनाने लायक है? इम को अभी भी यह जानने में दिलचस्पी है कि दूसरों का इस बारे में क्या कहना है। क्योंकि मैं अभी भी कुछ कवि कह रहा हूँ मैं सोच के बजाय कोड चाहिए .. तो इस पर आपकी क्या राय है?


क्या आप अकेले या एक टीम के रूप में काम कर रहे हैं?
नथन

6
-1 मुझे विश्वास नहीं है कि इस प्रश्न का सही उत्तर है। यह व्यक्ति के कौशल और परियोजना पर निर्भर करता है। यह केवल आपके लिए इसका जवाब देने की कोशिश करने के लिए स्थानीयकृत है।
MichaelHouse

3
बस एक सलाह: मैं कोडिंग से पहले अपने खेल की योजना कभी नहीं बनाता। इसके अलावा, मैंने कई गेम प्रोजेक्ट शुरू किए हैं और कभी भी एक को पूरा नहीं किया है।
लवेल्ला

1
@MarkusvonBroady मैं वास्तव में जवाब नहीं दे सकता। यदि यह कुछ करने के लिए "लायक" है या नहीं तो वास्तव में व्यक्ति पर निर्भर है। यह समय पर व्यक्ति, परियोजना और पल पर निर्भर करेगा। मुझे नहीं पता होगा कि यह ओपी के लिए यह करने लायक था या नहीं।
MichaelHouse

3
यह वास्तव में ऑफ-टॉपिक है, क्षमा करें। इसके बजाय programmers.stackexchange.com आज़माएँ ।
साइक्लॉप्स

जवाबों:


34

आपने अपने प्रश्न में दो स्मार्ट बातें कही हैं:

  1. "सोचने के बजाय कोड" - इसमें वर्णन करने वाला एक संपूर्ण दर्शन है: http://gettingreal.37signals.com/toc.php
  2. "अगर यह किया जा सकता है यह जांचने के लिए अवधारणा के सबूत" - मैंने देखा है और कई विचार थे जो लगभग समाप्त होने पर असंभव या बेहद कठिन हो गए थे। कभी-कभी आप सिर्फ इसका अनुमान नहीं लगा सकते हैं, क्योंकि यह आपके प्रोग्रामिंग वातावरण (भाषा, पुस्तकालय, हार्डवेयर प्रदर्शन) को सीमित कर रहा है।

इसलिए मैं कहता हूं:

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

दिलचस्प अंक।
रशिनो सेप

यह वास्तव में अच्छी तरह से सोचा जवाब है। +1
भेड़ियाडाउन

1
+1। मैं विशेष रूप से एक गंदे परीक्षण के बारे में आपकी बात को सीधा कर सकता हूं। एक डिजाइन की तुलना में प्रोटोटाइप बहुत सस्ते हैं जो सिर्फ काम नहीं करेंगे।
अर्लज़

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

5

हां, लेकिन केवल थोड़ा सा

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

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

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


^ क्या सही उत्तर के रूप में चिह्नित किया जाना चाहिए था। "हां थोड़ा सा।" बिल्कुल सही।
इंजीनियर

3

कुछ का कहना है कि आपको सोचने के बजाय कोड करना चाहिए? अच्छी तरह से कोड करने के लिए आपको यह जानना होगा कि आप क्या बनाना चाहते हैं, यह जानने के लिए कि आप क्या बनाना चाहते हैं, आपको पहले सोचने की ज़रूरत है कि आपके पास क्या है, क्या आपको कोड से पहले सोचने की ज़रूरत है;)।

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


3

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


2

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

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


1

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


1

(मुझे लगता है कि प्रश्न कोड-डिज़ाइन / वास्तुकला के दृष्टिकोण से बनाया गया है, गेम-डिज़ाइन एक नहीं है, हालांकि कम से कम कुछ हद तक जवाब दोनों पर लागू होता है।)

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

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

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


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

धन्यवाद, लेकिन मुझे लगता है कि आप मुझसे सहमत होंगे अगर मैंने कहा कि ऐसे प्रश्न हैं जहां कोई उद्देश्य उत्तर नहीं है और उन सभी को कम या ज्यादा राय या अनुभव पर आधारित किया जाएगा (चाहे वह व्यक्तिगत हो, या किसी और का हो ), और ये उनमें से एक है। मुझे उस सुझाव / नियम के बारे में पता था, और जब भी संभव हो मैं इसका पालन करने की कोशिश करूंगा। लेकिन धन्यवाद के लिए वैसे भी धन्यवाद।
sh
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.