Pourquoi Java n'est-il pas plus largement utilisé pour le développement de jeux? [fermé]

Je ne suis pas un développeur de jeux ou quoi que ce soit, mais je sais que Java n'est pas très utilisé pour le développement de jeux. Java devrait être assez rapide pour la plupart des jeux, alors où est le piège? Je peux penser à quelques raisons:

• Manque de développeurs de jeux experts en Java
• Manque de bons cadres de développement de jeux
• Les programmeurs ne veulent pas accepter Java comme langage de programmation de jeux. La plupart acceptent seulement C ++ comme ça?
• Pas de support pour les consoles de jeux (bien que le marché des PC existe toujours)

Cela pourrait bien sûr être autre chose. Une personne connaissant mieux le secteur que moi pourrait-elle expliquer pourquoi Java ne prend pas de vitesse en matière de développement de jeux?

Plusieurs raisons:

• Auparavant, vous aviez besoin d'un "accès direct" pour les performances et l'interface utilisateur. Cela précède les langages VM tels que Java et C #
• La plupart des consoles (par exemple 360 ​​et PS3) ne disposent pas de machine virtuelle Java. Vous ne pouvez donc pas réutiliser le code de la version PC. Il est beaucoup plus facile de compiler du code C ++ pour prendre en charge divers périphériques.
• La plupart des moteurs de jeu traditionnels (par exemple, Unreal) ont des liaisons C ++. Il existe certains connecteurs Java (par exemple, pour OpenGL) mais rien de tel.
• Pour les jeux sur PC, DirectX n’a pas vraiment de support Java (le cas échéant).
• Les jeux Web fonctionnent en JavaScript ou en Flash. Vous pouvez les écrire en Java en utilisant des éléments tels que GWT.
• L'iPhone exécute une variante Objective-C.

Java est principalement utilisé dans les jeux Android de nos jours, tout simplement parce que c'est le langage principal de cette plate-forme.

Raisons techniques:

• La plupart des meilleurs moteurs de jeux 3D sont écrits en C / C ++. C'est un gros problème, car la plupart des développeurs de jeux ne veulent pas faire de compromis sur leur moteur 3D, mais ils ne veulent pas non plus en écrire un à partir de zéro. Java a jMonkeyEngine qui est open source et vraiment très bon mais il ne peut toujours pas concurrencer le moteur Unreal .
• Dans certains cas très rares, il est avantageux de se rapprocher du métal en langage C ou en assembleur, notamment pour accéder à des fonctionnalités matérielles spéciales. Ce n'est pas si important de nos jours, mais les développeurs de jeux professionnels aiment toujours avoir la possibilité .....
• Java a un environnement d' exécution collecté et géré. C'est un avantage énorme dans 99% des cas, cela facilite certainement le codage et le rend moins sujet aux erreurs, et c'est l'une des principales raisons pour lesquelles Java est si populaire. Toutefois, cela entraîne parfois un problème de latence pour les jeux, car les cycles de récupération de place peuvent entraîner des pauses sensibles. Cela devient de moins en moins un problème avec les nouvelles JVM à faible temps de latence, mais reste un problème pour les jeux à forte intensité graphique où le maintien de FPS élevés est essentiel.

Raisons non techniques:

• Les maisons de développement de jeux professionnelles investissent énormément dans les compétences et les technologies C / C ++. Cela crée une énorme inertie .
• La perception largement irrationnelle que Java est lente. Peut-être vrai dans les années 90, mais certainement pas maintenant: vous pouvez écrire un jeu 3D commercialement rentable avec Java ( Runescape, n'importe qui? Ou que diriez-vous de Minecraft ?)
• Une perception plutôt juste que Java est davantage centré sur les applications métier et le Web que sur les jeux. Cela pourrait changer avec la croissance de Mobile et la nécessité de développer davantage le développement multi-plateformes, mais est certainement vrai à l'heure actuelle.

Il est intéressant de noter que les développeurs de jeux devraient également envisager Java:

• Portabilité : à mesure que le nombre de plates-formes cibles se multiplie, Java devient de plus en plus attrayant grâce à sa capacité pratiquement inégalée à créer des binaires véritablement multiplates-formes.
• Écosystème de bibliothèques - à l'exception très importante des moteurs de jeux 3D, Java propose la meilleure gamme de bibliothèques de toutes les plates-formes. Mise en réseau, son, intelligence artificielle, traitement d'image, magasins de données de clé / valeur, vous nommez le sujet et il y a probablement une bibliothèque Java open-source pour ce sujet.
• Développement côté serveur - Java est une excellente langue / plate-forme pour le serveur et, à mesure que de plus en plus de jeux incorporeront des éléments massivement multijoueurs, le côté serveur deviendra de plus en plus important. Java sous Linux est assez convaincant ici en tant que plateforme.
• La JVM - est probablement le meilleur environnement d’exécution de machine virtuelle au monde, avec une récupération des ordures fantastique, un compilateur JIT, une prise en charge de la simultanéité, etc. le meilleur environnement d'exécution possible.
• Autres langages JVM - Java est un outil de travail solide, mais la véritable innovation concerne les nouveaux langages JVM (Scala, Clojure en particulier). Ces langages bénéficient de tous les avantages de la plate-forme Java / JVM et constituent des langages modernes extrêmement puissants.

D'accord, il y a beaucoup de désinformation dans ce fil.

Je connais très bien le secteur du jeu vidéo depuis 25 ans. Je connais aussi très bien Java dans les jeux, ayant été l’évangéliste technique des jeux Java de Sun et expert en programmation de performances Java.

En termes de vitesse de calcul, Java bat le C ++ dans de nombreux tests de calcul scientifiques. Vous pouvez écrire du code pathologique dans l'une ou l'autre langue qui fonctionne mal si vous le souhaitez, mais dans l'ensemble, ils sont au pair et ce depuis longtemps.

En termes d'utilisation de la mémoire, Java a une surcharge. HelloWorld est un programme 4K en java. Mais cette surcharge n'a pas beaucoup de sens dans les systèmes multi-Go actuels. Enfin, Java a plus de temps de démarrage. Je ne recommanderais pas l'utilisation de Java pour des utilitaires d'exécution courts tels que les commandes en ligne de commande Unix. Dans ces cas, le démarrage dominera votre performance. Dans un jeu cependant, c'est assez insiginficant.

Le code de jeu Java correctement écrit ne souffre pas de pauses GC. Tout comme le code C / C ++, il nécessite une gestion de mémoire active, mais pas au niveau requis par C / C ++. Tant que vous conservez votre utilisation de la mémoire pour des objets à longue durée de vie (persister pour un niveau entier ou un jeu) et des objets de très courte durée (vecteurs et autres, transmis et détruits rapidement après le calcul), gc ne devrait pas être un problème visible.

En termes d’accès direct à la mémoire, Java l’a eu pendant très longtemps; depuis Java 1.4 sous la forme de Native Direct Byte Buffers. Un peu de tournoiement en Java peut être légèrement ennuyeux en raison de l'absence de types entiers non signés, mais les étapes de travail sont toutes bien connues et pas très lourdes.

Bien que son véritable Java n’ait jamais eu de liaison Direct3D, c’est parce que les technologies Java aspirent à la portabilité. Il a DEUX liaisons OpenGL (JOGL et LWJGL) et OpenAL (JOAL) et une liaison d'entrée portable (JInput) qui se lie sous le capot à DirectInput sur Windows, HID Manager sur OSX et une liaison Linux (je ne sais plus laquelle).

Il est vrai que, dans Unity, aucun moteur de jeu complet ne présente Java comme C #, c’est une faiblesse de l’espace indépendant. D'autre part, il y avait deux bons APIS de niveau Scenegraph totalement portables sur une plate-forme Windows, OSX et Linux. Tous deux écrits par Josh Slack, le premier s'appelait JMonkey engine et le second Ardor3D.

L’affiche du haut indique avec exactitude que les deux éléments les plus importants qui ont freiné Java dans le développement de jeux étaient les préjugés et la portabilité. Ce dernier était le plus gros problème. Bien que vous puissiez écrire un jeu Java et l’envoyer sous Windows, OSX et Linux, il n’ya jamais eu de machine virtuelle sur console. Cela était dû à l’inefficacité totale des cadres moyens de Sun. Les quelques-uns d’entre nous qui travaillions sur Java dans les jeux avaient en fait passé un contrat avec Sony pas moins de 3 fois pour obtenir un ordinateur virtuel sur une Playstation et les 3 fois que les cadres moyens de Sun l’aient tué.

Bien que Sun ait flirté avec les technologies client, le fait est que la direction de Sun n’a jamais eu de produits grand public. C’est pourquoi Java en tant que langue client de Sun n’a jamais réussi sous aucune forme, et pourquoi il a fallu Google et Dalvik (la machine virtuelle de type java Android) pour faire de Java un succès de plate-forme n’importe où.

Et c’est pourquoi je code les jeux en C # aujourd’hui. Parce que Mono est allé là où la direction de Sun a refusé.

Java est idéal pour la logique métier, les serveurs et le code indépendant de la plate-forme qui doit fonctionner de manière fiable. Plusieurs facteurs expliquent pourquoi Java n’est pas souvent utilisé dans les jeux:

• vérification des limites et autres mécanismes de sécurité (différence de performance marginale de nos jours)
• avoir à convertir entre les structures de données C ++ et les structures de données Java (ne peut pas simplement copier la mémoire entre les tampons)
• la plupart des livres et tutoriels suivent la foule, il est donc difficile de trouver des informations sur les développeurs de jeux non C ++
• les principales bibliothèques graphiques (DirectX et OpenGL) et de nombreux moteurs standard sont basés sur C / C ++
• de nombreux jeux essaient de fonctionner aussi vite que possible pour pouvoir ajouter des fonctionnalités plus attrayantes

Il n’est pas facile de travailler avec des bibliothèques C ++ à partir de langages bytecode tels que Java (écriture d’une couche JNI) et .net (nombreux attributs de marshalling / unmarshalling, api / structure). Cela ajoute donc un peu de travail pour peu d’avantages.

Une note de côté: certains serveurs de jeux utilisent Java.

Poste similaire ici : https://stackoverflow.com/questions/1034458/why-arent-video-games-written-in-java

Java n'est pas assez rapide pour la plupart des développements de jeux. C'est beaucoup plus lent que d'utiliser C ++ / Assembly, qui est la norme. C'est la même raison pour laquelle plus de développement de jeux n'est pas fait en utilisant C # ou VB. Les développeurs de jeux ont besoin et planifient chaque dernier cycle d'horloge qu'ils peuvent se procurer pour des tâches telles que les calculs de physique, la logique de l'intelligence artificielle et les interactions avec l'environnement.

Pour des jeux plus simples, Java pourrait être utilisé assez efficacement. Si vous voulez créer un clone Tetris ou Bejeweled, ou autre chose de ce niveau de détail, alors Java fonctionnerait bien. Mais Java ne peut pas créer de jeux comme Halo, Medal of Honor, Command & Conquer, etc., et le rendre jouable. Du moins tel qu'il existe aujourd'hui.

Et les raisons que vous avez énumérées dans votre question sont également valables. Sauf, je pense, pour le manque de développeurs de jeux avec une expertise Java. De nombreux jeux sur les téléphones et autres appareils portables sont écrits en Java (y compris la plupart des jeux Android), et certains jeux sont plutôt excellents. Je pense donc qu'il existe une base décente et croissante de développeurs de jeux avec des connaissances en Java.

L'idée est en train de changer sur la possibilité d'utiliser ces langages de niveau supérieur pour certains des jeux les plus avancés. Par exemple, l'un de mes jeux préférés, Auran's Train Simulator, est écrit avec de grandes portions en C #, et cela fonctionne assez bien. La base grandit donc et continuera d'évoluer.

Les jeux modernes se résument à des graphiques 3D se déroulant dans un matériel spécifique.

Même en 2002, Jacob Marner avait découvert dans son rapport "Evaluating Java for Game Development" que Java était tout à fait utilisable pour les jeux, à l'exception des composants les plus dépendants des performances, et en raison de la robustesse du langage et du fait que la JVM sous-jacente était moins chère. faire de cette façon.

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

Mon opinion personnelle est qu’avec les progrès réalisés depuis, en particulier dans le graphisme 3D, et avec les excellentes liaisons avec OpenGL et autres, cet inconvénient est beaucoup moins prononcé de nos jours.

Le problème doit donc être ailleurs. Une raison probable est la taille de l'exécution Java (qui est beaucoup moins un problème de nos jours avec des jeux multi-DVD), et une autre l'inertie du code existant. Il est notoirement fragile de commencer à travailler avec du code natif en Java. Une troisième raison est ce que les développeurs étoiles faisant les jeux sont familiers. Une quatrième est de savoir si Java est disponible sur la plate-forme.

Une chose est sûre cependant: la plupart des jeux sont en train de devenir des scripts, au lieu de tout graver depuis le début en code C, et vous voulez une meilleure exécution en-dessous de votre langage de script. De nos jours, cela signifie essentiellement soit le CLR, soit la JVM.

Les développeurs de jeux aiment être proches du métal et écrivent souvent leurs boucles internes serrées lors de l'assemblage. Java n'offre pas le même niveau de performances possible, à la fois en termes de vitesse constante et d'utilisation de la mémoire (l'exécution d'un JIT est coûteuse).

Je pense que le facteur limitant pour la plupart des gens est la (manque de) disponibilité de bons moteurs de jeu. Pour aller très loin, nous devons examiner pourquoi ces ressources ne sont pas disponibles.

Je regarderais cela de l’autre direction pour un moment. Développer un moteur de jeu (par exemple) demande beaucoup de travail. Qui gagnerait suffisamment à en développer un pour investir le temps et les efforts nécessaires?

La plupart des candidats évidents pour un développement de type framework dans / pour Java (par exemple, IBM ou Oracle) ne semblent avoir aucun intérêt pour les jeux. Les candidats évidents pour le développement de jeux (par exemple, Id, EA) semblent s'intéresser presque également à Java.

Google est presque le seul candidat qui me semble raisonnable. Le langage de développement principal pour Android est Java, et encourager le développement de jeux pour Android pourrait constituer un réel avantage pour la plate-forme.

Autant que je sache, ils ne l'ont pas encore fait (encore?), Ce qui laisse des limites assez sévères à presque quiconque. Le fait d'utiliser des moteurs de jeu modernes et hautes performances pour utiliser le développement sur Java représente une charge de travail supplémentaire considérable, avec (ce qui me semble tout à fait à mon goût) peu de chances de produire beaucoup d'avantages en retour de ce travail supplémentaire.

La question est sur le même plan de demander quelque chose dans les lignes de:

Quoi de mieux pour alimenter votre voiture, un moteur de bateau ou un moteur à réaction.

Cela dépend de l'évolutivité, de l'évitement des bogues, de la rapidité, de la signature de la mémoire, de la modularité et d'une foule d'autres choses. La question ne devrait pas être de savoir ce qui est le mieux en tant que norme de l’industrie, mais plutôt de savoir "ce qui est mieux pour moi", comme dans ce que vous savez ou dans quelle mesure vous le connaissez bien. S'il fait le travail, alors il fait le travail, si vous pouvez réellement vendre l'idée, alors cela fonctionne et qui sait, vous pourriez même plier quelques cuillères.

Java n'a pas été conçu pour le développement de jeux, il a été créé pour être un langage "pour le Web".

En ce qui concerne le développement de jeux, Sun n'a pas vraiment pris en charge Java en tant que langage de développement de jeux, car C # était soutenu par Microsoft.

Je pense que le manque de frameworks de développement de jeux convaincants est ce qui a vraiment tué Java dans cet aspect.

Il est plus facile de coller C plus directement sur de nouveaux matériels et pilotes non conventionnels. Plus tôt un programmeur de jeu peut se rapprocher du matériel, mieux il peut surpasser les jeux concurrents. Les programmeurs de jeux ultérieurs s'en tiennent simplement à la même méthodologie et aux mêmes outils que ces jeux précédemment éprouvés.

Pour les jeux où l'optimisation au matériel le plus récent est moins importante, comme les jeux occasionnels sur téléphone portable, l'utilisation de C de cette manière est moins importante que la plus grande portabilité de Java.

Pour certaines personnes, la raison n'a rien à voir avec la vitesse, les bibliothèques ou la disponibilité. C'est simplement à cause de la langue elle-même. Certaines personnes n'aiment tout simplement pas le langage Java. D'autres personnes préfèrent utiliser leur langage de programmation préféré plutôt que Java pour créer des jeux.

Cela pourrait bien sûr être autre chose. Une personne connaissant mieux le secteur que moi pourrait-elle expliquer pourquoi Java ne prend pas de vitesse en matière de développement de jeux?

C'est un langage d'interprétation, c'est-à-dire lent. Vous avez affaire à un graphique et à une carte graphique qui est du matériel. Qu'est-ce qu'un bon langage pour gérer le matériel? Eh bien, C ++, il est assez faible, et vous traitez avec des pointeurs et ainsi de suite.

Si vous voulez afficher des graphiques fous comme Crysis et tout ce que vous n'allez pas faire en Java pour cela.

Non seulement cela, Oracle appartient à Java, la pensée qu’une entreprise peut vous poursuivre en justice n’est pas très audacieuse. Surtout lorsque vous souhaitez créer votre propre interpréteur pour JAVA afin de cibler les jeux sans être poursuivi en justice en raison de la fragmentation FUD.