खेल के विकास के लिए जावा का अधिक व्यापक रूप से उपयोग क्यों नहीं किया जाता है? [बन्द है]

77

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

जावा में खेल डेवलपर्स की कमी
अच्छे खेल विकास ढांचे का अभाव
प्रोग्रामर जावा को खेल प्रोग्रामिंग भाषा के रूप में स्वीकार नहीं करना चाहते हैं। अधिकांश केवल C ++ को ही स्वीकार करते हैं?
गेम कंसोल के लिए कोई समर्थन नहीं (हालांकि पीसी बाजार अभी भी मौजूद है)

यह निश्चित रूप से कुछ और हो सकता है। कोई है जो मेरे से बेहतर व्यवसाय जानता है समझा सकता है कि खेल के विकास की बात क्यों नहीं हो रही है?

java game-development

— Anto
स्रोत

37

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

— एड एस।

20

वास्तव में, जावा का उपयोग खेल विकास के लिए किया जाता है; यानी मोबाइल बाजार में। जावा एमई, एंड्रॉइड।

— user281377

21

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

— 222

14

दिलचस्प है, Minecraft जावा आधारित है।

— उरई

5

@ कोडर लगता है कि C ++ कोड बहुत अधिक अनुकूलित था, लेकिन जावा कोड नहीं था। तो यह एक अवैध तुलना है।

— इज़्काता

94

कई कारण:

पुराने दिनों में, आपको प्रदर्शन और UI के लिए "सीधी पहुंच" की आवश्यकता थी। यह जावा और सी # जैसी वीएम भाषाओं को पूर्व निर्धारित करता है।
अधिकांश कंसोल (जैसे, 360, PS3) में JVM नहीं है, इसलिए आप पीसी संस्करण से कोड का पुन: उपयोग नहीं कर सकते। विभिन्न उपकरणों का समर्थन करने के लिए C ++ कोड को संकलित करना बहुत आसान है।
अधिकांश मुख्यधारा के खेल इंजन (जैसे, असत्य) में C ++ बाइंडिंग है। कुछ जावा कनेक्टर हैं (जैसे, ओपनजीएल के लिए) लेकिन ऐसा कुछ भी नहीं है।
पीसी गेमिंग के लिए, डायरेक्टएक्स में वास्तव में मजबूत जावा समर्थन नहीं है (यदि बिल्कुल भी)।
वेब आधारित खेल जावास्क्रिप्ट या फ़्लैश में चलते हैं। आप उन्हें GWT जैसी चीजों का उपयोग करते हुए जावा में लिख सकते हैं।
IPhone एक उद्देश्य-सी संस्करण चलाता है।

जावा मुख्य रूप से इन दिनों एंड्रॉइड गेम्स में उपयोग किया जाता है, बस इसलिए कि यह उस प्लेटफॉर्म के लिए प्राथमिक भाषा है।

— उड़ी
स्रोत

14

+1 "अधिकांश कंसोल (जैसे, 360, PS3) में JVM नहीं है, इसलिए आप पीसी संस्करण से कोड का पुन: उपयोग नहीं कर सकते। विभिन्न उपकरणों का समर्थन करने के लिए C ++ कोड को संकलित करना बहुत आसान है" यदि डिवाइस में रनटाइम नहीं है। , आप उस अनुपलब्ध रनटाइम के आधार पर विकसित गेम नहीं देखेंगे। Xbox 360 और Windows फ़ोन ने .Net रनटाइम को प्रबंधित किया है, इसलिए उनका उपयोग करके गेम डेवलपमेंट संभव है, और एक बढ़ती प्रवृत्ति की संभावना है। हालाँकि, क्योंकि रनटाइम अन्य प्रमुख प्लेटफार्मों (PS3, और बहुत कम हद तक, Wii) पर नहीं है, इसकी पूरी तरह से अलग कोडबेस को सही ठहराना मुश्किल है। यह वास्तव में एक प्रदर्शन मुद्दा नहीं है।

— जस्टिनसी

2

इसे XNA कहा जाता है, जो वर्तमान में .net 2.0 ढांचे का सबसेट है। जंगली में कुछ अन्य दिलचस्प रूपरेखाएँ हैं: मोनोएक्सएनए, मोनोऑच, और अन्य के बीच एक्सनाटच।

— जस्टिन

7

JVM के साथ प्रदर्शन की संभावना संभव नहीं है।

— कुलेम

5

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

— deadalnix

2

@ यह भी संभव नहीं है mallocया इसके साथ new, इसलिए यदि आप एक चिंता का विषय है जिसे लागू करने जा रहे हैं, तो कोई बात नहीं। उस बिंदु से संबंधित, जावा के साथ एक बड़ा मुद्दा यह है कि यह C # के विपरीत मूल्य प्रकारों का समर्थन नहीं करता है।

— डोभाल

80

तकनीकी कारण:

अधिकांश सर्वश्रेष्ठ 3D गेम इंजन C / C ++ में लिखे गए हैं। यह एक बड़ी बात है, क्योंकि अधिकांश गेम डेवलपर्स अपने 3 डी इंजन से समझौता नहीं करना चाहते हैं, लेकिन न ही वे स्क्रैच से एक लिखना चाहते हैं। जावा में jMonkeyEngine है जो खुला स्रोत है और वास्तव में वास्तव में अच्छा है लेकिन यह अभी भी अवास्तविक इंजन के साथ प्रतिस्पर्धा नहीं कर सकता है ।
कुछ बहुत ही दुर्लभ स्थिति के लिए, सी या असेंबली भाषा में "धातु के करीब" होने में फायदे हैं, विशेष रूप से विशेष हार्डवेयर सुविधाओं तक पहुंच के लिए। यह आजकल इतना महत्वपूर्ण नहीं है, लेकिन पेशेवर गेम डेवलपर्स अभी भी विकल्प पसंद करते हैं .....
जावा में एक कचरा एकत्र , प्रबंधित रनटाइम है। 99% यह एक बहुत बड़ा फायदा है, यह निश्चित रूप से कोडिंग को आसान और कम त्रुटि वाला बनाता है और जावा के इतने लोकप्रिय होने का एक बड़ा कारण है। लेकिन यह के रूप में कचरा संग्रहण चक्र खेल के लिए एक सामयिक विलंबता मुद्दे का कारण नहीं है सकते हैं ध्यान देने योग्य रुक जाता है हो सकता है। यह नए लो-लेटेंसी JVM के साथ एक इश्यू से कम हो रहा है, लेकिन अभी भी ग्राफिक रूप से गहन गेम के लिए एक मुद्दा है जहां उच्च एफपीएस बनाए रखना महत्वपूर्ण है।

गैर-तकनीकी कारण:

व्यावसायिक खेल विकास घर सी / सी ++ कौशल और प्रौद्योगिकियों में भारी निवेश किए जाते हैं। इससे भारी मात्रा में जड़ता पैदा होती है ।
काफी हद तक तर्कहीन धारणा है कि जावा धीमा है। संभवतः 90 के दशक में सच है, निश्चित रूप से अब सच नहीं है - आप निश्चित रूप से जावा के साथ एक लाभदायक, वाणिज्यिक 3 डी गेम लिख सकते हैं ( किसी को भी रेकस्केप ? या कैसे Minecraft के बारे में ?)
एक सुंदर निष्पक्ष धारणा है कि जावा व्यापार अनुप्रयोगों और गेमिंग के बजाय वेब पर अधिक केंद्रित है। यह मोबाइल के विकास और अधिक क्रॉस-प्लेटफॉर्म विकास की आवश्यकता के साथ बदल सकता है, लेकिन वर्तमान में निश्चित रूप से सच है।

दिलचस्प बात यह है कि कुछ अच्छे कारण भी हैं कि खेल डेवलपर्स को जावा पर विचार करना चाहिए :

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

— mikera
स्रोत

19

नहीं, वीडियो गेम की दुनिया में जावा में प्रोटेबिलिटी बेहतर नहीं है। अधिकांश कंसोल में JVM नहीं है। पोर्टेबिलिटी कारणों के लिए, C ++ को वीडियो गेम की दुनिया में जावा के लिए पसंद किया जाता है।

— deadalnix

5

लाइब्रेरी इकोसिस्टम जावा के लिए एक बोनस क्यों है? नेटवर्किंग, ध्वनि, कुंजी-मूल्य जोड़े - यह कोई बात नहीं है; यह आजकल हर जगह उपलब्ध है। मैं वास्तव में तर्क दूंगा कि एआई और छवि प्रसंस्करण सी / सी ++ पुस्तकालयों (फैन, ओपनसीवी) के साथ बहुत आसान है।

— मिरोक्स

4

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

— गैंकरो

1

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

— गौसेज

1

@deadalnix वीडियो गेम की दुनिया केवल कंसोल से बनी नहीं है।

— गौसेज

27

ठीक है, इस धागे में बहुत गलत जानकारी है।

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

कम्प्यूटेशनल गति के संदर्भ में, जावा आज कई वैज्ञानिक कंप्यूटिंग बेंचमार्क में C ++ को हरा देता है। आप किसी भी भाषा में पैथोलॉजिकल कोड लिख सकते हैं जो आप चाहते हैं तो बुरी तरह से प्रदर्शन करता है, लेकिन ओवर ऑल, वे बराबर हैं और लंबे समय से हैं।

स्मृति उपयोग के संदर्भ में, जावा में कुछ अधिक-प्रमुख हैं। हैलोवर्ल्ड जावा में एक 4K प्रोग्राम है। लेकिन यह ओवरहेड आज के मल्टी जीबी सिस्टम में बहुत अर्थहीन है। अंत में, Java के पास स्टार्टअप समय अधिक है। मैं यूनिक्स कमांड लाइन कमांड जैसी छोटी रन-टाइम उपयोगिताओं के लिए जावा का उपयोग करने की अनुशंसा नहीं करूंगा। उन मामलों में स्टार्टअप आपके प्रदर्शन पर हावी रहेगा। एक खेल में, हालांकि, इसकी काफी ढीठ है।

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

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

जबकि इसके असली जावा में Direct3D बाइंडिंग कभी नहीं थी, इसलिए जावा टेक्नोलॉजी पोर्टेबिलिटी के लिए प्रयास करती है। इसमें TWO OpenGL बाइंडिंग (JOGL और LWJGL) और OpenAL बाइंडिंग (JOAL) और एक पोर्टेबल इनपुट बाइंडिंग (JInput) है, जो विंडोज पर DirectInput, OSX पर HID मैनेजर, और एक Linux बाइंडिंग (I भूल जाते हैं) को बांधता है।

यह सच है कि किसी भी पूर्ण गेम इंजन ने जावा को नहीं दिखाया है, एकता कहते हैं, सी # को चित्रित किया है और यह स्वतंत्र स्थान में एक कमजोरी है। दूसरी ओर, दो अच्छे दृश्य स्तर APIS थे जो विंडोज, OSX और लिनक्स में पूरी तरह से मंच पोर्टेबल थे। दोनों को जोश स्लैक द्वारा लिखा गया था, पहला JMonkey इंजन और दूसरा आर्दोर 3 डी कहलाता था।

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

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

और यही कारण है कि मैं आज सी # में गेम कोड करता हूं। क्योंकि मोनो प्रबंधन के लिए मना कर दिया गया था।

— रेव्ह यूजर 430788
स्रोत

8

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

सीमा जाँच और अन्य सुरक्षा तंत्र (सीमांत प्रदर्शन अंतर इन दिनों)
C ++ डेटा स्ट्रक्चर्स और जावा डेटा स्ट्रक्चर्स के बीच कनवर्ट करना (केवल बफ़र्स के बीच मेमोरी कॉपी नहीं कर सकते)
कई किताबें और ट्यूटोरियल भीड़ का अनुसरण करते हैं, इसलिए गैर-सी ++ गेम देव जानकारी प्राप्त करना कठिन है
कोर ग्राफिक्स लाइब्रेरी (DirectX और OpenGL) और कई ऑफ-द-शेल्फ इंजन C / C ++ आधारित हैं
बहुत से खेल उतनी ही तेजी से चलने की कोशिश करते हैं, ताकि वे अधिक नेत्रहीन सुविधाओं को जोड़ सकें

जावा (जैसे एक जेएनआई परत लिखना) और .net (बहुत सारे मार्शलिंग / अनमरशलिंग, एपीआई / स्ट्रक्चर एट्रिब्यूट्स) जैसे बायटेकोड भाषाओं से सी ++ पुस्तकालयों के साथ काम करना आसान नहीं है। तो यह थोड़ा लाभ के लिए काफी काम जोड़ता है।

एक साइड नोट: कुछ गेम सर्वर जावा का उपयोग करते हैं।

ऐसी ही पोस्ट यहाँ : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

— ग्रीम विकस्टेड को दर्शाता है
स्रोत

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

— गौसेज

अच्छी बात। मैंने जावा में JOGL और JMonkeyEngine का उपयोग किया है। I में अधिक रिकेन्टीटी ने XNA / MonoGame का उपयोग DirectX और OpenTK के लिए OpenGL के साथ nvorbis / naudio / Openal के साथ C # में किया है। और वे छोटे से मध्यम आकार के खेल के लिए विशेष रूप से काम करते हैं, खासकर जब shaders के साथ काम करते हैं। C ++ पर उत्पादकता में बड़ा सुधार। फिर आपकी एकमात्र वास्तविक समस्या किसी भी जीसी-आधारित भाषा के समान है: जीसी को रोकना / कम करना। यह आपके फ्रैमरेट को समय-समय पर रोक देगा ताकि आप निश्चित आकार के ऐरे, स्थिर आवंटन या लंबे समय तक जीवित रहने वाले बफ़र्स चाहते हैं जो कि गेमप्ले (मेनू, लोडिंग, सिनेमैटिक्स) के बंद होने पर उछाले जा सकते हैं।

— ग्रीम विकस्टेड

मैंने 2006 से JOGL का उपयोग किया है और मुझे डेस्कटॉप वातावरण में बहुत कम अंत हार्डवेयर पर भी इस तरह की समस्या नहीं है। कचरा इकट्ठा करने वाले को दोष नहीं दिया जाता है क्योंकि सबसे बड़ी वस्तुएं या तो अक्सर GPU रैम में होती हैं या देशी ढेर में (आमतौर पर प्रत्यक्ष NIO बफ़र्स), पूर्व को "सामान्य" कचरा संग्रह और बाद वाले एरे द्वारा प्रबंधित नहीं किया जाता है ' टी सीधे "सामान्य" कचरा संग्रह द्वारा प्रबंधित किया जाता है क्योंकि यह जावा हीप पर जावा ऑब्जेक्ट्स की देखभाल करता है। यह डेवलपर पर निर्भर है कि वह देशी हीप पर आवंटित मेमोरी को कुशलतापूर्वक जारी करे।

— गौसिज

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

— गौसिज

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

— गौसेज १५'१ou

5

जावा अधिकांश गेम विकास के लिए पर्याप्त तेज़ नहीं है। यह सी ++ / असेंबली का उपयोग करने की तुलना में बहुत धीमा है, जो मानक है। यही कारण है कि अधिक खेल विकास C # या VB का उपयोग नहीं किया जाता है। गेम डेवलपर्स को हर अंतिम घड़ी चक्र की आवश्यकता होती है और योजना बनाते हैं कि वे भौतिकी गणना, एआई तर्क, और पर्यावरण इंटरैक्शन जैसी चीजों के लिए अपना हाथ पा सकते हैं।

सरल गेम के लिए, जावा का उपयोग काफी प्रभावी ढंग से किया जा सकता है। यदि आप एक Tetris क्लोन या Bejeweled, या विस्तार के उस स्तर के कुछ और बनाना चाहते हैं, तो जावा ठीक काम करेगा। लेकिन जावा संभवत: हेलो, मेडल ऑफ ऑनर, कमांड एंड कॉनकेर जैसे गेम नहीं बना सकता है और आगे भी इसे खेलने योग्य बना सकता है। कम से कम जैसा कि आजकल है।

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

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

— BBlake
स्रोत

17

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

— एड एस।

15

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

— BBlake

12

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

— बिट-टिड्डर

10

स्मृति उपयोग को न भूलें। मेमोरी का उपयोग संभवतः गति से अधिक महत्वपूर्ण है। जावा को C ++ की तरह डायरेक्ट मेमोरी कंट्रोल के लिए डिज़ाइन नहीं किया गया है और कचरा संग्रहकर्ता का मतलब है कि मेमोरी का उपयोग हमेशा समान कार्य के लिए C ++ से काफी अधिक है।

— मैथ्यू पढ़े

9

यह 1985 नहीं है। हमारे पास 640k से अधिक मेमोरी है, 50 mghz प्रोसेसर से बेहतर है, और 1.44 एमबी से अधिक रिमूवल स्टोरेज है। गेम डेवलपर्स चुनौती आज वैसी नहीं है जैसी 25 साल पहले थी। आगे बढ़ो और एक आधुनिक गेम के लिए हाथ से तैयार किए गए x86 / या ia64 कोड का उदाहरण ढूंढें। कुछ मिथक सीधे सादे गलत हैं। चुनौती पोर्टेबिलिटी है, और अपेक्षाकृत प्राचीन ऑपरेटिंग वातावरण का उपयोग करते हुए नीचे स्तर के ग्राहक हैं। आम संप्रदाय बनाम सम्मोहक विसर्जन।

— जस्टिन

5

आधुनिक गेम सभी 3 डी ग्राफिक्स विशेष प्रयोजन हार्डवेयर में हो रहे हैं।

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

http://java.coe.psu.ac.th/FreeOnline/Evaluating%20Java%20for%20Game%20Development.pdf

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

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

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

— user1249
स्रोत

1

oddlabs.com/technology.php - "हमने LWJGL और Java के संयोजन पर अपना विकास आधारित किया है, जो खेल को संशोधनों के बिना और प्लेटफ़ॉर्म-निर्भर मूल कोड के बराबर गति पर किसी भी LWJGL समर्थित प्लेटफ़ॉर्म पर चलने की अनुमति देता है।"

Jake2 ने 10 साल पहले Quake2 से बेहतर प्रदर्शन किया। हम अब 2002 में नहीं रहे हैं।

— gouessej

4

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

— dan_waterworth
स्रोत

4

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

मैं एक पल के लिए दूसरी दिशा से उसे देखूंगा। गेम इंजन विकसित करना (उदाहरण के लिए) बहुत काम है। ऐसा करने के लिए समय और प्रयास का निवेश करने से किसको पर्याप्त लाभ होगा?

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

लगभग एकमात्र उम्मीदवार जो मैं सोच सकता हूं कि ऐसा लगता है कि सभी उचित Google होंगे। एंड्रॉइड के लिए प्राथमिक विकास भाषा जावा है, और एंड्रॉइड के लिए खेल विकास को प्रोत्साहित करना प्लेटफॉर्म के लिए एक वास्तविक लाभ प्रदान कर सकता है।

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

— जेरी कॉफिन को दर्शाता है
स्रोत

मुझे लगता है कि आपने खेल इंजन के साथ एक महत्वपूर्ण मुद्दा मारा है - मुझे लगता है कि यह सबसे बड़ा कारण है कि जावा ने C / C ++ के साथ नहीं पकड़ा है। यह संभव है कि खुला स्रोत खेल के मैदान को थोड़ा सा बढ़ा सकता है - मैं jMonkeyEngine ( jmonkeyengine.com ) से बहुत प्रभावित हुआ हूं ।

— माइकेरा

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

— jwenting

1

सवाल कुछ की पंक्तियों में पूछने के बराबर है:

अपनी कार, एक नाव इंजन या जेट इंजन को बेहतर बनाने के लिए क्या बेहतर है।

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

— मेह
स्रोत

0

जावा को खेल के विकास को ध्यान में रखकर नहीं बनाया गया था, जावा को "वेब के लिए एक भाषा" बनाया गया था।

खेल के विकास के लिए, सूर्य वास्तव में जावा को गेम डेवलपमेंट लैंग्वेज के रूप में Microsoft समर्थित C # के रूप में समर्थन नहीं करता था।

मुझे लगता है कि सम्मोहक गेम डेवलपमेंट फ्रेमवर्क की कमी ने इस पहलू में वास्तव में जावा को मार दिया है।

— महमूद होसम
स्रोत

3

लेकिन C ++ को एक गेम लैंग्वेज के रूप में नहीं बनाया गया था, बल्कि एक सिस्टम प्रोग्रामिंग लैंग्वेज के रूप में C. और Sun की तरह वास्तव में Java पर एक गेम लैंग्वेज के रूप में कुछ प्रयास किया गया था, मुझे लगता है कि वे PS2 में जावा लाने के लिए Sony के साथ सहयोग कर रहे थे या कुछ, लेकिन ऐसा कभी नहीं हुआ ...

— Anto

1

@ फ़ोबिया: लेकिन इसे सिस्टम प्रोग्रामिंग के लिए डिज़ाइन किया गया था ।

— Anto

1

@Phobia: मैं कह रहा हूँ कि यह है एक सामान्य प्रयोजन प्रोग्रामिंग भाषा , बस सी की तरह ++। आपके जवाब में आप कहते हैं कि जावा को गेम प्रोग्रामिंग भाषा के रूप में नहीं बनाया गया था, लेकिन आप भूल जाते हैं कि सी ++ या तो डिज़ाइन नहीं किया गया है।

— Anto

2

@ जो ब्लो: सी के बारे में विकिपीडिया पृष्ठ से: "हालांकि सी को सिस्टम सॉफ्टवेयर को लागू करने के लिए डिज़ाइन किया गया था , लेकिन इसे व्यापक रूप से पोर्टेबल सॉफ्टवेयर सॉफ़्टवेयर के लिए भी उपयोग किया जाता है।" मुझे लगता है कि यह बहुत स्पष्ट है, है ना?

— Anto

2

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

— कोनराड रुडोल्फ

-1

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

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

— hotpaw2
स्रोत

-4

कुछ लोगों के लिए कारण गति, पुस्तकालयों या उपलब्धता से कोई लेना-देना नहीं है। यह केवल भाषा के कारण है। कुछ लोगों को बस जावा भाषा पसंद नहीं है। अन्य लोग गेम बनाने के लिए जावा का उपयोग करने के बजाय अपनी पसंदीदा प्रोग्रामिंग भाषा का उपयोग करेंगे।

— गूंज
स्रोत

यह एक टिप्पणी की तरह अधिक पढ़ता है, देखें कैसे उत्तर दें

— gnat

-8

यह निश्चित रूप से कुछ और हो सकता है। कोई है जो मेरे से बेहतर व्यवसाय जानता है समझा सकता है कि खेल के विकास की बात क्यों नहीं हो रही है?

यह एक व्याख्या भाषा है, अर्थात धीमी। आप ग्राफिक और ग्राफिक कार्ड के साथ काम कर रहे हैं जो हार्डवेयर है। हार्डवेयर से निपटने के लिए एक अच्छी भाषा क्या है? खैर सी ++, यह बहुत कम है, और आप संकेत और जो कुछ भी करते हैं।

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

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

— mythicalprogrammer
स्रोत

1

आपको जेआईटी संकलन के बारे में गंभीरता से पढ़ना चाहिए, और कुछ बेंचमार्क को देखना चाहिए, जहां जावा को C ++ के खिलाफ रखा गया है

— Anto

1

किसने इस जवाब को वोट दिया? यह पूरा सवाल अविश्वसनीय रूप से हास्यास्पद बन रहा है! सुखद दुख।

— फटी

7

@ जो जवाब गलत है। जावा की व्याख्या नहीं की गई है।

— कोनराड रूडोल्फ

3

@ उन मूर्ख बेंचमार्क को भूल जाओ। सी ++ है तेजी से जावा के अलावा जहां यह मायने रखता है, को देखने के परिमाण के आदेश programmers.stackexchange.com/questions/29109/29136#29136 और programmers.stackexchange.com/questions/368/13888#13888 ।

— कोनराड रुडोल्फ

1

@ कोई बात नहीं मैं क्या देख रहा हूँ? स्पीड? सी ++। स्मृति उपयोग? सी ++। मिनीक्राफ्ट को देखें और सर्वर को होस्ट करने का प्रयास करें और देखें कि गेम कितनी मेमोरी ले रहा है। जावा बहुत अधिक मेमोरी बनाम C ++ का उपभोग करता है। एक ऑनलाइन गेम बनाना, मुझे लगता है कि जावा में बहुत मुश्किल है। हर बेंचमार्क मैंने अब तक देखा है कि जावा अधिक मेमोरी का उपभोग करता है, अब एक mmorpg गेम है, जहां जावा में केंद्रीय सर्वर कोडित होता है, केवल तभी अच्छा लगता है जब आप मेमोरी पहलू को अनदेखा करते हैं या MMORPG में बड़े पैमाने पर परिभाषा बदलते हैं।

— पौराणिक