Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow AI to reuse teleporters that hero is standing on #9578

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

idshibanov
Copy link
Collaborator

Relates to #7139. Relates to #8105 but doesn't fully resolve it.

Similarly to how a player may use the space bar to re-activate the stone liths AI should be able to reuse it. This is especially important on maps the exit is blocked on the other side that makes AI to play with one less hero (that is often impossible to reach). The feature is only enabled on Hard+ so normal campaign runs shouldn't be affected.

@idshibanov idshibanov added improvement New feature, request or improvement AI Artificial intelligence behaviour labels Feb 17, 2025
@oleg-derevenetz
Copy link
Collaborator

oleg-derevenetz commented Feb 18, 2025

Hi @idshibanov The main reason why I avoided implementing such logic is that the current AI implementation is prone to the cyclical repetition of the same actions - at least nothing prevents this in theory (and sometimes in practice). All other hero movement methods currently used by AI (including Dimension Door, Town Gate and Town Portal spells) spend the hero's movement points, which serves as a kind of safety valve, which ensures that the AI-controlled hero's turn ends eventually, even if the situation on the map is currently such that the AI is doing cyclically repeating actions. Reusing teleports without performing movements does not have such a safety valve, because hero doesn't spend any movement points, therefore, it is theoretically possible for a hero to move between two teleporters indefinitely. What do you think?

@zenseii
Copy link
Collaborator

zenseii commented Feb 18, 2025

Hi, @idshibanov. I made two tests on some good example maps: Portals and Wizard's Isle 2. Another good test map would be Surf and Turf due to it having (too) many portals.

I tested Wizard's Isle map 2 on Hard campaign difficulty, which for this map corresponds to Hard scenario difficulty. In this case the strong Necro hero just stood in place on a stone lith and didn't move not matter how many days passed. This sort of behavior could be a problem for original maps and especially for the AI's ability to expand in the beginning. This happened on day 2 and should be easy to reproduce.

The next map I tested on Hard was Portals, and here it seemed like the AI never used the stone liths, and this made for a very different experience where usually you'd expect the AI to send scouts through to your side and be a thorn in the side. This made me question whether or how this will affect the player's ability to observe where the AI has been. What I mean is that it is often very important to know how much of the map is known to your opponent, especially for fheroes2 compared to the OG. Is it the case that during your turn, you won't be able to see whether the AI pops up through a stone lith you've discovered? I would assume yes, since part of the reason for this PR is to cut down on the time watching the AI spam through whirlpools and liths. If this is the case then it would become quite difficult to judge the risks of going near a stone lith because if you want to send a scout past it then it would help to know if that scout will immediately be seen and targeted or not.

These are just my experiences from testing this initial state of the PR. As I've said before, I think an easier solution (and certainly less headache prone) would be to make a new adventure map object that allows to pick an exit and so spend less efforts trying to figure out clever ways to adapt this broken design of the original liths. My point is that there's seemingly no way to satisfy everyone with regards to the original liths.

Either way, I'll continue to test updates if needed.

@idshibanov
Copy link
Collaborator Author

Reusing teleports without performing movements does not have such a safety valve, because hero doesn't spend any movement points, therefore, it is theoretically possible for a hero to move between two teleporters indefinitely.

I understand the concern. I was thinking we could add a superficial movement cost (based on # of teleporter exits on the map) in the AI pathfinder to discourage AI from jumping back and forth. Planner cost only, no actual hero movement spent. Stone lith or whirlpool shouldn't be a destination point anyway.

There's also a discussion if we should make a new UI for players to select the exit portal. Giving player ability to use space bar to jump to any desired exit point defeated the purpose of randomness anyway. AI already knows which one.

@idshibanov
Copy link
Collaborator Author

In this case the strong Necro hero just stood in place on a stone lith and didn't move not matter how many days passed. This sort of behavior could be a problem for original maps and especially for the AI's ability to expand in the beginning.

This sounds like a bug/something I forgot to update. Will check it out later when got time. Thanks for testing!

@oleg-derevenetz
Copy link
Collaborator

oleg-derevenetz commented Feb 19, 2025

I understand the concern. I was thinking we could add a superficial movement cost (based on # of teleporter exits on the map) in the AI pathfinder to discourage AI from jumping back and forth. Planner cost only, no actual hero movement spent. Stone lith or whirlpool shouldn't be a destination point anyway.

The issue is not in pathfinder, it perfectly avoids looping paths. The issue is that the high-level AI reconsiders its target after visiting any action object (and stone liths and whirlpools are action objects). Consider the following situation: there are two objects on the map, A and B, connected using the stone liths C and D:

A - C - D - B

Hero is currently at the object A. The high-level AI considers the object B as a target. Hero moves to C, teleports to D, then high-level AI is in charge once again and for some reason it decides that now the object A is a target. Hero teleports from D back to C, now high-level AI is in charge once again and now it decides to go to B again :) And so on. To eliminate this behavior, some kind of safety valve is needed - either the hero must continue on his way after teleporting without interfering with the high-level AI, or the high-level AI must turn off the use of teleporters in AI pathfinder under certain conditions (for example, after a certain number of teleportations made by this hero). Currently this "safety valve" is just the number of the hero's movement points, since there is no way for an AI-controlled hero to re-visit the teleport without spending the movement points.

There's also a discussion if we should make a new UI for players to select the exit portal. Giving player ability to use space bar to jump to any desired exit point defeated the purpose of randomness anyway. AI already knows which one.

Yes, from a logical point of view, randomness is superfluous here. By the way, this reminded me of another reason why I refrained from implementing this logic at the time. There are maps built in such a way that AI cannot quickly reach a human player or quickly transfer reinforcements due to the many identical teleporters, only one of which leads to the enemy. It is forced to get lost in them, wasting time and movement points. The idea of non-random teleports (and instant teleportation) is kinda ruins the whole idea of these maps. Yes, the "spacebar mechanics" is also kind of ruins the idea for the human player too, but the human players don't complain about it so much (unlike a situation where a more advanced AI opponent quickly arrives at you and easily sends reinforcements instead of getting lost).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AI Artificial intelligence behaviour improvement New feature, request or improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants