Mengapa hanya beberapa gim video yang ditulis dalam Java? [Tutup]

Mengapa tidak banyak komersial, video game 3D (bukan 2D sumber terbuka) yang ditulis dalam Java? Secara teori, ini sangat masuk akal: Anda mendapatkan peningkatan produktivitas dan aplikasi lintas-platform hampir gratis, antara lain, seperti sejumlah besar perpustakaan Jawa, dan pengumpulan sampah bawaan (walaupun saya akui saya ' Saya tidak yakin jika yang terakhir adalah hal yang baik). Jadi mengapa ini jarang digunakan? Saya hanya bisa memikirkan beberapa permainan komersial populer yang ditulis untuk platform Java.

Apakah karena kinerja? Jika demikian, bukankah sebagian besar pengangkatan berat akan dilakukan oleh GPU?

Dunia pengembangan game itu lucu: Di satu sisi, mereka sering cepat menerima ide-ide baru, di sisi lain, mereka masih di zaman batu.

Yang benar adalah, jarang ada banyak insentif dalam beralih ke .NET / Java / apa pun selain C / C ++.

Sebagian besar perusahaan game melisensikan bagian-bagian mesin game dari perusahaan lain. Bagian-bagian ini ditulis dalam C ++, dan meskipun Anda mungkin memiliki akses ke sumber sehingga Anda bisa porting, itu membutuhkan banyak upaya (dan tentu saja, lisensi perlu mengizinkannya).

Juga, banyak kode lawas sudah ada di C ++. Jika kode dari proyek sebelumnya dapat digunakan kembali (katakanlah, jika Anda menulis sekuel), itu bahkan lebih berarti bertahan dengan bahasa yang sama, alih-alih menulis ulang dalam bahasa baru (lebih dari itu karena Anda kemungkinan akan memperkenalkan kembali satu ton bug yang Anda harus menghabiskan waktu menyetrika.

Akhirnya, permainan jarang ditulis dalam 100% C ++ - banyak yang dilakukan menggunakan bahasa scripting, apakah itu khusus atau hanya mengintegrasikan bahasa yang ada (Lua menjadi salah satu yang lebih populer saat ini).

Sejauh menyangkut pengumpulan sampah, itu bisa menjadi sedikit masalah. Masalahnya bukan seberapa banyak itu ada, tetapi lebih pada cara kerjanya - pengumpul sampah HARUS non-pemblokiran (atau setidaknya dijamin hanya akan memblokir secara singkat), karena tidak dapat diterima untuk membekukan permainan selama 10 detik sementara itu memindai semua memori yang dialokasikan untuk melihat apa yang bisa dibebaskan. Saya tahu Java cenderung tersedak sedikit di GC'ing ketika hampir kehabisan memori (dan untuk beberapa game di luar sana, itu akan).

Anda juga sedikit lebih dibatasi dalam apa yang dapat Anda lakukan: Anda tidak dapat sepenuhnya mengeksploitasi perangkat keras karena overhead runtime. Bayangkan Crysis ditulis dalam Java ... bahkan jika itu satu-satunya perbedaan yang terlihat, itu tidak akan sama (saya juga cukup yakin Anda akan memerlukan Core i7 untuk menjalankannya.).

Ini tidak berarti bahasa-bahasa ini tidak memiliki tempat dalam pengembangan game - dan tidak, saya tidak hanya merujuk pada pemrograman alat. Untuk sebagian besar gim, Anda tidak perlu sedikit kinerja ekstra yang Anda dapatkan dari C ++, termasuk gim 3D, dan jika Anda menulis semuanya dari awal, masuk akal untuk menggunakan sesuatu seperti XNA - pada kenyataannya, ada peluang bagus itu akan terjadi.

Sejauh menyangkut permainan komersial - apakah RuneScape masuk hitungan? Itu mungkin game Java paling sukses di luar sana.

Saya pikir John Carmack mengatakan yang terbaik dengan:

Masalah terbesar adalah bahwa Jawa sangat lambat. Pada level cpu / memori / display / komunikasi murni, sebagian besar ponsel modern harus menjadi platform game yang jauh lebih baik daripada Game Boy Advanced. Dengan Java, pada sebagian besar ponsel Anda hanya memiliki kekuatan CPU dari PC IBM asli 4,77 mhz, dan kontrol buruk atas semuanya. [... snip ...] Tulis-sekali-lari-di mana saja. Ha. Hahahahaha. Kami hanya menguji pada empat platform saat ini, dan tidak satu pun pasangan memiliki kebiasaan yang sama persis. Semua game komersial di-tweak dan dikompilasi secara individual untuk setiap platform (seringkali 100+). Portabilitas bukan pembenaran untuk kinerja yang buruk.

( sumber )

Memang, dia berbicara tentang platform seluler, tetapi saya telah menemukan masalah serupa dengan Java secara keseluruhan yang berasal dari latar belakang C ++. Saya rindu untuk dapat mengalokasikan memori pada Stack / Heap dengan ketentuan saya sendiri.

Untuk satu hal, kurangnya operator Java yang kelebihan membuat semua matematika Anda harus berurusan dengan untuk mendapatkan pipa grafis yang bekerja sangat, sangat menjengkelkan dan sulit dibaca.

Semua perkalian matriks dan vektor affine yang perlu Anda tangani jauh lebih mudah diikuti jika mereka berada dalam ekspresi matematika yang terbentuk dengan baik daripada ekspresi berorientasi objek seperti

product = vector.multiply(projectionMatrix).dotProduct(otherVector);

Itu mengerikan. Matematika seharusnya tidak terlihat seperti itu.

Saya pikir. NET memiliki (memiliki) banyak masalah yang sama dengan yang dirasakan Java. Microsoft baru saja melakukan pekerjaan yang lebih baik dalam pemasaran untuk pengembang dengan XNA :-)

Poin minor pertama:

• setiap peningkatan produktivitas dari Jawa adalah hipotesis. Sintaksnya hampir identik dengan C ++ sehingga Anda benar-benar hanya mengandalkan penghematan dari manajemen memori dan perpustakaan standar. Perpustakaan memiliki sedikit untuk menawarkan pengembang game dan manajemen memori adalah masalah yang diperdebatkan karena pengumpulan sampah.

• cross-platform "gratis" tidak sebagus yang Anda pikirkan karena beberapa pengembang ingin menggunakan OpenGL dan beberapa platform utama mungkin tidak memiliki implementasi Java yang baik atau pembungkus untuk perpustakaan asli mereka, baik untuk grafik, audio, jaringan, dll.

Tetapi terutama, masalahnya adalah kompatibilitas ke belakang. Pengembang game pindah ke C ++ dari C dan ke C dari perakitan murni karena rute migrasi lancar. Setiap interoperate erat dengan yang sebelumnya, dan semua kode mereka sebelumnya dapat digunakan dalam bahasa baru, sering melalui kompiler tunggal. Karena itu migrasi lambat atau secepat yang Anda suka. Misalnya, beberapa tajuk lama kami yang digunakan saat ini masih memiliki #ifdef WATCOMCdi, dan saya tidak berpikir ada orang yang menggunakan kompiler Watcom di sini dalam satu dekade atau lebih. Ada investasi besar-besaran dalam kode lama dan setiap bit hanya diganti sesuai kebutuhan. Proses mengganti dan meningkatkan potongan-potongan dari satu game ke game berikutnya sama sekali tidak praktis jika Anda mengubah ke bahasa yang tidak asli beroperasi dengan kode yang ada. Ya, interoperabilitas C ++ / Java dimungkinkan, tetapi sangat tidak praktis jika dibandingkan dengan hanya menulis "C dengan sedikit C ++" atau menanamkan blok asm di C.

Untuk benar-benar menggantikan C ++ sebagai bahasa pilihan pengembang game, ia harus melakukan satu dari dua hal:

1. Mudah dioperasikan dengan kode lawas yang ada, sehingga menjaga investasi dan mempertahankan akses ke perpustakaan dan alat yang ada, ATAU
2. Menunjukkan peningkatan produktivitas di muka sehingga biaya penulisan ulang semua kode Anda sendiri (atau pengerjaan ulang antarmuka menjadi komponen yang dapat digunakan kembali yang dapat digunakan dari bahasa itu) lebih dari cukup untuk ditanggung.

Secara subyektif, saya pikir Java tidak memenuhi keduanya. Bahasa tingkat yang lebih tinggi mungkin memenuhi yang ke-2, jika seseorang cukup berani untuk menjadi perintis. (EVE Online mungkin adalah contoh terbaik yang kami miliki tentang Python yang dapat digunakan, tetapi yang menggunakan garpu bahasa Python utama, banyak komponen C ++ untuk kinerja, dan bahkan itu untuk permainan yang cukup ringan dalam istilah modern.)

Saya sedang bermain Sims 3, dan saya melakukan beberapa pencarian. Mesin grafis adalah C ++, sedangkan mesin scripting dan perilaku adalah C # / Mono. Jadi, sementara C ++ ada untuk bit waktu kritis, hal-hal lain seperti. Interaksi, logika permainan, AI dalam bahasa yang dikelola objek berorientasi.

• Apakah ada port yang bagus untuk mesin game / perpustakaan?
• Banyak pengembang C / C ++, terutama yang ada di Windows (di mana sebagian besar game komersial ditulis) sudah familiar dengan Visual Studio. Tidak ada perbandingan dalam IDE.
• Secara umum, Java telah dijual ke bisnis karena pengetikannya padat dan memiliki persepsi tidak memiliki masalah manajemen memori.
• Dan ya, Java masih menderita persepsi bahwa itu lambat, dan manajemen memorinya buruk, dan untuk game, mungkin tidak cocok untuk tugas itu. Seperti yang dinyatakan dalam beberapa jawaban lain, pengumpulan sampah tidak akan memotongnya ketika Anda berurusan dengan persyaratan kinerja tinggi real-time. Permainan video mendorong CPU dan GPU ke batasnya.

Salah satu alasan terbesar Java dan bahasa Mesin Virtual lainnya tidak digunakan untuk game adalah karena Pengumpulan Sampah. Hal yang sama berlaku untuk .NET. Pengumpulan sampah telah datang jauh dan bekerja sangat baik di sebagian besar jenis aplikasi. Untuk melakukan pengumpulan sampah, Anda perlu menjeda dan menghentikan aplikasi untuk mengumpulkan sampah. Ini dapat menyebabkan kelambatan berkala ketika pengumpulan terjadi.

Java memiliki masalah yang sama untuk aplikasi realtime. Ketika tugas harus dijalankan pada waktu tertentu, sulit untuk memiliki tugas otomatis seperti pengumpulan sampah.

Bukannya Java lambat. Java tidak pandai menangani tugas waktu nyata.

Alasan besar adalah bahwa video game memerlukan pengetahuan langsung tentang perangkat keras di bawahnya, sering kali, dan memang tidak ada implementasi yang bagus untuk banyak arsitektur. Ini adalah pengetahuan tentang arsitektur perangkat keras yang mendasari yang memungkinkan pengembang untuk memeras setiap ons kinerja dari sistem game. Mengapa Anda meluangkan waktu untuk port Java ke platform game, dan kemudian menulis game di atas port itu ketika Anda hanya bisa menulis game?

sunting: ini untuk mengatakan bahwa ini lebih dari masalah "kecepatan" atau "tidak memiliki perpustakaan yang tepat". Kedua hal itu berjalan seiring dengan ini, tetapi ini lebih merupakan masalah "bagaimana cara membuat sistem seperti sel menjalankan kode java saya? Sebenarnya tidak ada kompiler java yang baik yang dapat mengelola pipa dan vektor seperti yang saya butuhkan .. "

Masalah kinerja adalah alasan pertama. Ketika Anda melihat jenis kode C ++ hiper yang dioptimalkan yang ada di mesin Quake ( http://www.codemaestro.com/reviews/9 ), Anda tahu mereka tidak akan membuang-buang waktu dengan mesin virtual.

Tentu mungkin ada beberapa game .NET (yang mana? Saya tertarik. Apakah ada beberapa yang benar-benar intensif CPU / GPU?), Tapi saya rasa itu lebih karena banyak orang ahli dalam teknologi MS dan mengikuti Microsoft ketika mereka meluncurkan teknologi baru mereka.

Oh dan lintas-platform tidak ada dalam pikiran perusahaan video game. Linux hanya sekitar 1% dari pasar, Mac OS beberapa% lebih banyak. Mereka pasti berpikir itu tidak layak membuang teknologi dan librairia Windows saja seperti DirectX.

Anda dapat bertanya mengapa aplikasi web tidak ditulis dalam C atau C ++ juga. Kekuatan Java terletak pada tumpukan jaringan dan desain berorientasi objek. Tentu saja C dan C ++ memilikinya juga. Tetapi pada abstraksi yang lebih rendah. Itu tidak ada yang negatif, tetapi Anda tidak ingin menemukan kembali roda setiap kali, bukan?

Java juga tidak memiliki akses perangkat keras langsung, yang berarti Anda terjebak dengan API kerangka kerja apa pun.

Kesalahpahaman tentang kinerja dan optimalisasi JVM yang buruk akan menjadi dugaan saya. Saya mengatakan kesalahpahaman tentang kinerja karena ada beberapa port Java dari game C ++ yang berkinerja lebih cepat daripada rekan C ++ mereka (lihat Jake 2). Masalah sebenarnya, IMHO, adalah bahwa banyak programmer Java tidak terlalu fokus pada kinerja yang berdarah karena mereka dengan mudah digunakan dan dapat dimengerti / dipelihara kode. Pada sisi C / C ++ hal-hal yang pada dasarnya Anda koding dalam bahasa assembly level yang sedikit lebih tinggi dan sedekat mungkin dengan perangkat keras yang Anda dapat tanpa menulis dalam kode assembly atau mesin lurus.

Daftar mesin game di Wikipedia mencantumkan banyak mesin game beserta bahasa pemrogramannya.

Ada beberapa mesin game Java yang terdaftar.

Mengklik beberapa tautan akan mengarahkan Anda ke contoh permainan dan demo yang ditulis dalam Java. Inilah pasangan:

• Ardor3D
• Perangkat Lunak Bytonic

Untuk permainan dan situasi tertentu, trade-off Java mungkin dapat diterima.

.NET jelas memiliki beberapa masalah yang sama dengan yang dimiliki Java dalam hal kinerja 3D yang intens. Microsoft juga telah menginvestasikan lebih banyak waktu dan uang dalam pengembangan perpustakaan ketika datang untuk bekerja dengan operasi berat 3D.

(... secara pribadi, saya juga berpikir mereka memiliki kaki ketika datang ke keajaiban antara DirectX dan .NET)

1. Java lambat, sebagian besar pengangkatan berat tidak ditangani oleh GPU. Masih ada animasi, fisika, dan AI yang mengenai CPU, yang semuanya sangat memakan waktu.

2. Java tidak ada di konsol, dan konsol adalah target utama untuk gim komersial. Jika Anda menggunakan Java pada PC, Anda menghilangkan kemampuan Anda untuk port ke konsol dalam waktu dan anggaran yang wajar.

3. Banyak coders yang lebih berpengalaman dalam industri game telah menggunakan C dan C ++ jauh sebelum Java menjadi populer. Dua poin di atas dapat berkontribusi pada hal ini, tetapi saya berharap bahwa banyak coders game profesional tidak begitu mengenal Java.

4. Poin orang lain tentang middleware di atas adalah bagus, jadi saya menambahkannya ke jawaban saya. Ada banyak kode lama dan middleware yang ditulis khusus untuk dihubungkan dengan C / C ++, dan terakhir saya memeriksa Java tidak memiliki interoperabilitas yang baik. Menggunakan Java untuk sebagian besar perusahaan akan melibatkan membuang banyak kode, banyak yang telah dibayar dengan satu atau lain cara.

Sebenarnya, sangat mungkin bagi kode yang dikelola untuk melakukan game 3d, masalahnya adalah mesin belakang. Dengan .Net, untuk jangka waktu singkat, ada pembungkus Managed DirectX ke DirectX 9 oleh Microsoft. Ini sebelum abstraksi yang sekarang XNA.

Diberikan akses total ke DirectX api, .Net games dapat digunakan. Contoh terbaik yang saya tahu adalah www.entombed.co.uk, yang ditulis dalam VB.Net.

Sayangnya, di sisi Java, ini benar-benar kurang - terutama karena alasan DirectX tidak tersedia untuk Java, dan programmer game tahu dan memahami api DirectX - mengapa belajar api lagi ketika Anda akan kembali ke DirectX?

Pemasaran game adalah proses komersial; penerbit menginginkan hasil risiko rendah yang dapat diukur dari investasi mereka. Sebagai konsekuensinya, fokus biasanya pada tipuan teknologi (dengan pengecualian) yang akan dibeli konsumen untuk menghasilkan pengembalian yang andal - ini cenderung efek visual yang dangkal seperti silau lensa atau resolusi yang lebih tinggi. Efek ini dapat diandalkan karena mereka hanya menggunakan peningkatan kekuatan pemrosesan - mereka mengeksploitasi perangkat keras / hukum Moore meningkat. ini berarti menggunakan C / C ++ - java biasanya terlalu abstrak dari perangkat keras untuk mengeksploitasi manfaat ini.

Saya kira kecepatan masih menjadi masalah. Cross platform akan menjadi masalah bukan karena Anda tidak tahu kartu 3d apa yang tersedia saat Anda menulis kode? Apakah java punya sesuatu untuk mendukung penemuan otomatis kemampuan 3d? Dan saya kira ada alat untuk memudahkan porting game antara wii, xbox, dan ps3, tapi mahal saya berani bertaruh.

PS3 memiliki java, melalui dukungan sinar biru. Periksa situs bd-j.

Bahkan game yang ditulis pada platform .Net sering sangat dioptimalkan untuk kecepatan seperti akses langsung ke memori dan bus. .Net memungkinkan untuk menggunakan C / C ++ dan mencampurnya dengan bahasa tingkat yang lebih tinggi seperti C #.

Studio pengembangan game sering bekerja berdekatan dengan vendor perangkat keras, yang memang memberikan akses ke antarmuka tingkat rendah dari produk mereka. Ini adalah dunia, di mana Anda harus menggunakan ASM dan C untuk komunikasi perangkat. Lingkungan virtual akan memperlambat bagian-bagian program ini.

Bagaimanapun, game 3D modern sebenarnya menggunakan bahasa tingkat yang lebih tinggi. Seringkali, Anda akan menemukan logika permainan yang ditulis dalam bahasa seperti Lua atau Python. Tetapi inti (I / O, utas, penjadwalan tugas) dari game 3D tipikal akan ditulis dalam bahasa tingkat rendah selama 25 tahun ke depan atau selama perangkat tidak memungkinkan abstraksi dan virtualisasi sendiri (yang akan datang).

Saya setuju dengan posting lain tentang memanfaatkan elemen basis kode yang sudah ada / berlisensi, kinerja, dll.

Satu hal yang ingin saya tambahkan adalah sulit untuk menarik trik DRM jahat melalui mesin virtual.

Juga saya pikir ada komponen keangkuhan di mana manajer proyek berpikir mereka dapat membuat kode yang stabil / dapat diandalkan dengan C ++ dengan semua fasilitas seperti memiliki kendali mutlak atas alat dan sumber daya mereka, TETAPI tanpa semua negatif yang menyulitkan dan meredam persaingan mereka karena "kami" lebih pintar dari mereka ".

Runescape oleh Jagex ditulis dalam Java, tag "video game" mungkin tidak secara khusus menerapkannya sebagai game on-line, tetapi memiliki pengikut yang layak.

Sudah banyak dibicarakan, Anda dapat menemukan di Wiki alasannya ...

• C / C ++ untuk mesin game dan semua hal intensif.
• Lua atau Python untuk skrip dalam game.
• Java - kinerja sangat-sangat buruk, penggunaan memori besar + itu tidak tersedia di Konsol Game (Ini digunakan untuk beberapa game yang sangat sederhana (Ya, Runescape diperhitungkan di sini, ini bukan Battlefield atau Crysis atau apa lagi yang ada) hanya karena ada banyak programmer yang tahu bahasa pemrograman ini).
• C # - penggunaan memori besar (Ini digunakan untuk beberapa game yang sangat sederhana hanya karena ada cukup banyak programmer yang tahu bahasa pemrograman ini).

Dan saya mendengar semakin banyak programmer Java yang mencoba meyakinkan orang bahwa Java tidak lambat, tidak lambat untuk menggambar widget di layar dan menggambar beberapa karakter ASCII pada widget, untuk menerima dan mengirim data melalui jaringan (Dan itu adalah direkomendasikan untuk menggunakannya dalam kasus ini (manipulasi data jaringan) alih-alih C / C ++) ... Tetapi sangat lambat ketika menyangkut hal-hal serius seperti perhitungan matematika, alokasi memori / manipulasi dan banyak hal bagus ini.

Saya ingat sebuah artikel di situs MIT di mana mereka menunjukkan apa yang dapat dilakukan C / C ++ jika Anda menggunakan fitur bahasa dan kompiler: Pengganda matriks (2 matriks), 1 implementasi di Jawa dan 1 implementasi di C / C ++, dengan fitur C / C ++ dan optimisasi kompiler yang tepat diaktifkan, implementasi C / C ++ ~ 296 260 kali lebih cepat daripada implementasi Java.

Saya harap Anda mengerti sekarang mengapa orang menggunakan C / C ++ daripada Java dalam game, bayangkan Crysis di Jawa, tidak akan ada komputer di dunia ini yang bisa menangani itu ... + Pengumpulan sampah berfungsi dengan baik untuk Widget yang hanya menghancurkan gambar tetapi masih di-cache di sana dan perlu dibersihkan tetapi tidak untuk game, pasti, Anda akan memiliki lebih banyak keterlambatan pada setiap aktivasi pengumpulan sampah.

Sunting : Karena seseorang meminta artikel itu, di sini, saya mencari di arsip web untuk mendapatkannya, saya harap Anda puas ... Studi Kasus MIT

Dan untuk menambahkan, tidak, Java untuk gaming masih merupakan ide yang buruk. Hanya beberapa hari yang lalu sebuah perusahaan besar yang saya tidak akan menyebutkan namanya mulai menulis ulang klien game mereka dari Jawa ke C ++ karena permainan yang sangat sederhana (Dalam hal Grafik) tertinggal dan memanaskan Laptop i7 dengan kartu video nVidia GT 5xx dan 6xx generasi yang kuat ( tidak hanya nVidia, intinya di sini adalah bahwa kartu yang kuat ini dapat menangani pengaturan Max sebagian besar game baru dan tidak dapat menangani game ini) dan konsumsi memori ~ 2.5 - 2.6 GB Ram. Untuk grafik sederhana seperti itu dibutuhkan binatang mesin.