-
Notifications
You must be signed in to change notification settings - Fork 59
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
Secrets #34
Comments
The plan is to extend StopNode to handle secrets (SecretNode is actually already there... at least its skeleton of it). Here are my thoughts: Just like any other non-predictable outcome effects, secret handling in HearthSim will have to go through a StopNode, which is a search tree node that triggers a recompute of the search tree above it when it is actually played. For a secret, a SecretNode (extends StopNode) will have children that are the boardStates when different possible secrets are triggered. The AI is free to score the different cases however it wants to to come up with the overall "expected score of revealing this secret" and once that is computed, it can go and compare the expected score with the scores of all other leaf nodes (and possible of other StopNodes). The reference AI implementation will probably just take the worst outcome of the secret as the expected score, resulting in a conservative strategy, but I can imagine using other information to compute a more realistic probability distribution of the different outcomes (maybe with previous opponent plays, etc). My current priority is to do "at the end of turn" and "at the beginning of turn" cards first, then secret cards, and finally the rest of the "random effect" cards. Some of those random effects cards are particularly annoying as they end up creating intractable number of children node (e.g., Avenging Wrath), so I'm putting them off until the end... unless someone wants to tackle the problem :) Let me know if you have any other idea on how we can handle it. |
Sounds good, looking forward to seeing it! I'm curious to see how this is done, as it seems that the very first move the current player does when the waiting player has an active secret could trigger the secret, or it could not get triggered at all, so how do you know where to put the stop-nodes in the tree? It would seem to me that every node in the search tree would have to consider that it is revealing a secret.. Like, let's say the first child of the root is to play a minion: that could trigger it's health being lowered to 1 (repentance), or nothing could happen at all. So, do you create two children of that play, one with secret revealed, one without.. Or maybe if there are secrets on the board you start by branching from the root for each available secret, ie 6 children for Paladin. Looks like a tough problem! |
Yep, the SecretNode branch will have to happen at the very first play that the player is making, not when the secret is actually played. So, like you said, for Paladin, the AI will start out with 6 branch, simulate out (as much as possible) the branches to pick the best one and start playing down that branch. Each play that the AI makes along that branch may give it more information (e.g., played a minion, nothing happened... eliminate a few possibilities), so the AI might have to reconsider its branches after each move. The number of branches should decrease as the AI gets more information, so hopefully it'll be tractable. |
@oyachai , you might like to try running the updated ReferenceCardSpec, it pumps out a list of missing cards, now broken down by weapon/minion/spell/secret. |
What's the plan for implementing secrets? I'm looking through the cards left to implement and secret related ones are a good chunk.
The text was updated successfully, but these errors were encountered: