Le C ++ est-il remplacé par C # dans les jeux de l'industrie?

Dans les jeux de l'industrie, je veux dire comme Quake, CoD, etc.

Dans un sens, C ++ est vraiment en train d'être remplacé - non seulement par C #, mais par une multitude d'autres langages. Mais si vous demandez, est-ce que cela va être complètement remplacé - alors la réponse est définitivement non .

En effet, C ++ est traditionnellement utilisé à deux titres. Tout d'abord, pour créer le moteur de jeu : les composants de bas niveau qui chargent les ressources, poussent les polygones à l'écran et calculent les nombres dans les simulations physiques. Deuxièmement, pour coder la logique du jeu : les règles réelles qui font le gameplay.

Cette deuxième capacité ne nécessite pas les points forts de C ++ (comme un contrôle complet sur les détails de bas niveau), mais souffre de ses faiblesses (telles que la gestion de la mémoire codée à la main sujette aux bogues). Et dans cette deuxième capacité, C ++ est remplacé par différents langages de script. Beaucoup de développeurs utilisent Lua; certains utilisent Python. Mais si une plate-forme CLI est disponible, sous la forme de .NET ou Mono, elle présente un excellent candidat hôte de script. Ces plates-formes sont assez rapides, fiables, offrent un langage largement connu (C #) et une bibliothèque de classes de base complète. N'oublions pas les outils: MS Visual studio et SharpDevelop / MonoDevelop ne sont peut-être pas les meilleurs IDE au monde, mais ils sont assez bons.

Cela dit, le moteur de jeu ne sera pas écrit en C # (ni Lua, ni Python d'ailleurs). Pourquoi? Parce qu'ils ne sont tout simplement pas assez rapides.

Contrairement à de nombreuses croyances populaires, le plus gros succès de performance aujourd'hui est dû à la latence de la mémoire . Cela signifie que l'accès à la mémoire est une affaire sérieuse. Et les langages gérés ne permettent pas à l'utilisateur de contrôler l'accès à la mémoire - c'est précisément pourquoi ils sont "gérés" en premier lieu. Aucun langage géré ne permettra donc d'écrire un moteur de jeu très rapide. En fait, tous les gros moteurs "C #" auxquels je peux penser - XNA, MOGRE, Unity - sont basés sur du code C ++ natif ; mais permet d'écrire la logique du jeu en C #.

Pour résumer : C # va être utilisé à la place de C ++ ou d'autres langages. Mais il ne remplacera jamais C ++, du moins jusqu'à ce que quelqu'un invente une mémoire sans latence et à accès instantané.

Le choix de la langue dépend fortement de la plate-forme. À l'heure actuelle, il semble vraiment peu probable que quoi que ce soit, sauf une plate-forme Microsoft, nécessite réellement .NET comme implémentation.

La sagesse conventionnelle dirait qu'une petite plate-forme devrait être proche du métal pour être performante, mais d'un autre côté, les plates-formes gérées sont plus sûres . C'est probablement la raison pour laquelle Windows Phone 7 vous oblige à utiliser .NET.

Il serait certainement intéressant que la nouvelle Xbox nécessite une plate-forme gérée. Si le matériel d'un téléphone peut le gérer (et il le fait), je pourrais certainement les voir l'utiliser sur une console pleine taille. Cela remuerait un peu l'écosystème de la console car il serait plus difficile d'écrire des jeux multi-plateformes sans écrire tout votre code de jeu dans un langage de script. Si c'est le cas, alors C # ne remplacerait pas C ++, mais cela irait de pair.

À l'heure actuelle, vous pouvez utiliser Mono comme back-end de script (similaire à ce que fait Unity), mais j'imagine que la plupart des fabricants de moteurs voudraient soit rouler le leur, soit utiliser quelque chose de plus compact comme Lua ou Python que C #.

Quoi qu'il en soit, il s'agit du bon outil pour le bon travail. De toute façon, vous devriez vraiment apprendre les deux langages, car C # facilite certaines choses (développement d'outils, développement de serveurs probablement, etc.), et vous ne pouvez pas utiliser autre chose que C ++ dans certains cas.

Ce n'est pas probable. C ++ a l'avantage d'être de bas niveau afin que les développeurs puissent réellement modifier les moindres détails pour obtenir les meilleures performances possibles.

Avec C # et .NET, vous disposez d'une récupération de place, ce qui est très utile, mais lorsque vous travaillez avec des plates-formes à mémoire et ressources limitées (consoles portables et dans une certaine mesure, consoles domestiques), vous devez avoir autant de contrôle sur la mémoire que possible pour en faire le meilleur usage. des ressources. Permettre aux langues gérées de vous allouer et de libérer de la mémoire vous causerait très probablement beaucoup de problèmes.

La vitesse est également un problème (bien que probablement moins). Au fil du temps, je suis sûr que les langages gérés pourraient être conçus pour fonctionner de manière comparable aux compilateurs C ++.

Dans l'ensemble, d'après mon expérience, les développeurs de jeux ont tendance à être des fous de contrôle en matière de mémoire, de temps CPU et de ressources (pour obtenir autant de performances que possible), c'est pourquoi C / C ++ sont les langages principalement utilisés.

AFAIK .NET GC souffre toujours d' arrêter l' algorithme de style mondial . Bien que cela puisse convenir à une grande variété d'applications, c'est inacceptable pour les applications en temps réel comme les jeux.

En fait, il est très difficile d'utiliser efficacement les langages gérés pour les programmes en temps réel jusqu'à ce que nous ayons quelques percées dans GC.

Non. En fonction de .NET, cela impliquerait des réécritures massives pour les plates-formes sans Framework disponible, comme la PS3, et les inconvénients de performances peuvent être parfaitement acceptables sur le PC ou pour les jeux Live Arcade, mais les jeux plus grands auront besoin de chaque morceau de performances de leurs consoles pour fonctionner assez rapidement. Plus que cela, il existe d'énormes bases de code existantes en C ++ que personne ne pouvait se permettre de mettre à niveau, même s'il le voulait. Le C ++ est dans l'industrie du jeu et il va y rester longtemps.

À une époque où la puissance de l'ordinateur était rare, tout devait être programmé en C ou C ++, simplement parce que les langages récupérés détournent le contrôle de la mémoire du programmeur, et donc les performances peuvent chuter.

De nos jours, les ordinateurs sont plus rapides, mais comme le dit Knuth et pour faire court, l'optimisation peut être mauvaise:

• il est évident que les fonctionnalités de base de bas niveau doivent être optimisées, car le calcul de la géométrie 3D, de la physique, des collisions, de l'éclairage peut rapidement faire gonfler le meilleur processeur disponible. Vous pouvez facilement dire que l'augmentation de la qualité visuelle sur une machine tue presque toujours considérablement les performances.

• Maintenant, il existe d'autres fonctionnalités, telles que les états de jeu, l'IA, le son, l'entrée, le réseau, qui sont toujours importantes dans un jeu, mais qui ne prendront presque jamais autant de ressources informatiques. Ces fonctionnalités, la plupart du temps, ne doivent pas être optimisées. C'est le but du langage de script et des langages récupérés: vous n'avez pas à penser à la cohérence de votre mémoire et à l'organisation de votre application, car le code que vous écrirez avec ces langages, si vous ne codez pas des trucs de bas niveau, ne sera jamais un goulot.

Exemple avec 2 cas

• Expédiez 500 kg de meubles avec un camion.
• Expédiez 30 tonnes de matériel avec un bateau.

les deux sont à 500 km de distance.

Dans les deux cas, est-il important d'accélérer le processus de chargement / déchargement pour raccourcir le temps de transport, sachant que vous CANT rendez le bateau ni le camion plus rapides?

La réponse est: cela importait avec le camion, mais plus avec le bateau, car vous avez déjà beaucoup fait en déplaçant le stock avec le bateau.

Je ne sais pas si vous comprenez cette métaphore, mais d'une certaine manière, cela peut vous faire imaginer le problème mathématique, qui est plus important que de comprendre la réponse.

Les langages de script permettent de rendre les jeux plus rapides si vous avez déjà un moteur programmé en C / C ++: le moteur 3D résout les problèmes de bas niveau, maintenant vous devez faire le jeu avec vos scripts.

Mais rappelez-vous: vous ne pourrez jamais remplacer le langage compilé de bas niveau, JAMAIS. Les langages compilés de manière statique sont au cœur des performances et vous NE POUVEZ PAS les exclure, que ce soit un noyau, un moteur 3D ou un pilote de carte graphique.

Mais bien sûr, si votre jeu est graphiquement simple et ne nécessite pas beaucoup de calculs vectoriels, vous pouvez vous concentrer sur le gameplay et oublier l'optimisation, car dans ce cas, vous n'aurez jamais à gérer l'optimisation car votre machine est très rapide pour ça

Sauf si vous prévoyez de porter ir sur la DS. Mais je m'arrête là.

Écoutez, je sais que c'est une diatribe mais je ne fais pas que couper des cheveux. Je pense que la plupart des programmeurs ne mettent pas vraiment cela ensemble. Un langage lui-même n'a rien à voir avec la vitesse d'exécution / les performances. C'est le compilateur / framework. Vous pourriez mieux argumenter gcc contre cl (compilateur Microsoft pré 2010) ou msbuild (compilateur c ++ actuel pour 2010). À chaque version, ces compilateurs s'améliorent, vous devez également les comparer aux versions précédentes d'eux-mêmes. Je suis très impressionné par .net et il fonctionne bien mais même s'il était légèrement meilleur, je ne le vois pas prendre le dessus, une raison: la portabilité.

Les jeux AAA veulent être sur Windows, Linux, Mac, XBox, PS3, Nintendo, etc.