एक खेल बनाने के लिए पुस्तकालयों, इंजनों और रूपरेखाओं का मूल्यांकन करते समय मुझे क्या विचार करना चाहिए?


10

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

मैं पहले से ही कुछ प्रोग्रामिंग भाषाओं के साथ बहुत अच्छा हूं, लेकिन कुछ अन्य भी हैं जिन्हें मैं बिल्कुल नहीं जानता। मैं नई प्रोग्रामिंग भाषा सीखने के खिलाफ नहीं हूँ, अगर वह मदद करेगा, लेकिन मेरा असली लक्ष्य सिर्फ अपना खेल बनाना है।

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


11
इसके लायक क्या है, मैं एक दो कदम दृष्टिकोण का उपयोग करता हूं: (1) एक मनमाना उठाओ; (२) बाद में निर्णय पर पछतावा। फायदा यह है कि यह आपको पहला कदम जल्दी से आगे बढ़ा देता है।
कैमरन फ्रेडमैन

2
यह एक सामुदायिक विकी सवाल नहीं होना चाहिए?
मार्टन

मैं इसके लिए कम्यूनिटी विकी के सवाल पर खुश हूं, लेकिन ऐसा करने के लिए मेरे पास कोई विकल्प उपलब्ध नहीं है। मेरा मानना ​​है कि सवालों पर सीडब्ल्यू एक मध्यस्थ है-केवल एक चीज है, इन दिनों।
ट्रेवर पॉवेल

@ मार्टन आपको क्या लगता है कि यह एक सीडब्ल्यू होना चाहिए?
MichaelHouse

1
@ बाइट 56 क्योंकि यह सवाल हमेशा सामने आता है, जब कोई खेल विकास शुरू करना चाहता है। वहाँ पहले से ही बहुत सारे ढांचे / इंजन हैं, और इस तरह के एक सामान्य "क्या विचार करना है" विकी प्रविष्टि वास्तव में सहायक होगी। मुझे लगता है कि यह कई "किस इंजन का उपयोग करना चाहिए" मैं इस साइट पर दिखाई देने वाले प्रश्नों का उत्तर दूंगा। बाद के वाक्यांशों को वास्तव में इस तरह के प्रश्न 'रचनात्मक नहीं' बनाते हैं।
मार्टन

जवाबों:


14

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

  1. उन सुविधाओं की एक सूची बनाएं, जिनमें आपकी रुचि है। यानी 2D / 3D समर्थन, प्रकाश, भौतिकी, एक ऐसी भाषा का उपयोग करता है जिसे आप अच्छी तरह जानते हैं, आदि।
  2. अपनी वर्तमान परियोजना के आधार पर, उन्हें आपके लिए महत्व के आधार पर रैंक करें।
  3. अपने विकल्पों पर शोध करें और प्रत्येक विकल्प के लिए, अपने प्रोजेक्ट लक्ष्यों के साथ संरेखित करने के आधार पर उनकी सहायता सुविधाओं को रैंक करने का प्रयास करें।
  4. उस एक का उपयोग करें जो आपके लक्ष्यों के साथ सबसे अच्छा मेल खाता है। वैकल्पिक रूप से आप शीर्ष कुछ का चयन कर सकते हैं और उन्हें टेस्ट ड्राइव दे सकते हैं। अपने खेल की कुछ सरल विशेषता को लागू करें और देखें कि आपको कौन सा अधिक पसंद है।

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


3

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

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

यदि आप केवल विंडोज के लिए जा रहे हैं, तो डायरेक्टएक्स और सी # आधारित लाइब्रेरी मजबूत उम्मीदवार हैं। यदि आप मल्टीप्लायर बनना चाहते हैं तो आप ओपनजीएल और सी / सी ++ के आधार पर पुस्तकालयों को देखना चाहेंगे या यदि आपका गेम 2 डी है और आप एडोब के टूल का उपयोग कर सकते हैं। आपके मंच की तरह, आपकी प्रोग्रामिंग भाषा आपके उपलब्ध पुस्तकालयों को प्रभावित करेगी। C ++ में लिखे गए प्रोग्राम में जावा लाइब्रेरी को कॉल करने में मुश्किल समय होगा।

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

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

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


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

1

गेम-विशिष्ट सुविधाओं के अलावा जिन पर लोगों ने टिप्पणी की है, आपको कुछ सामान्य प्रश्नों पर भी विचार करना चाहिए।

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

0

पुस्तकालयों, चौखटों, इंजनों और एसडीके का मूल्यांकन करने और सर्वश्रेष्ठ चुनने के लिए एक छोटा धोखा पत्र

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

इसलिए इससे पहले कि आप मूल्यांकन करना शुरू कर दें, आपको स्पष्ट होना चाहिए कि आप किस परिदृश्य में हैं और आपके पास कौन सी आवश्यकताएं हैं / होना चाहते हैं क्योंकि यह ऐसे प्रश्न हैं जिनका उत्तर मूल्यांकन द्वारा दिया जाना चाहिए।

परिदृश्य परिभाषित करता है कि आवश्यकताएं कहां से आती हैं (कौन तय करता है कि क्या आवश्यकता है और क्या नहीं)।


विशिष्ट परिदृश्य हैं:

हॉबीस्टेस्ट प्रोजेक्ट परिदृश्य

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

अंतर्निहित आवश्यकताएं यह होंगी कि आप कुछ विशिष्ट (एक भाषा, एक विशिष्ट ढांचा / इंजन) सीखना चाहते हैं

छात्र परिदृश्य

आवश्यकताएँ आपके शिक्षक से आ सकती हैं। उस मामले में मेरे पास विशिष्ट आवश्यकताएं हैं: खेल को कुछ भौतिक तत्वों और मल्टीप्लेयर नेटवर्क समर्थन की आवश्यकता है। या इसे C ++ में लिखना होगा। इसलिए मूल्यांकन करना आसान हो जाता है। आप एक गेम इंजन की तलाश में हैं जो आपको c ++ में कोड देता है और पहले से ही एक नेटवर्क और भौतिकी इंजन शामिल कर सकता है।

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

इंडी खेल परिदृश्य

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

क्या यह जावा गेम, एचटीएमएल 5 गेम, ....) की अनुमति देता है

क्या आपको विशिष्ट पुस्तकालयों को शामिल करने की आवश्यकता है (यदि हाँ, तो कौन सी भाषाएँ उन पुस्तकालयों में उपलब्ध हैं)

Google Playstore को आपको अपना गेम Android गेम के रूप में लिखना होगा, Apple AppStore को आपको अपने गेम को iOS ऐप के रूप में लिखना होगा। या आपके पास मल्टीप्लेट रिकॉर्डर इंजन लेने की आवश्यकता है।

पेशेवर परिदृश्य

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

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


मैं कैसे तय करूं कि मेरी आवश्यकताएं क्या हैं जब मैं एक शौक़ीन या इंडी हूं और कोई और मुझे नहीं बताता है?

अपने लक्ष्यों और अपने खेल के बारे में अपने स्वयं के प्रश्न पूछें?

  • मेरा खेल क्या होना चाहिए? मोबाइल, पीसी, वेब (html / जेएस), जो नियंत्रक मैं उपयोग करूंगा (टच स्क्रीन, जाइरोस्कोप, गेम पैड)

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

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

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

  • क्या मेरा लक्ष्य कुछ विशिष्ट सीखने का है? हाँ? आप क्या सीखना चाहते हैं?

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

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


इस तरह के सवालों का जवाब देना आपको आवश्यकताओं की ओर ले जाता है। मूल्यांकन उपकरण और परीक्षण की सूची पा रहा है (न केवल होमपेज को पढ़ने के लिए) उपकरण क्या प्रदान कर सकता है या नहीं कर सकता है।


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

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


0

यहाँ जाओ

गेम इंजनों की संख्या के बावजूद , आपके पास वास्तव में उतने विकल्प नहीं हैं।

  1. लाइसेंस प्रतिबंध। कुछ इंजन पहले बड़े लाइसेंस फीस भुगतान के बिना अपने उत्पाद को रिहा करने की आपकी क्षमता बाधित होगा, जैसे एकता , एक अतिरिक्त शुल्क के लिए इस्तेमाल किया आईओएस के लिए संकलित करने के लिए, उदाहरण के लिए (यह 2016 में बदल )
  2. प्लेटफार्मों। क्या आप कई प्लेटफार्मों को लक्षित करने के बारे में परवाह करते हैं? कौन सा?
  3. 2 डी या 3 डी? कुछ इंजन 2 डी को पूरा करते हैं।
  4. भौतिकी की आवश्यकता है? कुछ इंजन भौतिकी प्रदान करते हैं
  5. एफपीएस, आरटीएस? यह एक इंजन का उपयोग करने के लिए बुद्धिमान हो सकता है जो आपके द्वारा बनाए जा रहे गेम प्रकार के लिए विशिष्ट है।
  6. जाहिर है आप अपनी पसंदीदा भाषा में काम करना चाहेंगे। C पसंद नहीं है? तब Allegro का उपयोग न करें!
  7. क्या आप एक विशाल डिजाइन पैटर्न, ओओपी प्रशंसक हैं? अच्छी तरह से ज्ञात OGRE "अति प्रयोग" पैटर्न
  8. सक्रिय विकास? आपको ब्लीडिंग एज फीचर्स की उपलब्धता (DX11 / OGL 4) बनाम इंजन की स्थिरता के बीच विचार करना चाहिए, जिसका विकास कुछ साल पहले बंद हो गया था
  9. उपयोगकर्ता का आधार? एक बड़े उपयोगकर्ता आधार का मतलब आमतौर पर बेहतर मंचों से होता है, ताकि आपके सवालों का जवाब देना आसान हो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.