组件化游戏设计中的共享字段

Question

组件化游戏设计中的共享字段

3

我相信我已经完成了使用XNA的C#组件化游戏引擎中的最后一个大的逻辑跳跃。我已经定义了Entity类和抽象组件。我的问题出现在EntityFactory中。

当我想要创建一个新实体时，我将EntityType枚举传递给工厂中的静态方法，并通过switch/case语句找到需要组合的组件。问题是，我正在尝试创建一种方法，使得组件可以共享与同一实体中的其他组件相同的字段，而不必访问所有内容。例如，如果两个组件具有表示位置的Vector2字段，则它们应该都指向同一个Vector2。

我可以通过在实体工厂中初始化所有字段并要求将其传递到组件的构造函数中（并使用原始类型的ref），来实现这一点。但是，这将非常难以维护，因为每次我扩展或更改组件时，我都必须在使用该组件的每个地方重新编写工厂中的代码。我真的想避免这种解决方案，但如果我找不到更好的方法，我将忍受它。

我目前的解决方案是创建一个名为Attribute的包装器类。它包含两个字段：

private AttributeType type;
private Object data;

属性类型是一个枚举，表示属性的目的。因此，在枚举中有位置、旋转、纹理等条目。

EntityFactory创建一个空属性列表，并将其传递给每个组件构造函数。setField方法将由组件的构造函数调用，而不是初始化字段。这是Attribute类和setField方法：

 public class Attribute
{
    private AttributeType type;
    private Object data;

    public AttributeType Type
    {
        get { return this.type; }
    }
    public Object Data
    {
        get { return this.data; }
    }

    public Attribute(AttributeType type, Object data)
    {
        this.type = type;
        this.data = data;
    }

    public static void setField<T>(List<Attribute> attributeList, AttributeType type, out T field, T defaultValue)
    {
        bool attributeFound = false;
        field = defaultValue;

        foreach (Attribute attribute in attributeList)
        {
            if (attribute.Type == type)
            {
                field = (T)attribute.Data;
                attributeFound = true;
                break;
            }
        }

        if (!attributeFound)
        {
            attributeList.Add(new Attribute(type, field));
        }
    }
}

我的问题是当属性包含原始数据类型的数据时。我考虑在Attribute类中编写一个方法。

public void getData<T>(out T field) { field = this.data; }

然而，我似乎无法使用ref将数据传递给Attribute构造函数。我无法使Attribute成为通用类型，因为它不能进入列表中。我只是想知道是否有一种方法来处理值类型和引用类型的数据，或者在整个过程中我是否犯了逻辑错误。

- Godric Seer

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Andrew Russell · Accepted Answer

嘲讽版：恭喜您重新发明了变量。糟糕的是，或者说最好的情况下，它只是接口上的属性。

有用版：

我看到你的设计有几个问题。

第一个问题就是它太复杂了。除非你有一个令人信服和已经存在的理由（即不是“将来可能”需要），否则应该尽量避免复杂化。否则就是YAGNI。在诉诸于创建表达这些概念的系统之前，你应该始终尝试直接在代码中表达概念（就像我所说的重新发明变量；还要考虑this）。

但是假设你确实有一个组件化设计的好理由……

第二个问题是装箱。无论何时你将值类型（例如int、float、Vector2、任何struct）直接存储为引用类型（例如object、IEquatable），都会发生装箱。装箱对象是不可变的——因此每次位置改变时，都会创建一个新的装箱对象。变量的装箱是（相对）缓慢的。装箱对象存储在堆上——因此它们会在垃圾回收期间被考虑，并可能引起垃圾回收。因此，你在问题中提出的设计将表现得极差。

我假设你对基于组件的设计有一些想法，类似于这篇文章中所解释的。下面是一个有用的图表：

_{(来源: cowboyprogramming.com)} 这也带来了第三个问题: 无论如何，你不应该有多个持有位置的组件!（在你的设计中，你似乎比需要更加细致。）

基本上，基于组件的设计是关于重新发明class，而不是variable。在normal的设计中，你可能会有一个像这样的"Render"函数：

public void Draw()
{
    spriteBatch.Draw(texture, this.Position, Color.White);
}

但在组件化设计中，您将在不同的类中拥有Draw和Position。顺便说一下，我会像这样实现接口：

interface IRenderComponent { void Draw(); }
interface IPositionComponent { Vector2 Position { get; set; } }

所以，Draw 如何访问 Position？嗯，你需要一种表达this的方法（如果你要重新发明类，this 可能是你需要包含的最重要的概念）。

你会如何做到这一点？这是一个粗略的设计想法：

我会让每个组件类继承一个带有属性 Self 的 Component 类。我会让 Self 返回某种带有通过接口访问组成复合对象的其他组件的机制的 ComposedObject。因此，你的渲染组件可能看起来像：

class SimpleRenderer : Component, IRenderComponent
{
    public void Draw()
    {
        sb.Draw(texture, Self.Get<IPositionComponent>().Position, Color.White);
    }
}

这类似于GameServiceContainer（即Game.Services属性）的工作方式。这里的想法是，没有一个ComposedObject应该具有每个接口的多个实例。如果您的接口数量很少，ComposedObject甚至不需要使用列表-只需直接存储每个接口。但您可以有实现多个接口的组件。

现在，如果这对您来说太冗长了，也许您可以在ComposedObject上添加一些方便的属性（或使用扩展方法）来表示常见的数据块，例如像Position：

public Vector2 Position { get { return Get<IPositionComponent>().Position; } }

那么你的绘图函数可以简单地写成这样：

spriteBatch.Draw(texture, Self.Position, Color.White);