En bref

RustyZoo est une réimplémentation de Zoo Tycoon (2001), écrite en Rust. Cette page explique comment le travail est organisé, comment il est vérifié, et ce que cela signifie pour la confiance que vous pouvez accorder au résultat. Les chiffres proviennent des dépôts publics, à la date du 17 octobre 2026.

L’objectif

Le premier objectif est une copie fidèle : les mêmes règles, le même rythme et les mêmes résultats que dans le jeu original. Ce n’est qu’une fois cela atteint que vient une seconde version, améliorée, tirée de la même source. Elle corrigerait les bogues connus de l’original, prendrait en charge les écrans larges et les zoos plus grands, et ajouterait une interface pour les mods.

Les bogues découverts dans l’original en chemin ne sont pas corrigés dans la version fidèle. Ils sont consignés dans des tickets portant l’étiquette original-bug, pour que la version suivante puisse s’en occuper. Au 17 octobre 2026, il y a 30 tickets de ce type.

Un mainteneur, plusieurs agents d’IA

Une seule personne dirige le projet. Elle prend toutes les décisions, répond à chaque question en suspens et vérifie le résultat contre le jeu original, y compris sur un vrai Mac.

L’essentiel du travail courant est confié à des agents d’IA. Chaque agent a un rôle et un jeu d’instructions écrit et figé, et les rôles sont volontairement tenus séparés :

• L’orchestrateur. Planifie le travail et le distribue par des tickets GitHub, des jalons et un tableau de projet public. GitHub fait foi : une tâche, une question ou une décision qui n’y figure pas ne fait pas partie du projet.
• Les analystes. Étudient le programme original à l’aide d’un désassembleur et d’un décompilateur, et en regardant le jeu original tourner sous Wine sur un écran virtuel, piloté par des saisies scriptées. Le jeu original en marche s’appelle « l’oracle ». Les analystes rédigent les spécifications de comportement.
• Les développeurs. Traitent un ticket par pull request, en travaillant uniquement à partir des spécifications. Ils ne voient jamais le code de l’original.
• Les relecteurs. Vérifient chaque pull request contre les spécifications et contre l’original, écrivent un petit script de reproduction et rendent un verdict unique.
• Le greffier. Tient en ordre les tickets, les étiquettes et le tableau. Il ne décide de rien.

Les tâches ne font pas appel à des modèles de même taille : de petits modèles économiques pour l’intendance, de plus grands pour les questions difficiles. Les agents proposent et construisent ; le mainteneur décide.

Salle blanche

Les personnes et les agents qui lisent le programme original ne sont pas ceux qui écrivent le moteur. Les analystes décrivent, dans des spécifications, ce que fait l’original. Les développeurs implémentent à partir de ces seules descriptions. Cette séparation est ce qui garde le moteur exempt du code de l’original.

Les spécifications sont privées, car elles décrivent le programme original. Le moteur et ses tests sont publics, sous licence GPL-3.0-or-later. Le dépôt ne contient aucun code original, aucune ressource originale et aucun texte original. Pour jouer, vous apportez votre propre exemplaire du jeu, ou vous utilisez l’une des deux versions d’essai officielles gratuites que Microsoft héberge encore. RustyZoo ne les redistribue jamais.

Comment une modification est acceptée

Chaque modification part d’un ticket et arrive sous la forme d’une seule pull request. Les pull requests sont fusionnées une par une, en un seul commit (squash). Avant l’ouverture d’une pull request, un contrôle local doit passer :

• vérification du formatage ;
• analyse statique (lint), avertissements traités comme des erreurs ;
• tests unitaires ;
• les tests qui nécessitent les données du jeu complet ;
• les commandes de ressources et de cartes lancées sur les données de la version d’essai gratuite.

Le relecteur vérifie ensuite la modification contre les spécifications et l’original. Son script de reproduction est rejoué sur le résultat fusionné avant la fusion, si bien que ce qui est fusionné est bien ce qui a été vérifié.

Les tests qui tranchent

Le développement s’appuie sur les tests. Au-delà des tests unitaires habituels, trois types de contrôle portent l’essentiel du poids.

Intégration continue sur trois systèmes

Chaque modification est compilée et testée sous Windows, macOS et Linux.

Une empreinte de simulation déterministe

La simulation peut tourner sans aucune fenêtre pendant un nombre fixe de pas et afficher une seule empreinte de l’état complet : cases, entités, animaux, visiteurs et personnel, argent, calendrier et générateur aléatoire. Le même zoo doit donner la même empreinte sur les trois systèmes. L’intégration continue les compare. Si l’un des systèmes dérive, la compilation échoue.

Des empreintes d’images figées

De vraies scènes du jeu sont dessinées sans fenêtre, et l’empreinte de chaque image dessinée est figée dans les tests. Une modification qui change une image change son empreinte : une régression visuelle ne peut donc pas passer inaperçue.

Une galerie d’images

Chaque pull request qui change ce qui est visible produit automatiquement des images. Elles vont dans le dépôt de captures d’écran, un dossier par jalon, avec à côté des images du jeu original pour comparer. Un README par jalon indique quelle commande a produit chaque image. Vous pouvez suivre les progrès sans rien compiler.

Les jalons

Le travail est découpé en dix jalons, de M0 à M9. Toutes les dates sont celles des jalons GitHub du projet. État au 17 octobre 2026.

• M0 Foundations. Dépôt, intégration continue sur trois systèmes, une fenêtre et une sortie audio. Clos le 13 octobre 2026.
• M1 Assets. Lecture des archives et des formats de fichiers de l’original, depuis le jeu complet ou l’une ou l’autre des versions d’essai. Clos le 14 octobre 2026.
• M2 Static world. Dessiner une carte comme l’original l’affiche. Clos le 14 octobre 2026.
• M3 Window. Boucle de jeu au rythme de l’original, caméra, saisie et son. Clos le 14 octobre 2026.
• M4 UI. L’interface du jeu construite à partir des fichiers de mise en page de l’original, et le menu principal. Clos le 15 octobre 2026.
• M5 Building. Modifier un zoo : terrain, allées, clôtures, décor, bâtiments, enclos, et les payer. Clos le 15 octobre 2026.
• M6 Life. Animaux, visiteurs et personnel, avec recherche de chemin, besoins et objectifs. Ouvert.
• M7 Full game. Sauvegardes, recherche, scénarios, récompenses, traductions. Ouvert.
• M8 Packaging. Versions prêtes à l’emploi pour Windows, macOS et Linux. Ouvert.
• M9 Beyond the original. La version améliorée, uniquement une fois la parité atteinte. Ouvert.

Le dépôt a été créé le 13 octobre 2026. Au 17 octobre 2026, il compte 130 pull requests fusionnées, 11 ouvertes, 144 tickets fermés et 133 ouverts.

Ce que cela signifie pour vous

Ce qui est fiable

• Les formats de fichiers et les lecteurs de données. Ils sont éprouvés sur le jeu complet et sur les deux versions d’essai, sur trois systèmes.
• L’affichage des cartes et de l’interface comme dans l’original, appuyé par des empreintes d’images figées et la galerie d’images.
• La simulation est déterministe : le même zoo donne le même résultat sous Windows, macOS et Linux.
• Le moteur ne contient rien de l’original. Vous pouvez tout lire, et chaque modification laisse une trace publique : ticket, relecture et tests.

Ce qui ne l’est pas encore

• C’est du pré-alpha. Au 17 octobre 2026, une partie libre n’est pas encore jouable ; les animaux, les visiteurs et le personnel sont en cours de construction dans M6.
• Les sauvegardes, la recherche, les scénarios et les récompenses arrivent avec M7.
• Il n’existe pas encore de version prête à l’emploi ; il faut compiler depuis les sources jusqu’à M8.
• La version améliorée, avec corrections de bogues, écrans larges et mods, n’existe pas encore. Elle ne démarre qu’une fois la version fidèle terminée.
• Fidèle veut dire vérifié contre l’original par le mainteneur et par des tests, pas prouvé. Si vous constatez une différence, ouvrez un ticket.

Liens

• Dépôt du moteur : github.com/RustyZoo/RustyZoo
• Tableau du projet : github.com/orgs/RustyZoo/projects/1
• Captures d’écran : github.com/RustyZoo/screenshots