Generalize the classic-Robocode shim so the hosted bot's main class, jar, extra
classpath and data directory are configurable (SHIM_BOT_CLASS / SHIM_BOT_JAR /
SHIM_EXTRA_CP / SHIM_DATA), with DrussGT kept as the default so every existing
script, fixture and generated bot dir behaves identically.
- LegacyBotBridge: generalized bridge (DrussGTBridge kept as an alias).
- BotHost: (mainClass, jar, extraJars, dataDir); disableShield -> generic
disableStaticBoolean.
- ClassicPeer: implement ITeamRobotPeer; synthesize StatusEvent each turn;
make move/turnBody/turnGun/turnRadar the immediate (turn-ending) variants;
guard re-entrant execute() from event handlers; record delivered events.
- make_botdir.sh / run_bridge_battle.sh / run_smoke.sh generalized, legacy
invocations unchanged; generated launcher uses a per-process mktemp data dir
so concurrent bots/battles cannot clobber one classic data directory.
Validated 35 legacy bots against a real Tank Royale battle (2 rounds vs sample
SpinBot): 28 usable (27 effective + DrussGT), 5 weak-but-playing, 2 failing.
Adds robots.json (manifest) and LEGACY_BOTS.md (how-to, status, missing-API
costs). No third-party jar is committed.
The unmodified DrussGT.jar connects, wave-surfs, fires and beats every
adversary we have. 5 rounds each, all rounds won:
SpinBot 542-16, Corners 823-4, Crazy 604-0, RamFire 900-0,
ModularBot 506-72.
It is genuinely surfing, not drifting or stalling. Movement statistics
against the classic captures, same metrics, same analyzer:
opp perp TR/classic reversing TR/cl median range TR/cl
SpinBot 0.967 / 0.962 0.466 / 0.464 462 / 402
Corners 0.894 / 0.920 0.462 / 0.419 520 / 504
Crazy 0.841 / 0.829 0.527 / 0.439 370 / 378
RamFire 0.762 / 0.651 0.533 / 0.417 326 / 283
ModularBot 0.956 / - 0.466 / - 453 / -
Every round starts moving within 3-11 ticks and runs at 75-82% full speed.
Implemented: the classic remaining-quantity motion model (delegated to the
TR Bot's own Nat-Pavasant model - identical constants: accel 1, decel -2,
max 8, body turn 10-0.75|v|, gun 20, radar 45 - so getDistanceRemaining and
getTurnRemaining are exactly self-consistent with what is emulated); event
synthesis with classic ordering; bullet identity via object identity; gun
heat; rounds; radar cadence; firing translation; and the ThreadManager
landmine is killed by installing a no-op IThreadManagerBase in
ContainerBase.instance (verified: without it 'RobotException: ThreadManager
cannot be null!' kills the bot thread; with it the write succeeds).
Also adds TrBattleCapture, an observer that dumps per-tick state in the SAME
JSONL fixture format as the classic capture, so legacy bots can be captured
from Tank Royale battles too.
HONEST DIVERGENCES (README section 5.9): the TR server moves along the
PRE-turn heading and then turns, while classic aligns displacement with the
POST-turn heading, so the analyzer's conversion error is ~1.5 deg rather than
0.000 deg; distanceRemaining decrements by target speed rather than actual
distance; collision clamping differs; BulletMissedEvent can fire less often
because age-expiry has no TR event; bulletId is a local temp id;
StatusEvent/onPaint/SkippedTurnEvent are never delivered. Physics fidelity
diverges by construction - expect to retune.
EnergyDomeWorker (the bullet shield) is off by default: its precise
bullet-detection warm-up makes round 1 up to 79% stationary vs 35% in
classic. Rounds 2+ match classic closely with it on, but the pure surfer is
the consistent path. DRUSSGT_SHIELD=1 re-enables it.
Jars remain out of git.
The question was whether we can fight a genuine legacy leader bot in Tank
Royale. Answer: the API side is now PROVEN, not estimated.
KEY FINDING: the classic robocode.* API is a thin delegation layer over a
public seam. javap -c shows AdvancedRobot forwarding every call to
_RobotBase.peer (IBasicRobotPeer/IAdvancedRobotPeer), and _RobotBase.setPeer
is public final. So we do NOT need to reimplement the API: we reuse the
genuine robocode.jar and implement only the 75-method peer interface.
Consequences:
- DrussGT's 22 sources compile against the real API with ZERO unresolved
symbols. (The literal 22-file javac fails only on two PRE-EXISTING
duplicate classes - GFRange and Indice are declared both inline in
DrussGunDC.java and as standalone files - and the 6 classes that ship
without source. The jar supplies all of them, so a shim never cares.)
- Runtime smoke test PASSES: the unmodified DrussGT.jar is loaded through a
child URLClassLoader and driven for 200 synthetic ticks, emitting movement
intents every tick and 169 fire requests, with its thread surviving.
This is the cheap path to the 'final boss', and it also unlocks the whole
roborumble archive rather than one bot.
Traps found by measurement:
- ScannedRobotEvent's constructor order is (name, energy, bearing, distance,
heading, velocity) - NOT heading-before-bearing. The wrong order silently
yields distance=0, an immediate KD-tree insert and an NPE in
EnemyMoves.predict; it hung the first smoke run.
- RobocodeFileOutputStream has a hard engine dependency (resolves
IThreadManagerBase via ContainerBase) and throws 'ThreadManager cannot be
null!' outside the engine, killing the bot thread. Reached from DrussGT's
own contain() error logging, so it must be stubbed.
- robocode.RobotDeathEvent is required and was NOT in the predicted API list.
- Bullet.equals() is genuinely called for bullet identity, not just getters.
REMAINING WORK (README section 5): coordinate rotation DONE, execute()->tick
bridge DONE and proven, ThreadManager fix scoped. The main open item is the
classic motion model (setAhead distance semantics vs TR speed), estimated
1-3 days, plus event synthesis/ordering, gun heat, bullet identity, round
and radar cadence, and firing translation. NO API UNKNOWNS REMAIN.
Physics fidelity will still diverge from classic - expect to retune.
Jars stay out of git (blocked by tools/robocode_shim/.gitignore); the
genuine robocode.jar and DrussGT.jar are referenced from /tmp via
ROBOCODE_JAR / DRUSSGT_JAR.
SirStone