# Technical Design Bridge > Translate game design into implementation requirements without prescribing engineering solutions. The bridge between "what the designer wants" and "what gets built." Use this skill when: (1) translating formalized rules into systems specifications, (2) identifying data structure requirements from game state, (3) flagging performance-critical systems, (4) assessing platform constraints and their design impact, (5) defining aesthetic implementation requirements (shader complexity, audio channels, print specs), (6) creating component design specs for tabletop manufacturing. Medium-agnostic — works for digital engines, tabletop manufacturing, and hybrid platforms. - Skill: `wanghaisheng/technical-design-bridge` (Agent Skill) - Install (CLI): `npx skillmds@latest add wanghaisheng/technical-design-bridge` - Raw SKILL.md: https://api.skillmd.com/api/skills/wanghaisheng/technical-design-bridge/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: wanghaisheng (https://skillmd.com/u/wanghaisheng) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/wanghaisheng/technical-design-bridge --- # Technical Design Bridge The designer says "what." The engineer says "how." The bridge translates between them without either overstepping. A designer shouldn't prescribe code architecture. An engineer shouldn't override design intent. This skill defines the handoff. ## Bridge Philosophy **Describe the WHAT, not the HOW.** "The combat system must resolve 4-player simultaneous actions within 100ms" is a design requirement. "Use a thread pool with lock-free queues" is an engineering decision. **Flag constraints, don't solve them.** "This system requires tracking 10,000+ entities with real-time collision" is a flag. The solution is engineering's domain. **Respect both directions.** Technical constraints are real and reshape design. If the platform can't handle the designer's vision, the design must adapt — but that's a conversation, not a unilateral cut. ## Core Deliverables ### 1. Systems Specification For each game system, translate from design to implementation requirements: ``` SYSTEM: [Name] PURPOSE: [What this system does in the game — from design perspective] STATE: [All variables this system tracks] - [Variable]: [Type, range, persistence, visibility] INPUTS: [What feeds into this system — player actions, other systems] OPERATIONS: [What transformations the system performs] OUTPUTS: [What this system produces — state changes, events, feedback] PERFORMANCE: [Real-time? Turn-based? Latency tolerance?] PERSISTENCE: [What must be saved? Session? Across sessions? Cloud?] DEPENDENCIES: [What other systems must exist for this to function?] ``` **Example:** ``` SYSTEM: Character Mutation System PURPOSE: Manages random power assignment and mutation interactions STATE: - active_mutations: List of MutationID, max 5, persisted per character - mutation_energy: Float 0-100, regenerates at 2/sec, session-only - catalyst_shard: ItemID reference, persisted INPUTS: - Player activates mutation (player input) - Shard equipped/unequipped (inventory system) - Damage received (combat system — some mutations trigger on damage) OPERATIONS: - Random mutation assignment on character creation (weighted tables) - Mutation activation (check energy, apply effect, start cooldown) - Mutation interaction check (when 2+ mutations combine) OUTPUTS: - Visual effect trigger (to rendering) - Stat modification events (to combat/movement) - Audio trigger (to audio system) PERFORMANCE: Real-time, mutation activation must resolve in < 1 frame PERSISTENCE: Mutations persist across sessions. Energy resets per session. DEPENDENCIES: Combat system, inventory system, character system ``` ### 2. Data Structure Requirements What state the game needs to track: ``` DATA DOMAIN ENTITIES VOLUME UPDATE FREQUENCY ────────────────── ──────────────── ────────────── ────────────────── Player state Characters 1-4 per session Real-time World state Map tiles 1000-5000 Per event Economy Resources 10-20 types Per transaction Combat Active effects 0-50 per entity Per frame Progression Unlock flags 100-500 Per milestone ``` **Data relationship mapping:** - One-to-one (player ↔ character) - One-to-many (character ↔ mutations) - Many-to-many (characters ↔ factions) - Hierarchical (world → zone → area → tile) ### 3. Performance-Critical Flags Systems that have hard performance requirements: ``` SYSTEM REQUIREMENT PRIORITY ────────────────── ──────────────────────────────────── ──────────── [System] [Specific performance constraint] [Critical/ Important/ Nice-to-have] ``` **Common performance-critical areas:** - **Input response** — Player action to visual feedback (< 100ms for action games) - **Physics/collision** — Real-time spatial calculations - **AI decision-making** — NPC behavior resolution per frame - **Network synchronization** — Multiplayer state consistency - **Rendering** — Visual complexity vs. framerate - **Audio mixing** — Simultaneous sound channels - **Save/load** — Serialization speed and data size ### 4. Platform Constraints Impact How target platform shapes design: **Digital platforms:** ``` CONSTRAINT DESIGN IMPACT ADAPTATION ────────────────────── ──────────────────────────────── ────────────────── Input method [Controller? Touch? M+K?] [How it affects UI] Screen size [Mobile? Monitor? TV?] [How it affects layout] Processing power [Mobile? Console? PC?] [What's feasible] Storage [Download size limits?] [Content budget] Network [Online required? Optional?] [Offline capability] Session context [Couch? Commute? Desktop?] [Session length design] ``` **Tabletop constraints:** ``` CONSTRAINT DESIGN IMPACT ADAPTATION ────────────────────── ──────────────────────────────── ────────────────── Component count [Manufacturing cost per unit] [Minimize unique pieces] Card size [Standard sizes cost less] [Use standard sizes] Print process [Color count, finish options] [Design within print] Box size [Shelf presence vs. shipping] [Optimize footprint] Setup time [Player patience threshold] [Minimize pieces] Table footprint [Available play space] [Fit standard tables] ``` ### 5. Aesthetic Implementation Requirements Technical requirements driven by aesthetic direction (Skill 3): **Digital:** ``` AESTHETIC CHOICE TECHNICAL REQUIREMENT COST ────────────────────── ──────────────────────────────── ────────────── [Visual style] [Shader complexity, render path] [GPU budget] [Animation style] [Bone count, blend trees] [Memory/CPU] [Audio design] [Channels, reverb, spatialization][Audio budget] [VFX approach] [Particle systems, post-process] [GPU budget] [Lighting model] [Dynamic? Baked? Hybrid?] [Build time + GPU] ``` **Tabletop:** ``` AESTHETIC CHOICE MANUFACTURING REQUIREMENT COST ────────────────────── ──────────────────────────────── ────────────── [Card art style] [Print DPI, bleed, color profile] [Per-unit] [Miniatures] [Material, detail level, molds] [Tooling + unit] [Board material] [Foldable? Mounted? Neoprene?] [Per-unit] [Token material] [Cardboard? Wood? Acrylic?] [Per-unit] [Box design] [Insert design, shrink wrap] [Per-unit] ``` ### 6. Component Design Spec (Tabletop) For tabletop games, the technical bridge includes physical component specification: ``` COMPONENT QUANTITY SIZE MATERIAL NOTES ──────────────── ────────── ────────────── ────────────── ────────────── Cards [Count] [Standard size] [Card stock] [Finish, sleeve] Tokens [Count] [Dimensions] [Material] [Shape, color] Board [Count] [Folded size] [Material] [Fold count] Dice [Count] [Size] [Material] [Custom faces?] Rulebook [Pages] [Size] [Paper weight] [Binding] Box [1] [Dimensions] [Material] [Insert type] ``` ## Workflow ### Creating a tech bridge document 1. **List all game systems** from rules (Skill 8) and systems map (Skill 9) 2. **Write system specifications** — State, inputs, operations, outputs 3. **Map data requirements** — What state is tracked, how much, how fast 4. **Flag performance-critical systems** — What has hard timing requirements? 5. **Assess platform constraints** — How does target platform shape feasibility? 6. **Document aesthetic requirements** — What does the art/audio direction cost technically? 7. **Create component spec** (tabletop) — Physical manufacturing requirements 8. **Cross-check with scope** (Skill 20) — Does the technical scope match the feature scope? 9. **Review with engineering** — Does this accurately represent the design intent? ### Responding to "we can't build that" 1. Understand the constraint precisely — what specifically is infeasible? 2. Assess design impact — how does this constraint affect the player experience? 3. Propose design alternatives that preserve intent within constraints 4. Evaluate trade-offs with the design team 5. Update affected skills (loop, balance, systems) if the design changes 6. Flag to Coherence Engine (Skill 0) for impact analysis ## Outputs This skill produces: 1. **Systems specifications** — per-system WHAT documentation for engineering 2. **Data structure requirements** — state tracking needs 3. **Performance-critical flags** — hard requirements per system 4. **Platform constraint analysis** — how platform shapes design 5. **Aesthetic implementation requirements** — technical cost of art/audio direction 6. **Component design spec** — physical manufacturing requirements (tabletop) These outputs feed into: - **Skill 8 (Rules)** — Rules become implementation specs - **Skill 10 (Economy)** — Economy needs data infrastructure - **Skill 20 (Scope)** — Feasibility informs priority - **Skill 3 (Aesthetic)** — Aesthetic has technical cost - **Skill 18 (UI/UX)** — Interface has implementation requirements - **Skill 19 (GDD)** — Technical requirements are a GDD section