-
Notifications
You must be signed in to change notification settings - Fork 759
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
Improvements needed for testing suite #8973
Comments
It's impossible to fully implement it due MTG rules and game lifecycle. Some targets require info about previous targets (example: target 3 creatures with diff colors). It's like some conditional mana or another things with modifying effects like x2 mana on taps -- you can't find full game state until make a real action. So it uses same technics as mana abilities with net mana methods: highlights max possible actions on playable and use real action on play. It's OK to highlights some rare non playable actions. But it's BAD to not highlights real playable. P.S. I saw your post about finding of all affecting effects for specific card/permanent (but don't remember the issue). It's has same problem -- you can't find effects list until look ahead for next game cycle (e.g. until really apply all effects). |
It's must works fine with stack and casts too. Cast command equal to activate play ability. Please, make bug report on broken use cases with checkPlayableAbility (bugs with checkPlayableAbility affects AI too). |
BTW "look ahead" is a useful feature and it supported by xmage engine (see game state and rollbacks/simulations). Can be used in many things like effects dependence like Blood Moon #4202, full ETB effects support, etc. But it can be slowly and buggy :-) At least I hold the idea that solutions to all those problems could be tried through look ahead future. |
For the testing purposes, a look ahead function might be acceptable. (simulate the game until when the action is supposed to happen, get the result, then restore the state and return the result). But I don't like the idea of look ahead implemented in the game (I will reply in more detail in one of my next messages).
I believe that you're thinking of #9225 where I want to implement the equivalency check. |
I don't understand this message |
I believe that look ahead could be used to solve those issues, but I think that it would be a hack. And an ugly and costly one at that. I prefer trying the approach mentioned at the bottom of #4202 (comment) Why I don't like look ahead (Aside from it being a workaround (which will add technical debt that will be even harder to fix later on if further changes are needed):
We don't rollback game states so much as save copying and return to a copy. If state was instead saved in a way that only actions were stored and actions could be perfectly undone, then the performance issue would go away. (But I still wouldn't like it since it's a workaround). |
Call |
It's look ahead feature as is (put to battlefield, apply effects, get characteristics). Current implementation is a hack (some effects manually looking for permanents in ETB list).
Yes, it will. So it can't be used in every corner of the engine.
There are many work with game states/rollbacks under the hood -- any mana or ability usage uses it.
Nope, it's impossible due MTG rules (one player action can go to multiple inner actions and changes, see State Based Actions as example). Moreover one simple action can change everything in game state (change effects list, effects order, affected permanents, etc). So you can't revert it. It's like a black box -- you take a current state, put it to black box and take a new game state. It's can be changed from any place of the card/ability/effect/engine. Improved/optimized game states can be used for replays only (e.g. store visible data and changes between states cause replays don't need real game data for calculations). |
I won't comment further since I don't know enough to say something true.
Sorry, english phrasing. What I mean is "Our code doesn't rollback/unwind actions. It simply saves many states in memory and then reverts to one of those". The engine can't "undo" an action, it can only save before an action and revert to that save.
I don't see why it is impossible. The MTG rules are deterministic. I make an action and then the rules go through their list of what happens. At any point that there's a choice to be made the choice taken can be saved so that it can be undo. The same with randomness, we only need to save the current state of the random number generator. No part of the game is a black box. All of it is completely known and will always act the same way (we control the random number generator, and even if we didn't we could just save the result).
I think that we could change the engine so that it handles progress forward and backwards through time by actually being able to undo actions. And the resulting engine could then also trivially handle replays since it would simply read the next action from a file rather than memory. |
You are talking about diff things. Yes, you can take starting game state, apply some actions list and get new game state (same result all the times -- only AI and some rare effects uses random and it can be fixed by store a random seed with game state). BUT you can't take current game state, revert some actions list and get a starting state -- it's impossible. You can't put the toothpaste back in the tube. But xmage needs it, so it store full game states to take it back on needs. |
But again. I don't see why. (I could very well be missing something). Every action in the game (including the random ones once the randomness is fixed) is deterministic, for any |
Thanks. I'll give it a read when I get a chance, and reply here. |
I recently took a look at this, and what you are describing is not how xmage currently works. There is a commented out call to Also, "look forward in time to when the permanent will be on the battlefield" is not actually how the rules work. Consider the God/Blind Obedience example when you have exactly 4 devotion. If you simply looked forward in time, the God would ETB tapped because you will have 5 devotion once it is on the battlefield. But that's not how it works--I checked with multiple judges and the God in this case is supposed to enter untapped! |
Entering with counters is a replacement effect. I'm talking about layered continuous effects (gain/lose types, gain/lose abilities etc.) We don't apply those at all to permanents that aren't yet on the battlefield (but we should at least for some of them, even under the old rules) |
Yes. It's the original of the "blood moon problem". Many continues effects looking for battlefield permanents only, so it can't apply it before real permanent. After changing code to looking for battlefield + etb permanents -- it's works fine. I tested it last years as one of the approach for blood moon problem (and it works) -- but I don't like that solution -- it require many changes for old and new cards (replace getbattlefield calls to another one with additional param). |
It's the only way to do it that produces the correct results in all cases (e.g. Gods when you're right at the threshold devotion value) |
Because determinism going forward in time doesn't mean you can go backward in time. "Current state + action = new state" might only have one answer for new state, but "current state - action = previous state" might have multiple possible answers for previous state. Concrete example: Battlefield consists of a Silvercoat Lion with a Dark Favor on it and a Walking Corpse with a Divine Favor on it. You cast Wrath of God. The state after the action is deterministic--you now have two creature cards and two enchantment cards in the graveyard. But you can't subtract the action "cast Wrath of God" and reconstruct the previous state--the information of which Aura was on which creature has been lost as a result of the action. |
That isn't true. On way to solve it (likely most computationally intensive way but with fewest extra states): reprocess the entire history and find the last thing that the aura was attached to. Then put that thing on the battlefield first and then the aura onto it |
There are possible workaround for "current state - action = previous state". You must store starting state + actions history. If you want to restore to prev state then you must take and recalculate all actions from starting to the needed. It's give some performance impact in long games, so it can be improved by "key game state + actions history" (key game state is a state in the middle of the game). |
Exactly. I wouldn't even consider it a workout. It's a change of phrasing/perspective. The "state" is not just the current game state, but the entire history of the game. See my reply above with same idea |
When you say that 1 is how xmage currently works, you must be referring to the client-server communication, because that's not how XMage handles rollbacks. AFAIK from the code the whole state is copied and stored, not deltas. Even deltas would help out immensely (e.g. no more copying all those lands in commander games). Yes 2. is close to what I am proposing for the new rollback handling in order for it to be much more efficient (it will have massive impacts on the AI). |
The following are based on my work on enabling checkAllCommands(). Checking off the current issues will allow for tests to be written without the need of try-catch blocks.
I'm also using it as a general tracking on for other issues.
The text was updated successfully, but these errors were encountered: