edited March 2016 in ORK Support
ACK: Wrong forum, Gil when you get back feel free to move this to Support :) Sorry!

The goal: Have a "hate" priority list that is unique for each enemy combatant. That is, it is a list that keeps track of what each of 4 player combatants have done that aggrivates each enemy. So if you Player1 attacks Enemy1, Enemy1 will begin to become aggravated more and more toward Player1, but not toward Player2, and Enemy2 will not care and will not become aggravated with Player1 since Player1 is not attacking it.

Implementation: Each enemy combatant has 4 status values: Player1_Hate, Player2_Hate, Player3_Hate, Player4_Hate. Abilities that players use, in addition to their effect, will modify these statuses on their enemy targets.

I then have 4 formulas, FirstAggro, SecondAggro, ThirdAggro, FourthAggro. The formulas, as their names might suggest, look at these status value for the user and return the appropriate result. So FirstAggro will return 2 if Player2_Hate is the highest. SecondAggro will return 1 if Player1_Hate is the SECOND highest, etc.

The idea is that typically, enemies will target the player with the ID generated by FirstAggro formula (so the one with the most PlayerN_Hate). Sometimes I also want to have abilities that specifically target the First and Second, or maybe just the Fourth, etc. Basically, I use this aggravation mechanic to make sure that there is a big cost to spamming high-damage or very debilitating abilities over and over (e.g. if your weak mage is constantly throwing super-amazing-awesome fireball at the enemy, that enemy will turn his attention to the mage and destroy him, but if the mage is careful, he can throw some fireballs with moderation without becoming the target of attacks).

Anyway, so the formulas work great, but I cannot use them in the BattleAI because under the battle AI the formula user is always the player, but the PlayerN_Hate status effects are on the BattleAI user (the enemy combatants).

I still got this to work using a very roundabout method. I have suggestions to make it easier to implement these things in the future which should be easier.

My solution was to first make an Ability that the enemy combatant can use. The ability will just use the formulas I set up to set 4 more status values. It will set up these statuses: FirstAggro, SecondAggro, ThirdAggro, FourthAggro, to integers corresponding to the appropriate player based on the PlayerN_Hate statuses on the enemy combatant. All the ability does is set the FirstAggro status to the result of the FirstAggro formula, etc etc. The battleAI starts with this ability, but the ability has a 5s reuse time, so that the combatant can also take other actions. (This step in this paragraph can arguably be entirely skipped, and the BattleAI can be used to generate the same values as the formulas, but I already wrote the formulas and the logic is much easier to keep clean with them).

Then, there is a nested BattleAI. This battleAI reads the FirstAggro, SecondAggro, etc statuses, and does some additional checks to set the actual target (e.g. if the player with the ID in the FirstAggro status is not detected by Move AI, then go to the next target on the list listed in SecondAggro, etc). The result of this Nested BattleAI is that it sets a final Status Value on the enemy combatant called Target with an ID corresponding to the selected target. Finally the main BattleAI then compares the Target status to each of the possible player IDs to target the appropriate player.

WHEW!

Ok this is obviously super complex, but I can't figure out how to do it otherwise given that I want to use formulas to generate FirstAggro, SecondAggro, etc, for reasons that I don't really want to get into.

Problems;

1. Update of target has a delay because it's done through an ability. Since abilities end the BattleAI i can't use that ability EVERY turn. So it has to have some sort of delay.

2. Super complex - it should not have to be this way. Maybe it doesn't and I'm missing something.

3. It's difficult to purposely target, say, the FourthAggro player. Basically, I have to write a new nested BattleAI to target the SecondAggro, ThirdAggro, and FourthAggro players if the FirstAggro player is targetable.

Solution:

In the battleAI, if I could use the BattleAI user as the formula user, it would be trivial to just replace most of this with a 'Check Object Variables' block. The block would check player combatants' ID (which is an object variable) to see if it matches the results of, say, FirstAggro formula with the ENEMY combatant (the BattleAI user) as the formula user. It would greatly reduce complexity. It would also allow me to directly ask for the target I want, e.g. if I wanted to have an ability that targets FirstAggro and SecondAggro, I could easily do this.

Alternatively, an 'aggro list' feature to just make this much easier (from the code perspective it would just be a sorted array of numbers that can be modified through ability use, one for each potential target) would also be great :)

If you have any better ideas about how to implement this of course, I'm very interested :)



Post edited by gamingislove on
  • edited March 2016
    Seems like this is currently not possible in the battle AI - I'll add a step for storing a formula result.
    Or you could use the Chance Fork node, the chance formula uses the battle AI's user for the calculation.

    However, you could just update the 4 hate tiers each time the hate status values are updated (e.g. storing them in object variables of the enemy or as additional status values). This could be done in the battle events of your abilities.
    Or if your hate status values are of type Normal, you could use combined status values for the hate tiers, which would automatically be updated when Normal type status values change.
    Post edited by gamingislove on
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • Cool :) I guess the stored formula result should be also calculated based on the BattleAI user, or just optional.

    I'm curious as to why there's a limit on these other blocks that does't let you set the formula's user and targets as the BattleAI user. Is there a design reason behind that?
  • That's coming from the early days of ORK 2 - these variable change steps all use the same class without special options for the different places (e.g. events and battle AI).

    Makinom is more advanced here, offering individual options for the different places variables are used. That's something that will change with ORK 3 :)
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
Sign In or Register to comment.