From Gladiabots Wiki
Jump to: navigation, search

This page explains the game in excruciating detail. If you don't understand some terms, that's entirely understandable. This page prefers correctness over ease of understanding. Most of the information here is not critical for a player to know, but where possible, programming terms are used that you can google or ask other players about. If you want a more approachable look at the mechanics, look at the basics.

Team Setup

There are 4 bot classes. In sandbox, you can use any team setup, in tournaments it can be specified by the tournament creator and in all other cases, a bot class can only make up 35% of your setup, except for assaults, which can be up to 100% of your team.


Gladiabots is a deterministic and symmetric game. This means that maps are always symmetric (rotationally or mirrored along the middle axis) and if the two teams have the same Team Setup and AI, the match will always be draw, with both teams executing the exact same actions and missing/hitting the exact same shots.


Gladiabots looks like a real-time game when you hit play, but it's actually a turn-based simulation running at 40 turns per second. Each bot has an instantiation order, decided by the map. This means that the first bot of each team will evaluate their AI before the first turn, the second bot of each team will evaluate together before a subsequent turn, etc. This means in effect that two allies never evaluate their AI before the same turn, because the evaluations are in effect staggered.


When you click a bot during a match and look at the debugger, there's a blue bar on the bottom that will tell you how many turns you have left to go before you will evaluate your AI. Pausing the game will pause it in between turns, AFTER the AI evaluation has run for any bots that evaluate before the next turn. This means that when your bot has just evaluated its AI, the blue bar will be full. If you want to make sure that you pause exactly after the AI of a certain bot is evaluated, before the action is executed, use the "next tick" button with that bot selected.


A tick is generally considered to be the combination of one AI evaluation followed by 10 turns (0.25 seconds) of simulation. Here is the order of operations taken in a tick:

  • The AI is evaluated until a valid action is found
  • The action is turned into a specific instruction
  • For the next 10 turns, that instruction is executed


An AI is a graph structure built from nodes and connections between nodes.

Action and Condition nodes are in effect search queries (not dissimilar to SQL queries for example) that are executed. Tagging and counting actions will execute immediately, during AI evaluation and subsequent nodes can see the result of their actions. Non-counting, non-tagging actions will be turned into instructions to be performed in the next 10 turns.

Connectors serve no purpose other than to let you split one connection line into multiple.

Sub-AIs are basically equivalent to taking the nodes inside and copying them over to the spot that sub-AI node is.

Node Count

In campaign, ranked matches and private matches, you are allowed to deploy 500 nodes per bot. In sandbox, you are allowed to deploy as many as you want and in tournaments, you are allowed as many as the tournament organizer specifies.

The only nodes that count towards your node count are actions and conditions. For sub-AIs, each sub-AI node placed will add the node sub-total of that sub-AI to the AI it's placed in (so if you place the same sub-AI twice, it will be counted twice).


When an AI is evaluating, a depth-first graph traversal is started, starting at the root node. Conditions and actions can fail or succeed. Failed conditions will stop traversal from going past it. Any node is only ever traversed once, even if multiple connections are connected to it (but it still matters due to failed conditions invalidating one of the connections). Children are traversed in anti-clockwise order, starting from the 12 o' clock (upwards) direction. Behavior for connecting lines that are the exact same direction or directly upwards is undefined and should not be relied upon. Whenever a non-tagging non-counting action node succeeds, evaluation is immediately stopped and that action turned into an instruction.


The debugger will show nodes that weren't traversed as translucent and ones that succeeded or failed as opaque. Succeeded nodes will have a green check mark, while failed nodes will have a red cross. This way, you can manually go through evaluation and see exactly what happened in the previous tick.

Actions and Conditions

Actions and Conditions are in effect search queries (not dissimilar to SQL queries or other query language instructions) that either fail or succeed and produce a result. Conditions will allow traversal to pass through as a result, tagging and counting actions will immediately execute a state change as a result and action nodes will stop AI evaluation and their result is an instruction carried out in subsequent turns. Each query has a target, target filters and a target sorting order selector or a threshold parameter.

Fails are produced when a valid target is not found, results are produced when a valid target is found.


Targets are a type of entity list, in which to search. This ranges from different bot targets to resources to special entities like force fields. Each interactable object on the map is an entity. Some entities are in multiple entity lists, for example enemy bots are both in the enemy bot list and the general bot list.


Filters will exclude items from an entity list. For example, the "short range from me" filter will exclude any entities in the list that aren't at short range of you. Filters can have different logical combinators: you can negate a specific filter or you can choose whether to AND or OR the conditions in the same filter group. Different filter groups are always combined with the AND combinator (this is all made more clear when you read the text produced).

Filters always look at the information of the previous turn, except when it comes to tags and counters.

Sorting and Conditions

Conditions have a threshold parameter. This means that you can set a threshold for how many search results you want (for example, only succeed when at least two targets are found). The "exists" parameter is exactly the same as the "> 0" parameter and the "does not exist" parameter is the same as the "= 0" parameter. For the comparison parameters, you can compare to any number or any counter (this is very powerful).

Actions will pick just one of the targets and they will do so by first sorting the entity list and picking the top item according to the sorting order selector. For example, entities can be sorted by how close or far they are to the center. If two entities are sorted into equal positions (for example, equally far from the center), a secondary sort is performed, which will sort them by how close they are to the bot that is evaluating currently.


The result of a successful non-tagging, non-counting action is an instruction to be executed in subsequent turns. An instruction only has a specific target and a type. This means that filters and sorting are only calculated at evaluation and the actual instruction will carry on targeting the same target the entire time (unless that target disappears, like with a dying/respawning bot or a resource being picked up, in which case the instruction does nothing instead). This also means that if a bot walks out of range in between evaluations and you are firing at bots in range, it will keep shooting at that target. In this way, it's possible for a sniper to miss a shot. Another example: if you move towards the closest bot, but the closest bot changes between evaluations, it will keep moving to the original bot until the next evaluation.

The following types of instructions are in the game (for any entities that are valid targets):

  • Wait
  • Approach an entity
  • Flee from an entity
  • Attack an enemy
  • Capture an entity
  • Score a resource

Secondary interactions

Some actions generate immediate 0 duration secondary interactions. Here's a list of them:

  • There is no "drop resource" instruction. Instead, the action creates a wait instruction and a secondary "drop resource" interaction
  • When a "capture resource" instruction is targeted at a resource within 0.5 meters, a "pick up resource" interaction is created
  • When an "attack enemy" instruction is generated after the correct aiming period, a secondary "shoot" interaction is generated

Edge Cases

Attack and Hit Chance

Attacks go through several phases: aiming, firing and cooldown between shot volleys. Whenever a shot is ready to be fired, an attack interaction will be generated on the next turn, provided the bot is still instructed to attack. This means that in reality, bots fire 1 turn AFTER the aiming turns. This means that a sniper will fire on the 121st turn (or 13th tick), not the twelfth, but the second shot will occur on the 241st turn (or 25th tick), because the shot secondary interaction doesn't interfere with that turn's attack instruction.

Hit chance is a random hit percentage generated at time of the shot interaction. Bullets travel at 40 meters per second. This means that even if the enemy steps out of range during the travel of the bullet, it will still hit. In the past, the game used a precision counter, but this is no longer the case, shot chances are now entirely random.


  • At the very first turn of the game, all bots are detected as executing the wait instruction
  • If a bot is moving to an object that it can reach within the current tick, it will move there and idle for the rest of the tick. This action will still be detected as moving, even if the unit has already started the tick at the destination and does not move at all.
  • The closest 2 bots can get to each other is restricted by the collision model. The collision model of a bot is a circle with a radius of 0.3 meters for Assault, Shotgun and Sniper and 0.4 meters for Machinegun.
    • TODO: add collision information: when can bots be pushed and by who and when can't they?
    • TODO: when can bots be pushed out of force fields? Is it when you move towards the force field instead of the bot?
  • TODO: Verify: If a bot is catching a resource, it will move to that resource until it is within the range where it then picks up the resource and goes into idle. While moving to the resource, it will be detected as moving to the resource. However, on the tick that it picks up the resource, it will be detected as idle unless it picks up the resource at the very end of a tick.
  • Scoring with a resource follows similar rules to catching a resource, with the difference being that it moves to the base instead of a resource.
  • Both catching and scoring with a resource can be done 0.5 meters away from the resource or base.
  • If bots from different teams are close enough to pick up the same resource and try to do so, neither one will do so, and they will idle instead.
  • Both aiming and attacking are detected as attacking. There is no way to detect the difference.
  • Capturing a base is different from moving to it, because it idles when the base is closer than a certain distance (TODO: what's that distance? 1.5 meters?)
  • Resources that are picked up disappear from the entity lists, but retain their tags
  • Resources that have been dropped can't be picked up again by the same bot in the next 4 ticks (TODO: does it show as waiting or catching during this period?)
  • There is no "turn" instruction, bots will immediately move in the other direction (even if the animation can make you think otherwise)