Robocode: a programming game where your tanks fight each other

What Robocode is and who it is for

Robocode is a programming game. The README calls it engaging and educational and says its primary aim is to teach programming skills in a fun and interactive environment, and the motto in the README is the summary of the loop: build the best, destroy the rest.

The mechanics are simple enough to explain in a sentence. You write a program for a robot tank, your robot and other robots are placed in a battle, and they shoot at each other according to your code. There is a radar to scan for opponents, a gun to fire, movement to dodge, and a score for surviving. What makes it interesting is that your opponent is also code, so the game becomes a problem of writing code that predicts and outmanoeuvres other code.

The README is explicit about the two audiences and frames them as the same audience at different points. You can learn to program, developing skills in Java or Kotlin. You can create battle tanks, designing and programming virtual robots that compete against each other. And you can improve problem solving, enhancing algorithmic thinking by writing better code to outsmart opponents. The README says it suits all levels, from beginners taking their first steps in coding to experienced developers looking for a fun challenge.

That framing is what separates it from an ordinary game. A beginner writes a robot that fires when it sees something, and the first line of code that runs does something visible on screen. An experienced developer writes a strategy that models an opponent's likely behaviour and edges ahead of it, and the same small API supports that.

The ecosystem around the game

The README is mostly a list of links, and that list is the real map of the project.

The Book of Robocode is described as the best place to start learning. The Robocode home page and an Introduction document sit alongside it. The RoboWiki is a community knowledge base that has been collecting Robocode wisdom since 2003, which tells you how long this has been running and how much accumulated knowledge there is to reuse.

Then there are the community spaces. A Google group is where you can ask questions, a Facebook group is for enthusiasts, and a separate Robocode Application Developers group exists for people who want to develop or experiment with the Robocode application itself, as opposed to writing robots in it. The last distinction matters, because there are two quite different communities here, the people who play and the people who change the game.

There is also a Developers Guide for building Robocode, on the wiki, for anyone who wants to build the game from source rather than install it.

The competitive element is LiteRumble, described as Robocode competitive rankings and hosted on the Robowiki domain. That is the ladder a player climbs, and its absence from the modern successor is the single most consequential fact in the README for anyone choosing between the two platforms.

The Gradle module layout

The repository root shows a project split into a dozen Gradle modules, and the names describe the architecture.

There is robocode.api/, which is the interface a robot program sees, and that separation is the important one, because it is the boundary that keeps a robot from reaching into the engine. robocode.core/ holds the core engine, robocode.battle/ the battle simulation, robocode.host/ the host that runs the battle, and robocode.main/ the entry point.

Then there are the presentation and support modules: robocode.ui/ and robocode.ui.editor/ for the user interface and the robot editor, robocode.sound/ for the audio, robocode.content/ for the shipped content, robocode.installer/ for the setup, robocode.repository/ for the repository of shared robots, and robocode.roborumble/ for the competitive rankings integration.

The testing modules are robocode.tests/ for the tests and robocode.tests.robots/ for the test robots, which is the pattern a game engine should follow, since the robots themselves are the best integration test material.

The build is Gradle in its Kotlin DSL, with build.gradle.kts, settings.gradle.kts, a gradle/ directory, a gradlew and gradlew.bat wrapper, and a buildSrc/ directory for custom build logic. The wrapper scripts are there so a contributor builds with the pinned Gradle version rather than whatever is installed. There is also gradle.properties, an AGENTS.md, a publish.md and a release.md for the release process, and a versions.md that presumably tracks the dependency versions across the modules.

The Docker image and what it actually runs

The Dockerfile at the root is short and does something slightly unexpected: it does not run the game, it runs the ranking server.

FROM eclipse-temurin:21-jre-alpine

COPY ./build/robocode-*-setup.jar ./
RUN java -jar robocode-*-setup.jar

ENV USER=https://hub.docker.com/r/zamboch/roborumble

WORKDIR /root/robocode
ENTRYPOINT ["./roborumble.sh"]

The base image is a JRE on Alpine rather than a JDK, which is what you want for a server that runs a jar. The setup jar is copied in and executed at build time, and the Robocode setup program unpacks the application into the working directory, which is where the roborumble.sh script that then runs the ranking server lives.

So the image is the competitive ranking infrastructure, not a game client. The ENV USER line points at the Docker Hub account for roborumble, which is the account under which those images are published.

Two things are worth noting for anyone who wants to run Robocode in a container. The image expects the build output to exist first, since it copies from a build/ directory, so you need to run the Gradle build before the Docker build. And a ranking server needs persistence for the results, which this Dockerfile does not configure, since there is no volume or database in it.

Where Robocode is the wrong choice

The first limitation is the competitive ecosystem. The README states that the next generation platform, Tank Royale, does not yet have an equivalent of LiteRumble for competitive rankings. So the ladder that made Robocode a long-running pursuit, with real opponents and real stakes, is not reproduced in the successor, and a player who wants to compete and improve against strangers has a reason to stay on the older platform.

The second is the language story. Robocode proper is Java or Kotlin, and the primary language field in the repository metadata says Java. Tank Royale is the modernised architecture and it supports Java, Kotlin, Python and C#, with more languages possible in the future. For a beginner deciding what language to learn with, that difference decides which platform they should start on, and the README points at Tank Royale as the next generation rather than describing a migration path in detail.

The third is that the game has been running for a very long time, and the Java and Kotlin APIs are what they are. The API surface is deliberately small, which is why it survives, but a developer coming from a modern framework will find it unusual, and the pattern of overriding methods on a Robot class is dated in a way that is part of the charm and part of the friction.

The fourth is the licence. The repository records a custom licence that GitHub cannot classify, with the terms in LICENSE.txt, and the README does not describe them. For a game you play, that hardly matters. For a robot you publish, a competition you enter, or code you fork, the terms are what you need to read first, and the README is not the place to find out.

The fifth is the practical matter of the competitive scene. A community that has been running since 2003 has an established culture, and joining it as a newcomer is a process of reading the wiki, the book and the ranking pages before writing any code.

Robocode compared with Tank Royale, LiteRumble and a modern bot competition

The comparison with Tank Royale is the one the README sets up itself, and the difference in approach is architectural rather than cosmetic. Robocode is a desktop application with a rich editor, a repository of shared robots and a Java API that has been stable for two decades, and the game runs as a deterministic simulation on your own machine. Tank Royale modernises the architecture and opens the language choice, which is the change that matters for new players.

The comparison with LiteRumble is the one that decides whether to keep playing. LiteRumble is described as Robocode competitive rankings, and it is where a robot earns its rating against other people's robots. Without that, the game is still a good learning environment and a decent hobby, but it is a hobby you practise alone.

A third comparison is with modern game-based learning platforms, most of which are browser games with a visual editor and no code at all, or a block-based language for children. The difference is in what you learn. Robocode teaches Java or Kotlin as real languages, in a project structure that resembles a real application, with an API you read and a class you extend. A browser platform teaches a simplified subset designed to be frictionless, which is a good on-ramp and a different destination.

The fourth comparison is with writing a bot for an existing strategy game, which is the closest modern activity. The difference is that Robocode gives you a small, well-specified, closed problem with an opponent you control, which is the point, because the learning is in the iteration loop and not in reverse engineering a commercial game.

Licence, releases and the state of the project

The licence field on the repository records a custom licence that GitHub cannot classify, with the full terms in LICENSE.txt at the root. That is a detail to settle before you publish a robot or fork the project, and the README does not paraphrase the terms, so the file is the only source.

The project is not archived and the last push was on 2026-10-15, so it is being worked on. The release history shows a steady line of versions, with v1.11.1 from 2026-07-13, 1.11.0 from 2026-06-06 and v1.10.3 from 2026-05-18, and the tag naming is not consistent between a v-prefixed and an unprefixed form, which is a small sign of a project that has been tagged by hand over a long period.

Three things about the release process are visible in the repository. There is a release.md and a publish.md, which is a clear sign that publishing to the various distribution channels is a documented, multi-step procedure rather than something improvised. There is a Dockerfile as well as the Gradle build, so the ranking server has its own containerised deployment path. And there is a .github directory, .dockerignore and an AGENTS.md, which suggests the automation around the project has been brought up to date with current tooling practice even though the game itself is decades old.

The practical advice for a newcomer is to start with the Book of Robocode, read the RoboWiki for the accumulated community knowledge, and treat the API as a small fixed surface to be learned rather than a framework to be explored.

Editorial conclusion

Robocode suits someone learning to program or an experienced developer who wants a small, self-contained problem to think about, and the code it produces is ordinary Java or Kotlin with no framework to learn. It is the wrong choice for a team that wants a shared competitive ranking, because the README says the modern successor, Tank Royale, does not yet have an equivalent of LiteRumble. Before writing a robot, work through the Book of Robocode, and read the licensing terms in LICENSE.txt, since the repository records a custom licence that GitHub cannot classify and the terms matter for anything you publish.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. robo-code/robocode on GitHub