Game Client Guardrails (loh-game)

1. No Emojis in Game Content

Rule: NEVER use emojis (🎮 ⚔️ 🏆) in game UI text, item names, or NPC dialogue.

• Emojis render inconsistently across platforms
• Breaks immersion in a lore-heavy game
• i18n complications with emoji support

2. Internationalization (i18n) Required

Rule: ALL user-facing strings MUST use the localization system.

data/lang/
├── ui_en.json      # UI strings
├── ui_hi.json      # Hindi translations
├── items_en.json   # Item names/descriptions
└── skills_en.json  # Skill names

// ❌ Bad: Hardcoded string
ui.label("Inventory");

// ✅ Good: Localized string
ui.label(t!("menu.inventory", &localization));

1. English (en) - Primary, default fallback
2. Hindi (hi) - 600M+ speakers, launch priority
3. Tamil/Telugu - Post-launch

3. Sprite Sheets for Game Assets

Rule: When generating game assets (icons, items, UI elements), generate as SPRITE SHEETS, not individual images.

• Grid layout (3x5, 4x4, etc.)
• 64x64 or 128x128 per item
• White background for easy extraction
• PNG with transparency after extraction

"Spritesheet containing 15 RPG [category] icons arranged in a grid. 
Items include: 1) [Item], 2) [Item], ... 
White background, [style] style."

• Weapons/Armor
• Food/Consumables
• Ores/Resources
• Potions (show dosage levels)
• Gems/Jewelry
• Farming tools
• Monster drops

4. Asset Naming Convention

5. UI Text Guidelines

DO:

• Use title case for headings: "Guard Captain Bhima"
• Use sentence case for descriptions: "A sturdy bronze sword."
• Keep button text short: "Buy", "Sell", "Close"

DON'T:

• ALL CAPS FOR EMPHASIS
• Exclamation marks everywhere!!!
• Generic placeholder text

6. Cultural Adaptation

Games inspired by OSRS/Runescape MUST be adapted to Indian lore.

7. Font Requirements

• UI Text: Noto Sans (Unicode, supports Devanagari)
• Mystical/Headers: Cinzel, Outfit
• Never: Browser defaults, Arial, Times

8. Number Formatting

9. Engine Upgrades & Build Stability

Rule: Major engine upgrades (e.g., Bevy 0.16 -> 0.17) MUST treat build failures as critical blockers.

1. Trait Check: When events break, check for new required traits (e.g., Event -> Message).
2. System Configurations: Validate system registration tuples; split run_if conditions if mixing systems and configs fails.
3. Clean Build: Run cargo check and ensure 0 errors before committing upgrade refactors.
4. Deprecations: Address "Use replacement" warnings immediately.
   • add_event -> add_message
   • .send() -> .write() (for MessageWriter)

10. Technical Implementation Standards (Bevy Specifics)

10.1 Event System

• Derive Macros: All events MUST derive Message in addition to Event.

  #[derive(Event, Message, Debug, Clone)]
  pub struct MyEvent;

• Registration: ALWAYS use app.add_message::<MyEvent>().
• Usage: ALWAYS use mut events: MessageWriter<MyEvent> and events.write(MyEvent).

10.2 System Parameter Limits

• Problem: Bevy systems fail to compile if they exceed 16 parameters (often seen as generic run_if or system errors).
• Solution: Consolidate related resources/queries into a struct deriving SystemParam.

  #[derive(SystemParam)]
  pub struct UiStatesParam<'w> {
     pub spell_book: ResMut<'w, SpellBookState>,
     pub settings: ResMut<'w, SettingsState>,
  }
  
  fn my_system(states: UiStatesParam) { ... }

10.3 Audio System

• Volume API: deprecated Volume::new(v) -> use Volume::Linear(v) or Volume::Db(v).

10.4 Binary & Tooling

• Feature Gates: Standalone binaries (like model_viewer) must verify standard library features (like bevy::hierarchy) are available in the crate's Cargo.toml dependencies before importing.