हमारे द्वारा तैयार किए गए खेलों को पूरा करने के लिए हमारे हाथों में मुश्किल से ही समय के साथ, आप ठोस सॉफ्टवेयर वास्तुकला के बीच एक अच्छा संतुलन कैसे बना सकते हैं और इसे पूरा करने के लिए अच्छी प्रगति कर रहे हैं?
मेरी व्यक्तिगत चुनौती: एक ही समय में आज और प्रभावी दीर्घकालिक सोच के बारे में कैसे? इसके अलावा, जब आप ऐसा कर रहे हैं तो आप उसी तरह दोहराए जा सकने वाले पैटर्न का सहारा लेने के बजाय रास्ते में नई चीजों को सीखना चाहते हैं, जो आप पिछले 5 सालों से इस्तेमाल कर रहे हैं?
जवाबों:
आपके पास जितना कम अनुभव होगा, उतना ही अधिक समय आप अप-फ्रंट डिजाइन के साथ बर्बाद करेंगे। अच्छे डिजाइन बनाना एक ऐसी चीज है जिसे आप इसे सीखकर और फिर इसका मूल्यांकन / मूल्यांकन करके देखते हैं कि यह कैसे होता है। कुछ निर्णय दूरगामी होते हैं लेकिन अस्पष्ट प्रभाव। कुछ गेमों के बाद आप संभवतः शुरुआती डिज़ाइन को बहुत ठोस बना पाएंगे और इस चरण में कुछ और समय लगाने के लिए भुगतान करेंगे।
मेरा आदर्श वाक्य: चीजों को पहले स्थान पर प्राप्त करें, लेकिन आप सामान्य ज्ञान का उपयोग करके यह पता लगा सकते हैं कि कौन से घटक दूसरों की तुलना में अधिक महत्वपूर्ण हैं और आपके समय सीमा के भीतर उन लोगों को अच्छी तरह से डिजाइन करते हैं। उदाहरण के लिए, यदि AI आपके खेल के लिए महत्वपूर्ण है, तो सुनिश्चित करें कि आप इसे बाद में आसानी से बढ़ा / बदल सकते हैं। या, यदि आप एक घटक लिखने जा रहे हैं जिसे आप हर खेल में उपयोग करेंगे, तो इसे पुन: प्रयोज्य के लिए डिज़ाइन करें। अपने समय को ट्रैक करें और डिजाइनिंग पर ध्यान न दें। एक डिज़ाइन-डेडलाइन सेट करें और उसके बाद, अपनी रिलीज़-डेडलाइन प्राप्त करने के लिए सब कुछ हैक करना शुरू करें। लेकिन सुनिश्चित करें कि आप उन बातों को सुधारने के लिए अगले गेम को शुरू करने से पहले कुछ बिंदुओं पर विचार करने / फिर से डिजाइन करने और बाद में गणना करने की आवश्यकता पर ध्यान दें, ताकि वे आपको वापस काटने के लिए न हों!
एक अच्छी सलाह: यदि आपको दो विकल्पों के बीच चयन करना है, तो विवरणों पर बहुत अधिक समय तक नहीं टिकें। ज्यादातर, कोई "अच्छा" या "बुरा" नहीं होता है। कुछ स्थितियों में, ए बेहतर होगा, कुछ में, बी होगा, और कुल मिलाकर, दोनों के बीच का अंतर हमेशा समय के लायक नहीं हो सकता है।
सॉफ्टवेयर या गेम डिजाइन करने में बहुत अनुभव है, इसलिए सुनिश्चित करें कि आप अपना कुछ समय अनुसंधान पर खर्च करते हैं (जैसे डिजाइन पर किताब पढ़ना, दूसरों के अनुभव के बारे में पढ़ना, अपने डिजाइन के बारे में साथी प्रोग्रामर से बात करना, आदि ... )।
लोग भविष्य की भविष्यवाणी करने में भयानक हैं। यह खेलों के लिए विशेष रूप से सच है, जहां आवश्यकताओं को दैनिक आधार पर बदल सकते हैं।
नामक एक सिद्धांत है YAGNI , उर्फ "यू आर गॉन नीड इट", जो मूल रूप से कहता है कि आपको तब तक कुछ लागू नहीं करना चाहिए जब तक आप नहीं जानते कि आपको इसकी आवश्यकता है।
मैंने देखा है कि बहुत सी प्रणालियाँ वास्तुशिल्प कठोरता से ग्रस्त हो गई हैं जो वास्तव में इसका कोई उपयोग नहीं करती हैं क्योंकि लोगों को लगता है कि जिन सुविधाओं की उन्हें आवश्यकता थी वे कभी भी उपयोग किए जाने वाले नहीं थे।
मेरा व्यक्तिगत दर्शन है द सिंपल थिस थिंग दैट पॉसिबल वर्क । कहा जा रहा है कि, गेटिंग इट ड्रोन और हैकिंग शिट टू में अंतर है। एक उद्देश्य के साथ कोड लिखने का अर्थ उन चीजों को नहीं करना चाहिए जो "कोड गंध" उत्पन्न करते हैं जैसे कि सब कुछ सार्वजनिक करने के लिए, बूँद वर्ग जो सब कुछ करते हैं, या उन दर्जनों अन्य चीजों में से जो "खराब" कोड को दर्शाते हैं।
यह आज मेरी मानसिकता में सच का मूल्यांकन करता है:
मैं सॉफ्टवेयर रैपिड प्रोटोटाइप का दोस्त हूं। खासकर खेल विकास के दौरान। यह त्वरित सीखने, परीक्षण और चीजों का उपयोग करने के लिए अच्छा है। हार्डवेयर प्रोग्रामिंग या जटिल एल्गोरिदम के करीब मेरे लिए सबसे अच्छी विधि है।
Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();रैपिड प्रोटोटाइप के मेरे संस्करण में उचित प्रोटोटाइप क्रस्ट है:
लाभ:
यदि आप इसे अच्छी तरह से करते हैं तो आपके पास अंत में अपने उत्पाद का वास्तविक डिबग / लर्न संस्करण हो सकता है।
हम इसे अपने प्रोजेक्ट में इस्तेमाल कर रहे हैं और हम इससे खुश हैं।
चुस्त सॉफ्टवेयर विकास पर एक नजर है । हालांकि यह एक चांदी की गोली नहीं है, इसका उद्देश्य दोनों को करना है (इसे पूरा करें और ठोस सॉफ्टवेयर डिजाइन करें)।