我应该如何处理游戏的卡牌分配？
我已经检查了关于我的标题显示的大部分问题，但它们与我正在寻找的内容无关，所以我开始我自己的问题。
我试图重新创建为在线游戏的游戏称为 Buraco 不确定是否大多数或你们中任何人知道这一点。
我已经具备了游戏的基本功能，例如：
- 洗牌
- 分发牌
我现在遇到的问题是我应该如何处理分配给玩家 A、B、C、D 的牌，牌牌组中剩余的牌、垃圾桶上的牌以及如果由 4 名玩家玩的话，则由两支球队或如果由 2 名玩家玩的话，则由每个玩家在桌上的牌。
考虑到我不希望任何玩家在游戏中作弊，我必须将每张指定的卡保存在数据库中，所以我在想如何创建我的 MySQL 表来适应这个？
我首先想到的是创建一个表格，其中包含游戏会话和所有卡牌作为一列，但是嘿，该列总共有 104 张卡牌？？？可能还有很多其他更好的方法来实现这一点。
然后我想到我可以使用 varchar 或文本来保存所有给定的卡片，这将使验证每张已经提交的卡片、仍在甲板上、在垃圾箱上或在桌子上的卡片变得更加困难。
所以我想我的问题是：
考虑到这款游戏是多人游戏（用户创建一个房间来服务 2 或 4 个玩家），什么数据库是我的最佳选择？
您将如何处理表以使用 MySQL 或任何其他数据库维护每个游戏？
您将如何处理更新（正如您所注意到的，我将使用 ajax 来更新游戏，是否有任何最佳实践来说明我应该限制每次更新的频率、数据量或数据类型，因为它将更新房间中的所有用户，并且很可能不会作为 1 个请求一起更新，这对于服务器的使用影响将是一个大问题）？
您将如何根据您希望使用的数据库结构来比较卡片（查询示例）？
PS：如果您对这个主题有更好的标题，请告诉我这就是我当时想到的。
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:
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) ?
How would you approch the tables to maintain each game with MySQL or any other database ?
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) ?
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这只是部分答案，但对于第 2 点（表结构），将其分解并考虑所有游戏资产都是纸牌。
创建一个表，其中包含游戏、卡牌、其值（如果适用）、当前所有者（这将是指示特定玩家、堆栈或弃牌堆的值）的列。为了管理形成的集合，创建两个附加表：一个用于卡组或卡组，以及一个链接表，用于显示游戏中的卡牌与给定组的成员资格（这也可以通过基表中的字符串列来实现）和一些逻辑，但对于纯 RDBMS 方法，请拆分表）。
编辑：
问题1 - 数据库选项
这里有很多关于MySQL 性能和优化的问题。游戏需要考虑的最大特征是读取操作与写入操作的频率。标准 MySQL 配置优化了读取性能 - 这可能是最好的，具体取决于您如何描述您的游戏。
问题 2 - 表配置
为了扩展我之前的评论，我建议如下（随意调整表名称 - 它们只是为了解释）：
game_cards表 (game_id< /code>,card_id,value,owner)set_idgame_sets表>,game_id,owner)set_id,card_id) 的card_set_membership表game_cards表最初应填充完整的牌组（无论您拥有多少张牌，这就是您添加到表中的行数）。所有卡牌均应由card_id进行标识，其中每张卡牌都代表一副牌组中的唯一卡牌，并且对于给定游戏，game_id< 均应具有相同的值/code> （因为它们是同一游戏的一部分）。game_cards.value列将代表该卡固有的点数。game_cards.owner列将包含一个值来指示卡的位置；游戏中的示例可以是“牌组”、“丢弃”、“p1”、“p2”、“p3”、“p4”这允许您存储您拥有的牌、它们的价值以及它们在哪里（谁或各自拥有什么）。默认情况下，如果所有卡牌都从牌组开始，那么您可以设置
game_cards.owner = 'deck'的值。当一张牌被“抽出”时，您（比如玩家 3）可以将抽出的牌的值更新为game_cards.owner = 'p3'。下一个难题是将卡片收集到任意组中。为了在典型的 RDBMS 中处理这个问题，我使用一个表来创建集合列表 (
game_sets)，并使用另一个表将游戏中的卡牌链接到集合 (card_set_membership)。当用户开始将卡牌收集到一组中时，在game_sets表中使用新的set_id创建一条记录，该记录来自主game_sets表。 >game_cards.game_id 字段，以及拥有该集合的玩家（或其他实体，如果可能的话，在您的游戏中）的所有者。如果您已定义集，则使用set_id和card_id将记录添加到card_set_membership表中。您不必在此处保留game_id，因为您可以通过game_sets表知道这一点。注意：此配置允许单张卡属于多组卡。如果您不需要这个（即一张卡可能只是单个集合的一部分），那么您可以将
game_id添加到card_set_membership表中，而不使用game_sets根本没有。希望这能让这一点更清楚一点！
问题 3 - 数据库更新
简而言之，您应该尽量减少客户端和服务器之间的流量。如果您使用ajax，那么请尝试确保消息开销（打包）尽可能小。查看用户可以在客户端执行的操作，然后考虑如何将其转换为服务器端的操作。设计一组实现这些动作的消息并查看它们所需的数据（例如一张或多张牌、哪个玩家采取了行动等）。如果您担心作弊，请考虑嵌入一个客户端无法轻易伪造的密钥（而不仅仅是“p1”或“p2”等）（可能与他们的会话登录有关？）。
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):
game_cardstable with columns (game_id,card_id,value,owner)game_setstable with (set_id,game_id,owner)card_set_membershiptable with (set_id,card_id)The
game_cardstable 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 acard_id, where each represents a unique card in the deck, and for a given game should all have the same value forgame_id(since they are part of the same game).game_cards.valuecolumn would represent the points inherent to the card, if applicable for your game.game_cards.ownercolumn 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 togame_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 thegame_setstable with a newset_id, thegame_idfrom the maingame_cards.game_idfield, and theownerto 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 thecard_set_membershiptable with theset_idand thecard_id. You don't have to keep thegame_idhere because you know that via thegame_setstable.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_idto thecard_set_membershiptable and not usegame_setsat 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?).