architecture - 游戏对象绘制和更新自身的架构有什么问题？

Question

支持和反对游戏对象绘制和更新自身的原因是什么？例如，如果你有一个游戏，玩家在屏幕上有一个位置，为什么不创建一个包罗万象的类:

public class Player {
    private int x, y, xVelocity, yVelocity;
    private Sprite s;
    //...

    public Player() {
        // load the sprite here, somehow?
    }

    public void draw(CustomGraphicsClass g) {
        g.draw(s, x, y);
    }

    public void update(long timeElapsed) {
        x += (xVelocity * timeElapsed);
        y += (yVelocity * timeElapsed);
    }
}

这个设计有什么问题？有什么缺点或担忧？你会如何更好地编写这样的东西，或者更好地在游戏中构建这种类型的东西？

另外，有些联系，您将如何实现加载该 Sprite 图像？

此外，您将如何实现两个 Player 之间的碰撞？年代？

(我可能应该把这两个额外的问题分成新的问题，嗯？)

Answer 1

当它们除了在概念上与同一个“实体”联系在一起之外几乎没有共同点时，它将所有的渲染和逻辑代码耦合在一起。随着你的类(class)越来越大，你会发现自己拥有一个巨大的单体 Player这是一场噩梦。沿着域边界(渲染、AI)拆分使其更易于管理，而不必放弃太多，因为这些域没有太多重叠。

除了可维护性之外，还有一些其他注意事项:

如果你想在不同的线程上处理渲染和 AI，将它们的状态混合到同一个类中只是在乞求讨厌的多线程问题。

如果您使用的是 C++ 之类的语言，那么像这样的高度耦合类会缩短您的编译时间。

根据您的代码和对象在内存中的布局方式，将对象拆分为每个域的单独组件可以为您提供更好的缓存一致性和更好的性能。

这里是 lots more info如果你很好奇。