feat: Implement game and server persistence using Redis and file storage, and add a collapsible, resizable card preview sidebar to the game view.
This commit is contained in:
@@ -0,0 +1,23 @@
|
||||
|
||||
# 2024-12-18 17:35:00 - Strict Rules Engine Implementation
|
||||
|
||||
## Description
|
||||
Implemented a comprehensive Magic: The Gathering rules engine (Core Logic) to replace the sandbox mode with strict rules enforcement. This includes a State Machine for Turn Structure, Priority System, Stack, and State-Based Actions.
|
||||
|
||||
## Key Changes
|
||||
1. **Core Types**: Created `src/server/game/types.ts` defining `Phase`, `Step`, `StrictGameState`, `StackObject`, etc.
|
||||
2. **Rules Engine**: Created `src/server/game/RulesEngine.ts` implementing:
|
||||
- **Turn Structure**: Untap, Upkeep, Draw, Main, Combat (Steps), End.
|
||||
- **Priority System**: Passing priority, stack resolution, phase transition.
|
||||
- **Actions**: `playLand`, `castSpell` with validation.
|
||||
- **State-Based Actions**: Lethal damage, Zero toughness, Player loss checks.
|
||||
3. **Game Manager Refactor**:
|
||||
- Updated `GameManager.ts` to use `StrictGameState`.
|
||||
- Implemented `handleStrictAction` to delegate to `RulesEngine`.
|
||||
- Retained `handleAction` for legacy/sandbox/admin support.
|
||||
4. **Socket Handling**:
|
||||
- Added `game_strict_action` event listener in `server/index.ts`.
|
||||
|
||||
## Next Steps
|
||||
- Client-side integration: The frontend needs to be updated to visualize the Phases, Stack, and Priority (Pass Button).
|
||||
- Move from "Sandbox" UI to "Rules Enforcement" UI.
|
||||
@@ -0,0 +1,20 @@
|
||||
|
||||
# 2024-12-18 18:00:00 - High-Velocity UX Implementation (Part 1)
|
||||
|
||||
## Description
|
||||
Started implementing the Frontend components for the High-Velocity UX Specification. Focused on the "Smart Priority Interface" components first to enable strict rules interaction.
|
||||
|
||||
## Key Changes
|
||||
1. **Frontend Plan**: Created `docs/development/plans/high-velocity-ux.md` detailing the gesture engine and UI components.
|
||||
2. **Strict Types**: Updated `src/client/types/game.ts` to include `Phase`, `Step`, `StackObject`, and `StrictGameState` extensions.
|
||||
3. **Smart Button**: Created `SmartButton.tsx` which derives state (Pass/Resolve/Wait) from the `StrictGameState`.
|
||||
- Green: Pass/Advance Phase.
|
||||
- Orange: Resolve Stack.
|
||||
- Grey: Wait (Not Priority).
|
||||
4. **Phase Strip**: Created `PhaseStrip.tsx` to visualize the linear turn structure and highlight the current step.
|
||||
5. **GameView Integration**: Updated `GameView.tsx` to house these new controls in the bottom area. Wire up `SmartButton` to emit `game_strict_action`.
|
||||
|
||||
## Next Steps
|
||||
- Implement `GestureManager` context for Swipe-to-Tap and Swipe-to-Combat.
|
||||
- Implement `StackVisualizer` to show objects on the stack.
|
||||
- Connect `ContextMenu` to strict actions (Activate Ability).
|
||||
@@ -0,0 +1,21 @@
|
||||
|
||||
# 2024-12-18 18:25:00 - High-Velocity UX Implementation (Part 2: Gestures & Backend Polish)
|
||||
|
||||
## Description
|
||||
Advanced the High-Velocity UX implementation by introducing the Gesture Engine and refining the backend Rules Engine to support card movement during resolution.
|
||||
|
||||
## Key Changes
|
||||
1. **Gesture Manager**: Implemented `GestureManager.tsx` and integrated it into the Battlefield.
|
||||
- Provides Swipe-to-Tap functionality via pointer tracking and intersection checking.
|
||||
- Draws a visual SVG path trail for user feedback.
|
||||
- Integrated with `CardComponent` via `useGesture` hook to register card DOM elements.
|
||||
2. **Stack Visualizer**: Implemented `StackVisualizer.tsx` to render the stack on the right side of the screen, showing strict object ordering.
|
||||
3. **Backend Rules Engine**:
|
||||
- Updated `RulesEngine.ts` to fully implement `resolveTopStack` and `drawCard`.
|
||||
- Added `moveCardToZone` helper to manage state transitions (untapping, resetting position).
|
||||
- Fixed typings and logic flow for resolving spells to graveyard vs battlefield.
|
||||
|
||||
## Next Steps
|
||||
- Implement Radial Menu context for activating abilities.
|
||||
- Add sound effects for gestures.
|
||||
- Polish visual transitions for stack resolution.
|
||||
9250
docs/development/mtg-rulebook/MagicCompRules20251114.txt
Normal file
9250
docs/development/mtg-rulebook/MagicCompRules20251114.txt
Normal file
File diff suppressed because it is too large
Load Diff
146
docs/development/plans/mtg-engine-and-ux.md
Normal file
146
docs/development/plans/mtg-engine-and-ux.md
Normal file
@@ -0,0 +1,146 @@
|
||||
|
||||
# Implementation Plan: MTG Rules Engine & High-Velocity UX
|
||||
|
||||
## Objective
|
||||
Implement a strict Magic: The Gathering rules engine (Backend) and a "Rich Input" high-velocity user experience (Frontend). The goal is to enforce 100% of the Comprehensive Rules on the server while allowing fluid, gesture-based actions on the client.
|
||||
|
||||
**Reference:** MagicCompRules 20251114.txt
|
||||
|
||||
---
|
||||
|
||||
## PART 1: THE RULES ENGINE (Server-Side Logic)
|
||||
|
||||
### A. Game Setup & Initialization (CR 103)
|
||||
The engine must execute this sequence automatically before the first turn:
|
||||
|
||||
1. **Deck Validation**: Verify decks meet format requirements (e.g., 60 cards min).
|
||||
2. **Life Initialization**: Set Life Totals to 20.
|
||||
3. **The Mulligan Process (CR 103.5)**:
|
||||
- **Initial Draw**: Both players draw 7 cards.
|
||||
- **Decision Loop**: Prompt players in turn order: "Keep Hand" or "Mulligan".
|
||||
- **Execution**: If Mulligan, shuffle hand into library and draw 7 new cards.
|
||||
- **London Rule**: For each Mulligan (N), user must select N cards to bottom.
|
||||
- **Concurrency**: Decisions sequential, Shuffles/Draws simultaneous.
|
||||
|
||||
### B. The Turn Structure State Machine (CR 500)
|
||||
Strict phase cycle. Priority (CR 117) must be passed by both players to advance.
|
||||
|
||||
1. **Beginning Phase (CR 501)**
|
||||
- **Untap Step**: AP untaps all permanents. No Priority.
|
||||
- **Upkeep Step**: Triggers go on stack. AP Priority.
|
||||
- **Draw Step**: AP draws. Triggers. AP Priority.
|
||||
|
||||
2. **Pre-Combat Main Phase (CR 505)**
|
||||
- AP may Play Land (Special Action, 1/turn, Stack empty).
|
||||
- AP may Cast Sorcery/Creature/Artifact/Enchantment/Planeswalker.
|
||||
|
||||
3. **Combat Phase (CR 506)**
|
||||
- **Start of Combat**: Triggers. Priority.
|
||||
- **Declare Attackers (CR 508)**:
|
||||
- AP selects attackers & targets (Player/Planeswalker).
|
||||
- Engine validates restrictions & taps attackers.
|
||||
- Triggers. AP Priority.
|
||||
- **Declare Blockers (CR 509)**:
|
||||
- DP assign blockers.
|
||||
- Engine validates (Flying, Menace, etc.).
|
||||
- Damage Ordering (if multi-blocked).
|
||||
- Triggers. AP Priority.
|
||||
- **Combat Damage (CR 510)**:
|
||||
- AP assigns damage (Lethal to 1st, then rest).
|
||||
- Damage dealt simultaneously.
|
||||
- Priority Check.
|
||||
- **End of Combat**: Priority Check.
|
||||
|
||||
4. **Post-Combat Main Phase**
|
||||
- Identical to Pre-Combat Main.
|
||||
|
||||
5. **Ending Phase (CR 512)**
|
||||
- **End Step**: Triggers. Priority.
|
||||
- **Cleanup Step (CR 514)**:
|
||||
- Discard to hand size.
|
||||
- Remove marked damage.
|
||||
- No Priority (unless trigger occurs).
|
||||
|
||||
### C. The Interaction Core: Priority & The Stack (CR 405 & 117)
|
||||
LIFO (Last-In, First-Out) Array.
|
||||
|
||||
- **Priority Passing (CR 117.3d)**: Game advances only when all players pass on empty stack.
|
||||
- **Response Window**: After cast, AP gets priority. If AP passes -> DP gets priority. If DP passes -> Resolve.
|
||||
- **State-Based Actions (The Referee Check - CR 704)**: Checked BEFORE every priority gain.
|
||||
- **Lethal Damage**: Damage >= Toughness -> Graveyard.
|
||||
- **0 Toughness**: Toughness <= 0 -> Graveyard.
|
||||
- **Legend Rule**: Duplicate legendary -> Controller chooses capture.
|
||||
- **Aura Check**: Invalid attachment -> Graveyard.
|
||||
|
||||
### D. Manual Mana Engine (CR 106)
|
||||
- **Production**: Tap Land -> Add color to **Floating Pool**.
|
||||
- **Spending**: Click symbol in pool to pay costs.
|
||||
- **Emptying**: Pool empties at end of every Step/Phase.
|
||||
|
||||
### E. Developer Notes & Edge Cases
|
||||
- **Layer System (CR 613)**: Must implement 7-Layer system (Copy, Control, Text, Type, Color, Ability, P/T).
|
||||
- **Token Generation**: Spawn game object with stats.
|
||||
- **Failure States**: Insufficient mana -> Bounce, Warning Flash.
|
||||
|
||||
---
|
||||
|
||||
## PART 2: THE "HIGH-VELOCITY" UX (Frontend Specification)
|
||||
|
||||
### 1. The "Smart" Priority Button
|
||||
Context-aware button (Bottom Right).
|
||||
- **Green ("Pass")**: Stack empty. clicking passes/advances.
|
||||
- **Orange ("Resolve")**: Stack has object. Click resolves top.
|
||||
- **Red ("Damage/Block")**: Mandatory manual assignment waiting.
|
||||
- **Blue ("Choice")**: Modal choice required.
|
||||
- **"Yield" Toggle**: Auto-pass priority until End Step (unless response needed).
|
||||
|
||||
### 2. Gesture Controls (Mouse/Touch)
|
||||
- **Swipe-to-Tap**: Drag line across background/cards. Intersected lands toggle & add mana.
|
||||
- **Combat Swipes**:
|
||||
- Attack: Swipe Up/Forward.
|
||||
- Cancel Attack: Swipe Down/Back.
|
||||
- Block: Drag blocker onto attacker.
|
||||
- **Targeting Tether**: Visual "rope" (Bezier curve) from source to target.
|
||||
|
||||
### 3. Contextual Radial Menus
|
||||
**Scenario**: User taps Dual Land.
|
||||
- **Interaction**: Pie menu spawns under cursor.
|
||||
- **Action**: Slide toward symbol to select. Minimal travel.
|
||||
|
||||
### 4. Visualizing "The Stack"
|
||||
Vertical list of tiles on screen edge.
|
||||
- **Hover/Long-press**: Show source card.
|
||||
- **Targeting**: Tiles must be valid targets for spells.
|
||||
|
||||
### 5. The "Inspector" Overlay
|
||||
Long-press/Right-click on card.
|
||||
- **Display**: High-Res Art + Oracle Text.
|
||||
- **Live Math**: Show Net Power/Toughness (Base + Layers).
|
||||
|
||||
---
|
||||
|
||||
## Task Breakdown & Status
|
||||
|
||||
### Backend (Rules Engine)
|
||||
- [x] **Core Structures**: `StrictGameState`, Phase, Step Types.
|
||||
- [x] **State Machine Baseline**: Phase advancement logic.
|
||||
- [x] **Priority Logic**: Passing, resolving, resetting.
|
||||
- [x] **Basic Actions**: Play Land, Cast Spell.
|
||||
- [x] **Stack Resolution**: Resolving Spells to Zones.
|
||||
- [x] **SBAs Implementation**: Basic (Lethal, 0 Toughness, Legend).
|
||||
- [ ] **Advanced SBAs**: Aura Validity check.
|
||||
- [ ] **Manual Mana Engine**: Floating Pool Logic.
|
||||
- [ ] **Game Setup**: Mulligan (London), Deck Validation.
|
||||
- [ ] **Combat Phase Detail**: Declare Attackers/Blockers steps & validation.
|
||||
- [ ] **Layer System**: Implement 7-layer P/T calculation.
|
||||
|
||||
### Frontend (High-Velocity UX)
|
||||
- [x] **Game View**: Render State Types.
|
||||
- [x] **Phase Strip**: Visual progress.
|
||||
- [x] **Smart Button**: Basic States (Green/Orange/Red).
|
||||
- [x] **Gesture Engine**: Swipe-to-Tap.
|
||||
- [x] **Stack Visualization**: Basic Component.
|
||||
- [ ] **Gesture Polish**: Combat Swipes, Targeting Tether.
|
||||
- [ ] **Smart Button Advanced**: "Yield" Toggle.
|
||||
- [ ] **Radial Menus**: Pie Menu for Dual Lands/Modes.
|
||||
- [ ] **Inspector Overlay**: Live Math & Details.
|
||||
Reference in New Issue
Block a user