|
| 1 | +# Data Structure |
| 2 | + |
| 3 | +This document details the structure of card data in the Rummage database, explaining how card information is organized and stored. |
| 4 | + |
| 5 | +## Card Data Model |
| 6 | + |
| 7 | +The core card data is modeled using a structured format: |
| 8 | + |
| 9 | +### Primary Card Entities |
| 10 | + |
| 11 | +- **CardDefinition**: The fundamental card entry containing all card data |
| 12 | +- **CardEdition**: Specific information for a card in a particular set |
| 13 | +- **CardFace**: Data for one face of a card (for multi-faced cards) |
| 14 | + |
| 15 | +### Core Card Data |
| 16 | + |
| 17 | +Each card contains these core attributes: |
| 18 | + |
| 19 | +```rust |
| 20 | +// Simplified example of core card data structure |
| 21 | +pub struct CardDefinition { |
| 22 | + pub oracle_id: Uuid, // Unique identifier |
| 23 | + pub name: String, // Card name |
| 24 | + pub mana_cost: Option<String>,// Mana cost string |
| 25 | + pub type_line: String, // Type line text |
| 26 | + pub oracle_text: String, // Oracle rules text |
| 27 | + pub colors: Vec<Color>, // Card colors |
| 28 | + pub color_identity: Vec<Color>,// Color identity |
| 29 | + pub keywords: Vec<String>, // Keyword abilities |
| 30 | + pub power: Option<String>, // Power (for creatures) |
| 31 | + pub toughness: Option<String>,// Toughness (for creatures) |
| 32 | + pub loyalty: Option<String>, // Loyalty (for planeswalkers) |
| 33 | + pub card_faces: Vec<CardFace>,// Multiple faces if applicable |
| 34 | + pub legalities: Legalities, // Format legalities |
| 35 | + pub reserved: bool, // On the reserved list? |
| 36 | +} |
| 37 | +``` |
| 38 | + |
| 39 | +## Storage Format |
| 40 | + |
| 41 | +Card data is stored in multiple formats: |
| 42 | + |
| 43 | +- **JSON files**: Static card data stored on disk |
| 44 | +- **Binary format**: Optimized runtime representation |
| 45 | +- **Database**: For web-based implementations |
| 46 | + |
| 47 | +### JSON Structure |
| 48 | + |
| 49 | +The JSON structure follows a standardized format for interoperability: |
| 50 | + |
| 51 | +```json |
| 52 | +{ |
| 53 | + "oracle_id": "a3fb7228-e76b-4e96-a40e-20b5fed75685", |
| 54 | + "name": "Lightning Bolt", |
| 55 | + "mana_cost": "{R}", |
| 56 | + "type_line": "Instant", |
| 57 | + "oracle_text": "Lightning Bolt deals 3 damage to any target.", |
| 58 | + "colors": ["R"], |
| 59 | + "color_identity": ["R"], |
| 60 | + "keywords": [], |
| 61 | + "legalities": { |
| 62 | + "standard": "not_legal", |
| 63 | + "modern": "legal", |
| 64 | + "commander": "legal" |
| 65 | + } |
| 66 | +} |
| 67 | +``` |
| 68 | + |
| 69 | +## Parsed Structures |
| 70 | + |
| 71 | +Rules text and other complex fields are parsed into structured data: |
| 72 | + |
| 73 | +### Mana Cost Representation |
| 74 | + |
| 75 | +Mana costs are parsed into a structured format: |
| 76 | + |
| 77 | +```rust |
| 78 | +pub struct ManaCost { |
| 79 | + pub generic: u32, // Generic mana amount |
| 80 | + pub white: u32, // White mana symbols |
| 81 | + pub blue: u32, // Blue mana symbols |
| 82 | + pub black: u32, // Black mana symbols |
| 83 | + pub red: u32, // Red mana symbols |
| 84 | + pub green: u32, // Green mana symbols |
| 85 | + pub colorless: u32, // Colorless mana symbols |
| 86 | + pub phyrexian: Vec<Color>, // Phyrexian mana symbols |
| 87 | + pub hybrid: Vec<(Color, Color)>, // Hybrid mana pairs |
| 88 | + pub x: bool, // Contains X in cost? |
| 89 | +} |
| 90 | +``` |
| 91 | + |
| 92 | +### Rules Text Parsing |
| 93 | + |
| 94 | +Rules text is parsed into an abstract syntax tree: |
| 95 | + |
| 96 | +```rust |
| 97 | +pub enum RulesTextNode { |
| 98 | + Text(String), |
| 99 | + Keyword(KeywordAbility), |
| 100 | + TriggeredAbility { |
| 101 | + trigger: Trigger, |
| 102 | + effect: Effect, |
| 103 | + }, |
| 104 | + ActivatedAbility { |
| 105 | + cost: Vec<Cost>, |
| 106 | + effect: Effect, |
| 107 | + }, |
| 108 | + StaticAbility(StaticEffect), |
| 109 | +} |
| 110 | +``` |
| 111 | + |
| 112 | +## Card Relationships |
| 113 | + |
| 114 | +The database tracks relationships between cards: |
| 115 | + |
| 116 | +- **Token creators**: Cards that create tokens |
| 117 | +- **Meld pairs**: Cards that meld together |
| 118 | +- **Companions**: Cards with companion relationships |
| 119 | +- **Partners**: Cards with partner abilities |
| 120 | +- **Flip sides**: Two sides of double-faced cards |
| 121 | + |
| 122 | +## Indexing and Lookup |
| 123 | + |
| 124 | +The data structure includes optimized indexes for: |
| 125 | + |
| 126 | +- **Name lookup**: Fast retrieval by card name |
| 127 | +- **Type lookup**: Finding cards by type |
| 128 | +- **Text search**: Finding cards with specific rules text |
| 129 | +- **Color lookup**: Finding cards by color identity |
| 130 | +- **Format lookup**: Finding cards legal in specific formats |
| 131 | + |
| 132 | +## Data Versioning |
| 133 | + |
| 134 | +The database supports versioning of card data: |
| 135 | + |
| 136 | +- **Oracle updates**: Tracking rules text changes |
| 137 | +- **Erratas**: Handling card corrections |
| 138 | +- **Set releases**: Managing new card additions |
| 139 | +- **Format changes**: Updating format legalities |
| 140 | + |
| 141 | +## Related Documentation |
| 142 | + |
| 143 | +- [Card Attributes](card_attributes.md): Detailed information about card attributes |
| 144 | +- [Effect Implementation](../effects/index.md): How card effects are implemented from data |
| 145 | +- [Card Database](index.md): Overview of the card database system |
0 commit comments