Cloaks & Dagger Litepaper

1. Overview

Cloaks & Dagger is a hidden-position survival game built around incomplete information. Players attack opponents while avoiding being targeted themselves, inferring positions from footprints, attack history, decoys, recharge-room behavior, item use, and trait-based powers.

The backend acts as the game master: clients submit intent, while the server owns the full room state and resolves the outcome. This keeps hidden positions and combat state from being exposed or fabricated by a browser, while still letting the client animate quickly and reconcile after position, resources, and combat are finalized.

Fig. 1. Gameplay loop.

Loop structure

The gameplay loop starts with room registration, then repeats through observation, player intent, server resolution, and client reconciliation until the room ends.

Table I. Current room loop stages.

Stage	Current structure
Registration	Selected Cloaks enter the room roster, up to the per-player limit.
Start threshold	The room starts when the required player count is reached.
Spawn	Cloaks spawn with metadata-derived vitals and abilities.
Visible state	Local board state, self state, visible items, clues, marks, decoys, presence signals, and live events.
Hidden state	Opponent positions and unresolved combat state stay server-owned.
Player intent	Move, queued movement, attack a tile, or use an item.
Validation	Rejects stale, invalid, unaffordable, blocked, or out-of-range actions.
Resolution	Applies the accepted action and writes the resulting room state.
Reconciliation	Optimistic movement, animation, and UI state reconcile to the server result.
Room lifecycle	Ends when time runs out or only one player's Cloak(s) remain.

2. Gameplay Rule System

*subject to change

The game logic is designed so each token's metadata can lead to different strategies. These examples show how several current rules connect metadata, hidden-state play, and board interaction.

Table II. Metadata-driven rule examples.

Metadata / item input	Rule or move	Current behavior
Cheetah Type	Stamina recovery	Recovers stamina faster than the normal stamina refresh rate.
Bat Type	Footprint suppression / Guano Bomb	Suppresses normal movement footprints and can use a Bat-specific area attack.
Potion of Invisibility	Stealth	Suppresses footprints and sight-based reveals; correct-tile attacks can still land.
Potion of Telekinesis	Reveal	Temporarily reveals exact nearby presence markers.
Potion of Summoning	Decoys	Adds decoy charges; placed decoys create false presence until attacked.
Clan	Recharge-room access	Matching clans enter; foreign clans are denied; clanless Cloaks use a remembered room decision.
Komodo Type	Komodo Pit	Creates a poison source that damages entrants over time while allowing movement.
Viper / Python Animal Wrap	Snake Pit	Creates an immobilizing trap zone for non-immune Cloaks.
Key of Secrets	Secret interaction	It's a secret, migo.
Halo	Lethal block	Blocks one lethal hit per room session, then is consumed for that session.
Sword of the Moon / Earth / Fire / Sun	Sword area attack	Uses a sword-specific area size, from smaller Moon coverage to larger Sun coverage.

Defensive behavior

Armor-style metadata traits map to a specific chance to block an incoming attack. When the block succeeds, the Cloak receives no damage from that attack.

Armor block rates use both item naming and rarity. Each armor family has its own defensive band, then rarity within that family determines the final rate. This keeps stronger-sounding armor meaningful without making global rarity the only balance input.

Table III-A. Current armor block rates by trait class.

Armor family	Trait class	Block-rate band
Chestplate	Chest	18%-30%
Elite Guard	Chest	16%-30%
Battle Vest	Chest	14%-25%
Vest	Chest	10%-20%
Shoulder Armor	Shoulder Gear	12%-30%
Shoulder Guard	Shoulder Gear	10%-20%
Single Guard	Shoulder Gear	20%-30%
Strap	Shoulder Gear	5%-10%

The full table below is sorted by highest block rate, then alphabetically for items with the same rate.

Table III-B. Full armor block rates.

Armor item	Trait class	Quantity	Block rate
Chestplate Samurai Moon	Chest	177	30%
Elite Guard Red	Chest	135	30%
Shoulder Armor Spikes	Shoulder Gear	54	30%
Single Guard Silver	Shoulder Gear	49	30%
Shoulder Armor Gold	Shoulder Gear	71	29%
Chestplate Titanium	Chest	325	28%
Chestplate Gold	Chest	446	27%
Elite Guard Silver	Chest	199	26%
Single Guard Gold	Shoulder Gear	124	26%
Battle Vest Red	Chest	121	25%
Chestplate Samurai Dusk	Chest	720	24%
Chestplate Samurai	Chest	821	23%
Shoulder Guard Emerald	Shoulder Gear	305	20%
Single Guard Steel	Shoulder Gear	243	20%
Vest Regal Guard	Chest	178	20%
Battle Vest Brown	Chest	279	19%
Chestplate Steel	Chest	1123	19%
Shoulder Armor Silver	Shoulder Gear	285	19%
Chestplate Iron	Chest	1224	18%
Vest Blue	Chest	229	18%
Vest Red Guard	Chest	231	18%
Vest Silver	Chest	251	17%
Elite Guard Bronze	Chest	339	16%
Shoulder Guard Ruby	Shoulder Gear	450	16%
Battle Vest Tan	Chest	395	14%
Shoulder Armor Steel	Shoulder Gear	437	12%
Shoulder Guard Topaz	Shoulder Gear	698	10%
Strap X Red	Chest	143	10%
Vest Brown Guard	Chest	401	10%
Strap Grey Left	Chest	283	9%
Strap Grey Right	Chest	302	8%
Strap X Grey	Chest	459	7%
Strap Black	Chest	592	5%
Strap X Brown	Chest	625	5%

When a Cloak has more than one defensive armor trait, block rates combine multiplicatively. This gives diminishing returns instead of summing the rates.

Armor combination example

# CLOAKS #27 has Chestplate Samurai Moon and Shoulder Armor Steel.
# Chestplate Samurai Moon -> 30% block.
# Shoulder Armor Steel -> 12% block.

combined_block = 1 - ((1 - 0.30) * (1 - 0.12))
combined_block = 0.384 # 38.4%, not 42%

Vitals

Vitals come from the three numeric metadata traits: Power/Strength sets HP, Wisdom/Magic sets PP, and Speed/Agility sets Stamina.

Trait-derived vitals

# Power -> HP, Wisdom -> PP, Speed -> Stamina.
# Example: CLOAKS #12432 has Power/Strength=98,
# Wisdom/Magic=97, and Speed/Agility=94.
# With HP_BASE=50, HP_MIN=1, HP_CAP=125: max_hp = clamp(98 + 50, 1, 125) = 125.

max_hp      = _clamp(power + 50, 1, 125) # range: 51-125 HP
max_pp      = _clamp(int(25 + ((wisdom - 1) / 98.0) * 25.0), 1, 50) # range: 25-50 PP
max_stamina = _clamp(speed + 50, 1, 150) # range: 51-149 Stamina

Information mechanics

Players read clues about where opponents may be; exact positions are shown only in specific cases such as same-tile presence or reveal effects.

Table IV. Clue signals shown to players.

Mechanic	Information it gives
Footprints	Shows a recently left tile, fading by movement step age and using clan color when available.
Attack marks	Shows the attacker whether a targeted tile missed, hit, or was blocked.
Directional clues	Summarizes nearby presence by direction without token IDs or exact coordinates.
Foreign / familiar clues	Indicates whether nearby presence is from the same clan or not.

Special tiles

Mystery tiles let players pull found items during a room. Drops can include stat replenishers, swords, potions, and other metadata item types, with rarity tied to drop rate.

Found items are separate from a Cloak's own metadata traits. A Cloak can always use its metadata item or ability when it has enough PP; mystery tiles add temporary room items through exploration.

Recharge rooms are tied to clan territory. A Cloak can enter the recharge room matching its clan, while Cloaks from other clans are blocked from that room.

For clanless Cloaks, entry is resolved per recharge room and remembered for that room for the rest of the game.

3. Eligibility And Access

Cloaks & Dagger is holder-gated. Players need to own at least one Cloak to enter a room, and wallet verification is handled through Privy.

A player can connect multiple wallets to one account, including wallet delegate support. Eligible Cloaks can then be registered into live rooms where holders play against each other in real time.

Table V. Holder access model.

Area	How it works
Player account	One account can collect eligible Cloaks across connected wallets.
Wallet verification	Privy verifies wallet login and ownership.
Holder gate	A verified Cloak is required to enter gameplay.
Game registration	Players choose which eligible Cloaks to register for the current room.
Live rooms	Registered holders play against each other in real time.

A Cloak can only be registered in one active game at a time. It must be eliminated or survive the room before it can enter another game.

4. Board Design

The game takes place on a classic RPG grid board. The Season 1 map is a custom-built arena with seven clan regions, distinct regional styling, and authored walkable and blocked tiles.

Fig. 2. Board view demo.

Map building progress as of 05/25/2026 — Fig. 3. map building progress as of 05/25/2026.

Token 76 movement and action sprite collage — Fig. 4. Cloak sprites.

5. Architecture

The runtime is split into a canonical game layer, a browser presentation layer, authored board data, and lightweight update paths. This keeps gameplay rules centralized while allowing the client to stay responsive.

Table VI. Current architecture.

Layer	Current structure
Game core	Django/DRF owns room state, action validation, movement writes, item effects, combat, elimination, and visibility rules.
Client layer	React/Vite renders the viewport, local controls, animation, and queued movement feedback from server-confirmed state.
Map	The authored map is imported once into the backend runtime coordinate model.
Update path	Clients receive compact room state, presence, and live events without exposing hidden opponent state.
Concurrency	Movement uses locked authoritative writes to prevent race conditions, burst movement, and teleport-style state drift.
Scaling	Hot state is kept compact, timed, and separated from larger static board payloads.

6. Work In Progress

Visuals: Cloak sprites and Season 1 map design.
Backend: Logic edge-case hardening, performance refactoring, and game rules.
Testing: Testbench coverage, regression checks, security leakage audits, and staging instrumentation for slow-path timing during playtests.
Planned: XP system, leaderboard design, and player profiles. Not started yet.
Potential feature: Contract-based room and result tracking for public analysis tooling.