Coding Adventure with Kaggle and Lux AI

Lux AI’s Kaggle 1v1 competition rewards the simplest end condition: finish with more city tiles than the opponent. The core takeaway from this coding run is that a bot can jump from “bottom-tier” to “competitive” with incremental, test-driven improvements—starting from a minimal working submission, then adding just enough strategy to reliably expand city area before nightfall punishes low fuel.

The walkthrough begins by setting up Lux AI locally via Node.js and installing the competition package, then using the provided Python “simple” bot as a baseline. Running “simple vs simple” on a 24x24 map generates replay files that can be inspected through the Lux viewer. That replay-driven loop becomes the development workflow: make a change, run a match, inspect behavior, and iterate—because stepping through full-speed games with logging alone quickly becomes painful.

Early on, the author frames the competitive reality: many teams sit at a single city tile, so building just one additional tile can move a bot from the bottom into a much higher percentile. But strategy code tends to sprawl, so the next move is structural cleanup—extracting repeated logic into helper functions like “get resource tiles,” “get close resource,” and “get close city.” The goal isn’t fewer lines; it’s isolating strategy decisions from mechanics so future expansions don’t turn the agent into an unmaintainable tangle.

With the bot cleaned up, the strategy shifts to expansion. A city tile requires 100 resources, and the bot’s workers carry 100 each, so the author adds logic to build a second city tile adjacent to an existing one. To do that correctly, the code must interpret Lux’s data model: “cities” are collections of “city tiles,” and adjacent tiles belong to the same city. The bot also logs and then derives city tile lists from the city objects, ensuring it can decide when it has enough tiles to stop building.

A major practical bug appears when workers naively navigate onto city tiles: Lux deposits cargo immediately, so a worker can repeatedly cross a city tile, dump resources, then return to refill—stalling the intended build. The fix is to improve movement so workers avoid running over city tiles while heading to a build location. Later, as the bot expands, it adds more workers and more city tiles using global dictionaries that track which worker is assigned to which city tile and which resource tile. It also addresses collisions and “stuck” units by tracking recent positions and applying a random cardinal move when a worker hasn’t changed coordinates over multiple steps.

Finally, the author introduces a simple evaluation harness for hyperparameter tuning: log the number of city tiles at the end of each game (especially watching for runs that end with zero city tiles, which often indicate the city died during night). A small change—searching for build locations within a larger radius—produces a noticeable improvement in average city tiles. The resulting bot scores 656, with clear room to improve via better navigation, smarter fuel management as night approaches, and more robust collision avoidance. The submission process is straightforward: compress to tar.gz and upload to Kaggle, then compare against other teams after matches begin.