01

Preserve the ability to play

The project’s practical goal is straightforward: a compatible client, a dedicated server anyone can operate, documentation that survives individual maintainers, and a discovery service that helps players find independent hosts.

Preservation does not mean freezing every implementation choice forever. It means protecting the recognizable experience and the evidence needed to make informed changes. Stable compatibility creates room for accessibility work, platform support, new tools, custom modes, and experiments without erasing the baseline.

02

How the work is done

The dedicated server is a clean-room implementation based on observed client behavior, packet captures, measured physics, controlled scenarios, and public documentation. It does not rely on possession of an original dedicated-server source tree.

Claims are tied to runnable work. Features move from observation to implementation, regression coverage, real-client validation, and operator documentation. Current limitations remain visible because an honest planned label is more useful to contributors than a polished fiction.

  1. 01
    Reverse

    Observe the client, isolate behavior, capture evidence, and document uncertainty.

  2. 02
    Rebuild

    Implement the smallest correct ownership layer in readable, testable code.

  3. 03
    Verify

    Replay fixtures and test real clients, modes, maps, bots, and capacity.

  4. 04
    Reconnect

    Package releases, support hosts, improve discovery, and organize playtests.

03

Project values

Compatibility is treated as a measurable contract. Performance claims need a baseline. Security defaults should protect a first-time host. Documentation should explain why a constant or packet exists, not only repeat its name.

Community work also needs readable progress. The portfolio, public repositories, focused docs, release checks, and operation board exist so players can see what is playable, developers can find evidence, and contributors can choose work with a clear definition of done.

  • People-first documentation instead of keyword-shaped filler
  • Real-client evidence instead of folklore
  • Portable releases instead of a development-only demo
  • Independent hosting instead of a single mandatory operator
  • Visible uncertainty instead of inflated completion claims
  • Accessible interfaces and useful text alternatives for project media
04

Independent and unofficial

Ace of Spades Revival is an independent community preservation project and is not an official release or affiliated with the original publisher. References to the game identify the compatibility target and the experience being preserved.

The portfolio uses visual materials already present in the local revival workspace to communicate the original Battle Builder design language. Project code, third-party dependencies, fonts, and game assets retain their respective notices and licenses; contributors should review the repositories before redistribution.

05

There is more than one way to contribute

Protocol and systems work are important, but a durable revival also needs server operators, map makers, testers, technical writers, release verification, accessibility review, moderation planning, and people willing to organize a match.

Start by reading the page closest to your interest. Run a server if you want operational feedback. Review protocol 168 if you enjoy evidence-driven reverse engineering. Test the client if you can describe reproducible visual or input behavior. Join the community before taking on a large branch so the result lands where it helps.

06

Common questions

Is this project affiliated with the original publisher?

No. Ace of Spades Revival is an independent, unofficial community preservation project.

Why rebuild both a client and a server?

A durable multiplayer game needs both sides of the connection. The server preserves shared rules and hosting; the client preserves access, presentation, input, and the player experience.

Why publish protocol research?

Public evidence reduces duplicated work, makes compatibility reviewable, and helps future client, server, and tool developers understand the contract.

Do I need to be a programmer to help?

No. Testing, hosting, maps, captures, documentation, accessibility feedback, moderation planning, and playtest organization are all valuable.