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. Just as an NFT is simply two structs from the Token Metadata program that live on top of a token (specifically the
Metadata and Master Edition structs), Raindrops adds additional structs on top of that NFT depending if that NFT represents a Class or an Instance of some Class.One object class NFT can inherit from another class NFT, 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 storing configurational information about what makes up this kind of Player or Item (like BodyParts, BasicStats like strength, or what BasicItemEffects an item should have), and the actual Player and Item instance structs are slimmed down data that only contain stateful information specific to that given NFT, like whether the strength is 5, or if the item was used 5 minutes ago.For an example of this, here is an
ItemUsage(Configurational data from an ItemClass) and an ItemUsageState(Stateful information from an Item that is a child of this class):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 trimmed down ItemUsageState for the ItemUsage defined within their parent ItemClass class. This keeps the Items and Players relatively small as PDAs.Last modified 1yr ago