database - 设计表以存储多人游戏的各种要求和统计信息

Question

原始问题:

你好，

我正在创建一个非常简单的爱好项目-基于浏览器的多人游戏。我一直在设计用于存储有关任务/技能要求信息的表格。

现在，我通过以下方式设计表格:

表用户(有关用户的基本信息)

表统计信息(各种统计信息)

表 user_stats (将每个用户与统计信息连接起来)

另一个例子:

表怪物(有关NPC敌人的基本信息)

表 monster_stats (使用与上面相同的统计表连接怪物和统计信息)

那是简单的情况。我必须承认，我在设计诸如任务之类的不同事物的需求时陷入困境。示例任务A可能仅具有最低的字符级别要求(并且很容易实现)-但是另一个任务B具有许多其他要求(完成的任务，获得的技能，拥有特定的物品等)-什么是好的方法设计用于存储此类信息的表？

以类似的方式-存储有关技能要求信息的有效方法是什么？ (特定的角色类别，最低等级等)。

对于创建数据库驱动游戏的任何帮助或信息，我将不胜感激。

编辑:

感谢您的回答，但我想收到更多。由于在为可加工物品设计相当复杂的数据库布局时遇到一些问题，因此我开始着手解决这个问题。

我想收到文章/代码段/与设计用于存储游戏数据的数据库的最佳实践有关的任何内容的链接( buildingbrowsergames.com上提供了此类信息的一个很好的示例)。

我将不胜感激。

Answer 1

我将对此进行编辑，以添加尽可能多的其他相关问题，尽管我希望OP可以解决我在上面的评论。值得一提的是，我作为专业的在线游戏开发者已经有好几年了，而作为业余爱好者的在线游戏开发者们已经有很多年了。

在线游戏意味着某种持久性，这意味着您大致拥有两种类型的数据-一种是由您设计的，另一种是由玩家在游戏过程中创建的。您很可能将两者都存储在数据库中。确保您具有不同的表，并通过常规的数据库规范化规则正确地交叉引用它们。 (例如，如果您的玩家制作了阔剑，则不会使用剑的所有属性来创建整个新行。您需要在player_items表中使用基于实例的属性来创建新行，并在其中引用阔剑行如果您发现一行数据保存着您设计的某些内容以及播放器在播放过程中进行更改的某些内容，则需要将其标准化为两个表。

这确实是典型的类/实例分离问题，并且适用于此类游戏中的许多事物:妖精实例不需要存储意味着成为妖精(例如绿色皮肤)的所有细节，只需存储与之相关的事物即可。到那个实例(例如位置，当前健康状况)。有时，构造行为有些微妙，在这种情况下，需要根据类数据创建数据。 (例如，根据地精类型的最大健康状况来设置地精实例的开始健康状况。)我的建议是将这些硬编码到您的代码中，以创建实例并为其插入行。由于实践中很少有此类值，因此该信息很少更改。 (有关健康，耐力，法力等可消耗资源的初始分数就是这样。)

尝试找到一致的术语，以将实例数据与类型数据分开-以后修补现场游戏时，将使生活变得更轻松，并且不要通过编辑错误的表来浪费玩家的辛苦工作。这也使缓存变得更加容易-您通常可以不受惩罚地缓存类/类型数据，因为只有当设计者将新数据推送到那里时，类/类型数据才会改变。您可以通过memcached运行它，或者如果您的游戏具有连续过程(例如，不是PHP / ASP / CGI / etc)，则可以考虑在启动时全部加载，等等。

请记住，一旦上线，从设计端数据中删除任何内容都是有风险的，因为播放器生成的数据可能会引用该数据。在将所有内容部署到实时服务器之前，请对其进行全面的本地测试，因为一旦安装完毕，就很难将其拆除。考虑能够以安全的方式将这些数据的行标记为已删除的方法-可能是 bool(boolean) “ Activity ”列，如果将其设置为false，则意味着它不会显示在典型查询中。考虑一下如果禁用了玩家赚取的物品(如果这些都是他们支付的物品，那么对玩家的影响)。

如果不知道如何设计游戏，就无法真正回答实际的制作方面。数据库设计必须遵循游戏设计。但我会讲一个简单的想法。也许您将希望能够创建一个基本对象，然后用符文， Crystal 或其他任何东西来增强它。为此，您只需要在项目实例和扩充实例之间建立一对多关系。 (请记住，您可能还具有项目类型和增强类型表。)每个增强都可以指定项目的属性(例如耐用性，战斗中最大伤害，重量)和修饰符(通常作为乘数，例如1.1至加上10％的奖金)。您可以看到我对如何实现这些修改效果here和here的解释-相同的原理适用于临时技能和咒语效果，适用于永久性物品修改。

对于数据库驱动游戏中的角色统计，我通常建议坚持使用每个统计单列(整型或浮点型)的幼稚方法。以后添加列并不是一项困难的操作，并且由于您将要大量阅读这些值，因此您可能不想一直对它们执行连接。但是，如果您确实需要灵活性，那么您的方法很好。这非常类似于我在下面建议的技能水平表:可以用这种方式对很多游戏数据进行建模-将一个事物的类或实例映射到其他事物的类或实例，通常还带有一些其他数据来描述映射(在这种情况下的统计值)。

一旦建立了这些基本联接-以及因以类/实例数据的分离方式(可能对您的代码而言不方便)而导致的任何其他复杂查询的发生，请考虑创建 View 或存储过程以在场景，这样您的应用程序代码就不必再为它担心。

当然，还可以使用其他良好的数据库做法-在需要确保自动执行多个操作(例如，交易)时使用事务，将索引放在您最常搜索的字段上，在空闲期间使用VACUUM / OPTIMIZE TABLE /以保持性能等

(这时的原始答案。)

老实说，我不会将查询需求信息存储在关系数据库中，而是存储在某种脚本中。最终，您对“需求”的想法采用几种不同的形式，这些形式可以利用不同种类的数据(例如，级别，类(class)，先前的任务完成，物品拥有)和运算符(operator)(一个级别可以是最低或最高，某些任务可能需要一个项目，而其他人可能需要不存在等)，更不用说连词和析取词的组合了(某些任务需要满足所有要求，而其他任务可能只需要满足其中之一)。用命令式语言更容易指定这种东西。这并不是说您在数据库中没有查询表，只是您没有尝试将有时任意的需求编码到架构中。我将有一个require_script_id列来引用外部脚本。我想您也可以将实际脚本作为文本字段放入数据库中。

技能要求非常适合数据库管理员，并且在您上特定类(class)的级别时，考虑到典型的学习技能游戏系统，这是微不足道的:

table skill_levels
{
    int skill_id FOREIGN KEY;
    int class_id FOREIGN KEY;
    int min_level;
}

myPotentialSkillList = SELECT * FROM skill_levels INNER JOIN
    skill ON skill_levels.skill_id = skill.id
    WHERE class_id = my_skill
    ORDER BY skill_levels.min_level ASC;

需要技能树吗？添加一列prerequisite_skill_id。等等。