How should i deal with the card assigment of my game ?

Question

I've checked most of the question that was display regarding my title but they were not related to what i am looking for, so i am starting my own question.

The game i am trying to re-create as an online game is called Buraco not sure if most or any of you know of it.

I already have the basic functions of my game such as:

• shuffle the deck of cards
• distribute the cards

What i am stuck at the momment is how should i deal with the the cards that were assigned to player A, B, C, D, cards left on the deck, cards on the trash and the cards that will be on the table by both teams if played by 4 players or by each player if played by 2 players.

Considering i do not wish any player cheating the game i would have to save each assigned card in a database so i what thinking how should i create my MySQL table to fit this ?

First thing that came to my mind was to create a table with the game session and all cards as a column but hey 104 cards total of column ??? there might be a lot of other better ways to acomplish this.

Then it came to my mind that i could use a varchar or text to hold all the given cards which would make it a little harder to verify each card that was already handed, still on the deck or is on trash or on the table.

---

So i guess my questions are:

1. What database would be my best option for this game considering it will be for multiplayer (The user creates a room to serve 2 or 4 players) ?

2. How would you approch the tables to maintain each game with MySQL or any other database ?

3. How would you take care of the update (as you notice i will be using ajax to update the game, is there any best pratice of how often or how much data or what sort of data should i be limiting each update since it will be updating all the users in the room and most likely not all together as 1 request this would be a big concern as for usage impact on the server) ?

4. How would you compare the cards (query sample) based on the database structure you would prefer using ?

PS: if you have a better title for this topic let me know this was what came to my mind at the time, also if you have any question feel free to comment i will try to answer if i can.

PSS: Guess not many people out there to input some piece of advices on this :(

Answer 1

This is only a partial answer, but with regards to number 2 (table structure) break it up and consider that all the game assets are the cards.

Create a table with a column for the game, the card, its value (if applicable), the current owner (which would be a value to indicate either a specific player, the stack, or the discard pile). For managing collections which are formed, create two additional tables: one for groups or sets of cards, and a linking table to show membership of cards in a game to a given group (this could also be achieved with a string column in the base table and some logic, but for a pure rdbms approach, split up the tables).

Edit:

Question 1 - Database option

There are many questions on here about performance of MySQL and optimization. The single biggest characteristic to consider for your game is the frequency of read operations vs write operations. The standard MySQL config optimizes read performance - which is probably best based on how you describe your game.

Question 2 - Table configuration

To expand upon my previous comments, I am suggesting the following (feel free to adapt table names - they are just for explanation):

• a game_cards table with columns ( game_id, card_id, value, owner )
• a game_sets table with ( set_id, game_id, owner )
• a card_set_membership table with (set_id, card_id)

The game_cards table should be initially populated with a complete deck (however many cards you would have, that is the number of rows you add to the table). All cards should be identified by a card_id, where each represents a unique card in the deck, and for a given game should all have the same value for game_id (since they are part of the same game).

• The game_cards.value column would represent the points inherent to the card, if applicable for your game.
• the game_cards.owner column would contain a value to indicate where the card is; example from your game could be "deck", "discard", "p1", "p2", "p3", "p4"

This allows you to store what cards you have, what they are worth, and where they are (who or what owns each). By default, if all cards start on the deck then you could set the value of game_cards.owner = 'deck'. When a card is "drawn" then you, say by player 3, you can update the value for the drawn card to game_cards.owner = 'p3'.

The next piece of the puzzle is collecting the cards into arbitrary sets. To handle this in a typical rdbms I use one table to create a list of the sets (game_sets) and another to link cards in the game to the sets (card_set_membership). When a user starts collecting cards into a set, create a record in the game_sets table with a new set_id, the game_id from the main game_cards.game_id field, and the owner to the player (or other entity, if possible in your game) which has the set. If you already have a set defined, then add a record to the card_set_membership table with the set_id and the card_id. You don't have to keep the game_id here because you know that via the game_sets table.

Note: This configuration allows a single card to be part of multiple sets. If you don't need this (i.e. a card may only be part of a single set) then you can add a game_id to the card_set_membership table and not use game_sets at all.

Hope that makes this a little more clear!

Question 3 - Updates to the database

The short answer is that you should look to minimize the traffic between the client and server. If you are using ajax, then try to make sure the message overhead (packaging) is a small as possible. Look at the actions your users can perform on the client end, then consider how this translates into actions on the server side. Design a set of messages which achieve these actions and look at the data they require (e.g. the card or cards, which player made the move, etc.). If you are worried about cheating, consider embedding a key (rather than just "p1" or "p2", etc.) which cannot be easily faked by the client (perhaps related to their session login?).