8 825 joueurs qui se canardent au même endroit, sur un seul serveur, pendant 14 heures. C'était en 2020 dans le système FWST-8 d'EVE Online, et le moteur qui a encaissé ça s'appelle Carbon. Et si je vous cause de ça c'est parce que Fenris Creations (le studio du jeu, ex-CCP Games) vient de le poser sur GitHub , en licence MIT, gratuit !

Au fil des mois, ils ont ainsi mis en ligne 33 dépôts à cloner, dont 30 sous licence MIT. Vous y trouvez Trinity, le moteur de rendu, Destiny , qui simule la physique et calcule les trajectoires de vos vaisseaux, et même une bibliothèque C++ dédiée au calcul d'itinéraire sur la carte du jeu. Du code qui tourne en production depuis 20 ans.

Et ça se monte tout seul puisque le README de Trinity dit simplement ceci : "*Compilez en utilisant le fichier CMakeLists.txt fourni à la racine du dépôt. *".

Un moteur de rendu avec 20 ans de production dans les pattes et pas une seule dépendance planquée, c'est fou.

Par contre, Destiny, lui, c'est le meuble en kit livré sans le sachet de vis. Son README prévient : "Pour compiler la bibliothèque, vous devez avoir accès à Perforce, car c'est là que se trouvent certaines de nos dépendances."

Pour vous la faire courte, chez vous, ça ne compilera pas, donc.

Car le 8 juillet, un développeur a ouvert l'issue #5 pour demander gentiment la liste des dépendances liées à Perforce et jusqu'à aujourd'hui, c'est resté sans réponse. Donc non, vous ne monterez pas votre serveur EVE privé ce week-end car l'économie du jeu et l'infrastructure serveur ne sont pas dans les cartons.

Alors pourquoi maintenant ??? Eh bien en mai, le studio a repris son indépendance en se rachetant 120 millions de dollars à Pearl Abyss, et il prépare EVE Frontier, un MMO de survie spatiale qu'il annonce "personnalisable, adapté au joueur". Donc "ouvrir la maison", ça prépare le terrain...

En tout cas, je trouve que ça nous change des jeux qu'on libère une fois morts, comme Arma Cold War Assault, dont Bohemia a ouvert le code pour ses 25 ans . Et vu ce que les moddeurs sortent sans même avoir le code ( un type a collé un mode multijoueur dans le Witcher 3 , j'vous rappelle ^^), avec les sources sous la main ça va être drôle.

Merci Emmanuel pour le lien !

Source

Il y a 25 ans, le studio tchèque Bohemia Interactive sortait Operation Flashpoint : Cold War Crisis, un shooter tactique qui a marqué toute une génération de joueurs PC.

Eh bien, pour l'anniversaire du jeu, ils n'ont pas fait les choses à moitié puisqu'un remaster est en route, une démo gratuite est dispo sur Steam , et surtout, ils ouvrent le code source du moteur. Tout ça d'un coup et c'est trop cool !

Le dépôt est public sur GitHub , sous le nom BohemiaInteractive/CWR et dedans, vous trouverez le moteur ET le code du jeu, le tout modernisé en C++20, compilé avec CMake et Clang, et compatible Windows x64 comme Linux x64. La démo Steam, elle, vous pose directement dans la sandbox open-world d'origine, avec les véhicules, l'IA et le système de missions. Enfin, un asset-pack est fourni pour que vous bricoliez vos propres mods.

Tiens, alors ça c’est rigolo ! Le projet deb-books vient de mettre en lumière une pratique assez fascinante, à savoir l’utilisation d’œuvres littéraires complètes comme données de test dans des dépôts Debian.

En général, quand je pense “dépôt Debian”, j’imagine des lignes de code impénétrables et des commentaires cryptiques et chelous qui feraient chialer un intégrateur HTML, mais certainement pas les œuvres complètes de William Shakespeare ou les aventures d’Alice au pays des merveilles.

Ça y est les amis, le moment que tous les fans de Descent attendaient est enfin arrivé ! Le code source de Descent 3, ce monument du jeu de tir à la première personne sorti en 1999, vient d’être rendu public sur GitHub. C’est Noël avant l’heure !

Alors, pour ceux qui ne connaîtraient pas encore ce chef-d’œuvre (honte à vous !), Descent 3 vous met aux commandes d’un vaisseau spatial dans des environnements entièrement en 3D, avec la possibilité de vous déplacer dans toutes les directions. On est loin des couloirs labyrinthiques des premiers Doom, là on parle de vraie liberté de mouvement, ce qui était du jamais vu à l’époque ! Ajoutez à ça des graphismes époustouflants (pour l’époque, encore une fois), une bande-son qui déchire composée par Christopher Larkin, et un mode multijoueur jusqu’à 4 joueurs addictif, et vous obtenez un classique intemporel.

Mais revenons à nos moutons (de l’espace). Jusqu’à présent, on n’avait accès qu’à des bribes de code, savamment distillées par les développeurs d’Interplay Entertainment. Mais là, c’est le jackpot : on a droit à la totale, le code complet ! Bon, quelques bouts de code propriétaires pour le son et la vidéo ont été retirés, mais rien de dramatique. Les anciens de chez Interplay bossent déjà pour rendre tout ça fonctionnel sans ces morceaux manquants.

Cette publication du code va permettre de pérenniser ce monument du jeu vidéo, comme ça, plus de risque qu’il tombe dans l’oubli et devienne injouable sur nos machines modernes. Et pour peu qu’une communauté motivée s’empare du truc, on peut s’attendre à des mises à jour, des corrections de bugs, et pourquoi pas des améliorations ! Imaginez un peu : de nouvelles armes, des vaisseaux inédits, des niveaux supplémentaires… Les possibilités sont infinies !

Mais le plus excitant, c’est surtout pour tous les moddeurs et développeurs en herbe qui vont pouvoir disséquer le moteur 3D maison Build engine, comprendre comment tout fonctionne sous le capot, et même s’en inspirer pour créer de nouveaux jeux ! C’est une mine d’or d’enseignements pour tous ceux qui veulent se lancer dans le développement de jeux vidéo.

Ce n’est que le début et les développeurs ont promis de nettoyer et commenter le code (parce que bon, on ne va pas se mentir, le code écrit il y a 20 ans, ce n’est pas toujours un modèle de clarté). On peut même espérer un petit système d’intégration continue pour faciliter les contributions de la communauté. Et qui sait, peut-être que dans quelques mois on aura droit à un Descent 4 entièrement conçu par les fans ! Oui, j’aime bien rêver…

En attendant, je vous invite à faire un petit tour sur le dépôt GitHub de Descent 3.

Sur ce, je vous laisse, j’ai un vaisseau spatial à réparer moi !

Il y a longtemps, à l’époque héroïque des jeux d’aventure Sierra, au milieu des années 80, un jeu venait juste de sortir : Space Quest II. Des milliers de joueurs s’empressent alors de se le procurer (en disquettes) pour partir dans de nouvelles aventures spatiales déjantées. Jusque là, rien d’anormal.

Sauf que… en réalité ces disquettes de Space Quest II (SQ2 pour les intimes) cachaient un secret incroyable que personne n’a décelé jusqu’à aujourd’hui ! En effet, sur la plupart des disquettes du jeu (versions 2.0D et 2.0F), les dev de Sierra avaient accidentellement laissé traîner près de 70% du code source original de leur moteur de jeu AGI (Adventure Game Interpreter) !

Car oui, sur ces disquettes qui tournaient sur tous les PC de la planète, il y avait non seulement le jeu mais aussi la majeure partie du code source normalement tenu secret qui faisait tourner tous leurs jeux depuis le premier King’s Quest !

Mais comment un truc pareil a pu arriver ?

Eh bien tout simplement à cause d’une petite erreur de manipulation lors de la préparation des disquettes master pour la duplication. À l’époque, le processus de fabrication des disquettes impliquait de copier l’intégralité des secteurs de la disquette master, y compris l’espace libre. Sauf que, manque de bol, les disquettes master utilisées pour SQ2 contenaient auparavant le code source AGI. Les fichiers avaient bien été effacés, mais les données étaient toujours présentes dans les secteurs non utilisés. Et avec la duplication, hop, le code source s’est retrouvé à l’insu de Sierra sur les disquettes de dizaines de milliers de joueurs !

Une simple commande DIR sur les répertoires de la disquette ne révélait rien d’anormal. Les fichiers principaux du jeu, comme PICDIR, LOGDIR, VIEWDIR, SNDDIR, VOL.0 et VOL.1, étaient bien daté de mars 1988. Cependant, l’espace libre sur la disquette 1 de la version 2.0D contenait des fragments de code source, issus des fichiers effacés mais non complètement supprimés et découvert simplement avec l’aide d’un éditeur hexadécimal.

En furetant dans les recoins des disquettes, Lance Ewing a pu retrouver 93 fichiers source éparpillés dans les secteurs oubliés ! La majeure partie de ces fichiers sont écrits en langage C, le reste est composé d’un peu d’assembleur et de scripts batch DOS. Une véritable caverne d’Ali Baba pour les passionnés de code rétro.

Le plus fou dans cette affaire, c’est que certains de ces fichiers C contenaient même des commentaires et un historique de modifications ultra détaillés ! On peut donc y voir apparaître les noms des développeurs, les dates, les descriptions de chaque changement…etc. C’est un véritable trésor archéologique pour comprendre comment ces pionniers du jeu d’aventure bossaient à l’époque.

On apprend ainsi que le code AGI a été principalement développé par Jeff Stephenson et Chris Iden entre 1985 et 1987, avec les dernières modifs début 88. On y voit leur labeur acharné pour peaufiner sans cesse le code, optimiser, débugger, ajouter de nouvelles fonctionnalités. Un boulot de fou qui a pavé la voie à tous les chefs d’œuvre d’aventure Sierra : King’s Quest, Larry, Space Quest, Police Quest… toutes ces légendes du genre sont passées par cette machinerie logicielle brillamment huilée !

Imaginez un peu si ce code source d’AGI s’était réellement retrouvé entre de mauvaises mains à l’époque, genre un concurrent peu scrupuleux… Celui-ci aurait pu le récupérer discrètement et l’utiliser dans ses propres jeux, en piquant toutes les idées révolutionnaires de Sierra sans aucune honte (enfin un peu quand même). Heureusement ce petit incident de sécurité est resté sans conséquence. Un miracle quand on y pense !

Lance a eu la bonne idée de partager toutes ses trouvailles dans un dépôt GitHub dédié donc avis aux amateurs de code old school, c’est une mine d’or à explorer ! En plus, il a développé son propre interpréteur AGI moderne basé sur ce code source original, pour faire tourner tous ces classiques directement dans le navigateur. Le dénommé AGILE, un projet aussi fou qu’admirable que vous pouvez tester avec de vrais jeux ici.

Et si vous aussi, vous avez de vieilles disquettes qui traînent, ça vaut peut être le coup d’y jeter un œil avec un éditeur hexa, car on ne sait jamais, elles ont peut-être été mal effacées avant le passage pour le master et vous pourriez y découvrir quelques trucs marrants.

Source

Aujourd’hui, je vous présente GritQL qui va vous permettre de fouiller et triturer du code source, sans avoir besoin d’être un crack en AST ou en parsing. Le truc génial avec ce langage de requête pour la recherche, l’évaluation et la modification du code, c’est que n’importe quel bout de code est une requête valide. Vous mettez un extrait de code entre guillemets simples, et hop, GritQL vous trouve tous les endroits où ce pattern apparaît !

Bon OK, vous allez me dire : « Mouais, mon grep il sait faire ça aussi… » sauf que GritQL est boosté aux stéroïdes notamment grâce à son moteur en Rust capable d’analyser des repos de 10 millions de lignes en un clin d’œil. Votre vieux grep, il peut aller se rhabiller ! 😜

Vous pouvez même utiliser des variables ($comme_ça) dans vos patterns pour identifier des bouts de code puis appliquer des transformations en mode « rechercher/remplacer » pour refactoriser à la volée.

Pour l’installer :

curl -fsSL https://docs.grit.io/install | bash

Et si par exemple, vous voulez remplacer tous vos console.log par des winston.log, c’est facile :

grit ‘console.log($msg)‘ => ‘winston.log($msg)‘

Et bim, votre code est mis à jour !

GritQL dispose également d’une bibliothèque standard avec plus de 200 patterns réutilisables, comme ça, plus besoin de réinventer la roue pour les tâches courantes. Et si vous avez des patterns spécifiques, vous pouvez même les partager avec la communauté.

Autre point fort : une fois que vous maîtrisez GritQL, vous pouvez l’utiliser avec tout un tas de langages. Que vous codiez en JavaScript, Python, Java, Go, Rust ou même en SQL, plus besoin d’apprendre 15 outils différents, un seul suffit !

Et cerise sur le gâteau, il permet d’inclure facilement des règles de « auto-fix » dans vos patterns. Comme ça, vous pouvez corriger et nettoyer votre code en même temps que vous le cherchez. Pratique pour maintenir la qualité sans se prendre la tête ! 👌

Bref, je vous conseille vraiment d’aller jeter un œil à GritQL sur GitHub.

Happy hacking !

Vous êtes-vous déjà demandé ce qui se cache dans les profondeurs obscures des dépôts Git publics ? Eh bien, figurez-vous qu’il y a un outil en ligne qui permet de dénicher des trucs de dingue ! Ça s’appelle Grep.app et c’est un moteur de recherche qui va vous faire halluciner.

Concrètement, vous balancez votre recherche dans la barre et hop, ça vous sort tous les résultats où votre mot-clé apparaît dans les repos Git publics. Genre, vous tapez une adresse email et vous tombez sur tous les endroits où elle est mentionnée. Mais attention, hein… Y a pas que des trucs anodins qui traînent dans ces dépôts. Si vous cherchez un peu, vous pouvez même tomber sur des clés d’API AWS ou Google !

Bon, après faut pas déconner non plus. Si vous tombez sur des clés dans un dépôt public, considérez-les comme grillées direct. Même si le dépôt est supprimé par la suite, y a plein de petits malins qui font ce genre de recherches régulièrement. Donc méfiance !

Cela dit, Github a quand même mis en place un système d’alerte pour les clés, mots de passe, etc qui se retrouvent dans le code. Du coup, y a des chances que la plupart soient invalidées assez vite, soit par le développeur qui change sa clé, soit direct par le fournisseur. Mais on n’est jamais trop prudent…

En parlant de Github, ils ont aussi leur propre outil de recherche de code qui est plutôt balèze. Ça s’appelle Github Code Search. Ça indexe environ 45 millions de dépôts, ce qui est déjà pas mal !

En gros, ils utilisent un moteur de recherche maison qui indexe le contenu avec une technique appelée « sparse ngrams ». D’après eux, ça permet d’exécuter les recherches plus rapidement, tout en étant un index plus petit. Si vous voulez en savoir plus sur la technologie derrière, ils ont publié un article de blog super intéressant.

Maintenant, est-ce que Grep.app est à la hauteur face à Github Code Search ? Difficile à dire… Une chose est sûre, c’est que Grep.app a l’air de se concentrer uniquement sur le code en lui-même. Donc si vous cherchez des chaînes de texte dans de la prose qui se retrouve dans des recherches de code, vous risquez de passer à côté avec Grep.app. Genre pour chercher dans des fichiers texte ou Markdown.

Et ça, c’est un peu dommage. Parce que des fois, on a besoin de chercher du code avec plein de caractères spéciaux vicieux. Et là, la recherche de code actuelle de Github nous laisse tomber. Mais bon, on peut pas tout avoir non plus… En attendant, Grep.app reste quand même un outil bien pratique pour dénicher des infos cachées dans les entrailles de Git. Et puis c’est gratuit et open-source en plus !