Discussion :

[tomlev]

-Coder des projets plus conséquent du genre AAA ça demande d'avoir une armée de codeurs, donc, à moi tout seul, je doute fort que je pourrai

Voilà qui est déjà plus raisonnable
Et c'est essentiellement sur ce point que portaient mes critiques... dans ton premier message, tu semblais mettre sur un même plan tes jeux indé développés tout seul et les jeux AAA, ce que je trouvais "un peu" prétentieux. Si on est finalement d'accord sur ce point, ça me rassure

Pour des projets à l'échelle d'une personne, effectivement il est bien possible que les optimisations dont parle Nicolas Fleury ne soient pas nécessaires. Mais plus un projet grossit, plus chaque petite optimisation peut devenir cruciale...

Ce que je trouve dommage, et ce qui peut frustrer c'est que dans les SSI on ne recherche que des codeurs Java, JEE, C#, Sharepoint, etc.., qui demande de maîtriser un tas de concepts et avec des bugs à foisons, bref, je ne connais que une SSI qui utilise du c++14. (du moins en Belgique)

C'est tout simplement parce que les SSII développent principalement des applications métier, et que pour ce type de développement, des langages comme Java ou C# sont plus productifs. C++ demande de se poser trop de questions sur des problématiques purement techniques (gestion de la mémoire principalement, même si de ce point de vue C++ est mieux loti que C), au détriment des aspects métier.

Cela étant dit, mon premier boulot était dans une SSII où je développais des applications métier (billing) en C, avec aussi un peu de C++. Comme quoi ça existe

Pour ce qui est des "bugs à foison", je ne vois pas ce que tu veux dire... il n'y a pas de raison de produire du code plus buggé en C# ou Java qu'en C++ ; je dirais même que c'est plutôt le contraire, dans la mesure où ces langages évitent intrinsèquement toute une catégorie de bugs, liés à la gestion manuelle de la mémoire.

-JEE et C# j'évite de rentrer dans ces boîtes car je sais que ça va être trop difficile pour moi et souvent ça va conduire à des bugs à foison.

Trop difficile ? Si tu es capable de maitriser C++, je ne vois pas ce qui t'empêcherait de maitriser Java ou C#, qui sont nettement plus simples que C++... Après c'est sûr qu'ils ont aussi leurs propres subtilités, mais en ayant fait du C++ tu es justement mieux armé pour les appréhender (je pense par exemple à la notion de types valeur en C#)

Mais bon, si tu développes des jeux, il vaut probablement mieux s'en tenir à C++ - du moins pour les aspects graphique/physique qui demandent des performances élevées. Pour les choses où les perfomances sont moins cruciales, C# est un bon candidat, et il semble d'ailleurs être de plus en plus utilisé dans les jeux AAA.

[Luc Hermitte]

Pour les bugs à foison et la difficulté à maitriser, je soupçonne qu'il voulait plutôt faire référence aux écosystèmes. Ces langages sont simples, mais après il existe 150 libs, frameworks & cie qui sont parfois redondants voire concurrents, parfois complémentaires, parfois à l'intégration hasardeuse, etc. La même chose est vraie en C++, mais vu que ce langage est moins utilisé comme langage d'assemblage de briques que Java et C#, cela se voit/rencontre moins souvent.

[Invité]

Voilà qui est déjà plus raisonnable
Et c'est essentiellement sur ce point que portaient mes critiques... dans ton premier message, tu semblais mettre sur un même plan tes jeux indé développés tout seul et les jeux AAA, ce que je trouvais "un peu" prétentieux. Si on est finalement d'accord sur ce point, ça me rassure

Pour des projets à l'échelle d'une personne, effectivement il est bien possible que les optimisations dont parle Nicolas Fleury ne soient pas nécessaires. Mais plus un projet grossit, plus chaque petite optimisation peut devenir cruciale...

En effet dans les projets d'une seule personne on peut se passer de se genre d'optimisations, par contre, je ne suis pas si sûr que ça soit encore nécessaire pour faire tourner un plus gros projet. (en utilisant des technologie modernes qui limite le nombre de triangles)

Malheureusement je ne suis qu'un simple développeur donc, je manque encore de connaissance en graphisme et en son, et même si ça ne change rien au niveau du code d'afficher 10 ou bien 100 000 entités avec la physique et tout ça, encore faut il créer tout ses graphismes, sons, etc...
Mais, j'essaye toujours de jouer avec les coordonnées de textures, les particules, les shaders..., plutôt que de devoir faire des optimisations compliquées avec d'ancienne techniques, qui sont plutôt galère à faire pour un développeur indépendant. :/

Pour les bugs à foisons je voulais plutôt parler des nombreux frameworks et des libs fournies avec le language, pas des langages eux même qui sont sympas lors du codage d'applications métier.

[Mat.M]

donc, je pense que je vais faire comme une majorité de personnes ici (voir tout le monde) semble vouloir faire c'est à dire, coder des petits projets dans mon coin avec mon moteur.
.

pour une personne qui étudie l'informatique, les algorithmes, la programmation oui c'est une bonne chose et même une excellent chose car si tu as crée ton moteur de jeu , tu sauras un minimum faire l'architecture d'un projet informatique en créant les classes et structures nécessaires à l'architecture de ce projet.

J'ai travaillé comme salarié à un projet commercial de logiciel d'entreprise ( donc pas de jeu vidéo ) c'était une catastrophe, aucune factorisation du code,pas d'analyse initiale, la majorité du code avec des tonnes de copier-coller partout..

Dans mon parcours professionnel combien de projets ai-je vus avec une architecture défaillante et carrèment inexistante ?
( projets d'informatique de gestion avec base de données client-serveur - je ne parle pas d'ERP quoique là il y a beaucoup à dire dessus).

Si tu arrives à acquérir un esprit "conceptuel" c'est tant mieux et ceci bien au-delà des querelles d'apothicaires, trolls sans fin à savoir si on fait du "C with classes" en utilisant un compilateur C++.

Cela signifie que comprendre les Design Patterns, UML,méthodologies... c'est une bonne chose et si tu peux appliquer ces "mécaniques" sur ton moteur de jeu eh bien ce n'est que mieux...

pourvu que cela puisse servir à l'avenir et trouver un champs d'application si tu est amené à travailler dans des secteurs autres que le jeu vidéo ,en SSII ou chez un éditeur de logiciels ( de compta ou de tout ce que l'on veut ).
Parce que je me répète j'ai tellement vu de choses horribles en milieu professionnel...

en informatique de gestion il y a un paquet de gens qui semblent ne pas savoir pas construire un "moteur" applicatif comme on construirait un moteur de jeu...
mais ce n'est pas de leur faute, c'est la pression professionnelle qui veut ça..

Maintenant pour en revenir au sujet principal, les jeux vidéos, faire ses petits projets dans son coin c'est bien mais il faut que ceci ait une finalité..
tu vas t'apercevoir que tu investis beaucoup de ton temps libre pour des projets qui au final risquent de n'intéresser personne..

qu'une personne développe ses petits jeux "dans son coin" c'est une bonne chose encore faudrait-il en faire la promo sur des sites de référencement de shareware ( si c'est un jeu pour PC Windows/Linux ) sur l'app Store etc...
parce que tu vas vite t'apercevoir que ça ne mène pas à grand chose..

Vous voulez faire des jeux mais vous n'irez nulle part tout seul, y'a pas de secret c'est comme n'importe quel autre type de programme: il faut du code, du code, du code, du code, du code, du code, du code et encore du code, il faut une armée de codeurs pour ça.

ce ne sont que lapalissades...

Ce qu'il ne faut pas perdre de vue c'est que tu as beau faire le jeu vidéo le plus réussi techniquement même avec une équipe de 100 personnes , si ton jeu ne se vend pas et que les joueurs ne veulent pas l'acheter , eh bien quelques titres comme ça et tu n'as plus qu'à pointer à Pôle Emploi.
Et puis après tout il y a bien quelques jeux amateurs qui ne sont pas des AAA qui se sont bien vendus tout de même..
Que ce forum soit fréquenté par des intervenants techniques je veux bien le comprendre mais il ne faut pas perdre de vue cela.

Bonjour,
Je suis un petit développeur indé "old school" mais je n'ai rien compris au sujet et j'ai vite perdu pied au fil du débat ...
On a beau savoir comment se goupille un jeu, n'empêche que j'ai l'impression que sans faire de passéisme, les machines d'antan étaient au service des développeurs alors que maintenant ça m'a l'air d'être tout le contraire ...

c'est ma conception des choses aussi..ne pas perdre de vue que pour ce qui est des machines d'aujourd'hui c'est que derrière se cache une logique commerciale et de mercantilisme..
pour ce qui est des outils de développement c'est pareil , les éditeurs ils ne veulent qu'une chose c'est qu'on achète leurs outils de développement qui regorgent de fonctionnalités bien attrayantes et qui font acheter..

[Invité]

pour une personne qui étudie l'informatique, les algorithmes, la programmation oui c'est une bonne chose et même une excellent chose car si tu as crée ton moteur de jeu , tu sauras un minimum faire l'architecture d'un projet informatique en créant les classes et structures nécessaires à l'architecture de ce projet.

J'ai travaillé comme salarié à un projet commercial de logiciel d'entreprise ( donc pas de jeu vidéo ) c'était une catastrophe, aucune factorisation du code,pas d'analyse initiale, la majorité du code avec des tonnes de copier-coller partout..

Dans mon parcours professionnel combien de projets ai-je vus avec une architecture défaillante et carrèment inexistante ?
( projets d'informatique de gestion avec base de données client-serveur - je ne parle pas d'ERP quoique là il y a beaucoup à dire dessus).

Si tu arrives à acquérir un esprit "conceptuel" c'est tant mieux et ceci bien au-delà des querelles d'apothicaires, trolls sans fin à savoir si on fait du "C with classes" en utilisant un compilateur C++.

Cela signifie que comprendre les Design Patterns, UML,méthodologies... c'est une bonne chose et si tu peux appliquer ces "mécaniques" sur ton moteur de jeu eh bien ce n'est que mieux...

pourvu que cela puisse servir à l'avenir et trouver un champs d'application si tu est amené à travailler dans des secteurs autres que le jeu vidéo ,en SSII ou chez un éditeur de logiciels ( de compta ou de tout ce que l'on veut ).
Parce que je me répète j'ai tellement vu de choses horribles en milieu professionnel...

en informatique de gestion il y a un paquet de gens qui semblent ne pas savoir pas construire un "moteur" applicatif comme on construirait un moteur de jeu...
mais ce n'est pas de leur faute, c'est la pression professionnelle qui veut ça..

Maintenant pour en revenir au sujet principal, les jeux vidéos, faire ses petits projets dans son coin c'est bien mais il faut que ceci ait une finalité..
tu vas t'apercevoir que tu investis beaucoup de ton temps libre pour des projets qui au final risquent de n'intéresser personne..

qu'une personne développe ses petits jeux "dans son coin" c'est une bonne chose encore faudrait-il en faire la promo sur des sites de référencement de shareware ( si c'est un jeu pour PC Windows/Linux ) sur l'app Store etc...
parce que tu vas vite t'apercevoir que ça ne mène pas à grand chose..

C'est la raison principale pour laquelle j'ai décidé de faire mon moteur, pour m'améliorer et avoir un esprit plus conceptuel, car, lorsque j'ai fais mes études en informatique de gestion, j'ai remarqué que mon esprit n'était pas encore assez conceptuel, et que la plupart des applications comme tu le dis si bien, sont codées à l’arrache. :/ Sûrement à cause de la pression subie par les développeurs comme tu dis.

D'ailleurs je comptes plus tard, si je peux arriver jusque là bien sûr, ne pas me limiter à du développement de jeux vidéos avec mon moteur, mais rajouter quelques interfaces pour du développement applicatif en espérant que mon moteur puisse aussi servir dans ce domaine là. (Et pourquoi pas rajouter aussi quelques composants pour faire du développement webs ?)

Bref c'est prévu pour la version finale de mon moteur en tout cas.

Mais je ne comptes pas incorporé un tas de fonctionnalités attrayantes qui sont là juste pour faire acheter (chose qui m'énerve au plus au point), et que au final, on s'y perd tellement il y a de fonctionnalités. :/
Je compte appliqué plutôt un mécanisme de programmation agile et rajouter une fonctionnalité uniquement lorsque j'en ai besoin.

De plus je ne suis pas non plus limité si par malheur j'ai besoin d'une fonctionnalité qui n'est pas présente dans le moteur.

PS : d'ailleurs, ça me fais pensé que je dois refaire le diagramme UML du moteur (j'ai perdu celui que j'avais sous windows en même temps que celui-ci) enfin du moins, la structure globale, pas toutes les méthodes du framework.

[Invité]

[...] Malheureusement je ne suis qu'un simple développeur donc, je manque encore de connaissance en graphisme et en son, et même si ça ne change rien au niveau du code d'afficher 10 ou bien 100 000 entités avec la physique et tout ça, encore faut il créer tout ses graphismes, sons, etc... [...]

J'ai peut être mal compris ce passage mais il me semble plus qu’improbable que rien ne change au niveau du code entre 10 et 100 000 entité affiché. On utilise tout simplement pas la même technique. Et cette idée avec les timers dans les premiers post... pour utiliser à la place des threads? omfg. Pardon je ne veux pas troller mais ce me fais bizarre de lire ça.

[Nicolas Fleury]

Je suis tombé sur cette discussion à mon retour de vacances, content de voir qu'on a pris de le temps de faire une discussion à partir de mon talk; c'est apprécié.

Si vous avez des questions, je peux prendre le temps d'y répondre.

J'ai parcouru la discussion et il y a quelques points que je peux adresser rapidement. Note: il y a certains termes que je ne vais pas traduire de l'anglais; par habitude, on les garde en anglais à Montréal.

On utilise beaucoup de fonctions virtuelles, c'est essentiel côté gameplay et pour une très grande majorité du code. C'est pour le 10% du code qui prend 90% du temps que c'est évité autant que possible, surtout pour le côté graphique. Et non, ce ne sera pas remplacé par des pointeurs de fonctions à ce moment-là, sinon c'est inutile. Ce sont les abstractions qui seront éliminées, dans le but d'améliorer l'utilisation de la cache. Le talk de Mike Acton au CppCon résume bien la problématique pour cette partie du code, entre autre avec un exemple où une grande majorité du temps est passé dans l'accès mémoire, ce qui laisse dans cet exemple peu au compilo à optimiser (https://www.youtube.com/watch?v=rX0ItVEVjHc). Oui, on pourrait dire que ce 10% va ressembler plus à du C, puisque typiquement les abstractions sont éliminées et que de simples PODs vont faire le travail, mais ce n'est pas le but, et on ne va pas se gêner pour utiliser des features C++ récents tant qu'ils sont disponibles sur tous les compilos de nos plates-formes. L'objectif est toujours de faire ce qui nous semble le mieux pour notre projet.

Il a eu des commentaires comme quoi Alexandrescu travaillerait davantage à faire travailler le compilo que nous pour optimiser. La première fois que je l'ai rencontré il y a une douzaine d'année, il avait effectivement présenté un concept hallucinant de métaprogrammation où un programme qui compilait n'aurait pas de deadlock. Mais aujourd'hui, il fait un travail similaire chez Facebook à ce qui se fait de notre côté. Il a d'ailleurs présenté cette année une implémentation à la main des tables des fonctions virtuelles pour avoir des performances légèrement supérieures, et une utilisation plutôt chiante, et c'est une direction dans laquelle je ne voudrais pas aller. On est tous les 2 devant le même problème: la vitesse d'accès de la mémoire n'a pas augmenté à la même vitesse que celles des processeurs, alors la mémoire se retrouve au coeur des performances.

On n'utilise pas de C# dans ce qui se retrouve dans le jeu final. Par contre, on considère que Unity 3D est un fabuleux moteur pour des prototypes ou pour des jeux où ses performances sont suffisantes. On l'utilise pour ces 2 cas chez Ubisoft, on ne va pas se mentir et se dire que nos moteurs monstrueux sont adéquats pour des prototypes si ce n'est pas le cas, quoique ça s'améliore.

Les plus anciens de l'industrie comme Mike Acton ne semblent pas aimer le C++, mais le coeur d'Ubisoft Montréal est plus jeune et a toujours travaillé en C++, je m'y inclus, et nous sommes intéressés par la direction qui est prise par le langage; certains d'entre nous discutent directement avec des membres du comité. Je conseille le talk de mon ami Jeff Preshing au CppCon, qui montre bien que le problème est souvent que ce dont on a besoin n'est pas disponible à temps (https://www.youtube.com/watch?v=X1T3IQ4N-3g).

Je partage l'essentiel du point de vue de Titus Winters de Google sur leur vision du C++ (https://www.youtube.com/watch?v=NOCElcMcFik). Les features qu'ont exclut le sont simplement parce qu'on le juge dans notre intérêt.

Et oui, Assassin's Creed Unity et Rainbow Six: Siege utilisent le même moteur. Sur Assassin le code gameplay est immense et a beaucoup d'histoire.

Je suis d'accord que la realité de nos projets est différentes de plus petits projets. Plusieurs choix que l'on fait sont rentables à cause la grosseur de nos équipes.

[Astraya]

Salut!

@foetus

UBISoft = Union des Bretons Indépendants

Ubiquity Software est la vrai origine de Ubisoft.

Pour les choix qu'Ubisoft défend, ils ne sont pas les seul à le faire. Unreal Engine fait les mêmes, et ceux qui parle de Unity je leur demande si ils ont eu les sources C++? Il ne faut pas confondre les outils (C#) qui sont intégrée au jeu (C++) pendant la phase de développement et qui sont complétement absent ( sauf autre outils client) du jeu en lui même.
Ne pas utiliser les exceptions est un choix avec plusieurs raisons , performance et debuggage. Il faut pas oublier que les équipes sont grosses, parfois plusieurs studio Ubisoft de plusieurs de plusieurs pays travaille sur le même code. Donc le fait de supprimer des éléments c'est pas parce qu'ils sont coincés en 1990, c'est pour des raisons de développement interne propre au jeu également. Pour ceux qui critique les jeux comme Assassin's creed qui ont des bugs, j'en trouverais beaucoup plus dans les jeux Java ou C# voir même Web... Et il ne faut pas rêver vous n'aurez pas un Assassin's sur Xbox One avec C#...

Pas de RTTI, c'est également pour des performances et de debuggage, j'ai lu ici que on pouvait utiliser typeid... avez-vous tester les performances et le fonctionnement de typeid au niveau hardware?
Ubisoft, Epic, Insomiac Game... etc... Tous n'utilise pas le RTTI de C++ mais un Custom...
Quel est selon vous la différence de performance entre un typeof() et une comparaison de 2 pointeurs?
De plus le RTTI à un overhead difficilement mesurable, un custom est facilement mesurable.

Ceux qui dise que c'est du C... Le C++ ce n'est pas que RTTI et exceptions... Ce n'est pas parce que ils disent éviter les fonctions virtuelles qu'il les interdisent complétement du code, il faut les supprimer là ou l'on pourrait avoir un gain significatif.

Arrêter de critiquer leur choix et essayer de les comprendre dans le contexte professionnel, multiplateforme (avec chacune leur limitation, dont le RTTI) avec de grosse équipe.
Je ne veux pas critiquer les indépendants ici, mais les budgets, les attentes des joueurs et de la presse ne sont pas les mêmes pour ce genre de studio.

[tomlev]

Pour ceux qui critique les jeux comme Assassin's creed qui ont des bugs, j'en trouverais beaucoup plus dans les jeux Java ou C# voir même Web...

Je ne vois pas pourquoi... comme je le disais plus haut, les langages de plus haut niveau comme Java ou C# ont plutôt tendance à diminuer le nombre de bugs (du moins, certaines catégories de bugs). Après évidemment ce ne sont pas des langages appropriés pour développer des jeux de cette envergure, mais c'est pour des raisons de performance, et non de fiabilité. Mais bon, de toute façon ce n'est pas le débat... je ne sais pas qui tu essaies de convaincre, personne n'a dit qu'il faudrait utiliser C# ou Java plutôt que C++ pour les jeux AAA

[Astraya]

Je ne voulais dénigrer ici le C# ou le Java. Je réponds juste à plusieurs poste qui justement sous entendait qu'il y avait plus de bugs possible avec C++. Ce qui je pense est totalement faux, tout dépend de qui est entre la chaise et le clavier. Et il faut pas oublié que la majorité des bugs dans les jeux sont des bugs de script ou de gameplay, moins de moteur(Core) à proprement parlé.

[Bousk]

Un nouveau très bon talk de Mike Acton à la GDC qui vient de s'achever
http://gdcvault.com/play/1021866/Cod...ic-2015-How-to

[DonQuiche]

Je réponds juste à plusieurs poste qui justement sous entendait qu'il y avait plus de bugs possible avec C++. Ce qui je pense est totalement faux, tout dépend de qui est entre la chaise et le clavier.

Si tu penses qu'avec un ph4tskillz on n'a pas besoin de bons outils ni de bonnes méthodologies, alors il y a effectivement un problème entre la chaise et le clavier.

Les causes les plus fréquentes de bogues sont connues depuis des décennies, elles ont été mesurées sur des centaines de millions de lignes de code, et c'est à l'aune de ces résultats que les langages ont évolué depuis le C++, par exemple avec la gestion automatisée de la mémoire (non, les smart pointers ne sont pas automatisés, seulement à moitié), les vérifications des indices des tableaux (ce qui permet de détecter rapidement et facilement les bogues), la vérification automatisée des références nulles, l'introduction de références non-nullables, et tant d'autres choses. On ne peut sérieusement contester qu'interdire ou mettre en évidence 75% des bogues débouche sur moins de bogues ! Il est absurde d'en voir certains ici soutenir ce genre de discours.

Si le C++ demeure utilisé c'est en dépit de son impact négatif, réel et mesuré, sur la productivité et la qualité du code. S'il demeure utilisé c'est parce que les langages récents ne permettent généralement pas d'obtenir des performances maximales (difficilement compatibles avec la productivité et la qualité du code) et parce que de tous les langages restants le C++ est le mieux placé en termes d'écosystéme (SDK des plateformes, bibliothèques tierce-parties, recrutement, etc)

Le C++ est un langage ancien, problématique, toxique, qui reste malheureusement indispensable. Pour autant je pense qu'on va le voir de plus en plus rapidement remplacé par Rust pour les nouveaux développements, laissant ainsi le C++ rejoindre Cobol au rang de la seule maintenance.

Et il faut pas oublié que la majorité des bugs dans les jeux sont des bugs de script ou de gameplay, moins de moteur(Core) à proprement parlé.

Sans doute parce que le moteur contient moins de cas de figure rares. En général les problèmes y sont rapidement visibles, au sens premier du terme comme au sens figuré. Je parie aussi sur une faible complexité cyclomatique et peu de couplages.

A contrario le code gameplay est typiquement une grosse gestion d'états, et ce genre de choses est toujours un nid de bogues. Et sans une forte hygiène (qui débouche malheureusement souvent sur un truc surarchitecturé) on obtient vite un fort couplage entre les différentes problématiques : le simple déplacement du joueur fait par exemple intervenir les entrées, l'environnement qui peut le ralentir, les collisions avec le monde, les buffs temporaires, le recul du fusil, l'interpolation réseau, etc. Autant dire des "if" par poignées de cent !

[white_tentacle]

Les causes les plus fréquentes de bogues sont connues depuis des décennies, elles ont été mesurées sur des centaines de millions de lignes de code, et c'est à l'aune de ces résultats que les langages ont évolué depuis le C++, par exemple avec la gestion automatisée de la mémoire (non, les smart pointers ne sont pas automatisés, seulement à moitié), les vérifications des indices des tableaux (ce qui permet de détecter rapidement et facilement les bogues), la vérification automatisée des références nulles, l'introduction de références non-nullables, et tant d'autres choses. On ne peut sérieusement contester qu'interdire ou mettre en évidence 75% des bogues débouche sur moins de bogues ! Il est absurde d'en voir certains ici soutenir ce genre de discours.

Je réponds quand même sur le point de la vérification automatisée des références nulles, c’est un problème assez amusant car c’est typiquement un problème introduit (problème qui concerne massivement C# et java) par un changement de paradigme destiné à régler d’autres problèmes... Comme quoi, les solutions « toutes prêtes » masquent toujours de nouveaux problèmes (même si, dans le cas de C# et Java, ils auraient pu mieux anticiper). C++ a des références non nullables… depuis le début en fait .

Sinon, des études ont montré que le nombre de bugs était uniquement fonction du nombre de lignes de codes et pas du langage utilisé, ce qui tendrait à donner un avantage aux langages dits « concis » tels que python, d’autres étude ont montré qu’il y avait plein de bugs en langage X et moins en langage Y, etc. Bref, on a lu tout et son contraire, et aujourd’hui, si quelqu’un prétend détenir « la » vérité, je crois que la seule bonne chose à faire c’est de lui rire au nez.

Si le C++ demeure utilisé c'est en dépit de son impact négatif, réel et mesuré, sur la productivité et la qualité du code.

En fait, pas forcément. Ça va peut-être te surprendre, mais on trouve deux familles chez les utilisateurs de C++. Ceux qui correspondent à ta description (la grande majorité), et ceux qui utilisent C++ parce que il leur apporte un bénéfice réel sur la productivité et la qualité du code. La grosse différence entre les deux familles : ceux de la deuxième maîtrisent beaucoup mieux leur outil, qui est effectivement d’un maniement complexe.

Le C++ est un langage ancien, problématique, toxique, qui reste malheureusement indispensable. Pour autant je pense qu'on va le voir de plus en plus rapidement remplacé par Rust pour les nouveaux développements, laissant ainsi le C++ rejoindre Cobol au rang de la seule maintenance.

Rust n’est même pas encore en version 1. Certes, les concepts derrière Rust sont plutôt bons, et il pourrait être une très bonne alternative, mais je me vois mal lancer aujourd’hui un projet sérieux dans un langage aussi peu répandu et abouti.

A contrario le code gameplay est typiquement une grosse gestion d'états, et ce genre de choses est toujours un nid de bogues. Et sans une forte hygiène (qui débouche malheureusement souvent sur un truc surarchitecturé) on obtient vite un fort couplage entre les différentes problématiques : le simple déplacement du joueur fait par exemple intervenir les entrées, l'environnement qui peut le ralentir, les collisions avec le monde, les buffs temporaires, le recul du fusil, l'interpolation réseau, etc. Autant dire des "if" par poignées de cent !

Au final, ça montre surtout que plus que le langage, c’est avant tout la conception (au service de la réduction de la complexité du problème) qui va diminuer le nombre de bugs.