Rules

General Rules

• • Competition Format (2024 edition):

    • The microRTS AI competition is organized around a series of tracks, each bot can participate in one or more tracks, each of which might have a different winner (see below for the list of tracks).

  • Each track will be run as a round-robin tournament, where each bot will play against each other in a collection of different maps.

    • We will try to do as many full rounds of the round-robin tournament as possible in order to get statistically significant results.

  • Maps:

    • The competition will run using twelve different maps. All of those are public this year:

      • melee14x12Mixed18.xml

      • 16x16/basesWorkers16x16A.xml

      • basesWorkers32x32A.xml

      • barricades24x24.xml

      • 8x8/FourBasesWorkers8x8.xml

      • 16x16/TwoBasesBarracks16x16.xml

      • NoWhereToRun9x8.xml

      • chambers32x32.xml

      • GardenOfWar64x64.xml

      • (2)Benzene.scxA.xml

      • (2)Destination.scxA.xml

      • (4)Andromeda.scxB.xml

    • Four of them are hidden, and will only be revealed after the competition (four new hidden maps will be created for each new competition edition). But they will range in sizes between 8x8 to 64x64, like the public maps.

      • The motivation for having hidden maps is to avoid participants from hard-coding strategies for specific maps, which goes against the spirit of the competition. However, it would have the implication that the competition organizers will not be able to submit any AIs, since they would have an unfair advantage. For that reason, and to allow organizers to participate, results in the hidden maps will be reported just for scientific purposes, but will not be used to rank the submitted bots.

      • See this page for a list of public/hidden maps in previous competitions

    • All the different tracks will use the same maps.

    • Results will be published per map, as well as a summary of the performance across maps.

  • Game Format:

    • Bots will play full-game, two-player matches.

    • Game length: games will run up to a fixed number of cycles (after which the game will be considered a tie). The maximum number of cycles will be (Thanks to Nicolas Barriga from the University of Alberta for determining these numbers):

      • 8x8 maps: 3000 + 1000 (new anti-draw time gap) = 4000

      • 16x16 maps: 4000 + 1000 =  5000 

      • 24x24 maps: 5000 + 1000 = 6000 

      • 32x32 maps: 6000 + 1000 = 7000 

      • 64x64 maps: 8000 + 2000 = 10000 

      • > 64x64 maps: 12000+  2000 = 14000 

    • Each bot will be given a computation budget of 100 milliseconds per game cycle.

    • The competition will be run in multiple computers, but in each match, both bots will run in the same computer, so that none of them gets any advantage from running on a faster computer.

    • Threads are allowed, but once the computation budget of the frame is over, bots need to stop all threads, in order to allow the other bot to make full use of the CPU. Bots that keep threads running on the background that have non trivial CPU usage will be disqualified.

    • Bots that consistently exceed the 100 millisecond limit per game cycle will be disqualified (where "consistently" will be determined by the human organizers). To prevent from Java's garbage collector to interfere with timing, the garbage collector will be called right before calling each of the two bots at each game cycle.

    • Games where a bot crashes will be considered a loss.

    • The game will be configured like this:

      • The UnitTypeTable that will be used is: VERSION_ORIGINAL_FINETUNED for the "classic" and "partial-observability" tracks, and VERSION_NON_DETERMINISTIC for the "non-deterministic" track. 

      • The move conflict resolution will be configured to MOVE_CONFLICT_RESOLUTION_CANCEL_BOTH for the "classic" and "partial-observability" tracks.

      • If you are using the microRTS graphical front end, these configurations are called "Finetuned-Both" (for the "classic" and "partial-observability" tracks).

  • Other Rules:

  • The competition is open source: to be accepted, participants need to submit the URL where the source code of their bot can be downloaded. This is necessary upon submission.

    • microRTS is built in Java and the easiest way to create a bot is using Java. But participants are welcome to write proxybots that open sockets to modules written in other languages (but remember that once the computation budget of one game cycle is over, bots need to stop all activity to allow the other bot full access to the CPU). For example, C++ or Python bots have been submitted in the past.

    • All the replays from the games in the competition will be made available immediately after the competition.

    • The competition will be run on Linux machines running Ubuntu.

    • In addition to the competition entries, four base AIs will be used as baselines:

      • RandomBiased

      • POWorkerRush

      • POLightRush

      • NaiveMCTS

    • Top performing AIs from previous editions of the competition might be entered as reference points (to measure improvement from previous years).

    • Finding and reporting microRTS bugs is welcome and encouraged, but exploiting unreported bugs for gaining an advantage will result in disqualification. Remember that the goal of this competition is to advance science, not to win.

    • Learning: in order to encourage submissions that are adaptive we will allow for a limited form of learning. The very first time an AI plays a new map, the agent will be given 1 hour of time to do whatever it wants with such map (e.g., playing simulations on it to discover good strategies, etc.). After that time is over, the AIs will be allowed to write the results to disk (a "write folder" will be given to them as a parameter, where they can write anything they want). At the beginning of each subsequent game, the agents will be allowed to read from that folder. No subsequent writing will be allowed to that folder, to ease the competition execution management.

  • Publishing:

    • Making a top-playing bot surely requires inventing or extending some algorithm in an interesting way. We encourage you to submit a paper with the techniques used in your bot to an AI/Game AI conference or journal.

    • If time constraints allow, we would like to write a paper with the results of the competition, where we will ask authors of the bots to contribute some sections to the paper and be co-authors. We did this for the 2017 competition (paper here), and would like to repeat it again.

Competition Tracks

• The microRTS "classic" track:

  • The focus of this track is the basics of AI techniques that must perform in real-time, with simultaneous and durative actions, and that scale up to full RTS games.

  • This track will feature a deterministic and fully-observable environment.