Every realm in the Avalon browser RPG begins as a design problem that we cannot fully solve until we start building it. The Labyrinth of Minds had a clear mechanical identity from the start — social deduction, information asymmetry, the feeling of being gaslit by your environment. The Void was straightforward in its nihilism: strip away colour, strip away music, let the silence speak. The Mystical Sanctum was harder. What does “mystical” mean as a gameplay experience, not just as a mood?
This is the third dev diary in our ongoing series documenting the construction of Avalon, a dark fantasy browser RPG built to live alongside Portal Avalon’s fiction. If you’re joining us here, the short version: we are a small team building an in-browser RPG using Canvas 2D and Vanilla JavaScript, intentionally avoiding frameworks and art-heavy pipelines to stay lean and fast. Dev Diary #1 covered our technical architecture. Dev Diary #2 covered the Labyrinth. This one is about the Sanctum — the realm that took the longest and taught us the most.
The Technical Decision: Canvas 2D + Vanilla JS
Before we could build the Sanctum, we had to commit to a rendering approach for the whole game. The options were WebGL (via Three.js or a custom implementation), a DOM-based approach using absolutely-positioned elements and CSS transitions, or Canvas 2D.
We chose Canvas 2D, and we would make the same choice again.
WebGL is genuinely powerful, but it introduces a level of complexity that is hard to justify for a game whose primary interaction model is clicking, reading, and making turn-based decisions. The cognitive overhead of maintaining a WebGL pipeline — shader compilation, buffer management, the inevitable Three.js version drift — is overhead we would be paying constantly without proportionate gains in what players actually experience.
Why Not the DOM?
DOM-based approaches have their place. CSS transitions are excellent for UI elements, and we use them extensively for the HUD, the dialogue boxes, and the navigation. But trying to run a game scene in the DOM produces layout thrashing, unpredictable reflow costs, and an architecture that fights against the browser’s rendering model. Canvas gives us a single, controlled surface to paint on. We decide what gets drawn, when, and in what order.
The Sanctum’s environment is rendered in three Canvas layers: background (the deep violet gradients, the particle field of floating glyphs), midground (NPC silhouettes, interactive objects), and foreground (the player’s avatar, combat overlays, dialogue windows). Separating layers means we can redraw only what changes, which keeps frame rates stable even on lower-end hardware.
Vanilla JS, Not a Game Framework
We looked at Phaser.js seriously. It is a mature, well-documented game framework with a large community, and it would have accelerated development. We chose not to use it for one specific reason: bundle size. Phaser’s minified build is around 1MB. For a game that lives as a supplementary feature on a fiction website, loading an extra megabyte before the first frame is unacceptable. Players arrive from story pages. We have seconds to hold their attention before they navigate away. A 1MB blocking script is a player we never meet.
Our entire game bundle, including all realm logic, NPC data, quest trees, and audio management, sits under 120KB gzipped. That is a decision we made on day one and protect aggressively.
Designing the Five NPCs
The Sanctum has five NPCs. Each was designed with a specific function in the player’s journey through the realm, and each required a distinct voice — because in a game with minimal visual assets, voice is character.
Merchant Thorn
Thorn is the first NPC most players encounter. He sells items, offers crafting materials, and provides the mechanical scaffolding that lets players feel they are progressing even when they are not sure what they are progressing toward. His dialogue is deliberately mundane among the Sanctum’s strangeness — he talks about inventory margins and supply chains. The joke is that commerce finds a way into every realm. The function is to give new players an anchor: a character who explains things in transactional terms when the metaphysics feel too dense.
The Oracle
The Oracle speaks only in questions and riddles. This was a game design decision before it was a characterisation decision. We wanted a quest-giver whose quests could be interpreted multiple ways, so that different players could approach the same content from different angles. The Oracle never confirms whether you completed a quest correctly — she offers a new question in response. Some players find this maddening. Others return to her more than any other NPC, drawn by the ambiguity.
The Archivist
The Archivist holds lore. In practical terms, he is the in-game encyclopaedia: click him and you get entries on Avalon’s history, the nature of the realms, the meaning of symbols encountered in combat. We designed him partly for SEO reasons — rich, well-written lore content gives us indexable depth — but the character justified himself in testing. Players who engaged with the Archivist showed longer session times. Lore, it turns out, is retention.
The Guardian
The Guardian is the combat gatekeeper. You cannot progress deeper into the Sanctum without defeating the Guardian at each tier, and each tier’s Guardian is mechanically harder. The Guardian speaks in formal, archaic English and does not negotiate. His function in the narrative is to represent the idea that some thresholds can only be crossed by force — or by understanding the pattern of the force that guards them. We designed his combat patterns to be learnable rather than random: players who pay attention to his attack cycles will beat him; players who button-mash will not.
The Shadow
The Shadow is the most complex NPC in the game. She appears at the edge of scenes, never in the centre. In early Sanctum tiers, she is silent. In mid-tiers, she begins leaving brief messages. In the late Sanctum, she reveals herself as a former player of Avalon who became entangled in the realm’s logic and never found a way out. She is, in a literal sense, the ghost in the machine — a reminder that the game has consequences beyond the current session. Players who engage with the Shadow unlock a questline that crosses into Portal Avalon’s fiction, where she appears as a character in one of the dark psychology stories.
Turn-Based Combat in the Sanctum
The Sanctum introduced the most significant combat mechanic in Avalon to date: Channelling.
Our base combat system is card-influenced and turn-based. On each turn, the player selects one of three available actions — Attack, Ability, or Item — drawn from a hand that refreshes between turns. Abilities are unlocked through quests and are realm-specific. The Labyrinth’s abilities were social and information-based. The Void’s abilities were destructive and self-costing. The Sanctum needed something different.
How Channelling Works
Channelling is a multi-turn ability. On turn one, you begin a Channel: you sacrifice your action for that turn but begin accumulating power. On turn two, you can continue the Channel or release it. The longer the Channel, the more powerful the release — but every turn you are Channelling, you cannot defend, and enemies know it. The Guardian is designed to exploit open Channels.
This creates a risk-reward dynamic that rewards patience and punishes aggression. It is the opposite of the Void’s design philosophy, which was built around burst damage and resource burn. The Sanctum asks you to wait. Most players find this uncomfortable at first, because they are used to games that reward clicking faster. The Sanctum rewards clicking less.
Designing Encounters Without Art
Every enemy encounter in the Sanctum is depicted through Canvas-painted silhouettes, colour-coded by type, against layered gradient backgrounds. We have no sprite sheets, no animated characters, no particle-heavy visual effects. What we have is text, timing, and the specific violet-and-gold palette of the Sanctum’s visual identity.
We found, through testing, that players respond more to pacing than to visual complexity. An enemy that pauses before attacking — that takes an extra 800 milliseconds to signal its intent — feels more threatening than an animated one that simply fires. Dread is temporal. We spend a lot of design time on the timing of silence.
The Quest-Story Connection
From the beginning, we designed Avalon to be porous with Portal Avalon’s fiction. The realms are not separate from the stories; they are extensions of the same world, accessible through different interfaces.
The Sanctum’s quests reference characters and events from Portal Avalon’s Mystical category. The Oracle’s riddles sometimes contain answers that are hidden in specific story passages. Completing certain Sanctum quests unlocks access to stories that are not publicly listed on the site — they exist only as rewards for players who persist long enough to reach them.
This is not just a content strategy. It is a design philosophy: fiction and game should feel like two windows into the same space. The reader who becomes a player should feel that their reading was relevant. The player who becomes a reader should feel that their play prepared them for something.
The Shadow questline is the most complete expression of this. It begins in the game, moves into the fiction, and ends in a space that is neither purely one nor the other — a choice presented to the player that exists as both a game mechanic and a narrative conclusion.
What Comes Next
The Sanctum is live and playable. Dev Diary #4 will cover the economy layer we built to sit across all realms — the three-currency system, the Premium Shop, and how we thought about monetisation in a context where the fiction comes first and the game is a companion, not a product.
If you have not played the Sanctum yet, the entry point is below. It is free to play. The Oracle is waiting, and she has a question for you.