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


#61

[stating the obvious]
Oui sûr que quand une équipe de dev grossie, il faut prendre le temps de penser le refactoring du code et les concepts qu’il porte pour le rendre au plus clair/malléable et influer cette notion après de tous les développeurs (cela étant facilité si on place une couche de gestion “agile” du projet en complément).
“Sociabiliser le code” en gros… mais cela ne se fait pas sans temps alloué pour et sans avoir la volonté des développeurs eux mêmes.
[/stating the obvious]

Mais après que cela soit impossible pour une équipe de développeurs bossant jusqu’alors “chacun dans leur coin”, je ne le crois pas, car le plaisir d’un travail en équipe qui marche et tout aussi valorisant que d’avoir son quart d’heure de gloire sur un beau code pensé dans son coin.
Car de toute façon le travail de chaque développeur est d’autant plus reconnu s’il se branche bien globalement et surtout cette reconnaissance perdure, alors qu’un code efficace mais qui n’est pas malléable peut passer de bijou à boulet.


#62

Ce n’est pas du tout le propos de Carmack.
Il parle du problème de perdre la notion de “vision globale” et d’unité d’un framework, pas de “travailler tout seul pour avoir toute la gloire à soi”.
Tu te places dans une optique de “réaliser le code le plus malléable possible pour que plein de gens puissent travailler dessus en même temps”, lorsque lui est dans une optique de réaliser le code le plus simple et le plus performant possible. Si tu as déjà essayé une fois dans ta vie d’écrire un code performant, tu devrais savoir à quel point tu te retrouves alors à vite t’éloigner de quelque chose de “clair et malléable”. Son propos est que plus tu rajoutes de features et de personnes sur un projet et plus tu lui rajoutes de l’inefficacité, c’est à dire de temps pendant lequel tu dois t’organiser pour que tout reste cohérent / les gens qui n’ont pas développés une partie passent dessus pour rajouter quelque chose ou corriger un bug.
Mais à aucun moment il ne dit que c’est mal, simplement que les projets grossissent et qu’il faut bien s’adapter, en acceptant cette surcouche d’inefficacité.

Mais où tu as lu ça dans la quote ?
Il faut vraiment que tu arrêtes de répondre à des trucs qui ne sont que dans ta tête.


#63

Je ne répondais pas aux propos pour les mettre en défaut, mais m’en servait comme base réflexion, sur laquelle tu viens de rebondir.
Arrivant d’ailleurs à la même conclusion que toi.

Ce n’est pas l’un ou l’autre d’après moi, ni pour lui non plus je pense, vu le découpage structurel de son moteur.

Et si j’évoquais le travers du “code dans son coin”, c’est car je l’ai souvent vu comme source du problème, ce travers résultant lui même non d’une volonté du développeur, mais d’un projet non réfléchi en amont dans l’optique d’un travail en équipe (plus que souvent du fait d’un planning serré), où chacun essaie de faire au mieux son boulot, mais détaché.
La possible réussite (gloire) résulte alors de la reconnaissance du travail effectué… détaché.


#64

J’aimerais bien te répondre, mais je ne comprends rien.
Sans déconner, plus ça va, et moins on te comprend. Vraiment.
Tu ne veux pas te remettre à faire des phrases simples ?


#65

Un truc super intéressant dans cette histoire, c’est que comme il le souligne lui-même les gens se sont concentré sur le système d’ombrage (qui était déjà plus trop top quand c’est sorti) alors qu’un truc carrément plus intéressant était le système d’écrans “live” manipulables et tout directement à l’intérieur du jeu.

Et sinon ce qui est toujours sympa avec Carmack (et aussi indiqué en bas d’interview) c’est qu’il ne cherche absolument pas à ne pas être technique ou à faire croire que le développement est une usine magique à rêves, il parle strictement développement et boulot. Même à la quakecon devant une audience de joueurs dont la plupart ne comprendront fondamentalement pas de quoi il parle il sera plus à fond dans les détails d’implémentation qu’un speaker GDC moyen.


On parlait des mégatextures dans Rage l’autre jour, avec les problèmes que cela amène en termes de production, de prédiction, etc… Il y a un papier super intéressant sur comment ils ont approché tout ça dans Battlefield 3 pour faire des textures virtuelles gigantesques avec du procédural, généré pendant que le jeu tourne à partir de données plus compactes et qui permettent d’avoir des textures encore plus grandes. Par contre c’est assez technique, hein, mais il y a deux-trois jolies images.

http://publications.dice.se/attachments/GDC12_Terrain_in_Battlefield3.pdf


#66

Oui je me faisais la même réflexion en jouant à Rage : les écrans interactifs de DOOM 3 étaient super impressionnants. Tandis que ceux de Rage sont standards et pas très wow.


#67

Shito : Juste que tout le monde est d’accord pour dire qu’il faut du temps pour réfléchir au découpage (équipe et code) d’un projet.
Et qu’il n’y a pas (ou plutôt plus) d’opposition entre un découpage de cet ordre et la performance, étant donné que les langages utilisés désormais permettent cela sans perte significative de performance, les processus critiques étant, ou pouvant être, de toute façon “API-sé”.

Surtout qu’il doivent de toute façon l’être. Car il n’est plus vraiment logique de concevoir même un bout de code comme seulement dédié à programme particulier.
Même au delà des gros moteurs/frameworks, toutes les boites de jeu/dev ont leur moteur/framework s’il n’en utilisent pas un du marché, ou tout du moins des bouts de code en “librairies”. On ne réinvente plus la roue comme le dit lui même Carmack.

Et donc, pour ma part, j’ai souvent entendu évoqué comme “fausse justification” au fait que cela ne se fasse pas, le fait que les développeurs préfèreraient de toute façon bosser dans leur coin (et aussi bien dans le domaine du jeu vidéo que dans le développement plus globalement, au delà des “on dit” type “lol la vision du développeur, la vision du designer, le vision du commercial”, je parle même de vécu).
Hors si cela est ressenti par certains “décideurs” et peut parfois être vrai pour certains développeurs, c’est le plus souvent car ces développeurs n’ont jamais eu l’occasion de vraiment travailler dans un contexte réfléchi en équipe.

Chev : Qu’entends tu par “ne cherche absolument pas à ne pas être technique” du coup ?
Parce que ce qui me parait justement intéressant dans les différents propos de Carmack que j’ai pu lire/voir, est qu’il évoque les points techniques complexes rencontrés, aussi bien positifs que négatifs, dans le détail (en vrai ingénieur quoi). Et qu’il sait les présenter afin toute personne un tant soit peu programmeur, puisse les comprendre. Il suffit de lui demander “que retenez vous ?” et hop il délivre ses réflexions.


#68

Sauf que ça n’a rien à voir avec la choucroute.
Carmack dit simplement que le “découpage” dont tu parles rajoute du temps “d’inefficacité”, pendant lequel tout le monde doit se mettre d’accord sur une vision commune, en y parvenant probablement jamais tout à fait.
Et si, il y a une différence fondamentale entre écrire un code qui recherche la performance pure et dure et un code qui pourra être malléable et utilisable par plusieurs personnes à la fois ; même lorsque tu écris du code “juste pour toi” tu dois t’en rendre compte assez facilement, de cet antagonisme entre “ça c’est optimisé pour faire ça, mais si je veux ensuite l’utiliser pour aussi faire ça peut-être que je devrais prévoir plus de cas, et donc rendre mon algo moins performant au passage”. L’optimisation est l’opposé de la souplesse.


#69

Encore une fois il ne s’agissait pas de mettre en défaut SES propos, mais certains propos que le passage en quote et ta réaction à celui-ci m’ont rappelé.
Et suite à cela, bien que ce que tu dises sur l’optimisation maximum, soit bien sûr oui, vrai, on ne recherche plus cela au détriment de la flexibilité dans des contextes pro/industrialisés.


#70

Parles-en aux mecs qui développent des moteurs de jeux.
Genre Carmack. :slight_smile:


#71

Ben oui justement, les deux derniers paragraphes de son interview, menant à la “conclusion”.


#72

Où, au juste, dans ces deux phrases, trouves-tu un quelconque rapport avec ce dont nous parlions ?
Il parle des MOTEURS de jeux, et du fait que l’industrie s’oriente vers un hardware qui réduit le champs des possibles, et donc des découvertes.


#73

Oui je quotais juste ces deux phrases pour ne pas remettre un gros bloc, celles-ci mettant en avant le fait que sa vision du développement de jeu vidéo incluait fortement les aspects d’industrialisation.


#74

Via Shishi, un article fascinant sur la création du premier Warcraft, par un mec qui a son permis. Des anedoctes de dingue par milliers.


#75

A noter qu’il dit une petite bêtise vers le début, considérant Dune comme le prédécesseur de Dune 2, ce qui n’est naturellement pas le cas, chacun des deux ayant plus ou moins été fait dans le dos de l’autre. Pour le reste c’est super intéressant. Vivement la suite.

Je relance avec un gars qui aimait bien From Dust et qui a refait les fonctions de base en webGL (démo sur le site). Accessoirement, c’est très intéressant pour voir à quel point des algorithmes d’érosion peuvent générer des terrains bien plus naturels que seulement les fractales, et aussi que de nos jours on peut faire les érosions en question très vite avec simplement avec des shaders.


#76

Clair que le plaisir de réussir à implémenter ce que l’on a envisagé, il n’y a rien de plus satisfaisant. :slight_smile:
Et comme tout est envisageable dans le code, c’est sans limite (j’entends pas de limitation par des contraintes physiques ou de coût ; bon après il faut gérer avec les possibles contraintes techniques du hardware, mais ça c’est tout un art et d’autant plus gratifiant lorsque l’on s’en sort) (et puis les contraintes de temps bien sûr, mais ça c’est le côté boulot).
Bon après il suffit de montrer notre réalisation à quelqu’un ne codant pas, pour qu’il casse notre joie et sortant un “ouai c’est bien” platonique, pensant intérieurement “enfin [tel jeu/soft/site] le fait déjà” (the story of my fckn IT life). Mais bon là dans son anecdote il y a clairement le côté pionnier qui est présent.


#77

Alors je comprends ce que tu veux dire, mais le principe justement, au delà de l’implémentation pure, c’est pas plutôt de bâtir un produit fini, dans lequel la feature ou la fonctionnalité prend son sens ? Je ne suis pas codeur, mais j’ai plus l’impression qu’au delà du feat technique, et de l’approbation pas tjrs avisé d’un mec qui n’y connait rien, ce ne serait plutôt le but final sur lequel il faut tacher de se focaliser ? Par exemple ici : bâtir un meilleur jeu de stratégie que Dune 2, plus facile à prendre en main et multijoueur ? Enfin c’est comme ça que je vois la perspective et le mandat d’un “bon” codeur.


#78

Oui je l’entendais comme cela, car tout algorithme n’est satisfaisant seulement lorsqu’il remplit sa fonction dans le soft.
Et là effectivement on le ressent d’autant plus dans ses propos du fait qu’il codait une nouvelle façon de manipuler les troupes.

Mais sans avoir terminer tout le soft, le bouclage d’un algorithme touffu est une “daily satisfaction” sympathique, enfin pour moi tout du moins. :slight_smile:
Comme un écrivain peut être satisfait d’un chapitre, ou un musicien d’une mélodie de son morceau.

[EDIT] (ok, je pense que c’est “Clair que le plaisir de réussir à implémenter ce que l’on a envisagé, il n’y a rien de plus satisfaisant.” qui t’a fais réagir dans ce sens, mais toute la phrase était une formule globale, valable entre autres, dans ce contexte)


#79

Je pataugeais un peu avec les persos d’Omikron (manque les coudes, genoux, n’importe quoi de flexible en fait) donc je me suis replié sur le format des niveaux de Populous 3 (qui a une communauté étonnamment active pour un truc aussi vieux et moins bien considéré par les critiques que les deux autres populous). Il y a deux techniques intéressantes liées au terrain dans ce jeu, toutes deux assez simples mais donnant un look très distinctif.

La première, c’est qu’au lieu de juste utiliser une texture qui se répète normalement pour la couleur, le terrain est coloré en fonction de son altitude, et la texture répétitive est utilisée pour décaler les couleurs vers le haut ou le bas.

Couleur uniquement en fonction de l’altitude:

Avec le décalage, beaucoup plus de personnalité:

En variant simplement la palette d’altitude et la texture, on peut avoir des feelings très différents d’un niveau à l’autre. J’adore le rendu, c’est dommage que Bullfrog soit mort avant d’avoir pu raffiner la technique.

Le deuxième truc rigolo, c’est que le jeu stocke un terrain tout à fait classique, une grille carrée, mais fait croire au joueur qu’il s’agit d’une sphère, simplement en utilisait un fisheye (spécifiquement, la variante orthographique). Je n’ai pas encore essayé de le reproduire mais voyez mobygames pour le résultat.


ça n’a pas de rapport direct, mais voici le futur de l’eau dans les jeux, qui explose From Dust (qui était déjà bien fort mais ne pouvait que déformer une grille, ce qui se voyait cruellement sur les tsunamis):

(sautez à 2:40 si vous voulez directement voir le meilleur bout)


(si vous vous rappelez l’océan dans le message d’intro du topic, c’est pas la même catégorie de simulation. L’océan était un shader qui savait reproduire un mouvement de vagues crédible mais inflexible, pas de réaction aux côte ou à des trucs flottants dessus. Celui-là simule les réactions de l’eau. La vraie excellence sera atteindre quand on aura un système qui peut switcher de l’un à l’autre).


#80

Il me semble que cela n’a pas été posté ici : la présentation de Tri-Ace au dernier Siggraph. Trop technique pour moi mais cela en intéressera sûrement plus d’un (mais pas plus de dix) sur Boulette.