Video summary

UNSW Battlecode Launch Stream

Main summary

Key takeaways

Gaming

Storyline / Premise

  • The game is set underwater: a probe lands on the ocean floor, pearls are scattered across the map, and deep-sea dragons (snake-like bots) fight to survive and grow.
  • Each team controls a swarm of dragons via code. Competition lasts four weeks, with bots battling other teams and earning an ELO ranking.

Core Gameplay (what the game is like)

  • Your program (Python/C/C++) controls multiple independent dragon instances.
  • Dragons compete to become the longest by the end of play (500 rounds per match), primarily by:
    • Eating pearls (the only way to increase length).
    • Killing enemy dragons (both die when one intentionally collides head-to-head).
    • Using advanced mechanics: sprint, splitting, and sonar.

Key Additions vs classic Snake

  • Splitting: a dragon can divide into two dragons, each running an independent instance of your code.
  • Communication (sonar): dragons can emit a 32-bit sonar message that travels forward (including through portals) and affects what receives on the other side.
  • Sprint: dragons can move multiple tiles in a single turn by sacrificing length for additional steps.

Match Rules (high-level)

  • Turn structure: within each round, dragons move sequentially by ID (no simultaneous movement).
  • Elimination condition: if a team’s dragons are fully eliminated, that team loses; if both teams eliminate each other in the same round, it’s a draw.
  • Win condition: primarily the team with the longest dragon wins; ties break by total summed length across all dragons.
  • Map: rectangular, with wraparound edges (a torus). Major obstacles mentioned:
    • Kelp (colliding kills you)
    • Portals (teleport to the paired exit portal)

What Dragons Can Perceive (strategy-relevant)

  • Each dragon receives input consisting of the tiles within a 7x7 vision square centered on its head (wrapping around board edges).
  • Vision includes relevant entities: pearls, enemy dragons, heads, portals, kelp, and board geometry.

Movement, Collisions, and Offense

  • Movement: can go forward (continue direction) or turn left/right, but cannot reverse (moving backward causes death).
  • Collision:
    • Hitting obstacles or other dragons results in death.
    • Intentional offensive collision: if your head enters an enemy head, both die that turn (only explicit offense mechanic highlighted).

Major Mechanics You’d Build Strategies Around

1) Sprint (multi-step movement)

  • You can attempt multiple steps in a turn:
    • The first move is free
    • Additional sprint steps cost body segments (length decreases)
  • Important: the order of issued moves matters, especially around kelp and route planning through tight spaces.

2) Splitting (create separate controlled agents)

  • If a dragon is long enough, it can split into two dragons.
  • The “child” direction mentioned is opposite to current facing.
  • The split spawns a fresh instance of your code (no state carried over), so strategy depends on re-initialization and role logic.

3) Sonar (information transfer)

  • A dragon can output a sonar message containing an unsigned 32-bit integer.
  • Conceptually behaves like a beam that travels forward and stops when colliding with the next object, passing through portals.
  • Messages are not restricted to allies: enemy dragons can also receive them, so encoding/decoding must assume adversaries.

4) Pearl Mechanics (growth driver)

  • Pearls spawn based on per-tile countdowns.
  • When countdown hits zero, a pearl attempts to spawn and then the countdown resets to a random value within a configured range.
  • Symmetry fairness: mirrored/symmetric tiles share the same countdown behavior.

5) Death Drops Pearls (secondary strategy)

  • When dragons die, they drop pearls along their body segments (every second segment described becomes a pearl starting from the head).
  • This can be used both offensively and defensively:
    • Deny growth to enemies
    • Re-allocate “potential pearls” toward endgame positioning

Gameplay / Platform Highlights Demonstrated

  • Visualizer usage:
    • Step through games turn-by-turn.
    • Hover tiles for pearl spawn timing and positions.
    • Hover dragons for vision radius and status (length/age/alive).
    • “Follow” to debug one dragon’s behavior at high zoom.
  • Logs & debugging:
    • Filter events by round and by event type (bot output, splits, deaths, pearl spawns/taken, sonar, engine timeouts, etc.).
    • “Indicator string/dots/lines” features are supported for drawing/debugging behaviors (strings explicitly shown; dots/lines mentioned as partially not supported in the demo bot).
  • Replay strategy stealing: you can browse battle replays of teams, including top-ranked ones, and copy ideas (within competitive learning norms).

Event Structure, Ranking, and Match Types

ELO Scrims (how you test bots)

  • Auto scrims:
    • Run every 2 hours on a schedule
    • Match you against two teams, prioritizing teams with similar ELO and who haven’t fought recently.
  • Rank scrims:
    • You choose when to run them.
    • Run 5 games; rating changes depend on outcome and the opponent’s ELO gap.
    • ELO change capped: max amplitude mentioned as 96 per game (up/down).
  • Unranked scrims:
    • Available automatically to all teams if a valid bot is submitted.
    • You choose the maps; useful to avoid wasting rate-limited attempts on maps where your bot is weak.
    • Rate limit: 60 match requests per hour (stated in terms of individual matches/maps).

Grand Final Qualification Path

Sprint (online)

  • Open to anyone worldwide.
  • Prize: $800 (1st), $400 (2nd)
  • Format: seated knockout, matches are best-of-5
  • Sprint maps are new/unseen: you must adapt.
  • Website has a map editor for preparing for unseen maps.

Qualifier (main path to finals)

  • Selects top 10 eligible teams.
  • Format described using a bracket process:
    • Run seated matchups for every bot (details on tournaments/quals page).
    • Round of 16: 8 winners advance directly; from the remaining 8 losers, another bracket selects 2 more to make 10 total.

Grand Final Eligibility Constraints

  • Every team member must be either:
    • studying in Asia Pacific, or
    • a citizen of one of those countries while studying elsewhere
  • and must be high school or university students
  • plus: each member uploads a resume for sponsors.

Key Tips / Strategies Emphasized

  • Treat unseen maps carefully: sprint uses maps not seen previously; the map editor exists to help test adaptation.
  • Build efficient pathfinding and portal/route logic: demo notes mention:
    • choosing good pearl locations,
    • traversing portals efficiently,
    • killing enemies via head-on collisions.
  • Respect resource constraints:
    • Each dragon gets limited computation per turn (described as ~25ms rough limit, implemented via instruction/time accounting).
    • Avoid expensive operations (strings, excessive work).
  • Use sandboxing for server-accurate testing once ready:
    • Iterate locally without sandbox first; then optimize using sandbox to fit server limits.

Developer Workflow (CLI + Website)

CLI Quick Setup

  • Install via pip:
    • pip install UNSW battle code
  • Initialize a project (VS Code project template shown).
  • Run locally with:
    • UNSWBC run specifying:
      • map
      • bot folder

Local Replay + Visualizer

  • After running, open the generated replay file.
  • The VS Code extension supports replay playback and turn stepping.

Server-Condition Testing

  • Use a sandbox mode flag (mentioned as -d sandbox) to simulate server time/instruction limits.

Submission to Website

  • Obtain API token from team page.
  • Submit bot using CLI:
    • UNSWBC submit <bot>
  • Submitted bots remain as a permanent record; choose which one is active for future matchmaking.

Security Note (Responsible Disclosure)

  • The organizers “encourage” trying to find vulnerabilities, but under responsible disclosure:
    • A separate sandbox instance is intended for safe experimentation.
    • Prize mentioned for the most severe reported vulnerability.

Gamers / Sources Featured (named at the end)

  • Kelvin
  • Nan
  • Martin
  • Peter
  • In-server aliases: Retrograde and Limb K
  • Sponsor/source mentions: Jump HRT and UNSW School of Computer Science and Engineering
  • Tournament/team demo references: bit shift and my cactus died (appearing in live demo battles; no further creators named)

Rate this summary

Your feedback will help improve summaries.

Improve this summary

Reprocess with a stronger model when the summary feels incomplete or inaccurate.

Pro

Translate summary in another language

Pro

Ask questions to this video

Chat for follow-up questions, clarifications, and source-backed answers.

Coming soon

Share this summary

Original video