Mengapa Java tidak lebih banyak digunakan untuk pengembangan game? [Tutup]


77

Saya bukan pengembang game atau apa pun, tetapi saya tahu bahwa Java tidak terlalu banyak digunakan untuk pengembangan game. Java seharusnya cukup cepat untuk sebagian besar game, jadi di mana tangkapannya? Saya dapat memikirkan beberapa alasan:

  • Kurangnya pengembang game dengan keahlian di Jawa
  • Kurangnya kerangka pengembangan game yang bagus
  • Programmer tidak ingin menerima Java sebagai bahasa pemrograman game. Sebagian besar hanya menerima C ++ seperti itu?
  • Tidak ada dukungan untuk konsol game (meskipun pasar PC masih ada)

Tentu saja itu bisa menjadi sesuatu yang lain. Bisakah seseorang yang mengenal bisnis lebih baik dari saya menjelaskan mengapa Java tidak mendapatkan momentum dalam hal pengembangan game?


37
Dan sekarang tunggu semua jawaban "Java lambat, C ++ cepat" yang benar-benar hanya menyentuh permukaan masalah dengan cara yang terlalu luas dan sepenuhnya benar. Ketahuilah bahwa orang-orang yang menjawab cara ini hampir pasti bukan pengembang game profesional.
Ed S.

20
Bahkan, Java adalah digunakan untuk pengembangan game; yaitu di pasar ponsel. Java ME, Android.
user281377

21
Mengapa harus digunakan? Apa yang ditawarkan Java kepada pengembang game, yang tidak dimiliki oleh bahasa yang lebih banyak digunakan? Java menyediakan ekosistem yang sangat kaya bagi pengembang aplikasi bisnis, yang lebih besar daripada kekurangannya sebagai bahasa, tetapi ketika menyangkut pengembangan game, platform Java menawarkan sedikit alat dibandingkan dengan sejumlah alternatif.
back2dos

14
Menariknya, Minecraft berbasis Java.
Uri

5
@Coder Sepertinya kode C ++ sangat dioptimalkan, tetapi kode Java tidak. Jadi ini perbandingan yang tidak valid.
Izkata

Jawaban:


94

Beberapa alasan:

  • Di masa lalu, Anda memerlukan "akses langsung" untuk kinerja dan UI. Ini mendahului bahasa VM seperti Java dan C #.
  • Sebagian besar konsol (misalnya, 360, PS3) tidak memiliki JVM, jadi Anda tidak dapat menggunakan kembali kode dari versi PC. Jauh lebih mudah untuk mengkompilasi kode C ++ untuk mendukung berbagai perangkat.
  • Sebagian besar mesin permainan utama (mis., Unreal) memiliki binding C ++. Ada beberapa konektor Java (misalnya, untuk OpenGL) tetapi tidak ada yang seperti itu.
  • Untuk gaming PC, DirectX tidak benar-benar memiliki dukungan Java yang kuat (jika sama sekali).
  • Game berbasis web dijalankan dalam JavaScript atau Flash. Anda dapat menulisnya di Jawa meskipun menggunakan hal-hal seperti GWT.
  • IPhone menjalankan varian Objective-C.

Java terutama digunakan dalam permainan Android saat ini, hanya karena itu bahasa utama untuk platform itu.


14
+1 "Sebagian besar konsol (misalnya, 360, PS3) tidak memiliki JVM, jadi Anda tidak dapat menggunakan kembali kode dari versi PC. Lebih mudah untuk mengompilasi kode C ++ untuk mendukung berbagai perangkat" Jika perangkat tidak memiliki runtime , Anda tidak akan melihat game dikembangkan berdasarkan runtime yang tidak tersedia itu. Xbox 360 dan Windows phone telah berhasil mengelola runtime. Net, jadi pengembangan game menggunakan mereka mungkin, dan kemungkinan tren yang berkembang. Namun, karena runtime tidak ada pada platform utama lainnya (PS3, dan pada tingkat yang jauh lebih rendah, Wii), sulit untuk membenarkan basis kode yang sepenuhnya terpisah. Ini benar-benar bukan masalah kinerja sama sekali.
JustinC

2
Ini disebut XNA, yang saat ini merupakan bagian dari kerangka .Net 2.0. Ada beberapa kerangka kerja menarik lainnya di alam liar: MonoXNA, MonoTouch, dan XnaTouch.
JustinC

7
Prediktabilitas kinerja tidak dimungkinkan dengan JVM.
Klaim

5
Poin yang sangat bagus. Namun, saya akan menambahkan fakta bahwa GC dapat menyebabkan jeda / muat yang tidak terduga. Jika ini bukan masalah untuk aplikasi server, itu untuk permainan waktu nyata. Ini misalnya terlihat di minecraft.
deadalnix

2
@Klaim Ini juga tidak mungkin dengan mallocatau new, jadi jika itu masalah Anda akan menerapkan pengumpulan apa pun. Tidak terkait dengan titik itu, masalah besar dengan Java adalah bahwa ia tidak mendukung tipe nilai, tidak seperti C #.
Doval

80

Alasan teknis:

  • Sebagian besar mesin game 3D terbaik ditulis dalam C / C ++. Ini adalah masalah besar, karena sebagian besar pengembang game tidak ingin berkompromi pada mesin 3D mereka, tetapi mereka juga tidak ingin menulis satu pun dari awal. Java memiliki jMonkeyEngine yang merupakan open source dan sebenarnya sangat bagus tetapi masih belum bisa bersaing dengan Unreal Engine .
  • Untuk beberapa situasi yang sangat jarang, ada keuntungan dalam mendapatkan "dekat dengan logam" dalam bahasa C atau bahasa assembly, khusus untuk akses ke fitur perangkat keras khusus. Ini tidak begitu penting saat ini, tetapi pengembang game profesional masih suka memiliki opsi .....
  • Java memiliki sampah yang dikumpulkan , runtime yang dikelola. 99% dari waktu ini adalah keuntungan yang sangat besar, tentu saja membuat pengkodean lebih mudah dan lebih sedikit rawan kesalahan dan merupakan salah satu alasan utama mengapa Java begitu populer. Namun hal itu menyebabkan masalah latensi sesekali untuk game karena siklus pengumpulan sampah dapat menyebabkan jeda yang nyata. Ini semakin menjadi masalah dengan JVM low-latency yang lebih baru, tetapi masih menjadi masalah untuk game-game intensif grafis di mana mempertahankan FPS tinggi sangat penting.

Alasan non-teknis:

  • Rumah pengembangan game profesional sangat diinvestasikan dalam keterampilan dan teknologi C / C ++. Ini menciptakan inersia dalam jumlah besar .
  • Persepsi sebagian besar tidak rasional bahwa Jawa lambat. Mungkin benar di tahun 90-an, jelas tidak benar sekarang - Anda tentu bisa menulis game 3D komersial yang menguntungkan dengan Java ( Runescape, siapa? Atau bagaimana dengan Minecraft ?)
  • Persepsi yang cukup adil bahwa Java lebih fokus pada aplikasi bisnis dan web daripada game. Ini mungkin berubah seiring dengan pertumbuhan Mobile dan kebutuhan untuk pengembangan lintas-platform yang lebih banyak, tetapi sudah pasti saat ini.

Menariknya ada juga beberapa alasan bagus mengapa pengembang game harus mempertimbangkan Java:

  • Portabilitas - seiring dengan semakin banyaknya platform target, Java menjadi semakin menarik dengan kemampuannya yang tak tertandingi untuk menciptakan binari lintas platform yang benar-benar
  • Ekosistem perpustakaan - dengan pengecualian yang sangat penting dari mesin permainan 3D, Java memiliki jangkauan perpustakaan terbaik secara keseluruhan dari semua platform. Jaringan, suara, AI, pemrosesan gambar, penyimpanan data kunci / nilai, sebutkan topiknya dan mungkin ada perpustakaan Java sumber terbuka untuknya.
  • Pengembangan sisi server - Java adalah bahasa / platform yang hebat untuk server, dan karena semakin banyak game memasukkan elemen multi-pemain secara besar-besaran, sisi server akan menjadi semakin penting. Java di Linux terlihat sangat menarik di sini sebagai platform.
  • JVM - mungkin adalah lingkungan eksekusi VM terekayasa terbaik di dunia, dengan pengumpulan sampah yang fantastis, kompiler JIT, dukungan konkurensi, dll. Ini hanya akan menjadi lebih baik, dan seiring dengan semakin berkembangnya pengembang game mulai menggunakan bahasa dinamis dalam game mereka, mereka akan menginginkannya. lingkungan runtime terbaik.
  • Bahasa JVM lainnya - Jawa adalah pekerja keras yang solid, tetapi inovasi yang sebenarnya terjadi dengan bahasa JVM baru (Scala, Clojure khususnya). Bahasa-bahasa ini mendapatkan semua keuntungan dari platform Java / JVM, ditambah mereka adalah bahasa modern yang sangat kuat.

19
Tidak, protabilitas tidak lebih baik di Jawa di dunia video game. Kebanyakan konsol tidak memiliki JVM. Untuk alasan portabilitas, C ++ lebih disukai daripada java di dunia video game.
deadalnix

5
Mengapa ekosistem perpustakaan bonus untuk Java? Pasangan jaringan, suara, kunci-nilai - itu bukan sesuatu; itu tersedia di mana-mana saat ini. Saya sebenarnya berpendapat bahwa AI dan pemrosesan gambar jauh lebih mudah dilakukan dengan perpustakaan C / C ++ (fann, OpenCV).
MrFox

4
Lebih penting daripada FPS, saya mungkin akan menekankan frame rate yang konsisten . Saya dapat menjalankan game saya pada 100FPS, tetapi jika beberapa frame itu membutuhkan waktu setengah detik, itu tidak akan berhasil. Bahkan jika GC cepat, jika menyebabkan penyimpangan yang nyata, itu masih menjadi masalah. (Ini tidak berbicara apa-apa tentang kinerja Java secara khusus, hanya masalah umum yang perlu diingat)
Gankro

1
Saya menulis penembak orang pertama di Jawa dan saya tidak pernah memiliki masalah dengan pengumpul sampah bahkan ketika saya tidak menggunakannya dengan latensi rendah. Lagi pula, ketika memori tidak dialokasikan pada tumpukan Java, terserah saya untuk menghadapinya tanpa pengumpul sampah dan sebagian besar jejak memori saya berasal dari VBO. Dengan kata lain, pengumpulan sampah tidak menjadi masalah karena ia berfungsi ketika digunakan untuk apa yang dirancang untuk itu dan tidak terserah untuk menangani objek besar pada GPU atau pada heap asli (! = Java heap). Jangan salahkan landasan karena tidak menjadi sarana yang efisien untuk menyikat gigi.
gouessej

1
@deadalnix Dunia video game tidak hanya terdiri dari konsol.
gouessej

27

Oke, ada banyak informasi yang salah di utas ini.

Saya tahu bisnis game dengan sangat baik, telah berada di dalamnya selama 25 tahun. Saya juga mengenal Java dalam game dengan sangat baik sebagai penginjil teknis Sun Game Java dan mengajar pakar pemrograman kinerja Java.

Dalam hal kecepatan komputasi, Java mengalahkan C ++ di banyak tolok ukur komputasi ilmiah saat ini. Anda dapat menulis kode patologis dalam kedua bahasa yang berkinerja buruk jika Anda mau, tetapi secara keseluruhan, mereka setara dan telah lama.

Dalam hal penggunaan memori, Java memang memiliki beberapa over-head. HelloWorld adalah program 4K di java. Tetapi overhead itu sangat tidak berarti dalam sistem multi-GB saat ini. Akhirnya, Java memang memiliki lebih banyak waktu startup. Saya tidak akan merekomendasikan menggunakan Java untuk utilitas run-time pendek seperti perintah baris perintah Unix. Jika demikian, startup akan mendominasi kinerja Anda. Namun dalam sebuah game, itu cukup tidak penting.

Kode game Java yang ditulis dengan benar tidak mengalami GC jeda. Sama seperti kode C / C ++, itu memang memerlukan beberapa manajemen memori aktif tetapi tidak ke tingkat C / C ++. Selama Anda menjaga penggunaan memori Anda untuk objek yang berumur panjang (bertahan untuk seluruh level atau permainan) dan objek yang berumur pendek (vektor dan semacamnya, diedarkan dan dihancurkan dengan cepat setelah perhitungan) gc seharusnya tidak menjadi masalah yang terlihat.

Dalam hal akses memori langsung, Java sudah lama memilikinya; sejak Java 1.4 dalam bentuk Native Direct Byte Buffer. Memutar-mutar bit di Jawa bisa sedikit menjengkelkan karena kurangnya tipe integer yang tidak ditandatangani tetapi putaran pekerjaannya sudah terkenal dan tidak terlalu berat.

Walaupun Java sebenarnya tidak pernah memiliki Direct3D mengikat, itu karena teknologi Java berusaha untuk portabilitas. Ini memiliki DUA pengikatan OpenGL (JOGL dan LWJGL) dan pengikatan OpenAL (JOAL) dan pengikatan input portabel (JInput) yang mengikat di bawah tenda ke DirectInput pada Windows, HID Manager pada OSX, dan pengikatan Linux (saya lupa yang mana).

Memang benar bahwa tidak ada mesin permainan lengkap yang menampilkan Java dengan cara, katakanlah Unity, telah menampilkan C # dan itu adalah kelemahan dalam ruang independen. Di sisi lain, ada dua APIS tingkat Scenegraph yang baik yang sepenuhnya platform portabel di Windows, OSX dan Linux. Keduanya ditulis oleh Josh Slack, yang pertama disebut mesin JMonkey dan Ardor3D kedua.

Poster atas benar bahwa dua hal terbesar yang menahan Java dalam pengembangan game adalah prasangka dan portabilitas. Yang terakhir adalah masalah terbesar. Meskipun Anda bisa menulis game Java dan mengirimkannya ke Windows, OSX dan Linux, tidak pernah ada VM konsol. Ini karena ketidakmampuan total dalam manajemen menengah Sun. Beberapa dari kita yang bekerja pada Java dalam game sebenarnya memiliki kesepakatan dengan Sony tidak kurang dari 3 kali untuk mendapatkan VM di Playstation dan semua 3 kali manajemen menengah Sun membunuhnya.

Sementara Sun bermain-main dengan teknologi klien, faktanya adalah bahwa manajemen Sun tidak pernah mendapatkan produk konsumen. Itulah mengapa Java sebagai bahasa klien dari Sun tidak pernah berhasil dalam bentuk apa pun, dan mengapa butuh Google dan Dalvik (VM mirip Java Android) untuk menjadikan Java platform sukses di mana saja.

Dan itulah sebabnya saya kode game di C # hari ini. Karena Mono pergi ke mana manajemen Sun menolaknya.


8

Java sangat bagus untuk logika bisnis, server, dan kode independen platform yang harus dijalankan dengan andal. Ada beberapa faktor mengapa Java tidak sering digunakan dalam gim:

  • batas memeriksa & mekanisme keamanan lainnya (perbedaan kinerja marginal hari ini)
  • harus mengkonversi antara struktur data C ++ dan struktur data Java (tidak bisa hanya menyalin memori antara buffer)
  • banyak buku dan tutorial mengikuti kerumunan sehingga sulit untuk menemukan informasi pengembang game non-C ++
  • pustaka grafis inti (DirectX dan OpenGL) dan banyak mesin di luar rak berbasis C / C ++
  • banyak gim mencoba berlari secepat mungkin sehingga mereka dapat menambahkan fitur yang lebih menarik secara visual

Tidak mudah untuk bekerja dengan pustaka C ++ dari bahasa bytecode seperti Java (menulis layer JNI) dan .net (banyak atribut marshalling / unmarshalling, api / struktur). Jadi itu menambah sedikit kerja untuk sedikit manfaat.

Catatan tambahan: beberapa server game menggunakan Java.

Posting serupa di sini : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java


Anda tidak harus menulis JNI sendiri, cukup gunakan JogAmp atau perpustakaan serupa lainnya.
gouessej

Poin bagus. Saya telah menggunakan JOGL dan JMonkeyEngine di Jawa. Lebih banyak recenlty di saya telah menggunakan XNA / MonoGame ke DirectX dan OpenTK ke OpenGL dengan nvorbis / naudio / openal di C #. Dan mereka bekerja sangat baik untuk game kecil hingga menengah terutama ketika bekerja dengan shader. Peningkatan besar produktivitas melebihi C ++. Maka satu-satunya masalah Anda yang sebenarnya adalah sama dengan bahasa berbasis GC: mencegah / memitigasi GC. Ini akan menghentikan framerate Anda secara berkala sehingga Anda akan menginginkan array ukuran tetap, alokasi statis, atau buffer berumur panjang yang dapat dilemparkan ketika gameplay dihentikan (menu, memuat, sinematik).
Graeme Wicksted

Saya telah menggunakan JOGL sejak 2006 dan saya belum pernah memiliki masalah seperti ini bahkan pada perangkat keras yang sangat rendah di lingkungan desktop. Pengumpul sampah tidak bisa disalahkan karena benda terbesar sering kali dalam RAM GPU atau di heap asli (biasanya buffer NIO langsung), yang pertama tidak dikelola oleh pengumpulan sampah "normal" dan yang terakhir tidak t langsung dikelola oleh pengumpulan sampah "normal" karena menangani objek Java di heap Jawa. Terserah pengembang untuk melepaskan memori yang dialokasikan pada tumpukan asli secara efisien.
gouessej

Menurut pendapat saya yang sederhana, masalahnya lebih berasal dari beberapa "optimisasi" yang dibayangkan oleh programmer tidak dalam pola pikir Jawa yang mencegah pengumpul sampah melakukan tugasnya. Jika Anda menyimpan beberapa referensi kuat pada beberapa objek Java yang tidak berguna yang terhubung ke beberapa sumber daya asli, pengumpul sampah tidak akan pernah menganggapnya dapat direklamasi. Alokasi off-heap dapat berguna dalam beberapa kasus tetapi jika Anda menyalahgunakannya, sumber daya lama Anda akan tetap tersimpan dalam ingatan dan Anda tidak akan dapat membuat objek baru.
gouessej

Beberapa programmer game lebih suka mengalokasikan buffer besar di awal, mengiris mereka saat runtime dan mengelola memori ini sendiri, tetapi mereka mungkin akan melakukannya lebih buruk daripada sistem operasi dan kemudian, Java akan menghabiskan banyak waktu untuk membebaskan beberapa ruang untuk membuat objek baru. Menghindari kebocoran memori tidak sulit di Jawa dan solusi yang lebih layak terdiri dari pelacakan hanya objek yang memorinya tidak dialokasikan di tumpukan Jawa untuk melepaskannya pada waktu yang tepat (selama jeda, ketika beralih dari satu tingkat ke yang lain , ...), itu tidak ada hubungannya dengan pengumpul sampah.
gouessej

5

Java tidak cukup cepat untuk sebagian besar pengembangan game. Jauh lebih lambat daripada menggunakan C ++ / Majelis, yang merupakan standar. Itu alasan yang sama lebih banyak pengembangan game tidak dilakukan menggunakan C # atau VB. Pengembang game perlu dan rencanakan setiap siklus jam terakhir yang dapat mereka peroleh untuk hal-hal seperti perhitungan fisika, logika AI, dan interaksi lingkungan.

Untuk gim yang lebih sederhana, Java dapat digunakan dengan cukup efektif. Jika Anda ingin membuat klon Tetris atau Bejeweled, atau hal lain dengan tingkat detail seperti itu, maka Java akan berfungsi dengan baik. Tetapi Java tidak mungkin membuat game seperti Halo, Medal of Honor, Command & Conquer, dan sebagainya dan membuatnya bisa dimainkan. Setidaknya seperti yang ada saat ini.

Dan alasan Anda mendaftar dalam pertanyaan Anda juga valid. Kecuali, saya pikir, karena kurangnya pengembang game dengan keahlian Java. Banyak game di ponsel dan perangkat portabel lainnya ditulis dalam Java (termasuk sebagian besar game Android), dan beberapa gimnya cukup bagus. Jadi saya pikir ada basis yang layak, dan terus berkembang, para pengembang game dengan pengetahuan Java.

Pikiran berubah pada kemampuan untuk menggunakan bahasa tingkat yang lebih tinggi ini untuk beberapa game yang lebih maju. Sebagai contoh, salah satu game favorit saya, Auran's Train Simulator, ditulis dengan porsi besar dalam C #, dan itu bekerja dengan cukup baik. Jadi basisnya berkembang dan akan terus berkembang.


17
Anda meninggalkan salah satu poin paling penting; sebagian besar alat dan API yang akan digunakan ditulis dalam C ++ dan menulis ulang mereka untuk bekerja dengan Java atau bahasa lain akan menjadi satu ton pekerjaan. Juga, generalisasi Anda bahwa "[Java] jauh lebih lambat daripada menggunakan C ++ / Majelis " terlalu luas untuk akurat. Assembly tidak digunakan sesering yang mungkin Anda pikirkan dalam game PC karena kompiler yang baik kemungkinan akan menghasilkan kode yang lebih efisien daripada yang Anda tulis assembler. Namun, penggunaan sumber daya deterministik dan kemampuan untuk memperbaiki perangkat keras diperlukan.
Ed S.

15
Seseorang benar-benar perlu membuat contoh kemampuan Java yang lebih baik daripada Minecraft. Sampai seseorang dapat membuat yang setara dengan WoW atau C&C atau MOH atau Starcraft di Java atau C #, saya akan terus berpegang pada apa yang saya katakan.
BBlake

12
"Assembly tidak digunakan sesering yang mungkin Anda pikirkan dalam game PC karena kompiler yang baik kemungkinan akan menghasilkan kode yang lebih efisien daripada yang Anda tulis assembler." Itu generalisasi lain. Saya belum melihat kompiler daripada yang bisa menghasilkan bahasa mesin IA32 yang lebih baik daripada programmer bahasa assembly IA32 yang berpengalaman. Compiler menghasilkan kode untuk mesin abstrak yang dipetakan ke mesin target. Programmer bahasa assembly mengambil manfaat penuh dari prosesor yang mendasarinya, termasuk idiom mesin.
bit-twiddler

10
Jangan lupa penggunaan memori. Penggunaan memori mungkin lebih penting daripada kecepatan. Java tidak dirancang untuk kontrol memori langsung seperti C ++ dan pengumpul sampah berarti penggunaan memori selalu jauh lebih tinggi daripada C ++ untuk tugas yang sama.
Matius Baca

9
Ini bukan tahun 1985. Kami memiliki lebih dari 640k memori, lebih baik dari 50 mghz prosesor, dan lebih dari 1,44 mbs penyimpanan yang dapat dilepas. Tantangan pengembang game saat ini tidak sama dengan 25 tahun yang lalu. Silakan dan temukan contoh kode x86 / atau kerajinan64 buatan tangan untuk gim modern. Mitos tertentu benar-benar salah. Tantangannya adalah portabilitas, dan klien tingkat bawah menggunakan lingkungan operasi yang relatif kuno. Paling tidak sama denominator vs imersi yang meyakinkan.
JustinC

5

Game modern adalah semua tentang grafik 3D yang terjadi pada perangkat keras tujuan khusus.

Bahkan pada tahun 2002, Jacob Marner menemukan dalam laporannya "Mengevaluasi Java untuk Pengembangan Game" bahwa Java cukup dapat digunakan untuk game, kecuali untuk bagian yang paling tergantung pada kinerja, dan karena kekokohan bahasa dan JVM yang mendasarinya, itu lebih murah melakukannya dengan cara ini.

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

Ini adalah pendapat pribadi saya bahwa dengan kemajuan yang telah terjadi sejak itu, terutama dalam grafis 3D, dan dengan binding yang sangat baik untuk OpenGL et al, bahwa kerugian ini jauh lebih sedikit diucapkan akhir-akhir ini.

Karenanya masalahnya harus di tempat lain. Alasan yang mungkin adalah ukuran runtime Java (yang jauh lebih sedikit masalah saat ini dengan permainan multi-DVD), dan satu lagi kelambanan dari kode yang ada. Ini terkenal rapuh untuk mulai bekerja dengan kode asli di Jawa. Alasan ketiga adalah apa yang biasa dilakukan oleh pengembang bintang dalam permainan. Yang keempat adalah apakah Java sama sekali tersedia di platform.

Satu hal yang pasti - sebagian besar gim berubah menjadi skrip alih-alih semuanya dibakar dalam kode C sejak awal, dan Anda menginginkan runtime terbaik di bawah bahasa skrip Anda. Hari-hari ini pada dasarnya ini berarti CLR atau JVM.


1
oddlabs.com/technology.php - "Kami telah mendasarkan pengembangan kami pada kombinasi LWJGL dan Java, yang memungkinkan game berjalan pada platform yang didukung LWJGL tanpa modifikasi dan dengan kecepatan yang sebanding dengan kode asli yang bergantung pada platform."

Jake2 mengungguli Quake2 lebih dari 10 tahun yang lalu. Kami tidak lagi pada tahun 2002.
gouessej

4

Pengembang game suka menjadi dekat dengan logam dan sering akan menulis loop batin ketat mereka dalam perakitan. Java tidak menawarkan tingkat kinerja yang mungkin sama, baik dalam hal kecepatan yang konsisten atau penggunaan memori (menjalankan JIT akan sangat merugikan).


4

Saya pikir faktor pembatas bagi kebanyakan orang adalah (kurangnya) ketersediaan mesin game yang bagus. Untuk melangkah lebih jauh, kita perlu melihat mengapa itu tidak tersedia.

Saya akan melihat itu dari arah lain sejenak. Mengembangkan mesin permainan (misalnya) adalah banyak pekerjaan. Siapa yang akan mendapat manfaat cukup dari pengembangan satu untuk menginvestasikan waktu dan upaya untuk melakukannya?

Sebagian besar kandidat yang jelas untuk pengembangan seperti kerangka kerja di / untuk Java (misalnya, IBM, Oracle) tampaknya tidak tertarik pada permainan. Calon yang jelas untuk pengembangan game (misalnya, Id, EA) tampaknya memiliki minat yang hampir sama kecil di Jawa.

Hampir satu - satunya kandidat yang dapat saya pikirkan yang tampaknya masuk akal adalah Google. Bahasa pengembangan utama untuk Android adalah Java, dan mendorong pengembangan game untuk Android dapat memberikan keuntungan nyata bagi platform.

Sejauh yang saya tahu, mereka belum melakukannya (belum?) Namun, yang meninggalkan beberapa batasan yang cukup berat bagi hampir semua orang. Tanpa sedikit cara modern, mesin game berkinerja tinggi untuk menggunakan pengembangan di Jawa berarti cukup banyak pekerjaan ekstra, dengan (apa yang tampak bagi saya seperti) prospek kecil untuk menghasilkan banyak manfaat sebagai imbalan untuk kerja ekstra.


Saya pikir Anda telah menemukan masalah penting dengan mesin gim - saya pikir ini adalah alasan terbesar mengapa Java tidak mengejar C / C ++. Mungkin saja open source dapat sedikit meningkatkan level permainan - Saya sangat terkesan dengan jMonkeyEngine ( jmonkeyengine.com ).
mikera

dan jangan lupa bahwa pengembang game secara keseluruhan sangat konservatif (secara teknis), dan sebagian besar toko besar (berpengaruh) telah ada selama beberapa dekade dan C (++) / ASM sentris sehingga tidak akan berinvestasi dalam pengembangan Java karena itu berarti investasi besar waktu, uang, dan sumber daya lainnya di muka ketika mereka memiliki seluruh arsitektur C (++) / ASM yang siap bergulir.
jwenting

1

Pertanyaannya adalah setara dengan menanyakan sesuatu di baris:

Apa yang lebih baik untuk menyalakan mobil Anda, mesin perahu atau mesin jet.

Itu datang ke skalabilitas, penghindaran bug, kecepatan, tanda tangan memori, modularitas dan sejumlah hal. Pertanyaannya seharusnya bukan tentang apa yang lebih baik sebagai standar industri, pertanyaannya haruslah "apa yang lebih baik bagi saya" seperti dalam apa yang Anda ketahui atau seberapa baik Anda mengetahuinya. Jika berhasil, maka berhasil, jika Anda benar-benar dapat menjual ide, maka itu berhasil dan siapa tahu Anda bahkan mungkin menekuk beberapa sendok.


0

Java tidak dibuat dengan pengembangan game, Java dibuat menjadi bahasa "untuk web".

Adapun pengembangan game, Sun tidak benar-benar mendukung Java sebagai bahasa pengembangan game karena Microsoft mendukung C #.

Saya pikir kurangnya kerangka pengembangan game yang memikat adalah yang benar-benar membunuh Java dalam aspek ini.


3
Tapi C ++ juga tidak dibuat sebagai bahasa gim, tetapi sebagai bahasa pemrograman sistem seperti C. Dan Sun benar-benar melakukan upaya di Jawa sebagai bahasa gim, saya pikir mereka bekerja sama dengan Sony untuk membawa Java ke PS2 atau sesuatu, tetapi itu tidak pernah terjadi ...
Anto

1
@ Phobia: Tapi itu dirancang untuk pemrograman sistem.
Anto

1
@ Phobia: Saya mengatakan bahwa ini adalah bahasa pemrograman untuk tujuan umum , seperti C ++. Dalam jawaban Anda, Anda mengatakan bahwa Java tidak dirancang sebagai bahasa pemrograman gim, tetapi Anda lupa bahwa C ++ tidak dirancang seperti itu.
Anto

2
@ Jo Blow: Dari halaman Wikipedia tentang C: "Meskipun C dirancang untuk mengimplementasikan perangkat lunak sistem , ini juga banyak digunakan untuk mengembangkan perangkat lunak aplikasi portabel." Saya pikir itu cukup jelas, bukan?
Anto

2
@ Phobia Saya minta maaf tentang preferensi pribadi Anda, tetapi mereka sama sekali tidak relevan dengan diskusi. Selain itu, saya tidak ingin bertarung bahwa saat ini C ++ digunakan hampir secara eksklusif dalam pemrograman aplikasi. Ini bukan tentang diskusi ini. Klaim Anda bahwa Java dirancang dengan mempertimbangkan pemrograman web. Nah, C ++ dirancang dengan pemrograman sistem dalam pikiran. Kata desainernya. Akhir dari diskusi.
Konrad Rudolph

-1

Lebih mudah untuk merekatkan C lebih langsung ke perangkat keras dan driver baru yang tidak konvensional. Semakin cepat dan semakin dekat seorang programmer game bisa mendapatkan ke perangkat keras, semakin baik mereka bisa mengalahkan permainan yang bersaing. Pemrogram game kemudian hanya bertahan dengan metodologi dan alat yang sama dengan game yang telah terbukti sebelumnya.

Untuk game yang mengoptimalkan perangkat keras terbaru tidak terlalu penting, seperti game ponsel biasa, menggunakan C dengan cara ini tidak sepenting portabilitas Java yang lebih besar.


-4

Bagi sebagian orang alasan tidak ada hubungannya dengan kecepatan, perpustakaan, atau ketersediaan. Itu hanya karena bahasa itu sendiri. Beberapa orang tidak menyukai bahasa Jawa. Orang lain lebih suka menggunakan bahasa pemrograman favorit mereka daripada menggunakan Java untuk membuat game.


ini berbunyi lebih seperti komentar, lihat How to Answer
agung

-8

Tentu saja itu bisa menjadi sesuatu yang lain. Bisakah seseorang yang mengenal bisnis lebih baik dari saya menjelaskan mengapa Java tidak mendapatkan momentum dalam hal pengembangan game?

Ini adalah bahasa interpretasi, yaitu lambat. Anda berurusan dengan kartu grafis dan kartu grafis yang merupakan perangkat keras. Apa bahasa yang baik untuk berurusan dengan perangkat keras? Yah C ++, ini cukup rendah, dan Anda berurusan dengan pointer dan apa pun.

Jika Anda ingin memompa grafis gila seperti crysis dan apa pun yang Anda tidak akan lakukan Java untuk itu.

Tidak hanya itu, Oracle memiliki Java, pemikiran bahwa sebuah perusahaan dapat menuntut Anda tidak berani. Terutama ketika Anda ingin membangun juru bahasa Anda sendiri untuk JAVA untuk menargetkan game tanpa mendapatkan tuntutan karena FUD fragmentasi.


1
Anda harus serius membaca tentang kompilasi JIT, dan melihat beberapa tolok ukur di mana Java diletakkan melawan C ++
Anto

1
Siapa yang memilih jawaban ini? Seluruh pertanyaan ini menjadi sangat konyol! Duka yang bagus.
Fattie

7
@ Jo. Jawabannya salah. Java tidak ditafsirkan.
Konrad Rudolph

3
@Anto Lupakan tolok ukur konyol itu. C ++ adalah urutan yang lebih cepat dari Jawa di mana ia diperhitungkan, lihat programmer.stackexchange.com/questions/29109/29136#29136 dan programmers.stackexchange.com/questions/368/13888#13888 .
Konrad Rudolph

1
@ Ke Apa yang harus saya lihat? Kecepatan? C ++. Penggunaan memori? C ++. Lihatlah minecraft dan coba hosting server dan lihat berapa banyak memori yang digunakan permainan. Java mengkonsumsi lebih banyak memori dibandingkan C ++. Membuat game online, saya bayangkan cukup sulit di Jawa. Setiap benchmark yang saya lihat sejauh ini Java mengkonsumsi lebih banyak memori, sekarang memiliki permainan mmorpg di mana server pusat dikodekan dalam java terdengar bagus hanya jika Anda mengabaikan aspek memori atau mengubah definisi besar-besaran dalam MMORPG.
mitos
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.