एक गेम डेवलपर मौजूदा वाले का उपयोग करने के बजाय अपना इंजन क्यों लिखेगा?

41

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

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

game-industry business

— Pauld
स्रोत

1

संभावित डुप्लिकेट: gamedev.stackexchange.com/questions/12488/… और संबंधित: gamedev.stackexchange.com/questions/859/…

— माइकलहाउस

1

वे अन्य कंपनियों के खेल इंजनों और उन्हें भुगतान करने के लिए लाइसेंस नहीं देना चाहते हैं।

— जन्नोस तुरन्स्की

मुझे लगता है कि जब आप 9K + कर्मचारियों को चारों ओर बिछाते हैं तो आप क्या करते हैं ...

— glampert

3

बड़े स्टूडियो के कई काउंटर-उदाहरण हैं जो अवास्तविक या क्राय्वेज़िन जैसे 3 पार्टी इंजनों का उपयोग करके एएए खिताब बनाते हैं ।

— फिलिप

3

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

— नायरौ

53

कई कारण हैं कि एक स्टूडियो अपनी तकनीक को "खरीदने" के बजाय "बनाने" का चयन कर सकता है:

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

सामान्य तौर पर, यह आपके व्यवसाय की सफलता के लिए महत्वपूर्ण चीजों को स्वयं करने और नियंत्रित करने के लिए और उन लोगों को आउटसोर्स करने के लिए अच्छा अर्थ नहीं देता है।

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

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

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

— जोश
स्रोत

20

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

— स्काइलर

गंभीरता से, एकता कहती है "कोई जुआ खेल"? यहां तक कि वे अपनी वेबसाइट के कम्यूनिटी सेक्शन में जुए के बारे में एक विशिष्ट पेज भी रखते थे!

— झॉकिंग

एकता का पेज यहां unity3d.com/indenders/gambling कहता है कि आप "यूनिटी जुआ लाइसेंस" खरीद सकते हैं। मुझे इसके लिए कोई कीमत नहीं मिली है, लेकिन लगता है कि वे अभी भी आपको जुआ के लिए खेल बनाने की अनुमति देते हैं बशर्ते कि आप विशेष लाइसेंस के लिए भुगतान करें।

— एलेक्स 15

1

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

— दिमित्री

18

जोश पेट्री ने कहा :

" यहां सिंड्रोम नहीं बनाया गया है ?"

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

मैंने विभिन्न प्रकार के गेम इंजनों का परीक्षण किया, एपीआई प्रतिपादन और इस तरह, विशेष रूप से प्लॉब्स, UNITY WaveEngine, XNAFinalEngine, Love, Ogre, आदि .. कई और अधिक ... मैं खेल लिखना शुरू करना चाहता था - मैंने एक अच्छे आरामदायक की तलाश में बहुत कुछ डाउनलोड किया। और अच्छी तरह से प्रलेखित प्रवेश बिंदु ...

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

जो कि मैंने करना समाप्त कर दिया।

इसलिए मैंने XNA की स्थापना के लिए चुना क्योंकि मैं पहले से ही सी # जानता था, और यह सोचना शुरू कर दिया कि मुझे कैसे या कहां शुरू करना चाहिए। मुझे एक आइडिया चाहिए था।

मैंने फैसला किया कि, कोई बात नहीं, मैं सीधे 3 डी में जाऊंगा ।

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

मैंने Shader Based Instancing को लागू करने की एक नई यात्रा शुरू की (और जब मैं उस पर था तब HLSL सीखा), मैंने XNA के मॉडल और इफ़ेक्ट ऑब्जेक्ट्स में अपनी जगह बदलने के लिए बनाया। मुझे सबसे पहले VBO स्ट्रीम को समझने में परेशानी हुई; मैंने चीजों को तोड़ दिया - मैं ऑनलाइन सामान के बारे में सवाल पूछ रहा था और जब तक मैं अंत में समझ नहीं पाया कि GPU क्या कर रहा था। इसने भुगतान किया; अब मेरे पास बीस हज़ार से अधिक परीक्षण इकाइयाँ थीं, जो मेरे VBO को PIX (dxsdk) के साथ डिबग करने के कुछ दिनों के बाद अपने व्यूपोर्ट में ज़ूम कर रही थीं।

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

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

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

मैंने लगभग वह सब कुछ खींच लिया जो मैं चाहता था।

लेकिन अंत में - मैंने फैसला किया कि उसे नीचे रखने का समय आ गया है। जितना मैंने अपने आप को नेट, और अन्य gamedev मित्रों से सलाह के साथ अपने आप से इतना बड़ा इंजन लिखने से संतुष्ट किया, मैंने फैसला किया कि मैं इसे फिर से करने जा रहा हूं - और इसे बेहतर करूंगा - क्योंकि अब इस समय को मैं ज्यादातर जानता हूं मै क्या कर रही हूँ।

वह परियोजना अभी भी मेरे जीआईटी रेपो में टक टिकी हुई है।

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

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

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

— कोडी मॉर्गन
स्रोत

13

यह एक बहुत अधिक पढ़ता है जैसे कि एक व्यक्तिगत व्यक्तिगत किस्सा; आप शायद इसे अधिक संक्षिप्त बनाने के लिए इसे संपादित कर सकते हैं और यह बेहतर उत्तर देगा।

— जोश

2

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

— antont

मुझे इस बात की जानकारी है, बस हर काम जो मैंने किसी भी भाषा में किसी भी तरह का कोड शामिल किया है, मेरे लिए हमेशा से अकेला रहा है;

— कोडी मॉर्गन

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

— क्वांक्स

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

— मॉरिशी

15

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

यदि आपने एक बड़ा, जटिल खेल लिखा है, और इसमें एक क्रैश बग है, और आपके पास स्रोत कोड है (और इसे लिखे जाने के आधार पर उस स्रोत कोड से परिचित हैं), तो आप बस एक डिबगर संलग्न कर सकते हैं प्रक्रिया और पाते हैं कि दुर्घटना का कारण क्या है। किया हुआ।

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

खेल विकास कठिन है, लेकिन डिबगिंग कठिन परिमाण के आदेश हैं। मेरी पुस्तक में, कुछ भी जो खेल के विकास को कठिन बनाता है लेकिन डिबगिंग को आसान बनाना एक बहुत बड़ी जीत है।

— ट्रेवर पॉवेल
स्रोत

3

यह एक बड़ा उल्टा है जिसे हमने एक ओपन सोर्स इंजन (cocos2d-iphone) का उपयोग करके अनुभव किया है। हम इसे ठीक उसी तरह से डीबग कर सकते हैं जिस तरह से कोड हमने लिखा है। मुझे वास्तव में लगता है कि खुले स्रोत के बारे में सोचने का तरीका यह है कि यह आपका कोड है। वहाँ कीड़े हैं तो हम .., उन्हें ठीक करने के हमारे कोड के किसी अन्य भाग में की तरह होगा

— antont

1

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

— टिम

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

— ट्रेवर पॉवेल

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

— टिम

2

@ टिम आरईएम: "मिडलवेयर चीजों को आसान बनाता है", मेरे पास आपके मुकाबले बहुत अलग अनुभव थे, जाहिर है।

— ट्रेवर पॉवेल

9

यहाँ बहुत अच्छे उत्तर हैं, लेकिन वे एक महत्वपूर्ण अतिरिक्त बिंदु को याद कर रहे हैं।

आज के कई लाइसेंस वाले इंजन समर्पित इंजन के रूप में शुरू हुए ।

चलो अवास्तविक को एक उदाहरण के रूप में लेते हैं क्योंकि यह बहुत सर्वव्यापी है।

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

एक बार की बात है, अवास्तविक नाम का एक खेल था । इसके डेवलपर्स ने किसी मौजूदा लाइसेंस के बजाय अपने स्वयं के इंजन का निर्माण करने का निर्णय लिया । कई पुनरावृत्तियों के माध्यम से तेजी से आगे बढ़ना और वह इंजन अवास्तविक इंजन बन जाता है जिसे हम आज जानते हैं।

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

— मैक्सिमस मिनिमस
स्रोत

2

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

— joltmode

3

अन्य कारण हैं कि एक स्टूडियो अपनी तकनीक को "खरीदने" के बजाय "बनाने" का चयन कर सकता है:

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

मैं विशिष्ट अनुरोधों / आवश्यकताओं और इंजन मूल्य निर्धारण और लाइसेंस युद्धों के साथ कुछ स्टूडियो को रोल आउट करने के लिए कुछ स्टूडियो को मजबूर करता हूं।

अन्य इंजनों को "खरीदने" या "उपयोग" करने के अच्छे उद्देश्य हैं:

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

— पेड्रो पोलोनिया
स्रोत

2

ऐतिहासिक कारण (अधिकतर)।
जो मूल्य निर्धारण से संबंधित है।

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

लेकिन यह बदल गया। अब हर कोई बड़ा इंजन भी खरीद सकता है, जैसा कि प्राइस रेस शुरू हुआ।
इसका मतलब है...

आप UE4 और CryEngine दोनों का उपयोग करके बहुत अधिक गेम देखेंगे।
हालांकि, वे एएए खेल नहीं होंगे जैसे वे थे।
प्रत्येक प्रोजेक्ट के लिए कस्टम आवश्यकताएँ और आवश्यकताएँ दूर नहीं होंगी।
Relic पर Warhammer40k / COH इंजन देखें, या वह जो कि EA में उपयोग किया जाता है।
यहां तक कि अगर कोई भी बड़े इंजन का खर्च उठा सकता है, तो भी वे बेहतर विकल्प नहीं देते हैं।
बाजार में अन्य हैं। एकता की तरह।
लोग इसे आसानी से उपयोग करने, तेज़ प्रदर्शन और विशाल संपत्ति भंडार के लिए प्यार करते हैं।
बेशक, एकता लगभग किसी भी मंच पर तैनात करने में सक्षम है।

तो हाँ। जरूरत है, अतीत में मूल्य निर्धारण और ऐसी।

— अमरीका की एक मूल जनजाति
स्रोत

1

मैं हॉक को "भारी संशोधित" नहीं कहूंगा।

— जोश

क्या हॉक सिर्फ एक भौतिकी इंजन नहीं है?

— फिलीपींस

यह है, और GW2 ने इस पर ज्यादा ध्यान नहीं दिया कि मैं याद कर सकता हूं।

— जोश

क्या आपका मतलब नहीं है (ie.: you want UE, not UDK only.)?

— केवॉन

#JoshPetrie: क्षमा करें, ईमानदार होने के लिए मैं हॉक में अनुभवी नहीं हूं / इसके साथ कभी नहीं खेला गया। इसलिए मैंने GW2 की LICENSE फ़ाइल पर ठोकर खाई और फिर कुछ दिन पहले विकी पेज पर गया और हॉक को देखा। फिर मुझे एक गेम की शुरुआत में "हॉक" देखने के बारे में कुछ पुरानी याद थी, जहां मैंने सोचा था कि इंजन है। लेकिन तब मैंने भी हॉक को वापस देखा और मुझे पता था कि यह एक भौतिकी इंजन है। tl; dr: मैंने चीजों को हॉक के बारे में मिलाया। || # फिलीप: यह थोड़ा अधिक है, लेकिन वास्तव में यह गेम इंजन नहीं है, मेरा बुरा है। || # शेवन: सही, तय। धन्यवाद!

— अपाचे

0

टीम संगठन के बारे में क्या?

डिबग सामान के पीछे दस्तावेज़ीकरण और समर्थन हैं, कोई कोड नहीं, क्योंकि अंत में मैं नहीं चाहता था कि मेरा भवन समूह अपने स्वयं के इंजन के कोड को स्पर्श करेगा। वह गड़बड़ हो सकता है।

इसलिए, मुझे ऐसा करने के लिए एक सहायता समूह की आवश्यकता है। लेकिन इससे लागत बढ़ती है: अधिक लोग, अधिक स्थान, अधिक लाइन फोन, अधिक प्रशासन ...

इसका एक समाधान आउटसोर्स हो सकता है ... एक मिडलवेयर कंपनी को, जो खेल और रचनात्मक समूह और लेखकों को बनाने के मेरे व्यवसाय के लिए संसाधनों को जारी करता है।

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

— 0zkr पी.एम.
स्रोत

0

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

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

— Killer_B
स्रोत

0

मेरा उत्तर मौजूदा वाले से अलग है, इसलिए मैं इसे जोड़ता हूं, हालांकि यह देर हो चुकी है:

यदि आप प्रश्न से वाल्व का उदाहरण लेते हैं, या इस Witcher श्रृंखला की प्रक्रिया थी:

एक इंजन का लाइसेंस
अपने उद्देश्य के लिए इंजन को संशोधित / अनुकूलित करें
खेल जारी करें और पैसे उत्पन्न करें
अगले गेम के लिए खुद का इंजन बनाएं

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

— पीटर
स्रोत

-2

मेरे प्रोग्रामिंग शिक्षक ने हमें बताया, केवल एपीआई / विधियों / वर्गों / कार्यों का उपयोग करें जिन्हें आप जानते हैं कि कैसे निर्माण करना है

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

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

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

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

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

वैसे भी मुझे आशा है कि मैंने स्पष्ट कर दिया है कि मैं क्या इंगित करना चाह रहा था

— thingybingytie
स्रोत

6

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

— concept3d

2

क्या आपके शिक्षक को पता है कि खरोंच से रासायनिक तत्वों से एक पूरी कार कैसे बनाई जाए? या वह ड्राइव करता है यह मानते हुए कि यह सिर्फ काम करता है ;-)

— क्रॉम्स्टर कहते हैं कि

1

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

— thingybingytie

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

— कॉन्सेप्ट

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

— Aidiakapi