My first real foray into Linux was inspecting network traffic with a program called ShowEQ for EverQuest. At the time, the traffic was unencrypted and had lots of juicy info in it. I used a hub to replicate traffic to my Linux box, and it would draw a live map of the zone and showed where the mobs, NPCS, and users were. It even showed what loot the mobs had on them so you could cherry pick certain ones. The beauty of this was that it was passive and impossible to detect. Eventually SOE wised up and started to encrypt the traffic.
The data has to be decrypted and read, so eventually you reverse engineer the client and figure out how to decrypt on the fly, then they wise up and introduce key based signing, which you eventually try to steal from the client and breaking the encryption again, then anti cheat is implemented... thus, the cat and mouse game is born, lol
Once the siphoning happens on the same machine your client is running on it's easier to detect through anti-cheats at least. If it can run on a completely separate machine it seems like it'd be essentially impossible to detect except through changes in how a user acts like only going directly to the mobs with the juicy loot and ignoring the trash but that's really tough to detect.
Hypothetically the client doesn't really have to know about the juicy loot until it's dropped, right? On a sufficiently fast internet connection, the client doesn't need to know about anything until exactly the time when the player needs to know it, at which point revealing it in a cheating tool is meaningless.
At the very least with everquest (iirc) npcs would sometimes use their loot. I recall tanks occasionally letting the rest of the raid know what weapon drop the boss had on them because they were seeing a different damage type (pierce, slash, bludgeon instead of hit) and the boss was known to sometimes drop a certain piercing weapon (for example).
That being said, I can totally think of a few ways to get around that. It's like you said, the client doesn't really need to know until the enemy is looted.
[Actually, the one exception that I can think of is that rogues can pickpocket certain loot. And while pinging the server to generate loot once the npc is dead feels like it shouldn't be a major problem, having to ping the server to generate loot while the npc is still alive does make the system architect in me feel a bit more nervous ... at the very least for systems as they were when EQ first came out.]
NPCs also gain stat bonus from their equipment. NPCs wear every slot except only 1 wrist,finger,ear. Big difference between a mage pet in full banded vs naked.
Modern games you don't need to unless the boss changed depending on the loot and even then it would be tangential. Don't forget this is EQ2 we're talking about internet back then was sloooooow and online games of that type were pretty new so designs and security were still being sorted out. Now you know from the beginning that any useful information about the enemy and world will be pried out of your game so you go through the whole anti-cheat cat and mouse game.
The final stage beeing the Opt player kill & Bann. Compute a all knowing AI and hold it's behavior against that of players, then cull the closest percentage.
Sending loot on NPCs to every client costs more, not less.
The reason why they probably did it is because NPCs actually used the items. When the froglok King loaded his two handed sword, he was actually using it. And when he didn't load it, he wasn't.
I'll admit I did something similar for a game called Dark Age of Camelot as a teenager. Very educative, learned about both network sniffing, hubs vs switches and Linux.
Was it worth it to give me an advantage in the game? No, I never played the game seriously enough to be able to use it, I think I used it for a week after spending two setting it up, but it was a great learning experience.
I also fell into my first programming experience with DAoC! I worked on fixing some very simple bugs/exploits on an emulated server (C#) back in 2005.
There's a ton of fascinating stories coming out in the last decade around hacking/exploits/etc of games of that era; DAoC, UO, Shadowbane (this one was real bad).
If you don't encrypt your network traffic, you can quite easily decrypt it on another PC (as you can just set promiscuous mode on your 2nd PC NIC), giving you undetectable read-only hacks like "radar", where you basically have a map of the game with the enemy positions, health, gun, ...
If you encrypt it, this is no longer possible.
If a cheater wants to decrypt it, he has to get access to the decryption key, which usually is send over an TLS encrypted connection (with certificate pinning in place) [Or in some cases self made encryption :/].
Therefore he has to either reverse the game to get the certificate or has to attempt to read it while the game is running.
In the first case the game developers (and the Anti-Cheat providers) will try there best by obfuscating the specific regions.
And the 2nd case is basically what AC is all about, and therefore difficult for modern Anti-Cheats.
I think reading the encryption key from memory is usually easy and cannot really be detected in any way if done from the kernel or hypervisor by parsing page tables and accessing physical memory (except by looking for known code if the anti-cheat has as much privileges as the extractor, which the hypervisor approach avoids).
In first approximation, there are only two kind of difficulty levels: the impossible things you don't know how to do, and the trivial things that you do.
I always wished that CPU/GPU manufacturers would make a "online gaming edition" with hardware level encryption/anti-cheat. I know many people would love to play exclusive lobbies where it is virtually guaranteed there are no cheaters.
You can just hook the networking system calls and you have the unencrypted buffer. TLS encryption doesn't do anything since you can just look at it unencrypted on the network function when they pass in the buffer.
If they encrypt before the network functions, you can just look at the callstack and trace the variable containing the buffer backwards until it's non encrypted.
Yes. Sometimes software will encrypt HTTP calls while relying on the operating system certificate authorities, so it's easy to intercept again using tools such as mitmproxy.
Sometimes you will be forced to hack the software, to allow interception or to replace a key. Unless they use a symmetric key that is easily found, but I have never seen that.
It doesn't, we are just in 90's security mindset. We even have the typical idiot here chiming in, "it doesn't have to be perfect". Meanwhile in adult software engineer world, we know we can just not send the state of the entire world to every player and that would also save costs.
Decompiling (in a meaningful way) an optimized binary generated from C without debug symbols is much harder than what the author has shown in C#. It is not impossible, but probably very time consuming.
Versus just reading clean packages from a network.
ShowEQ still works, there is also MySEQ which is Windows based but just reads memory instead. They are fine to use as the current owners of EQ don't really seem to care. Neither app has ever been able to show what loot a mob has except for visible pieces. Some of the data has changed over the years, for example exact mob HP used to be sent, now they just send percentages.
> Neither app has ever been able to show what loot a mob has except for visible pieces.
ShowEQ definitely showed drops at some point. I vividly recall farming lightstones from Willowisp and using ShowEQ to ignore the ones with burned out lightstones.
I would suspect "modern" has a lot more impact than "browser" (notably, aside from more developer awareness of cheating, I would suspect TLS is far more common now, though that can of course be worked around when you control the client). Browser traffic isn't any different from any other type of traffic, the standard packet sniffing tools (tcpdump, wireshark, mitmproxy, etc.) work just fine.
"I was totally surprised by this, because it means that a (mostly) fully-functioning bot capable of playing arbitrary games of Magic: The Gathering has a small enough footprint to run locally on your machine"
I dont get that. Maybe I am missing something.
Lets say, the MTG AI was so intensive to run that it would be unreasonable to run on the customer's machine - then I wouldn't run it on the server either, since it would be quite expensive (and bot games in card games are usually not pay per play).
Also, servers are not magic - most of them run on the same x86 CPUs as the local machine, with a lower clockspeed than their desktop counter parts (but higher than (most) notebooks). Therefore, the only way to archive a lower Bot turn timer compared to running locally would be to use significantly more cores than the customer (usually 4-8, hence 8-16 allocated cores per player?!). Sounds like a nightmare, especially during peak concurrent player hours/days!
If the CPU Player does not support multi-core, running locally should be faster in any case.
>> "I was totally surprised by this, because it means that a (mostly) fully-functioning bot capable of playing arbitrary games of Magic: The Gathering has a small enough footprint to run locally on your machine"
> I dont get that. Maybe I am missing something. Lets say, the MTG AI was so intensive to run that it would be unreasonable to run on the customer's machine - then I wouldn't run it on the server either [...]
They said "footprint", not "processing power". The bot's rules engine is small enough to run in the memory footprint on older iPhone or Android devices, a server could have a lot of memory dedicated to holding a state machine or rules engine and still use very little processing power to execute the engine for any particular request.
His point wasn't that an MTG bot should be easy to run, his point was that it shouldn't be any easier/cheaper to run server-side than client-side.
But to address your point, while that is true, Sparky itself plays with very basic decks, and plays even those very poorly. The goal of Sparky is to introduce players to the rules, not to be a competitive MtG agent; playing badly is intended. I wouldn't be surprised if Sparky's code is actually just a bunch of very simple heuristics (maximize your mana utilization this turn, attack with any creature that can trade evenly or better, etc).
Congratulations again for the top story, Daniel! I was hacking on MTGA since you posted this article and spoke a little about that with you on GitHub [0].
For anyone interested, I'm _inactively_ working on an unofficial client of MTGA which does hardly anything meaningful for now. The vision is to provide some automation for playing ranked games and stronger bot opponents. Sadly I was distracted lately away from the project and am still puzzled how to make a good UI to see things clearly. I can't even estimate when it will be barely useful.
Beside that, I'm still very interested in any game hacking story of Daniel and anyone else! Please tell me more about how to spot such bugs, how not to worry being banned after such hacking, how to `disclosing the bug to them` like @aethros commented, how to structure an unofficial card game client, and other stories. Thank you!
> I would have thought that a game as complex as MTG would require a lot of overhead in terms of creating an AI opponent. But nope! You can actually check out all of the logic for Sparky, including a few places in the debug UI where WOTC developers reached a corner case that they felt was not worth implementing. I don't blame them - MTG is a beast of a game to try to have full coverage for!
This is a huge understatement, since the game is nearly (no infinite loops) Turing complete, and people have a lot of fun with that. I assume there's a lot of work already done on AI strategy for it though.
The post title should probably have a "Show HN:" on it too, since you're posting it yourself.
"The game can be used to encode a Turing machine" is not at all the same as "it is difficult to write a program that can play a legal action in every situation". It's the latter that seems to be difficult for the bot authors.
> "it is difficult to write a program that can play a legal action in every situation"
This is trivial (just forfeit).
The hard part is figuring out the best possible action to select from. MTG is particularly hard at this because:
* Some actions are only allowed in certain conditions (e.g. in response to, in a specific phase, etc)
* Actions vary significantly not only in their effects but also in their inputs (some require targeting a creature, a player, an opponent, a card in hand, a card in exile, a name of a card that could exist). Some have a varying list of inputs (target many creatures). This variance makes it hard to encode the action space.
* The state space is huge. It is not only determined by the cards in play, but is also affected by the meta-game (to play optimally players have to play in a specific way to avoid getting countered by a card that could be in play by the opponent, because that card is legal to play and is commonly used by decks that look like what the opponent is playing).
* Technically the state space is also infinite because you can create infinite loops that keep creating more and more triggers/creatures/etc.
The game is constantly changing because new sets are rotating through, but I believe it is possible to create infinite loops with certain dynamics, or at least it has been possible at various points. ie. something like creating/killing token characters with "on entry"/"on exit"/"untap" mechanics, etc. Not all of them result in either player taking damage.
The rules explicitly address infinite loops and forbid players from forever taking actions that create one. If one would occur anyways, the game ends in a draw.
There are multiple unresolvable game states (panglacial wurm...) but there are catch all rules which allows judges to say 'you're not trying to win, so your blocking line results in a game loss'. They have banned cards before (painter's servant) which resulted in competitive non-deterministic winning sequences that forced hundreds of game actions to resolve.
> 'you're not trying to win, so your blocking line results in a game loss'.
Is that how it goes now? It used to be infinite loops (e.g. playing a Faceless Butcher when the only creature in play is a Faceless Butcher that exiled another Faceless Butchers) resulted in a draw, not a loss.
Forced infinite loops are still a draw, but setting up a complex-enough board state where the infinite-ness or forced-ness of a particular loop is hard for the judge to decide on will just result in a game loss.
Put another way: you can try to set up a game state in a competitive match where the judge has to solve the Collatz conjecture, but because that would take way too long and clearly be contrary to good sportsmanship, you'd never reach that point.
The halting problem does not forbid us from discerning if SOME programs will ever halt. It says that there are definitely programs for which we cannot know.
I suspect most of the MTG infinite loops are something like "A triggers B, B triggers C, and C triggers A". Asserting that the loop will never resolve is not a violation of the halting problem.
Absolutely, but assuming that magic the gathering without the rule about loops is turing complete, then it's possible to set up all programs in magic the gathering, not just nice ones. In particular there exists a program where it is impossible to tell whether it is in an infinite loop or not without solving the halting problem.
The rule cited is worded to only apply to loops that go on indefinitely (machines that don't halt), so the referee can't even know whether or not they're allowed to apply the rule against a without knowing if it halts. On the particular machine mentioned above that would require solving the halting problem.
And yes, I'm sure the people saying "they'd just kick you out if you tried this in a tournament" are right. That's really not the point. The point is the cited rule doesn't really make things better with respect to turing completeness. If magic the gathering without the cited rule is turing complete, then with it it's both just-shy-of-turing-complete* (you'd be able to run any program that does halt) and uncomputable.
* Depending on the precise definition of "turing complete" it might in fact be turing complete. You can evaluate any program. Either it does halt and you can report the output, or it doesn't halt and you can report that you're in an infinite loop because the referee-oracle said so. That's probably enough to satisfy most definitions - even if it's a strange way to implement it.
Probably not, the infinite loop rules are specifically about rules where a player cannot make a choice in the process.
It's possible that there's a way to do something turing-challenging or busy-beavery in such a situation, but it's usually pretty difficult to make complex unbendable loops, they're usually very direct cases where taking an action more or less forces you to immediately take the same action again, so the loop has...two steps. Anything much bigger or more complex and you're basically assured to have player choice.
There's probably room to do something where a player is clearly losing unless they do something which might continue a situation that is undecidable.
If you have two choices for spend/untap, I think it would be fairly trivial to create Turing complete logic that also presents discretion and requires involvement from the player. However, it sounds like such an arrangement can still considered a draw in “competitive play”. There are many formats to Magic, though. If any other Turing machine had an outside observer ready to pull the plug after an arbitrary amount of time, does it make it less of a Turing machine?
Semantically, yes. Turing machines (actual ideal ones that only exist in maths papers) always compute forever. They are also instantaneous and have infinite resources.
The argument is that MtG is Turing complete except for that part, because it cannot compute forever, even in an ideal scenario where time and space are infinitely available, because the rules explicitly forbid it.
An ideal Turing machine with someone to pull the plug is not a Turing machine. Also: just because humans can recognize some infinite loops doesn't mean we can recognize all infinite loops, so the person pulling the plug may be misinterpreting and pulling the plug on a machine that would otherwise eventually halt.
> Ok, so instead of being turing complete it requires solving the halting problem to properly referee it?
No - because the referee doesn't have to devise a program to do it. They can decide whatever they want. Also the statement of the halting problem isn't about it being impossible to tell whether a program will terminate, it's about it being impossible to devise a program that can tell whether any other program running on a turing machine (which actual physical computers are not, since they have finite state) will terminate.
For any program running on actual physical computer hardware it is obviously possible to tell whether it will terminate. For an actual game of magic, which has considerably less possible state, it's likely even trivial 99.9% of the time. The remaining 0.01% are up to the judge. In the case of MTGA on a computer, there are hard-coded limits on many things (but a lack of enforcement of the first part of the loop rule. Nexus of Fate wasn't a good time.).
It is absolutely not true that for any problem on a real computer it's possible to tell if it terminates, other than fairly trivial observations such as noting that if it runs longer than 2^(size of memory) steps it must be looping.
If you could, then I'd start using your "real computer" halt checker to instantly mine bitcoin or break all cryptography, so let me know when you figure out out.
MTG doesn't require solving the halting problem because, if neither player nor the referee can come up with a way to halt a loop, then the match ends (long ago, when I played, it ended in a draw; other comments in this thread suggest that a player intentionally doing this may incur a loss now).
2ⁿ > n ∀n ∈ ℕ (n>1), therefore while the test is trivial to define for any finite system, in practice you can't do that many steps even for very small n — n=256 states is 2^256 tests is just shy of 2e26 years if each test takes one Planck time.
For a purely theoretical system (which includes the abstracted rather than physically implemented rules of MtG as used by Churchill, Biderman, & Herrick in their paper), n is effectively ℵ₀.
We don't actually need to know whether something will result in a loop ahead of time, so there's another approach which is much more doable in the context of MTG: Most digital CCG engines already record every past state through a history of actions (some even have full match replays). Together with engine-limits on recursively triggered actions, it really isn't that much data. You can check for repeated state here.
The most naive implementation would replay the entire previous match every time a new action happens. A better implementation realizes that you don't need to - because once you have one repeat, everything after should be a repeat as well, so you really can just keep running and merely check for repeats at strategic points (such as between turns or on any human input). Store the serialized state at those points in some appropriate Set implementation to make checking easy and fast. Increase the spacing between those checkpoints, deleting old ones, if space becomes an issue - though if you get to this point, the game has run for so long that the humans playing it probably need medical attention.
If you want to get even fancier, store serialized state rarely and just store hashes of state at checkpoints, replay from a serialized state using recorded inputs once you detect a collision.
All of this is possible because of the human element: Human just aren't physically capable of producing enough input to make a computer sweat about recording it.
One downside of this approach is that it requires some programmatic refeering in case of "numbers go up" scenarios if you don't want to wait for some player's health pool or token pile to run into the engine limit and keep the game to a length a human can enjoy (do you cap these for comparison? compare with low precision? only allow a decrease?). There's some other scenarios that will not repeat exact state until a human died of old age too. However in real life magic "Loop" is not such a narrow term - just one number being slightly different will not save you from having to explain yourself to the judge.
n.b. I think some of your misunderstandings and invokings of the halting problem are nerd sniping people here. One in particular that got me was:
> For any program running on actual physical computer hardware it is obviously possible to tell whether it will terminate.
You can't tell if this program will terminate:
import random
while random.randint(0, 100000) != 4: pass
You can intuit why that's the case (nothing at all says that random.randint ever has to return 4, or that it will never return 4), and from there you can probably also get to why it wouldn't be possible to write a program to tell you if this program would terminate.
> You can check for repeated state here.
> because once you have one repeat, everything after should be a repeat as well
> just one number being slightly different will not save you from having to explain yourself to the judge
Yeah see, I think you're seeing the problem here. Computers are pretty particular about equality: even if your states are only slightly dissimilar they're still unequal. I think you're outlining some various heuristics you might use, but those clearly aren't perfect.
And FWIW, a single repeat doesn't mean infinite repeats. There could be some outside state (an RNG, a counter) that's being updated, or literally an enchantment (function) that says "if the state of the game didn't change at all last iteration, gain 30 life". See you're thinking about states, but you're forgetting about the state machine, which can respond to unchanging states just as easily as it can respond to changes. Your heuristic also fails if you get into a loop that iterates through 2 or more states.
But I think on some level you know this right? That's why you point out that AFK there's a judge and in most game engines there's some kind of execution counter that bails if something takes too long. This stuff is related to the halting problem but they're not solutions to it, they're submissions to it.
No. Just don't use outside state? Obviously you can just make the state of your PRNG part of your overall state as well. For an actual computer it is: It's sitting somewhere in RAM.
Also remember we're trying to reason about computer programs before you come up with ideas like measuring physical phenomena.
Allowing for dicerolls going different ways is an interesting problem though (from the perspective of trying to make a playable game). Since we know whether any happened between the two states we care about, there are multiple approaches. In the case MTG, which doesn't have many dice mechanics, I'd probably just wait until we have exhausted each possibility, where possiblities means each computed direct outcome, not each possible diceroll. This lets us cut down on "gain X life" outcomes with our heuristic judge (2000 + 3 would be the same as 2000 + 2 to us). Most cards with dicerolls only have 2-3 outcomes, even if they roll a d20.
> or literally an enchantment (function) that says "if the state of the game didn't change at all last iteration, gain 30 life"
There's no problem here if you consider the last iteration part of the state of the current iteration. Attach that previous state (sans recursion) to the state of the enchantment on the field. You'll need it to code that enchantment anyways.
> but you're forgetting about the state machine, which can respond to unchanging states just as easily
It becomes quickly obvious that a FSM itself can't detect that its own state didn't change between the previous two iterations and make that affect the next state.
Simple example:
function FSM(previousState: number): number {
if (stateDidntChange(previousState)) {
return 0;
}
return blackbox(previousState);
}
How would you implement stateDidntChange, so the FSM's state becomes 0 when state was the same for two iterations? You may think you can move the if clause after the blackbox state computation and compare the return value, but then you merely prevent the machine from having the same state twice in a row, and are not responding to it actually having happened.
To illustrate, let's assume blackbox always returns 2. You can never make the return value of FSM be 2, 2, then 0.
You would have to add more state to the FSM to detect this, but then you'd have more state you need to compare!
Now if we just want to compare a subset of the state, that's fine. We can do that by storing a copy of the previous state in the overall state - but doing it like that also causes no issues with my proposed loop detection.
> No. Just don't use outside state? Obviously you can just make the state of your PRNG part of your overall state as well.
You can't write a program to analyze any given PRNG (or whatever) to know what it will return when without executing it. You could do this for some PRNGs, but that... probably doesn't meet the definition of pseudorandom.
> Also remember we're trying to reason about computer programs before you come up with ideas like measuring physical phenomena.
Oh I think if anyone's doing this it's you: one of your argument's main legs is that you can analyze RAM usage.
> In the case MTG, which doesn't have many dice mechanics
Yeah the last I played was Homelands so I'm very out of date. If we restrict ourselves to MtG then yeah, I think dice probably aren't insurmountable. For instance, dice are pretty limited RNGs, so you can easily interpret them as ranges to limit the scope of states you'd need to track, and you can do even better if they're just numeric values (i.e. it's always like "add N health" or "add N * 2 health") instead of branches (N <= 2 you lose, N >= 4 you win). This is modelable in finite space, and as you point out the space in general is pretty small. So, yeah sometimes the domain can allow you to avoid theoretical pitfalls.
> Attach that previous state (sans recursion) to the state of the enchantment on the field. You'll need it to code that enchantment anyways.
I'm not super sure what you mean here. I've been thinking of state as like, what cards are in play/hands/graveyard/etc, (tapped) lands, counters, turn, life, phase, and so on--basically whatever you would save in a game save to restore it later. I guess maybe you're thinking you can save something like a triggered or didn't trigger flag on every enchantment as part of your state, but this only works for the "check last state" enchantment, not a "check the last 10 (or N) states". Again I'd be very surprised if there were ever a card like this, so we're purely in the wider realm of the halting problem. My only point here is that there's, as Wikipedia puts it, always a theoretical pathological program (enchantment) to do the opposite of what your heuristic analysis program expects it to do, such that it's not possible to write a general analysis program to see if a Turing complete program will halt. I think the answer re: MtG is: don't print that card lol.
> How would you implement stateDidntChange
Nah let's not get confused here. States are successive, not recursive, i.e. they can refer to each other ("last turn", "after untap") but they can't contain each other. Re: implementation, generally the execution engine has some container of states it can access in various ways (previous, first, current, etc) and things in the program/game can access them. In this way you can then check for changes, because you now have access to more than 1 thing.
But, yeah you can get around this by just limiting the number of states you'll store that haven't changed, and not printing cards (writing expressions) that refer to states outside that limit. This is what a lot of in-game scripting engines do: if you've run N bytecode ops or for M seconds without finishing, you're looping infinitely (even if you might not be) and you're killed. Hardware watchdog timers do a similar thing. So, I think overall you're right that in practice we deal with the halting problem in arbitrary ways all the time and it's very OK, you just kind of have to outline the kinds of valid programs you're disallowing.
> The most naive implementation would replay the entire previous match every time a new action happens. A better implementation realizes that you don't need to - because once you have one repeat, everything after should be a repeat as well, so you really can just keep running and merely check for repeats at strategic points (such as between turns or on any human input). Store the serialized state at those points in some appropriate Set implementation to make checking easy and fast. Increase the spacing between those checkpoints, deleting old ones, if space becomes an issue - though if you get to this point, the game has run for so long that the humans playing it probably need medical attention.
Any test of this type only works if there is a repeat, which you can only know about if you have a finite machine, and even with finite steps it takes 2^n steps[0] to be sure you've hit an infinite loop. Even in a computer, even with a fairly small deck to build the state, you'll time out on things like the stars going out before you can rule out any loop.
And there isn't necessarily any repeat at all in the unbounded case. The state is recorded by 18 types of card, where "moving" left or right along the tape modifies the number of hitpoints on each card. At that point, I think you can still kinda decide if it halts or is infinite with the Busy Beaver number, except only "kinda" because now you run into the problem that the Busy Beaver number itself isn't generally computable because of the halting problem.
Also the lower bound S-number for a mere 2-state 6-symbol machine, let alone the 2-state 18-symbol one in the paper, is already 10⇈10⇈(10^(10^115)), which is so much larger than the Poincaré recurrence time of the universe (even when measured in Planck times) as to make those periods themselves to be infinitesimal rounding errors.
> All of this is possible because of the human element: Human just aren't physically capable of producing enough input to make a computer sweat about recording it.
In practice, it's the opposite problem: for both humans and computers, even if you already know what it's going to compute and it's only doing something simple, it takes ages to get through enough states to say either way. It's a very slow Turing machine.
[0] well actually[1] it's something more like min(2^n, BB(2, 18)), but BB numbers grow so much faster that in practice they only matter for infinite tapes
[1] I've probably got this wrong, like getting the m and n switched around because the terminology doesn't seem to be entirely consistent, hence me starting that footnote with the traditional catchphrase for someone about to say something stupid :P
> They're referring to the halting problem. If you believe you can solve it, you will win money.
Proving that you can programatically determine whether a program halts when you limit the turing machine to finite memory is trivial - which the conversation you interjected was about.
They weren't saying the problem was trivial. They were saying that if you massively reduce the problem to its most trivial form, then its trivial form is doable.
Is there any practical strategy that approaches this complexity at all? I have never played. But I assume this claim is just that you can technically create some stateful stuff if you’re explicitly not trying to win
Turing machines? Not really. Infinite loops[0]? All the time. The designers generally try to avoid those being legal in "Standard" unless it's extremely unlikely to happen (only the most recent few years of cards are legal in tournament play. In casual play anything can be legal if your group is okay with it).
A common trope is to have a card that allows you to create mana, and then a way to infinitely bring that card back from the discard pile, allowing for infinite mana. Then you play a card that says something like "spend X mana to deal X damage" and you deal a trillion damage.
[0] the above commenter is correct that a true infinite loop is not allowed. But you're allowed to create a scenario where an infinite loop happens according to a repeating choice you can make (essentially a while loop) and repeat as much as you want within the match timer while still allowing time for your damage card. The general etiquette is just to say "I can do this a billion times and so I deal a billion damage".
I've actually been at a local (mostly informal) tournament where someone with an Elf deck managed to pump their life into the thousands (you start with 20 or 40 depending on the ruleset), and his opponent with a Goblin deck got an infinite combo for infinite damage. But the Elf player refused to accept "I can do this infinity times" and made him actually try to perform his card combo over a thousand times before the round timer ran out. Goblin deck did not win.
> I've actually been at a local (mostly informal) tournament where someone with an Elf deck managed to pump their life into the thousands (you start with 20 or 40 depending on the ruleset), and his opponent with a Goblin deck got an infinite combo for infinite damage. But the Elf player refused to accept "I can do this infinity times" and made him actually try to perform his card combo over a thousand times before the round timer ran out. Goblin deck did not win.
So the Goblin-deck owner allowed the Elf-deck owner to do a "I give myself 1000 life" with a combo but the Elf-deck owner wouldn't let the Goblin-deck owner do the same with damage? That's kind of a jerk move if so.
If the Elf can give themselves infinite life in response to the infinite damage, then they have essentially won, because however much damage the Goblin would deal, they can just go "OK, but before that damage applies I give myself enough life to survive". The Goblin deck can never reach a game state where they win.
If the combos are sequential and the Elf has to commit to a certain number of life before the Goblin commits to a certain number of damage, then the Goblin would win.
There are some other possible intricacies (can they give themselves 1 life infinite times? or infinite life once?) From the mechanics of how the game usually goes, I would assume the first case applies here.
The way match/tournament rules work, when you have an infinite loop you can pick any number of iterations, but it has to be a number, not "infinity". Which means that the interaction of two infinite combos comes down to which one occurs with priority over which other.
If the elf deck can gain "infinite life" at instant speed, then they'd win over a goblin deck that can deal infinite damage at sorcery speed, because whatever number the goblin player picks, the elf deck can pick that number squared, for instance.
If both players can combo at instant speed then it's an impasse and they have to jockey for who can put their opponent in a position where they're tapped out, etc.
> If the combos are sequential and the Elf has to commit to a certain number of life before the Goblin commits to a certain number of damage, then the Goblin would win.
I agree that in formal tournaments this would happen, but the comment I was responding to was about a "casual tournament." I was assuming the 1000 life was with a sorcery (e.g. infinite mana combo + stream of life). In casual play, shortcuts are only when both sides agree, so it would be a jerk move to not agree to one that benefits your opponent after your opponent has agreed to one that benefited you.
An interesting result of how MtG handles infinite loops plus how it handles priority is that in a scenario where two players attempt to go infinite whoever gets to name their number last wins. And that most infinite loops are non-reloadable, in that when you stop repeating them, you can't restart them for free. I have seen a game that was lost because one player had an infinite life combo, named "a hundred trillion" and wrote their life total down on a piece of paper, and later in the game an opponent who had apparently mis-heard "a hundred billion" and didn't think to check only elected to repeat their infinite combo a trillion times.
So the moral of this story is, uh, always name Graham's number. Or don't because I'm not sure what a Judge is to do if two people name numbers so large that the Judge can't work out which one is bigger on a pocket calculator.
(I think that in a Comp REL game, in your scenario, the Goblin player should have won unless the combo was non-deterministic.)
I'm not terribly familiar with tournament rules, but AFAIK in paper games you can always shortcut truly infinite actions by picking a number and the opponent has to accept it, it is not just etiquette.
This is only true if the series of actions you take in the combo are fully deterministic. If the combo includes non-deterministic steps (usually anything related to deck shuffling) you can't use shortcuts and have to actually perform the steps.
It's a bit of a can of worms (but you're right, I should have said "deck/discard pile manipulation").
Shortcuts are supposed to be used to speed up and smooth play, there should be no information exchange, and so as another person pointed out this is about being able to describe all intermediate game states. If shuffling means you will reveal (seemingly) irrelevant but arbitrary information about your deck (e.g. cards that are no longer in it because they were discarded), you can't describe the intermediate game state beforehand (it is random) and the other player can't make an informed decision about whether or not they'd interrupt. And if you could infer from their refusal that there is a situation they might interrupt, you'd have extracted information you shouldn't have had access to. Hence in tournaments it is not allowed.
The deck shuffling is relevant due to other factors. There is a card in the combo deck that reshuffles the discard pile into the deck when it's put to discard, and the deck revolves around (as a shortcutted, freely undertaken combo) dealing one damage every time a certain creature goes to the discard pile. As you re-shuffle every time the 'engine' piece is hit, you can't predict how many times you need to activate the discard combo, so it cannot be shortcutted. Shortcutting in magic requires stating exactly as many iterations as will occur and the clear end state.
Slow play is the phrase explaining why indeterminate combos don't get shortcutted. "An indeterminate-loop combo may take anywhere from fifteen minutes to fifteen hundred years to actually succeed, and we really do not need to be waiting around to see which it's going to be."
It's not that easy. There are strategies but they depend on the game format (standard, legacy, modern, etc) and on a deep understanding of the game meta. You cannot devise a strategy that works under any conditions. Lookup the rules + understand that new abilities and cards are introduced all the time.
I'm not sure what level of complexity you're looking for, but there are some pretty complex combos that have been viable over the years, even in formats that don't use some of the older "broken" cards. One popular strategy for a while in the "Modern" format, which doesn't allow cards for the first 10 years or so of the game, used a mechanic called "Storm" where a spell would be copied for every spell you previously cast in the same turn. A card called Grapeshot had this ability and did 1 damage, so the deck played creatures that made your spells cost less mana and spells that gave you extra mana or draw cards, and the goal was to cast 19 spells and then grapeshot your opponent for their entire starting life total of 20, often as early as on their fourth turn. It was consistent enough that it was a staple in the format for at least a few years (although I haven't kept up with the meta as much for a few years now). Another higher variance but potentially even faster combo used a creature called Griselbrand, which let you pay 7 life to draw 7 cards, a bunch of mana "rituals" like storm, and used a card called Nourishing Shoal to let you exile certain cards from your hand to gain life. The win condition was typically to draw at least 7 lands and cast a creature that let you discard a land to do 3 damage, and it could potentially do this on the very first turn, although eventually one of the cards that was necessary for it to function got banned in modern, although by then Griselbrand decks weren't really ever played due to there being far more consistent options with better ability to deal with an opponent trying to thwart their game plan. If you include Legacy (which allows cards from any point in the history of the game but still with a custom ban list) or Vintage (where all cards are allowed but some are "restricted" to only one copy instead of the typical 4 per deck), there are even more powerful combos you can take advantage of.
Combo decks have always and likely will always be a part of the meta for most formats, although to varying degrees depending on how many cards the format has available and how effective it happens to be in the current meta. It's considered one of the three main deck archetypes along with "control" decks that attempt to shut down what the opponent is trying to do and slowly build an advantage over time and "aggro" which use a more straightforward approach of just attacking the opponent with creatures or spells (or both). Not everything cleanly fits into one of those strategies of course, and even a deck that has a win condition that fits into one archetype might dip into the other as a backup plan (e.g. a combo deck with control elements that help it buy time if it can't get off the combo as quickly as it would prefer, or a control deck with some efficient creatures that it can use for a surprise attack if the circumstance makes sense), but even in a setting like playing a few games at a card shop on a Friday night, seeing a combo deck with the level of complexity described above isn't really uncommon at all.
That said, I've read that a lot of the hardest cards to program tend to be the ones that subvert the basic expectations of the game. One infamous example that comes to mind is a creature that after being cast added an extra turn after yours where you controlled your opponent, after which they took their regular turn and the turn order resumed its previous alternation. Programming that would require adding in the ability to show one player's hidden game state to the other, let them make any sort of decisions using their cards that the player would normally do (short of literally conceding the game) and inserting an extra turn in the order with that weird control mechanism...all just for one card out of tens of thousands! Obviously most cards are not that complex, and Arena specifically doesn't attempt to support literally every card in existence and instead supports cards going back to its initial stable release along with explicitly chosen cards added to special Arena-only sets in order to introduce them, but when its an explicit rule that the text on the card overrides the normal rules of the game when they disagree, it very quickly gets to the point where you need to consider that there will likely be an edge cast for almost any possible state transition.
Arena's rule engine was explicitly not based on Duels; this was a big selling point when it first launched to replace Duels, and they've gone into some detail since then describing how it works. See https://magic.wizards.com/en/news/mtg-arena/on-whiteboards-n... for instance.
The AI player just casts the first card it has the mana to cast, regardless of if any normal player would do it. As an example Sparky will gladly cast a kill spell on their own creature if the opponent has none, or cast protection spells on the opponents creatures if it has no creatures itself. This is far different than duels of the planewalkers.
On a related note, I have a blast playing old school magic 93/94 with my son. Of course using physical cards. We travel to Madrid each year to participate in the world championship of 7pts Singleton. This summer my son placed #9 which I am very proud of. 7pts Singleton is such a wonderful way to play the game with diverse affordable deck-building and balanced gameplay ( https://7pts-singleton.com )
I wouldn't call a format where Black Lotus, Ancestral Recall and the Moxen are legal "affordable" - even though you can't play all of them in 7pts Singleton, even any single one of them costs thousands (or tens of thousands) of dollars. However, I'm glad you and your son enjoy the game, and congratulations on his placement.
Yes, I agree. And we don't own them. I find it a very stimulating intellectual exercise to construct a deck without those cards and still perform great. Those powerful cards have several points and only 7 points total are allowed in your deck. For example I currently choose to play Sol Ring instead of 2 of the moxes.
You can get professionally printed proxies [1]. I've been told there's often a "don't ask, don't tell" policy around many unofficial mtg tournaments regarding proxies. It obviously upsets some people, but others see it as requirement for new players to enter legacy format (and keep it alive).
I've been told that many players buy counterfeits specifically for old school tournaments so they don't put their very expensive pieces at risk to theft or damage. I can't verify this, but it makes a lot of sense to me ¯\_(ツ)_/¯
> Proxies are allowed. We encourage the use of easily recognisable proxies as long as they are undetectable under sleeves and are easily recognizable and nicely made, but no counterfeits!
A proxy can be as simple as a basic land with Sharpie writing on it, so this format is by definition as affordable as Magic can ever be.
Exactly. Except that they should be easily recognizable and nicely made. So for example a basic plains that you draw over and make look a bit like the card is very recommended.
Official MTG tournaments "allow" proxies, cost is not and never has been a prohibitor to any paper magic.
WoTC as a card distrubtor on the other hand, does not agree with this. Thankfully they have no input on the matter. And is why they push the online avenues as much if not more than paper.
This is categorically false - any WPN/DCI sanctioned tournament forbids proxies except in extremely limited circumstances:
Section 3.4 - Proxy Cards
A proxy card is used during competition to represent an otherwise legal Magic card or substitute card that can no longer be included in a deck without the deck being marked. For a proxy to be issued, the card it is replacing must
meet at least one of the following criteria:
• The card has been accidentally damaged or excessively worn in the current tournament, including damaged or misprinted Limited product. Proxies are not allowed as substitutes for cards that their owner has damaged intentionally or through negligence.
• The card is a foil card for which no non-foil printing exists.
Players may not create their own proxies; they may only be created by the Head Judge who has sole discretion as to whether the creation of a proxy is appropriate. When a judge creates a proxy, it is included in the player’s deck
and must be denoted as a proxy in a clear and conspicuous manner. The original card is kept nearby during the match and replaces the proxy while in a public zone as long as it is recognizable. A proxy is valid only for the duration of the tournament in which it was originally issued
It is not categorically false, as evidenced by your quote which says they are allowed plainly, and as I caveate'd my statement with quotes. Perhaps we should replace "proxy" in my statement with "clones".
WOTC, judges, players, do not check for "dupe/clone" cards. How can they? why would they? To prove the player/opponent is poor in this individual set in the middle of a tournament?
When we're taking about proxies in sanctioned tournaments, we are not talking about what WotC is talking about:
No one declares at tournaments "This is my proxy" and presents a hand drawn liliana, that then prompts the inspection you quoted in which the judge has to unsleeve my very valuable card for the judge to inspect, and can only be used for the tournament. What a waste of time and lack of professionalism, for no reason. WotC would stop paper magic tournament support.
Instead they play a "liliana of the veil", in mint condition holo somehow, and we all know what's up.
Players fake/clone cards very easily/well, for obvious reasons. You would not be able to determine my commander deck is entirely "fake". There's no mechanism in tournaments to prove it. I simply don't want to support Hasbro/WotC and TCGPlayer admins.
I assure you, as a frequent bottom 2048 loser of these sanctioned tournaments, every single player is playing with clones, WotC is aware, and they would be foolish to enforce any ruling on that.
I once developed a small game. Sometimes, for responsiveness, you need to implement game logic on the client. But nothing says you can't redo the logic on the server and that's what I did.
It can be hard on a real time game like FPS or RTS, but there simply is no excuse for a card game.
I think for a card game like this you really want to send no more information to the client than a real player would see. So for example, rather than send the cards that the opponent has in hand, just send the number of cards that he has -- no more and no less than what you would see in a real game situation.
It goes without saying that any actions sent to the server are only speaking for you and not your opponent. So no, you should not be able to declare forfeit for your opponent. You should only be able to say "forfeit!" which the server interprets as your forfeit because you are the only player you have power over.
I'm pretty sure the article declares the game was programmed in exactly the way you are suggesting it should be, where you only get the information required at the time it's needed, and you only send actions for yourself.
The exploit was that one was able to set up a second client and connect to the currently ongoing game but in the opponents seat, once this was done they could sene actions as the opponent including the forfeit action.
> It can be hard on a real time game like FPS or RTS, but there simply is no excuse for a card game.
As the article clearly states, the game play is entirely server side. The author exploited a problem in the authorization and game connection code, not any client side game logic.
> It goes without saying that any actions sent to the server are only speaking for you and not your opponent. So no, you should not be able to declare forfeit for your opponent. You should only be able to say "forfeit!" which the server interprets as your forfeit because you are the only player you have power over.
You are simply repeating how exploit that the author found works.
In League of Legends there was a division-by-zero bug with a certain champion and item which caused server to kick all players and then crash. Because the exploiter was being kicked last, their team gets the win while opponents get Loss Prevented because the game doesn't have a normal result.
IIRC it was added to the game because of serial leavers (and cheaters, which is funny with this exploit) and then sometime later applied to deal with server instability issues.
I love the accessible yet insightful level of detail in this post.
One thing I don't understand is, in the case where you connect your bot during a real match, 1) why does the game allow someone to join mid-match, and 2) when the bot resigns, why does that count as your opponent resigning? If it's creating a 3-player game, Player 3 conceding shouldn't also make Player 2 concede.
> If it's creating a 3-player game, Player 3 conceding shouldn't also make Player 2 concede.
It stays a 2 player game, his code has to figure out which "seat" index his account is, and then has the bot join the other seat index.
The problem is that they're not validating that the joining user is the correct user that should be in that seat.
There's also the thought that you shouldn't allow a player to connect to an already connected seat. But since this game is also available on mobile, you probably want disconnection timeouts to be fairly long, and you don't want to interrupt a player who briefly disconnected and then reconnected before the timeout has recognized their early connection is broken. I've seen this in other games, where you try to reconnect and get a "cannot join game in progress" for about 10 seconds until you're actually able to reconnect.
Basically imagine showing up to an MTG tournament at your local game store, pushing someone out of their seat, sitting in it and shouting "I concede!". And then the judges agree that player B forfeited the game because the person in their chair declared it.
Thanks for this simple explanation! I got distracted by the [FULL VERSION] Magnus Carlsen Blind & Timed Chess Simul at the Sohn Conference in NYC (https://www.youtube.com/watch?v=xmXwdoRG43U) video and now I'm late for dinner!
1) I'm guessing this is how they handle people reconnecting after a disconnection. You terminate the old connection?
2) The bot replaces player 2, then submits a resignation. The server registers it as player 2 resigning.
Yeah, the seat is the problem. There are a LOT of security systems that depend on assuming the holder of a large random string, like a guid, is the proper holder of that string so it's not necessarily a bad thing for the match. They should have made the seat index random as well though they are probably now just checking credentials.
MTG: Arena doesn't allow three player games, so what the bot is doing is joining _in_ the opponent's seat. Presumably this is why it can concede on their behalf. I guess the game doesn't check for this because its developers didn't see why anyone would even care to try.
This takes me back to the Diablo 2 days when you could connect an open server character (LAN) onto the official bnet (internet) servers by reusing the same connection packets. Since open server data was all saved locally, you could create all kinds of items that aren't supposed to exist and the official server would still accept them.
Lol, i recently got into MTG again with MTGA. I did a quick decompile as its a Unity game and not il2cpp (not that it would have protected it that much) but I found some fun stuff too. Keys for their epic launcher build, some undocumented apis.
I never wanted to use it to cheat, i really just wish there was a battle log. What matches I won, what I lost, view the battlefied of a finished game, etc...
Gonna check this out, but hopefuly its patched quick.
This vulnerability was patched before I wrote the post - I disclosed it to MTG.
In terms of viewing your history, you should check out https://untapped.gg/en. I have talked to them a bit and they essentially do what you want. They take most of their info from MTG's debug log, which you can find in MTGA's application directory, so you could also make your own tracker as well if you want. They talk about it on their site: https://help.hearthsim.net/en/articles/3620440-how-do-i-supp...
What is the Twitter post for? I'm assuming this was not you "disclosing" it to them, but it's basically some kind of advertisement for yourself? You did contact them via a proper, private channel to disclose and make sure they fixed it before the Twitter post, correct?
They didn't respond to my email so I tried twitter. That got a prompter response! No details about how to actually perform the insta-win are visible in the video so I wasn't too pressed about someone replicating it from the tweet
What was the process like disclosing the bug to them? One part of your post that you left out and I was curious on. Was it friendly/straightforward? Were they surprised at all that this was possible?
Pretty nondescript. I just sent them the code and explained how to replicate it. They said they'd patch it and then they did haha. They offered me some in-game currency as a reward (20,000 gems, which I think is equivalent ~115 bucks).
https://www.17lands.com/ collects your limited game win/loss stats, and it also records your turn-by-turn game history for both limited and constructed games. (I was a contributor)
You can just use Cockatrice for that. Sure it’s not as pretty or as easy, but it supports every card since you pretty much are playing paper magic and it’s not trying to be the referee.
I think a lot of people explicitly do not want to bother with playing essentially paper magic, because it requires quite a bit more concentration if your board state is complicated to not miss any triggers or phase change too far accidentally.
There was an app called Apprentice that was popular around 1996, and that is how we would lay MT:G via IRC. It was a generic tabletop simulator and you create or import he cards.
That's very fun. This is a "simple" enough exploit that I sent it to my MTG group chat, I bet they can understand it without needing to understand any programming jargon beyond client/server.
I'm simultaneously surprised something this simple worked, and also not surprised at all. He does make a good point, this is an effective way to provide a practice bot and not need to make many server side modifications. I understand why they did it this way. The problem is they didn't make any server side modifications haha.
Edit: so far 3 of them have given me a lol or laugh emoji. This is excellent writing.
This is buried but fascinating: magic the gathering is turing complete, probably even more complicated than simply uncomputable , and possibly the most complicated major real world game
Wish we could hack the card-shuffler for MTGA. I can't remember the last time I had a match where at least one of us didn't have either no land or nothing but land.
My understanding is that at the start of a game, the system shuffles and draws three hands for you, and then selects one of them to be your actual starting hand. I don't know what heuristics it uses for which of the three to select, but typically in real life you would be hoping for three lands as a baseline, ideally that can tap for the colours of the spells in your hand as well.
I believe this only applies in best of 1 matches, but not best of three matches.
Unfortunately I don't have a credible source for this.
You can, but it doesn't help when your next hand is exactly the same, or the opposite problem. There's been times I mulligan down to 1 card and see nothing but land the entire way through. Probably in the same match, the opponent mulligans down to 3 cards just to get 1 land.
It's bad enough that my friend group casually accepts having to "concede" 2 or 3 times just to get a decent match going.
It does, you can shuffle and draw a new hand but then you need to put a card from your hand on the bottom of the deck (you can repeat, putting two cards on the bottom, then three, etc.)
Card advantage is massive in MTGA so people don't mulligan when they should ...
- Decompile C# for Sparky bot [a], rewrite Sparky to be a substitute online opponent, connect Sparky vs you online as if you're connecting a human in a match, have Sparky auto-concede and jack your win rate.
[a] Note I thought was interesting was: "C# is also really nice because it utilizes metadata tokens to associate elements of the compiled code with their human-readable names, which are still stored in the compiled .NET assembly. That means I can see all the function, variable, and class names that the developers wrote when they wrote their code." Which means its super easy to reverse engineer.
