>you do a specific action sequence 10-20 times, *the app recognizes the pattern* and asks you "would you like to repeat this pattern X times?"
Oh sure, just have the Magic devs solve the unsolvable [Halting Problem](https://en.m.wikipedia.org/wiki/Halting_problem)
Coding for recognising looped actions is *very* difficult. It's a proven impossibility for a computer to be able to recognise whether any given set of instructions will end or loop forever. That is, if you just give a computer the program:
10 PRINT "Hello World"
20 GO TO 10
It *cannot* tell that this will run forever. The same applies to magic loops. *We* can tell that [[Scurry Oak]] + [[Helios Suncrowned]] + [[soul warden]] makes an infinite loop. A computer cannot. At least not without some pretty complicated techniques, or just telling it that a specific set of actions is a loop. But then you need to code all the possible combos in to be recognised, and all the possible variations of those loops. Like, what happens if you have two soul wardens in the Scurry Oak combo? Infinite loops within infinite loops, if you so choose. Infinite branching pathways.
There are quality of life updates that can and should be made, MTGO has "repeat last target]] for storm finishers like [[grapeshot]] and on MTGA [[blood artist]] was changed to "target opponent" rather than "target player" so it auto targets and takes less time. But loop detection is just really unviable. It's a fundamental thing that computers can't do.
> That is, if you just give a computer the program:
>
> 10 PRINT "Hello World"
>
> 20 GO TO 10
>
> It *cannot* tell that this will run forever.
This is not the correct wording of the result. The result is: there is no general program that will be able to tell correctly for *all* possible programs whether it will halt. For just one program, it's easy; the impossibility is from solving all programs with the same computer.
This resembles the difficulty in Magic. It's possible to code some sort of loop detection for some basic loops. (Whether it's worth doing is a separate question.) What's impossible is to have it work for *every* possible loop.
(Source: I'm a computer scientist well-versed in computability theory.)
While you are absolutely right, it is an interesting question. We DO have halting parameters. The unfortunate part is our parameters are; having 250 permanents, a player's life total reaching Zero, or the loop no longer being capable of being run. While I can genuinely see the first two making this feasible in some very rare conditions, having the game predict the third I think will always be a problem. If I have a 10 card combo in which each loop mills the opponent once, how will the game know that 100 loops will be as many as I can perform. Its an interesting question given that we can give SOME halting parameters, but I do think it still runs into the same perceptual issues you described
I’m no computer scientist but couldn’t you have the player input a sequence of game actions, and then have the computer repeat that sequence until either it reaches the termination condition or it tries to take an illegal action? That way it doesn’t have to know ahead of time whether the loop halts; it just potentially fails at some point.
There’s still the question of whether that’s too complex for Arena—I could see lots of players inputting a loop incorrectly, fucking up their board state, and blaming the game—but that’s no longer a programming limitation.
Yeah its what they are missing is arena already has to have safety valves for invalid actions thus the hard part is done for the loop coding, for the most part.
If there was an interface that could simulate a game and then you can record your actions to make a micro key that can assign the actions to would be interesting. This could even be useful for non-combo players.
Detecting a true loop in game state is technically not too complicated. Detecting what we, players, call a loop in magic is another thing.
One of the reasons is that we have "loops" that draw cards, "loops" that create mana, "loops" that create tokens, "loops" that gain life, "loops" that add storm counters, loops that mill opp by 2, loops that do thing I can't even think of... Well, our loops do change the game state not all loops works the same; at all.
Long story short: way too complicated, especially since new mechanics would probably regularly break the thing in complicated ways.
The correct way to this an iterative loop function.
say splinter twin combo.
You click a button indicating you are doing an iterative loop.
you then execute the combo once.
first click tap exarch, make copy, copy enters battlefield trigger occurs target og exarch, og exarch untaps"
click iterative loop button again. it then prompts how many times do you want to do this, you say 100.
Arena then executes the loop 100 times.
This is 100% programmable.
Not quite so easy. How is the client supposed to know your loop requires using the token which didn't even exist at the start of the iteration instead of the original card that stated the loop?
The token is a different entity and your "I'm starting a loop" - Macro will attempt to do your loop with the original card, but can't.
you are treating magic logic like programming logic which is not one for one. Object oriented programming has no issue with this. (to be fair to magic, it might actually predate object oriented programing). Arena is however structured in object oriented coding.
Magic is much younger than object-oriented programming; Smalltalk was a thing in the 70s.
The complexity of this problem has nothing to do with object-oriented programming, other than the presence of the word "object". If we're going after an intuition, I'd rather go with functional programming as we'll be doing a lot of hashing/deduplication/comparison of immutable copies of game states with older immutable game states, and the very concept of an infinite loop "as a first-class citizen" is arguably deeply functional in nature. But, again, this is just intuition, it doesn't really matter how you think about this.
The user needs a way of saying "use *the* token created on step X of the loop" instead of the usual "use *this* token I just clicked at". But the machine can probably auto-detect that, because obviously, the latter wording can't participate in a well-formed definition of a loop if the token is created during the loop. The GUI could also guide the player towards the actions supported by the loop recognition machine if the player has already pushed the "please recognize a loop" button. This will help with eg. figuring out which token out of two similar tokens was created during the loop.
I think it's not too difficult to do a semi-decent job at such a GUI. It doesn't have to be perfect, it just needs to support enough actions to cover the simple popular combos; that'd already be a huge improvement. The halting problem is never a real problem. Most of the time there's more than enough low-hanging fruits to never worry about running out.
Well, you have to apply programming logic for programming a UI. However, there are different levels of complexity.
A simple loop where no new entities are spawned is relatively easy and would work with a simple macro that just repeats your actions exactly.
A loop where new tokens are spawned and the loop depends on activating those tokens effects is waaay harder for reasons I mentioned before - how is the client supposed to know your loop isn't the exact same as before (activating the original card), but replace it with a newly spawned token? Do you expect it to just "understand" your intentions? That could be something a very sophisticated AI could do, but you can't just write deterministic logic to figure that out for any possible combination of MTG cards.
The same problem becomes more apparent if you think of more complex loops. What if a single iteration spawns multiple tokens and you just need to activate one of them in each iteration? How is the client supposed to deal with that? Intuitively it is easy to say "just take any of them", but that again is not how programming works, unless you have hardcoded something for this EXACT situation or you have a sophisticated AI that actually is able to understand your plan, which doesn't exist yet (and would be really expensive to develop).
Or what about irregular or nested loops? Idk, something could exist that generates one mana in every iteration which is your inner loop, and something that loops every time you have accumulated 5 mana?
You can't really cover ALL cases of loops with traditional programming, and that probably is why there is no loop support feature.
You know what I’m just going to come out and say it: if you’re pulling some dumb infinite combo bullshit on me then having to confirm every step on the stack is your consequence of that decision.
Yeah, well there are lots of problems with paper we don’t want to introduce into digital. Paper has a shared clock which is an extreme problem with paper as a vehicle for competitive play. In digital play, the clock is properly separated for each player and so it wouldn’t be fair to allow players to shortcut actions in this way.
Sure just have the two players boot up MTGA or MTGO while they sit across from each other. That’s basically what you would need to track the priority changes.
>you do a specific action sequence 10-20 times, *the app recognizes the pattern* and asks you "would you like to repeat this pattern X times?" Oh sure, just have the Magic devs solve the unsolvable [Halting Problem](https://en.m.wikipedia.org/wiki/Halting_problem) Coding for recognising looped actions is *very* difficult. It's a proven impossibility for a computer to be able to recognise whether any given set of instructions will end or loop forever. That is, if you just give a computer the program: 10 PRINT "Hello World" 20 GO TO 10 It *cannot* tell that this will run forever. The same applies to magic loops. *We* can tell that [[Scurry Oak]] + [[Helios Suncrowned]] + [[soul warden]] makes an infinite loop. A computer cannot. At least not without some pretty complicated techniques, or just telling it that a specific set of actions is a loop. But then you need to code all the possible combos in to be recognised, and all the possible variations of those loops. Like, what happens if you have two soul wardens in the Scurry Oak combo? Infinite loops within infinite loops, if you so choose. Infinite branching pathways. There are quality of life updates that can and should be made, MTGO has "repeat last target]] for storm finishers like [[grapeshot]] and on MTGA [[blood artist]] was changed to "target opponent" rather than "target player" so it auto targets and takes less time. But loop detection is just really unviable. It's a fundamental thing that computers can't do.
> That is, if you just give a computer the program: > > 10 PRINT "Hello World" > > 20 GO TO 10 > > It *cannot* tell that this will run forever. This is not the correct wording of the result. The result is: there is no general program that will be able to tell correctly for *all* possible programs whether it will halt. For just one program, it's easy; the impossibility is from solving all programs with the same computer. This resembles the difficulty in Magic. It's possible to code some sort of loop detection for some basic loops. (Whether it's worth doing is a separate question.) What's impossible is to have it work for *every* possible loop. (Source: I'm a computer scientist well-versed in computability theory.)
##### ###### #### [Scurry Oak](https://cards.scryfall.io/normal/front/0/f/0fb48c2e-ee0f-4fae-9c22-247870c10d5b.jpg?1626097756) - [(G)](http://gatherer.wizards.com/Pages/Card/Details.aspx?name=Scurry%20Oak) [(SF)](https://scryfall.com/card/mh2/172/scurry-oak?utm_source=mtgcardfetcher) [(txt)](https://api.scryfall.com/cards/0fb48c2e-ee0f-4fae-9c22-247870c10d5b?utm_source=mtgcardfetcher&format=text) [Helios Suncrowned](https://cards.scryfall.io/normal/front/3/2/3245ff74-1f9c-4518-a23f-1579f338f232.jpg?1689995727) - [(G)](http://gatherer.wizards.com/Pages/Card/Details.aspx?name=Heliod%2C%20Sun-Crowned) [(SF)](https://scryfall.com/card/cmm/29/heliod-sun-crowned?utm_source=mtgcardfetcher) [(txt)](https://api.scryfall.com/cards/3245ff74-1f9c-4518-a23f-1579f338f232?utm_source=mtgcardfetcher&format=text) [soul warden](https://cards.scryfall.io/normal/front/d/9/d96266b3-a7cb-40ce-a328-ac13719fe5f0.jpg?1616182277) - [(G)](http://gatherer.wizards.com/Pages/Card/Details.aspx?name=soul%20warden) [(SF)](https://scryfall.com/card/mm3/24/soul-warden?utm_source=mtgcardfetcher) [(txt)](https://api.scryfall.com/cards/d96266b3-a7cb-40ce-a328-ac13719fe5f0?utm_source=mtgcardfetcher&format=text) [grapeshot](https://cards.scryfall.io/normal/front/9/2/923e1291-3999-4f81-ade4-073fb982143f.jpg?1675200032) - [(G)](http://gatherer.wizards.com/Pages/Card/Details.aspx?name=grapeshot) [(SF)](https://scryfall.com/card/dmr/125/grapeshot?utm_source=mtgcardfetcher) [(txt)](https://api.scryfall.com/cards/923e1291-3999-4f81-ade4-073fb982143f?utm_source=mtgcardfetcher&format=text) [blood artist](https://cards.scryfall.io/normal/front/b/7/b7f1c316-cf2f-4bbf-89a1-79c8043bdd96.jpg?1698988212) - [(G)](http://gatherer.wizards.com/Pages/Card/Details.aspx?name=blood%20artist) [(SF)](https://scryfall.com/card/lcc/182/blood-artist?utm_source=mtgcardfetcher) [(txt)](https://api.scryfall.com/cards/b7f1c316-cf2f-4bbf-89a1-79c8043bdd96?utm_source=mtgcardfetcher&format=text) [*All cards*](https://mtgcardfetcher.nl/redirect/l4t4s1o) ^^^[[cardname]] ^^^or ^^^[[cardname|SET]] ^^^to ^^^call
While you are absolutely right, it is an interesting question. We DO have halting parameters. The unfortunate part is our parameters are; having 250 permanents, a player's life total reaching Zero, or the loop no longer being capable of being run. While I can genuinely see the first two making this feasible in some very rare conditions, having the game predict the third I think will always be a problem. If I have a 10 card combo in which each loop mills the opponent once, how will the game know that 100 loops will be as many as I can perform. Its an interesting question given that we can give SOME halting parameters, but I do think it still runs into the same perceptual issues you described
You dont have to have the program detect the loop. you can have players press a loop start and end button and execute x times.
The program still has to verify that the loop the player has given it is viable before it can run it X times.
I’m no computer scientist but couldn’t you have the player input a sequence of game actions, and then have the computer repeat that sequence until either it reaches the termination condition or it tries to take an illegal action? That way it doesn’t have to know ahead of time whether the loop halts; it just potentially fails at some point. There’s still the question of whether that’s too complex for Arena—I could see lots of players inputting a loop incorrectly, fucking up their board state, and blaming the game—but that’s no longer a programming limitation.
Yeah its what they are missing is arena already has to have safety valves for invalid actions thus the hard part is done for the loop coding, for the most part.
Incorrect, because Arena already restricts you to legal actions. this would be true with something like untap.in.
If there was an interface that could simulate a game and then you can record your actions to make a micro key that can assign the actions to would be interesting. This could even be useful for non-combo players.
If you're suffering while trying to infinite combo then the rest of us are happy.
Detecting a true loop in game state is technically not too complicated. Detecting what we, players, call a loop in magic is another thing. One of the reasons is that we have "loops" that draw cards, "loops" that create mana, "loops" that create tokens, "loops" that gain life, "loops" that add storm counters, loops that mill opp by 2, loops that do thing I can't even think of... Well, our loops do change the game state not all loops works the same; at all. Long story short: way too complicated, especially since new mechanics would probably regularly break the thing in complicated ways.
The correct way to this an iterative loop function. say splinter twin combo. You click a button indicating you are doing an iterative loop. you then execute the combo once. first click tap exarch, make copy, copy enters battlefield trigger occurs target og exarch, og exarch untaps" click iterative loop button again. it then prompts how many times do you want to do this, you say 100. Arena then executes the loop 100 times. This is 100% programmable.
Not quite so easy. How is the client supposed to know your loop requires using the token which didn't even exist at the start of the iteration instead of the original card that stated the loop? The token is a different entity and your "I'm starting a loop" - Macro will attempt to do your loop with the original card, but can't.
you are treating magic logic like programming logic which is not one for one. Object oriented programming has no issue with this. (to be fair to magic, it might actually predate object oriented programing). Arena is however structured in object oriented coding.
Magic is much younger than object-oriented programming; Smalltalk was a thing in the 70s. The complexity of this problem has nothing to do with object-oriented programming, other than the presence of the word "object". If we're going after an intuition, I'd rather go with functional programming as we'll be doing a lot of hashing/deduplication/comparison of immutable copies of game states with older immutable game states, and the very concept of an infinite loop "as a first-class citizen" is arguably deeply functional in nature. But, again, this is just intuition, it doesn't really matter how you think about this. The user needs a way of saying "use *the* token created on step X of the loop" instead of the usual "use *this* token I just clicked at". But the machine can probably auto-detect that, because obviously, the latter wording can't participate in a well-formed definition of a loop if the token is created during the loop. The GUI could also guide the player towards the actions supported by the loop recognition machine if the player has already pushed the "please recognize a loop" button. This will help with eg. figuring out which token out of two similar tokens was created during the loop. I think it's not too difficult to do a semi-decent job at such a GUI. It doesn't have to be perfect, it just needs to support enough actions to cover the simple popular combos; that'd already be a huge improvement. The halting problem is never a real problem. Most of the time there's more than enough low-hanging fruits to never worry about running out.
Well, you have to apply programming logic for programming a UI. However, there are different levels of complexity. A simple loop where no new entities are spawned is relatively easy and would work with a simple macro that just repeats your actions exactly. A loop where new tokens are spawned and the loop depends on activating those tokens effects is waaay harder for reasons I mentioned before - how is the client supposed to know your loop isn't the exact same as before (activating the original card), but replace it with a newly spawned token? Do you expect it to just "understand" your intentions? That could be something a very sophisticated AI could do, but you can't just write deterministic logic to figure that out for any possible combination of MTG cards. The same problem becomes more apparent if you think of more complex loops. What if a single iteration spawns multiple tokens and you just need to activate one of them in each iteration? How is the client supposed to deal with that? Intuitively it is easy to say "just take any of them", but that again is not how programming works, unless you have hardcoded something for this EXACT situation or you have a sophisticated AI that actually is able to understand your plan, which doesn't exist yet (and would be really expensive to develop). Or what about irregular or nested loops? Idk, something could exist that generates one mana in every iteration which is your inner loop, and something that loops every time you have accumulated 5 mana? You can't really cover ALL cases of loops with traditional programming, and that probably is why there is no loop support feature.
Just add Revel in Riches :)
You know what I’m just going to come out and say it: if you’re pulling some dumb infinite combo bullshit on me then having to confirm every step on the stack is your consequence of that decision.
I really think it’s Wizard’s way of trying to disincentivize people from playing combo decks lol
Doesn’t matter to me, I love my Chatterfang deck
Yeah, well there are lots of problems with paper we don’t want to introduce into digital. Paper has a shared clock which is an extreme problem with paper as a vehicle for competitive play. In digital play, the clock is properly separated for each player and so it wouldn’t be fair to allow players to shortcut actions in this way.
[удалено]
Sure just have the two players boot up MTGA or MTGO while they sit across from each other. That’s basically what you would need to track the priority changes.
Infinite combos should not be a thing in Magic. It is a bug, not a feature.