The Rumble Client runs local Tank Royale battles against the published Rumble catalog. Ranked mode validates the current engine and catalog pin, journals every completed result with replay evidence, and submits batches through the Rumble data repository's issue inbox. Practice mode never creates a ranked record or submission.
The project is currently being built under Tank Royale change CH-012. The public contracts are owned by CAP-016.
Contributors may use the supported native distribution or the recommended Docker image. Docker supplies the complete Java, .NET, Python, and Node.js environment and is the isolation boundary for reviewed bot code; direct execution uses the same client contracts but runs bots with the contributor's host permissions. Production images are published only after Tank Royale releases the engine contracts required by ranked Rumble battles.
Install JDK 17 and keep a Tank Royale checkout containing BR-049 beside this repository, then run:
./gradlew --no-configuration-cache -PtankRoyaleSource=../tank-royale buildOn PowerShell, quote the property argument: .\gradlew.bat --no-configuration-cache "-PtankRoyaleSource=../tank-royale" build.
The source substitution is the development dependency path until the Runner API is part of a value-bearing Tank Royale release. It compiles the client against dev.robocode.tankroyale:robocode-tankroyale-runner without publishing an interim artifact. CI and the Docker build pin the accepted Tank Royale merge commit rather than following a moving branch. Configuration caching is disabled for source-substituted builds because the included Tank Royale build does not support it.
The build produces native ZIP and TAR archives under build/distributions/. Run ./gradlew run --args="--check-runtimes" to verify the required Java 17, .NET 8 SDK, Python 3.12, and Node.js 22 installations; the check never installs or changes them.
The client validates configuration and can synchronize the current ranked input snapshot. Run ./gradlew run --args="--validate-config" to check local settings, then run ./gradlew run --args="--sync" to resolve the canonical data repository, validate its engine pin, catalog, client registration, and matchmaking advice, and prepare an immutable bot cache at the catalog's exact source commit. Every cached source tree is checked against its catalog SHA-256 before it can be used. Ranked battle selection uses a recorded random seed, prioritizes under-sampled pairings involving myBots, and falls back to distinct active catalog bots when no advice is available. Each game type declares how many bots one catalog entry expands to, so TwinDuel selects two team entries for its four pinned participants while 1v1 and melee select individual bots, and a selection never contains two entries that share a member bot. Run ./gradlew run --args="--run" to execute one pinned ranked battle through Battle Runner and retain its replay evidence locally. Run ./gradlew run --args="--submit" to post pending records through the rumble-data issue inbox. It reads RUMBLE_CLIENT_TOKEN only at runtime; use a GitHub fine-grained token limited to read and write Issues access for that repository. The client records posted batches locally and removes records only after their result-data receipt comments appear. The runtime container is added in a subsequent CH-012 task.
Copy rumble-client.example.json to rumble-client.json. Ranked mode requires a registered clientId; practice mode may omit it. The optional workDirectory selects the local cache, journal, and replay-evidence root and defaults to .rumble-client beside the configuration file. Do not commit the resulting file or any token. A submission token is supplied at runtime only when issue-ops support is available.
Docker Engine or Docker Desktop is required. Build the current non-published development image with docker build --tag rumble-client:dev ., then use docker/rumble.sh or docker/rumble.ps1 to validate configuration, check the bundled runtimes, or synchronize the ranked snapshot. Docker execution uses the default .rumble-client work directory beside the configuration file. The launchers expose only that configuration file and state directory to the container and apply a read-only root filesystem, dropped capabilities, finite resource limits, and no external network for the runtime check.
Submission commands remain unavailable until their later CH-012 implementation tasks land. Their Docker launcher phases will run battles offline without a submission credential and submission online without starting bot code.
Read CONTRIBUTING.md, SECURITY.md, and GOVERNANCE.md before opening a pull request.