How do you use subroutines?

[pier4r]

From alpha 4.x to alpha 5.3.1 there were no subroutines, and I organized my trees in "departments" or blocks according to invariant conditions.

Code: Select all

if carry
  do something (mostly based on enemy distance and health)
 
if not carry
  if enemy short range
    do something
  else if enemy medium range
    do something
  else if enemy long range
    do something
  else if enemy out of range
    do something
  else if no enemy
    capture resources


So now that I have finally some minutes to relax (I got a not so easy start with the little one) and I was thinking to refactor the AIs in subroutines but, well, mostly it is not needed. For the moment it is easier for me to have all the block of actions in one program. What is more interesting is when I want to activate/deactivate complete behaviors of a bot.

Like a bot that behaves like a fighter/collector and then behaves very conservative. So actually more than using subroutines for little part of the program is like I use subroutines to switch "mode" of the bot. That's means that the subroutine has exactly the same structure of the parent program, to let the bot behave differently.

Instead how do you use them? Do you pack little part (like collecting resources) of the bot behavior in subroutines and then you assemble them in one program?

[HBomb]

You should definitely take each one of those little sections of yours and put it in its own subroutine.

1. Splitting up your display helps reduce the lag gained from large trees.
2. What feels small now may need large improvements later. Why fiddle with a large tree when you can modify on a focused tiny one?
3. If you want another AI, you've already got your options accessible. I just made a second AI for the "Definitely dead" bots in circle of death and the like, but it took almost no effort. I just used small set of subroutines. And the jobs done.
4. Even subroutines within subroutines make your trees massively neater. Eg. I have a "run_away" function in both "low_health" and "low_shields" functions, divvy-ing up when to run and how to run.
5. It's very existence is to solve issues such as these:

activate/deactivate complete behaviors of a bot.

Like a bot that behaves like a fighter/collector and then behaves very conservative.

I split the sections up the same way you do, with each section dedicated to one job or strategy. It's a good system IMHO and better than a huge binary tree based on botclass, health, shield, enemy distance etc which would be exponentially huge.

[MGBlitz81]

Wow, how many nodes do you think you are using there?

[HBomb]

Wow, how many nodes do you think you are using there?

Uhhhhhhhh... How badly do you want to know? Lol

[mcompany]

I use subtrees for resources and AI choosers (such as having AI that chooses based on bot class or starting rank, or an AI that has only one command, which is to run another AI). I decided against spliting my attack systems up because I wanted to be able to work on them quickly to test other stuff

[pier4r]

1. Splitting up your display helps reduce the lag gained from large trees.
2. What feels small now may need large improvements later. Why fiddle with a large tree when you can modify on a focused tiny one?
3. If you want another AI, you've already got your options accessible. I just made a second AI for the "Definitely dead" bots in circle of death and the like, but it took almost no effort. I just used small set of subroutines. And the jobs done.
4. Even subroutines within subroutines make your trees massively neater. Eg. I have a "run_away" function in both "low_health" and "low_shields" functions, divvy-ing up when to run and how to run.
5. It's very existence is to solve issues such as these:

1. Yup this I know but so far they are manageable, otherwise refactor in subroutines! (in alpha 4.x I had 100+ nodes, now just around 50)
2. Exactly because the blocks are depending on each other, so I retreat from medium but the long range block should consider the retreat conditions of medium range, so not having them in the same "page" is a bit of an hassle. A solution would be refactoring the retreat part in one subroutine, but then I have different strategies for different bots and this means duplicating the retreat subroutine or making it complicated by bot type. At the end it is less maintenance to keep it in the program for the bot class.

What was game changing was an AI per bot class, and not an AI per map (with separated bot classes).
3. Completely understandable (indeed it is like a library of actions), but would be the same for me. Duplicate the base AI (see how I evolve my Ais in the other thread), and then some changes.
4. That's true, the point is still that so far, aside from a couple of nodes, I do have particular settings in every case so there is nothing to reuse for everyone.
5. Indeed, that is the main purpose in my case. Another purpose would be to define actions that are common to everyone, like electing a commander.

[pier4r]

Moreover HBomb I'm interested in your "a", "b", "c" prefixes. Do you use to sort stuff for sure, but how?

[NullPointer]

I follow a very simple idea: if it can be reused, it should be in a subtree.

I'm not creating them for any other reason so far.

[HBomb]

Moreover HBomb I'm interested in your "a", "b", "c" prefixes. Do you use to sort stuff for sure, but how?

Organising what sub belongs to what and ordering in advance in case I make another AIs.

0_ Actual AI
a_ Fundamental subs that need to be in every good AI.
b_ optional extras that could be added to specific AIs
c_ Subs to be added to other subs
d_ and e_ are subs included in other subs that do increasingly small jobs.

There's one c_ in my AI page because it was originally going to go in my a_move, but I felt that it had to take president before attacking subroutines so it's now on its own. I should rename it to b_.

In response to what you said, I would consider reorgonising your trees if they don't fit neatly into subroutines. It will be a pain now but future changes and additions will be so much easier.

[mcompany]

Meh, I don't feel like reorganizing everything to subtrees because I have every bot attack differently and I sometimes merge certain attack orders with other move orders to test stuff (plus I sometimes analyze battles tick by tick and it is easier for me to see the entire AI altogether)

[pier4r]

I follow a very simple idea: if it can be reused, it should be in a subtree.

I'm not creating them for any other reason so far.

That's it 100% like functions/classes/etc. in programming. Indeed would be my same approach.

[pier4r]

Organising what sub belongs to what and ordering in advance in case I make another AIs.

0_ Actual AI
a_ Fundamental subs that need to be in every good AI.
b_ optional extras that could be added to specific AIs
c_ Subs to be added to other subs. That one should probably be moved to b_
d_ and e_ are subs included in other subs that do increasingly small jobs.

I will link this post as possible naming convention in the FAQ

[Ritter Runkel]

For me it works well too have these reusable blocks like retreat.ballanced or retreat.under.fire or whichever. I also use subtrees to change behavior during the battle.

e.g. act conservative in the beginning of the battle. When enemys mg or sniper is down be more pushy or start to collect. That can be implemented very easy and for some maps is pretty efficient.

[pier4r]

I really like that I edit my programs from 5.3.1 and slowly I recognize that I edit the same part in multiple programs, I get pissed and, how one would do while programming or in system administration, I start to write a subtree to replace everything (like many suggested, for example nullpointer). It is rewarding, even if then one loses in battle, the work saved, until copy and paste actions will be available in the editor, is a lot.

[NullPointer]

Adding to that, I recommend using a name convention. For generic AIs, I use:

<game version> SUB <description> <subtree version>

Examples:
6.1.3 SUB Attack
6.1.3 SUB Attack 2
6.1.3 SUB Attack 3

When I have to make a subtree to a specific map, I use:

<game version> <map name> <strategy number> SUB <description>

Examples:
6.1.3 Wonders 2 SUB Flee
6.1.3 Wonders 2 SUB Attack
6.1.3 Wonders 3 SUB Attack

[pier4r]

Thanks for sharing, I linked your post into the faq.

Instead I use :

NNNN description

Where N is a number between 0 and 9, and numbers close to 0000 are the most generic subroutines . Then every type of subroutines I assign intuitively a range and then I fill the numbers leaving gaps, so I have space for new subroutines of the same type that cover different needs, for example (I'm loading a screenshot)

Gladiabots_20170101_192739.jpg (253.1 KiB) Viewed 2671 times

One can see the block for tagging/untagging behaviors.

I learned this due to administration of IDs (bfore they got automated) for categories in a db.