Unicorn Overlord TACTICS IN DETAIL! Expert 

This system makes a lot more sense once you realize that, despite the name, these aren't really "conditions" so much as "operations performed on a list of potential targets," meaning that there actually is a difference between Condition 1 and Condition 2 in some cases. There are actually 3 different types of operations, and they are identified by the red text in the Condition description at the bottom of the screen. They are: CHECK - "The skill will not activate otherwise." FILTER - "The skill will not activate if there are no applicable targets." SORT - "The skill will override default targeting rules." (some of them are missing the red text, but you should be able to figure out what they are by their name, like all "prioritize" conditions are SORTs). All of these Tactics Conditions relate to selecting a target for a skill, or doing nothing and moving on to the next Tactic if no target is found. When it is time to select a target for a skill, the game does the following steps in order: 1) Generate a default list of possible targets for the skill. For AP skills this default list is well-documented in the game's help section and relates to character positions. For PP skills it depends on the specific skill and may only include a single possible target (i.e. skills that buff an ally before they attack will only get a "list" containing that single ally). 2) Run Condition1's operation on the list, making it be SORTED, FILTERED, CLEARED, or LEFT AS-IS. 3) Run Condition2's operation on the resulting list, further SORTING or FILTERING it, or CLEARING it or leaving it AS-IS. 4) If the target list is now empty, go to next Priority and start over at step 1 (meaning generating a new list from scratch). 5) Use the skill on the first target in the list (and possibly hitting other targets in the case of area attacks). For steps 2 and 3, here is how each operation works: * CHECK - If the condition being checked is true, nothing happens. If it is false, the list is CLEARED of all targets. * FILTER - Each target still in the list is checked, and any that do NOT meet the condition are removed from the list. * SORT - The list is reordered based on a specific stat for each target, in either ascending or descending order. In the case of things like "Prioritize Scouts", it means Scouts are sorted first before non-scouts, but otherwise it is things like sorting from lowest to highest HP and the like. These sorts are "stable", meaning that if multiple targets have the same value for the stat, they will retain their previous order. Note that if both Conditions are SORT operations, then the order DOES matter, because Condition2 will re-sort the list after Condition1 sorted it already. This is why some people claim Condition2 has "priority", because its sorting will happen last and thus potentially override any sorting from Condition1. That doesn't mean Condition1's sorting will do nothing, however. For example, if Condition1 was "Prioritize Scouts" and Condition2 was "Lowest HP", then the only way Condition1 would matter would be in the case where 2 targets were tied for lowest HP with the exact same HP value, but one of them was a scout and one of them was not. Otherwise, if any target has a lower HP than all the scouts do, then that target would be selected instead, meaning the "Prioritize Scouts" sort would have done nothing in that case. Reversing the order (so Condition1 is "Lowest HP" and Condition2 is "Prioritize Scouts") could easily change the result though, causing the list to first be sorted by HP, and then by "is a scout or not". This means the list will first contain scouts, ordered from lowest to highest HP, and then contain non-scouts, ordered from lowest to highest HP. Thus if there are any scouts at all in the initial list, one of them will definitely be the target no matter what HP amounts the non-scouts have. Also note that the target list may be enemies and it may be allies, depending on the skill. In some cases, as mentioned before, it might only be a single character (such as a passive skill that activates to buff an ally just before they attack), meaning that a SORT Condition won't do anything at all. For skills that respond to enemy attacks by performing an action on an ally (such as "Cover" skills), the list that is being filtered and sorted will contain *all allies that are being attacked*, NOT the enemy attacker! However, the attacker can still be checked in these cases via CHECK conditions available in the "Attack Type" category of conditions.

Can’t believe it’s taken this long for devs to realise FFXII’s gambits had the foundations for a really fun strategy game. But I’m glad we’re here.

I never thought I’d be excited to implement if then statements in a game before but it looks really fun

Currently in a coding boot camp and was worried about this game distracting me but seems like tactics are a good way to further understand conditional statements 🤣

Hey ICG, tactics in this game are extremely interesting. About your comment on prioritizing caster by Melisandre at some point you can get close to that by just changing all your lowest % HP by Lowest HP, in most cases the lower HP characters often having less bulk will result on focusing caster/low bulk without innate guards. Using Lowest HP% is great when you want to prioritize focusing target when you have access to magic/armor ignore but I'm not convinced it's generally better than HP flat. The opposite when using poison attack is true, using highest HP (flat) with 1AP or more will apply that poison to gladiator hoplite and whatever has the most HP that is targetable to maximize damage. (I know you probably know it but your audience may want to know : ) The event trigger and priority list parsing when triggerd is also important to explain, the priority list that is "read" to chose action is done at each event and not for a whole combat so something high on the priority list could never occur if the trigger isn't passed and lower action are triggered using all AP/PP. For example you have Noble Guard higher than Luminous Cover but if Melisandre is attack by Archer/magic or another ally by anything twice and gets the Luminous Cover then Alain will not trigger Noble Guard if a cav for example use Thrust on the Melisandre/alain column. I know it caused me some issue for my Ochlys/Alain column I had to restrict him to only do Noble Guard because Ochlys is never in danger and he died to any 2 cav unit that were able to act by being thrusted. Also you don't need "Back row" on Alain Noble Guard because this only triggers when he is physically attacked so he guards himself, it works if he is on backline but it can only trigger for him anyway (and if you don't remove that condition and put in front he won't guard himself). Your tactics on Alain to allow only parryable attacks to go to Melisandre looks damn good.

Oh and I forgot to talk about Powerful Call, you never have to restrict it to 1 or more AP because it will never trigger without AP because it triggers when any ally attack and then check if the conditions allow its use. You can restrict with pure filter like back row, front, combatant type strict but any Highest / lowest won't be taken into account (basically any prioritize won't work). because the trigger event that cause the Powerful Call is always the attack from an ally, the prioritize only has that ally to list and priorize (the event is on the action not the whole battle). That is why it's really easy to use with Knight or Gryphon if the rest of your team is infantry but you can't prioritize highest phys ATK for example. ( highest initiative only works pratically for the first attack because the highest initiative character triggers the event first, but the condition "highest initiative" does nothing as its the only character listed) I had Alain - Berenice - Chloe in back row and tried for the longest to have chloe powerful call Berenice but couldn't do it, as soon as Alain attack he triggers the event "ally attack" from powerful call and "prioritize highest Phys ATK" would just pass and buff him, because that triggers only considers the ally attacking. So to target a specific ally in back row for Powerful call either he has higher initiative than the rest of the same type and then goes first or you are out of luck and have to use other type. ( and if you rely on initiative it'll only work for his first attack for the 1st PP, if you have more it'll buff the same combattant type you filter on) So to recap, when triggering an event on a passive, it list the units involved. Basically when an event triggers what is listed in a passive : the character is attacked, an ally is physically attacked, a character attack, etc. The list only has the character that is being attacked. For before an ally attack trigger event like powerful call, the list only has the attacking character and you have to use condition if possible to refuse or not the trigger use.

Attacks should use "lowest HP" instead of "lowest %HP" to do what you are trying to do. Lowest % will be tied at the start of a fresh battle with all enemy units. Targeting the actual lowest HP unit will help you pick off units more effectively. Heals though should use lowest %.

The part where you try filtering by highest initiative doesn't actually do anything. That's because highest initiative condition is a SORT function, not a FILTER function, and in this case, the list being passed to the conditions only has a single unit on it anyway (whichever allied unit is about to attack). It only "works" here because having highest initiative means Clive goes earlier than the other Cav and thus gets Powerful Call. If you tried, for example, using Highest HP for condition 2 and had 2 Cav's, but one of them had higher HP but lower initiative, it wouldn't save the ability for the one that had higher HP, it would still use it on whichever one just happened to go first. SORT functions don't do anything in this case, because the list you are sorting only has 1 target on it - the allied unit that is about to attack. You need to pick a FILTER function if you want to prevent Powerful Call from being used on more than one unit. Which does, unfortunately, limit you quite a bit. You could, for example, have one cav in the front row and one in the back and then filter by Cav + Front Row (filter version for the front row check, not the "prioritize" sort version) and then it would only target the Cav that happens to be in the front row. See my other comment for details on the difference between SORT and FILTER functions and the effects they have.

Lex is S tier at guarding towns.

Really helpful guide!

Alains 3 and 4 conditions do virtually nothing 3. Prioritize armoured - To have reached this condition there had to already be no armoured so the priority aspect is irrelivant and is only looking for lowest hp. 4. Unreachable - To have gotten here condition 3 would need to be hyper specific otherwise it will always run condition 3 and never reach 4

Highest Initiative is redundant for Powerful Call because the skill only triggers before an ally attacks, which is necessarily only a single ally! If you have Clive and Josef but Josef attacks first because he's Pursuiting after Alain then Chloe would target him even if Clive has higher raw initiative. I do wish the 'Attacked by Class' conditions worked off when the _target_ was being attacked though, I think it's dumb that you can't set a hoplite to guard a Flying unit that is Attacked by Archer because the latter checks if the hoplite is attacked instead of the flier.

I think your gameplay style feels like you are willing to micromanage a lot for individual combats - I would probably rather have more complex algo to make it so I'm not switching tactics per combat. But maybe like for example you just set a few simple ones where you can toggle on/off as needed, which seems a little easier to manage than upkeep on all of these templates.. Though I guess I have done some amount of weapon switching for the magical weapon vs. non magical scenario

Best tactic for Lex. If space available in unit. Sit on bench anyway.

Thanks for the explanation. There are some cases where I think the logic is more complex than an and gate but I'm not sure how to test it. This came up because I was interested in how mixing HP, max HP, and HP % conditions work. Like does high % + low hp give us the lowest value which makes up the highest fraction or are we excluding everything that isn't tied for high % then selecting the lowest value from the remaining choices? Does switching conditions 1 and 2 make a difference? Sounds overly complex, but I could see some permutations of those conditions making useful heuristics. Smaller health pools are likely to have more mitigation tools and for a lot of use cases its not very relevant whether that's defense, evasion, passives, or formation. If you're trying to get a kill for a condition like the lance assault then you'd be better off going for the target which has less mitigation in whatever form.

Do you know what is the difference between "< % average hp" vs "< % hp". How does the average hp tactic work?

Why use lowest %HP when attacking instead of simply lowest HP? Usually the priority targets have lower health by default. Using %HP could have you focusing on some kind of tank that's at 80% health, but still has way more health and defense than the more offensive targets. Lowest %HP makes sense for healing, but I don't see it for attacking.

I struggle to understand why you've got 3 tactics for magic attack that do essentially the same thing to varying degrees. 1. Magic Attack, armored only. It will attack only an armored target. 2. Magic Attack, prioritize armored. So it will pick an armored target if it can, but otherwise it will default to default targeting behavior otherwise. 3. Magic Attack, armored enemies present. So, if armored enemies are present, it will use magic attack. Seems to me, if you're trying to use magic attack on armored enemies, you ONLY need to set it up with tactic 1. If you want it to prio low HP, the tactic should be. 1. Magic Attack, low HP condition 1, armored only condition 2. 2. Lean Edge, low HP. A priority is fundamentally an always true condition, which means it will never progress beyond that check. Unless I misunderstand, and you're giving 3 examples of how to setup Magic Attack!

the tactics are a wife simulator, it prepares you to "do exactly what she wants you to do, but without her telling exactly what to do directly" 🤣🤣

why would you need him set with magick attack: armored. but then also prioritize armored, and then on top of that if armored are present? is this just an example of different ways to program or do you actually have all three set on him? i aint ever gonna understand this game. that dont kmake sense to me

The programmer in me gets giddy with this system. Game is literally trying to teach people how coding works low key