गेम इंजन का उपयोग करने से पहले दो बार सोचें

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

आइए समझदारी से तर्क करें

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

कौशल स्तर

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

यदि आपके पास न तो तकनीकी कौशल है और न ही उन्हें सीखने में रुचि है, तो वास्तव में कोई विकल्प नहीं है - आपको इंजन के साथ काम करना होगा (या किसी को आपके लिए तकनीकी भाग करने के लिए राजी करना होगा; इसके साथ शुभकामनाएं!)।

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

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

विकास के लक्ष्य

इस परियोजना में आपके लक्ष्य क्या हैं? प्रौद्योगिकी को अपनी उपलब्धि को अधिकतम करना चाहिए:

• यह आपके लिए एक शौक है और आप सभी को एक डेवलपर के रूप में विकसित करना चाहते हैं? शायद आपको एकता और अवास्तविक से दूर रहना चाहिए और निचले स्तर के पुस्तकालयों के आधार पर विकासशील खेलों की ओर देखना चाहिए।
• क्या यह आपके लिए एक व्यवसाय है? इस स्तर पर, चीजें बहुत अधिक जटिल हो जाती हैं। कई कारकों के आधार पर विकल्पों का मूल्यांकन किया जाना चाहिए: क्या आप तकनीक से परिचित लोगों को काम पर रख सकते हैं? क्या ये लोग तकनीक का उपयोग करना चाहते हैं? क्या यह आपके समय सीमा में फिट बैठता है? क्या आपके पास इसे प्रभावी ढंग से उपयोग करने का कौशल है? क्या आपके कलाकारों / डिजाइनरों को तकनीक पसंद है?

ब्याज

यदि आप अकेले डेवलपर्स की तुलना में अधिक काम (या काम करने की योजना) करते हैं, तो आपको यह मूल्यांकन करने की आवश्यकता है कि अन्य लोग प्रौद्योगिकी में कैसे रुचि रखते हैं। यदि आप एक पुराने इंजन / ढांचे के साथ काम करते हैं, जिससे हर कोई नफरत करता है, तो आपके लिए अपने प्रोजेक्ट के लिए प्रेरित डेवलपर्स को ढूंढना मुश्किल होगा।

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

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

वे वास्तव में आपको क्या देते हैं?

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

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

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

आपको प्रश्न पूछने की आवश्यकता है: "मुझे वास्तव में क्या चाहिए?" हर चीज को बेवजह निकालो। हर अनावश्यक व्यवस्था संसाधनों और समय को बर्बाद कर रही है।

आपके प्रोजेक्ट के लिए क्या आवश्यक है?

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

ऐसे सफल गेम हैं जो किसी भी उपलब्ध इंजन की खराब सेवा की सेवा करेंगे:

• ड्रीम्स के लिए , एक कस्टम रेंडर लिखा गया था जो 3 डी परिसंपत्तियों के सहज निर्माण को सरल और तेज करता है।
• नो मैन्स स्काई पूरी तरह से प्रक्रियात्मक पीढ़ी के नए तरीकों का सक्रिय रूप से उपयोग कर रहा है। इंजन में ऐसी चीजों को लागू करते समय, आपको लगातार इससे निपटना होगा।
• Minecraft में , मानक इंजन की केवल कुछ सुविधाओं का उपयोग किया जा सकता है।

आपके (और हमारे) उद्योग का भविष्य

किसी भी तकनीक का उपयोग करते समय, यह बंद करने के बारे में सोचने योग्य है। जोएल स्पोलस्की के पास सॉफ्टवेयर विकास के लिए एक व्यापार रणनीति पर लेखों की एक श्रृंखला है, जिसमें वह उत्पाद पर बंद होने पर प्रतिबिंबित करता है। संक्षेप में, उनका विचार यह है कि कंपनियां आपको अपने उत्पाद का उपयोग करने में रुचि रखती हैं, क्योंकि यदि आप उत्पाद का उपयोग नहीं करते हैं, तो वे पैसा नहीं बनाते हैं। संपूर्ण उद्योगों पर कब्जा करने में परास्नातक हैं Apple, Microsoft, Adobe और Autodesk, वे यह महसूस करते हैं कि उनके सॉफ़्टवेयर के अलावा कोई अन्य विकल्प नहीं हैं।

समापन भी शौक / एकल डेवलपर्स को प्रभावित करता है। मेरे पास एक मित्र है जो निरंतर एकता (संगतता-ब्रेकिंग अपडेट, प्रोटोटाइप सिस्टम, एडवेयर, खराब 2D समर्थन ...) के साथ संघर्ष कर रहा है। वह एकता से दूर होना चाहता है, लेकिन इस इंजन में दृढ़ता से बंद है क्योंकि उसका अधिकांश कोड (और डेटा) यूनिटी एपीआई पर निर्भर करता है।

इंजन क्यों खरीदते हैं?

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

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

क्या नई सुविधाएँ वास्तव में आपके खेल को पूरा करना आसान बनाती हैं? क्या वे वास्तव में अंतिम उत्पाद के लिए मूल्य जोड़ते हैं?

केन्द्रीयकरण से लड़ो

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

यहां तक ​​कि शौक के स्तर पर, अवास्तविक या एकता के पक्ष में अनुसंधान को छोड़ देना इंजन की भावी पीढ़ियों को परेशान करता है। यह अवास्तविक को भी चोट पहुँचा सकता है: यदि हर कोई अवास्तविक का उपयोग करता है, तो एपिक किसी और को इंजन की नई पीढ़ी बनाने में सक्षम नहीं करेगा, क्योंकि कोई नहीं जानता होगा कि खेल इंजन कैसे लिखे जाते हैं!

भविष्य खुला स्रोत हो सकता है

यदि हम, एक उद्योग के रूप में, अधिक से अधिक उच्च गुणवत्ता वाले उत्पाद बनाना चाहते हैं, तो हमें प्रौद्योगिकियों को साझा करने के लिए अधिक नहीं, कम साझा करने की आवश्यकता है।

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

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

सॉफ्टवेयर की गुणवत्ता

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

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

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

विकल्प क्या हैं?

इंजन का उपयोग करने के बजाय, आप सिर्फ एक खेल लिख रहे हैं।

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

पुस्तकालयों का उपयोग करना

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

यहां कुछ लाइब्रेरी हैं जो स्क्रैच से काम करने और पूरी तरह से तैयार इंजन का उपयोग करने के बीच के अंतर को भर सकती हैं:

• ग्राफिक्स: एसडीएल, एसएफएमएल, ओग्रे
• भौतिकी: बुलेट, PhysX (जो हाल ही में खुला स्रोत बन गया है - एक बहुत बड़ी जीत!)
• साउंड: एसडीएल, एसएफएमएल

यह मौजूदा पुस्तकालयों का केवल एक छोटा सा अंश है।

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

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

निष्कर्ष में

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

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