0

我正在创建一个游戏，用户可以在其中设计自己的关卡（放置怪物、陷阱、任务等）。我使用的是 Symfony 2.3，并选择了 MongoDB，因为它有 Doctrine 支持。

当有人编辑关卡并保存更改时，ZoneData JSON 被提交到服务器。这个 JSON 的结构是一些参数（名称、大小、天气）和数百个ZoneObject（大约有 30 种不同的类型）。这些 ZoneObject 中的每一个都是基类的扩展，例如...

class ZoneObject extends Document {
    protected $xPos;
    protected $yPos;
}

class MonsterObject extends ZoneObject {
    protected $name;
    protected $challengeRating;
}

这些 ZoneObject 现在只是文档，因为我知道它们不是实体。我不确定它们应该是文档还是简单的类。它们永远不需要自己保存，它们始终是 ZoneData 的一部分。但是，它们确实需要经过验证，并通过表单进行编辑。

所以我的问题是 - 在这样的设置中，你会制作这些文档，还是坚持使用普通的旧 PHP 对象？我担心具有 500 个嵌入式子文档的 MongoDB 文档将如何扩展。

抱歉，如果我在这里遗漏了一些简单的东西。

在此先感谢，詹姆斯

4

1 回答 1

0

MongoDB 的插入速度非常快，其 NoSQL 特性意味着您可以使用所需存储的尽可能多的信息来扩展文档。技术栈保证了你可以写得非常快，但是参考信息可能比较难，我认为这对于游戏运行的时候更重要。如果我正在设计一个关卡，我希望初始设置的处理更加密集，但要让关卡本身渲染得非常快。

我会将您的 *Objects 设置为实体，并根据它们的类型将它们存储在不同的集合中。怪物会进入“怪物”集合，“天气”进入它自己的集合，等等。这背后的原因是集合存储具有相似范围的文档（这在您展示的设计中绝对正确，尽管控制较少， 参见下文）。

然后我会有一个“区域”实体，它具有天气、怪物、环境等属性，并链接到每个特定集合中的条目。这里的优点是它更加分散，并且您可以更好地控制组件的范围。

最后，我将展示一个 Level 实体，它引用与其关联的 Zone 实体。

上述设置使您可以根据需要轻松参考信息，并可以生成特定区域的报告等。它还有一个优点是一切都更容易测试，并且您可以根据需要轮询信息。假设您有一张地图，当玩家进入关卡时会显示该地图。您可能想要显示天气或环境信息，但您不必为检索该段的所有其他信息而绑定。当一个动作发生在一个区域中时，您将显示该区域的适当信息，但如果您有更好的范围，您仍然可以对您期望的每个元素进行大量控制（即您知道您将只有一个天气文档，但怪物一个或多个）。

通过将事物结构化为实体，您还可以访问 Symfony 出色的验证服务，它确实解决了您在构建表单和执行约束时通常面临的许多问题。

最后，记住过早的优化是魔鬼总是公平的。有很多方法可以在不重构应用程序（缓存、Gearman 等）的情况下提高访问速度，您应该考虑最重要的是什么 - 为 alpha 版本构建和运行某些东西，或者提供应该是的付费服务完美无瑕。

我希望我已经涵盖了您的大部分问题，但如果没有，请务必发表评论，我会更新我的答案！

于 2013-10-12T14:48:07.737 回答