MMO游戏对象属性设计

Kevin Lynx 2011-05-02 19:19

MMO游戏对象属性设计

Author: Kevin Lynx
Date: 5.2.2011

一般的MMORPG中,游戏对象主要包括怪物和玩家。这两类对象在经过游戏性方面的不断“进化”后,其属性数量及与之相关的逻辑往往会变得很巨大。如何将这一块做得既不损失效率,又能保证结构的灵活、清晰、可维护?本文将提供一种简单的结构。

原始结构

最原始的结构,极有可能为这样:

Player:     +---------------+
            | property-1    |
            +---------------+
            | property-2    |
            +---------------+
            |     ...       |
            +---------------+
            | operator-1    |
            +---------------+
            | operator-2    |
            +---------------+
            | ...           |
            +---------------+

也就是,一个对象为一个C++类,然后里面直接塞满了各种属性名,然后是针对这个属性的逻辑操作(函数)。其结果就是Player成为巨类。针对这个情况,一直以来我觉得可以使用一种简单的方法来拆分这个类。冠以官腔,称之为Entity-Component-based Desgin。产生这种想法和我的个人技术积累有一定关系,见下文。

Policy-based Design

Policy-based Design,基于决策的设计。这个概念来源于<Modern C++ Design>。虽然这本书讲述的是针对C++模板的使用及设计技巧。但这种思想依然被我潜意识般地用在其他地方。Policy大致来说就是一个小的组件(Component)。它努力不依赖于其他东西,它可能就是个简单的类,它拥有极少的数据结构,及针对这些数据的极少操作接口。举例而言,玩家MP的自动回复功能,就可封装为一个Policy。将许多Policy组合起来,就可完成一个复杂的功能。

这种思想还可指导很多程序结构方面的设计。例如在做功能的接口拆分时,就将每个函数设计得足够小,小到单纯地完成一个功能。一个功能的入口函数,就将之前实现的小函数全部组合起来,然后共同完成功能点。

当然,<Modern C++ Design>里的Policy在表现形式上有所不同。但其核心思想相同,主要体现在组合 特点上。

Entity-Component-based Design

Entity-Component-based Design按照google到的文章,严格来说算是与OOP完全不同的软件设计方法。不过在这里它将按照我的意思重新被解释。

如果说Policy-based Design极大可能地影响着我们平时的细节编码,那么Entity-Component则是直接对游戏对象的结构设计做直接的说明。一个游戏对象就是一个Entity。 Entity拥有很少的属性,也许仅包含一个全局标示的ID。一个Component则是Entity的某个行为、或者说某个组成部分。 其实说白了,以玩家为例,一个玩家对象就是一个Entity,而一个MP的自动回复功能就可被包装为一个Component。这个Component可能包含若干与该功能相关的数据,例如回复时间间隔,每次的回复量等。我们往玩家对象这个Entity添加各种Component,也就是给玩家添加各种逻辑功能。

但是,Component之间可能会涉及到交互,玩家对象之外的模块可能也会与玩家内的某个Component交互。子功能点的拆分,不得不涉及到更多的胶水代码,这也算一种代价。

游戏对象属性设计

这份属性结构设计,基本就是参考了上面提到的设计思想。整个系统有如下组件:

Entity:    +-------------------+
           | property-table    |
           +-------------------+
           | component-table   |
           +-------------------+
Property:  +-------------------+
           | observer-list     |
           +-------------------+
Component: +--------------------+
           | logic-related data |
           +--------------------+
           | logic-related func |
           +--------------------+

意即,所有Entity都包含一个属性表和组件表。这里的属性表并非硬编码的属性数据成员集合,而是一个key-value形式的表。Property包含一个观察者列表,其实就是一系列回调函数,但是这些观察者本质上也是组件,后面会提到。Component正如上文描述,仅包含Component本身实现的功能所需要的数据和函数。整个结构大致的代码如下:

class Entity {
private:
    GUID id;
    std::map<std::string, IComponent*> components;
    std::map<std::string, Property*> properties;
};
class Property {
private:
    std::string name;
    Value val;
    std::vector<IComponent*> observers;
};
class IComponent {
public:
    virtual bool Operate (const Args &args) { return false; }
    virtual void OnNotify (const Property &property, const Args &args) {}
protected:
    std::string name;
    Entity *entity;
};

属性本身是抽象的,这完全是因为我们将属性统一地放在了一个表里。从而又导致属性的值也需要继续阅读



Kevin Lynx2011-05-02 19:19发表评论

[返回] [原文链接]