🕹️PlayerHUD Availability Condition

The PlayerHUD Availability Restriction is a required-companion extension for the PlayerHUD Block. It lets teachers restrict access to activities, resources, or course sections based on a student's progress in PlayerHUD — Level, owned Items, Character class, or gamification status.

👥 Who it is for: teachers already using the PlayerHUD Block who want to gate content behind progression milestones — a boss item, a minimum level, an RPG class — instead of manual date or grade restrictions.

📋 Requirements

• Moodle 4.5 or later.
• Required dependency: the PlayerHUD Block must be installed first — this condition has no data to evaluate without it.

✨ Features

• 🎯 Restrict by Minimum Level: unlock content only once a student's PlayerHUD level reaches a configured threshold.
• 🎒 Restrict by Owned Item: unlock content based on how many units of a PlayerHUD item a student holds, with a comparison operator.
• 🧙 Restrict by Character Class: unlock content only for students with a specific RPG class assigned in PlayerHUD.
• 🎮 Restrict by Gamification Status: unlock content only for students who have gamification active (not paused/opted out).
• 🧠 Native Restrict Access Integration: appears as a regular option inside Moodle's own "Restrict access" panel — no separate screen, no extra capability to manage.
• ⚡ Real-Time Evaluation: the condition is recomputed on every page load from the student's current PlayerHUD data — no caching, no stale "unlocked" state.
• 📝 Dynamic Description Text: the "Not available unless..." message shown to students is built from the live requirement, not a static string.
• 🧩 Bulk Course-Wide Editing (optional): manage every PlayerHUD restriction in the course from a single dashboard via the separate Report Unlocker plugin.

🕹️ PlayerGames Ecosystem

PlayerHUD Availability Restriction is part of the PlayerGames gamification ecosystem:

• PlayerHUD Block (required): the gamification engine — XP, levels, inventory, quests, trade, and RPG progression. This condition has no data to evaluate without it.
• PlayerHUD Filter (recommended): inserts collectible item drops, trade offers, and the compact HUD widget via shortcodes.
• PlayerGroup (optional): lets students form their own groups from the activity page — no teacher intervention needed.

Explore the full ecosystem at jeanlucio.github.io/en/playergames.

🚀 Getting started

• Install the PlayerHUD Block first — this condition depends on it and will not function without it.
• Install PlayerHUD Availability Restriction in availability/condition/playerhud and complete the Moodle upgrade.
• Edit an activity, resource, or section, open Restrict access and add a PlayerHUD restriction.
• Choose the restriction type — Minimum Level, Owned Item, Character Class, or Gamification Status — and its parameters.
• Students gain access once the condition is met; the description shown to them updates automatically.

🔐 Security & Compliance

• Instance isolation: item/class lookups and inventory counts are always scoped to the course's own PlayerHUD block instance.
• XSS-hardened rendering: level and quantity values are cast to int before being persisted or rendered.
• Safe deserialization: stored configuration is read with unserialize_object(), never raw unserialize().
• Server-side re-evaluation: access is always recomputed from the student's live PlayerHUD data — nothing is trusted from the client.
• No external API calls: the condition only ever reads Moodle's own database.
• Privacy-aware: implements Moodle's null_provider — it only reads data owned by the PlayerHUD Block and stores none of its own.

📚 Documentation and support

Full documentation — features, the restriction type reference, the PlayerGames ecosystem, security details, and the full test suite — is at jeanlucio.github.io/moodle-availability_playerhud. Found a bug or have a question? Open an issue on the issue tracker.

📄 License

This project is licensed under the GNU General Public License v3 (GPLv3).

Copyright: 2026 Jean Lúcio