क्या आवश्यकताओं का विश्लेषण खेल के विकास में उपयोगी है?


9

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

मैं पूछ रहा हूं क्योंकि मैं यह तय करने की कोशिश कर रहा हूं कि क्या आवश्यकताओं के विश्लेषण पर कक्षा ली जाए। यहाँ एक विवरण है:

आवश्यकताओं के उपयोग, आवश्यकताओं, विश्लेषण, आवश्यकताओं विनिर्देश, आवश्यकताओं के सत्यापन और सत्यापन, और आवश्यकताओं के प्रबंधन में वर्तमान शोध और अभ्यास का गहन अध्ययन।

क्या इस प्रकार का ज्ञान एक स्वतंत्र गेम डेवलपर के लिए उपयोगी होगा? (विकल्प कृत्रिम बुद्धिमत्ता या सॉफ्टवेयर आर्किटेक्चर हैं।)


स्पष्ट करने के लिए, आपके विकल्प क्या हैं?
क्रिस

हां, अपनी स्थिति पर थोड़ा और प्रकाश डालें, कृपया। क्या यह आपके कोर कोर्सवर्क के अतिरिक्त कुछ है या आप यह निर्धारित करने की कोशिश कर रहे हैं कि क्या आरए आपके कोर का हिस्सा है?
जेसन पाइनो

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

कोई भी लागू टूल / तकनीक जो आपको विश्लेषण से बचने में मदद करेगी पक्षाघात उपयोगी होगा।
पैट्रिक ह्यूजेस

जवाबों:


7

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

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

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


+1 जो कुछ भी यहां बताया गया है वह सही है, साथ ही साथ कुछ इस विचार को संबोधित करते हुए कि आप कॉरपोरेट प्रोग्रामिंग कर सकते हैं जब तक कि आपने इसे इंडी सीन में नहीं बनाया है।
क्रिस ई

यह कैसे उपयोगी नहीं हो सकता है? आपको कुछ भी करना होगा जो आप एक संरचित तरीके से करते हैं। सिर्फ इसलिए कि कुछ शब्द अस्पष्ट हैं इसका मतलब यह नहीं है कि इसे मात्रा देना असंभव है।
जॉनी

2

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

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


मुझे आशा है कि "सुविधा की कमी" के लिए "द्रव की आवश्यकताएं" एक व्यंजना नहीं है। : \ _ मैं असहमत हूं कि आप जिस चीज से "अंत" करेंगे, वह अर्थहीन और अस्पष्ट शब्द जैसे "मस्ती", "लत", आदि हैं। वे गैर-तकनीकी आवश्यकताओं का प्रतिनिधित्व करते हैं, जो वास्तव में सोची गई आवश्यकताओं का एक सबसेट हैं। दस्तावेज़।
पैट्रिक बीब

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

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

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

अन्य तरीके क्या हैं?
जॉनी

2

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

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


0

इसे छोड़।

खेल विकास के किस क्षेत्र में जाने में आपकी रुचि है? मैं प्रोग्रामर मान रहा हूँ लेकिन ...

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

प्रोग्रामर: लीड तकनीकी आवश्यकताओं को निर्धारित करता है जो प्लेटफॉर्म और परिसंपत्ति पाइपलाइन पर बेहद निर्भर करेगा। आप सीखेंगे कि यह कैसे करना है क्योंकि आप काम पर अपने नेतृत्व के साथ काम करते हैं।

कलाकार: मुख्य कलाकार के साथ इसके प्रमुख कलाकार के साथ फिर से जो कला संपत्ति के लिए आवश्यकताओं को निर्धारित करते हैं। काम पर जानें।

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

यदि आप इंडी जाने की योजना बनाते हैं तो व्यवसाय / लेखा / प्रबंधन विषय लें। आपको इसे जीवित रहने और खराब होने की आवश्यकता नहीं है। शुभ लाभ।


मैं प्रोग्रामर भी मानूंगा, क्योंकि उन्होंने इसे प्रोग्रामर टैग किया था;)
कम्युनिस्ट डक

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

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

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

1
@PatrickB आवश्यकताएँ विश्लेषण को प्रभावित नहीं करेगा कि सॉफ्टवेयर का एक टुकड़ा कैसे डिज़ाइन किया गया है। आवश्यकताओं का विश्लेषण जानकारी के बेकार टुकड़ों से भरा है जो एक गेम डेवलपर शायद ही कभी उपयोग करेगा (केस डायग्राम विशेष रूप से वसंत को ध्यान में रखें)। यह एक ऐसा विषय है जो हितधारकों और इसलिए कॉर्पोरेट वातावरण की ओर बहुत ज्यादा सक्षम है। मैं सहमत हूं कि डेवलपर को आवश्यकताओं (सुविधाओं) को सूचीबद्ध करना चाहिए लेकिन यह सामान्य ज्ञान होना चाहिए। सॉफ्टवेयर के एक टुकड़े को डिजाइन करना एक पूरी तरह से अलग विषय है, जिसके विश्लेषण के लिए आवश्यकताओं का विश्लेषण मुश्किल से ही होता है (वैसे भी विश्वविद्यालय में)
रे डे
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.