# Classic-Robocode leader movement fixtures — DrussGT

Captured **real, unmodified DrussGT 3.1.4159** movement from classic Robocode
1.9.5.5 and converted it to the project's shared JSONL fixture format.

These are **movement-pattern fixtures for gun testing**, not runnable opponents.

## How the data was obtained

| Artifact | Source | Result |
|---|---|---|
| Classic Robocode 1.9.5.5 (full install, 20,431,686 bytes) | `https://sourceforge.net/projects/robocode/files/robocode/1.9.5.5/robocode-1.9.5.5-setup.jar/download` | HTTP 200 |
| `robocode-1.9.5.5.zip` | same SourceForge dir | HTTP **404** (does not exist) |
| `net.sf.robocode:*` 1.9.5.5 (api/core/battle/host/samples/repository/ui/sound/roborumble) | `https://repo1.maven.org/maven2/net/sf/robocode/` | HTTP 200 (available; not needed once the full installer was fetched) |
| DrussGT 3.1.4159 jar (159,289 bytes, md5 `5cd6015dcc6d6da8a7e6aeecb1fec211`) | `http://robocode-archive.strangeautomata.com/robots/jk.mega.DrussGT_3.1.4159.jar` | HTTP 200 |

The Robocode "setup jar" is a plain ZIP of the full installation
(`libs/`, `robots/`, `battles/`, javadoc). Extracting it is enough to run the
programmatic control API headlessly. On Java 21 the engine needs
`-Djava.security.manager=allow` and four `--add-opens` flags (see
`tools/robocode_fixture_capture/README.md`); Java 17/11 also work.

**The DrussGT jar and classic Robocode are third-party redistributables and are
kept OUT of the repository** — they live only under `/tmp/robocode/`.
`tools/robocode_fixture_capture/capture.sh` re-downloads them on demand.

## Capture mechanism

`tools/robocode_fixture_capture/Capture.java` uses the classic Robocode control
API — no GUI:

- `robocode.control.RobocodeEngine` + `BattleSpecification` (800×600, 20 rounds,
  gun-cooling 0.1, inactivity 450) run the battle headlessly.
- A `BattleAdaptor` receives `onTurnEnded(TurnEndedEvent)` every turn.
- `event.getTurnSnapshot().getRobots()` yields `IRobotSnapshot[]` with `getX()`,
  `getY()`, `getBodyHeading()`, `getVelocity()`, `getEnergy()` for every robot,
  every turn — true positions, no fog of war.
- The fallback "spy robot" approach was **not needed**; the observer API worked.
- Robots captured: `e* = jk.mega.DrussGT`, `s* = the opponent that fought it`.

## Coordinate conversion (exact)

Tank Royale and classic Robocode share the **same positional axes** (origin
bottom-left, +x right, +y up), so `x`/`y` are copied unchanged. Only the angle
system differs:

- classic: `0° = North (+y)`, positive rotation **clockwise**
- Tank Royale: `0° = East (+x)`, positive rotation **counter-clockwise**

The control-snapshot API returns headings in **radians** (per the official
javadoc: *"Returns the body heading of the robot in radians"*), in the classic
convention. Conversion used:

```java
double classicDeg = Math.toDegrees(rawBodyHeadingRadians);   // 0=north, clockwise
double tankDeg    = (90.0 - classicDeg) % 360.0;             // 0=east,  counter-clockwise
if (tankDeg < 0) tankDeg += 360.0;
// x, y: unchanged
```

Equivalently, in radians: `tankRad = PI/2 - classicRad`.

**Validation:** for every consecutive tick within a round, the measured
displacement direction of DrussGT was compared with the direction implied by the
converted heading + signed velocity. Mean angular error is **0.000°–0.001°** on
every fixture — the conversion is exact, and it doubles as proof the fixtures are
real recorded motion rather than fabricated data.

## Fields

Following the mandated shared format exactly:

```
{"meta":{"adversary":"...","source":"classic-robocode","perfect_info":true,"arena":{"w":800,"h":600},"note":"..."}}
{"tick":0,"ex":...,"ey":...,"eh":...,"es":...,"ee":...,"sx":...,"sy":...,"sh":...,"ss":...,"se":...}
```

- `eh`/`sh`: **Tank Royale** heading in degrees (0=east, CCW).
- `es`/`ss`: **signed** velocity in px/tick (`getVelocity()`; negative = moving
  backwards relative to body heading).
- `ee`/`se`: energy (0–100).
- `tick`: **continuous global counter across all rounds** in the file; positions
  teleport at round boundaries. Round boundaries are listed in
  `drussgt_meta/<file>.jsonl.rounds.json` (`startTick`, `count`).

## Files

| File | ticks | rounds | bytes | enemy (`e*`) | shooter (`s*`) |
|---|---:|---:|---:|---|---|
| `drussgt_vs_spinbot.jsonl` | 5002 | 20 | 741,720 | DrussGT | sample.SpinBot |
| `drussgt_vs_ramfire.jsonl` | 3240 | 20 | 481,176 | DrussGT | sample.RamFire (rammer) |
| `drussgt_vs_crazy.jsonl` | 9025 | 20 | 1,335,519 | DrussGT | sample.Crazy |
| `drussgt_vs_corners.jsonl` | 4975 | 20 | 732,806 | DrussGT | sample.Corners (wall-hugger) |
| `drussgt_vs_drussgt.jsonl` | 6555 | 2 | 965,834 | DrussGT | DrussGT (mirror) |
| `contrast_straightline.jsonl` | 1451 | 1 | 213,049 | trivial.StraightLine | sample.SittingDuck |
| `contrast_stationary_sittingduck.jsonl` | 1451 | 1 | 213,117 | sample.SittingDuck | sample.SittingDuck |

`drussgt_meta/` holds the round-boundary sidecars; it is deliberately outside the
`*.jsonl` namespace.

## Statistics — evidence this is real DrussGT movement

All numbers measured from the fixtures above.

| fixture | mean speed | %ticks speed≥7.5 | %ticks speed<0.5 | %neg. velocity | mean |Δheading| | %|Δh|>5° | median dist | perp frac | radial frac | mean\|sin\| |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| drussgt_vs_drussgt | 5.26 | 41.1% | 6.6% | 45.7% | 1.29° | 8.2% | 526 | 0.951 | 0.001 | 0.972 |
| drussgt_vs_spinbot | 6.59 | 70.1% | 6.7% | 46.4% | 1.81° | 9.4% | 402 | 0.962 | 0.001 | 0.971 |
| drussgt_vs_ramfire | 6.65 | 72.3% | 4.6% | 41.7% | 3.00° | 14.9% | 283 | 0.651 | 0.013 | 0.898 |
| drussgt_vs_crazy | 6.16 | 66.8% | 13.7% | 43.9% | 2.01° | 8.3% | 378 | 0.829 | 0.010 | 0.934 |
| drussgt_vs_corners | 6.01 | 58.6% | 9.2% | 41.9% | 2.09° | 12.5% | 504 | 0.920 | 0.004 | 0.964 |
| **contrast straight-line** | 6.28 | 75.3% | 18.4% | **0.0%** | 1.66° | 16.6%* | 239 | **0.086** | **0.752** | 0.373 |
| **contrast stationary** | **0.00** | 0.0% | **100%** | 0.0% | **0.00°** | 0.0% | 210 | n/a | n/a | n/a |

`perp frac` = fraction of moving ticks whose movement is within 30° of
perpendicular to the enemy→shooter line (`|sin δ| > 0.866`); `radial frac` = within
30° of that line (`|cos δ| > 0.866`).

\* the straight-line bot only ever turns 10°/tick in place at a wall, giving the
bimodal heading-change distribution below — it never arcs.

**Speed distribution** (fraction of all ticks per px/tick bin):

| bin | 0 | 0.5-1 | 1-2 | 2-3 | 3-4 | 4-5 | 5-6 | 6-7 | 7-7.5 | 7.5-8 |
|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| DrussGT vs SpinBot | .067 | .006 | .024 | .033 | .024 | .042 | .030 | .052 | .020 | **.701** |
| straight-line (contrast) | .184 | .000 | .009 | .009 | .009 | .009 | .009 | .009 | .009 | **.753** |
| stationary (contrast) | **1.000** | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

**Heading-change-per-tick distribution** (fraction, degrees):

| bin | 0-0.5 | 0.5-1 | 1-2 | 2-3 | 3-5 | 5-7 | 7-10 | 10-11 |
|---|---:|---:|---:|---:|---:|---:|---:|---:|
| DrussGT vs SpinBot | .439 | .113 | .122 | .057 | .175 | .035 | .044 | .015 |
| DrussGT vs Crazy | .389 | .096 | .117 | .075 | .240 | .033 | .041 | .010 |
| straight-line (contrast) | **.833** | 0 | 0 | .001 | 0 | 0 | 0 | **.166** |
| stationary (contrast) | **1.000** | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

Interpretation: DrussGT spends most of its time at full speed, frequently
**reverses** (≈42–46% of ticks have negative velocity — stop-and-go surfing), and
its movement is strongly **perpendicular** to the opponent (mean |sin| ≈ 0.90–0.97,
radial fraction ≈ 0.001–0.013) while actively controlling range (median distance
283–526 px, varying by opponent). The contrast bots are stationary or move
radially at constant heading with no reversals. The difference is in the numbers,
not asserted.

## Caveats (read before using these as an opponent)

1. **OPEN-LOOP.** This is recorded trajectory data replayed into a gun test.
   Replayed DrussGT does not react to bullets fired by *our* bot, so our gun's
   score against these fixtures is **optimistic**. This is a *movement-pattern
   benchmark*, not an opponent. It tests whether our aiming math can lead and
   predict leader-class motion; it does not test whether we can out-duel DrussGT.
2. **PERFECT INFORMATION.** Classic Robocode's battle observer reports true
   positions every turn. Our live bot's `WorldState` is stale between radar scans.
   Fixtures from this source are therefore optimistic relative to live play in
   *two* ways (open-loop + no sensor latency/fog). A gun that performs well here
   may perform worse live.
3. **Bullet-shielding is excluded.** Against predictable guns (`sample.Walls`,
   `sample.TrackFire`) DrussGT's EnergyDome shield engages and it **stands still**
   — a real DrussGT behaviour but not movement. Those captures were rejected;
   only opponents that make DrussGT surf (SpinBot/RamFire/Crazy/Corners and a
   DrussGT mirror) are included. DrussGT's source was **not modified** — the
   shipped jar is used as-is.
4. **Rounds are concatenated.** `tick` is continuous, so positions jump at round
   boundaries. Split on the boundaries in `drussgt_meta/*.rounds.json` (or on
   impossible displacements) before computing anything displacement-based.
5. **Signed velocity.** `es`/`ss` may be negative. Reconstruct motion as
   `x += es*cos(radians(eh)); y += es*sin(radians(eh))` — do **not** use `abs(es)`
   with `eh` unless you also flip `eh` by 180° for negative ticks.

Reproduce with `tools/robocode_fixture_capture/capture.sh`; validate/analyse with
`tools/robocode_fixture_capture/analyze.py`.