Hello everyone,
I've been working on a trading card game for quite a while and there's a question that has been bugging me for so long. I went with one design but I keep questioning my choice. The issue is about how do I handle the cards that belong to a player. I have 2 choice.
Method 1 - Keep a list of how many cards he owns per card type. For example "player x has 17 card of type abc". This is the easiest way, takes little space in my sql database and can grows with no problems. However it is very hard to spot bugs that would create (dupe) cards and I believe it might be an issue. Since a single card has no real id, cards can be created and destroyed -very- easily. That is the main reason why I went with the second method.
Method 2 - Every card has a unique id, so I can track informations like: when was this card created and why ? To whom was it created for. I can also follow the trading history of any particular card. I have a lot of data on every card to cover any needs I might have. However the downside, and it is a major one, is scaling. I will have so muchhhhhhh data to handle it's unbelievable. For instance, every time I want to get the list of cards of a particular player, if that player has 10k cards, it's 10k rows instead of say, 500 (assuming that's the number of different cards he owns). Multiply this by the number of players and the numbers are huge.
I'm afraid if my game ever becomes popular and I stick with method 2, I could have big problems. If I am to switch methods I would rather do it sooner than later.
Data handling question in network game
There's a difference between what you store in the database, and what you send to the player. Also, you can store a cached, calculated set of the user's inventory as "N cards of type X" and only invalidate/re-calculate that cache when the user trades cards.
Also, you can have the log of "what happened to cards" by writing a log entry to a log table each time a card is created, destroyed, or traded. Commit that log entry at the same time you commit the player inventory table, and they will always be in sync.
But I don't quite understand how you would "easily" create dupes of cards. Updating the card table is done only on your server side. You could easily wrap all card inventory modification in a few functions that do transactionally consistent updates, and log the appropriate audit information. Unless the user has some way to trick your server into calling the "make a new card" function, you should be safe. And if they do, then unique-card-objects is as vulnerable as card-type-count.
Also, you can have the log of "what happened to cards" by writing a log entry to a log table each time a card is created, destroyed, or traded. Commit that log entry at the same time you commit the player inventory table, and they will always be in sync.
But I don't quite understand how you would "easily" create dupes of cards. Updating the card table is done only on your server side. You could easily wrap all card inventory modification in a few functions that do transactionally consistent updates, and log the appropriate audit information. Unless the user has some way to trick your server into calling the "make a new card" function, you should be safe. And if they do, then unique-card-objects is as vulnerable as card-type-count.
I already send only a condensed list of cards (no "unique" stuff) to the players, since they really don't need the extra info. My concern was more on the database size and extra handling / card. Also what I meant about "easily" duping cards is that it is easier to go unnoticed. Right now all events that creates card are logged and linked to events, and matches so it's easier to trace back the origin. In the method 1, it's much harder to follow the trace. Maybe I'm paranoid, but I felt method 2 is more safe, but I'm not sure that it's worth the trouble anymore.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement