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

#281

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

0 Likes

#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.

0 Likes

#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.

0 Likes

#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.

0 Likes

#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

0 Likes

#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.

0 Likes

#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 ?

0 Likes

#288

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

0 Likes

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.

1 Like

#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.

0 Likes

#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).

0 Likes

#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.)

1 Like

#293

Un papier très intéressant chez Gamasutra sur les méthode employées sur Graveyard Keeper pour donner du volume et de plus de vie à leur pixel art : http://www.gamasutra.com/blogs/SvyatoslavCherkasov/20181023/329151/Graveyard_Keeper_How_the_graphics_effects_are_made.php

Pas mal de ces méthodes pourraient être mises à profit pour certaines sorties rétro.

1 Like

#294

Je trouve la vidéo sur les explosions absolument fascinante. L’article sur graveyard keeper est pas mal non plus même si je trouve que leurs ombres gagneraient à avoir un effet de seuil plus prononcé (pour faire plus 256 couleurs, pour ainsi dire). Par contre le truc des feuilles est super.

Voici un article fort instructif sur les outils qu’on a bien envie d’avoir quand on est le gars qui doit faire des bande-annonces de jeu:

1 Like

#295
0 Likes

#296
1 Like

#297

Les animations de Sonic Mania, quel bijou.

1 Like

#298

Une video pas récente mais que j’ai trouvé interessante sur les effets de transparence de la Saturn

0 Likes

#299

@nova l’avait découverte lors de sa sortie mais vous avez le droit de la reposter chaque année ! Les sous-titres francophones n’existaient pas à l’époque, d’ailleurs.

0 Likes

#300

La vidéo sur Sonic Mania me fait penser à un truc sur lequel j’aimerais revenir plus en détail à l’occasion, qui est que pour des raisons historiques (taille des anims disproportionnée par rapport à la mémoire disponible, programmeurs qui n’ont pas implémentés les fonctions nécessaires, cursus différent) les animateurs JV connaissent mal les principes de l’animation classique et que du coup il y a périodiquement des jeux qui font des trucs en anim admirables pour des jeux mais normaux pour des films ou séries, alors que techniquement on en est plus ou moins au même point des deux côtés.


Ce soir je vous propose un peu de rétro. Il y avait déjà eu un lien vers une vidéo qui parlait des graphismes en CGA et du fait qu’on peut jouer avec le signal analogique en envoyant certains motifs pour obtenir 16 couleurs au lieu de 4, mais voici un article qui détaille l’escalade à 1024 couleurs sur CGA: https://int10h.org/blog/2015/04/cga-in-1024-colors-new-mode-illustrated/

En dessert, le filtrage des textures N64 qui était un poil différent de tous les autres rendus de textures
de l’univers, et qu’il convient donc d’analyser si on veut le reproduire en émulation: https://filthypants.blogspot.com/2014/12/n64-3-point-texture-filtering-in.html

Pour la petite histoire, à l’époque je n’avais pas de N64 mais il y a eu très tôt un émulateur super pour Mario 64, donc tous mes souvenirs sur ce jeu sont avec un rendu des textures qui n’était pas le vrai.

1 Like