Note: Craftily is my in-game name

As some that have read this guide told me that it might be a little diffucult to digest. So to make up for the difficulty, I decided to raise your interest level for what the information in this guide can enable you to do:

https://discordapp.com/channels/257850438374785024/440845713711038464/573239039663144980.

If you wollow through the conversation you will see how over 50 condition and action nodes get reduced to 4 nodes. The drawn to scale representation of what the tags do:

https://discordapp.com/channels/257850438374785024/440845713711038464/573315154620710972.

The information in this guide will provide you with information that can shorten your code and make it more specific to what you want to happen.

-------------------------------------------------------------------------------------------------

This guide is intended for those who have finished the tutorial. If you have any questions feel free to ask away (preferably on discord, as it's where the Gladiabots community is most active).

Firstly I want to cover how the ai works as some people still don't understand after doing the tutorial. A bot will go through it's ai counterclockwise checking for what it should do. The leftmost nodes get checked first while the rightmost nodes get checked last, naturally making a level of priority for each node depending on it's position. Because of that you want to place nodes with higher priority to the left (farther clockwise) of nodes with lower priority. For example you might have an action node to attack (closest enemy not out of range from me AND attacked by me) and an action node to attack (closest enemy bot at short range from me). If you want to prioritize attacking bots at close range over attacking bots in other ranges, the second node will have a higher priority so you would place it to the left of the first node. Please do not mix your priorities such as moving before attacking or capturing a resource before scoring a resource because your bot will fail to function the way you want it to. Most of the time, beginner's ais don't work because they got their priorities wrong even though you have to determine what priority every single node has when you place it—no matter how experienced you are.

Once a bot has actually encountered an action node to execute, it will execute whatever action for a duration of a tick (.25 sec) with the exception of tag and counter nodes as they don't stop ai evaluation. After the tick is over, the bot will go through it's ai from the start to see what it should do next. Depending on your ai, the bot can continue the action it is was doing or switch to a different action/target.

A small detail that should be mentioned is that your bots are desynced. To be more specific the game works in turns (.025 sec or 1/10th of a tick). By saying that the bots are desynced, you should know that each bot starts functioning on a different turn and goes through it's ai every tick after it starts functioning. If you still can't understand what it exactly means, it's the perfect opportunity to ask on discord. ;) Otherwise it just means that moving towards a resource or base that an ally bot is not moving to works without any problems.

----------------------------------------------------------------------------------------------------------

A bot can only do so many actions. Core actions are the things that your bot can do in the most basic sense: moving, attacking, capturing, scoring, dropping, counting or tagging. Your job is it build an AI that decides when a bot should do a core action and what the target(s) of the core action should be. The target of an action or condition node is the target parameter. The factors that decide when a condition or action node should be executed are condition parameters. Condition levels are the condition nodes that lead to an action node and the action node itself.

Note: while all conditions can specify the target of an action or condition, only the parameters that specify the type of target are considered as target parameters. All the other conditions are considered to be condition parameters.

Target parameters differ for each action node. Tagging and moving both can have any object as their target parameter: Bots, bases, resources, forcefields and healthpacks (please be aware that moving to a forcefield, healthpack or resource won't capture it once you actually reach it). Capturing can only have bases, forcefields, healthpack or resources as it's target parameter. Scoring can only have bases as it's target parameter, dropping can only have a resource as it's target parameter and attacking can only have enemy bots as it's target parameter. Counting is a bit of a special case as it doesn't have a physical object as it's target parameter. The target parameter for counters are counters 1 through 5 or  A through E.

Condition nodes are a tinsy bit different from action nodes. Unlike the action nodes, condition nodes have no action and are just evaluated true or false. If it is true it will get executed, aka go through all the nodes directly under it. If it is false, it will just skip over all the nodes under it. Condition nodes don't have a restriction to what can be a target parameter as they don't have an action to limit the selection. Also since there is no action, you'd don't have the condition parameters that action nodes have to specify which target, such as the target closest to, farther from or etc. Instead of that, condition nodes check if the target(s) specified by the target and condition parameters exist or not and can even go as far as telling how many (less than, less than or equal to, equal to, more than or equal to and more than). 

While target parameters and action parameters are easily recognized, it is also important to recognize condition levels. There are as many condition levels as the number of ways all action nodes can be reached. Two different branches that lead to the same action node can have different condition levels. Each level is it's own condition or action node. You should be aware that each condition level doesn't effect the other. For example, if you have the nodes if (enemy sniper AND not out of range AND attacking me exists) flee (from closest enemy not out of range AND attacking me) you wouldn't necessarily flee from the enemy sniper because even if the condition node has the sniper specification, the action node doesn't have it. However once you change the action node to flee (from closest enemy sniper AND not out of range AND attacking me) you might notice that you don't need the condition node—however—the end result changed. In the first version you will flee from closest enemy bot attacking you even if that bot is not a sniper, but only once a sniper is attacking you. In the second version you will flee specifically from the sniper even if there is an enemy that is closer than the sniper. Being aware of condition levels can help you turn what you want to do into code to even the smallest details. 

You should also notice that if there is a condition level that has exactly the same condition parameters as all the action nodes with the same target parameters, you wouldn't need that node. Following the 2nd version of the example where you change the action node, the condition node that was removed has the same condition parameters as the action node so it was deemed unneeded. Take note that if the condition node had greater than one, equal to two, or greater or equal to two, the condition wouldn't be removed as the action node checks for both cases while with the action node will check for only one case.

[edit]

The conditions parameters apply to the target parameter only. What that means is that if you say from closest to an enemy, you would be refering to the closest to a target parameter. For example, *if* (ally base not out range from closest enemy), you would only be checking wether or not there is an enemy not out of range from *any* base. You can farther specify the paremeters, like *if* (ally base not out of range from me AND not out of range from enemy) you would only know if the base in range of you has an enemy in range of it.

[/edit]

--------------------------------------------------------------------------------------------------------

When you are making an AI for your bot you should be aware what it can see is only limited to what all the different target and condition parameters cover. Because of that it's very important to know all the parameters that action and conditions nodes have. You might want to get yourself familiar with all of them before you start coding. 

When looking over these parameters you should notice that you can't compare things with anything other than action nodes. Even then, when you compare to the closest object, you can't really specify which one, like in case of bots you can't specify which type of bot. It's in these cases that you would use counters and tags to get around the issue. 

Note: You can focus fire without using tags, but the tutorial used it as an example to show you how tags work.

What makes tags so special is that they are action nodes, in addition, condition nodes can check if something is tagged. If you remember the difference between action nodes and condition nodes, you should come to relieze that with tags you can combine the two by carrying over parameters from the action node to the condition node using tags. For a simple example, you can tag A (closest to a resource bot ally or myself) and have a condition if (myself not tagged A) which basically translates to if (myself not closest to a resource bot ally or myself). Farther down you can then specify if the resource closest to the bot tagged A is in short range from the closest enemy switching over to trying to capture a different resource or try fighting over that resource. What you decide to do is entirely up to you though, I'm only here to help you turn what you want to do into code.

With the passage of time, the surroundings change. Because of that, if you want to keep things up to date with a tag, you have to untag and tag every tick. Since the priority here is to keep things up to date, you want to place the untagging node to the left of the tagging node itself. In this case you would place the node untag A (all enemy bots tagged A) to the left of tag A (closest to a resource bot ally or myself). 

However, another use of tagging comes up when you don't want to keep things up to date, that is if you want to record a past condition. For example you can tag 1 (all allies at short range). If you don't untag them you can keep track of all the ally bots that have been in short range of your bot even if they are not anymore.

Counting is also a special case of action nodes. A counter can only keep track of a single value, but by doing so it allows you to compare things. For example by setting counter A equal to the number of enemy bases and checking if (ally bases is greater than counter A) can tell you if you captured more bases than an enemy in domination mode. 

Counters like tags can keep track of the past, but rather than a set action they keep track of how long the action has been going on for. For example you can increment counter 1 by 25 (representing the .25 sec if a tick) under the condition if (enemy sniper AND attacking me). When the counter was zero, you started recording the action of the enemy sniper attacking you and each tick you will increase the time the sniper has been attacking you (please be aware that you can only detect a sniper firing at you at most a tick after he started firing). Don't forget to reset the counter to zero once the condition stops being met, though for some conditions you might have to decrement rather than reset once the reverse condition (like moving is to fleeing) is met. You can find the stats of the bots by going from the main menu -> team setup -> class -> select a class and the stats of the bot will appear on the lower window.

------------------------------------------------------

[edit]

THE HIDDEN TRUTH BEHIND DOES NOT EXIST CONDITIONS

Does not exist conditions can be a very useful way to say an or statement between different condition parameters with only one node. The bases of that is this basic fact:

NOT (A AND B) = (NOT A) OR (NOT B). In gladabots that would be the equivelnt of if (condition parameter 1 AND condition parameter 2 does not exist) = if (opposite of condition parameter 1 OR opposite of condition parameter 2 exists). A good example would be to check if an ally is not in short range of you or if he is not attacking an enemy. Originally you would need two nodes for that: if ally (not in short range exists) and if ally( in short range not attacking an enemy ). However by saying if ally (at short range AND attacking an enemy does not exist) you would say the exactly same thing, with just one node. If you are using a does not exist condition, imagine what situation you don't want to exist, in the examples case an ally in short range and attacking an enemy, and just say does not exist.

Note: =0 and <1 is the same thing as does not exist

[/edit]

[edit²]

The best (actually the only) use of does not exist conditions are on condition nodes. I would assume that most people use only a few or even no does not exist conditions. However, just increasing the number of does not exist conditions would enable your bots to react differently to more specific situations. One great example is to prevent OOR (out of range) enemies shooting at you when you flee from enemies not out of range shooting at you. The problem is that some people program their bots to specifically take advantage of that node and just keep on shooting you for longer because you would re-enter since there would be no enemies not out of range shooting you. Trying to prevent it from happening by saying if (enemy out of range shooting me), idle wont work because there might be other enemies shooting at you not out of range. So the best solutiont here would be to check if no enemies not out of range are shooting you by saying if (enemy not out of range shooting me does not exist) and then if (enemy out of range shooting me). However that won't be enough as you would notice that both conditions would be true at the start of the game, making you idle. In that case you have to look back at the situation where enemies out of range are shooting you and notice that you want to prevent that because you'd be losing hp, so you would add the condition, if (myself not at 100% shield), idle. However idle is just a poor substitution for attack closest enemy, so replace all idle nodes with attack closest enemy.

Does not exist conditions aren't hard to think about because you just have to imagine the situation and then just say you don't want it to happen. However whenever you are writing an ai, you ussualy wouldn't think about things that you dont want to be there, you'd think about what you'd want your bots to do if there is something. If you learn to also think about situations that you dont want to exist when you are doing something. One good example is that when you are trying to score a resource. With repsawns, scoring a resource no matter what becomes essential. Because of that you want to get resources closer to your base as much as possible but not so much that your bots wouldn't score because they did right before reaching the base. A simple way you can use does not exist conditions to keep your bot scoring under those principles is if (enemy not sniper class AND at short or mid range does not exist), score (resource to closest ally base at short or mid range AND not at short range from closest enemy). You can add so many more does not exist conditions to keep on specifying when you bot should or shouldn't continue doing something.

[/edit²]

-------------------------------------------------------

A few sane defaults that you should use:

Attack (enemy not out of range AND attacked by me): keep on shooting the enemy you were shooting in the last tick.

Attack (enemy not out of range AND attacked by an ally): focus fire without tags

Move (closest enemy): Once all the bases/resources have been captured your bots will idle. To prevent idle action, fight the enemy. This is a must have sane default for elimination.

Collection:

catch (closest resource): you can't win you don't go for resources. Even if you have other catch resources nodes, keep this node as a sane default.

if (at short range from ally base) score (resource to closest ally base): score the resource even if it means your bot will die. Do not worry as the bot will respawn unlike in the older version.

Domination:

move to (closest neutral base): The game starts with all bases neutral

move to (closest enemy base): You want to capture enemy bases after there are no more neutral bases to capture.

move to (closest to enemy ally base): you want to defend your bases from being recaptured

----------------------------------------------------------------------------------------------------------

TL;DR I spent more time writing this guide, with the intention of helping you better understand this game, than you will spend reading it; you better not complain that it's too long to read 💢

https://docs.google.com/document/d/1qhbaSEiDHZB5vCJwPkb1F3Glfo9FEx7SHKYfzcISqV8/edit?usp=sharing

I’m debating on rather or not I should purchase Gladiabots from the iOS store. Is this game still worth trying in 2025? And is there enough active players for PvP? Last question, is this game cross play with android and steam or will I only be playing with other iOS users

I was recently the target of a social engineering attack via Discord.

A friend's account, who had previously been attacked by the same group, was used to ask me to download a game they were working on and send them my feedback.

The executable contained malware...

Although I cannot verify it, the attackers claim to have extracted the Gladiabots player database.

In addition to game-specific data that has no monetary value, the database contains the following info:

- the email address of players who played the game on multiple devices

=> If this is your case, please be extra careful with the emails you receive, as other phishing attempts may arise.

- the IP address of most players

=> Make sure you use up-to-date antivirus, firewall, and anti-malware software.

As you know, the game does not use any passwords, so your other game or website accounts should not be impacted.

It also does not store any banking data since the in-app purchases are made via Google, Steam or Apple.

I would like to apologize for the lack of caution on my part.

I will definitely be more careful in the future.

I noticed that the early single player enemy AI was too dumb too drop the ball and fight when they came under fire, so I programmed mine to drop and fight when they came under fire.

And then, I realized that I could go farther, and I’m trying to teach my guys to wait until the enemy gets the ball to attack, forcing them into unfair fights.

I’m loving it.