खेल विकास अन्य सॉफ्टवेयर विकास से कैसे अलग है? [बन्द है]

Question

एक ठोस सामान्य प्रयोजन सॉफ्टवेयर डेवलपर के लिए, क्या विशेष रूप से खेल के विकास के बारे में अलग है, या तो मौलिक रूप से या सिर्फ डिग्री में अंतर है?

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

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

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

पुनश्च यह महसूस करने के लिए स्वतंत्र हैं, मैं वास्तव में निश्चित नहीं हूं कि टैग क्या लागू होते हैं।

Answer 1

एक बड़ा अंतर है। मेरी राय में, यह एकमात्र अंतर है जो वास्तव में मायने रखता है।

हम तकनीकी विवरणों पर जा सकते हैं कि यह अलग क्यों है, निश्चित है। 3 डी इंजन, कण भौतिकी, विभिन्न चीजों के बहुत सारे खेल में आते हैं।

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

तो क्या खेलों को अलग बनाता है?

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

खेलों के साथ, आपके व्यवसाय की आवश्यकता "मज़ेदार" है। "मज़ा" के लिए एक तकनीकी विनिर्देश लिखने का प्रयास करें।

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

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

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

अपने खेल-भक्ति के साथ शुभकामनाएँ !! : डी

Comments

यदि आप "उपयोगी" के साथ "मज़ा" स्वैप करते हैं, तो मुझे लगता है कि आप एक उत्पाद को डिजाइन करने के साथ एक ही समस्या में भाग लेते हैं (जैसा कि एक क्लाइंट के लिए सॉफ्टवेयर लिखने के विपरीत)। मुझे लगता है कि हालांकि डिग्री में अंतर है। लोग कभी-कभी इस बारे में गलत होते हैं कि क्या उपयोगी होगा, वे आम तौर पर इस बात से जुड़े होते हैं कि उनके लिए कुछ "मजेदार" होता है। (+1 हालांकि)

— डेविए 8

वयस्क फिल्म उद्योग के बारे में एक कुख्यात सर्वोच्च न्यायालय का फैसला था और '60 के दशक में "कट्टर" का वर्गीकरण किया गया था। न्याय ने कहा "मैं इसे परिभाषित करने में कभी सफल नहीं हो सका] लेकिन मुझे पता है कि जब मैं इसे देखता हूं।" मुझे लगता है कि मजे के लिए भी ऐसा ही कहा जा सकता है। मेरा मतलब है, मुझे उन चीजों के बारे में पता चल सकता है जो मुझे खेलों के बारे में पसंद हैं, लेकिन मैं अक्सर खुद को एक गेम खेलता हूं और खुद से पूछता हूं कि "यह मजेदार क्या है?" (जाहिर है कि मैं जानना चाहता हूं इसलिए मैं इसे अपने एक गेम में फिर से बना सकता हूं !!) लोग नहीं जानते कि क्या कुछ मजेदार है, लेकिन वे निश्चित रूप से जानते हैं कि उन्होंने इसे कब पाया!

— corsiKa

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

— फिल

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

— corsiKa

यह अब तक का सबसे अच्छा जवाब है। सॉफ्टवेयर व्यवसाय आला विचारों और इसके आगे के लिए बहुत सारे लेख हैं, लेकिन खेल के विकास के बारे में बहुत सारे नहीं हैं। Hmmmm।

— जॉनी

Answer 2

मैं मुख्य रूप से एक गेम डेवलपर हूं और पारंपरिक सॉफ्टवेयर डेवलपर नहीं हूं, लेकिन मुझे लगता है कि कई महत्वपूर्ण अंतर हैं।

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

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

कुछ आसानी से पहचाने और अलग किए गए सिस्टम?

• टक्कर की पहचान हुई है
• टकराव की प्रतिक्रिया
• भौतिक विज्ञान
• एनीमेशन
• ग्राफिक्स (2 डी और 3 डी)
• कृत्रिम होशियारी
• उपयोगकर्ता का निवेश
• फ़ाइल इनपुट / आउटपुट
• नेटवर्किंग

Comments

+1 प्रश्न के अच्छे उत्तर के लिए भले ही मेरे विशेष खेल के लिए मुझे उन सबसे (टर्न-बेस्ड और टाइल-आधारित) से निपटना नहीं है, इसलिए कोई वास्तविक टकराव नहीं, कोई भौतिकी नहीं, ग्राफिक्स में स्प्राइट और अधिक JQuery फेंकना शामिल है इस पर, 2-खिलाड़ी तो कोई AI, अभी तक, उपयोगकर्ता इनपुट को अधिकतर Restful तरीके से संभाला जाता है जो नेटवर्किंग पहलू को भी कवर करता है) मुझे यकीन नहीं है कि आप फ़ाइल IO से क्या मतलब है, हालांकि एक गेम को बचाने / लोड करने के अलावा अन्य क्या कहते हैं विशिष्ट खेलों में IO के प्रकार की आवश्यकता होती है?

— डेवि 8

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

— corsiKa

@glowcoder मुझे पता है कि आप क्या कह रहे हैं, लेकिन मुझे लगता है कि मैं इस बिंदु को भी समझता हूं कि सायन बनाने की कोशिश कर रहा है, कि आम तौर पर या तो पूरी परियोजना एक सफलता है या यह एक विफलता है, और यह आमतौर पर आपके उत्तर में वर्णित एक कारक है। : क्या यह मज़ेदार है? आप बग के लिए हॉट-फ़िक्स कर सकते हैं लेकिन आप फ़न की कमी को हॉट-फ़िक्स नहीं कर सकते।

— डेविए 8

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

— पीटर टेलर

@ डेवी 8 ओह, यदि किसी गेम की केवल व्यावसायिक सफलता आनुपातिक है तो यह कितना मजेदार है। :)

— दस

Answer 3

मुझे नहीं लगता कि गेम प्रोग्रामिंग अन्य एप्लिकेशन डोमेन की तुलना में किसी भी तरह से अलग है, यह चिंताओं के सही पृथक्करण को लेने के लिए कठिन है। जब भी आप अपने कौशल को एक अलग प्रकार के एप्लिकेशन डोमेन पर ले जाते हैं, तो आप पाते हैं कि संक्रमण उतना सुचारू नहीं है जितना कि आप उम्मीद कर सकते हैं क्योंकि हमेशा मतभेद होते हैं। आपके डेटाबेस एप्लिकेशन में काम करने वाले कई पैटर्न / मुहावरे हैं जो आपके एम्बेडेड एप्लिकेशन में इतनी अच्छी तरह से काम नहीं करते हैं, जिसमें कई पैटर्न / मुहावरे हैं जो उस वास्तविक समय प्रणाली में इतनी अच्छी तरह से काम नहीं करते हैं जिसमें कई पैटर्न / मुहावरे भी हैं गेम प्रोग्रामिंग में काम न करें। हालाँकि, गेम प्रोग्रामर को एक ही समस्या होती है जब वे अपने गेम प्रोग्रामिंग डोमेन को छोड़ देते हैं। यह सब बस एक बात है कि आप क्या करने के आदी हैं।

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

Answer 4

और एक चीज जो मैंने इस विशेष परियोजना के साथ पाई है, वह यह है कि चिंताओं का पृथक्करण बहुत कठिन है क्योंकि सब कुछ राज्य को प्रभावित करता है, और हर वस्तु हर दूसरे ऑब्जेक्ट के साथ असंख्य तरीकों से बातचीत कर सकती है।

मुझे लगता है कि आपके पास वहां एक उत्तर है, बहुत सारे इंटरैक्शन हैं। मैंने XNA (C #) के साथ कुछ गेम बनाए, अब आप एक मिड-साइज़ गेम कर रहे हैं, जैसा कि आप कहते हैं, एक स्ट्रेटजी-सिमुलेशन गेम, अब लगभग 2 महीने से इस पर काम कर रहा है, और बिना किसी की मदद से इसे अकेले कर रहा हूँ, इसलिए मेरे कोड को सरल रखना चाहिए। एक बड़ा अंतर मुझे लगता है, कार्यक्षमता के लिए कुछ वर्गों को समझना और डिजाइन करना है, और ड्राइंग के लिए अन्य, यह आपके प्रोग्राम को क्लीनर बनाने और बनाने में मदद करता है। बेशक, यदि आप एक खेल कर रहे हैं, तो आपके पास अधिक संसाधन होने चाहिए, जैसे कि छवियां (2 डी या 3 डी) और संगीत (या ध्वनियां)। इसलिए मतभेद हैं, मुझे लगता है कि यह कठिन है, लेकिन यह बहुत मज़ेदार है।

Answer 5

मुझे लगता है कि गेम प्रोग्रामिंग अधिक मजेदार है। आप लगातार अपने खेल का परीक्षण कर सकते हैं, आप अलग-अलग भौतिकी को लागू करते हैं, जिसके परिणामस्वरूप विभिन्न व्यवहार होते हैं।

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

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

PS: मैं सॉफ़्टवेयर डेवलपमेंट, HTML5, Asp.Net, C #, आदि के लिए नवीनतम टूल का उपयोग करता हूं। मुझे अभी भी डायरेक्टएक्स, यूडीके, एक्सएनए, यूनिटी को कोड में अधिक मज़ा आता है।