Pourquoi seuls quelques jeux vidéo sont-ils écrits en Java? [fermé]

Pourquoi n'y a-t-il pas beaucoup de jeux vidéo commerciaux en 3D (pas de jeux 2D open source aléatoires) écrits en Java? En théorie, cela a beaucoup de sens: vous obtenez une augmentation de la productivité et une application multiplateforme presque gratuitement, entre autres, comme la grande quantité de bibliothèques Java et le ramasse-miettes intégré (même si j'avoue que je '' Je ne sais pas si ce dernier est une bonne chose). Alors pourquoi est-il rarement utilisé? Je ne peux penser qu'à quelques jeux commerciaux populaires écrits pour la plate-forme Java.

Est-ce à cause des performances? Si tel est le cas, la plupart des tâches lourdes ne seraient-elles pas effectuées de toute façon par le GPU?

Le monde du développement de jeux est amusant: d'une part, ils acceptent souvent rapidement de nouvelles idées, d'autre part, ils sont encore à l'âge de pierre.

La vérité est qu'il y a rarement autant d'incitation à passer à .NET / Java / autre chose que C / C ++.

La plupart des sociétés de jeux licencient des parties du moteur de jeu d'autres sociétés. Ces parties sont écrites en C ++, et bien que vous puissiez avoir accès à la source pour pouvoir la porter, cela demande beaucoup d'efforts (et bien sûr, la licence doit le permettre).

De plus, beaucoup de code hérité existe déjà en C ++. Si le code des projets précédents peut être réutilisé (par exemple, si vous écrivez une suite), cela compte encore plus en faveur du maintien du même langage, au lieu de le réécrire dans un nouveau langage (d'autant plus que vous allez probablement le réintroduire une tonne de bugs dont vous aurez besoin pour passer du temps à aplanir.

Enfin, il est rare que les jeux soient écrits en 100% C ++ de toute façon - beaucoup est fait en utilisant des langages de script, qu'ils soient personnalisés ou simplement en intégrant un langage existant (Lua étant l'un des plus populaires de nos jours).

En ce qui concerne le ramassage des ordures, cela peut être un peu un problème. Le problème n'est pas tant qu'il existe, c'est plutôt comment cela fonctionne - le ramasse-miettes DOIT être non bloquant (ou du moins être garanti de ne bloquer que très brièvement), car il est tout simplement inacceptable que le jeu se fige pendant 10 secondes. il scanne toute la mémoire allouée pour voir ce qui peut être libéré. Je sais que Java a tendance à s'étouffer un peu en GC quand il est proche de manquer de mémoire (et pour certains jeux, ce sera le cas).

Vous êtes é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 de l'exécution. Imaginez que Crysis soit écrit en Java ... même si c'est la seule différence visible, ce ne serait tout simplement pas la même chose (je suis également sûr que vous auriez besoin d'un Core i7 pour l'exécuter.).

Cela ne veut pas dire que ces langages n'ont pas leur place dans le développement de jeux - et non, je ne fais pas simplement référence à la programmation d'outils. Pour la plupart des jeux, vous n'avez pas besoin de ces performances supplémentaires que vous obtenez de C ++, y compris les jeux 3D, et si vous écrivez tout à partir de zéro, il peut être parfaitement logique d'utiliser quelque chose comme XNA - en fait, il y a un bonne chance.

En ce qui concerne les jeux commerciaux, RuneScape compte-t-il? Cela pourrait bien être le jeu Java le plus réussi.

Je pense que John Carmack l'a mieux dit avec:

Le plus gros problème est que Java est vraiment lent. Au niveau pur processeur / mémoire / affichage / communications, la plupart des téléphones portables modernes devraient être des plates-formes de jeu considérablement meilleures qu'un Game Boy Advanced. Avec Java, sur la plupart des téléphones, il vous reste à peu près la puissance du processeur d'un PC IBM original de 4,77 mhz et un contrôle minable sur tout. [... snip ...] Écriture-une-exécution-n'importe où. Ha. Hahahahaha. Nous ne testons actuellement que sur quatre plates-formes, et pas une seule paire n'a exactement les mêmes bizarreries. Tous les jeux commerciaux sont modifiés et compilés individuellement pour chaque plateforme (souvent plus de 100). La portabilité ne justifie pas les performances horribles.

( source )

Certes, il parlait de plates-formes mobiles, mais j'ai trouvé des problèmes similaires avec Java dans son ensemble provenant d'un arrière-plan C ++. Je m'ennuie de pouvoir allouer de la mémoire sur la pile / tas à mes propres conditions.

D'une part, l'absence de surcharge d'opérateurs de Java rend tous les calculs que vous devez gérer pour obtenir un pipeline graphique fonctionnel très, très ennuyeux et difficile à lire.

Toutes les multiplications matricielles et vecteurs affines que vous devez gérer 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 tout simplement terrible. Les mathématiques ne devraient pas ressembler à ça.

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

Points mineurs en premier:

• toute augmentation de productivité de Java est hypothétique. La syntaxe est presque identique à C ++, vous misez donc simplement sur les économies réalisées grâce à la gestion de la mémoire et aux bibliothèques standard. Les bibliothèques ont peu à offrir aux développeurs de jeux et la gestion de la mémoire est un problème litigieux en raison du ramassage des ordures.

• «gratuit» multiplateforme n'est pas aussi bon que vous le pensez car peu de développeurs veulent utiliser OpenGL et plusieurs plates-formes clés manquent probablement d'une bonne implémentation Java ou de wrappers pour leurs bibliothèques natives, que ce soit pour les graphiques, l'audio, le réseau, etc.

Mais principalement, le problème est la compatibilité ascendante. Les développeurs de jeux sont passés au C ++ de C et au C à partir de l'assembly uniquement parce que la route de migration était fluide. Chacun interagit étroitement avec le précédent, et tout leur code précédent était utilisable dans le nouveau langage, souvent via un seul compilateur. Par conséquent, la migration était aussi lente ou aussi rapide que vous le souhaitiez. Par exemple, certains de nos anciens en-têtes utilisés aujourd'hui ont toujours #ifdef WATCOMCdans, et je ne pense pas que quiconque ait utilisé le compilateur Watcom ici depuis une décennie ou plus. Il y a un investissement massif dans l'ancien code et chaque bit n'est remplacé que si nécessaire. Ce processus de remplacement et de mise à niveau de bits et de pièces d'un jeu à l'autre est loin d'être aussi pratique si vous passez à un langage qui n'interagit pas nativement avec votre code existant. Oui, l'interopérabilité C ++ / Java est possible, mais très peu pratique par rapport à simplement écrire "C avec un peu de C ++" ou incorporer des blocs asm dans C.

Pour remplacer correctement C ++ en tant que langage de choix des développeurs de jeux, il doit faire l'une des deux choses suivantes:

1. Être facilement interopérable avec le code hérité existant, préservant ainsi l'investissement et maintenant l'accès aux bibliothèques et outils existants, OU
2. Démontrez clairement une augmentation de productivité suffisante pour que le coût de la réécriture de tout votre code (ou de la retouche des interfaces en composants réutilisables pouvant être utilisés à partir de ce langage) soit plus que couvert.

Subjectivement, je ne pense pas que Java rencontre l'un ou l'autre de ces éléments. Une langue de plus haut niveau pourrait rencontrer le 2ème, si quelqu'un est assez courageux pour être le pionnier. (EVE Online est probablement le meilleur exemple que nous ayons de Python utilisable, mais qui utilise un fork du langage Python principal, de nombreux composants C ++ pour les performances, et même cela pour un jeu assez peu exigeant en termes modernes.)

Je joue aux Sims 3, et j'ai fait quelques fouilles. Le moteur graphique est C ++, tandis que le moteur de script et de comportement est C # / Mono. Ainsi, alors que C ++ est là pour les bits critiques en termes de temps, d'autres choses comme .interaction, la logique du jeu, l'IA est dans un langage géré orienté objet.

• Existe-t-il de bons ports de moteurs / bibliothèques de jeux?
• De nombreux développeurs C / C ++, en particulier ceux sous Windows (où la plupart des jeux commerciaux sont écrits) connaissent Visual Studio. Il n'y a pas de comparaison dans les IDE.
• En général, Java a été vendu aux entreprises en raison de sa frappe solide et il a l'impression de ne pas avoir de problèmes de gestion de la mémoire.
• Et oui, Java souffre toujours de la perception qu'il est lent, et sa gestion de la mémoire est médiocre, et pour les jeux, il est probablement mal adapté à la tâche. Comme indiqué dans certaines des autres réponses, le garbage collection ne va tout simplement pas le couper lorsque vous faites face à des exigences de haute performance en temps réel. Les jeux vidéo poussent les processeurs et les GPU à leurs limites.

L'une des principales raisons pour lesquelles Java et d'autres langages de machine virtuelle ne sont pas utilisés pour les jeux est due à la collecte des ordures. La même chose vaut pour .NET. Le nettoyage de la mémoire a parcouru un long chemin et fonctionne très bien dans la plupart des types d'applications. Cependant, pour effectuer le garbage collection, vous devez suspendre et interrompre l'application pour collecter la corbeille. Cela peut provoquer un décalage périodique lors de la collecte.

Java a le même problème pour les applications en temps réel. Lorsque les tâches doivent s'exécuter à un moment précis, il est difficile de faire en sorte qu'une tâche automatisée telle que le garbage collection respecte cela.

Ce n'est pas que Java soit lent. C'est que Java n'est pas bon pour gérer les tâches en temps réel.

Une grande raison est que les jeux vidéo nécessitent une connaissance directe du matériel sous-jacent, souvent, et il n'y a vraiment pas de bonne implémentation pour de nombreuses architectures. C'est la connaissance de l'architecture matérielle sous-jacente qui permet aux développeurs de tirer chaque once de performance d'un système de jeu. Pourquoi prendriez-vous le temps de porter Java sur une plate-forme de jeu, puis d'écrire un jeu sur ce port alors que vous pourriez simplement écrire le jeu?

edit: c'est dire que c'est plus qu'un problème de "vitesse" ou "je n'ai pas les bonnes bibliothèques". Ces deux choses vont de pair avec cela, mais c'est plus une question de "comment faire exécuter mon code java à un système comme la cellule? Il n'y a pas vraiment de bons compilateurs java capables de gérer les pipelines et les vecteurs comme j'ai besoin .. "

Le problème de performance est la première raison. Quand vous voyez le genre de code C ++ hyper optimisé qui se trouve dans les moteurs Quake ( http://www.codemaestro.com/reviews/9 ), vous savez qu'ils ne vont pas perdre leur temps avec une machine virtuelle.

Bien sûr, il peut y avoir des jeux .NET (lesquels? Cela m'intéresse. Y a-t-il des jeux vraiment gourmands en CPU / GPU?), Mais je suppose que c'est plus parce que beaucoup de gens sont des experts en technologies MS et ont suivi Microsoft lors de leur lancement leur nouvelle technologie.

Oh, et le multi-plateforme n'est tout simplement pas dans l'esprit des sociétés de jeux vidéo. Linux représente à peine 1% du marché, Mac OS quelques% de plus. Ils pensent définitivement qu'il ne vaut pas la peine de se débarrasser des technologies et des bibliothèques Windows uniquement telles que DirectX.

Vous pouvez également vous demander pourquoi les applications Web ne sont pas écrites en C ou C ++. La puissance de Java réside dans sa pile réseau et sa conception orientée objet. Bien sûr, C et C ++ l'ont aussi. Mais sur une abstraction inférieure. Ce n'est rien de négatif, mais vous ne voulez pas réinventer la roue à chaque fois, n'est-ce pas?

Java n'a pas non plus d'accès matériel direct, ce qui signifie que vous êtes coincé avec l'API de tous les frameworks.

Je suppose que les idées fausses sur les performances et les mauvaises optimisations JVM seraient. Je dis des idées fausses sur les performances car il existe certains ports Java de jeux C ++ qui fonctionnent plus rapidement que leurs homologues C ++ (voir Jake 2). Le vrai problème, à mon humble avis, est que de nombreux programmeurs Java ne se concentrent pas tant sur les performances de pointe que sur la facilité d'utilisation et la compréhensibilité / maintenabilité du code. Du côté C / C ++ des choses, vous codez essentiellement dans un langage d'assemblage de niveau légèrement supérieur et c'est à peu près aussi proche du matériel que vous pouvez l'obtenir sans écrire en assembleur ou en code machine direct.

La liste des moteurs de jeu sur Wikipedia répertorie de nombreux moteurs de jeu ainsi que le langage de programmation dans lequel ils sont écrits.

Il existe plusieurs moteurs de jeux Java répertoriés.

Cliquez sur certains des liens pour accéder à des exemples de jeux et de démos écrits en Java. En voici quelques-uns:

• Ardour3D
• Logiciel Bytonic

Pour certains jeux et certaines situations, les compromis de Java peuvent être acceptables.

.NET a certainement les mêmes problèmes que Java en ce qui concerne les performances 3D intenses. Microsoft a également investi beaucoup plus de temps et d'argent dans le développement des bibliothèques lorsqu'il s'agit de travailler avec des opérations 3D lourdes.

(... personnellement, je pense aussi qu'ils avaient une longueur d'avance en ce qui concerne la magie entre DirectX et .NET)

1. Java est lent, la plupart des tâches lourdes ne sont pas gérées par le GPU. Il y a encore de l'animation, de la physique et de l'IA qui frappent le processeur, qui prennent tous beaucoup de temps.

2. Java n'existe pas sur les consoles et les consoles sont une cible majeure pour les jeux commerciaux. Si vous utilisez Java sur PC, vous éliminez votre capacité à effectuer un portage vers des consoles dans un délai et un budget raisonnables.

3. La plupart des codeurs les plus expérimentés de l'industrie du jeu utilisaient C et C ++ bien avant que Java ne devienne populaire. Les deux points ci-dessus peuvent y contribuer, mais je pense que de nombreux codeurs de jeux professionnels ne connaissent tout simplement pas très bien Java.

4. Le point de quelqu'un d'autre sur le middleware ci-dessus était bon, donc je l'ajoute à ma réponse. Il y a beaucoup de code hérité et de middleware écrits spécifiquement pour se lier avec C / C ++, et j'ai vérifié dernièrement que Java n'avait pas une bonne interopérabilité. Utiliser Java pour la plupart des entreprises impliquerait de jeter beaucoup de code, dont une grande partie a été payée d'une manière ou d'une autre.

En fait, il est très possible pour le code managé de faire des jeux 3D, le problème vient des moteurs de retour. Avec .Net, pendant une brève période, il y avait un wrapper DirectX géré pour DirectX 9 par Microsoft. C'était avant l'abstraction qui est maintenant XNA.

Étant donné l'accès total aux API DirectX, les jeux .Net fonctionnent un régal. Le meilleur exemple que je connaisse est www.entombed.co.uk, qui est écrit en VB.Net.

Malheureusement, du côté de Java, il manque sérieusement - principalement pour la raison que DirectX n'est pas disponible pour Java et que les programmeurs de jeux connaissent et comprennent l'API DirectX - pourquoi apprendre encore une autre API lorsque vous reviendrez à DirectX?

Le marketing de jeu est un processus commercial; les éditeurs veulent des retours sur investissement quantifiables à faible risque. En conséquence, l'accent est généralement mis sur les gadgets technologiques (à quelques exceptions près) que les consommateurs achèteront pour produire un retour fiable - il s'agit généralement d'effets visuels superficiels tels que l'éblouissement des lentilles ou une résolution plus élevée. Ces effets sont fiables car ils utilisent simplement des augmentations de puissance de traitement - ils exploitent le matériel / les augmentations de la loi de Moore. cela implique l'utilisation de C / C ++ - java est généralement trop abstrait du matériel pour exploiter ces avantages.

Je suppose que la vitesse est toujours le problème. La multiplateforme va être un problème, n'est-ce pas puisque vous ne savez pas quelle carte 3D est disponible lorsque vous écrivez le code? Java a-t-il quelque chose pour prendre en charge la découverte automatique des capacités 3D? Et je suppose qu'il existe des outils pour faciliter le portage d'un jeu entre la Wii, la Xbox et la PS3, mais je parie cher.

La ps3 a java, via le support blue ray. Consultez le site bd-j.

Même les jeux écrits sur la plate-forme .Net sont souvent hautement optimisés pour la vitesse comme l'accès direct à la mémoire et au bus. .Net permet d'utiliser C / C ++ et de le mélanger avec des langages de niveau supérieur tels que C #.

Les studios de développement de jeux travaillent souvent en étroite collaboration avec les fournisseurs de matériel, qui fournissent un accès aux interfaces de bas niveau de leurs produits. C'est un monde dans lequel vous devez utiliser ASM et C pour la communication des appareils. Un environnement virtuel ralentirait ces parties de programme.

Quoi qu'il en soit, les jeux 3D modernes utilisent en fait des langages de niveau supérieur. Souvent, vous trouverez la logique du jeu écrite dans des langages comme Lua ou Python. Mais le cœur (E / S, threads, planification des tâches) du jeu 3D typique sera écrit dans des langages de bas niveau pendant les 25 prochaines années ou tant que les appareils longs ne permettent pas l'abstraction et la virtualisation par eux-mêmes (ce qui viendra).

Je suis d'accord avec les autres articles sur l'exploitation des éléments d'une base de code préexistante / sous licence, les performances, etc.

Une chose que j'aimerais ajouter est qu'il est difficile de tirer de vilaines astuces DRM via une machine virtuelle.

Je pense aussi qu'il y a un composant hubris où les chefs de projet pensent qu'ils peuvent créer du code stable / fiable avec C ++ avec tous les avantages comme avoir un contrôle absolu sur leurs outils et ressources, MAIS sans tous les inconvénients qui compliquent et embourbent leur concurrence parce que «nous» re plus intelligents qu’ils ne le sont ».

Runescape by Jagex est écrit en Java, la balise "jeu vidéo" ne l'applique peut-être pas spécifiquement comme étant un jeu en ligne, mais il a un public décent.

On en a déjà beaucoup parlé, vous pouvez trouver même sur Wiki les raisons ...

• C / C ++ pour le moteur de jeu et tous les trucs intensifs.
• Lua ou Python pour les scripts dans le jeu.
• Java - très très mauvaises performances, grande utilisation de la mémoire + il n'est pas disponible sur les consoles de jeu (il est utilisé pour certains jeux très simples (oui, Runescape compte ici, ce n'est pas Battlefield ou Crysis ou quoi d'autre) juste parce qu'il y a beaucoup de programmeurs qui connaissent ce langage de programmation).
• C # - grande utilisation de la mémoire (il est utilisé pour certains jeux très simples simplement parce qu'il y a à peu près beaucoup de programmeurs qui connaissent ce langage de programmation).

Et j'entends de plus en plus de programmeurs Java qui essaient de convaincre les gens que Java n'est pas lent, il n'est pas lent pour dessiner un widget sur l'écran et dessiner des caractères ASCII sur le widget, pour recevoir et envoyer des données via le réseau (Et c'est recommandé de l'utiliser dans ce cas (manipulation de données réseau) au lieu de C / C ++) ... Mais c'est sacrément lent quand il s'agit de choses sérieuses comme les calculs mathématiques, l'allocation / manipulation de mémoire et beaucoup de ces bonnes choses.

Je me souviens d'un article sur le site du MIT où ils montrent ce que C / C ++ peut faire si vous utilisez le langage et les fonctionnalités du compilateur: Un multiplicateur de matrice (2 matrices), 1 implémentation en Java et 1 implémentation en C / C ++, avec des fonctionnalités C / C ++ et les optimisations appropriées du compilateur activées, l'implémentation C / C ++ était ~ 296 260 fois plus rapide que l'implémentation Java.

J'espère que vous comprenez maintenant pourquoi les gens utilisent C / C ++ au lieu de Java dans les jeux, imaginez Crysis en Java, il n'y aurait aucun ordinateur dans ce monde qui pourrait gérer cela ... + La collecte des ordures fonctionne bien pour les widgets qui viennent de détruire une image mais il est toujours mis en cache là-dedans et doit être nettoyé, mais pas pour les jeux, bien sûr, vous aurez encore plus de retards à chaque activation du ramasse-miettes.

Edit : Parce que quelqu'un a demandé l'article, ici, j'ai cherché dans les archives Web pour l'obtenir, j'espère que vous êtes satisfait ... Étude de cas MIT

Et pour ajouter, non, Java pour les jeux est toujours une idée horrible. Il y a quelques jours à peine, une grande entreprise que je ne nommerai pas a commencé à réécrire son client de jeu de Java vers C ++ parce qu'un jeu très simple (en termes de graphisme) était à la traîne et chauffait les ordinateurs portables i7 avec de puissantes cartes vidéo de génération nVidia GT 5xx et 6xx ( non seulement nVidia, le point ici est que ces cartes puissantes qui peuvent gérer les paramètres Max la plupart des nouveaux jeux et ne peuvent pas gérer ce jeu) et la consommation de mémoire était de ~ 2,5 - 2,6 Go de RAM. Pour des graphismes aussi simples, il faut une bête de machine.