Inside the Ace of Spades protocol 168

ENet underneath the battlefield

BattleSpades uses ENet 1.3.17 through a pinned pyenet wrapper and vendored C sources. The Battle Builder contract uses protocol version 168, one ENet channel, and range-coder compression. Pinning the transport source makes release builds reproducible across supported systems and avoids depending on obsolete binary packages.

Reliable UDP is useful here because different messages have different needs. Connection management and important state can use ENet’s reliability machinery without forcing every real-time update into a TCP stream where one delayed packet stalls everything behind it.

A packet catalog with evidence

The protocol catalog records packet IDs, direction, reliability, implementation state, handlers, sources, and validation notes. Known behavior and planned recovery are separated so a partially understood message is not presented as settled truth.

That distinction is especially important for a retail protocol with broad presentation and mode surfaces. Building, entities, roster state, combat effects, match lifecycle, UI messages, objectives, deployables, scene rollover, and authentication do not all become clear at the same time.

• Client-to-server input, aim, actions, chat, class, and team requests
• Server-to-client world updates, entities, effects, rules, and objectives
• Scene and resource messages used during map and mode transitions
• Retail behavior notes for VIP, Zombie, CTF, blocks, and equipment
• Explicit planned categories where evidence is still incomplete

Client prediction changes the meaning of movement

The client does not wait for a round trip before showing every step. It predicts local movement, then consumes authoritative server updates. A compatible server therefore needs the same practical physics model and reconciliation expectations, not merely the ability to decode input bits.

BattleSpades uses deterministic fixtures and captured client behavior to calibrate walking, sprinting, crouching, wading, climbing, gravity, friction, jumping, and owner-row updates. Position parity is measured over long sequences because a tiny per-frame difference can become a visible correction seconds later.

VXL maps are live network state

The map begins as a streamed VXL resource with CRC validation, but it immediately becomes mutable shared state. Block lines, individual placement, digging, bullet damage, explosive damage, color, prefabs, and collapse all need stable ordering so every client ends with the same world.

KV6 voxel models cover a different layer: entities and prefabs rather than the terrain volume itself. Keeping formats and responsibilities explicit prevents a visual resource problem from being misdiagnosed as a map synchronization problem.

From observation to regression test

The clean-room workflow begins with observable behavior: captures, instrumented clients, controlled input, packet traces, and repeatable scenarios. A finding is documented with its evidence, implemented at the correct ownership layer, then protected by a regression test or real-client validation gate.

This turns the protocol archive into more than a reference for BattleSpades. It becomes a map for client developers, alternative server implementations, tool authors, and future maintainers trying to understand why a seemingly odd field or ordering constraint exists.

1. 01
   Observe

   Create a narrow scenario and capture what the retail client sends, receives, and displays.

2. 02
   Describe

   Record direction, layout, reliability, timing, uncertainty, and links to supporting evidence.

3. 03
   Implement

   Place behavior in transport, protocol, simulation, world, mode, or presentation code according to ownership.

4. 04
   Verify

   Replay fixtures and retest with real clients so later changes cannot silently erase parity.