代码之家 › 专栏 › 技术社区 › Kasper Holdum

游戏与渲染逻辑的分离

coupling design-patterns

28

Kasper Holdum · 技术社区 · 15 年前

将渲染代码与实际的游戏引擎/逻辑代码分开的最佳方法是什么?把它们分开是个好主意吗?

假设我们有一个叫做骑士的游戏对象。必须在屏幕上渲染骑士以供用户查看。我们现在有两个选择。要么我们给骑士一个 Render/Draw 方法,或者我们创建一个渲染器类,负责渲染所有骑士。

在两个分离的场景中,骑士应该仍然包含呈现他所需的所有信息,还是应该将其分离?

在我们创建的上一个项目中,我们决定将呈现对象所需的所有信息存储在对象本身中,但是我们有一个单独的组件来实际读取该信息并呈现对象。对象将包含诸如大小、旋转、缩放以及当前播放的动画等信息,基于此,渲染器对象将组成屏幕。

XNA等框架似乎认为加入对象和渲染是一个好主意,但我们害怕绑定到特定的渲染框架,而构建一个单独的渲染组件可以让我们在任何给定时间更自由地更改框架。

3 回复 | 直到 12 年前

1

6

dash-tom-bang 15 年前

我会尽力使你的对象尽可能通用,尽量避免把游戏事实编码到你的代码中。

例如,您有一个实体、对象或参与者类,该类有一个指向其决策制定(其AI)的指针和一个指向其图形表示的指针。

它的决策必须与游戏事实相结合;事实上是游戏事实的一部分。所以你可以把你的决策者命名为“骑士”之类的。

另一方面,图形表示只是一些图形。它将与其他所有实体一样绘制。你有一个模型或者一些位图还有一些动画或者没有…这可以被称为类似“模型”的东西,并将加载它被告知要加载的信息,定义实体在玩家看来是什么样子的。当涉及到呈现你的骑士对你的马对城堡时,你可能会发现他们都用不同的数据做同样的事情。他们拥有的数据种类甚至都是一样的,只是内容不同而已。

假设你的实体都被表示为圆。你只需要让它们指向一个圆形引用器,它采用了应该绘制它们的大小。你不会为你想要的每一个不同大小(或颜色,或其他)的圆创建不同的渲染器类!

2

21

Thomas 15 年前

我会创建一个单独的 KnightRenderer 类。优势:

游戏逻辑和渲染之间的清晰分离。这个 Knight 他自己甚至可能在游戏服务器上运行,根本不知道渲染。
更小、更简单的类,只涉及一个功能。

所有的一切 奈特渲染器 需要了解 骑士 (位置、状态)必须公开可读 骑士 。

特定于呈现的属性将进入 奈特渲染器 类。例如,也许你想让骑士在被击中时闪光,所以你需要存储一个计数器或时间值。

3

6

Community CDub 8 年前

我知道我要迟到了,但对未来的读者来说,你可能对我写的教程感兴趣。

我不是真正的专家,但我就是这样看待问题的适当分离的:
http://aurelienribon.wordpress.com/2011/04/26/logic-vs-render-separation-of-concerns/

alt text