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

78

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?

java game-development Anto
la source
37
Et attendez maintenant que toutes les réponses "Java, c'est lent, C ++, c'est rapide" qui ne touchent vraiment que la surface du problème d'une manière trop large et tout à fait correcte. Sachez que les personnes répondant de cette manière ne sont certainement pas des développeurs de jeux professionnels.
Ed S.
20
En fait, Java est utilisé pour le développement de jeux; c'est-à-dire sur le marché mobile. Java ME, Android.
user281377
21
Pourquoi devrait-il être utilisé? Qu'est-ce que Java offre à un développeur de jeux, que les langages les plus largement utilisés n'ont pas? Java fournit aux développeurs d’applications métiers un écosystème d’une richesse énorme, qui surpasse ses lacunes en tant que langage, mais s’agissant du développement de jeux, la plate-forme Java offre peu d’outils par rapport à un grand nombre d’alternatives.
back2dos
14
Fait intéressant, Minecraft est basé sur Java.
Uri
5
@Coder On dirait que le code C ++ a été fortement optimisé, mais pas le code Java. C'est donc une comparaison invalide.
Izkata le

Réponses:

95

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.

Uri
la source
14
+1 "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" Si le périphérique ne dispose pas du runtime , vous ne verrez pas les jeux développés en fonction de cette exécution indisponible. La Xbox 360 et le Windows Phone ont géré les exécutions .Net, ce qui permet de développer des jeux en les utilisant, ce qui constitue probablement une tendance croissante. Cependant, comme l'exécution ne figure pas sur les autres grandes plates-formes (PS3 et, dans une moindre mesure, sur la Wii), il est difficile de justifier une base de code complètement séparée. Ce n'est vraiment pas un problème de performance.
JustinC
2
Cela s'appelle XNA, qui est actuellement un sous-ensemble du framework .Net 2.0. Il existe quelques autres cadres intéressants dans la nature: MonoXNA, MonoTouch et XnaTouch, entre autres.
JustinC
7
La prévisibilité des performances n’est pas possible avec une machine virtuelle Java.
Klaim
5
Très bons points. Toutefois, j’ajouterais que le GC peut provoquer des pauses / charges imprévisibles. Si ce n'est pas un problème pour les applications serveur, c'est pour un jeu en temps réel. Ceci est par exemple visible dans Minecraft.
deadalnix
2
@Klaim Cela n'est pas non plus possible avec mallocou new, alors si c'est une préoccupation, vous allez mettre en œuvre le pooling, quoi qu'il en soit. Sans rapport avec ce point, un gros problème avec Java est qu’il ne prend pas en charge les types de valeur, contrairement à C #.
Doval
80

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.
Mikera
la source
19
Non, la protabilité n'est pas meilleure en Java dans le monde du jeu vidéo. La plupart des consoles n'ont pas de machine virtuelle. Pour des raisons de portabilité, C ++ est préférable à Java dans le monde du jeu vidéo.
deadalnix
5
Pourquoi l'écosystème de bibliothèque est-il un bonus pour Java? Mise en réseau, son, paires clé-valeur - ce n'est pas une chose; c'est disponible partout de nos jours. Je dirais même que l'IA et le traitement des images sont beaucoup plus faciles à réaliser avec les bibliothèques C / C ++ (fann, OpenCV).
MrFox
4
Plus important que FPS, je mettrais peut-être l'accent sur des taux de trame cohérents . Je peux faire tourner mon jeu à 100 images par seconde, mais si certaines de ces images prennent une demi-seconde, ce ne sera tout simplement pas le cas. Même si la GC est rapide, si elle cause des irrégularités notables, le problème persiste. (Cela ne dit rien sur les performances de Java en particulier, c'est juste un problème général à garder à l'esprit)
Gankro
1
J'ai écrit un jeu de tir à la première personne en Java et je n'ai jamais eu de problèmes avec le ramasse-miettes, même si je n'en ai pas utilisé un avec une faible latence. Quoi qu'il en soit, lorsque la mémoire n'est pas allouée sur le segment de mémoire Java, il m'appartient de la gérer sans le ramasse-miettes et la plus grande partie de mon empreinte mémoire provient des VBO. En d'autres termes, le garbage collection ne pose pas de problème car il fonctionne lorsqu'il est utilisé pour quoi il a été conçu et ce n'est pas à lui de gérer des objets volumineux sur le GPU ou sur le tas natif (! = Tas Java). Ne blâmez pas l’enclume de ne pas être un moyen efficace de se brosser les dents.
dimanche
1
@deadalnix Le monde du jeu vidéo ne se compose pas uniquement de consoles.
jeudi
27

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é.

utilisateur430788
la source
8

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

Graeme Wicksted
la source
Vous n'avez pas besoin d'écrire vous-même JNI, utilisez simplement JogAmp ou une bibliothèque similaire.
jeudi
Bon point. J'ai utilisé JOGL et JMonkeyEngine en Java. Plus récemment, j'ai utilisé XNA / MonoGame pour DirectX et OpenTK pour OpenGL avec nvorbis / naudio / openal en C #. Et ils fonctionnent très bien pour les jeux de petite et moyenne taille, en particulier lorsque vous travaillez avec des shaders. Grande amélioration de la productivité par rapport à C ++. Ensuite, votre seul véritable problème est identique à celui de tout langage basé sur le GC: empêcher / atténuer le GC. Il ralentira périodiquement votre framerate, vous aurez donc besoin de tableaux de taille fixe, d'allocations statiques ou de mémoires tampons longue durée pouvant être lancées lorsque le jeu est bloqué (menus, chargement, cinématiques).
Graeme Wicksted
J'utilise JOGL depuis 2006 et je n'ai pas eu ce type de problème, même sur du matériel très bas de gamme dans un environnement de bureau. Le ramasse-miettes n'est pas à blâmer car les objets les plus volumineux sont souvent soit dans la RAM du GPU, soit dans le tas natif (généralement les tampons NIO directs), le premier n'est pas géré par le garbage collection "normal" et le second n'est pas " t directement géré par la corbeille "normale" car elle prend en charge les objets Java sur le tas Java. Il appartient au développeur de libérer efficacement la mémoire allouée sur le segment de mémoire natif.
dimanche
À mon humble avis, le problème vient plutôt de quelques "optimisations" imaginées par des programmeurs qui ne sont pas dans un état d'esprit Java qui empêche le garbage collector de faire son travail. Si vous conservez des références fortes sur des objets Java inutiles liés à des ressources natives, le récupérateur de place ne les considérera jamais comme récupérables. L'affectation hors du tas peut être utile dans certains cas, mais si vous en abusez, vos ressources à vie longue resteront en mémoire et vous ne pourrez pas créer de nouveaux objets.
dimanche
Certains programmeurs de jeux préfèrent allouer d’énormes tampons au début, les découper au moment de l’exécution et gérer cette mémoire eux-mêmes, mais ils feront probablement pire que le système d’exploitation, puis Java passera beaucoup de temps à libérer de l’espace pour créer de nouveaux objets. Eviter les fuites de mémoire n’est pas plus difficile en Java et une solution plus viable consiste à ne suivre que les objets dont la mémoire n’est pas allouée sur le tas Java pour les libérer au moment opportun (pendant une pause, lors du passage d’un niveau à un autre). , ...), cela n’a rien à voir avec le ramasse-miettes.
jeudi
5

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.

BBlake
la source
17
Vous laissez de côté l'un des points les plus importants. la grande majorité des outils et des API utilisés seraient écrits en C ++ et leur réécriture pour fonctionner avec Java ou tout autre langage représenterait une tonne de travail. En outre, votre généralisation selon laquelle "[Java est] beaucoup plus lent que l'utilisation de C ++ / Assembly " est trop large pour être précise. L'assemblage n'est pas utilisé aussi souvent que vous le pensez dans les jeux PC, car un bon compilateur générera probablement un code plus efficace que l'écriture d'assembleur. L'utilisation déterministe des ressources et la capacité à maîtriser le matériel sont toutefois indispensables.
Ed S.
15
Quelqu'un a vraiment besoin de créer un meilleur exemple des capacités de Java que Minecraft. Tant que personne ne pourra créer l’équivalent de WoW, C & C, MOH ou Starcraft en Java ou en C #, je continuerai à tenir ce que j’ai dit.
BBlake
12
"L’assemblage n’est pas utilisé aussi souvent que vous le pensez dans les jeux PC, car un bon compilateur générera probablement un code plus efficace que l’écriture en assembleur." C'est une autre généralisation. Je n'ai pas encore vu de compilateur capable de générer un meilleur langage machine IA32 qu'un programmeur expérimenté en langage d'assemblage IA32. Les compilateurs génèrent du code pour une machine abstraite mappée sur une machine cible. Un programmeur en langage assembleur tire pleinement parti du processeur sous-jacent, notamment des idiomes de la machine.
peu-twiddler
10
N'oubliez pas l'utilisation de la mémoire. L'utilisation de la mémoire est probablement plus importante que la vitesse. Java n'est pas conçu pour le contrôle direct de la mémoire comme C ++ et le ramasse-miettes signifie que l'utilisation de la mémoire est toujours nettement supérieure à C ++ pour la même tâche.
Matthew Lu
9
Ce n'est pas 1985. Nous avons plus de 640k de mémoire, mieux que des processeurs de 50 mégahertz, et plus de 1,44 mbs de stockage amovible. Le défi des développeurs de jeux aujourd'hui n'est plus le même qu'il y a 25 ans. Allez-y et trouvez un exemple de code x86 / ou ia64 fabriqué à la main pour un jeu moderne. Certains mythes sont tout simplement faux. Le défi est la portabilité et les clients de bas niveau qui utilisent des environnements d’exploitation relativement anciens. Plus petit dénominateur commun contre une immersion convaincante.
JustinC
5

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.

utilisateur1249
la source
1
oddlabs.com/technology.php - "Nous avons basé notre développement sur la combinaison de LWJGL et de Java, qui permet au jeu de fonctionner sur toutes les plates-formes prises en charge par LWJGL sans modifications et à une vitesse comparable à celle d'un code natif dépendant de la plate-forme."
Jake2 a dépassé Quake2 il y a plus de 10 ans. Nous ne sommes plus en 2002.
gouessej
4

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).

dan_waterworth
la source
4

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.

Jerry Coffin
la source
Je pense que vous avez touché un problème important avec les moteurs de jeu - je pense que c'est la principale raison pour laquelle Java n'a pas rattrapé C / C ++. Cependant, il est possible que l'open source nivelle un peu le terrain de jeu - j'ai été très impressionné par jMonkeyEngine ( jmonkeyengine.com ).
Mikera
et n'oubliez pas que les développeurs de jeux sont extrêmement conservateurs (techniquement), et que la plupart des grands magasins (influents) existent depuis des décennies et sont centrés sur C (++) / ASM, ils ne vont donc pas investir dans le développement Java, cela impliquerait un investissement considérable en temps, en argent et en autres ressources dès la mise en place d'une architecture C (++) / ASM complète.
Jwenting
1

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.

Meh
la source
0

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.

Mahmoud Hossam
la source
3
Mais C ++ n'était pas non plus un langage de jeu, mais en tant que langage de programmation système tout comme C. Et Sun a fait des efforts sur Java en tant que langage de jeu. Je pense qu'ils coopéraient avec Sony pour amener Java à la PS2 ou quelque chose, mais ce n'est jamais arrivé ...
Anto
1
@Phobia: Mais il a été conçu pour la programmation système.
Anto
1
@Phobia: Je dis qu'il est un langage de programmation à usage général , comme C ++. Dans votre réponse, vous dites que Java n'a pas été conçu comme un langage de programmation de jeux, mais vous oubliez que le C ++ n'est pas non plus conçu comme ça.
Anto
2
@ Joe Blow: Extrait de la page Wikipedia sur C: "Bien que C ait été conçu pour implémenter un logiciel système , il est également largement utilisé pour développer des logiciels d'application portables." Je pense que c'est assez clair, n'est-ce pas?
Anto
2
@ Phobia Je suis désolé de vos préférences personnelles, mais elles ne sont absolument pas pertinentes pour la discussion. En outre, je ne veux pas contester le fait qu'aujourd'hui, le C ++ est utilisé presque exclusivement dans la programmation d'applications. Ce n’est pas le sujet de cette discussion. Vous affirmez que Java a été conçu pour la programmation Web. Eh bien, C ++ a été conçu avec la programmation système à l’esprit. Dit son concepteur. Fin de la conversation.
Konrad Rudolph
-1

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.

hotpaw2
la source
-4

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.

Echo dit Réintégrer Monica
la source
cela se lit plus comme un commentaire, voir Comment répondre
gnat
-8

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.

programmeur mythique
la source
1
Vous devriez lire sérieusement sur la compilation JIT, et regarder quelques points de repère où Java est comparé à C ++
Anto
1
Qui diable a voté contre cette réponse? Toute cette question devient incroyablement ridicule! Bon chagrin
Fattie
7
@ Joe La réponse est fausse. Java n'est pas interprété.
Konrad Rudolph
3
@Anto Forget ces repères stupides. C ++ est un ordre de grandeur plus rapide que Java, voir programmers.stackexchange.com/questions/29109/29136#29136 et programmers.stackexchange.com/questions/368/13888#13888 .
Konrad Rudolph
1
@Anto Qu'est-ce que je suppose de regarder? La vitesse? C ++. Utilisation de la mémoire? C ++. Regardez minecraft et essayez d’héberger un serveur et voyez combien de mémoire le jeu utilise. Java consomme beaucoup plus de mémoire que le C ++. Faire un jeu en ligne, j’imagine que c’est assez difficile en Java. Tous les tests que j'ai vus jusqu'à présent consomment plus de mémoire. Maintenant, avoir un jeu mmorpg dans lequel le serveur central est codé en java ne sonne bien que si vous ignorez l'aspect mémoire ou modifiez la définition de massive dans MMORPG.
mythicalprogrammer