Delivering the tested arena build without changing the server around it

Once the browser build was qualified, the deployment job was to deliver that same build. The October 12 release record ties Battle Bot Arena Engine 2.0.0 to a specific five-file WebGL package, rather than treating any successful Unity export as interchangeable.

The package contained the page, loader, framework, WebAssembly and data payload. Its compression fallback matched the existing hosting behavior, so the update could use the current server configuration. The old site was preserved before an atomic switch to the new release.

After activation, the four engine and loader payloads matched their expected bytes over HTTPS. The page received the site's existing analytics injection, so its served response was checked against a separately prepared expected result. That's a good example of why the source file's hash and the public HTML response aren't always the same check.

The deployment record also verified retained legacy assets for cached clients and kept private manifests, archives and diagnostic paths out of the public site. The surrounding service and hostname comparisons remained unchanged across the deployment captures.

A separate report from the Windows build owner recorded a fresh public desktop-browser check: Workshop and components, preflight, the Garage handoff, actual driving, weapon spin and the Forge switch. That is distinct from the deployment audit's direct file and HTTP checks.

This release still wasn't mobile-qualified. The wrapper recommended desktop keyboard and mouse, and the source acceptance explicitly excluded touch input. The next browser milestone needs a deliberately tested mobile artifact and a complete save/load editing path, alongside audio and performance checks. For this stage, the important result was getting the tested desktop experience onto the site with its identity and recovery path preserved.