Quels sont les pièges typiques lors de l'écriture de jeux avec un langage géré tel que C #? [fermé]

Quelles difficultés avez-vous rencontrées lors de la création de jeux pour PC avec un langage géré tel que C # et comment les avez-vous résolues?

Je ne connais pas grand chose à Java, c'est donc du point de vue d'un développeur .net.

Le plus gros de loin est la poubelle. Le ramasse-miettes .NET de Windows fait un travail fantastique, et vous pouvez vous en sortir sans laisser le bébé s'asseoir pour la plupart. Sur la Xbox / Windows Phone 7, le problème est différent. Si vous obtenez des décrochages toutes les quelques images, la récupération de place peut vous causer des problèmes. Pour le moment, il se déclenche après chaque allocation de 1 Mo.

Voici quelques conseils pour faire face aux ordures. Vous ne devriez pas avoir à vous soucier de la plupart de ces problèmes dans la réalité, mais ils pourraient vous être utiles un jour.

• Dessinez le contenu de GC.GetTotalMemory()à l'écran. Cela vous donne une approximation du nombre d'octets alloués que votre jeu utilise. Si ça bouge à peine, tu vas bien. Si ça monte vite, vous avez des problèmes.
• Essayez d'allouer tous vos objets de tas à l'avant. Si vous n'allouez pas tout avant le début du jeu, chaque fois que vous frappez un mégo d'allocations, vous perdez votre temps. Pas d'allocation, pas de collection. Aussi simple que cela.
• Après le chargement, appelez GC.Collect(). Si vous savez que la plupart de vos grosses allocations sont épuisées, il est bon que le système le sache.
• NE PAS APPELER GC.Collect()chaque image. Cela peut sembler une bonne idée, de garder le dessus de vos ordures et tout le reste, mais souvenez-vous que le seul qui soit pire qu’une collecte des ordures est la récupération des ordures.
• Cherchez d'où viennent vos ordures. Il existe des causes courantes telles que la concaténation de chaînes au lieu de les utiliser StringBuilder(attention, StringBuildern’est pas une solution miracle, mais peut toujours provoquer des allocations!. Cela signifie que de simples opérations telles que l’ajout d’un nombre à la fin d’une chaîne peuvent créer des quantités surprenantes de déchets) ou utiliser des foreachboucles sur des collections qui utilisent l' IEnumerableinterface peut également créer des déchets sans que vous le sachiez (par exemple, foreach (EffectPass pass in effect.CurrentTechnique.Passes)c'est un problème commun)
• Utilisez des outils tels que le profileur de mémoire CLR pour déterminer où la mémoire est allouée. Il existe de nombreux tutoriels sur l'utilisation de cet outil.
• Lorsque vous savez où vous allouez pendant le jeu, voyez si vous pouvez utiliser des astuces telles que la mise en pool d'objets pour réduire le nombre d'allocations.
• Si tout échoue, accélérez vos collections! Le GC sur le cadre compact suit chaque référence dans votre code pour déterminer quels objets ne sont plus utilisés. Refactor votre code utilise moins de références!
• N'oubliez pas d'utiliser des IDisposableclasses contenant des ressources non gérées. Vous pouvez les utiliser pour nettoyer la mémoire que le CPG ne peut pas se libérer.

L'autre chose à laquelle il faut penser est la performance en virgule flottante. Bien que .NET JITer effectue un nombre suffisant d’optimisations spécifiques au processeur, il ne peut pas utiliser SSE ni aucun autre jeu d’instructions SIMD pour accélérer vos calculs en virgule flottante. Cela peut entraîner une différence de vitesse assez importante entre C ++ et C # pour les jeux. Si vous utilisez mono, ils disposent de bibliothèques de mathématiques SIMD spéciales dont vous pouvez tirer parti.

Un piège de performance typique ne tient pas compte du ramasse-miettes dans la conception / le développement du jeu. Produire trop de déchets peut conduire à des "hoquets" dans le jeu, ce qui se produit lorsque le GC tourne longtemps.

Pour C #, l'utilisation d'objets de valeur et de l'instruction "using" peut réduire la pression exercée par le CPG.

Je dirais que le plus gros problème que j'ai rencontré en écrivant des jeux en C # a été le manque de bibliothèques décentes. La plupart des solutions que j'ai trouvées sont soit des ports directs, mais incomplets, soit des enveloppes recouvrant une bibliothèque C ++ qui entraînent de lourdes pertes de performances pour le marshaling. (Je parle spécifiquement de MOgre et Axiom pour la bibliothèque OGRE et de BulletSharp pour la bibliothèque de physique Bullet)

Les langues gérées (par opposition à Interprété - ni Java ni C # ne sont en réalité plus interprétées) peuvent être aussi rapides que les langues natives si vous comprenez bien ce qui les ralentit (marshaling, nettoyage de la mémoire). Je pense que le vrai problème, c'est que les développeurs de bibliothèques ne l'ont pas encore compris.

Comme d’autres l’ont dit, les pauses de recouvrement du GC constituent le principal problème. L'utilisation de pools d'objets est une solution typique.

C # et Java ne sont pas interprétés. Ils sont compilés en un bytecode intermédiaire qui, après JIT , devient aussi rapide que le code natif (ou assez proche pour être insignifiant)

Le plus gros écueil que j'ai trouvé est de libérer des ressources qui affectent directement l'expérience utilisateur. Ces langages ne prennent pas automatiquement en charge la finalisation déterministe comme le fait le C ++, ce qui, si vous ne vous attendez pas à cela, peut donner lieu à des éléments tels que des maillages flottant dans la scène après que vous pensiez avoir été détruits. (C # accomplit la finalisation déterministe via IDisposable , je ne suis pas sûr de ce que fait Java.)

En dehors de cela, les langages gérés sont en réalité beaucoup plus capables de gérer le type de performances requises par les jeux que d'obtenir un crédit. Un code géré bien écrit est beaucoup plus rapide qu'un code natif mal écrit.

Ni Java ni C # ne sont interprétés. Les deux sont compilés en code machine natif.

Le plus gros problème avec les deux et les jeux est de devoir coder de manière à ne jamais ramasser les ordures pendant le jeu. Le nombre d'objectifs à franchir pour accomplir cette tâche est presque supérieur aux avantages de les utiliser. La plupart des fonctionnalités qui rendent ces langages amusants à utiliser pour la programmation d'applications ou de serveurs doivent être évitées pour la programmation de jeux, sinon vous obtiendrez de longues pauses pendant le jeu, au fur et à mesure de leur disparition et de leur ramassage des ordures.

Un grand piège que je vois en faisant des jeux avec des langages comme ceux-ci (ou en utilisant des outils comme XNA, le moteur TorqueX, etc.) est que vous aurez du mal à trouver une équipe de bonnes personnes possédant l'expertise nécessaire pour créer un jeu équivalent à ce Il serait relativement facile de trouver des personnes pour C ++ et OpenGL / DirectX.

L’industrie du développement de jeux est encore très fortement ancrée dans le C ++, car la plupart des outils et des pipelines utilisés pour lancer de petits jeux bien ou très bien conçus ont été écrits en C ++ et, autant que je sache, vous pouvez utiliser TOUS les kits de développement officiels. obtenir pour XBox, PS3 et Wii sont publiés uniquement avec une compatibilité pour C ++ (l'ensemble d'outils XBox peut être plus géré de nos jours, quelqu'un en sait plus?)

Si vous souhaitez développer des jeux pour consoles dès maintenant, vous obtenez quasiment XNA et C # sur la XBox, puis uniquement dans une partie de la bibliothèque de jeux appelée XBox Live Indie Games. Certains qui gagnent des concours, etc. sont sélectionnés pour transférer leur jeu sur le véritable XBox Live Arcade. Autre que ce plan sur la création d'un jeu pour PC.