类似但不同类型消息的数据包组织答案

【问题标题】：Packet organization for similar but different type messages类似但不同类型消息的数据包组织
【发布时间】：2014-08-15 12:09:44
【问题描述】：

在游戏中，服务器可能必须向客户端发送一个包含信息的数据包，比如添加一个敌人。添加此类敌人的数据可能与每个敌人相似（位置、id ...），但需要区分它是哪个敌人。是僵尸吗？狼人？嗯。

我记得有两种方法：

1 - 创建一个 Enum。
所以我可以为每种类型的敌人创建一个 Enum，并在我的数据包中发送该类型。 优点： 只需一个数据包即可添加多种类型的敌人，只有一种方法来处理它的接收。

缺点：每次我想添加一个新敌人时，我都必须在枚举上创建一个新条目，而接收的方法很可能是一个烦人的大开关。

2 - 为每个敌人创建一个数据包，每个敌人都有不同的“处理”方法
优点：“似乎”更有条理，因为每个元素都有一个指定的数据包和方法，并且不需要向枚举添加一个条目（虽然 id 需要添加一个新的句柄方法所以....是的。）

缺点：敌人多意味着数据包多，也就意味着处理方法多，可能会一团糟。

所以，基本上，tl:dr，要么我有一个“PacketAddEnemy”，其中有一个像 EnemyType 这样的枚举和一些 switch-case，或者我有一个“PacketAddZombie”、“PacketAddWerewolf”等，但最终会收到一个垃圾邮件数据包和方法。

我更喜欢第一个选项，但我都不喜欢这两个选项。我想知道是否有有趣的替代品？

【问题讨论】：

标签： java libgdx packet kryonet

【解决方案1】：

有很多不同的方法来处理这个问题。我最喜欢的处理方式类似于您发布的选项一。每个实体都有一个唯一的类型 ID。您可以使用更多基于 reflection 的方法，而不是使用一个长的 switch 语句来创建实体。这是一种稍微慢一些的方式，但它确实提供了一个非常漂亮和干净的界面。

请记住，有很多方法可以处理这个问题，而这只是我的首选方式。每个游戏的处理方式都不同，你真的只需要选择你喜欢的东西。

示例：

public enum EntityIDs {

    Zombie( EntityZombie.class ),
    Werewolf( EntityWerewolf.class );
    // And so on for all of your entities

    public Class< ? extends Entity > entityClass;

    private EntityIDs( Class< ? extends Entity > cl ) {
        this.entityClass = cl;
    }

    public static Entity createEntity( int id ) {
        Class< ? extends Entity > cl = EntityIDs.values()[ id ].entityClass;

        return cl.newInstance();
    }
}

然后，您将收到来自服务器的类型 ID 和公共数据，例如位置。该 ID 可以是实体类型的序号，或者您决定将其映射到其类型的其他方式。然后，您可以使用 entityClass 字段以反射方式创建实体。当然，这要求您仍然列出枚举中的每个实体，但是创建一个新实体就像一行一样简单。这确实要求所有实体子类化一个公共超类，例如本例中的实体。它还要求每个 Entity 子类都有一个公共构造函数，通常只是一个默认构造函数，并在构造后完成初始化。

拥有一个通用的超类确实可以简化部分问题。您可以将所有常见数据（例如位置）放在超类中。当你想移动一个实体时，你不需要关心它是什么类型的实体，你只需要知道哪个实体以及它在哪里移动。

World world = ...;
Entity entity = world.getEntity( entityId );
if( entity != null ) {
    entity.move( newX, newY );
}

我想再次重申，这只是一种方法，绝不是唯一的方法。这可以很容易地扩展到许多真正取决于您的偏好的不同解决方案。这绝不是一个完整的示例，而只是我的首选解决方案的一般概念。

这确实会带来性能成本，因为反射不是很快。它通常由每个调用的多个方法调用组成。您可以将其更改为使用工厂模式，而不是每个实体类型都有一个负责创建每个实体的 EntityCreator。

【讨论】：