Question

我正在为一个微型游戏引擎的屏幕管理器工作，到目前为止，我无法找到管理屏幕对象的正确解决方案，而不使用每个屏幕的“blob”。在我需要一个控制器中的可渲染对象列表的情况下，blob是否可以容忍？

Answer 1

在这种情况下，我会考虑使用MVC pattern。否则，如果你不小心，很容易得到一堆意大利面条代码，屏幕代码进入游戏代码，反之亦然。

Answer 2

我最近编写了一些你称之为“屏幕管理员”的内容。

我开始认为，无论我制作什么游戏，渲染系统在如何渲染（如何管理硬件）方面都差不多。改变的是渲染的东西，以及如何绘制它（我想要一个盒子，一个圆圈或一个位图......代表什么......等等）。

所以基本上“游戏状态”负责知道如何渲染自己，并且当从屏幕管理器或图形系统给出渲染表面时应该这样做（它还应该负责其他事情，比如知道如何输入，物理等等自己动手。）

我使用GraphicsSystem对象的单例实现了它，其名称如下：

GameState gs;
Graphics::System().Init(DOUBLE_BUFFER, 640, 480);
...
while(still_looping) {
    ...
    // When it is time to render:
    Graphics::System().RenderGameState(&gs);
}

你问，你怎么知道Graphics :: System（）单例是否知道如何渲染游戏状态？它知道因为游戏状态是从图形系统公开的监听器继承的......

//within GraphicsSystem.h...
class BaseRenderer
{
public:
    virtual void Render(BITMAP *render_surface) = 0;
};

//GameState defined with:
class GameState : public BaseRenderer
{
public:
    void Render(BITMAP *render_surface);
    ...

几乎所有的子系统都可以做到这一点......（可能不是计时，因为在游戏循环中需要它。）

为什么选择单身人士？好吧，它是C ++，我假设只有1个屏幕或图形子系统可以渲染。我不确定您是使用多个屏幕，还是手机或控制台。我要这样做的另一种方法是将图形系统作为静态全局变量放在一个单独的文件中，只为它们提供文件范围，并在该文件中具有访问器功能（我的旧C方式）。

关键是封装。让您的屏幕管理员管理硬件。让你的游戏状态决定如何表达自己。

如果错过了这一点，请澄清您的问题，我可以编辑答案。

游戏画面管理

2 个答案: