Class Inheritance Structure

It is a pain to have to redefine the same stats for different player or item NFTs across many unique NFT mints, as well as costly. The Raindrops Protocol avoids this by taking the stance that object inheritance is useful, and an object class should be it’s own NFT.

An object class can inherit from another, and all existing object instances should inherit from an existing object class NFT.

Both the Player and Item contract behave this way, with PlayerClass structs and ItemClass structs living on top of their own NFTs where configuration data is stored, and the actual Player and Item instance structs being slimmed down structs that only contain stateful information specific to that NFT.

For an example of this, here is an ItemUsage(Object class, configuration data) and an ItemUsageState(Object instance, stateful information):

pub struct ItemUsage {
    index: u16,
    basic_item_effects: Option<Vec<BasicItemEffect>>,
    usage_permissiveness: Vec<PermissivenessType>,
    inherited: InheritanceState,
    item_class_type: ItemClassType,
    callback: Option<Callback>,
    validation: Option<Callback>,
    do_not_pair_with_self: bool,
    dnp: Option<Vec<DNPItem>>,
}

pub struct ItemUsageState {
    index: u16,
    uses: u64,
    activated_at: Option<u64>,
}

An ItemUsage will have a has_many relationship with an ItemClass and is embedded within the ItemClass.

ItemUsage defines how a given item may be used, and an item can be used in many ways. However, the ItemClass doesn’t actually get used - it is a blueprint for creating Item instances. When made, Items don’t all contain this massive struct in their PDAs, they instead contain a single trimmed down ItemUsageState for each ItemUsage defined within their parent ItemClass class.