Software programmers here? Tell me if this is possible

This is something I have had on my mind for ages and I just can't figure out why none ever took the effort to actually do it (Aside shops not wanting to redirect potential customers)

Why is there no site that allows people to upload their Wants / Haves / Collection cards and then cross checks people their Wants/Haves to bring forth ''hits'' of people that could thus potentially make a trade?

So simple example:

Player A:
Haves: 4 FOW
Wants: 4 Wasteland

Player B:
Haves: 4 Wasteland
Wants: 4 FOW

*Imagine button: Generate hits under the wants section*

And the system would link the 2 players, making it clear instantly they could make a potential trade (even though there is a value difference.)

There is a Dutch site called Nedermagic that allows people to upload haves/wants/collection. When looking up cards in their database theres also a button to bring forth all players that offer said card to trade. So this helps somewhat, but you still have to go to that persons profile, then check his want list yourself.

Now I am no programmer, but it feels to me this is mostly table work (inserting the card database) and not that rocket science complicated coding wise correct? (Forgive me if it turns out to be much more complex then I imagine it to be)

Would this be possible? It seems to me that the site/forum pulling this off (and not linked to any shop) would benefit greatly from people flocking to said site as ''trading is easy on said site''.

Hmm. I'm a programmer by trade, so I'll bite.

This does seem relatively trivial, at least at small scale. You're right that it's mostly a database schema problem. Off the top of my head, the database would contain tables like

• card - id; name; etc. Just a basic Magic card.
• want - number; card_id (Foreign key to card); account_id (Foreign key to account).
• have - number; card_id (Foreign key to card); account_id (Foreign key to account).

Then the lookup is something like `SELECT have.card_id, have.number, have.account_id FROM have INNER JOIN want ON have.card_id = want.card_id WHERE want.account_id = %s AND have.account_id != %s`.

Why has no one built it? Well, probably not a lot of money in enabling other people to make trades — it's more lucrative to sell.

Quote:

---

Originally Posted by Emurian

This is something I have had on my mind for ages and I just can't figure out why none ever took the effort to actually do it (Aside shops not wanting to redirect potential customers)

Why is there no site that allows people to upload their Wants / Haves / Collection cards and then cross checks people their Wants/Haves to bring forth ''hits'' of people that could thus potentially make a trade?

So simple example:

Player A:
Haves: 4 FOW
Wants: 4 Wasteland

Player B:
Haves: 4 Wasteland
Wants: 4 FOW

*Imagine button: Generate hits under the wants section*

And the system would link the 2 players, making it clear instantly they could make a potential trade (even though there is a value difference.)

There is a Dutch site called Nedermagic that allows people to upload haves/wants/collection. When looking up cards in their database theres also a button to bring forth all players that offer said card to trade. So this helps somewhat, but you still have to go to that persons profile, then check his want list yourself.

Now I am no programmer, but it feels to me this is mostly table work (inserting the card database) and not that rocket science complicated coding wise correct? (Forgive me if it turns out to be much more complex then I imagine it to be)

Would this be possible? It seems to me that the site/forum pulling this off (and not linked to any shop) would benefit greatly from people flocking to said site as ''trading is easy on said site''.

---

It's a built in function of magiccardmarket, trading is dead anyway.

I'm not entirely sure but I think this might be one of the NP-Problems. That is a known set of problems for which it is uncertain (and as most people agree unlikely) that they are solvable deterministically in polynomial time meaning they can only be solved by "guessing and checking". So basically the same complexity as brute forcing someone's password. So there are finite algorithms which allow to do that - they just scale miserably. If you have to guess a one character password which might only consist of digits your guessing is pretty fast. If it is ten characters long and can the given alphabet contains more than 20 symbols, your computer might take some months to guess.

I think this could be one of the "covering" problems. You might want to check this list yourself, probably you'll find out if I'm right: https://en.m.wikipedia.org/wiki/Karp...plete_problems

Quote:

---

Originally Posted by nupert

I'm not entirely sure but I think this might be one of the NP-Problems. That is a known set of problems for which it is uncertain (and as most people agree unlikely) that they are solvable deterministically in polynomial time meaning they can only be solved by "guessing and checking". So basically the same complexity as brute forcing someone's password. So there are finite algorithms which allow to do that - they just scale miserably. If you have to guess a one character password which might only consist of digits your guessing is pretty fast. If it is ten characters long and can the given alphabet contains more than 20 symbols, your computer might take some months to guess.

I think this could be one of the "covering" problems. You might want to check this list yourself, probably you'll find out if I'm right: https://en.m.wikipedia.org/wiki/Karp...plete_problems

---

To be able to generate an optimal set of trades could very well be NP-complete - it reminds me of a bipartite matching problem in which each trade creates an edge between two vertices, and we attempt to match the largest number of vertices. I don’t remember whether bipartite matching is NP-complete. I don’t think this is a covering problem because ultimately we want to pair vertices (or “color” them), not find some minimal set. But maybe I’m misinterpreting.

But all that aside, you don’t need to generate an optimal set of trades for such a program to be useful - first and foremost because no computer-generated set of trades will actually be optimal, given many users will be non-responsive and not actually up to make the deal. Therefore you’re better off just surfacing potential trading partners: querying for users who want to trade cards a player wants, and wants cards that player wants to trade. That might scale badly if each player has and wants thousands of cards, but that’s a different problem.