[Mesh rebelle] Le topic des techniques qui décoiffent dans les jeux


#281

Ouais, c’est du domaine de Mesh Rebelles ça !


#282

Pour l’idée de ne pas générer de résultat buggé quand on est full procédural, ça se heurte directement à un truc mentionné par exemple dans l’article sur The Witness: tu ne peux pas faire confiance à tes données, tu dois vraiment tester du point de vue du joueur. C’est le même a priori que pour les vétérans d’un jeu qui trouvent les tactiques d’une IA insensées jusqu’à ce qu’ils se fassent massacrer: des années d’a priori limitent leur perception, problème qui n’arrêtera pas un système de test via la force brute.

Mais sinon non, Daggerfall avait des testeurs humains (et accessoirement les tests ont été bâclés de l’aveu même des devs). On parle d’une époque où dans l’industrie du JV le partage des sources se faisait souvent en baladant des disquettes master entre les PC des différents devs et les bases de données de bugs étaient des post-its, bien loin de l’infrastructure minimum et la télémétrie qu’il faut avoir pour se lancer dans des tests automatisés.

Ceci dit l’équivalent le plus proche était l’enregistrement des replays genre attract modes, qui était aussi utilisé pour faire un premier semblant de test automatisé sans IA.


#283

Oh je dis pas que c’était répandu (ou ni même que Daggerfalls en avait hein), mais il y avait surement des expérimentations qui ont du apparaître la seconde où un développeur s’est retrouvé devant un truc chiant et répétitif, et qu’il a levé les yeux au ciel et du se dire que coder un test automatique d’une feature ou d’un ensemble de données (genre des collisions) allait lui sauver du temps. Mais peut être que je surestime la mentalité, voir tout simplement les moyens techniques disponibles à l’époque, comme tu le soulignais.

Je me souviendrais tjrs des outils complément fumés que j’ai pu voir, développés from scratch pour adresser un problème spécifique dans le développement d’un jeu. Ou de ces chaines d’assets faites avec du scotch, mais qui marchent. Ca me manque un peu cet aspect bricolo/garage dans mon métier actuel tiens.

Y avait pas Quake qui avait un peu ce genre d’approche dans la façon dont les .bsp étaient générés, avec un clipping super agressif de toute ce que le joueur ne verrait pas au triangle près (pour garder les perfs), suivi de tests pour vérifier qu’il n’y avait pas de trou ?

EDIT : alors pas du tout, mais pas si loin.

This preprocessing step cannot work if there are any small holes or “leaks” that interconnect the interior game space with the exterior empty space, and it was common for complex map-building projects to be abandoned because the map designer could not locate the leaks in their map. To prevent leaks, the brushes should overlap and slightly interpenetrate each other; attempting to perfectly align along the edges of unusually shaped brushes on a grid can result in very small gaps that are difficult to locate.


#284

Oui, Quake était d’une part conçu pour pouvoir faire tout le rendu des décors sans z-buffer, ce qui faisait que deux polygones ne pouvaient pas se croiser et tout était donc découpé à fond, mais d’autre part (et en fait sans rapport direct avec le premier truc) l’algorithme utilisé pour déterminer quels bouts du décor doivent être dessinés (le PVS, une liste des secteurs visibles depuis chaque autre secteur) nécessite que les maps soient scellées, sans quoi la liste devient gigantesque. Donc le compilateur de niveaux avait d’abord une passe qui vérifiait l’étanchéité de la map en force brute, en balançant des rayons partout.

Même si je vois l’analogie, voire la généalogie, pour le côté force brute et automatisation, j’ai le sentiment qu’on n’est pas tout à fait dans le même domaine dans le sens où là le test cherche un truc bien défini au lieu de chercher des bug inattendus.


#285

Oui tu as raison dans l’absolu, on est plus dans une pure contrainte de production que de tests auto.

Ce qui va d’ailleurs être intéressant c’est en revanche l’arrivée de stratégie de déploiement type A/B ou voir du canary testing avec la popularisation des GaaS, en combinaison avec du QC traditionnel et/ou assisté par de l’IA. Alors évidemment tu restes encore sur des features très spécifiques, et certaines choses requérant de la data un peu lourde passeraient encore difficilement. Mais ça va être intéressant de voir comment à terme, bcp de choses que l’on voit dans le monde des applications web vont influencer, voir influencent déjà petit à petit la façon dont les jeux sont développés, testés, déployés et opérés. Cela va être très intéressant de voir les fenêtre de release d’un jeu et de ses mises à jour se resserrer de plus en plus, avec l’arrivée de pipelines calés sur des logiques de CI/CD, et des titres sortant de plus en plus de manière fragmentaire et sans interruption. Sans compter le jour où les techs de streaming seront au point. C’est vraiment là où se joue l’avenir de nos jours dans la manière de développer les très gros jeux.

D’ailleurs tu vois ce genre d’exemple de combo CI/tests auto chez des pionniers comme LoL (pour revenir au topic original). Je serais curieux de voir ce qu’ils font ensuite en déploiement tiens.

Mais là encore on reste dans du test écrit avec un résultat prévu, ce qui fait que cela est imparfait, même avec les meilleurs unit tests au monde. Cela dit, même des tests auto prévus à l’avance ont une joli capacité à faire remonter des problèmes émergents, à condition de savoir quoi simuler. Si on garde l’analogie des services web, Netflix s’amuse avec ça depuis 10 ans d’ailleurs en faisant pêter des points d’infra au hasard balthazar.

Y a vraiment des choses fascinantes qui s’en viennent en tout cas dans les prochaines années.

Pour revenir aux tests auto appliqués au gameplay par exemple, en farfouillant le sujet en écrivant ce post, je suis tombé sur cette petite collection d’exemples de tests auto :

One-person independent game. It was a multiplayer tank game with destructible terrain, and the destructible terrain and collision code proved somewhat flaky.

I ended up rigging up some basic dumb AIs (by “dumb”, I mean “absolutely idiotic” - they would randomly choose “drive towards an enemy tank”, “drive away from an enemy tank”, and “drive in a random direction”, while randomly firing the main weapon) and playing the game at maximum framerate while recording keypresses. I got about 10-15x realtime. The code was heavily asserted, so if anything went wrong, it would dump the entire keypress log to disk along with an error report and the initial random seed. I could then go and replay the keypress log to duplicate the state exactly, or just debug from the error report.

I left it running constantly for literally months. At the beginning it would rarely get an hour without crashing - I had to sit there and babysit it for a week, killing several obscure bugs per day. Eventually it got to the point where it was running for a week between failures, which translates to about 1500 player hours per crash.

It was invaluable and I heartily recommend it.

C’est pas alpha GO qui teste ton jeu, mais <3<3<3


#286

Trouver des bugs qui existent ? Mais tout ça, c’est has-been, mec ! Le but des recherches actuelles, c’est que les IA prédisent les bugs avant qu’ils n’existent.


#287

“Balance tes tests, c’est du tout cuicui !”

J’aime bien ce forum, je vais revenir, mais vous faites chier avec vos sujets intéressants, ça fait une tonne d’article à lire, vous croyez que j’ai que ça à faire ? Le monde est pas déjà assez inspirant comme ça ?


#288

Une excellente video (du fameux half A press guy) sur les collisions et hitboxes dans Mario 64


La revanche du topic vachement éclectique, limite bordélique
#289

J’étais un peu maladroit (et je ne me suis pas relu): je voulais établir un spectre qui va des jeux qui demande de l’adresse (genre les FPS) aux jeux purement intellectuel (genre le Go); parce que évidemment un robot sera mieux qu’un humain pour viser une cible. Et tout ça pour arriver exactement à

et

Vos réponses sont très chouettes.


Ca s’appelle Evolution chamber, et c’est un algo génétique qui génère les build order.


#290

Passionnant comme d’hab, surtout dans le contexte de ses vidéos précédentes sur le même sujet. Ca fait vingt-deux ans que je joue à ce jeu, j’ai refait les 120 étoiles au minimum une dizaine de fois, et ma mémoire me joue peut-être des tours mais je suis pas certain d’avoir à un seul moment pigé que je pouvais grimper sur le pingouin.


#291

Une démo CG technique chez VisualWorks (Square-Enix) pour aider au recrutement et donner une perspective de leurs objectifs pour la prochaine génération de personnages à animer (en temps réel, je suppose ?). Au bon souvenir d’Agni’s Philosopy (2012).


#292

Une vidéo sur les animations d’explosions, en 2D comme en 3D, feat. le petit Bomb Chicken cher à Loops.

(La chaîne recommandée à la fin est pas mal non plus, notamment la vidéo sur les animations d’Overwatch.)