Tramway SDK – l’union impie des moteurs de Half-Life et de Morrowind

• Tramway SDK est un package graphique/framework/moteur de jeu développé depuis trois ans, qui vise à proposer un moteur léger à rebours des exigences matérielles élevées et du flux de travail à éditeur monolithique des moteurs grand public
• Estimant que les moteurs grand public comme Unity et Godot demandent un matériel excessif même pour de simples jeux low-poly, il cible aussi le matériel des 15 dernières années et jusqu’au rendu par rastérisation logicielle
• Son mode de création consiste à écrire du code par héritage de classes Entity, plutôt qu’à faire des allers-retours entre une GUI à nœuds et du code, et à n’utiliser que les éditeurs nécessaires
• La création de niveaux s’appuie sur un workflow de brushes à la Quake, avec un convertisseur .map, des lightmaps, l’ombrage de Gouraud et un système d’entrées/sorties à la Source
• Il vise le streaming d’open world et un framework RPG proche d’un RPG Maker 3D, mais reste encore à un stade de développement précoce : API instable et éléments non implémentés sont à prévoir

---

Le problème visé par Tramway SDK

• Tramway SDK est à la fois un package graphique, un framework et un moteur de jeu, et utilise aussi la graphie façon heavy metal « T̈ra̦m̊ẅa̦ÿ SD̈K »
• Sa critique des moteurs grand public se concentre sur le Turbobloat
  • Unity est considéré comme nécessitant un matériel très puissant et beaucoup d’énergie
  • Godot est jugé un peu meilleur qu’Unity, mais nécessitant encore un matériel relativement performant
  • Sa position est que des jeux comme des simulateurs de deckbuilder roguelite d’horreur low-poly devraient pouvoir tourner sans problème sur du matériel vieux de 15 ans
• Tramway SDK met en avant l’absence de Turbobloat, ce qui lui permettrait de tourner sur presque tout matériel des 15 dernières années
  • Il peut basculer vers la rastérisation logicielle pour fonctionner même sans carte graphique
  • Il va jusqu’à citer l’exemple d’afficher des graphismes sur des appareils comme un grille-pain ou un réfrigérateur
• À l’argument « il suffit d’acheter un meilleur ordinateur », il répond par trois raisons
  • Un problème d’accessibilité financière, car beaucoup de personnes n’ont pas les moyens d’acheter du matériel puissant
  • Un problème de déchets électroniques, car la production de puces informatiques est mauvaise pour l’environnement et, si le logiciel n’était pas boursouflé, on n’aurait besoin d’acheter du nouveau matériel que lorsque l’ancien est en panne et irréparable
  • L’idée que, si l’on possède déjà un ordinateur qui fonctionne bien, il n’y a aucune raison d’en acheter un nouveau à cause du Turbobloat de quelqu’un d’autre

Mode de création et fonctionnalités

• Les méthodes de création basées sur des nœuds sont critiquées parce qu’elles obligent à gérer « plusieurs choses qui semblent n’en faire qu’une » et à passer sans cesse d’une GUI à nœuds au code
• Dans Tramway SDK, il suffit d’écrire du code en héritant de la classe Entity, puis de créer les niveaux avec l’éditeur de niveaux
  • La structure est centrée sur les entités, sans utiliser de nœuds
  • Elle évite le flux de travail qui alterne entre code et GUI à nœuds
• L’éditeur monolithique des moteurs grand public est également vu comme un problème
  • Il faudrait attendre le chargement de l’éditeur complet, y compris de fonctions qui ne sont pas utilisées
  • Les éditeurs de Tramway SDK sont tous optionnels
  • Pour l’utiliser uniquement comme framework, il est possible de n’utiliser que le runtime C++
  • Si seule la création de niveaux est nécessaire, on peut n’utiliser que l’éditeur de niveaux
  • Les fichiers de données étant dans un format de valeurs séparées par des espaces, ils peuvent aussi être modifiés à la main sans éditeur
• Côté graphismes, les lightmaps et l’ombrage de Gouraud suffisent à produire les images d’exemple
  • Cet exemple peut être rendu même sur le pipeline à fonctions fixes d’une carte graphique de niveau Direct3D 7
• La création de niveaux prend en charge un workflow à base de brushes de la famille Quake
  • Tramway SDK fournit un convertisseur de fichiers .map qui transforme les brushes en maillages triangulés
  • Le flux présenté consiste à créer un niveau dans Trenchbroom puis à le configurer dans l’éditeur de niveaux de Tramway SDK
  • Le moteur rend les niveaux avec lightmaps appliquées
  • Un système d’entrées/sorties similaire à celui de Source permet de configurer les interactions entre entités dans le niveau
  • Il est prévu d’implémenter à terme l’ensemble des logic entities de Source afin de permettre du scripting visuel dans l’éditeur de niveaux
• Côté RPG, il voit comme exemples intéressants les outils comme RPG Maker et le fait que beaucoup de choses peuvent être créées par simple modification de données dans les mods et total conversions basés sur Morrowind
  • Tramway SDK dispose d’une extension de framework RPG proche d’un RPG Maker pour la 3D
  • Le moteur étant conçu dès le départ pour prendre en charge le streaming de niveaux, il devrait permettre de créer rapidement et facilement des jeux de type RPG en open world
• En résumé, Tramway SDK est un moteur de jeu à base d’entités dans le style Quake/Source, avec des extensions optionnelles comme le streaming d’open world et un framework RPG
• L’état de développement est encore très précoce
  • L’API est instable
  • Des fonctionnalités peuvent être cassées ou ne pas fonctionner
  • De nombreux éléments ne sont pas encore implémentés
  • Le projet indique progresser rapidement
• Dépôt GitHub : racenis/tram-sdk

[GN⁺]

Avis sur Hacker News

• Certains diront « achetez simplement un meilleur ordinateur », mais je suis entièrement d’accord avec l’idée qu’acheter un meilleur ordinateur est une mauvaise chose. Beaucoup de gens, surtout dans les pays en développement, n’ont pas les moyens d’acheter le matériel nécessaire pour faire tourner Turbobloat, et la production de puces a un impact négatif sur l’environnement.
  Si les logiciels modernes n’étaient pas aussi obèses, on ne rachèterait du matériel que lorsque l’existant tombe en panne et n’est plus réparable. Quand on a un ordinateur qui fonctionne parfaitement, il n’y a aucune raison d’en acheter un nouveau à cause des logiciels boursouflés de quelqu’un d’autre, et avec cet argent on pourrait s’acheter 1 000 canettes de Dr. Pepper. C’est vraiment un bon projet, j’espère qu’ils continueront à publier des nouvelles de son avancement.

  • Il est question de « résolutions d’écran de 320x200 à 800x600 », mais les résolutions plus élevées n’ont pas été inventées uniquement à cause de Turbobloat.
  • Cela dit, le moteur semble quand même exiger un GPU OpenGL 4, alors que le niveau graphique paraît accessible même à une carte Voodoo.
  • Je ne sais pas ce qu’est Turbobloat. D’après le contexte, ça se lit comme « les technologies graphiques que je n’aime pas », mais je ne vois pas clairement où commence et où s’arrête Turbobloat.
  • Fabriquer et livrer un nouvel ordinateur peut aussi valoir le coup à long terme. Les gains de performances et d’efficacité énergétique peuvent, avec le temps, compenser l’impact environnemental.
    Bien sûr, pour un usage de loisir, c’est plus difficile à trancher, et une vieille Game Boy peut être plus amusante qu’un PC gaming moderne de 1 000 W.

• La phrase « Un doit être un. Pas plusieurs qui prétendent être un. Avec les nœuds, il faut faire passer des collections de plusieurs choses pour une seule » sonne vraiment comme du Terry Pratchett, et elle est excellente.
  J’aime l’imaginer comme une phrase que Sam Vimes pourrait se dire en pleine enquête compliquée, et j’espère que le projet continuera à progresser. Je ne l’ai pas encore essayé moi-même, mais j’ai des idées pour l’utiliser dans mon projet d’IA.

  • Prise isolément, cette phrase me semble au contraire manifestement fausse. Nous considérons constamment des ensembles de choses comme une seule chose.
    Un humain est un ensemble de parties du corps, les parties du corps sont des ensembles de substances chimiques, les substances chimiques sont des ensembles de molécules, les molécules sont des ensembles d’atomes, et pourtant, à chaque niveau, nous les considérons comme une unité. Dire qu’on ne devrait pas pouvoir le faire n’a pas de sens. Le projet a quand même l’air chouette.
  • J’imagine bien Sam Vimes dire ça, puis, à cause de Sybil, traverser une douloureuse phase de croissance personnelle et finir par admettre à contrecœur que « parfois, un doit peut-être être plus qu’un simple un ».
    Et le système entité-composant de Vetinari a beau sembler compliqué, il fonctionne correctement et fait tourner cette fichue ville.
  • Cette formule semble viser les gens qui ont essayé d’autres solutions et les ont détestées, mais, du point de vue de quelqu’un qui n’a jamais utilisé de moteur de jeu, ce serait bien d’expliquer simplement en quoi les nœuds reviennent à « faire passer des collections de plusieurs choses pour une seule ».
    J’imagine que l’expérience utilisateur d’un éditeur de nœuds encourage à attribuer des propriétés et des relations à des choses comme des Vector de Finger, mais qu’au final un Vector n’est qu’une « collection de choses » et non un « type » doté de son propre comportement, ce qui rend difficile d’y attacher du code.
    Je me demande si « tout est une Entity, écrivez simplement du code » signifie qu’il faudrait plutôt créer une classe Hand contenant des Fingers, avec son propre état et son propre comportement, plutôt qu’un Vector. Ou si cela veut dire qu’au lieu de créer une instance de nœud qui regroupe à l’avance certaines valeurs statiques et certains membres de relation, il faut hériter à nouveau d’une sous-classe d’Entity pour la spécialiser davantage.
  • Le paragraphe juste après est intéressant : « Quand on construit quelque chose avec des nœuds, il faut sans cesse faire l’aller-retour entre l’interface graphique des nœuds et le code ».
    La combinaison Node/GDScript de Godot peut être vue comme une sorte de réponse à cet argument. Avec des choses comme l’opérateur $ et l’autocomplétion, elle tente de rendre cet « aller-retour » aussi fluide et intégré que possible. Mais au bout du compte, il faut bien sortir le jeu, donc je pense que la façon de penser « un est un » finit par l’emporter.
  • Malheureusement, tout est une collection de choses qui prétend être une seule chose, même les choses supposément unitaires. Le mieux que nous puissions faire, c’est faire semblant, ou éviter de nous faire prendre.

• Plus le temps passe, plus j’ai l’impression qu’il existe une force extérieure qui fait baisser la qualité des moteurs de jeu. Ce qui se répand largement dans la tech, ce sont généralement les choses pour lesquelles il est facile de créer un programme de cours.
  Les éditeurs à base de nœuds comme Unity ont une structure parfaite pour être expliqués sur plusieurs cours. À l’inverse, un moteur comme raylib se comprend en un après-midi, si bien qu’il est difficile d’imaginer un cours universitaire de niveau supérieur consacré à raylib. Résultat : des écoles façon bootcamp produisent des développeurs amateurs qui ne connaissent que Unity/Unreal, les entreprises recrutent des profils Unity/Unreal, et les universités se remettent à l’enseigner. C’est un peu comme la popularité de Java.
  En plus, comme chaque entreprise a des besoins différents pour ses projets Unity, Unity, en tant qu’entreprise commerciale qui s’adresse à des clients plutôt qu’à un seul programmeur mécontent, doit sans cesse adapter son moteur, ce qui finit par donner du Turbobloat. Les moteurs de Half-Life et de Morrowind sont nés d’une situation particulière où des programmeurs passionnés étaient payés pour développer ce qu’ils trouvaient génial ; on a donc obtenu des moteurs minimaux adaptés à des développeurs de jeux professionnels, avec une excellente technologie.
  Ce projet semble se situer quelque part entre raylib et Unity. Je crains qu’il ne soit pas assez attirant pour les programmeurs amateurs, tout en en faisant peut-être trop pour les programmeurs qui veulent un petit moteur. J’espère me tromper, et les performances comme le niveau de finition ont l’air bons. Il y a clairement des développeurs lassés de Unity, et avec le cycle de nostalgie qui arrive aux années 2000, il existe aussi une vraie demande pour jouer à des jeux moins complexes graphiquement que Half-Life 2, et pour en créer. Le design du site et le ton de la documentation sont également réussis.

  • Il est aussi important que le jeu et le moteur soient créés ensemble, car ils peuvent s’adapter l’un à l’autre. Dans Doom, on ne pouvait pas placer un sol au-dessus d’un autre sol : c’était une limite du moteur due aux contraintes CPU, et les level designers ont inventé des astuces pour donner cette impression.
    Quand on conçoit les deux ensemble, on peut exploiter activement les fonctionnalités ajoutées, éviter celles qui fonctionnent mal, ou même adapter le style artistique au moteur. Les mobs anguleux et pixellisés de Minecraft s’accordent bien avec son moteur, mais si l’on commence à les rendre plus détaillés, on tombe dans une vallée dérangeante où ils paraissent plus datés et maladroits que Minecraft, jusqu’à ce qu’ils puissent être rendus correctement avec suffisamment de polygones.
  • Je me souviens d’une interview de quelqu’un qui avait travaillé sur Bioshock, probablement le lead designer, disant en substance : « Dans l’entreprise, pour expérimenter une nouvelle idée, il faut monter une équipe et passer au moins un mois avant d’avoir quelque chose de manipulable. Alors qu’à la maison, je peux créer une campagne Doom entière en une soirée. »
  • J’aime le développement de jeux basé sur des bibliothèques comme raylib ou libgdx, mais il y a une raison pour laquelle un jeu comme Slay the Spire est passé par Unity puis Godot pour sa suite.
    Je ne pense pas que les gens utilisent Unity parce qu’ils auraient été mal formés par des professeurs qui aiment la complexité.
  • Les vieux jeux étaient vraiment nets ; les jeux d’aujourd’hui tournent n’importe comment, plantent, demandent 150 Go de téléchargement et mettent 150 ans à se lancer. Si nous jouions pour les graphismes, l’un des MMO les plus populaires ne serait pas basé sur un jeu navigateur de 2002, et nous ne jouerions même pas à des jeux : nous jouerions à la réalité.
    Il suffit de voir ce qu’Epic Games a fait à Fortnite. Ils ont tué un jeu centré sur une scène compétitive qui tournait fluidement, à cause des graphismes Turbobloat et des skins.
  • Le phénomène « des programmeurs qui ne connaissent que Unity/Unreal arrivent sur le marché, les entreprises recrutent des profils Unity/Unreal, puis les universités l’enseignent à nouveau » se retrouve aussi de manière similaire avec ArcGIS.

• Je suis entièrement d’accord avec le problème de l’hyper-boursouflure. Les machines d’aujourd’hui sont bien plus puissantes, et pourtant la plupart des programmes semblent au contraire plus lents qu’avant.
  Le projet est aussi très chouette, et le design du site mérite un A+.

  • Dire que « la plupart des programmes sont plus lents qu’avant » ne me semble vrai que pour les gens qui ont eu la chance, à une certaine époque, d’utiliser du matériel un peu surdimensionné.
    De mon point de vue d’utilisateur de matériel ordinaire à l’époque de Windows 98/2000/XP, faire tourner Windows 10/11/KDE/Gnome, etc., sur un portable moderne bon marché équipé d’un SSD est beaucoup plus réactif, même avec des webapps réputées boursouflées comme vscode ou Slack.
  • Je ne comprends pas le terme Turbobloat. J’ai déjà créé des jeux, mais je ne l’ai jamais entendu ; l’auteur ne le définit pas, et une recherche sur Kagi ne renvoie que l’article soumis, tandis que Google ne donne aucun résultat pertinent.
    Je me demande si cela veut simplement dire « très boursouflé ». En lisant davantage le site, on voit aussi des expressions comme « simulation physique hyperréaliste », donc j’ai l’impression qu’au final cela veut dire « très boursouflé ».

• L’idée selon laquelle « la plupart des jeux Unity ont très mauvaise allure, même avec des shaders tape-à-l’œil, du normal mapping et d’autres techniques » semble devenir de plus en plus courante dans certaines générations.
  Il est certain qu’un certain type de technique de texture mapping a disparu. Les décors d’Ikaruga sont meilleurs qu’ils n’auraient besoin de l’être, en particulier l’effet de forêt tout simple du début. Certains simulateurs de train de l’époque PS2 y arrivaient aussi.
  Cela dit, si une source lumineuse directionnelle aussi forte que le soleil éclaire un objet brillant et que le joueur se déplace, cette approche s’effondre. Dans un environnement nuageux, sans aucun objet dynamique, on peut contourner pas mal de combines modernes.

  • Exact. Le problème, c’est que certains jeux modernes sont nuageux et n’ont même pas d’éclairage dynamique, mais utilisent quand même Lumen. C’était le cas du remake de Silent Hill : il tourne très lentement, paraît encore pire sur PS5 Pro, et même l’herbe a l’air moins réussie que dans des jeux plus anciens.
    À l’origine, le cadre de Silent Hill avait été conçu pour justifier des astuces d’optimisation. Afin de faciliter la gestion des objets à l’écran, on avait instauré un « espace de brouillard » permanent, alors que le remake gaspille une quantité énorme de traitement pour produire un brouillard réaliste au lieu d’un brouillard d’apparence surnaturelle.
  • Les beaux jeux faits avec Unity ne ressemblent pas à des « jeux Unity », donc les gens ne les prennent pas comme exemples de ce à quoi ressemble un jeu Unity. Résultat, l’archétype du jeu Unity reste « assez brut ».
    Les compétences artistiques nécessaires pour produire quelque chose de beau n’ont absolument pas disparu ; elles sont simplement réparties de façon très inégale. Une équipe avec de bons modeleurs, texture artists, animateurs et compétences en programmation visuelle peut obtenir un résultat superbe avec Unreal, Unity ou un moteur maison.
  • Il existe cette idée tenace selon laquelle les matériaux à eux seuls peuvent compenser un texturing et un normal mapping insuffisants. C’est faux, et c’est le résultat de slogans marketing de choses comme Unreal Engine mal compris ou déformés.
    Dans Super Mario Sunshine, les ombres « nettes » que la GameCube ne pouvait pas rendre étaient en réalité des meshes plats. À Delfino Plaza, près de la Shine Gate, l’ombre sous l’auvent n’est pas une texture, mais un mesh. En revanche, si la place carrelée sur laquelle cette ombre est posée rend bien, ce n’est pas grâce à une énorme texture unique, mais parce que des dizaines de textures 128x128px ont été correctement mappées en UV.
    Dans un jeu moderne, on utiliserait deux textures de briques et un motif de bruit pour les mélanger, toutes trois en 2048x2048px, et les ombres auraient des bords nets grâce au ray tracing. Ironiquement, alors que la VRAM et la vitesse des bus ont augmenté, nous avons choisi des textures plus grandes plutôt que davantage de textures. Même chose pour le normal mapping : au lieu de l’utiliser avec des modèles plus subdivisés, on s’imagine que les normal maps sont dépassées et que modéliser réellement chaque détail est la voie techniquement la plus avancée. Une sphère moins anguleuse, très bien ; mais modéliser réellement chaque fissure et éraflure d’une sphère est idiot et gaspille du calcul.
  • Avec quelque chose comme Unity, on peut assez vite fabriquer quelque chose qui fonctionne, mais pour que ce soit vraiment beau, il faut des compétences et du polissage supplémentaires.
    Même un jeu « 2D » comme Factorio présente une énorme différence de polissage entre sa première sortie, la version 1.0 et la version actuelle. Cette différence est aussi évidente dans les jeux moddés : les assets de mods sont en général « utilisables », mais ils ne paraissent pas aussi soignés que ceux du jeu de base.

• J’ai récemment relancé Half-Life 2, et j’ai été surpris de voir à quel point il reste magnifique aujourd’hui, même sans pack de textures haute résolution.

  • À mon avis, c’est parce que le jeu a choisi son style artistique avec une intelligence extrême. Il y a beaucoup de surfaces à réflexion diffuse sur lesquelles l’éclairage précalculé fonctionne très bien, et les ciels couverts permettent une lumière ambiante diffuse plutôt qu’un éclairage directionnel qui imposerait un shading dépendant de l’angle et des contours d’ombres nets et très contrastés.
    Même les surfaces brillantes ne sont généralement pas trop lustrées, ce qui aide aussi. Ces choix conviennent très bien à un monde vieilli, occupé et dystopique à l’extrême, ce qui le rend crédible, tandis que les textures aux couleurs sobres unifient l’ensemble.
  • C’est pour cela que je pense qu’une très bonne direction artistique l’emporte toujours sur la puissance graphique pure. Source était déjà impressionnant à l’époque, mais ce qui a tenu dans le temps, c’est le soin apporté à la conception des environnements et des modèles.
    Valve a concentré ses ressources sur l’ajout de détails et l’exploitation maximale des contraintes techniques, et vingt ans plus tard le résultat reste cohérent et bien conçu.
  • Half-Life 2 a reçu plusieurs mises à jour de shading et de niveau de détail depuis sa sortie, donc il paraît un peu meilleur qu’au lancement. Mais même à sa sortie, c’était déjà un jeu visuellement impressionnant.
  • J’ai rejoué à Half-Life 2 il y a moins d’une semaine, et je me suis dit que « même si les niveaux ne sont pas aussi remplis de détails que ceux des jeux modernes, la direction artistique des graphismes et du level design est meilleure que celle de beaucoup de designers modernes disposant de budgets bien plus importants ».
  • Black Mesa, le remake de HL1 dans le moteur de HL2, vaut aussi le coup. J’y ai joué pendant la pandémie et je ne l’ai pas regretté.

• En tant que membre d’une petite équipe qui crée un jeu low poly avec Godot, je trouve ça génial.
  Les phrases « quand on construit quelque chose avec des nœuds, il faut sans cesse passer de l’interface graphique des nœuds au code » et « les moteurs grand public ont un énorme éditeur de jeu monolithique, et quelle que soit la fonctionnalité utilisée, il faut attendre 10 minutes que tout soit chargé » me parlent énormément. Même dans Godot, alors que nous utilisons très peu de fonctionnalités sophistiquées, la boucle de debug m’a semblé beaucoup plus lente que lorsque je programme dans d’autres environnements.
  J’aime aussi l’idée de plusieurs éditeurs fonctionnant ensemble autour d’une spécification unique de fichier de données. Les IDE intégrés facilitent les conflits de merge entre plusieurs développeurs ; des éditeurs plus spécialisés pourraient aussi aider les développeurs de chaque rôle à limiter l’ampleur et la nature de leurs changements. J’ai hâte de voir comment le moteur évoluera.

  • Le mois dernier, pendant un hackathon, j’étais assez fier d’avoir trouvé comment faire du développement piloté par les tests de modules C# sans lancer Unity.
    Même avec un netbook peu performant, j’ai pu contribuer à ma part. Je n’avais jamais écrit une seule ligne de C#, mais je n’avais pas l’intention d’abandonner le TDD en ligne de commande. J’ai découvert que c’était possible et j’ai fini par le faire fonctionner. Tout le monde pensait que j’étais fou, et les responsables relations développeurs du sponsor n’ont été d’aucune aide.
    La plus grande friction de ce week-end-là restait que la meilleure machine devait perdre une éternité à lancer et relancer ce fichu IDE Unity. Les chaînes que les gens acceptent de supporter sont stupéfiantes.

• Le texte emploie « Turbobloat » et dit que les moteurs sont « bloatés » ; dans une certaine mesure, c’est juste. Mais il vaudrait la peine d’expliquer ce que cela signifie pour l’auteur, quelles fonctionnalités sont considérées comme de la bloat et ce qui a été retiré du projet Tramway.
  Par exemple, pour certaines personnes, l’inclusion d’un framework RPG pourrait déjà passer pour de la bloat, or Tramway en contient un.

  • C’est pour cela que je l’ai mis sous forme de fonctionnalité d’extension optionnelle. Il fait partie du projet de moteur plus large, mais il reste entièrement optionnel.
    J’aime le principe du C++ selon lequel « on ne paie que pour ce qu’on utilise ».

• Il est présenté comme « comment utiliser le framework pour les débutants qui ont peur du C++ ou qui sont simplement nuls » ; je suis plutôt dans le second cas, et j’ai été reconnaissant pour la page Getting Started.
  Une théière est apparue, et j’ai compris des choses que je pensais ne jamais comprendre. Je n’ai que 30 minutes de pause déjeuner pour l’instant, donc pas le temps de finir le tutoriel, mais le fait que j’aie envie de continuer montre bien à quel point cette documentation est amusante et accessible.

• Quelqu’un a trouvé la page Design Patterns ? C’est un tableau de score avec un objectif à 100 %, et j’adore.

  • Elle est liée depuis la page d’accueil : « 82 % des design patterns utilisés. Quand tous les patterns auront été utilisés, le projet sera supprimé et réécrit en Rust. Sans orienté objet. »
  • J’ai cherché un bon moment, mais je ne l’ai toujours pas trouvée.