--- title: "Inside the Ace of Spades protocol 168" description: "A readable guide to Ace of Spades protocol 168: ENet transport, packet research, VXL map streaming, prediction, and clean-room verification." canonical: "https://aosplay.net/protocol-168" markdown: "https://aosplay.net/docs/protocol-168.md" last_updated: "2026-07-16" content_type: "TechArticle" keywords: ["Ace of Spades protocol 168","Battle Builder network protocol","Ace of Spades packet documentation","ENet voxel game protocol","VXL map protocol"] --- # Inside the Ace of Spades protocol 168 > A readable guide to Ace of Spades protocol 168: ENet transport, packet research, VXL map streaming, prediction, and clean-room verification. Protocol 168 is the language shared by the Battle Builder client and dedicated server. Rebuilding it means more than assigning names to packet IDs: ordering, reliability, binary layout, state ownership, timing, compression, and the client’s local prediction all affect what players actually experience. ![Tokyo Neon Ace of Spades map preview with dense voxel city buildings](https://aosplay.net/game/maps/tokyoneon.png) _A protocol carries more than player positions: the complete match scene, changing VXL terrain, entities, rules, objectives, and presentation state cross the wire._ ## At a glance | Value | Meaning | | --- | --- | | 168 | protocol identifier | | ENet | reliable UDP transport | | 1 | network channel | | VXL | streamed voxel worlds | ## 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 > **Documentation rule — Unknown is a valid state.** Marking a packet or field as planned is more useful than assigning a confident name that sends future reverse engineering in the wrong direction. ## 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. **Observe.** Create a narrow scenario and capture what the retail client sends, receives, and displays. 2. **Describe.** Record direction, layout, reliability, timing, uncertainty, and links to supporting evidence. 3. **Implement.** Place behavior in transport, protocol, simulation, world, mode, or presentation code according to ownership. 4. **Verify.** Replay fixtures and retest with real clients so later changes cannot silently erase parity. ## Frequently asked questions ### What does protocol 168 mean? It is the protocol identifier used by the targeted Ace of Spades 1.x Battle Builder network contract. Compatible clients and servers must agree on that contract. ### Does protocol documentation contain original game source code? No. The project documents observable wire formats and behavior for a clean-room implementation. ### Why use ENet instead of raw UDP? ENet provides connection management, sequencing, reliability choices, and congestion-aware delivery while retaining the low-latency characteristics useful to a real-time game. ### Are all packets fully understood? No. The catalog distinguishes implemented, observed, partially understood, and planned areas so uncertainty remains visible. ## Related reading - [BattleSpades dedicated server](https://aosplay.net/dedicated-server) ([Markdown](https://aosplay.net/docs/dedicated-server.md)) - [A master server for reconnecting the community](https://aosplay.net/master-server) ([Markdown](https://aosplay.net/docs/master-server.md)) - [How to host a BattleSpades server](https://aosplay.net/host-a-server) ([Markdown](https://aosplay.net/docs/host-a-server.md)) --- Source: [Inside the Ace of Spades protocol 168](https://aosplay.net/protocol-168) Maintained by Ace of Spades Revival contributors.