RustyZooUser's Guide · pre-alpha edition, October 2026

← Back to the User's Guide

Chapter1

At a glance

RustyZoo is a re-implementation of Zoo Tycoon (2001), written in Rust. This page explains how the work is organised, how it is checked, and what that means for how far you can trust the result. Figures are taken from the public repositories as of 17 October 2026.

Chapter2

The goal

The first goal is a faithful copy: the same rules, the same timing and the same results as the original game. Only when that is reached does a second build follow, an enhanced one made from the same source. It would fix the original's known bugs, support large and wide screens and larger zoos, and add a modding interface.

Bugs found in the original along the way are not fixed in the faithful build. They are recorded as issues with an original-bug label, so that the later build can deal with them. As of 17 October 2026 there are 30 such issues.

Chapter3

One maintainer, several AI agents

One person directs the project. They make every decision, answer every open question, and test the result against the original game, including on a real Mac.

Most of the routine work is done by AI agents. Each agent has a role and a fixed written set of instructions, and the roles are kept apart on purpose:

  • Orchestrator. Plans the work and hands it out through GitHub issues, milestones and a public project board. GitHub is the single source of truth: if a task, question or decision is not there, it is not part of the project.
  • Analysts. Study the original program, using a disassembler and decompiler and by watching the original game run under Wine on a virtual display, driven by scripted inputs. The running original is called “the oracle”. Analysts write behaviour specifications.
  • Developers. Implement one issue per pull request, working only from the specifications. They never see the original's code.
  • Reviewers. Check each pull request against the specifications and against the original, write a small reproduction script, and post a single verdict.
  • Clerk. Keeps issues, labels and the board tidy. It decides nothing.

Different jobs use different model sizes: small, cheap models for bookkeeping, larger ones for hard questions. The agents propose and build; the maintainer decides.

Chapter4

Clean room

The people and agents who read the original program are not the ones who write the engine. The analysts describe what the original does, in specifications. The developers implement from those descriptions alone. This separation is what keeps the engine free of the original's code.

The specifications are private, because they describe the original program. The engine and its tests are public, under GPL-3.0-or-later. The repository contains no original code, no original assets and no original text. To play, you bring your own copy of the game, or use one of the two free official trials that Microsoft still hosts. RustyZoo never redistributes them.

Chapter5

How a change gets in

Every change starts from an issue and arrives as one pull request. Pull requests are merged one at a time, as squashed commits. Before a pull request is opened, a local gate must pass:

  • formatting check;
  • lint check, with warnings treated as errors;
  • unit tests;
  • the tests that need the full game data;
  • the asset and map commands run over the free trial data.

The reviewer then checks the change against the specifications and the original. The reviewer's reproduction script is run again on the merged result before the merge, so what is merged is what was verified.

Chapter6

Tests that decide

Development is test-based. Beyond the usual unit tests, three kinds of check carry most of the weight.

Continuous integration on three systems

Every change is built and tested on Windows, macOS and Linux.

A deterministic simulation hash

The simulation can run without any window for a fixed number of steps and print one hash of the whole state: tiles, entities, animals, guests and staff, money, calendar and the random generator. The same zoo must give the same hash on all three systems. CI compares them. If one system drifts, the build fails.

Pinned frame hashes

Real game scenes are drawn without a window, and the hash of each drawn frame is pinned in the tests. A change that alters a picture alters its hash, so a visual regression cannot pass unnoticed.

Chapter7

A picture gallery

Each pull request that changes what is visible produces pictures automatically. They go into the separate screenshots repository, one folder per milestone, with pictures of the original game next to them for comparison. A README per milestone says which command made each picture. You can compare progress without building anything.

Chapter8

Milestones

The work is split into ten milestones, M0 to M9. All dates are from the project's GitHub milestones. Status as of 17 October 2026.

  • M0 Foundations. Repository, CI on three systems, a window and an audio device. Closed 13 October 2026.
  • M1 Assets. Read the original's archives and file formats, from the full game or either trial. Closed 14 October 2026.
  • M2 Static world. Draw a map as the original shows it. Closed 14 October 2026.
  • M3 Window. Game loop with the original's timing, camera, input and sound. Closed 14 October 2026.
  • M4 UI. The in-game interface built from the original layout files, and the main menu. Closed 15 October 2026.
  • M5 Building. Edit a zoo: terrain, paths, fences, scenery, buildings, exhibits, and pay for them. Closed 15 October 2026.
  • M6 Life. Animals, guests and staff with path finding, needs and goals. Open.
  • M7 Full game. Saving games, research, scenarios, awards, localisation. Open.
  • M8 Packaging. Ready-to-run releases for Windows, macOS and Linux. Open.
  • M9 Beyond the original. The enhanced build, after parity only. Open.

The repository was created on 13 October 2026. As of 17 October 2026 it has 130 merged pull requests, 11 open ones, 144 closed issues and 133 open ones.

Chapter9

What this means for you

What is reliable

  • The file formats and the data readers. They are exercised on the full game and on both free trials, on three systems.
  • Drawing maps and the interface as the original does, backed by pinned frame hashes and the picture gallery.
  • The simulation is deterministic: the same zoo gives the same result on Windows, macOS and Linux.
  • The engine contains nothing from the original. You can read all of it, and every change has a public trail of issue, review and tests.

What is not yet

  • It is pre-alpha. As of 17 October 2026 a freeform game is not yet playable; animals, guests and staff are being built in M6.
  • Saving games, research, scenarios and awards come in M7.
  • There are no ready-to-run releases yet; you build from source until M8.
  • The enhanced build with bug fixes, wide screens and modding does not exist yet. It starts only after the faithful build is complete.
  • Faithful means checked against the original by the maintainer and by tests, not proven. If you find a difference, open an issue.
Chapter10

Links