Pourquoi les jeux vidéo ne sont-ils pas écrits en Java?

Question

Pourquoi ne sont pas de nombreux commerces, la 3D, les jeux vidéo (pas au hasard open source 2D) écrit en Java? En théorie, il fait beaucoup de sens: vous obtenez une augmentation de la productivité et une application multiplate-forme, presque gratuitement, entre autres choses, telles que la grande quantité de bibliothèques Java, et intégré dans la collecte des ordures (même si j'avoue que je ne suis pas sûr si ce dernier est une bonne chose). Alors pourquoi est-il jamais utilisé? Je ne peux penser à un couple populaire de jeux commerciaux écrit pour la plate-forme Java.

C'est à cause de la performance? Si oui, ne serait pas la plupart du levage lourd, être fait par le GPU de toute façon?

Answer 1

Le développement du jeu du monde est une drôle de l'un: d'une part, ils sont souvent prompts à accepter de nouvelles idées, d'autre part, ils sont encore dans l'âge de pierre.

La vérité est, il y a rarement beaucoup d'intérêt à basculer .NET/Java/rien d'autre que le C/C++.

La plupart des compagnies de jeu de la licence parties du moteur du jeu à partir d'autres entreprises. Ces pièces sont écrites en C++, et bien que vous pourriez avoir accès à la source de sorte que vous pourriez port, qui prend beaucoup d'efforts (et bien sûr, la licence doit autoriser).

Aussi, beaucoup de code hérité existe déjà en C++. Si le code de précédents projets peuvent être réutilisés (par exemple, si vous écrivez une suite), qui compte encore davantage en faveur de coller avec la même langue, au lieu de le réécrire dans une nouvelle langue (plus donc, puisque vous aurez probablement à réintroduire une tonne de bugs que vous aurez besoin de passer du temps de repassage.

Enfin, il est rare que les jeux puissent être écrit en 100% C++ de toute façon beaucoup est fait à l'aide de langages de script, qu'ils soient personnalisés ou tout simplement l'intégration de l'existant langues (Lua étant l'un des plus populaires ces jours-ci).

Aussi loin que la collecte des ordures est en cause, qui peut être un peu d'un problème. Le problème n'est pas tant qu'elle existe, elle est plus comment ça marche - le garbage collector DOIT être non-bloquant (ou au moins être garanti à seulement bloquer très brièvement), puisque c'est tout simplement inacceptable que le jeu freeze pendant 10 secondes alors qu'il scanne la mémoire allouée pour voir ce qui peut être libéré. Je sais que Java a tendance à étouffer un peu dans le GC qui pratiquent quand il est près de manquer de mémoire (et pour certains jeux, ça viendra).

Vous serez également à un peu plus limité dans ce que vous pouvez faire: vous ne pouvez pas exploiter pleinement le matériel en raison de la surcharge du moteur d'exécution. Imaginez Crysis écrite en Java... même si c'est la seule différence visible, il ne serait pas la même (je suis aussi assez sûr que vous auriez besoin d'un Core i7 pour l'exécuter.).

Cela ne signifie pas que ces langues n'ont pas leur place dans le développement de jeux - et non, je ne parle pas seulement de l'outil de programmation. Pour la plupart des jeux, vous n'avez pas besoin d'un peu plus de rendement que vous obtenez à partir de C++, y compris les jeux 3D, et si vous écrivez tout à partir de zéro, il peut tout à fait logique d'utiliser quelque chose comme XNA - en fait, il ya une bonne chance qu'il sera.

Aussi loin que les jeux commerciaux sont concernés - ne RuneScape comte? C'est peut-être la plus réussie Java jeu.

Answer 2

Je pense que John Carmack a dit qu'il meilleur avec:

Le plus gros problème, c'est que Java est vraiment lent. Sur un pur cpu / mémoire / affichage / communication niveau, la plupart des téléphones cellulaires modernes devrait être beaucoup mieux les plateformes de jeux de Game Boy Advanced. Avec Java, sur la plupart des téléphones, vous êtes de gauche avec à propos de la puissance du PROCESSEUR d'un original de 4,77 mhz IBM PC, et moche contrôle sur tout. [...snip...] Write-once-run-n'importe où. Ha. Hahahahaha. Nous ne faisons que des tests sur les quatre plates-formes à l'instant, et pas une seule paire a exactement les mêmes manies. Tous les jeux commerciaux sont tordu et compilé individuellement pour chaque (souvent+ de 100) plate-forme. La portabilité n'est pas une justification pour l'affreux performance.

(source)

Accordé, il parlait de plates-formes mobiles, mais j'ai trouvé des problèmes similaires avec Java comme un ensemble provenant d'une C++ arrière-plan. Je m'ennuie d'être en mesure d'allouer de la mémoire sur la Pile/Tas sur mes propres termes.

Answer 3

D'une part, le manque de surcharges d'opérateurs de Java fait que tous les calculs que vous avez à faire pour obtenir un pipeline graphique fonctionnel sont très ennuyeux et difficiles à lire.

Tous les vecteurs de multiplication matricielle et affine que vous devez traiter sont beaucoup plus faciles à suivre s'ils sont dans des expressions mathématiques bien formées plutôt que dans des expressions orientées objet comme

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

C'est juste terrible. Les maths ne devraient pas ressembler à ça.

Answer 4

Je pense que .NET avait (a) beaucoup des mêmes problèmes perçus que Java a. Microsoft vient de faire un meilleur travail de marketing auprès des développeurs avec XNA :-)

Answer 5

Points mineurs d'abord:

• toute augmentation de la productivité à partir de Java est hypothétique. La syntaxe est presque identique à C++ si vous êtes vraiment juste bancaires sur les comptes d'épargne à partir de la mémoire de gestion et de bibliothèques standard. Les bibliothèques ont peu à offrir aux développeurs de jeux et de la mémoire la gestion est une question controversée en raison à la collecte des déchets.

• croix-plate-forme "gratuit" n'est pas aussi bon que vous le pensez, car peu de les développeurs veulent utiliser OpenGL et plusieurs plates-formes de manque probablement un bonne implémentation Java ou wrappers pour leurs bibliothèques natives, si pour les graphiques, audio, réseau, etc.

Mais surtout, la question est de rétro-compatibilité. Aux développeurs de jeux déménagé à la C++ à partir de C et de C à partir de l'assemblée simplement parce que la voie de migration s'est faite en douceur. Chaque interagit étroitement avec la précédente, et toutes leurs précédentes code est utilisable dans la nouvelle langue, souvent par l'intermédiaire d'un simple compilateur. Par conséquent, la migration a été aussi longtemps que vous avez aimé. Par exemple, certains de nos anciens en-têtes utilisés aujourd'hui ont encore des #ifdef WATCOMC , et je ne pense pas que quelqu'un a utilisé le Watcom compilateur ici dans une décennie ou plus. Il y a un investissement massif dans l'ancien code et chaque bit est remplacé en tant que de besoin. Ce processus de remplacement et de mise à niveau des pièces et de morceaux à partir d'un jeu à l'autre est loin d'être aussi pratique si vous avez changé d'une langue qui n'est pas nativement interagir avec votre code existant. Oui, C++/Java interopérabilité est possible, mais très peu pratique par rapport à tout simplement écrit "C avec un peu de C++" ou l'incorporation de l'asm blocs en C.

Pour bien remplacer le C++, les développeurs du jeu langue de votre choix, il doit faire une de deux choses:

1. Être facilement interopérables avec existants, héritage de code, donc la préservation de l'investissement et de le maintien de l'accès à l'existant d'outils et de bibliothèques, OU
2. Manifestement montrer à l'avant assez d'une l'augmentation de la productivité, le coût de réécriture de votre propre code (ou en retravaillant les interfaces en composants réutilisables qui peuvent être utilisés à partir de cette langue) est plus que couvert.

Subjectivement, je ne pense pas que Java rencontre de ces deux groupes. Un langage de niveau plus élevé peut répondre à la 2ème, si quelqu'un est assez courageux pour être le pionnier. (EVE Online est probablement le meilleur exemple que nous avons de Python étant utilisable, mais qui utilise une fourche de la principale langage Python, de nombreux composants C++ pour la performance, et même qui est assez peu exigeant jeu en termes modernes.)