[HN Gopher] I hacked Magic the Gathering: Arena for a 100% win rate
       ___________________________________________________________________
        
       I hacked Magic the Gathering: Arena for a 100% win rate
        
       Author : danielwmayer
       Score  : 479 points
       Date   : 2023-12-05 01:49 UTC (21 hours ago)
        
 (HTM) web link (www.mayer.cool)
 (TXT) w3m dump (www.mayer.cool)
        
       | chupasaurus wrote:
       | 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.
        
         | MaxikCZ wrote:
         | If the enemy doesnt get loss because game doesnt have normal
         | result, winning team should not get win aswell...
        
       | squeaky-clean wrote:
       | 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.
        
         | danielwmayer wrote:
         | Thank you!
        
         | adw wrote:
         | It's shown up in one of the bigger Magic-podcast Discords too.
         | You nailed the writing on this. And "always validate your
         | inputs"!
        
       | chrisweekly wrote:
       | Kudos for a very well-written and educational post!
        
       | w-ll wrote:
       | 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.
        
         | tayo42 wrote:
         | I'm pretty sure this exists. I think it's player log. There are
         | a bunch of apps that do tracking that use it iirc
        
           | blargpls wrote:
           | There is mtgatool, an open source app to read the logs and
           | generate a history of played games and some statistics:
           | https://github.com/mtgatool/mtgatool-desktop
        
         | Namahanna wrote:
         | https://mtgaassistant.net/ is the most common one I know of for
         | collecting your play data.
        
         | danielwmayer wrote:
         | 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...
        
           | aethros wrote:
           | 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?
        
             | danielwmayer wrote:
             | 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).
        
               | EdwardDiego wrote:
               | I hope you have the blingiest cards ever now, great write
               | up.
        
         | maxwindiff wrote:
         | 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)
        
       | ProjectArcturis wrote:
       | 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.
        
         | virgildotcodes wrote:
         | 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.
        
           | ProjectArcturis wrote:
           | Ah, makes sense. I guess they just assume that any client who
           | is requesting to sit in that seat is authorized to.
        
             | knallfrosch wrote:
             | Looks to me like they only verified match ids, not the
             | seats at all.
        
           | Ensorceled wrote:
           | Yes, I had my desktop version of MTGA hang and when I
           | connected to the match with my iPhone it immediately
           | disconnected the desktop.
        
         | YawningAngel wrote:
         | 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.
        
         | squeaky-clean wrote:
         | > 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.
        
           | Vicinity9635 wrote:
           | 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!
        
       | r1ch wrote:
       | 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.
        
       | althea_tx wrote:
       | Great post. Thank you for highlighting that hilarious code
       | comment.
        
       | hfuaiobfa wrote:
       | 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!
       | 
       | [0]
       | https://github.com/MayerDaniel/mayerdaniel.github.io/issues/...
        
       | extraduder_ire wrote:
       | > 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.
        
         | Dylan16807 wrote:
         | Show HN is for projects people can play with, not blog posts.
         | https://news.ycombinator.com/showhn.html
        
           | mgdev wrote:
           | The sample code plus walkthrough sounds like "things people
           | can run on their computers". :)
        
             | Dylan16807 wrote:
             | Don't make me regret removing the sentence that
             | _explicitly_ pointed out that the sample code in an
             | appendix is not the point of the linked page.
        
         | jncfhnb wrote:
         | 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
        
           | sciolist wrote:
           | Here's a paper on creating a Turing machine in Magic:
           | 
           | https://arxiv.org/abs/1904.09828
        
           | x86x87 wrote:
           | 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.
        
           | saghm wrote:
           | 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.
        
           | squeaky-clean wrote:
           | 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.
        
             | aidenn0 wrote:
             | > 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.
        
               | nailuj wrote:
               | 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.
        
               | apetresc wrote:
               | 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.
        
               | aidenn0 wrote:
               | > 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.
        
             | gpderetta wrote:
             | 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.
        
               | deredede wrote:
               | 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.
        
               | jncfhnb wrote:
               | Even if the deck shuffling is deterministically
               | irrelevant?
        
               | spicymapotofu wrote:
               | 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."
        
               | gpderetta wrote:
               | Well yes, don't bring four horsemen or Gitrog dredge to a
               | tournament. But the majority of combos are not like that.
        
             | YurgenJurgensen wrote:
             | 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.)
        
             | fishe wrote:
             | The elf player cheated, your opponent can't stop you from
             | shortcutting a valid loop.
        
           | sdenton4 wrote:
           | Let us listen to the sweet stories of Sherazad...
           | 
           | https://gatherer.wizards.com/pages/card/Discussion.aspx?mult.
           | ..
        
         | tcbawo wrote:
         | 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.
        
           | chmod775 wrote:
           | 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.
           | 
           | https://mtg.fandom.com/wiki/Loop
        
             | gpm wrote:
             | Ok, so instead of being turing complete it requires solving
             | the halting problem to properly referee it?
        
               | chmod775 wrote:
               | > 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.).
        
               | readams wrote:
               | 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.
        
               | aidenn0 wrote:
               | 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).
        
               | chmod775 wrote:
               | > It is absolutely not true that for any problem on a
               | real computer it's possible to tell if it terminates
               | 
               | Hmmm. Reading on...
               | 
               | > [..] other than fairly trivial observations such as
               | noting that if it runs longer than 2^(size of memory)
               | steps it must be looping.
               | 
               | So you are saying "You can't do it, even though it's
               | trivially obvious that you can."
               | 
               | Or maybe "If we ignore that it is possible, it is not
               | possible."
               | 
               | What am I supposed to do with your comment?
        
               | robertlagrant wrote:
               | > So you are saying "You can't do it, even though it's
               | trivially obvious that you can."
               | 
               | They're referring to the halting problem. If you believe
               | you can solve it, you will win money[0].
               | 
               | [0] https://www.claymath.org/millennium/p-vs-np
        
               | chmod775 wrote:
               | > 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.
        
               | robertlagrant wrote:
               | 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.
        
               | chmod775 wrote:
               | > They weren't saying the problem was trivial.
               | 
               | Neither was I? The proof is trivial - actually doing it
               | is very much not.
        
               | robertlagrant wrote:
               | How would you prove it in the non-trivial case?
        
               | chmod775 wrote:
               | What? Are you trolling?
        
               | robertlagrant wrote:
               | I've no idea what you're talking about. If you ask a non-
               | content free question I can help.
        
               | ben_w wrote:
               | 2n > n [?]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 0.
               | 
               | https://arxiv.org/abs/1904.09828
        
               | chmod775 wrote:
               | 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.
               | 
               | It'll stop this guy in any case: https://www.reddit.com/r
               | /MagicArena/comments/amxhnk/is_there...
               | 
               | Since what they did was reportable behavior, I suppose
               | technically human referees would eventually take care of
               | it anyways.
        
               | ben_w wrote:
               | > 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 Poincare 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
        
               | kbrkbr wrote:
               | You probably meant 99.99%, or 0.1%.
        
               | lanternfish wrote:
               | 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.
        
               | aidenn0 wrote:
               | > '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.
        
               | ivanbakel wrote:
               | 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.
        
               | joshuamorton wrote:
               | 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.
        
               | tcbawo wrote:
               | 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?
        
               | themoonisachees wrote:
               | 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.
        
               | dolni wrote:
               | 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.
        
               | gpm wrote:
               | 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.
        
         | fauria wrote:
         | It is actually Turing Complete:
         | https://arxiv.org/abs/1904.09828
        
         | asmor wrote:
         | Arena's rule engine and AI is based on Duels of the
         | Planeswalkers, so they had several years to develop the AI
         | player.
        
           | ugexe wrote:
           | 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.
        
           | Ensorceled wrote:
           | 14-15 years ...
        
           | apetresc wrote:
           | 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.
        
         | dmurray wrote:
         | "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.
        
           | jprafael wrote:
           | > "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.
        
             | dmurray wrote:
             | Oh I completely agree, I'm just shitting on the idea that
             | this has anything to do with the game being "Turing-
             | complete".
        
       | MountainMan1312 wrote:
       | 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.
        
         | minimaxir wrote:
         | This goes _all_ the way back to the original Magic the
         | Gathering: Online in 2001. tl;dr it 's actually random unlike
         | real shuffling:
         | https://forum.nogoblinsallowed.com/viewtopic.php?f=15&t=1184...
        
           | ugexe wrote:
           | MTGO does not use the same shuffler as MTGA
        
         | mproud wrote:
         | There's supposed to be some non-random hand smoothing going on
         | MTGA.
        
           | baoluofu wrote:
           | 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.
        
           | Karliss wrote:
           | Does MTGA not have any kind of Mulligan mechanics that would
           | solve the initial bad hand?
        
             | Ensorceled wrote:
             | 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 ...
        
       | Bluecobra wrote:
       | 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.
        
         | Kiro wrote:
         | How does encryption help? Your client obviously needs to
         | decrypt it so can't you just piggyback on that?
        
           | vasco wrote:
           | You need to hack the client for that vs just binding to a
           | network port, or at least have access to a decryption key.
        
             | speedgoose wrote:
             | 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.
             | 
             | And then you have the monsters such as Widevine.
        
           | Scarjit wrote:
           | 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.
        
             | devit wrote:
             | 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).
        
               | vsnf wrote:
               | You didn't mean it this way, but your post reads like
               | comedy. The juxtaposition of "very easy" with everything
               | else you wrote is a striking image.
        
               | lobf wrote:
               | It's simple!
        
               | throwbadubadu wrote:
               | But the bar is much higher than just network sniffing and
               | reversing a dumb protocol?
        
               | Workaccount2 wrote:
               | 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.
        
               | devit wrote:
               | That's what game consoles usually attempt to be.
        
             | maldev wrote:
             | 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.
        
           | low_tech_love wrote:
           | 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.
        
             | neonsunset wrote:
             | You don't need to obfuscate the code if you apply
             | sufficient amount of acronym-driven coding practices to it!
        
               | another_bear wrote:
               | "It's not shit code, it's just acronym driven
               | obfuscation!" -My coworkers, apparently.
        
           | bcrosby95 wrote:
           | It's not about finding a 100% solution. It's about deterring
           | as many people as you can.
        
           | dbttdft wrote:
           | 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.
        
         | gnyman wrote:
         | 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.
        
           | zdware wrote:
           | 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).
           | 
           | I'd highly suggest checking out these two episodes of this
           | podcast - https://darknetdiaries.com/episode/7/
        
         | acters wrote:
         | 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
        
           | Cpoll wrote:
           | It would also help to not send the high-value information to
           | the client until required. Especially loot drops!
        
             | Workaccount2 wrote:
             | But then you have to pay for more server side compute!
             | Think of the profit margins!
        
               | bcrosby95 wrote:
               | 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.
        
           | rtkwe wrote:
           | 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.
        
             | kqr wrote:
             | 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.
        
               | Verdex wrote:
               | 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.]
        
               | rtkwe wrote:
               | 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.
        
         | michaelcampbell wrote:
         | That brings back some memories. IIRC, showEQ was used to prove
         | several theories and bugs that Verant/Sony steadfastly denied:
         | 
         | - there were hell levels
         | 
         | - Halflings instead of Humans got the XP bonus (and that there
         | actually WERE race/class XP differences?)
         | 
         | - early Shaman alchemy actually WAS broken
         | 
         | Also wasn't it what lead to eqemulator.org?
        
           | stocktech wrote:
           | iirc, eqemu reverse engineered the server based on the
           | traffic. I remember being impressed.
        
         | sprite wrote:
         | 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.
        
         | IG_Semmelweiss wrote:
         | Curious since I don't know about this topic:
         | 
         | Is this sort of packet sniffing (to cheat) far more difficult
         | (impossible?) for browser-based games ?
         | 
         | Assume of course a modern browser fairly standard use of the
         | browser itself
        
           | tga_d wrote:
           | 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.
        
       | no_time wrote:
       | How hard would it be to write a server emulator that facilitates
       | LAN matches with all cards unlocked?
       | 
       | I have no interest in interacting with a glorified skinnerbox.
        
         | bodangly wrote:
         | 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.
        
           | asmor wrote:
           | 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.
        
             | bodangly wrote:
             | Understandable. I do think knowing how to play paper magic
             | leads to a better understanding of the game but being a
             | spike isn't everyone's goal.
        
         | RALaBarge wrote:
         | 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.
         | 
         | https://www.apprentice.nu/
        
         | frameset wrote:
         | The project you want is http://xmage.today/
         | 
         | All cards available, and full rules engine.
        
       | JimWestergren wrote:
       | 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 )
        
         | indigo945 wrote:
         | 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.
        
           | JimWestergren wrote:
           | 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.
        
           | JTon wrote:
           | 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).
           | 
           | [1] https://old.reddit.com/r/bootlegmtg/wiki/index
        
             | JimWestergren wrote:
             | In the old school community: counterfeits absolutely not
             | ok. Proxies normally ok except in some tournaments.
        
           | chimeracoder wrote:
           | > 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.
        
             | JimWestergren wrote:
             | 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.
        
           | Reubachi wrote:
           | 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.
        
       | ljlolel wrote:
       | 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
       | 
       | https://arxiv.org/abs/1904.09828
        
       | onetimeuse92304 wrote:
       | Pure client side game logic...
       | 
       | 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.
        
         | lewisedc wrote:
         | 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.
        
         | Ensorceled wrote:
         | > 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.
        
         | mkonecny wrote:
         | The author explicitly mentions this is how the game is
         | implemented in the first 1/3 of the article
        
         | PawgerZ wrote:
         | Reading the post explains the post.
        
       | Sweepi wrote:
       | "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.
        
         | Ensorceled wrote:
         | >> "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.
        
         | lima wrote:
         | MTG is a very complicated game with a complex ruleset.
        
           | apetresc wrote:
           | 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).
        
         | themoonisachees wrote:
         | Fair enough for desktop, but also remember that MTGA runs on
         | phones.
        
       | partomniscient wrote:
       | The thing that weirded me the most in the article out was seeing
       | the 'goto IL_1894' statements in C# code.
       | 
       | It brought back memories of error handling in VB6, and was rather
       | unpleasant. I presume this is being done for performance reasons?
        
         | neonsunset wrote:
         | This is simply how C# decompiled from IL looks like - sometimes
         | you can turn IL-level gotos back into control flow idioms and
         | sometimes not.
        
       | erfgh wrote:
       | MTG is not very interesting when actually playing it. Most of the
       | game is building your deck. Thereafter the deck mostly plays by
       | itself.
        
         | mgdev wrote:
         | Building deck = programming
         | 
         | Playing = executing
        
         | alfons_foobar wrote:
         | There are drafts/sealed, you know...
        
       | wbecher wrote:
       | well... WOTC is a small indie game company
        
       | araes wrote:
       | The TLDR is a little too short.
       | 
       | - 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.
        
       ___________________________________________________________________
       (page generated 2023-12-05 23:02 UTC)