Hacker News new | ask | show | jobs
by ProjectArcturis 929 days ago
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.

3 comments

> 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.

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.
Ah, makes sense. I guess they just assume that any client who is requesting to sit in that seat is authorized to.
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.
Looks to me like they only verified match ids, not the seats at all.
Yes, I had my desktop version of MTGA hang and when I connected to the match with my iPhone it immediately disconnected the desktop.
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.