01

Why an open client matters

A closed executable can remain playable for years, but every operating-system change, driver regression, unavailable service, and undocumented assumption increases the chance that one day it simply stops. An open client turns those risks into work the community can inspect, discuss, test, and repair.

The goal is not to sand away the identity of Battle Builder. The chunky silhouettes, readable team colors, dramatic voxel destruction, class equipment, map tools, and slightly unruly sandbox are the reason the project exists. Modern maintenance should protect that character rather than replace it with a generic shooter.

02

One battlefield, shared rules

The revival client and BattleSpades server are separate projects with a shared contract. The server owns authoritative world state and game rules; the client handles input, prediction, rendering, sound, menus, and the player’s immediate view of the match.

Protocol 168 compatibility is the bridge between them. Keeping that boundary documented allows the client to be tested against the new dedicated server while the server remains usable by original clients. It also prevents either side from quietly inventing behavior the other cannot understand.

  • Connect to BattleSpades through the established 1.x network contract
  • Preserve client prediction while accepting authoritative reconciliation
  • Receive VXL worlds, entities, objectives, players, and match state
  • Keep packet changes documented so compatibility is deliberate
03

The Battle Builder experience

Ace of Spades works because different fantasies share the same map. A marksman reads distant silhouettes. An engineer sees a defensive line that does not exist yet. A miner sees the route underneath it. A rocketeer sees the structure everyone else assumed was permanent.

That interaction puts unusual demands on a client. Terrain is not background decoration; it is navigable state, cover, ammunition, objective strategy, and a source of debris. Menus, class selection, map previews, blueprint tools, hit feedback, world updates, and sound cues all help players understand a battlefield that changes every second.

04

Current development focus

The client is in development, so this page avoids pretending that every platform, feature, and release channel is finished. The durable target is clear: a maintainable client that can join the same matches as the original game and the BattleSpades server.

Progress is most valuable when it can be reproduced. Client work benefits from the same captured packet sequences, retail behavior notes, physics fixtures, and real-server playtests used by the dedicated server. A visual fix that breaks the wire contract is not a fix, and a compatible packet decoder is not enough if the result is unpleasant to play.

05

How players and builders can help

Client preservation needs a wider range of contributors than network programmers. Build testing, GPU and operating-system coverage, input testing, UI comparison, sound verification, map loading, screenshots, documentation, and clear bug reports all reduce uncertainty.

The most useful report includes the build, operating system, hardware, steps to reproduce, expected behavior, observed behavior, and a short capture when visuals or timing are involved. Join the community before starting a large change so effort lands where it can unblock the project.

06

Common questions

Is the revival client finished?

No. It is an active development project. The site labels it that way deliberately and points players to the community for current build and playtest information.

Will it connect to BattleSpades?

Compatibility with the BattleSpades dedicated server is a core target, using the documented Ace of Spades 1.x protocol boundary.

Does this replace the original art direction?

The preservation goal is to retain the recognizable Battle Builder identity—voxel environments, classes, tools, readable UI, construction, and destruction—while making the implementation maintainable.

Can non-programmers contribute?

Yes. Hardware testing, accessibility feedback, comparison captures, documentation, map checks, sound checks, and reproducible bug reports are all useful.