Jump to content
Sign in to follow this  
ruadath

Enemy AI Targeting Priority

Recommended Posts

Gotta admit, I'm also curious. Just now, on 3-4, there was a Swordmaster at half HP with a Wyrmslayer next to a wounded Haar (that would die in one more hit) and a Heather with Shade. He was walled off in such a way that he could only attack those two units. He went for Heather because Heather could not kill him but Haar could.

I feel that enemies will avoid potentially dying no matter how great a chance they have at killing your units. Obviously that's not saying too much by itself, but since nobody else has responded, I thought I'd point that out.

Share this post


Link to post
Share on other sites

I feel that enemies will avoid potentially dying no matter how great a chance they have at killing your units. Obviously that's not saying too much by itself, but since nobody else has responded, I thought I'd point that out.

Yeah, this was something that I've definitely noticed as well. Although it seems that a certain point (as far as I've tested) if you drop the unit in danger's HP down really low (like 3 HP or something), they sometimes change their mind. I'm not sure how this works though.

Share this post


Link to post
Share on other sites

For reference, in 1-3, the Fighter and one of the Archers dont seem to target Micaiah even if they can 1HKO her. Actually, they attack Sothe or some other 1-ranged peep, like Edward.

In the same chapter, the enemy attack order shifts as soon as Sothe hits 20 HP and/or lower.

This game is so weird. :awesome:

Share this post


Link to post
Share on other sites

I made an experiment in 1-P:

In a LP I saw that an enemy went for Leonardo instead for damaged Micaiah, who could be killed.

So I tested it out for myself. I placed Leonardo and damaged Micaiah in the attack range of a brigand. And the enemy went for her and caused me the Game Over.

In general I always thought that the A.I. in FE10 is pretty smart. Whenever the enemy has the chance to kill one of my units, he takes the chance.

However it seems to be that the A.I. is apparently unpredictable.

Share this post


Link to post
Share on other sites

The priority is based if you can respond to the attack or not, then goes what unit takes the most amount of damage or can be killed, for example I have Sothe and Edward, Sothe is not equipped with a weapon and Edward has a Wind Edge(if you equip a 1 range weapon units like archers and mages will go for Edward if he is weaker since he cannot counterattack), this means that enemies will not attack Edward and go for Sothe, in the case of Ballistae and Meteors since you cannot fight back they will target the unit with less def or res in range.

This is useful since you can for example unequip Sothe so enemies target him and make leveling Nolan and Edward easier since Enemy Phase is not that much of a pain for training.

Edited by Roxachronc

Share this post


Link to post
Share on other sites

I agree with this in general, but it seems (as we would expect) that this is determined by some numerical weighting rather than a strict preference list. In particular, I have done tests where I have placed Sothe with a 1-range weapon and Micaiah in range of an enemy mage. The mage usually attacks Sothe, even if he can kill Micaiah with 100% probability, but if Micaiah's HP is below a certain threshold (I don't remember what it was), then the mage goes for her instead.

It would be nice if someone could figure out how to calculate these numbers, like Gryz did for FE6-8

Share this post


Link to post
Share on other sites

A specific question that I have for anyone who might know: can you give a qualitative description of the targeting priority shifted by "Provoke - Shade." In particular, if I have two units A and B of roughly equal strength, unit A has 1-2 range and Provoke, unit B has only 1-range but also Shade, will an enemy mage target unit A or unit B?

Share this post


Link to post
Share on other sites

This sounds right up my alley, and I've been looking for a reason to return to RD for more fun adventures. I'll have to wait until I get my primary computer back, but this is a fairly simple thing to test.

One thing that needs to be known/determined though is whether attack priority is fixed (exact same circumstances, exact same result every time) or a probability (60% nearly-dead unit without Shade, 40% nearly-dead unit with Shade, or thereabouts).

Basically we'd have to re-run the same circumstances, then slightly different circumstances, then again, until we chance upon some pattern. Fixed priority (like say, unit atk - (HP / Def), attack the unit with the most negative value) should be a determinable formula from enough data points, just like the forge calculations and everything else over the years. Probabilities would be a little harder.

I admit I don't know how this was done in the past, so I'm starting from a blank slate, but I would think that rigorous analysis would be universally applicable.

For what it's worth, I've always found that enemy units usually work in tandem to deal as much damage to individual units over spreading damage around, and so enemy AI may be reevaluated even within the same turn if a particular outcome does or does not occur (and even if the CPU knows in advance which outcomes will occur, this is irrelevant to the planning as far as players are concerned).

Edited by BlenD

Share this post


Link to post
Share on other sites

I'm almost certain that attack priority is fixed (unless perhaps when "weightings" are equal, not sure then), since in the many resets I've done for various parts of my LTC run, I've never seen "random" behavior once the map is loaded. It does, however, seem to be the case that sometimes enemy AI depends on a random seed when the map is loaded, though I'm not sure about this.

One interesting point of data that you might want to start with: in 1-1 (on Hard Mode), I accidentally did an "experiment," where I saw that a fighter had the chance to attack either Edward or Leo (and no one else could/would attack them). Edward was low on HP and could be one-shotted by the fighter, but Leo could survive a hit.

When Edward had 6 Def (and as a consequence 9/20 or 21 HP from an earlier attack), the fighter preferred to attack Leo (and did so in all ~100 resets that I did). However, when Edward had 5 Def (and therefore only 8/20 or 21 HP from the earlier attack), the fighter would attack him instead.

Make of this what you will.

Share this post


Link to post
Share on other sites

If F is some function of Atk (0 when no counterattack is possible), Def, and HP, written as F(Atk, Def, HP), and priority is by greatest value (I changed my mind based on how code tends to be written), then:

F(?, 6, 9) < F(0, ?, ?) < F(?, 5, 8)

If other stats for those two are available somewhere it could be a good starting point indeed.

Then once we hit on a prototype formula, we can test it against predicted edge cases.

Edited by BlenD

Share this post


Link to post
Share on other sites

I imagine this formula is also going to involve MaxHP (maybe?) and Atk/Def stats of the enemy unit. I can get those for you for this case if you want.

EDIT: Also another thing we should take into consideration. In the GBA games, enemies had some preference for staying "closer" to other enemy units. I don't remember exactly how this was calculated, but sometimes enemies would prefer to attack slightly lower priority units (with priority being measured in a black box), if attacking the "higher priority" unit meant going far enough away from other enemies (leaving themselves vulnerable to getting ganged up upon without endangering any of the player's units). We have reason to expect something similar may be implemented in RD.

Edited by ruadath

Share this post


Link to post
Share on other sites

Yes, please. And we're going to likely need tens of cases, depending on how many terms are a factor. At every turn, we need to record the AS differential, enemy Atk, enemy Hit, enemy Def/Res, and enemy HP, along with player character Atk, Hit, Def/Res, and HP, at the least. I don't necessarily think that Hit is a factor, but I'd rather be too rigorous than too lax.

Basically, we need to isolate a one-enemy case between two player characters, like the one you've provided, for many different stat combinations (ignore statuses like sleep and paralysis for now). We can also test the same case against multiple player character combinations, such as Edward-Nolan, Edward-Micaiah, Leo-Micaiah, etc., for 1-1, to get a broader range of values from the same test cases. Try to find relationships in terms of two, three, four variables. If we get something that works for two characters, try another case and try to predict the outcome. If it succeeds, keep going. If it fails, reevaluate based on other variables.

Once we get a fairly accurate one-enemy prediction function, then we have to figure out how that changes in a two-enemy, two-target system. If no change, fine. If there's a change, we have to find the how and why.

Share this post


Link to post
Share on other sites

Are you sure attack priority is fixed? I've seen some janky shit and I feel like it's partially random too, because it doesn't seem to just conform to "can't counterattack."

Share this post


Link to post
Share on other sites

Yes, please. And we're going to likely need tens of cases, depending on how many terms are a factor. At every turn, we need to record the AS differential, enemy Atk, enemy Hit, enemy Def/Res, and enemy HP, along with player character Atk, Hit, Def/Res, and HP, at the least. I don't necessarily think that Hit is a factor, but I'd rather be too rigorous than too lax.

This seems like it could be a factor. In some testing I did for 1-E, a couple of mages had the choice between attacking Nailah and Leo (equipped with a Longbow and with a not so great hit-rate), and went for Leo since they had almost no chance of hitting Nailah (and probably would have done limited damage), but could 2RKO Leo. However, when I hacked Leo's weapon to like a +50 hit forge or something like that (I don't remember, this was a while ago), they would go for Nailah instead. This could alternatively be attributed to a general enemy AI wariness of forged weapons, but I'm not sure.

That reminds me, Crit is another important factor to record and test out. I did some testing the other day with a fighter who could attack Edward and Nolan; normally they would go for Edward because Nolan is much tankier, but I incrementally stepped up Edward's crit rate (by "forging" his Iron Sword), and after like +4 to crit, they decided to go for Nolan instead. I will dig that up and get more details on what happened at some point.

Are you sure attack priority is fixed? I've seen some janky shit and I feel like it's partially random too, because it doesn't seem to just conform to "can't counterattack."

I'm reasonably confident that it is fixed, but I don't know for sure. Believe me, I've seen some weird stuff too and it definitely doesn't conform to "can't counterattack," but from experience with enemy AI not changing from in-map resetting, I would think that there is some deterministic formula that governs who the enemy attacks, or even where they move, since that doesn't seem to be random (unlike GBA games, sometimes). I do recall some variance with the enemy AI after doing resetting entire maps (at least in terms of which squares they would attack from, not who they would attack), but this might be due to differences in Hit/Avo from changes in biorhythm (though somehow I doubt it).

Share this post


Link to post
Share on other sites

Have you tried save stating and burning some RNs on Dolphin? I haven't tried that specifically to look for AI behavior, but it's worth a shot to see if there's an RNG involved.

Edited by Lord Raven

Share this post


Link to post
Share on other sites

RNG isn't stored with in map saves in RD, so every time you do a Battle Save or "Suspend" trick and then reset, you do in fact completely change the RNG seed. Having done this numerous amounts of times in certain scenarios where I imagine targeting priorities could be "close," and seeing absolutely no deviation from standard behavior leads me to believe that the mechanism is fixed, at least to a strong degree.

Share this post


Link to post
Share on other sites

derp i just noticed this is the RD board

You can save state on Dolphin. I'm talking about save states, not Battle Saves.

Edited by Lord Raven

Share this post


Link to post
Share on other sites

Yes, I understand that. Sorry, I think I'm not communicating my point clearly, so let me go a bit more in detail.

After making a save state on Dolphin, you want to test the enemy phase with different RNG seeds so that you can see if it affects the enemy actions, right? The cursor movement trick doesn't work in RD (the last game where it works is PoR), so to manipulate the RNG you Battle Save/Suspend and reset (or if you want to maintain the current RNG string for whatever purpose, there are slightly more sophisticated things one can do, but that's besides the point), run the thing, go back to your save state, and rinse and repeat. Having done this numerous times in various different scenarios, I think that RNG doesn't play a role in determining AI targeting priorities. I could be wrong though.

Share this post


Link to post
Share on other sites

Oh okay, that makes sense then. The only thing the RNG determines then is like where they attack then?

I guess we should start collecting actual scenario data on this instead of speculating... like stringing the target priority from empirical data.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...