Contribute

Thanks for helping bring old games back. Everyone can take part, whether you reverse engineer, write web code, make art, research history, or just remember how a game played.

Ways to help

  • Propose a game. Open a new project issue or send the project as a pull request.
  • Analyze. Run REA on a game you own and write up what you find as specs in a project's notes/.
  • Rebuild. Implement specs in a project's play/ folder, or in its own repository.
  • Verify. Play the original and the rebuild next to each other and report differences.
  • Research. Fill in history, versions and rights status on project pages.

Every project page has a Help wanted list. Those are good first tasks.

Start a new project

  1. Search the projects and issues to make sure the game isn't already covered.
  2. Fork the repo and copy the template: 
    cp -r projects/_template projects/your-game-slug
    Use a lowercase slug with dashes, such as zombie-lane or dark-reign-2.
  3. Add an entry to projects/projects.json (see below), then fill in projects/your-game-slug/index.html.
  4. Add yourself to maintainers if you plan to lead it. You can also leave it empty for someone else to pick up.
  5. Run bun run check, then open a pull request. Once it merges, the project gets its own page and a card on the home page.

Each project is self-contained. Maintainers decide their stack, structure and roadmap. Changes outside a project folder (styles, scripts, docs) are reviewed by the site maintainers.

The projects.json entry

{
  "slug": "your-game-slug",
  "title": "Game Title",
  "summary": "One sentence.",
  "status": "proposed",            // proposed | analysis | rebuilding | playable | complete
  "original": {
    "developer": "Studio",
    "publisher": null,             // optional
    "year": 1999,
    "platforms": ["Windows"]
  },
  "target": "HTML5 Canvas + JavaScript",
  "play": null,                    // "play/" once something runs, or a full URL
  "repo": null,                    // optional separate repository
  "maintainers": ["your-github-username"],
  "tags": ["strategy"],
  "help_wanted": ["A task someone could pick up"]
}

The comments above are only for explanation. JSON doesn't allow comments, so leave them out.

Ground rules

These rules protect the project and the people who made the original games. Pull requests that break them will be closed.

  1. Never commit original game files. That means binaries, ROMs, APKs, ISOs, extracted art, audio, maps or text. .gitignore blocks common formats and CI rejects them, but you are still responsible.
  2. Commit specs, not decompiled code. Notes describe behavior and file formats in your own words, with evidence references. Short identifiers, constants and format tables are fine. Pages of decompiled functions are not.
  3. Write rebuilds from scratch. Implement from the specs. Do not translate decompiled code line by line.
  4. Bring your own copy. A rebuild either loads original assets locally from the player's own files (in the browser, never uploaded) or uses new assets with a compatible license.
  5. "Abandonware" has no legal meaning. Record what is known about each game's rights status. If a rights holder asks for a project to be removed, it will be removed promptly, without argument. Get in touch through a GitHub issue or privately via the repository owner's profile.
  6. No cheating, piracy or DRM-bypass tools. The goal is preservation and playability, not getting around protections on games that are still sold.
  7. Be kind. Critique work, not people. Harassment of any kind is not tolerated.

Running the site locally

The site is plain HTML, CSS and JavaScript. There is no build step. Serve the repo root with any static server:

bun run dev          # bunx serve . → http://localhost:3000
bun run check        # validate projects.json and look for forbidden files

Using AI responsibly

AI agents do most of the analysis here, and they can be wrong. Before you commit a finding:

  • Make sure every claim in a spec points to REA evidence (an address, method, capture or file offset).
  • Mark guesses as guesses, and keep open questions in the spec's "Unknowns" section.
  • Read and understand the code you commit. You are its author.

License

Site code and docs are MIT-licensed. Each project's code is MIT by default unless its folder includes a different LICENSE. Contributors keep the copyright to their contributions. Original games and their assets belong to their rights holders and are never distributed here.