0

我决定使用我自己的简单引擎来制作我的下一个游戏。我已经为对象渲染、物理等编写了一些代码，现在我正在考虑如何轻松地将它们连接在一起。

我想用一个主对象创建层次结构，我们称之为场景，它的父对象为 Sprites 或 InteractiveObjects，每个 Sprite 或 InteractiveObject 都可以有自己的子对象，而子对象也可以有自己的子对象。我想你已经明白了我的意思： )

让我们假设，每个对象类型都将继承自某个基础对象，例如，我们称它为 Node。我还不确定，如果 Node 将是“真实”的对象，它将具有它的大小、位置等，或者只是游戏中每个对象的抽象包装器（实际上我倾向于选择第二个）。

最后。我的目标是，拥有实际场景的对象，调用像 Scene->Move(x,y) 这样的东西，它会移动场景的每个孩子（或 Sprite、InteractiveObject 等）。或 Scene->Render() 它将渲染每个（可渲染的）孩子。如果我创建 Sprite，我想添加像 Sprite->addChild() 这样的子元素，并且子元素可以是另一个 Sprite、InteractiveObject 或只是简单的节点。

现在我的问题。用 C++ 实现它的最佳方法是什么？还是我完全错了，这种结构很愚蠢？:)

4

1 回答 1

0

我应该认为结构是否合理在一定程度上取决于您真正想要实现的目标——系统听起来非常灵活，但通常在灵活性和性能之间进行权衡。根据游戏的类型，性能可能很难达到。

此外，如果所有事物都来自某个 BaseNode，那么它们都需要（尽管可能是空的）各种事物的方法，无论它们是否真的可以被渲染、移动等。或者你最终会得到很多 dynamic_casts，这不是也很好。因此，游戏实体和图形实体之间的灵活性和区分度可能会稍低一些，后者是前者的一部分（您可能希望允许游戏实体由多个图形实体或子实体组成，尽管）。

如果您确实使用当前的架构，我应该认为每个 BaseObject 都有类似向量的东西，当您在主对象上调用 render() 时，它会遍历所有子对象并在它们上调用 render。他们做同样的事情并做任何适合他们的渲染代码。

但是，另一个问题是，一个对象是否可以附加到其他几个对象上（例如，如果渲染和物理之间存在差异）。如果是这样，知道何时删除对象可能会变得很棘手，除非您不使用普通的 BaseObject*，而是使用某种形式的 auto_ptr 或 shared_ptr。

我希望这个答案对您有所帮助，尽管我意识到这不是一个简单的“这就是他们的方式！” 一。

于 2012-07-19T10:58:47.927 回答