将渲染代码与实际游戏引擎/逻辑代码分开的最佳方法是什么？将它们分开是个好主意吗？
假设我们有一个名为 Knight 的游戏对象。骑士必须渲染在屏幕上供用户查看。我们现在有两个选择。我们要么为骑士提供一个可以调用的 Render/Draw 方法，要么创建一个渲染器类来负责渲染所有骑士。
在两者分开的情况下，骑士应该仍然包含渲染他所需的所有信息，还是也应该分开？
在我们创建的上一个项目中，我们决定将渲染对象所需的所有信息存储在对象本身内部，但我们有一个单独的组件来实际读取该信息并渲染对象。该对象将包含诸如大小、旋转、缩放以及当前正在播放的动画等信息，并且渲染器对象将基于此来组成屏幕。
像 XNA 这样的框架似乎认为加入对象和渲染是一个好主意，但我们害怕被特定的渲染框架束缚，而构建单独的渲染组件让我们可以更自由地在任何给定时间更改框架。
What is the best way to separate rendering code from the actually game engine/logic code? And is it even a good idea to separate those?
Let's assume we have a game object called Knight. The Knight has to be rendered on the screen for the user to see. We're now left with two choices. Either we give the Knight a Render/Draw method that we can call, or we create a renderer class that takes care of rendering all knights.
In the scenario where the two are separated the Knight should the Knight still contain all the information needed to render him, or should this be separated as well?
In the last project we created we decided to let all the information required to render an object be stored inside the object itself, but we had a separate component to actually read that information and render the objects. The object would contain information such as size, rotation, scale, and which animation was currently playing and based on this the renderer object would compose the screen.
Frameworks such as XNA seem to think joining the object and rendering is a good idea, but we're afraid to get tied up to a specific rendering framework, whereas building a separate rendering component gives us more freedom to change framework at any given time.
发布评论
评论（3）
我将创建一个单独的 KnightRenderer 类。优点：
Knight本人甚至可能在游戏服务器上运行，并且根本不知道有关渲染的任何信息。KnightRenderer需要了解的有关Knight的所有信息（位置、状态）都必须在Knight中公开可读。特定于渲染的属性将进入
KnightRenderer类。例如，也许您想让骑士在被击中时闪光，因此您需要存储一个计数器或时间值。I would create a separate
KnightRendererclass. Advantages:Knighthimself might even run on a game server and not know anything about rendering at all.Everything the
KnightRendererneeds to know about theKnight(position, status) has to be publically readable inKnight.Properties specific to rendering would go into the
KnightRendererclass. For example, maybe you want to make the knight flash when he's hit, so you would need to store a counter or time value.我会尽力使您的对象尽可能通用，并尽可能避免将游戏事实编码到您的代码中。
例如，您有一个实体或对象或参与者类，并且该类有一个指向其决策（其 AI）的指针和一个指向其图形表示的指针。
它的决策必然与游戏事实相结合；事实上，它是游戏事实的一部分。因此，您可以在此处将您的决策者命名为“KnightAi”或其他名称。
另一方面，图形表示只是一点图形。它将与其他实体一样绘制。你有一个模型或一些位图和一些动画或没有......这将/可以被称为类似“模型”的东西，并将加载它被告知加载的信息，定义实体对玩家的外观。当渲染你的骑士、马匹和城堡时，你可能会发现它们都做同样的事情，只是使用不同的数据。他们所拥有的数据种类甚至都是一样的，只是内容不同而已。
假设您的实体全部表示为圆圈。您只需让它们指向一个 CircleRenderer，该 CircleRenderer 就具有应绘制的大小。您不会为您想要的每个不同尺寸（或颜色，或其他）的圆圈创建不同的渲染器类！
I would endeavor to make your objects as generic as feasible and to avoid encoding gameplay facts into your code as much as possible.
E.g. you have an Entity or Object or Actor class, and that class has a pointer to its decision making (its AI) and a pointer to its graphical representation.
Its decision making is necessarily coupled to the gameplay facts; indeed it is a part of gameplay facts. So this is somewhere where you might name your decision maker "KnightAi" or something.
On the other hand, the graphical representation is just a bit of graphics. It'll be drawn the same as every other entity. You have a model or some bitmaps and some animations or not... This would/could just be called something like "Model" and will load the information that it's told to load the defines what the entity looks like to the player. When it comes to rendering your knight versus your horse versus a castle, you'll likely find that they all do the same thing just with different data. The sorts of data that they have is even all the same, it's just the contents that are different.
Say your entities were all represented as circles. You would just have them point to a CircleRenderer that took the size that they should be drawn. You wouldn't create a different renderer class for each different size (or color, or whatever) of circle you wanted!
我知道我来晚了，但对于未来的读者，您可能会对我写的教程感兴趣。
我不是真正的专家，但这就是我如何看待正确的关注点分离：
http://aurelienribon.wordpress.com /2011/04/26/logic-vs-render-separation-of-concerns/
I know i'm coming late, but for future readers, you might be interested in a tutorial I wrote.
I'm no real expert but this is how I see proper separation of concerns:
http://aurelienribon.wordpress.com/2011/04/26/logic-vs-render-separation-of-concerns/