Bâtir une communauté comme un service

Posté par  (site web personnel) . Édité par Benoît Sibaud, NeoX, Anonyme, Ysabeau 🧶 et claudex. Modéré par Ysabeau 🧶.
44
9
jan.
2021
Culture

Du 19 au 22 novembre 2020, Debian a organisé une « MiniDebConf » en ligne avec pour thème principal le jeu vidéo, et nattie a invité le projet Unvanquished à soumettre une conférence. Membre actif de ce projet j’ai proposé le sujet suivant :

Bâtir une communauté en tant que service : comment cesser de souffrir de « ce code est censé être forké ».

Dont voici la présentation :

Il est connu que les précédents moteurs id Tech ont vu leur code source ouvert lorsqu’ils furent remplacés et donc non rentables. Bien que l’apport à l’humanité fut gigantesque, les développeurs de jeux souffrent encore aujourd’hui des choix de conception et de l’état d’esprit induit par le fait qu’une telle base de code était destinée à mourir. 20 ans plus tard, nous nous concentrerons sur l’héritage de l’id Tech 3, sur la manière dont le marché, les communautés open source et les pratiques de développement ont évolué, et nous embarquerons dans l’aventure de la transition nécessaire depuis des vidages de dépôt de code mort à un écosystème en tant que service.

Mini Deb Conf: bâtir une communauté comme un service

En partant de divers exemples tirés de l’industrie du jeu vidéo, la conférence est le fruit d’une quinzaine d’année d’observations et d’immersion et développe une réflexion plus large sur la nature d’un service, le besoin de développer des communautés, la place de la collaboration dans une communauté de logiciel libre, comment des choix de conceptions peuvent induire un état d’esprit qui nourrit la conception à son tour, etc. Sont abordées certaines problématiques comme le coût (éventuellement caché) de certaines pratiques, la nature d’une économie, ou encore comment certaines méthodes encouragent plus volontiers la production de déchet ou bien le recyclage de la production.

Cette conférence de 45 minutes a été donnée en ligne, en anglais, le dimanche 22 novembre 2020 à 19:30 UTC.

Cette dépêche propose une retranscription et traduction en français de cette conférence. La vidéo peut également être visionnée en anglais avec un sous-titrage francophone (ou anglophone).

Merci à Debian pour l’accueil et l’organisation de l’événement et à Thomas Vincent de Debian France pour la transformation de la retranscription en sous-titres et le fastidieux travail de synchronisation, ainsi que son méticuleux travail de relecture et de correction de la traduction en français.

Note de l’auteur — Cet article et la retranscription sont couverts par les termes de la licence CC 0 1.0 « Transfert dans le domaine public ».

Sommaire

Avertissement : Le sujet de cette conférence prend le parti d’étudier l’héritage du code libéré d’id Software d’un point de vue qui a été négligé par les études : ce qui peut être amélioré. L’héritage d’id Software a profondément changé le paysage, la libération du code a alimenté à la fois le monde universitaire et une passion vive chez de nombreuses personnes, et le jeu Unvanquished lui-même n’existerait tout simplement pas sans cet héritage. Rien ne doit donc être enlevé à la gratitude envers les différents acteurs qui ont rendu cela possible. Cependant, au-delà de se concentrer sur ce qui est très bon, il semble intéressant d’étudier également ce qui est moins bon, car c’est souvent moins la réussite que l’échec qui permet d’apprendre et de se dépasser.

Cet exposé présente des opinions personnelles et fait appel à des métaphores colorées (voire infernales, « doom-esque »).

La vidéo peut être visionnée avec les sous-titres (français et anglais) sur Youtube, ou visionnée en anglais sur le Peertube Debian (je ne sais pas quand seront disponible les sous-titres sur le Peertube) :

Bâtir une communauté comme un service, prévisualisation de la vidéo

La vidéo peut-être téléchargée ici (incluant les sous-titres et le chapitrage en anglais et en français). Les diapositives (en anglais) peuvent-être téléchargées ici. Les transcriptions, sous-titres, le chapitrage, les sources des diapositives et de la vidéo sont disponibles sur le dépôt GitLab de la conférence (les « rush » audio vidéo et vidéo sont pré-édités pour des raisons de discrétion mais le montage final doit pouvoir être reproduit).

Tout ce que j’ai produit d’original pour cette conférence (voix/image/texte…) est distribuée sous licence CC 0 1.0. D’autres licences peuvent s’appliquer (logos, images de décoration, la partie en direct).

Ci-après la transcription.

NdM.: il a été explicitement demandé à la modération de ne pas éditer la transcription.


Bâtir une communauté comme un service

Bonjour, je suis Thomas Debesse du projet de jeu Unvanquished. Je fais partie de la direction et suis un contributeur à de nombreux projets associés. Unvanquished est un jeu de science-fiction mêlant des mécanismes de stratégie en temps réel avec une vue de jeu de tir à la première personne. Le projet Unvanquished est destiné à fournir un jeu entièrement libre depuis le code jusqu’aux données.

Un service est un acte d’assistance auprès de quelqu’un

En dehors du développement de logiciel libre, je suis plus dans l’administration système et l’ingénierie de fiabilité de site (SRE, site reliability engineering), ou je dirais plutôt, ingénierie de réhabilitation de site (site rehabilitation engineering). Ce qui fait de Debian une part importante de mon travail et je suis convaincu que l’un des premiers services de Debian après sa communauté est une méthode de travail. Quand votre travail est de fournir des infrastructures, le logiciel lui-même devient moins important
que la manière dont vous l’utilisez, et Debian définit des moyens de traiter les problèmes et construit un état d’esprit pour les penser.

Thomas est un chef du projet Unvanquished Unvanquished est un jeu libre de stratégie en temps réel à la première personne Debian définit des méthodes de travail

Parce que ce que je fais est de rendre les autres capables de faire leur propre travail, je connais le premier sens d’un service : un acte d’assistance auprès de quelqu’un.
Je crois qu’il est important de replacer ce mot dans nos métiers, un service n’est pas une fonction logicielle, n’est pas un abonnement à une industrie économique, un service est un acte d’assistance auprès de quelqu’un.

Le moteur de jeu propulsant le jeu Unvanquished est nommé le moteur Dæmon, lui-même étant un petit-petit fils de nombreux forks incluant Quake 3.

Les projets basés sur le code ouvert d’id Software font face à de très nombreux forks. Nous investiguerons les raisons pour lesquelles ce problème ne réside pas seulement dans le côté humain des personnes, mais comment la conception du code induit ce comportement. Nous essaierons de comprendre pourquoi certains projets arrivent à développer des communautés et d’autres non, et ce qui peut être fait pour limiter le gaspillage de ressource et prendre soin des efforts humains, ce qui est prendre soin des humains eux-mêmes.

Une histoire des moteurs id Tech

Pour commencer, nous allons observer l’histoire des jeux id Software.

Dans les pas du succès de Wolfenstein 3D, Doom est sorti en 1993 et son code source ouvert en 1999. Ce moteur est d’ordinaire appelé id Tech mais le terme de “moteur” ne correspond pas au sens actuel et les noms comme id Tech 1, 2, 3 et les autres font partie d’un effort rétroactif pour nommer les instantanés (snapshots) de code de manière à ce qu’ils ressemblent aux produits faits par d’autres sociétés.

Il n’y a jamais de choses comme des moteurs id Tech à l’époque. Il y avait le moteur de Doom, le moteur distribué avec Doom. Ensuite, des dérivés ont été faits à partir de lui, ce que l’on appelle fork.

Distribué en open-source quand devenu obsolète

Quake est sorti en 1996 et tandis que Doom était un jalon important dans le jeu à la première personne, Quake fut un jalon important pour les environnements 3D. En 2020 un jeu comme Xonotic utilise toujours un moteur basé sur et compatible avec Quake premier du nom tout en fournissant une scène compétitive et une expérience de jeu actuelle.

Les Jeux id Software arrivant après Quake sont des améliorations itératives au-dessus de Quake, de même pour les outils. Les moteurs distribués avec les nouveaux jeux sont des instantanés de l’arbre des sources et ces jeux sont des forks.

Quake II a été distribué en 1997. Tandis que Quake et Quake World furent ouverts en 1999, le code de Quake II fut ouvert en 2001. Ces trois forks de Quake sont rétroactivement appelés sous le même nom id Tech 2.

Des instantanés de Quake et Quake II furent vendus et utilisés par des sociétés tierces comme base de jeux et de séries comme Kingpin, Soldier of Fortune ou Half Life.

En tant que société, id Software vendait essentiellement deux choses : des jeux, et des instantanés de code (snapshot).

Nous pouvons dire que certains instantanés d’id Tech 2 furent ouverts, mais cela ne fait pas sens de dire que id Tech 2 l’a été. id Tech 2 est seulement une approximation commode pour classer diverses choses qui sont proches les unes des autres, cela ne nomme pas un produit tangible.

Grâce à l’ouverture du code des projets communautaires open source émergèrent comme Nexuiz et son successeur Xonotic, Warsow, AlienArena, UFO: Alien Invasion, DDay: Normandy, l’à venir Quetoo, etc. Nous pouvons même voir des sorties commerciales comme le prochain Wrath: Aeon of Ruin par 3D Realms qui utilise le moteur DarkPlaces comme Xonotic.

id Software a sorti Quake III Arena en 1999. Les instantanés de code sont rétroactivement appelés id Tech 3. id Software a ouvert l’instantané Quake 3, l’instantané Return to Castle Wolfenstein, et l’instantané Wolfenstein: Enemy Territory. Une autre société a ouvert deux instantanés de jeux Jedi Knights.

Ce code source de Quake 3 eu beaucoup de succès et fut utilisé dans de nombreuses franchises bien connues
comme celles que l’on vient de citer mais aussi Star Trek Elite Forces, encore une fois Soldier of Fortune, Medal of Honor, quelques jeux James Bond, Resident Evil, Call of Duty et d’autres.

En 2005 le code de Quake 3 fut libéré quand il était obsolète d’un point de vue économique. Les anciens codes étaient ouverts par id Software quand un autre code était commercialisé à la place.

Sélection de jeux construits sur le code de Quake et Quake 2 Sélection de jeux construits sur le code de Quake 3 Une chronologie de quelques sorties et libérations majeures d’id Software

Cette ouverture a permis de nombreux jeux libres, ou jeux avec un code source libre, de devenir des choses autonomes. Nous pouvons citer Tremulous sur lequel Unvanquished est fondé, World of Padman, Smokin' Guns, OpenArena et d’autres. Urban Terror a été distribué avec le moteur Quake 3 open source mais le code du jeu fut toujours propriétaire.

Doom 3 a été distribué en 2004 et son code source ouvert en 2011. Comme à l’ordinaire des instantanés
furent utilisés dans des franchises établies comme Doom, Quake, Enemy-Territory et Wolfenstein, mais moins d’instantanés semblent avoir été vendus à des sociétés tierces. L’ouverture du code de Doom 3 a donné naissance à moins de projets libres, mais nous pouvons nommer The Dark Mod qui a construit un produit viable.

Nous pouvons encore remarquer la confusion entre les moteurs utilisés par tous ces jeux et ceux qui furent ouverts, sur la page Wikipédia anglophone sur le jeu vidéo Quake nous pouvons lire :

Quake 4 […] utilisait le moteur de Doom 3.

Mais vous ne pouvez pas faire tourner Quake 4 avec le moteur fermé de Doom 3, pas plus avec le moteur libéré. Ces moteurs sont des forks incompatibles.

Le code de Doom 3 fut couvert par une licence différente des codes précédemment ouverts. Quand on regarde les dérivés de Quake 3 et de Doom 3 ayant leur code ouvert, nous pouvons voir des projets ayant une licence GPLv2 seulement, GPLv2 ou supérieur, et GPLv3. Il peut donc être compliqué d’échanger du code.

Dans ce cas les licences copyleft semblent être un moyen pour les sociétés impliquées de garder le contrôle du code source, comme une variante non-commerciale mais avec le sceau d’approbation de la FSF et de l’OSI. Cela a l’inconvénient de limiter ce que la communauté peut faire et éventuellement rendre plus difficile pour les personnes de travailler ensemble, échanger du code, rétroporter du code et fusionner des branches.

Le moteur de l’époque d’id Tech 5 utilisé par le jeu Rage n’a pas vraiment été utilisé en dehors d’une poignée de titres Wolfenstein et quelques rares autres. Les moteurs de génération id Tech 6 et 7
semblent ne pas avoir été utilisés en dehors de jeux préexistants comme Doom et Wolfenstein et de ne pas avoir été commercialisé pour ce que j’en sais. Et avec Quake Champions ils ont commencé à utiliser du code tierce-partie. À ce niveau il semble que vous ne pouvez plus faire un jeu avec les technologies d’id Software actuelles.

Compétiteurs

Epic et son moteur Unreal

Un compétiteur bien connu d’id Software fut Epic Games. Ils ont sorti Unreal Tournament en 1999, presque au même moment que Quake III Arena.

Rendre possible la modification est différent de concevoir pour la modification Epic and Unreal : l’éditeur d’abord Epic : la communauté d’abord

Epic Games et les jeux id Software ont attiré une large communauté de modders, des personnes réalisant de nouveaux niveaux, implémentant des modifications de jouabilité et plus encore. Tandis que le temps passe nous pouvons remarquer des différences parmi la façon dont ces modifications furent prises en compte.

Si vous regardez le code d’id Software, vous remarquerez une grande quantité de choses qui vous donnent la possibilité de modifier et étendre le jeu, et faire de nouveau jeux à partir de ça.
Je dis que le design « rend possible de modifier » et je ne dis pas qu’il est conçu pour être modifié.
Certaines choses dans le code d’id Software sont pensées pour que réaliser des modifications soient une chose facile mais lorsque vous y faites face vous découvrez qu’elles rendent possible de faire des choses nouvelles mais ne s’attendent pas à ce que cette modification soit faite par vous.

Epic et Unreal ont commencé avec des éditeurs. Le premier jeu de Tim Sweeney ZZT a évolué depuis un éditeur de texte. Ce jeu de 1991 était distribué avec un éditeur de niveaux et a toujours une scène active de modification (modding).

J’ai entendu dire que les développeurs à Epic Mega Games passaient leur temps sinon perdaient leur temps à jouer à Doom donc pour les rendre plus efficace dans leur travail, Tim Sweeney leur a écrit un éditeur. Pour ce que j’en sais, cet éditeur a précédé Unreal et a précédé Quake.

Le premier pas qu’Epic a fait pour que Unreal Tournament tienne la compétition avec Quake III Arena avant que Quake 1 soit annoncé fut un éditeur.

Après la sortie d’Unreal de nombreux développeurs ont demandé à utiliser le moteur. Le code source semble
avoir été rapidement re-designé pour être réutilisable, de même pour l’éditeur.

Si vous regardez ce fil de discussion de 2003 sur gamedev.net, vous pouvez voir une personne dire :

Je suis quasiment sûr que cette chose telle le « Unreal Engine » n’existe pas. Le moteur utilisé dans tous les jeux Unreal est optimisé et modifié pour chaque jeu Unreal.

Et quelqu’un d’autre cite le site web Unreal Developer Network de l’époque en disant :

L’Unreal Developer Network est un groupe de sites et de services fournissant du support et des ressources pour les licenciés utilisant les derniers build d’Epic Games, (builds 600+).

Puis la personne continue en disant :

Le moteur est en développement continu […] et les fonctionnalités sont seulement figées pour la sortie du jeu (si tu licencies le moteur de la part d’Epic tu peux avoir les mises à jour pour le moteur à tout moment).

C’est le moteur Unreal

Le site web d’Epic Games disait à cette époque au sujet de l’Unreal Developer Network :

Les licenciés reçoivent le code source complet pour notre moteur, des outils et le jeu le plus récent.
Le support est fourni directement par l’équipe qui développe actuellement le moteur […] UDN est un dépôt de connaissance, de documentation et de tutoriels pour les « builds » récents de l’Unreal Engine.

À la question « est-ce le Unreal II Engine, le UT2003 Engine, le Unreal Warfare Engine, le Unreal Championship engine ou le Unreal Tournament Engine ? », la réponse était claire :

Ce n’est ni l’un ni l’autre. C’est simplement le « Unreal Engine ».

Bien sûr cela fait partie d’un effort de communication, mais tandis que nous voyons le flux de travail à base d’instantanés distribués comme id Software le faisait, cela révèle un tronc commun, ou comme nous pourrions l’appeler aujourd’hui, une branche maîtresse. Ils parlaient déjà de « build ». Cela signifie que le moteur doit être réaffectable sans requérir du développeur qu’il le recompile.

Aujourd’hui l’Unreal Engine est l’un des moteurs de jeux les plus populaires, ou cadriciel de jeu (game framework) comme les gens disaient à l’époque. Peut-être l’Unreal Engine fut la cause de ce glissement de vocabulaire.

Epic a construit une communauté de développeurs de jeu autour de leurs technologies, ils fournissent
des outils réutilisables et des éditeurs, et maintenant ils se concentrent sur le fait de faire se rencontrer artistes et développeurs. Ceci est fait avec la communauté à l’esprit. Le premier produit d’Epic est son service, et la communauté est un service en elle-même.

Bien que non-libres, les sources de l’Unreal Engine sont mises à disposition et il est prévu de recevoir des contributions en retour de la part des développeurs de jeu. C’est la problématique des projets logiciels qui sont en vie.

Valve et le moteur Source

Bien que nous puissions nous attendre à ce que des gros projets de jeux puissent utiliser des branches personnalisées du moteur, avec le temps il devient évident que l’un des premiers services à rendre aux développeurs de jeux est un « précompilé » (build) réutilisable.

Gold Source de Valve est basé sur Quake Des outils pensés pour être réutilisables Valve : la communauté d’abord

Concentrons-nous désormais sur Valve. Valve a obtenu des instantanés de Quake et Quake II, et quand ils les eurent dans les mains ils appelèrent ceci de l’or. Ils appelèrent leur arbre de source « Gold source ». Ils sortirent Half Life sur le moteur qu’ils bâtirent à partir de cela et plus tard, de la même manière qu’Epic Mega Games a retiré l’adjectif « Mega » pour se focaliser sur « Epic », Valve a retiré le mot « Gold » pour se focaliser sur « Source ».

Le moteur Source de Valve est prévu pour être réutilisable. Vous pouvez installer le « Source 2007 SDK » dans Steam et installer le jeu « GoldenEye: Source ». Les développeurs n’ont pas à compiler le moteur eux-mêmes. Le moteur source n’est pas un modèle (template), vous ne devez pas le forker, le compiler et le maintenir vous-même.

Valve fournit des outils comme l’éditeur de niveau Hammer et le compilateur de carte. Ces outils sont maintenus par Valve et conçus pour être réutilisables. Les cartographes (mappers) n’ont pas à recompiler les outils.

Il semble que cela n’a pas été si évident du côté d’id Software.

Avec Steam, Valve a bâti une distribution logicielle. Ils ont donc eu à concevoir leurs logiciels
de façon à ce qu’ils soient distribuables dans un dépôt, ils ont résolu la duplication des fichiers
et la fragmentation des fichiers, ils ont résolu les dépendances et ont rendu possible pour des équipes diverses d’avoir leur propre cycle de production tout en dépendant les uns des autres. Au-delà des questions légales et idéologiques, peut-être pourrions-nous techniquement faire des paquets Debian
du moteur Source et des jeux. Du moins, certains problèmes ont été corrigés, Valve dut le faire.

Valve porte ses précédents jeux vers les versions mises à jour du moteur. Ils ne voient pas le vieux code comme du code mort, et ils doivent traiter des problèmes spécifiques que vous rencontrez en portant des jeux. Leur conception ne doit pas empêcher des portages de se produire.

Tandis que ces produits ont leur code source fermé on voit qu’ils ont trouvé des solutions à des difficultés que nous rencontrons en tant que communauté de logiciel libre. Le premier produit de Valve est son service et la communauté est un service elle-même, c’est la problématique des projets logiciels qui sont en vie.

Ces services induisent des méthodologies comme Debian en tant que distribution logicielle doit développer des méthodologies.

Du côté libre : Godot

Godot : la communauté d’abord

Du côté libre, Godot est un écosystème libre et open source qui est en compétition avec des moteurs
comme Unreal, Unity ou Unigine, mais n’est pas en compétition avec id Tech pour une raison simple : Godot est pensé pour être réutilisable depuis le début et le développement est pensé pour recevoir des contributions dans la branche principale. Par conception Godot n’est pas voulu pour être un jeu en lui-même mais la technologie sous-jacente pour vos jeux. Le produit n’est pas le jeu, mais les outils.
Cette perspective introduit des problèmes intéressants à traiter.

En tant que développeur de jeu, vous téléchargez une version pré-compilée de Godot et c’est parti. Godot est pensé avec la communauté en tête, bâti comme un logiciel communautaire libre et open source.

Les moteurs id Software, éditeurs et outils étaient des modèles

À la différence des autres que je viens de citer, les codes ouverts et fermés d’id Software étaient des modèles (templates).

id Software vendait des modèles de jeu Ça a toujours été fait ainsi Corriger l’état d’esprit induit par le code

Quand vous faites un jeu basé sur les technologies d’id Software, vous devez forker une arborescence existante et la maintenir vous-même.

id Software vendait des instantanés de codes comme des modèles, et en tant que développeur vous aviez à faire des modifications nécessaires pour que ce ne soit plus destiné à un autre jeu mais au vôtre. Ceci est appelé « instanciation ».

Il y a quelques fonctionnalités limitées pour exécuter un mod « conversion complète » avec un jeu existant, mais vous ne pouvez pas prendre une précompilation du moteur et simplement la rempaqueter avec votre jeu pour en faire un jeu autonome qui tourne sans l’original.

Vous devez faire des changements nécessaires et mettre en œuvre l’infrastructure pour recompiler le moteur vous-même. Ceci produit un « état d’esprit induit par le code ».

Parce que le code lui-même est conçu pour être forké, quand vous travaillez avec, si vous n’essayez pas
de penser en dehors des clous et de faire des efforts spécifiques pour aller contre ce que le code induit à votre esprit, vous commencez à penser que la seule manière de faire des choses est de forker sans contribuer en retour. Si vous demandez « pourquoi je devrais forker ? », certaines personnes pourraient vous répondre comme si vous aviez posé une question idiote s’ils ne répondent pas tout simplement « on a toujours fait comme ça ».

Pour prévenir cela du côté du moteur des changements de conception sont requis.

Pour corriger l’état d’esprit au niveau du code du jeu, le plus simple serait de cloner un dépôt amont et de faciliter les fusions dans un sens et dans l’autre. Les anciens systèmes de suivi de version comme Subversion sont aussi connus pour rendre la collaboration plus coûteuse que de forker c’est pourquoi utiliser des outils induisant de bonnes pratiques comme Git sont une bonne idée.

Parce que les codes d’id Software furent ouverts parce qu’abandonnés, en dehors de quelques projets comme le nôtre vous ne pouvez pas compter sur un amont (upstream).

Du côté du code du jeu il est aussi possible de diviser des parties du code en bibliothèques réutilisables. Pour Unvanquished nous ne considérons pas encore cette éventualité, mais nous avons jeté
le code d’interface historique pour une bibliothèque tierce-partie que nous ne maintenons pas nous-mêmes,
et pour d’autres parties nous avons introduit quelques mécanismes de génération de code.

Des formats de fichiers destinés à être forkés

Le format de fichier BSP devait être forké pour ajouter des fichiers Exemple du greffon Blender de SomaZ : personne ne veut le forker pour tous les jeux Modifier le format BSP perd la compatibilité avec les outils et les fichiers existants

Jetons un œil au format de fichier BSP. BSP est le nom d’une technique pour stocker des informations spatiales pour le niveau du jeu en tant que modèle 3D. Nous ne nous focaliserons pas sur cette technique
mais sur le fichier avec une extension .bsp qui est utilisé pour stocker ces informations et d’autres choses.

Vous pouvez voir un fichier BSP comme un tarball primitif : un container pour de multiples fichiers
que le moteur de jeu charge. Cela peut être le modèle 3D lui-même mais aussi d’autres chose comme des images. Un fichier BSP commence par une entête avec des nombres magiques (magic numbers), comme la chaîne « IBSP » pour les jeux id Software, « RBSP » pour les jeux Raven, « VBSP » pour les jeux Valve. Puis un numéro de version. Après cela vous devez vous attendre à ce que tout le reste soit non-documenté et spécifique à chaque fork sur terre.

Il y a un tableau pour les entrées de sous-fichiers avec leurs décalages (offset) et tailles,
mais il n’y a pas de nombre pour vous dire combien de fichiers il y a. Donc, vous ne pouvez pas extraire de sous-fichier provenant d’autres forks.

Imaginez que chaque jeu basé sur id Tech utilise son propre format tar, et que si votre jeu a besoin de distribuer un fichier supplémentaire, il vous est requis de forker le format tar et de créer une autre variante non-documentée.

Tout d’abord le problème ne semble pas si problématique parce qu’il est aussi attendu que vous forkiez l’éditeur de niveau, le compilateur de carte qui produit les données BSP, et de forker le traceur de rayon pour faire le rendu des cartes de lumière (light map). Tout fonctionne dans votre écosystème fermé qui n’échange jamais avec le monde.

Les choses commencent à devenir difficiles quand vous avez besoin de sortir de cet état d’esprit. SomaZ du projet OpenJK est en train d’écrire un greffon Blender pour charger des fichiers BSP et rendre les cartes de lumière en utilisant le traceur de rayon Cycle. Personne ne veut forker ce greffon pour chaque jeu, donc au final un tel greffon devra implémenter
votre propre variante spécifique à votre jeu si vous voulez l’utiliser.

Quand vous êtes un éditeur des années 90 gravant des jeux sur des CD ROMs qui ne seront jamais mis à jour, vous ne vous en préoccupez pas. Mais même si les jeux id Tech ont été produits avec le marché du PC en tête, quand vous mettez en œuvre les technologies ouvertes d’id Software vous appliquez des méthodologies qui conviendraient parfaitement si vous cibliez des cartouches de consoles.

Le jeu Unvanquished utilise le moteur Dæmon qui est un fork du moteur XreaL qui est un fork du moteur ouvert de Quake 3. Pour introduire de nouvelles fonctionnalités et pour résoudre des problèmes, XreaL a dû étendre le format BSP. Ce moteur avait du code pour charger à la fois le nouveau format et l’original,
mais à cause de la manière dont ces formats et le moteur étaient conçus, vous deviez recompiler le moteur
avec des définitions (defines) spécifiques pour activer la prise en charge d’un format ou d’un autre, sans être capable de prendre en charge les deux au même moment. Pour Unvanquished et Dæmon nous avons pour le moment renoncé à ces améliorations pour ne pas perdre la compatibilité avec les logiciels tierce-parties et les actifs (assets) existant, mais cela signifie que nous devons contourner des problèmes qui ont des correctifs connus que nous n’utilisons pas encore.

Des éditeurs destinés à être forkés

Longue liste de fork de radiant

Du temps de Quake il y avait un éditeur de niveau maison appelé QuakeEd, du temps de Quake 3 cet éditeur était nommé QERadiant puis Q3Radiant, de là vous obtenez CoDRadiant pour Call of Duty, MoHRadiant pour Medal of Honor,
vous avez compris…

Comme le moteur, l’éditeur de niveau devait être forké, instantié, édité pour s’adapter à votre jeu spécifique,
construit et maintenu par le développeur de jeu. La même chose se produisait avec les outils de compilation de carte.

Ici est ma liste personnelle d’instance de Radiant connus pour divers jeux. Attendez-vous aussi à une longue liste pour les compilateurs de cartes et traceurs de rayon.

Quand vous regardez en dehors de cet héritage d’id Software, il n’y a pas de DarkBlender, pas de NetBlender,
pas de ÜberBlender… mais quand vous jonglez avec les technologies d’id Software, vous le devez. Ceci n’est pas seulement parce que le code ouvert est mort, non-supporté et que les gens ne savent pas travailler entre eux.
La raison est que c’était voulu comme cela : les dévelopeurs payant id Software à l’époque devaient forker et faire le travail de maintenance et de publication de l’éditeur. Splash Damage avait son propre fork à l’époque, Raven avait un fork par jeu et ça fait beaucoup.

Radiant est peut être OK pour des employés, pas pour des indépendants La liste des forks de compilateurs de cartes est toute aussi longue À l’époque de Quake Live id Software a forké l’éditeur tandis que la communauté le maintenait

À un moment id Software a ouvert le code source de l’éditeur et du compilateur de carte de Quake 3, il a été porté vers GTK pour devenir multiplateforme, et rendu à peu près multijeu. Ne vous attendez pas à ce que la fonctionnalité multijeu aille de soi. Ce n’est pas prévu pour que vous travailliez sur plusieurs jeux en même temps, multijeu signifie seulement que vous n’avez pas à réinstaller l’éditeur quand vous arrêtez de travailler
sur un jeu pour travailler sur un autre.

Même avec cette amélioration multijeu, l’éditeur de niveau Radiant n’attend pas de vous que vous éditiez des niveaux pour un jeu un jour et pour un autre jeu un autre jour. Cela peut satisfaire le modèle de développement de jeux commerciaux, mais pas le modèle de contribution d’une communauté bénévole et libre motivée par la passion et le désir.

L’éditeur s’attend à ce que vous stockiez les fichiers à seulement un endroit codé en dur, donc vous ne pouvez pas stocker vos fichiers où vous le voulez. Ceci est suffisant si vous faites partie d’une équipe travaillant sur un seul jeu dans un dossier partagé fourni par votre société, pas si vous êtes un passioné.

L’histoire a aussi révélé un comportement intéressant d’id Software : quand ils ont eu besoin d’un éditeur de niveau pour leur jeu Quake Live, au lieu d’utiliser GtkRadiant 1.5 qui était maintenu par la communauté après qu’ils l’ont ouvert, ils sont simplement revenus à une ancienne version 1.4 qu’ils ont gardée en interne avant de la republier et la réouvrir une nouvelle fois. Ils ont forké leur propre code depuis une ancienne version,
et après cela les gens ont eu à choisir entre deux forks parce que les fonctionnalités et la prise en charge des jeux étaient partagées. À ce niveau il semble qu’id Software ne savait pas comment faire avec une communauté.

Il n’y a pas de DarkBlender, pas de NetBlender, pas d’ÜberBlender Forks de Radiant déjà distribué dans Debian Changements apportés à NetRadiant pendant les trois dernières années tandis que le logiciel est vieux de 20 ans

Voici une simple liste de fonctionnalités qui furent ajoutées à l’initiative d’Unvanquished à la branche NetRadiant, qui est le fork communautaire avec probablement la liste la plus étendue de jeux pris en charge aujourd’hui :

  • ouvrir un fichier depuis la ligne de commande et le gestionnaire de fichier,
    cela a été implémenté en 2017.
  • charger les données de jeu depuis des chemins arbitraires et prédéfinis,
    cela a été implémenté en 2017.
  • changer le jeu courant sans avoir à redémarrer l’éditeur vous-même, recharger la carte courante avec le nouveau jeu dans l’éventualité où vous auriez chargé la mauvaise carte avec le mauvais jeu,
    cela a été implémenté en 2019, l’année dernière.

La capacité de choisir où sauver vos données et d’ouvrir un fichier depuis le gestionnaire de fichier fut ajoutée pendant les trois dernières années, pour un logiciel conçu avant l’an 2000. Pourquoi cela a pris tant de temps est parce que ce logiciel est pensé pour être forké pour cibler la hiérarchie spécifique de votre jeu.

Parce que ceci est une conférence Debian, je cite une fonctionnalité spéciale qui a été ajoutée à NetRadiant en 2018 : rendre possible d’installer l’éditeur en suivant le standard FHS (File Hierarchy Standard). Quand il est attendu que vous distribuiez un fork de l’éditeur avec chacun des différents jeux que vous publiez, rendre l’éditeur capable d’être installé globalement est la dernière de vos préoccupations, et cela pourrait même être stupide parce que tous ces forks seront distribués avec les outils associés comme les compilateurs de carte qui pourraient partager le même nom de binaire mais sans avoir le même comportement.

Il y a déjà deux forks de Radiant distribués dans Debian, DarkRadiant qui est un fork de NetRadiant destiné pour The Dark Mod et focalisé sur les jeux basés sur Doom 3, et UFO Radiant qui est un fork d’une autre branche de DarkRadiant qui peut seulement éditer les données du jeu UFO: Alien Invasion.

Au sujet du développement logiciel et du sacrifice d’enfant

Le flux de travail tue le précédent pour rediriger les ressources et le support de vie vers le nouveau

Donc, nous avons mis en lumière plusieurs choses :

  • la technologie d’id Software est très efficace mais c’est comme si chacune de ses parties suppose que vous forkiez l’ensemble et ne contribuiez jamais en retour ni ne mutualisiez les efforts de développement,
  • les moteurs id Tech étaient censés être vendus et oubliés. Il semble que cela a été conçu pour une seule relation sociale : la vente,
  • les formats de carte, matériaux, code réseau et autres choses ne sont pas vraiment pensées pour être étendues, versionnés, et dans de nombreux cas, il n’y a rien pour seulement détecter le format, quand parfois un seul entier aurait été suffisant pour parser des données inconnues.

À peu près tout dans les moteurs id Tech est pensé pour distribuer un jeu qui va tuer le précédent. Le développement nouveau est pensé pour distribuer un jeu incompatible. La conception est pensée autour de cet état d’esprit, et ensuite le design induit cet état d’esprit à son tour.

Forker est comme donner naissance à un nouveau-né La conception d’id Tech suppose que vous forkez Les méthodologies évitent les situations requérant de résoudre des problèmes

Forker un projet logiciel c’est comme donner naissance à un enfant, un fork est aussi fragile qu’un nouveau-né : il ne peut rien faire d’autre par lui-même que mourir. Si vous n’êtes pas capable de donner assez d’attention et de soin à un nouveau-né, le bébé va mourir. De même pour les forks.

Le flux de travail d’id Software à l’époque ressemblait à du sacrifice d’enfant : à chaque fois qu’un nouveau jeu devait être développé, l’enfant précédent était tué pour rediriger les ressources et le support de vie sur le nouveau. À la différence des autres développeurs de moteur de jeu comme Epic ou Valve, id Software n’a jamais pris le risque de laisser son enfant atteindre l’adolescence et devenir un adulte.

Ils n’ont pas distribué de précompilation réutilisable du moteur, les éditeurs n’étaient pas vraiment réutilisables, ils n’ont pas construit une communauté autour des outils comme si c’était un produit par lui-même, ils n’ont pas bâti une distribution logicielle donc ils n’ont jamais eu à en résoudre les problèmes associés, ils n’ont pas bâti un système de distribution de données donc ils n’ont pas eu à traiter les problèmes
d’incompatibilité de formats et de conflits de fichiers.

À un moment dans le développement de jeu avec du code basé sur id Tech, vous remarquerez que pour solutionner certains problèmes vous ne devez pas seulement étendre votre moteur mais forker votre propre jeu. En travaillant sur Unvanquished je dois avoir rencontré cette situation 5 ou 6 fois.

D’une certaine manière on peut mesurer le génie impressionnant de John Carmack par le fait que ses compétences techniques ont gardé id Software en vie pendant tant d’années malgré tant d’erreurs commerciales, ratages stratégiques et pertes d’opportunité, empêchant leurs propres communautés de joueurs de grandir avec eux.

Du code mort produit des zombies

Avec une telle rétrospective, ce qui semble bizarre est découvrir que c’est parce que le code était mort, je veux dire tué, qu’il était possible de l’ouvrir. Donc d’un côté nous avons reçu un code libre et ouvert,
mais de l’autre ce code était censé être mort et produire des morts-vivants (zombies).

Aussi, le moins vous obtenez des contributions, plus facile il devient pour votre service juridique
de mettre tout en ordre pour une libération du code. Donc c’est comme s’il était plus possible pour le code source d’id Software d’être ouvert parce que le flux de travail était plus fermé que les autres.
Ça fait un peu bizarre de s’en rendre compte.

En 2020, aucun développeur de jeu recherche un moteur qui requiert d’être forké et maintenu seul.
Pour Dæmon un de nos objectifs est de rendre possible à un développeur de jeu de simplement réutiliser une précompilation existante, disons celui que nous faisons pour Unvanquished, et de l’empaqueter avec son propre code de jeu et ses données. Cela n’est pas entièrement terminé, mais nous voulons que ce le soit.

Un état d’esprit induit par le code

Le VFS PK3 est conçu pour recevoir des mises-à-jour de la part du vendeur, pas de vous Le VFS DPK introduit un nouvel état d’esprit et une économie Le BSP n’a rien pour versionner les formats d’image

Le moteur de Quake 3 vient avec une fonctionnalité vraiment sympa appelée VFS PK3, c’est un système de fichier virtuel qui facilite vraiment l’extension de données de jeu. Mais ce n’est pas conçu pour la modification (modding). Cela peut être utilisé pour le modding, mais c’est conçu pour permettre au jeu de recevoir des mises à jour provenant d’une seule source : le vendeur.

La conception n’empêche pas le jeu du joueur d’être cassé par n’importe quel fichier arbitraire provenant de n’importe quel serveur arbitraire. Donc nous l’avons étendu en créant le VFS DPK de manière à ce que cela rende possible de charger seulement une sélection prédéfinie de données au lieu de charger tout.

Cela n’est pas suffisant pour corriger certains problèmes et il y a quelques autres fonctionnalités à implémenter, mais vous verrez la différence entre concevoir un format pour permettre au vendeur de mettre à jour le jeu, et de concevoir le format en prenant en compte que des gens au hasard vont mettre à jour votre propre jeu.

Ce petit changement mineur introduit un nouvel état d’esprit. Parce que les paquets ont maintenant un nom de base et une chaîne de version standardisée (réutilisant le tri de version de Debian), il devient naturel de penser ces paquets comme des bibliothèques. Les artistes peuvent faire des bibliothèques de textures et des bibliothèques de modèles, ils peuvent avoir leur propre cycle de sortie et les cartographes (mappers) peuvent alors créer des niveaux utilisant cette-version-ci ou cette-version-là de bibliothèque de modèle ou de texture.

Ce changement que nous avons fait est tellement mineur que si vous ne faites que rétablir l’extension du fichier
pour celle attendue par Quake 3, un binaire d’il y a 20 ans peut lire les données.

Mais cette modification vraiment mineure signifie beaucoup de choses pour une communauté, chaque membre étant capable de développer son propre métier et ses relations aux autres, devenant un fournisseur pour d’autres ou se reposant sur des fournisseurs, ça s’appelle une économie.

Motif de consommation moderne

Nous avons parlé du format de fichier BSP. Il embarque des images qui sont des textures de lumières et d’ombres précalculées. Seulement un format de stockage était pris en charge et seulement une seule taille d’image permise, et il n’y avait rien pour décrire le format, seulement le nombre d’images était variable. Il y a plusieurs années des personnes ont eu la bonne idée de rendre le moteur capable de charger ces textures depuis l’extérieur de ce fichier. Cela a permis de nouvelles tailles, de nouveaux formats d’images incluant des formats compressés.

Ce simple exemple montre comment le premier concept requérait que les jeux forkent le format pour créer des variantes incompatibles si quelqu’un avait besoin de stocker des textures avec une plus grande résolution, quand le second concept permet à n’importe quel moteur d’ajouter n’importe quel format sans introduire des incompatibilités dans la spécification du fichier BSP lui-même.

Le code id Tech suivaitle motif de consommation linéaire moderne : production, consommation, déchet. Nos efforts à Unvanquished est de recréer un cycle. Et pour recréer ce cycle, nous avons à corriger le concept induisant l’état d’esprit du motif linéaire.

Sur le code open source et les communautés humaines de partage

Copie d’écran du billet de blog de Dave Airlie Les entreprises doivent passer du temps à construire des projets et des communautés Le modèle de distribution de sources n’est pas un modèle de développement partagé

Dave Airlie de Red Hat a publié un article de blog sur ce sujet pendant que je préparais cette conférence. Parlant de pile graphique au lieu de moteur de jeux, il a dit :

Il y a une grande différence entre les projets distribués comme open source et développés comme open source
en termes de durabilité et de communauté.

En théorie il pourrait être possible de produire une telle pile avec les bénéfices du développement open source, cependant la plupart des vendeurs semblent y échouer. Ils voient l’open source comme un modèle de distribution, ils développent en interne et jettent les résultats à la pelle par-dessus la barrière dans un dépôt github tous les X semaines, […] mais ils ne passent jamais de temps à construire des projets ou des communautés autour d’eux.

Il ajouta :

J’ai commencé radv parce qu’AMD promettait au monde un pilote Vulkan open source pour Linux […]. Mais quand il fut livré il était distribué comme open source mais développé en interne. Il n’y avait aucune passerelle pour la participation de la communauté […]. Comparez cela au projet radv dans Mesa qui permit à Valve de contribuer le compilateur backend ACO et fournir de meilleurs résultats qu’AMD […] n’aurait jamais pu obtenir, avec bien moins d’investissement et de main d’œuvre.

Il y a quatre choses importantes dans cette citation. Premièrement il est important pour les entreprises
de dépenser du temps à construire des projets et des communautés autour de leurs propres projets.

id Software a ouvert des moteurs mais n’a pas construit de communauté La conception ne reflète pas les problèmes rencontrés par les communautés La conception d’id Software économise les ressources au niveau local, pas à l’échelle de la communauté

En second, le nom de Valve a été encore cité. La frontière entre le bien et le mal n’est pas entre les hommes mais passe au travers de chaque être humain, de même pour les sociétés et organisations humaines. Tandis qu’Epic et Valve n’ont jamais rendu leur moteur de jeu libre et open source, ils comprirent ce qu’est une communauté.
De l’autre côté, tandis qu’id Software savait ce que c’était de publier son code de manière libre et ouverte, ils n’ont pas vraiment bâti de communauté autour d’eux, pas même de communauté à code fermé.

Quand vous regardez dans le passé il semble que les entreprises qui utilisaient les technologies d’id Software étaient plus susceptibles d’accepter cette situation étant donné que le code était efficace, et pour certaines d’entre elles la seule relation sociale a pu être la vente.

Rebecca Heineman, la développeuse du port 3DO de Doom a même dit que lorsque sa société a acheté le droit de porter Doom sur cette plateforme, elle n’a pas eu le code source au début. Cela n’était pas la faute d’id Software et elle n’a pas rencontré de problème particulier à obtenir une copie du source sur un CD en contactant John Carmack directement, mais cela signifie que même quand le code source est acheté à cette intention l’idée d’un service semble être optionnelle.

La conception logicielle reflète usuellement les services autour de lui. Bien sûr nous ne pouvons pas attendre
des méthodologies de l’époque de Doom d’être au niveau de celles actuelles, mais quand on regarde les codes sources ultérieurs, ils ne semblent pas refléter de changements fondamentaux dans ces méthodes de travail.

La façon dont les problèmes sont solutionnés et fonctionnalités implémentées reflètent ordinairement les méthodologies et flux de travail. Et les reflets des problèmes rencontrés par les communautés sont difficiles à remarquer dans la conception du code d’id Software.

La troisième chose importante est la formulation que Dave utilise dans son billet de blog quand il parle au sujet du « modèle de distribution de source ouverte ». Nous pouvons enlever l’adjectif « ouverte ». Les logiciels id Tech semblent avoir été plutôt construits autour d’un modèle de distribution de source qu’un modèle de développement d’effort partagé, même si propriétaire et sous accord de non-divulgation.

La quatrième chose importante est le coût. Les logiciels id Software semblent avoir été seulement conçus
pour traiter des problèmes techniques, pas les problèmes sociaux comme récupérer les contributions en retour
et prévenir le gaspillage de ressources de développement à l’échelle d’une communauté. Les ressources semblent avoir été économisées au niveau local de l’entreprise au détriment de la communauté.

Enfin, une telle conception blesse profondément la croissance technique du logiciel lui-même quand il doit survivre à un homme ou à une entreprise, et que ce logiciel repose sur des contributions bénévoles.

Bâtir un écosystème et une communauté comme un service

Les humains ont besoin d’expérimenter les projets comme des amonts Rôder et vivre dans les communautés Pour ouvrir des portes vous devez regarder les chemins des gens

Comment faire qu’un projet comme Unvanquished et le moteur Dæmon fassent ce que le moteur Quake 3 n’a jamais vraiment fait sur le plan de la communauté et se fraient un chemin à travers l’enfer de l’état d’esprit de fork d’id Software ?

D’abord, ce n’est pas technique, mais les être humains ont besoin d’expérimenter un projet existant comme un projet amont. Par exemple quand vous avez besoin d’ajouter quelque chose à Blender, cela semble évident
que vous devez leur soumettre des patchs. Cela n’est pas évident en soi, c’est une connaissance qu’un projet doit construire.

Les gens doivent entendre parler des intentions des organisations et des personnes de relire et fusionner leur code. Les gens doivent entendre que leur code est censé faire partie d’un tout. Il est nécessaire de construire une visbilité sur ces buts et ces intentions.

Si vous pensez qu’il est évident que n’importe quel patch que vous feriez pour le noyau Linux ferait mieux d’être fusionné en amont (upstreamed), cela signifie que quelqu’un a semé avec succès ce sentiment dans votre cœur. L’industrie Android révèle que cette conviction n’est pas évidente : malgré tous les efforts faits
pour rendre l’amont clairement identifiable et le code et les outils conçus pour les contributions, de nombreuses entreprises agissent comme si le noyau Linux était conçu pour être forké et ils implémentent leurs fonctionnalités sur ce qui est déjà un cadavre de Linux.

Une chose très importante est de marauder (lurk) et de vivre dans les communautés, d’écouter leurs besoins,
remarquer les aspirations grandissantes, et d’accompagner les naissances. C’est comme sonder un marché sauf qu’il s’agit d’être un ami.

Nous ne pouvons sous-estimer l’importance d’être proche des communautés. Je viens seulement de découvrir ce mois-ci un autre projet basé sur XreaL à peu près en vie. Une refonte (remake) de Kingpin sur XreaL. Je fais partie de ceux ayant la plus profonde connaissance de tous ces forks mais j’ai manqué celui-ci pendant une décennie. Moins de deux semaines après avoir parlé pour la première fois avec l’un des contributeurs agonisants
il nous a aidé à corriger un problème pour notre version à venir. Cela m’a pris 10 années pour rencontrer cette communauté, j’espère que nous pouvons faire plus de choses ensemble.

Parfois un concept peut être amélioré seulement en parlant à d’autres même s’ils n’utiliseront jamais le logiciel. Cela aide à prendre du recul et avoir un meilleur panorama de ce qui peut être fait. Parfois on découvre que le logiciel peut faire plus que nos propres besoins en faisant seulement la même chose différemment. Pour ouvrir des portes vous devez regarder le chemin des gens.

Tout patch solutionnant un problème est pour de vrai

Les gens sous-estiment la valeur de leur contribution. Certains forks sont faits par des personnes bidouillant pour s’amuser ou des étudiants expérimentant quelque chose par curiosité. Ils ignorent souvent que ce qu’ils font est précieux. Cela peut être dû à des présupposés faux provenant du système scolaire qui leur font penser qu’ils ne sont pas encore des adultes ou pas encore des professionnels et que rien de ce qu’ils font ne l’est pour de vrai. Mais tout patch qui résout un problème est pour de vrai. Aussi en grandissant on découvre que les professionnels peuvent être simplement des adolescents prétendant être sérieux… Donc, personne ne doit sous-estimer la valeur d’une contribution.

Certaines personnes forkent simplement en disant « je veux simplement ajouter cela », supposant que le code original est terminé et qu’il n’y aurait rien à tirer de lui dans le futur. Le logiciel fermé peut introduire cet état d’esprit mais pour un projet open source il n’y a rien de tel qu’un code étant terminé. Aussi, ils ignorent que d’autres personnes veulent « simplement ajouter cela » aussi.

Le moteur Dæmon est pensé pour être réutilisable, de l’aide a été fournie par Xonotic Le coût de forker est supérieur au coût de contribuer en retour Laisser grandir un enfant signifie que tout le monde est libre

Comme nous le voyons avec les formats BSP et DPK, il est parfois possible de repenser les choses avec des différences vraiment mineures de façon à ce qu’il soit rendu plus facile d’étendre le code sans avoir à le forker. Parfois une seule petite modification peut révéler que l’idée de forker une base de code complète
pour changer la taille d’une image est du gaspillage, quand précédemment un tel fork pour une modification aussi mineure était requis par conception.

Pour Unvanquished nous avons clairement signifié que le moteur est censé être réemployable, et nous avons reçu beaucoup d’aide de la part de personnes de Xonotic pour diviser les arborescences et faire du moteur Dæmon un projet par lui-même. Parce que l’un des premiers services qui doit être rendu à un développeur de jeu est un binaire réutilisable, chaque problème qui empêche encore cela est désormais proprement rapporté et est prévu d’être corrigé un jour.

Une autre chose importante étant l’éditeur et les outils, avec encore l’aide de Xonotic nous avons fait beaucoup de travail pour rendre l’éditeur de niveau NetRadiant plus accessible aux nouveaux-venus et améliorer le flux de travail de façons plus naturelles.

Cependant, tant d’efforts n’ont pas empêché un autre fork de NetRadiant d’apparaître tout juste et les gens doivent à nouveau choisir entre quel jeu est pris en charge et les fonctionnalités, encore. Parce que ce fork est basé sur une vieille branche qui précède une large réorganisation du code, l’effort pour les fusionner est élevé et sur la base d’un salaire de développeur, le coût de la quantité de travail pour fusionner les deux branches serait un nombre avec quatre zéros si évalué en dollars. Cela ne serait pas le coût d’une fonctionnalité, cela serait seulement le coût du gaspillage. Faire travailler les gens entre eux est vraiment une route longue et difficile.

Le premier service que chacun reçoit dans la vie est une communauté

Ce qu’il est important de garder à l’esprit est qu’à un certain point le coût du fork est plus élevé que le coût de contribuer en retour. Cela peut être difficile à remarquer dans des communautés de personnes bénévoles quand vos propres actes ne signifient pas plus d’effort pour vous mais plus d’efforts pour les autres.

Nous ne pouvons pas faire de la magie et devons nous reposer sur la volonté des autres. C’est le risque de laisser un enfant grandir : nous pouvons donner la direction que nous pensons être la bonne, mais à la fin tout le monde est libre.

Un service est un acte d’assistance auprès de quelqu’un, et le premier service que chacun reçoit dans la vie est une communauté.

Questions

Sahil : Merci Thomas pour la conférence, passons aux questions, donc la première question est :

Tout cela me semble super, mais avez-vous déjà réussi à réunir à bord d’autre forks non-Unvanquished ?

Thomas : Si la question est au sujet des autres projets qui sont intéressés par notre moteur, aucun n’a encore abouti dans leur portage de leur jeu sur le moteur parce que cela requiert beaucoup de main d’œuvre, donc cela pourrait se produire dans le futur, mais pour le moment nous ne savons pas. Mais cependant cela nous a déjà aidé à, comment dire… par exemple ils ont corrigé des bugs ou nous avons trouvé des bugs que nous avons corrigés
en regardant comment rendre possible leur portage, donc au final si aucun jeu n’a encore été porté avec succès,
le moteur est meilleur grâce à eux, grâce à leurs effort pour leur portage.

Sahil : Très bien, ensuite je crois que la seconde question a déjà été répondue, à propos de l’animal vert.

Thomas : Oui ça s’appelle un granger. Il y a plein d’histoires qui ont été écrites par certaines personnes donc parfois vous pouvez entendre le nom de « Dave », vous pouvez lire ce nom dans certains de nos articles de blogs par exemple, blaguant à son sujet.

Donc il s’appelle Dave, c’est un granger. C’est une espèce dans Unvanquished qui a le rôle de construire les structures donc si tout est détruit dans l’équipe alien et qu’il n’y a pas de granger, l’équipe alien a perdu.

Sahil : Très bien ! Maintenant nous avons presque dépassé le temps, donc merci Thomas pour cette incroyable conférence et tout le travail que vous avez fait, et merci à Jathan pour la direction et, profitez de la suite de la MiniDebConf.

Jathan : Merci Thomas.

Thomas : À Bientôt !

Aller plus loin

  • # Au delà du fond, la forme : logiciels libres utilisés, etc.

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 10 janvier 2021 à 01:56.

    Pour information, voici les logiciels libres utilisés pour produire les divers fichiers et réaliser l’événement (liste non exhaustive):

    • Wordpress : rédiger le brouillon initial de la conférence (sur l’instance d’Unvanquished) et soumettre à pré-relecture/avis ;
    • Pandoc : convertir en markdown le texte anglophone ;
    • ghostwriter : traduction en français, séparation des transcriptions en propositions pour produire les sous-titres ;
    • LibreOffice Impress : réaliser les diapositives et les convertir en PDF ;
    • ImageMagick convert : convertir les diapositives en PNG ;
    • Audacity : traiter le son (débruitage, mise à niveau…) ;
    • Kdenlive (avec MELT) : monter la vidéo ;
    • GIMP : produire certaines images ;
    • FFMpeg : convertir certains formats multimédia, extraire les pistes de la partie en direct ;
    • Gnome Subtitles : Importer la transcription et synchroniser les sous-titres (utilisé par Thomas Vincent) ;
    • Aegisub : affiner la synchronisation des sous-titres avec précision (utilisé par Thomas Vincent) ;
    • srt-vtt : convertir des fichiers sous-titre SRT au format VTT ;
    • libxml/xmllint : valider la DTD des métadonnées Matroska ;
    • MKVToolnix : produire le fichier Matroska final ;
    • Barrier : partager la souris entre plusieurs ordinateurs (contrôler le prompteur) ;
    • Entangle : capturer l’image de la caméra lors de la partie en direct ;
    • OBS : capturer la vidéo affichée par Entangle lors de la partie en direct ;
    • v4l2loopback : créer une webcam virtuelle ;
    • obs-v4l2sink : diffuser ce que produit OBS comme une webcam virtuelle afin que firefox puisse l’envoyer à Jitsi ;
    • Firefox : se connecter à Jitsi et diffuser la webcam virtuelle et le microphone pour la partie en direct ;
    • Jitsi : diffuser la partie en direct (hébergé par Debian) ;
    • Magic Lantern : désactiver certaines limitations de la caméra (la rendre apte à l’exercice) ;
    • MyPaint : produire le dessin en couverture (réalisé précédemment pour d’autres motifs) ;
    • PeerTube : diffuser la vidéo sur la plateforme Debian Social ;
    • LinuxFr.org : rédiger cette dépêche, publier la retranscription jointe et autres tâches de modération. =)

    Mais aussi GNU bash, make, sed, core utilities

    Et Git, parce Git c’est la vie !

    Les fichiers de la conférence et pour reproduire la vidéo sont hébergés sur GitLab.

    Ces fichiers sont prévus pour permettre de reproduire la vidéo (le Makefile est inclus), vous pouvez par exemple changer l’angle de la caméra, voire faire une vidéo multi-angle, ou bien traduire les diapositives et reproduire la vidéo avec celles-ci incrustées à la place de celles actuelles.

    Le Makefile est malheureusement rendu inutilement complexe afin de contourner des bugs de Kdenlive (incapacité à produire de l’Opus en mono par exemple, la vidéo et le son sont donc rendus séparément…).

    Le brouillon initial (en anglais) a été rédigé sur Wordpress (l’instance d’Unvanquished) pour permettre une relecture de la part de membres de la communauté Unvanquished (et éventuellement membre de la communauté LinuxFr.org comme freem), ce qui a par ailleurs permis de publier la transcription anglophone en même temps que démarrait la conférence. Le texte a été converti avec Pandoc pour le reste des opérations qui furent essentiellement faites dans l’éditeur Markdown ghostwriter.

    Pour les sous-titres, Thomas Vincent m’a dit :

    J’alterne entre Gnome Subtitles et Aegisub. Le premier est très pratique pour importer une transcription et synchroniser vite fait. Le deuxième est idéal pour synchroniser avec précision, mais ça prend beaucoup plus de temps.

    À noter que j’ai écrit deux petits logiciels libres (sous licence CC 0) pour l’occasion :

    • building-a-community-as-a-service/pdftopng : convertir un PDF en une série de diapositive en PNG, s’appuyant sur mais contournant certaines limitations d’ImageMagick Convert (différentes manière de numéroter, limitation du nombre de diapo exportable en fonction de leur taille de sortie…).
    • building-a-community-as-a-service/mkctxttoxml : fusionner plusieurs fichiers de chapitres Matroska « simples » au format Matroska XML complexe afin de fournir un chapitrage multi-langue.

    Pour ma part tout cela a été réalisé sous Ubuntu 20.04 (avec donc beaucoup de Debian dedans), et je remercie particulièrement Grammalecte pour m’accompagner dans toutes mes rédactions francophones un tant soi-peu travaillées. =)

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Au delà du fond, la forme : logiciels libres utilisés, etc.

      Posté par  (site web personnel) . Évalué à 4.

      Koâ, il n'y a pas Linux dans la liste ?! ;)

      Merci pour la dépêche, je suis en train de regarder la vidéo sous-titrée

      • [^] # Re: Au delà du fond, la forme : logiciels libres utilisés, etc.

        Posté par  (site web personnel) . Évalué à 7.

        Je ne peux pas tous lister, mais je ne suis pas certain qu’il existe une distribution Ubuntu (appelée comme telle) avec un autre noyau que Linux. =)
        J’ai cité make, sed et les core utilities parce que là, je m’en suis servi directement pour le makefile, pour écrire les scripts… :)

        D’ailleurs j’ai levé plein de bugs. Kdenlive ne sait pas exporter du Webm avec du Opus et il a du mal à sortir de l’audio en mono et il crash en rechargeant les images modifiées en arrière-plan (et j’ai rencontré bien d’autres bizarreries, notamment dans les formats). ImageMagick Convert n’extrait pas toutes les pages du PDF si la définition demandée est élevée. Le format de chapitrage Matroska décrit sur le site web officiel n’est pas à jour et je n’ai pas trouvé la dtd pour celui-ci. Le format Webm est sensé prendre en en charge le VTT mais même à coup de pédales (ahah) ça ne rentre pas (Alors j’ai fait un MKV avec du SRT finalement). Firefox permet de choisir sa webcam mais pas son micro… Et changer le micro par défaut dans le bureau ne change rien, il s’entête à écouter toujours le même (qui est forcément le mauvais). Tandis que Chromium utilise toujours la même webcam quelque soit celle sélectionnée (et c’est forcément la mauvaise). J’ai passé beaucoup de temps à comprendre pourquoi mon interlocuteur ne m’entendait pas pendant les tests. LibreOffice ne sait pas afficher les émojis avec le modificateur “féminin”. Et j’en passe. 😱

        ce commentaire est sous licence cc by 4 et précédentes

  • # plus facile en français

    Posté par  . Évalué à 6.

    Merci pour la traduction de la conf en français.

  • # Doom… sur Unity ?

    Posté par  (site web personnel) . Évalué à 7.

    Un des points clés de la conférence est la considération pour le code, sa valeur supposée en tant qu’actif et la place qu’on lui accorde. La valeur du code d’id Software est encensée, voir par exemple les commentaires de Fabien Sanglard sur certains aspects des jeux DOOM de [DOOM3](https://fabiensanglard.net/doom3/index.php, même si, il est vrai, la disponibilité des sources permet plus facilement l’étude et que je serai curieux de voir de telles études sur les codes des concurrents, ce qui n’est pas prêt d’arriver.

    Donc, le code d’id Software est encensé, sa valeur est jugée comme très élevée. Pourtant, c’est parce qu’il est déconsidéré qu’il a été libéré. Dans le sillage d’id Software, un vocabulaire est apparu, la distinction du code et des « assets ». Pour nous francophones pour qui ce mot est étranger, et pour nous libristes qui sommes sensibilisés à la valeur du code et sommes donc soumis à un biais qui pourrait nous amener à déconsidérer les données, on pourrait être tenté de considérer les « assets » comme des « données accessoires ». Au moment de la libération du code de Quake 3 il était de bon ton de considérer que le fait que les données n’étaient pas libérées était assez accessoire, dévalorisant donc la valeur des données.

    Pourtant le mot « assets » est explicite en anglais : cela signifie « les actifs ». Contrairement au code, les données étaient considérés par id Software comme les actifs de l’entreprise. C’est pour cela d’ailleurs qu’il faut toujours acheter Doom, Quake, Quake 3, Doom 3 etc. même si le code est libre.

    J’ai oublié de le mentionner dans la conférence, et de toute manière je n’aurai peut-être pas eu le temps de ne serait-ce que l’évoquer (j’ai dû supprimer 1600 mots pour tenir le créneau de 40 minutes), mais Karl Jobst m’a rappelé après coup dans une vidéo que la dernière fournée du Doom original à ce jour a été réalisée… sur le moteur Unity.

    C’est à dire,

    1. qu’ils ont utilisés une moteur tierce-partie alors qu’ils étaient connus pour être la société qui tirait les nouveaux moteurs vers le haut ;
    2. qu’ils agissent encore comme si toute contribution provenant de la communauté n’existe pas.

    On peut comparer avec ce qui est cité dans la conférence au sujet du dernier épisode de Quake en date : Quake Champions qui fusionne du code « id Tech » avec le moteur « Saber3D Engine » de Saber Interactive. Le fait que Tim Willits soit passé de id Software à Saber Interactive a pu aider dans le rapprochement, mais on remarque cette transition partielle qu’opère id Software a devenir client du code d’autres sociétés (les titres phares comme Doom 2016 et Doom Eternal sont toujours des purs produits internes).

    Aussi, cela pourrait vous intéresser de plonger dans quelques histoires de ports de Doom comme celui qui a été distribué avec des jeux plus tarifs, comme Doom3 pour Xbox ou encore Doom3 BFG edition. Je n’ai pas entendu dire qu’ils auraient fusionnés des contributions de la communauté mais j’en doute fortement puisqu’ils auraient eu à traiter avec la licence GPL couvrant du code écrit par d’autres personnes qu’eux. Donc malheureusement on peut s’attendre à ce que le plus simple pour eux aurait été de simplement forker encore une fois une vieille version de leur arborescence interne qui n’a jamais été touchée par la communauté. Encore une fois on y voit id Software vivant sa vie quand la communauté en vivait une autre.

    La valeur accordée aux données pourrait faire le sujet d’autres discussions, ainsi que la valeur accordée aux outils pour manipuler les données, gérer les projets de données artistiques, et ce que cela témoigne de la considération faites aux artistes. Les artistes subissant des outils et des formats qui ne s’intègre pas dans un flux de travail adapté, à mille lieux de la performance des outils de gestion de développeurs (même Blender, un cador du libre dans le domaine des outils de production de donnée, est complètement à la ramasse sur ce sujet).

    ce commentaire est sous licence cc by 4 et précédentes

  • # Bilan ?

    Posté par  . Évalué à 4.

    Bravo et merci pour cette dépêche !

    On voit bien la différence de fonctionnement entre la communauté et l'industrie. C'est comme la Bazar vs la Cathédrale, sauf que là la Cathédrale est construite uniquement pour être rentable, on la laisse à l'abandon une fois que la messe est dite (et que l'argent de la quête est collecté, évidemment).

    Comment qualifierais-tu le bilan des contributions d'id Software au libre ? D'un côté id a libéré du code mais il ne pouvait pas être réutilisé sans énormément de travail (même pour des clones, vu qu'on doit recréer toutes les données). Des forks ont été faits et ont eu beaucoup de succès mais chacun a dû être maintenu indépendamment dans une communauté qui a déjà peu de ressources. Beaucoup de gens ont été découragés et il y a eu beaucoup de projets morts-nés, mais d'un autre côté sans l'intervention d'un gros acteur comme id au moment des balbutiements de l'opensource, est-ce que le monde du jeu libre aurait autant de contributeurs aujourd'hui ?

    Comment tu verrais une uchronie dans laquelle id Software ne libère pas son code ? Est-ce que la communauté du libre développe ses moteurs dans son coin et arrive au même résultat ? Est-ce que ça prend plus de temps ? Est-ce que le code est de meilleure qualité ? Quand tu regardes les FPS pas basés sur un moteur issu de l'industrie (RedEclipse…), qu'est-ce que ça t'inspire ?

    Maintenant qu'id Software ne libère plus de jeux, et que la vieillesse des moteurs darkplaces/QFusion/ioquake3/Daemon se fait de plus en plus ressentir (incapacité à tirer convenablement parti du multicore, par exemple), quel est le plan / quels sont les pronostics ? Est-ce qu'il faut coder from scratch le nouvel idTech X ? Ou est-ce que tu crois que Godot pourra répondre à tous les besoins d'un Xonotic ou d'un Unvanquished ?

    *splash!*

    • [^] # Re: Bilan ?

      Posté par  (site web personnel) . Évalué à 4.

      On voit bien la différence de fonctionnement entre la communauté et l'industrie. C'est comme la Bazar vs la Cathédrale, sauf que là la Cathédrale est construite uniquement pour être rentable, on la laisse à l'abandon une fois que la messe est dite (et que l'argent de la quête est collecté, évidemment).

      Oui dans ce sens là. Parce que l’aspect qu’Eric Raymond semble oublier (mais ma lecture est très lointaine donc c’est peut-être moi qui oublie) c’est que la cathédrale médiévale n’est généralement pas finie par celui qui l’initie. Comme un arbre, elle met plusieurs générations à pousser, elle est pensée pour ceux qui viennent après, les plans changent en cours de route selon la géopolitique, les modes ou même l’état de l’art, certaines parties sont refaites. Et pendant tout ce temps, les gens vivent dans la cathédrale en chantier, avec les ouvriers, où se déroulent les cultes et les danses et la cathédrale médiévale est en réalité un véritable bazar. La cathédrale décrite par Eric Raymond est vraiment spécifique à notre époque, et ça dit quelque chose…

      Quand Notre-Dame de Paris a brûlé et qu’Emmanuel Macron est partie en mode « je la rebâtirai en trois jourscinq ans » je me suis dit « non, s’il-vous-plaît, faites-nous un vrai chantier centenaire avec des supers métiers », non pas un chantier moderne où tout est fermé pendant la construction, et mettez en valeur l’artisanat !

      Bref, je reviens au sujet du jeu vidéo… Oui ça correspond au modèle cathédrale tel que décrit par Eric Raymond, et c’est du jetable à usage unique, un peu comme certaines infrastructures de jeux olympiques (pour filer la métaphore des grand-messes contemporaines). Et comme c’est du jetable à usage unique, tu as genre les fermetures à clips que tu ne peux pas ouvrir de l’extérieur, non pas que ce soit pour t’en empêcher, mais que le fait de le réouvrir après fermeture n’était pas dans le cahier des charges et a été sacrifié sur l’autel (haha) de l’économie.

      Des forks ont été faits et ont eu beaucoup de succès mais chacun a dû être maintenu indépendamment dans une communauté qui a déjà peu de ressources. Beaucoup de gens ont été découragés et il y a eu beaucoup de projets morts-nés […]

      Voilà c’est ça, le premier problème est le manque de main d’œuvre et de temps, donc toutes les économies faites pour livrer un produit qui ne devait pas durer deviennent des montagnes, et le coût est plus cher après qu’avant. C’est comme si une cabane qui coûte 100 avec 3 poutres peut tenir 3 ans mais que la maison qui coûte 120 avec 4 poutres peut tenir 30 ans, mais qu’une fois que la cabane avec 3 poutres est livrée, et qu’il faut tenir plus de 3 ans, il faut re-dépenser 50 pour faire les modifications. Toutes ces petites économies coûtent beaucoup plus cher que ce qu’elles économisent à la base, mais pour les trois ans d’exploitation prévue ça fait le boulot (je ne dis pas que les jeux id Software étaient prévus pour trois ans, c’est une analogie).

      […] mais d'un autre côté sans l'intervention d'un gros acteur comme id au moment des balbutiements de l'opensource, est-ce que le monde du jeu libre aurait autant de contributeurs aujourd'hui ?

      Je ne sais pas. Il y aurait une un énorme vide de jeux libres à cette époque comparé à ce qu’on a eu, certainement.

      On pourrait dire qu’il y a bien eu des moteurs écrit from-scratch comme le moteur Cube, mais quand je vois que l’auteur de Cube a nommé son format de modèle IQM pour Inter Quake Model, je suppose que les jeux d’id Software ont eu une grosse influence, et probablement leur libération aussi, car le besoin d’un format commun entre Cube 2 et des forks libres de Quake requiert que des forks libres de Quake existe.

      Par contre un projet comme Godot aurait probablement existé même si id Software n’aurait rien libéré ni même jamais existé. Et donc au pire on aurait manqué plein de jeux et dérivés, mais probablement pas Godot ou un truc similaire, peut-être à un autre moment dans le temps. Rien ne dit d’ailleurs qu’un projet comme Godot ne serait pas apparu plus tôt.

      Il y a eu plein de projets « from scratch », s’ils n’y avait pas eu le rouleau compresseur des codes id Software, certains auraient forcément eu plus de chance.

      Donc l’uchronie est difficile à peindre, mais m’est avis que plus le temps passe, et moins l’impact d’id Software sera décisif sur notre présent. À un moment dans le temps un autre acteur aurait sorti des jeux de ce niveau, un autre acteur aurait sorti un moteur libre (peut-être communautaire dès le début), on a peut-être déjà passé le temps où le scénario le plus défavorable (où l’absence des actes d’id Software aurait provoqué un retard) serait rattrapé.

      Maintenant qu'id Software ne libère plus de jeux, et que la vieillesse des moteurs darkplaces/QFusion/ioquake3/Daemon se fait de plus en plus ressentir (incapacité à tirer convenablement parti du multicore, par exemple), quel est le plan / quels sont les pronostics ?

      Quake 3 a un héritage avec Quake, Doom avec Quake 3, et c’est probablement toujours vrai aujourd’hui. id Software n’a pas réécrit ses moteurs à partir de rien, parfois la réécriture remplaçait quasi tout au final, mais ça a toujours été itératif à ce que je sache, donc techniquement rien n’empêche la branche Dæmon ou la branche RBDOOM3-BFG d’évoluer vers ce que font les derniers moteurs d’id Software, qui sont tout à fait actuels.

      Est-ce qu'il faut coder from scratch le nouvel idTech X ?

      Donc je ne pense pas qu’il faille partir de rien. La nature des communautés open source, la nature humaine elle-même, et la nature du travail font qu’il est toujours plus raisonnable d’avancer de manière incrémentale.

      Tu peux lire “Things You Should Never Do, Part I” par Joel Spolsky sur le sujet de la réécriture depuis la feuille blanche. À part que j’ai une nuance à ajouter quand il dit qu’il est plus facile de lire du code que de l’écrire, je suis intimement convaincu que ceci vient des notre système d’éducation et autres pratiques de notre industrie. En tant que contributeur de logiciel libre mon expérience est toute contraire, parce que ma première approche est de contribuer à de l’existant et c’est le passage quasi obligé, avant de pouvoir écrire depuis une page blanche je ne modifie (écrit) que ce que j’ai préalablement lu.

      Ou est-ce que tu crois que Godot pourra répondre à tous les besoins d'un Xonotic ou d'un Unvanquished ?

      Je vais être honnête, je ne connais pas assez bien Godot. Mais je ne vois rien qui par principe puisse empêcher de faire évoluer Godot pour qu’il puisse répondre aux besoins d’un jeu comme Xonotic ou Unvanquished.

      La grosse différence c’est surtout que Godot est aussi une plate-forme de création. La plate-forme de création autour des moteurs id Tech est en très mauvaise état, avec des forks pires que les moteurs, j’ai donné un exemple pour un éditeur de niveau, mais c’est toute la chaîne de production qui est fragile.

      Dans la dépêche sur la libération des dernières données non-libres d’Unvanquished j’ai écrit :

      Tandis que certains outils de création peuvent être encore un peu frustres, il y a un écosystème complètement libre autour d’Unvanquished et d’autres jeux libres ouverts amis pour créer des niveaux, des modèles, des textures, des effets sonores, et pour les distribuer de manière adéquate avec des formats efficaces.

      Je me suis rendu-compte après, par l’expérience, que j’avais oublié une point qui n’est pas prêt. On a des contributeurs qui ont modelé et animé des modèles avec Blender, donc oui ça c’est bon. Il y a un greffon pour exporter du Blender vers du IQM et d’autres l’ont fait donc a priori c’est bon aussi (mais ça je n’ai pas encore fait moi-même). Il existe des outils pour visualiser des modèles IQM et parfois faire de petites retouches que j’ai pu faire moi-même donc ça c’est bon aussi. Par contre quand il a fallu transformer le modèle du nouveau “lasgun” en vue à la première personne pour être utilisable à la première personne… je n’ai pas réussi. Pour une raison que j’ignore encore le modèle qui a fonctionné à la troisième personne fut un modèle MD3 (le format historique de Quake 3) et c’est peut-être que notre moteur doive-t-être amélioré pour pouvoir utiliser proprement des MD3 à la première personne, mais voilà, il a fallu faire un MD3, un format utilisé par tous les projets dérivés de Quake3 depuis 1999 (on est en 2021, ça fait donc bientôt 22 ans qu’on manipule ce format), eh bien celui qui nous a transformé le modèle et fait les ajustements a utilisé 3DS Max qui a su gérer ce format selon nos besoins. Peut-être que Blender peut faire aussi bien ? Je ne sais pas, mais c’est la première fois depuis mes premières participations au projet (2013?) que je rencontre un cas d’usage spécifique qui a été résolu avec un logiciel propriétaire. C’est dire combien c’est rare, mais ça signifie qu’il existe encore dans les coins des zones d’ombres qui peuvent nous surprendre.

      Godot est aussi une plate-forme de production, donc une partie d’elle est sensée être au point avec les capacités du moteur lui-même. À un moment il faut bien importer des formats depuis Blender ou autre chose, et prendre en charge des formats intermédiaires (si possible standardisés. Mais du côté des logiciels id Tech, la plate-forme de production souffre autant sinon plus que le moteur de jeu. Un jeu sera considéré comme libre si le code et les données sont couvertes par une licence libre, même si le logiciel produisant les données n’est pas libre, ça peut peut-être expliquer pourquoi il y a encore moins d’attention, de soin et de collaboration (et de survie des outils) du côté des outils de productions.

      Comment tu verrais une uchronie dans laquelle id Software ne libère pas son code ? Est-ce que la communauté du libre développe ses moteurs dans son coin et arrive au même résultat ? Est-ce que ça prend plus de temps ? Est-ce que le code est de meilleure qualité ? Quand tu regardes les FPS pas basés sur un moteur issu de l'industrie (RedEclipse…), qu'est-ce que ça t'inspire ?

      Je ne sais pas si ça aurait pris plus de temps, le code aurait pu être pensé différemment (pour les générations suivantes) certainement, de meilleure qualité peut-être pas. Je ne connais pas le code du moteur de RedEclipse (généalogie Cube / Sauebraten) mais il me semble que freem a un avis assez mitigé (euphémisme) sur la qualité du code de RedEclipse/Blue Nebula.

      Je n’arrive pas à accrocher à ces jeux, mais c’est une affaire de goût. Je peux d’ailleurs expliquer le principal problème très peu rationnel qui m’a le plus inconsciemment détourné de Sauebraten : la faible combinaison de modèles et surtout de son (les mêmes pour tout les personnages) et le fait que ces sons m’insupportent m’ont toujours donné une impression de démo technique et m’ont toujours gâché le plaisir. Au final le code n’est pas en cause. J’imagine que la physique de chaque jeu a aussi un impact sur mes préférences, mais c’est encore une affaire de goût et ce n’est pas une question de qualité de code ni même de fonctionnalité. La démo jouable de Tesseract (toujours l’héritage Sauerbaten) ne m’a rebuté en rien, je jouerai sans problème à un jeu de ce genre.

      ce commentaire est sous licence cc by 4 et précédentes

  • # Quake 2 → Quake 3

    Posté par  (site web personnel) . Évalué à 4.

    J’ai remarqué une petite erreur de ma part dans la retranscription en français (cette erreur n’est ni dans le texte original ni dans l’enregistrement de la conférence) après « Les instantanés de code sont rétroactivement appelés id Tech 3. » :

    -id Software a ouvert l’instantané Quake 2,
    +id Software a ouvert l’instantané Quake 3,

    Mais le contexte ne laisse aucun doute. =)

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Quake 2 → Quake 3

      Posté par  . Évalué à 4.

      Corrigé, merci.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.