游戏对象的体系结构绘制和更新本身有什么问题？

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图像？

而且,你如何实现两个Players 之间的碰撞呢？

(我应该将这两个额外的问题分成新问题,对吧？)

Answer 1

它将所有渲染和逻辑代码耦合在一起,除了在概念上与同一"实体"相关联之外几乎没有共同之处.随着你的班级变得越来越大,你会发现自己拥有一个巨大的整体Player,这是一个维持的噩梦.沿着域边界(渲染,AI)拆分使得它更易于管理而不必放弃太多,因为这些域没有很多重叠.

除了可维护性之外,还有一些其他考虑因素:

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

2. 如果您使用的是C++之类的语言,那么这样的高度耦合类可能会导致编译时间过长.

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

如果你很好奇,这里有更多信息.