Moteurs de jeux Java [fermé]

en général, tout ce qui est dit ici est une raison de ne pas porter sur Java pour le développement du jeu; . L'industrie du jeu est actuellement frapper un changement de paradigme. Trois choses ont changé ou sont en train de changer l'industrie du jeu:

• Piratage
• Client-serveur de modèles de programmes
• modÃles de programmes de rà © seautage modulaires

un jeu ne dépend plus entièrement de lui-même. Les principaux avantages qui existant dans les premiers (les langues de bas niveau) ralentissent d'être pesé par les avantages qui existent dans les langues comme C# et Java (les langues de haut niveau). Deux exemples grossiers mais indéniables sont des jeux qui fonctionnent sur Facebook et distance de supports, tels que les téléphones, les tablettes, etc.

il est important de préciser que, dans les deux scénarios, les trois préoccupations susmentionnées sont dissoutes. Un jeu qui ne peut fonctionner sans un serveur n'a pas besoin de s'inquiéter d'être copie contrefaite (hébergement privé par rétro-ingénierie non inclus). La demande pour les jeux dépendant du réseau nécessite un langage qui peut équilibrer les performances du système avec les performances du réseau (généralement un impasse entre Java et C / c++,favorisant C/C++ strictement en raison de l'abondance de bibliothèques préexistantes). Cependant, un jeu conçu dans un module de programme de réseau modulaire ne serait pas pratique à développer dans des langages de bas niveau tels que C/C++. Une société qui serait intéressé à concevoir un jeu en C/C++ pour un modèle de programme de réseau modulaire devrait créer une machine virtuelle entièrement consacrée à ce jeu, ou reprogrammer/recompiler le jeu un certain nombre de fois trop fou à penser. IMO, bien qu'il soit peut-être trop tôt pour dire quelle langue sera préférée, je mets mes paris sur Java pour trois raisons principales.

• 1) la JVM permet aux applications basées sur Java de fonctionner virtuellement sur n'importe quelle plate-forme, que ce soit Apple, Android, Windows 8, ou Linux/UNIX dérivé (pratiquement de soutien sur toute plate-forme matérielle).

• 2) Java utilise OpenJL (le dérivé D'OpenGL, qui s'exécute sur OpenGL en tant que client - jMonkey est un moteur conçu en OpenJL). Il est important de noter que seul Microsoft Windows utilise DirectX, comme bon comme il peut être, il y a une seule tirer en arrière. Pratiquement tous les OS qui peuvent exécuter des jeux seront capable de rendre en OpenGL et la conception modulaire pousse sur ce comme jamais auparavant. (Veuillez note, Microsoft tente de dévier cette question en monopolisant sur la distribution de Windows 8).

• 3) Java prend en charge le threading interne au sein de la JVM, ce qui lui permet pour profiter pleinement des processeurs multi-core sans l'utilisation de toute bibliothèque tierce. Actuellement, c'est un handicap pour tous les autres les langues (spécialement celles développées pour les téléphones).

la réponse à votre question Est artwork et ressources financières. Et à L'origine Minecreft a été développé par une personne à java. Alors que les titres comme AC ou NFS sont développés à partir d'équipes de milliers de personnes. Comparez les ressources. De plus, Ubisoft utilise le moteur de jeu custom. Si vous êtes seul développeur, vous devriez vous concentrer sur l'idée en raison du manque de ressources. Et si vous avez une idée, le collecteur garbege est imprenable dans les jeux de développeur sole normaux. Et en tant que développeur unique, vous devriez choisissez la technologie de développement la plus rapide.

je voulais juste aborder un sujet de côté de cette question, mais la collecte des ordures n'est pas nécessaire pour créer les aspects de bas niveau, la performance critique d'un moteur de jeu de type AAA. En fait, éviter ce genre de référencement et de système de collecte pour les objets est utile. Vous voulez que même les types définis par l'utilisateur soient contigus en mémoire et s'adaptent aux objets adjacents dans le cache, etc.

à part les problèmes de performances de la collecte des ordures à intervalles réguliers et de dispersant des objets dans la mémoire, les jeux ne peuvent pas se permettre d'être fuyante avec leurs ressources plus volumineuses, et le collecteur d'ordures entrave les choses là. Oui, j'ai juste dit que le GC empêche la capacité d'éviter les fuites.

la collecte des ordures N'est pas une solution miracle contre les fuites de ressources.

aussi contre-intuitif que cela puisse paraître, regardez les applications qui fuient le plus: celles où plus vous les utilisez, plus l'utilisation de la mémoire est importante. continue à augmenter. En général, ce ne sont pas des applications C ou C++. Applications C/C++ peuvent être connus pour s'écraser, mais pas tellement pour les fuites. Ceux qui fuient sont beaucoup plus souvent programmés dans des langages avec collecte des ordures.

par exemple, prenez Flash games. Il ya beaucoup là-bas, et pas seulement un logiciel amateur complet, qui utilisent de plus en plus de ressources et obtenir de plus en plus lent plus vous jouez le jeu, vous forçant parfois à redémarrer votre navigateur pour obtenir le jeu rapide à nouveau. Pourtant, ils sont codés en ActionScript, un langage qui a la collecte des ordures.

en théorie, la collecte des ordures devrait réduire les fuites. En pratique, il élimine souvent les fuites physiques moins chères et plus faciles à réparer et à repérer (whoops j'ai oublié de supprimer cette chaîne) en échange de fuites logiques beaucoup plus coûteuses et difficiles à isoler (whoops, la logique du système provoque des ressources volumineuses à traîner autour jusqu'à ce que le jeu entier est arrêté).

C'est parce que dans un langage GC, si vous voulez créer une propriété partagée d'une nouvelle ressource,R, tout ce que vous avez à faire est de stocker une poignée de référence à un autre objet, A. B et C peut aussi stocker une poignée pour R et R a trois propriétaires et ne sera libéré que si les trois propriétaires libèrent la référence. L'utilisateur ne voit et travaille avec ce A stores, de sorte que la logique du jeu implique de supprimer RA périodiquement, mais les références à s'attarder autour de B et C silencieusement que le code a oublié de relâcher. En C / C++, le pointeur pendulaire ici en B et C peut en fait être préférable, car cela conduirait à un problème immédiatement détectable et corrigeable pendant le test de jeu, où le développeur qui exécute un débogueur va très rapidement repérer et corriger le problème. Dans un langage GC, c'est extrêmement difficile à détecter et bien que le programme ne s'écrasera pas, il peut commencer à fuir à grande échelle.

donc GC évite définitivement pointeurs pendants, mais si quelque chose avait été suspendu en C/C++ et ne serait pas suspendu dans un langage GC, alors c'est une fuite de ressource logique dans un langage GC et une erreur de segfault en C/C++. Autrement dit, le GC échange des pointeurs pendants pour des ressources pendantes qui traînent autour pour toujours. Il échange ce qui serait un crash flagrant dans une fuite silencieuse qui peut être un cauchemar de débogage à découvrir (et peut même passer inaperçu longtemps après la sortie du produit). Donc pour quelque chose comme un jeu qui est créer des mondes massifs et dynamiques et des objets graphiques et physiques et ainsi de suite et peut-être à chaque image, fuites de ressources logiques sont une grosse affaire.

la collecte des ordures est préférable lorsque les fuites de ressources ne sont pas importantes.

ce scénario précédent est malheureusement trop courant dans un environnement d'équipe à grande échelle utilisant la GC, surtout si chaque programmeur n'est pas très prudent des pièges de la collecte des ordures et du besoin fort de références faibles. Donc, GC n'est pas nécessairement quelque chose à citer comme un avantage pour faire des jeux, à moins que vous ne parlez que du niveau le plus élevé de la logique humaine. La logique de système de niveau inférieur et délicat qui doit constamment créer, accéder et détruire des ressources va généralement mieux se passer, même en termes d'éviter les fuites, sans elle.

il n'est pas tout à fait vrai que la collecte des ordures n'est pas utilisée dans l'industrie du jeu. Unreal Engine 3 dispose d'une collecte des ordures implémentée pour les classes' Script'. Pour eux, la performance est acceptable lorsqu'il est utilisé à la légère; le levage lourd est fait par C / C++ code qui gère sa propre mémoire.

comme fortran l'a dit, Java n'est pas vraiment utilisé dans l'industrie du jeu en raison de préoccupations sur la vitesse (Java exécute le code sur une VM, pas nativement... la plupart du temps) et parce qu'il y a déjà un grand nombre de programmeurs de jeu talentueux qui ont écrit beaucoup de code souvent utilisé en C et C++. Cela ne veut pas dire que vous ne pouvez pas utiliser Java pour faire un jeu, parce qu'il y a quelques jeux Java là-bas, mais l'industrie du jeu 'mainstream' a investi massivement dans un backend C / C++.

fortran et James l'ont déjà assez bien couvert, mais une autre chose que j'aimerais mentionner, ce que fortran a laissé entendre en parlant d'inertie, c'est le gigantesque réservoir de bibliothèques disponibles en C++. Avoir plusieurs bibliothèques C++ pour presque tout ce à quoi vous pouvez penser est une énorme raison de ne pas passer à Java. Cela ne veut pas dire qu'il n'y a pas de bibliothèques pour Java en ce moment, mais les bibliothèques C++ sont déjà arrivées à maturité et ont de grandes communautés de développeurs expérimentés. Pas avoir à réécrire la même chose que vous avez fait 1000x avant est un grand gain de temps.

vous pouvez trouver des jeux écrits en java(moteur jmonkey entièrement écrit en java).

Ici -->"http://www.indiedb.com/engines/jmonkeyengine/games".

1.la hausse mondiale .

2.de minecraft.

3.mynthurana.

tout en jmonkey engine. La qualité de leurs graphismes sont intenses et les défis sont bons.

je dirais exigence de développement de jeu est d'avoir un minimum de deux personnes. Java est OK.