0

我试图弄清楚如何最好地为我的游戏设置一种通用游戏元素类。我想尝试和创建的也是一个类似的结构..

GameElementPositionMovement（根类）->GameElementVisual（处理所有图形）->GameElementPersonality（处理游戏逻辑）

然后我希望能够通过创建 GameElementPersonality 的实例来设置不同的个性（怪物、英雄、图标等），但在它的构造函数中也能够设置视觉和定位/移动方面。

我在另一个问题中提到了这一点，然后回来的答案是......

您似乎需要一种“数据模型”类来存储逻辑和一个可视（“视图”）类。视觉类不应该从数据模型继承，它应该使用它。这是与 OOP 相关的问题：IS vs HAS（继承 vs 组合）

但我不确定我是否理解这一点。没有任何视觉数据的位置/运动，似乎是一个很好的第一个根类，然后添加视觉方面（GameElementVisual），最后添加个性“特征”（GameElementPersonality），如盔甲、伤害、健康等

因此，我将定位/运动、视觉和逻辑分开，并且我认为我所布置的层次结构将是做到这一点的最佳方式，但这不是一个好的方式吗？它应该更平坦吗？使用 GameElementPositionMovement，创建视觉和逻辑实例并将其存储在自身中？

4

2 回答 2

2

您可以创建一个类似这样的结构：

（伪代码）
元素数据

//it doesn't have to extend any particular class
//however it would be nice if it could  dispatch events and register listeners
class ElementData implements IEventDispatcher
{
    public function ElementData() //constructor 
    {
        //do some stuff
    }

    public function setSomeProperty(value:int):void
    {
        //
    }

    public function doSomeCrazyStuff():void
    {
        //
    }
}

元素视觉

class ElementVisual extends MovieClip //or just Sprite or even DiplayObjectContainer
{
    public function ElementVisual(elementData)
    {
        //constructor takes an instance of ElementData class

        elementData.addEventListener(CHANGE, onDataChange)

        elementData.doSomeCrazyStuff();
        if (userCliked)
        {
            elementData.setSomeProperty(15);
        }   

        //you can have here some interactions with user (keyboard, mouse)
        //then it can communicate with elenemtData and 'listen' what it says.
    }

    function onDataChange
    {
        //react accordingly
    }
}

一些视觉表现（你可能需要很多）

class Monster extends ElementVisual
{
    //do all the graphic, animations etc
}

然后您需要一个类来设置所有数据、视觉效果等……在最简单的实现中，它可以是“文档类”。

这不是一个合适的 MVC 模型——它是一个简单的例子，展示了将逻辑与可视化解耦的概念。

MVC 不是唯一的解决方案，还有其他所谓的“设计模式”可能有用......

于 2012-06-08T16:39:31.213 回答
0

是的，MVC 的想法是保持事物解耦，在您的情况下，您最终会将所有内容粉碎到一个继承链中，您最终会得到一种类型的对象，该对象继承了另一个对象的所有属性，该对象继承了另一个对象的所有属性另一个对象，因此您将拥有一个代表一切的事物的实例，这就是为什么这不是一个很好的模式。

相反，如果您有一个 GameElementPositionMovement 类（您的主类），则创建一个 GameElementVisual 实例和 GameElementPersonality 实例（或多个实例，如果需要）。然后，任何时候在 GameElementPersonality 中对属性进行更改（或者如果您选择创建集合，则在集合中的任何属性）都可以调度事件，主类 GameElementPositionMovement 可以侦听调度的事件，并且当它获取时可以设置/传递GameElementPersonality 实例或数组到 GameElementVisual。然后在 GameElementVisual 中，您一直在处理基于当前模型的绘图，模型与视图逻辑分离，您可能还希望在单独的类或 GameElementPositionMovement 中处理控制。（控制是模型的修改，

通过这种方式，模型保持干净的控制逻辑和视图逻辑，它清楚地分开了什么去哪里，实际上只有视图类型取决于模型，控制器类型取决于视图，但是如果为模型建立了接口每个视图控制器都需要以这种方式相互通信，您可以用实现接口的新类替换任何这些部分（在小型游戏中不太可能出现问题，但设计有助于这种能力以及未来的可扩展性）。

于 2012-06-08T15:53:03.407 回答