Case Study — Worldbuilding · Narrative Systems · Game Design Document
Temple of Bastet
Temple of Bastet: Guardian's Path is a worldbuilding and GDD piece for an exploration-based narrative adventure: a web-based (Three.js) temple where players learn Bastet's teachings through exploration, daily rituals, NPC tasks, and puzzles.
It's a designed, not built project — a detailed game design document covering concept, gameplay, art direction, narrative, and structure. I wrote it as a complete, actionable plan with a one-week MVP scope.
The challenge. Turn a brand's mystical sensibility into a playable-feel: rituals that advance the story, a one-week MVP, and a complete design package that another reader could implement without filling in core blanks.
Project
This lives in the TeaArtTarot repo as bastets_temple/: a small set
of interlinked Markdown documents (README/brand context, game concept, gameplay mechanics, art
and visual style, narrative design, and a project-structure diagram). The design is for a
web-first narrative adventure — a sacred temple to Bastet — where players learn her teachings:
protection, balance, harmony, motherhood, femininity, and mystical knowledge.
Scope discipline: The GDD explicitly marks an MVP: one primary temple environment with a few chambers, two–three NPCs, exploration, daily rituals, and a small set of puzzles/tasks. The tone is deliberate — aligned with the TEAARTTAROT brand: luxury, minimal, modern, sophisticated and mystical — with Bastet's dual nature woven into the world.
Design
Core loop. Players explore freely, interact with NPCs who assign tasks tied to Bastet's teachings, perform a daily ritual at the central shrine (lighting candles, arranging offerings, reciting), solve environmental and symbolic puzzles to unlock chambers, and — through each piece — assemble the narrative. The goal is not collection, it's understanding.
Three-act structure. Prologue (arrival, meet Temple Priestess, basics). Act 1 (introduction to teachings, protect/learn). Act 2 (deepen into motherhood, nurture, new area and harder puzzles). Act 3 (inner sanctum, culmination, final ritual — face Bastet, receive blessing). Epilogue: a transformed guardian, with room for future expansions.
NPCs. Temple Priestess (mentor, first contact), Guardian Spirit (guide at key moments, represents protection), and Bastet (divine presence — direct only in the final act). Dialogue is deliberate: reverent, metaphorical, designed to teach.
Art & Technical Direction
Visual style. Luxury modern architecture blended with ancient Egyptian mysticism — black, white, gray with gold and soft light yellow accents; ethereal, moody lighting; clean lines against ancient carvings, hieroglyphics, and murals; the gardens (serene, flora, water) balance the temple's solidity. Sacred objects — altars, shrines, scrolls, statues — are set off visually to draw attention.
UI/UX. A minimal HUD; dialogue and menus in the same palette with subtle Egyptian motifs; simple symbolic iconography; unobtrusive quest log; clear interactive affordances without breaking immersion. Animations lean graceful, ritualistic.
Technical. The GDD lists Three.js for a web build (focus on lightweight 3D and basic interactions) and notes Unreal as an alternative — a deliberate decision so the scope fits a one-week MVP. The structure doc and tables of contents keep sections cross-referenced for implementation.
Key Design Decisions
1 · Rituals advance narrative, not XP
Daily rituals at the central shrine unlock new areas, reveal NPCs, or grant blessings — tied directly to narrative milestones.
Why. Keeps the "daily" loop compact and thematic — it reflects deepening connection to Bastet rather than grinding.
Result. Progression reads like learning, not farming.
2 · One-week MVP, with explicit future expansion
Defined MVP: core exploration, daily rituals, 2–3 NPCs, a few puzzles/tasks, one primary temple with few chambers, and core story. Future: altar customization, expanded rituals, more quests.
Why. Prevents scope creep — every design decision can be filtered against "can this run in a week if implemented in Three.js?"
Result. The document is concrete enough to plan, without trying to write the whole franchise.
3 · Environmental storytelling over exposition
Murals, hieroglyphics, statues, altars, and ambient cues carry history and teaching; puzzles are symbolic, tied to Bastet's meanings.
Why. Fits the "quiet, minimal, mystical" tone of TEAARTTAROT — the temple itself is the lesson.
Result. The player learns by looking and doing, not by reading walls of text.
4 · Design the boundary explicitly
States clearly: this is a GDD / worldbuilding project — not an implemented game. Distinguishes built vs designed/proposed at every level.
Why. Keeps portfolio claims honest — the deliverable is documentation and design, not a playable build. Three.js is "intended", not implied running.
Result. The case study is evidence-faithful: the repo contents are the evidence.
Evidence
The repository holds the full GDD package for the project.
Note. This is a designed/proposed worldbuilding GDD, not a built and published game. It was written to be implementable — with a concrete one-week MVP scope — but no playable build is claimed.
What I Learned
- Good GDDs read like specs. Interlinking sections (structure diagram) means you can jump from a mechanic to its narrative purpose and back.
- Scope is a design decision. Capping to a one-week MVP forced tradeoffs — two–three NPCs, few chambers — and made it stronger.
- Tone must be systemic. The luxury-minimal palette, reverent dialogue, and ritual loop all reinforce the same feeling — that's as intentional as the loop itself.
- Honest claims build credibility. Saying "designed, not built" reads cleaner than implying a demo exists — it shows discipline.
Note. A worldbuilding/design portfolio piece — deliberately presented as designed/proposed, not built.