feat: Wiki-fication of 145 raw documents into structured Topics
This commit is contained in:
+125
@@ -0,0 +1,125 @@
|
||||
# Skybound Code Structure Audit and Stabilization Plan
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw analysis logged before implementation
|
||||
|
||||
## 1. Overview
|
||||
|
||||
This document records the first code-level audit after reviewing Skybound-related wiki documents. The goal was to compare the documented architecture with the actual code path in `/Volumes/Data/project/Antigravity/Skybound`, identify design and feature risks, and define the first stabilization pass.
|
||||
|
||||
## 2. Documents Reviewed
|
||||
|
||||
- `Topics/Skybound/Skybound-Knowledge-Hub.md`
|
||||
- `Topics/Skybound/01_Core_Engine/Skybound-Modular-Game-Architecture.md`
|
||||
- `Topics/Skybound/01_Core_Engine/Game-Engine-Loop-and-System-Orchestration.md`
|
||||
- `Topics/Skybound/05_Project_Issues/2026-04-22_Engine_Stability_Audit.md`
|
||||
- `Topics/Skybound/02_Combat_AI/Combat-System-and-Bullet-Interaction-Pipeline.md`
|
||||
- `Topics/Skybound/04_Mechanics_Progression/Campaign_and_Dual_Loop_System.md`
|
||||
- `Topics/Skybound/04_Mechanics_Progression/InGame_Progression_System.md`
|
||||
- `Technical_Reports/2026-04-22_Boss_Battle_System_Implementation.md`
|
||||
|
||||
## 3. Code Structure Observations
|
||||
|
||||
Skybound's actual runtime center is `src/features/game/hooks/useGameEngine.ts`. It directly instantiates and updates `EntityManager`, `StageDirectorSystem`, `SpawnerSystem`, `CombatSystem`, `ProgressionSystem`, `ModularWeaponSystem`, `TacticalSystem`, `HazardSystem`, `BossSystem`, `EffectSystem`, and `GameRenderer`.
|
||||
|
||||
`SystemManager.ts` exists and documents a centralized orchestration pattern, but the active engine path does not use it. This is not inherently broken, but it creates a mismatch between the documented orchestrator and the actual execution path.
|
||||
|
||||
React is primarily responsible for scene composition and modal/UI handling through `GameSceneRenderer.tsx`, while Zustand state is centralized in `useGameStore.ts`.
|
||||
|
||||
## 4. Confirmed Problems
|
||||
|
||||
### 4.1 Build Gate Is Broken
|
||||
|
||||
`npm run build` fails. Representative causes:
|
||||
|
||||
- `App.tsx` imports `useGameEngine` but does not use it.
|
||||
- Legacy `src/features/game/combatSystem.ts` is still included in TypeScript compilation and has type drift against current domain models.
|
||||
- `useSceneAudio.ts` does not include `HANGAR` in `SCENE_AUDIO`, despite `Scene` including `HANGAR`.
|
||||
- `SystemBoss.phase` is typed as `1 | 2 | 3`, while `bossRegistry.ts` contains a 4-phase boss.
|
||||
- `GameRenderer.ts` calls `CanvasRenderingContext2D.close()`, which should be `closePath()`.
|
||||
- `EntityManager` initializes enemies with `movePattern: 'NONE'`, which is not part of the current `Enemy.movePattern` union.
|
||||
|
||||
### 4.2 Timeline Spawn Intents Are Not Wired
|
||||
|
||||
`StageDirectorSystem` dispatches `SCRIPTED_SPAWN` and `SPAWN_MODE` intents, but `useGameEngine.ts` does not route those intents to `SpawnerSystem`.
|
||||
|
||||
`SpawnerSystem` already provides `notifyScriptedSpawn()` and `activateSwarmBurst()`, so the design exists but the active dispatch wiring is missing.
|
||||
|
||||
Expected impact: scripted waves and burst events may not appear as designed, leaving procedural spawning to carry too much of the combat pacing.
|
||||
|
||||
### 4.3 Campaign Stage State Is Not a Single Source of Truth
|
||||
|
||||
`StageDirectorSystem` receives `campaignStageIndex` when created, but `GameState.currentStage` still defaults to `1` and is not initialized from the selected campaign stage.
|
||||
|
||||
Expected impact: Standard campaign can show stage progression in UI while the engine continues to evaluate boss selection, damage curves, backgrounds, rewards, and tech-part rolls as Stage 1.
|
||||
|
||||
### 4.4 StageManager Mode Can Drift from Store Mode
|
||||
|
||||
`StageManager` has its own internal `mode`, defaulting to `BLITZ`. The UI updates Zustand `stageMode`, but `stageManager.setMode()` is not called from the store action.
|
||||
|
||||
Expected impact: Standard campaign clear can call `stageManager.onStageClear()` while the singleton still believes it is in Blitz mode, preventing next-stage campaign progression.
|
||||
|
||||
### 4.5 COMMS Events Are Not Rendered
|
||||
|
||||
`COMMS` events are emitted by engine systems, and `CommsOverlay.tsx` exists, but `useGameEngine.ts` does not map `COMMS` events to `useGameStore.setComms()`. `CommsOverlay` is also not rendered by `App.tsx`.
|
||||
|
||||
Expected impact: mission dialogue, warning text, and tactical pacing messages are silently dropped.
|
||||
|
||||
### 4.6 Starter Weapon Timer Is Not Cleaned Up
|
||||
|
||||
`useGameEngine.ts` starts a `setTimeout()` for starter weapon selection, but cleanup does not clear the timer.
|
||||
|
||||
Expected impact: if the engine unmounts quickly, a stale timer can emit a level-up modal or pause signal from an old engine instance.
|
||||
|
||||
### 4.7 Skill Sync Boundary Is Fragile
|
||||
|
||||
`GameSceneRenderer.tsx` calls store `addSkill()` and then engine `applySkill()`. `ProgressionSystem.applySkillSelection()` says Zustand owns skill increments, but also mutates `state.skills` as a fallback.
|
||||
|
||||
Expected impact: this usually works because of the store subscription bridge, but the ownership boundary is not clean and may cause missed or inconsistent skill levels under timing stress.
|
||||
|
||||
## 5. Stabilization Plan
|
||||
|
||||
Priority order:
|
||||
|
||||
1. Restore TypeScript build by removing obvious compile blockers and isolating legacy drift.
|
||||
2. Wire `SCRIPTED_SPAWN` and `SPAWN_MODE` intents from `StageDirectorSystem` into `SpawnerSystem`.
|
||||
3. Initialize engine `currentStage` from `stageMode` and `campaignStageIndex`.
|
||||
4. Keep `StageManager` mode synchronized with Zustand `stageMode`.
|
||||
5. Route `COMMS` events into the store and render `CommsOverlay`.
|
||||
6. Clear the starter weapon timer during engine cleanup.
|
||||
|
||||
## 6. Verification Targets
|
||||
|
||||
- `npm run build`
|
||||
- `npm run lint` as a visibility check, with the expectation that broad historical lint debt may remain after the first stabilization pass.
|
||||
|
||||
## 7. Implementation Result
|
||||
|
||||
The first stabilization pass was applied immediately after this raw audit.
|
||||
|
||||
### 7.1 Build Recovery
|
||||
|
||||
- Removed an unused `useGameEngine` import from `App.tsx`.
|
||||
- Added `HANGAR` to `SCENE_AUDIO` in `useSceneAudio.ts`.
|
||||
- Excluded legacy `src/features/game/combatSystem.ts` from `tsconfig.app.json` because the active runtime path uses `src/features/game/systems/CombatSystem.ts`.
|
||||
- Expanded boss phase typing from `1 | 2 | 3` to `number` so 4-phase registry bosses are valid.
|
||||
- Fixed `EntityManager` default enemy `movePattern` from invalid `NONE` to `SIDE_TO_SIDE`.
|
||||
- Fixed `CanvasRenderingContext2D.close()` to `closePath()`.
|
||||
- Removed compile-blocking unused locals from active systems.
|
||||
|
||||
### 7.2 Runtime Wiring Recovery
|
||||
|
||||
- `SCRIPTED_SPAWN` intents now call `SpawnerSystem.notifyScriptedSpawn()`.
|
||||
- `SPAWN_MODE` intents now activate `SWARM_BURST` or enqueue `MINI_BOSS` spawns.
|
||||
- Engine `currentStage` now initializes from `campaignStageIndex + 1` in Standard mode.
|
||||
- Zustand `setStageMode()` now synchronizes the `StageManager` singleton mode.
|
||||
- `COMMS` engine events now populate `useGameStore.activeComms`.
|
||||
- `CommsOverlay` is rendered while playing.
|
||||
- Starter weapon selection timer is cleared during engine cleanup.
|
||||
|
||||
### 7.3 Verification Result
|
||||
|
||||
- `npm run build`: passed.
|
||||
- `npm run lint`: still fails due broad pre-existing lint debt, mostly `@typescript-eslint/no-explicit-any`, older helper files, and React hook lint findings. The first pass reduced the functional blockers but did not attempt a large-scale type cleanup.
|
||||
+149
@@ -0,0 +1,149 @@
|
||||
# Skybound Final Stylized Casual Magitech Redirection
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw art direction correction after final concept change
|
||||
|
||||
## 1. Reason for Redirection
|
||||
|
||||
The previous pass moved Skybound toward **Semirealistic Magitech Fantasy**, but the latest direction returns the project to a clearer and more immediately readable mobile-survival style.
|
||||
|
||||
The new target is **Stylized Casual Magitech** for a top-down survival shooter inspired by Survivor.io.
|
||||
|
||||
This direction prioritizes:
|
||||
|
||||
- maximum in-game visibility
|
||||
- bold silhouettes
|
||||
- thick readable outlines
|
||||
- flat lighting
|
||||
- vivid magical accents
|
||||
- consistent UI language from intro to mission result
|
||||
|
||||
## 2. Core Concept
|
||||
|
||||
Skybound should feel like a polished casual magitech action game rather than a dark semirealistic fantasy title.
|
||||
|
||||
Primary gameplay readability goals:
|
||||
|
||||
- player vehicle must be instantly identifiable
|
||||
- enemies must remain readable in dense hordes
|
||||
- pickups and weapon icons must be recognizable at small sizes
|
||||
- background grid must support movement clarity without competing with combat
|
||||
- every exposed screen should share the same playful magitech frame language
|
||||
|
||||
## 3. Tone and Manner
|
||||
|
||||
### Stylized Casual Magitech
|
||||
|
||||
Visual language:
|
||||
|
||||
- bold navy outlines
|
||||
- clean top-down silhouettes
|
||||
- flat color blocks
|
||||
- minimal material noise
|
||||
- bright arcane cyan
|
||||
- gold/orange mechanical accents
|
||||
- purple and pink enemy/corruption accents
|
||||
- chunky UI frames
|
||||
- high contrast buttons and progress bars
|
||||
|
||||
Avoid:
|
||||
|
||||
- gritty brushed metal
|
||||
- heavy realistic shadows
|
||||
- low-contrast dark UI
|
||||
- thin semireal linework
|
||||
- noisy texture detail
|
||||
- external non-project image dependencies
|
||||
|
||||
## 4. Palette
|
||||
|
||||
Base colors:
|
||||
|
||||
- deep navy outline
|
||||
- saturated royal blue panels
|
||||
- readable sapphire floor tiles
|
||||
- bright brass and gold trim
|
||||
|
||||
Magic accents:
|
||||
|
||||
- arcane cyan for player and positive energy
|
||||
- crystal white-blue for highlights
|
||||
- vivid purple for advanced magic
|
||||
- hot pink for danger and enemy cores
|
||||
- mint green for healing and positive pickups
|
||||
- orange/gold for calls to action
|
||||
|
||||
## 5. Screen Coverage
|
||||
|
||||
The exposed user-facing screens were reviewed and targeted by the final theme pass:
|
||||
|
||||
- Intro title screen
|
||||
- Airframe select screen
|
||||
- Hangar / upgrade overlay
|
||||
- In-game HUD
|
||||
- Quick start overlay
|
||||
- Tutorial overlay
|
||||
- Comms overlay
|
||||
- Level up modal
|
||||
- Mission success / failed / complete result screen
|
||||
|
||||
## 6. Asset Coverage
|
||||
|
||||
The procedural asset generator now outputs the final Stylized Casual Magitech library while preserving runtime file paths.
|
||||
|
||||
Generated categories:
|
||||
|
||||
- Magitech player airframes
|
||||
- normal enemies
|
||||
- elite enemies
|
||||
- bosses
|
||||
- modular stage tiles
|
||||
- title and result local backdrops
|
||||
- item drop sprite sheet
|
||||
- turret sheet
|
||||
- weapon and skill icons
|
||||
- projectiles
|
||||
- shield and currency icons
|
||||
- muzzle flash, impact, explosion, and laser VFX
|
||||
- commander and pilot portraits
|
||||
- contact sheet preview
|
||||
|
||||
## 7. Implementation Notes
|
||||
|
||||
The generator was redirected away from semirealistic material rendering and toward flat, readable shapes.
|
||||
|
||||
Main implementation choices:
|
||||
|
||||
- palette updated to bright casual magitech colors
|
||||
- default shape helpers now draw bold navy outlines
|
||||
- material texture strength reduced to keep assets flat
|
||||
- background tiles use readable grid blocks and low-competition arcane circuitry
|
||||
- local title and result background images were generated
|
||||
- title and result screens no longer depend on external Google image URLs
|
||||
- global magitech CSS override was rewritten for the final casual tone
|
||||
|
||||
## 8. Changed Runtime Paths
|
||||
|
||||
Important changed or generated paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/scripts/generate_magitech_assets.py`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/styles/magitechArt.css`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/TitleScreen.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/ResultCard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/magitech_art_contact_sheet.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/background/title_magitech.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/background/result_magitech.png`
|
||||
|
||||
## 9. Verification
|
||||
|
||||
Asset generation completed successfully.
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The build still reports that `/sprites/player.png` is left unresolved at build time, which is a Vite static asset warning and was already non-blocking. The production bundle was generated successfully.
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Skybound HUD and TAC Level Up Stylized Casual Magitech Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix from gameplay HUD screenshot review
|
||||
|
||||
## 1. Screenshot Issues
|
||||
|
||||
The reviewed gameplay screenshots showed that the HUD and TAC Level Up modal still leaned heavily into the previous cyber-terminal style.
|
||||
|
||||
Observed issues:
|
||||
|
||||
- side HUD panels used thin cyan lines and transparent glass styling
|
||||
- top TAC level widget looked like a cold terminal module
|
||||
- control buttons were dark monochrome blocks
|
||||
- TAC Level Up modal used glitch text and blue terminal cards
|
||||
- skill cards did not share the bold casual magitech frame language
|
||||
|
||||
## 2. Cause
|
||||
|
||||
The global `magitechArt.css` provided the broad art direction, but component-level CSS files still applied later or more specific styles.
|
||||
|
||||
Main affected files:
|
||||
|
||||
- `HUDOverlay.css`
|
||||
- `LevelUpModal.css`
|
||||
|
||||
These files preserved the original Stitch/cyber UI look and overrode parts of the new tone.
|
||||
|
||||
## 3. Fixes Applied
|
||||
|
||||
### HUD
|
||||
|
||||
HUD styling was redirected to Stylized Casual Magitech:
|
||||
|
||||
- chunky navy outlines
|
||||
- rounded blue magitech panels
|
||||
- gold active highlights
|
||||
- mint/cyan resource bars
|
||||
- less transparent glass
|
||||
- stronger mobile-game button affordance
|
||||
- side modules grouped into readable cards
|
||||
- top TAC level widget converted to a framed casual panel
|
||||
|
||||
### TAC Level Up Modal
|
||||
|
||||
The level-up modal was restyled:
|
||||
|
||||
- removed glitch pseudo text
|
||||
- removed aggressive terminal skew animation
|
||||
- converted the modal into a rounded blue magitech reward panel
|
||||
- added thick dark outline and drop-shadow depth
|
||||
- changed skill cards to chunky selectable cards
|
||||
- changed icon boxes to framed magitech sockets
|
||||
- converted level dots into brighter readable pips
|
||||
- kept EVO cards gold/orange for special hierarchy
|
||||
|
||||
## 4. Changed Runtime Paths
|
||||
|
||||
Important changed paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HUDOverlay.css`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
|
||||
|
||||
## 5. Verification
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static path warning remains non-blocking.
|
||||
+83
@@ -0,0 +1,83 @@
|
||||
# Skybound Nova Burst Icon and Effect Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix for skill-specific visual mismatch
|
||||
|
||||
## 1. Screenshot Issue
|
||||
|
||||
`Nova Burst` looked like a lemon-shaped projectile icon.
|
||||
|
||||
This did not match the actual skill behavior.
|
||||
|
||||
## 2. Skill Meaning
|
||||
|
||||
`Nova Burst` is not a missile, crystal shard, or thrown projectile.
|
||||
|
||||
Actual gameplay behavior:
|
||||
|
||||
- automatic radial AoE shockwave
|
||||
- triggers around the player
|
||||
- damages enemies inside the radius
|
||||
- knocks enemies outward
|
||||
- cooldown-based burst every few seconds
|
||||
- evolves into `Nova Guardian`, which adds stronger golden guardian behavior
|
||||
|
||||
## 3. Art Direction Correction
|
||||
|
||||
The icon should communicate:
|
||||
|
||||
- central arcane core
|
||||
- circular shockwave expansion
|
||||
- radial force
|
||||
- rune-like magitech energy
|
||||
- area control around the player
|
||||
|
||||
It should not communicate:
|
||||
|
||||
- lemon
|
||||
- fruit
|
||||
- single projectile
|
||||
- gem pickup
|
||||
- missile tip
|
||||
|
||||
## 4. Fixes Applied
|
||||
|
||||
The procedural generator now creates `Nova Burst.png` with a dedicated `nova` icon shape.
|
||||
|
||||
New visual structure:
|
||||
|
||||
- cyan circular shockwave rings
|
||||
- central navy magitech core
|
||||
- arcane core light
|
||||
- radial spokes showing outward force
|
||||
- subtle purple secondary energy ring
|
||||
|
||||
The in-game Nova Burst renderer was also adjusted:
|
||||
|
||||
- center sprite is smaller and treated as a rune core
|
||||
- expanding shockwave ring is now the main visual read
|
||||
- added translucent pressure disk
|
||||
- added segmented rune ring
|
||||
- kept Guardian variant as gold/orange
|
||||
|
||||
## 5. Changed Runtime Paths
|
||||
|
||||
Important changed paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/scripts/generate_magitech_assets.py`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/missiles/Nova Burst.png`
|
||||
|
||||
## 6. Verification
|
||||
|
||||
Asset generation completed successfully.
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static asset warning remains non-blocking.
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Skybound Particle and Supply Readability Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix from gameplay screenshot review
|
||||
|
||||
## 1. Screenshot Issues
|
||||
|
||||
The reviewed screenshot exposed two readability problems.
|
||||
|
||||
Observed issues:
|
||||
|
||||
- Mint/cyan square particles were scattered across the floor and looked like items even though they could not be collected.
|
||||
- The supply crate asset looked good, but it was not clear whether it was a player pickup or an enemy projectile/debris object.
|
||||
|
||||
## 2. Cause
|
||||
|
||||
### Mint Floor Squares
|
||||
|
||||
The mint squares were runtime particles from `EffectSystem`.
|
||||
|
||||
They were rendered in `GameRenderer.renderEffects()` using `fillRect()`, so every spark appeared as a small collectible-looking square.
|
||||
|
||||
These particles can come from combat hits, skill effects, EMP interactions, exp pickup feedback, or other short-lived feedback systems.
|
||||
|
||||
### Supply Ambiguity
|
||||
|
||||
The supply crate sprite itself was readable as an object, but the gameplay affordance was weak.
|
||||
|
||||
It needed explicit pickup language:
|
||||
|
||||
- pickup color
|
||||
- capture ring
|
||||
- directional marker
|
||||
- short label
|
||||
|
||||
## 3. Fixes Applied
|
||||
|
||||
### Particle Shape
|
||||
|
||||
Runtime particles now render as small rotated diamond sparks instead of square floor blocks.
|
||||
|
||||
This keeps the magical spark feedback while reducing item confusion.
|
||||
|
||||
Normal shard fragments were also changed from square blocks to triangular fragments.
|
||||
|
||||
### Supply Pickup Readability
|
||||
|
||||
Supply drops now render with:
|
||||
|
||||
- mint-green dashed pickup ring
|
||||
- soft pickup fill
|
||||
- bobbing downward arrow
|
||||
- retained supply crate sprite
|
||||
- `PICK UP` label
|
||||
|
||||
This separates supply drops from enemy bullets, hazards, and cosmetic particles.
|
||||
|
||||
## 4. Changed Runtime Paths
|
||||
|
||||
Important changed path:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
|
||||
## 5. Verification
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static path warning remains non-blocking.
|
||||
+141
@@ -0,0 +1,141 @@
|
||||
# Skybound Semirealistic Magitech Fantasy Redirection
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw art direction correction before second asset pass
|
||||
|
||||
## 1. Reason for Redirection
|
||||
|
||||
The first generated art pack leaned too far into childish cartoon readability: thick outlines, flat toy-like shapes, and simplified symbolic silhouettes.
|
||||
|
||||
The new target is **Semirealistic Magitech Fantasy** for a top-down horde survival-shmup inspired by Survivor.io, aimed at players aged 12-18 and casual adults.
|
||||
|
||||
## 2. Core Concept
|
||||
|
||||
The visual library should feel detailed, grounded, and cool rather than cute.
|
||||
|
||||
Primary references by feel:
|
||||
|
||||
- League of Legends-like readable fantasy detail
|
||||
- Warhammer-like dark material weight
|
||||
- Survivor.io-like top-down clarity and grid readability
|
||||
|
||||
This is still a game with high enemy density, so readability remains critical, but contrast should come from lighting, value, and energy color rather than thick black outlines.
|
||||
|
||||
## 3. Tone and Manner
|
||||
|
||||
### Semirealistic Magitech
|
||||
|
||||
Visual language:
|
||||
|
||||
- dark iron
|
||||
- aged brass
|
||||
- brushed metal
|
||||
- weathered stone
|
||||
- glowing crystals
|
||||
- engraved runes
|
||||
- arcane circuitry
|
||||
- controlled deep shadows
|
||||
- focused magical highlights
|
||||
|
||||
Avoid:
|
||||
|
||||
- childish cartoon shapes
|
||||
- toy-like flat icons
|
||||
- heavy black outlines
|
||||
- overly bright candy palettes
|
||||
- large simplified emblem-only designs
|
||||
|
||||
## 4. Palette
|
||||
|
||||
Base colors:
|
||||
|
||||
- dark sapphire
|
||||
- dark iron
|
||||
- forest green
|
||||
- weathered brass
|
||||
- basalt gray
|
||||
- deep crimson
|
||||
|
||||
Magic accents:
|
||||
|
||||
- arcane blue for player energy
|
||||
- neon purple for corruption
|
||||
- plasma red for enemy/boss danger
|
||||
- molten orange for forge/lava accents
|
||||
|
||||
## 5. Asset Rules
|
||||
|
||||
### Player Vehicle
|
||||
|
||||
The player vehicle should read as a Magitech airship rather than a simple airplane.
|
||||
|
||||
Required traits:
|
||||
|
||||
- complex symmetrical or slightly asymmetrical hull
|
||||
- dark iron and brass material mix
|
||||
- intense crystalline power core
|
||||
- smaller gun turrets
|
||||
- visible engine components, gears, vents, and rune plates
|
||||
- subtle energy glow readable from top-down view
|
||||
|
||||
### Enemies
|
||||
|
||||
Enemies should be threatening corrupted creatures or ancient mechanical horrors.
|
||||
|
||||
Examples:
|
||||
|
||||
- clockwork spiders with poison sacks
|
||||
- rune golems made of dark stone
|
||||
- corrupted winged drakes
|
||||
- ancient mechanical horrors with plasma-red cores
|
||||
|
||||
### Background
|
||||
|
||||
Background should preserve Survivor.io-style grid readability but feel like an immersive fantasy environment.
|
||||
|
||||
Target environments:
|
||||
|
||||
- ancient overgrown Magitech city ruin
|
||||
- subterranean magma forge
|
||||
|
||||
Rules:
|
||||
|
||||
- weathered stone pavement
|
||||
- broken magitech circuitry embedded in the floor
|
||||
- basalt structures
|
||||
- subtle lava or arcane channels
|
||||
- background contrast lower than enemies and player
|
||||
|
||||
### Effects
|
||||
|
||||
Player effects should be arcane blue or crystal cyan.
|
||||
|
||||
Enemy effects should lean plasma red, purple, or corrupted crimson.
|
||||
|
||||
Death effects should be optimized and satisfying:
|
||||
|
||||
- scrap metal shards
|
||||
- dark crystal fragments
|
||||
- arcane dust
|
||||
- controlled flashes, not full-screen clutter
|
||||
|
||||
### UI
|
||||
|
||||
UI should use Survivor.io-like directness with a refined dark iron and crystal shell.
|
||||
|
||||
Required traits:
|
||||
|
||||
- heavy dark iron frames
|
||||
- crystal level bar
|
||||
- rune and gear details
|
||||
- minimal but detailed HUD
|
||||
- clean modern gothic / steampunk-inspired readability
|
||||
|
||||
## 6. Implementation Notes
|
||||
|
||||
The next pass should replace the first cartoony art pack with a darker semirealistic procedural raster set while preserving runtime file paths.
|
||||
|
||||
The existing generator should be rewritten so future iterations can adjust palette, materials, and silhouettes consistently.
|
||||
|
||||
+153
@@ -0,0 +1,153 @@
|
||||
# Skybound Semirealistic Magitech Fantasy Art Pack
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Superseded by semirealistic second pass
|
||||
|
||||
## 1. Direction
|
||||
|
||||
Skybound's 2D visual identity was first redirected toward **Stylized Casual Magitech**, then corrected into **Semirealistic Magitech Fantasy** after visual review.
|
||||
|
||||
The corrected target tone is a top-down survival shooter inspired by clear mobile action readability, but with more mature fantasy material treatment:
|
||||
|
||||
- reduced outlines
|
||||
- dark iron and brass material language
|
||||
- controlled lighting
|
||||
- glowing crystalline cores
|
||||
- corrupted magical enemies
|
||||
- ancient magitech ruin backgrounds
|
||||
- high contrast at small gameplay sizes
|
||||
- color-coded enemy and weapon readability
|
||||
- playful magitech forms instead of realistic military hardware
|
||||
|
||||
## 2. Core Art Rules
|
||||
|
||||
### Silhouette
|
||||
|
||||
Every gameplay object must remain readable at 36-72px on canvas.
|
||||
|
||||
- Player vehicles use triangular forward-facing silhouettes.
|
||||
- Normal enemies use compact diamond/bug-like silhouettes.
|
||||
- Elite enemies use wider, more decorated silhouettes.
|
||||
- Bosses use tall central hulls with visible side modules and glowing cores.
|
||||
- Weapons and drops use symbolic icons instead of detailed illustrations.
|
||||
|
||||
### Linework
|
||||
|
||||
Use value contrast and glow separation instead of heavy cartoon outlines.
|
||||
|
||||
Purpose:
|
||||
|
||||
- separates sprites from busy scrolling backgrounds through lighting
|
||||
- keeps bullets, drops, and enemies visible during VFX-heavy combat
|
||||
- supports a grounded semirealistic style
|
||||
|
||||
### Lighting
|
||||
|
||||
Lighting is controlled and directional. Avoid noisy photorealism, but use subtle brushed metal, stone, and crystal texture.
|
||||
|
||||
Allowed:
|
||||
|
||||
- small inner highlights
|
||||
- soft magical glow behind important objects
|
||||
- subtle bevels
|
||||
- material grain
|
||||
- controlled shadow
|
||||
|
||||
Avoid:
|
||||
|
||||
- toy-like flat panels
|
||||
- low-contrast smoke
|
||||
- tiny greeble details
|
||||
|
||||
### Palette
|
||||
|
||||
Corrected palette:
|
||||
|
||||
- Void: `#080a12`
|
||||
- Dark iron: `#1c2029`
|
||||
- Aged brass: `#a57a37`
|
||||
- Dark sapphire: `#102a52`
|
||||
- Forest green: `#164535`
|
||||
- Crimson: `#671a20`
|
||||
- Arcane blue: `#36cdff`
|
||||
- Neon purple: `#b03eff`
|
||||
- Plasma red: `#ff4149`
|
||||
- Molten orange: `#ff7a21`
|
||||
|
||||
## 3. Generated Asset Coverage
|
||||
|
||||
The following runtime assets were regenerated in-place under `public/sprites`:
|
||||
|
||||
- player airframes: `Falcon.png`, `rayce.png`
|
||||
- charge shot: `chargeshot.png`
|
||||
- normal enemies: `normal_enemy/enemy01.png` through `enemy09.png`
|
||||
- elite enemies: `elite_enemy/elite01.png` through `elite16.png`
|
||||
- bosses: `boss/tile000.png` through `tile010.png`
|
||||
- turret atlas: `turret/turret_sprites.png`
|
||||
- item drops: `item_drops_sprite.png`
|
||||
- stage backgrounds: `background/stage_tile_1.png` through `stage_tile_8.png`
|
||||
- weapon and skill icons under `sprites/missiles`
|
||||
- core bullet, shield, currency, VFX sprites
|
||||
- comms portraits: `portraits/hq_commander.png`, `portraits/pilot_standard.png`
|
||||
|
||||
## 4. UI Skin Coverage
|
||||
|
||||
The UI skin was added through:
|
||||
|
||||
- `src/features/game/styles/magitechArt.css`
|
||||
- imported from `src/App.css`
|
||||
|
||||
The skin aligns:
|
||||
|
||||
- HUD panels
|
||||
- level-up cards
|
||||
- comms overlay
|
||||
- hangar/action buttons
|
||||
- warning text
|
||||
- canvas saturation/contrast
|
||||
|
||||
## 5. Generator
|
||||
|
||||
The art pack is reproducible through:
|
||||
|
||||
`scripts/generate_magitech_assets.py`
|
||||
|
||||
This script uses the bundled Python runtime with Pillow and generates vector-like raster PNGs. It intentionally avoids relying on one-off manual image files so future palette or silhouette changes can be regenerated consistently.
|
||||
|
||||
## 6. Preview Sheet
|
||||
|
||||
Generated preview sheet:
|
||||
|
||||
`public/sprites/magitech_art_contact_sheet.png`
|
||||
|
||||
The preview sheet is for art review only and is not currently consumed by the game runtime.
|
||||
|
||||
## 7. Follow-up Art Tasks
|
||||
|
||||
Recommended next art pass:
|
||||
|
||||
1. Add animation frame variants for normal and elite enemies.
|
||||
2. Split skill icons into a formal UI icon atlas instead of relying on individual PNGs.
|
||||
3. Add boss-specific silhouettes matching the narrative names in `bossRegistry.ts`.
|
||||
4. Add projectile color language documentation for player, enemy, boss, and gimmick bullets.
|
||||
5. Replace remaining CSS vocabulary from older cyber-neon UI with magitech naming over time.
|
||||
|
||||
## 8. Second Pass Correction
|
||||
|
||||
After user review, the first art pack was judged too childish/cartoon-like. The generator and UI skin were rewritten.
|
||||
|
||||
Second pass changes:
|
||||
|
||||
- removed thick outlines
|
||||
- added brushed metal / stone noise
|
||||
- added stronger shadows and glow-based separation
|
||||
- changed vehicles into darker magitech airships
|
||||
- changed enemies into corrupted mechanical/stone silhouettes
|
||||
- changed backgrounds into darker stone grid ruins with broken circuitry
|
||||
- changed UI from bright toy-card framing to dark iron/crystal framing
|
||||
|
||||
The reproducible generator remains:
|
||||
|
||||
`scripts/generate_magitech_assets.py`
|
||||
+102
@@ -0,0 +1,102 @@
|
||||
# Skybound Stylized Casual Magitech Ingame Asset Fix
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw follow-up fix from gameplay screenshot review
|
||||
|
||||
## 1. Screenshot Issues
|
||||
|
||||
The reviewed screenshots exposed three in-game visual problems.
|
||||
|
||||
Observed issues:
|
||||
|
||||
- `SUPPLY` air drop was rendered as a simple cyan ring and text label instead of a proper magitech supply crate.
|
||||
- Enemy sprites showed a faint rectangular transparency box around the aircraft body.
|
||||
- Large falling translucent circular hazards were rendered as plain gray circles and did not match the Stylized Casual Magitech tone.
|
||||
|
||||
## 2. Cause
|
||||
|
||||
### Supply Drop
|
||||
|
||||
The supply drop was not using an image asset.
|
||||
|
||||
It was drawn directly in `GameRenderer.renderAirDrops()` as:
|
||||
|
||||
- animated circle stroke
|
||||
- translucent cyan fill
|
||||
- white `SUPPLY` text
|
||||
|
||||
### Enemy Rectangle Artifact
|
||||
|
||||
The procedural generator used glow layers and Lanczos downsampling.
|
||||
|
||||
This left very low alpha pixels across the image canvas. In gameplay, those tiny alpha values became visible as a faint rectangular box around enemies.
|
||||
|
||||
### Falling Circular Hazard
|
||||
|
||||
The falling translucent circle was an `EMP_CLOUD` hazard.
|
||||
|
||||
It was drawn directly in `GameRenderer.renderHazards()` as a generic gray filled circle.
|
||||
|
||||
## 3. Fixes Applied
|
||||
|
||||
### Supply Drop Asset
|
||||
|
||||
A new stylized magitech crate sprite was generated:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/supply_crate.png`
|
||||
|
||||
The renderer now draws this crate for air drops while preserving a small dashed cyan capture ring.
|
||||
|
||||
### Alpha Cleanup
|
||||
|
||||
The procedural asset generator now clamps very low alpha values to `0` during PNG export.
|
||||
|
||||
This removes transparent rectangle artifacts while keeping intended outlines, glow, and silhouettes.
|
||||
|
||||
Verified enemy sprite alpha:
|
||||
|
||||
- normal enemy corner alpha: `0`
|
||||
- elite enemy corner alpha: `0`
|
||||
- boss corner alpha: `0`
|
||||
- no alpha values below the cleanup threshold remain
|
||||
|
||||
### Hazard Assets
|
||||
|
||||
New hazard sprites were generated:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_emp.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_asteroid.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_debris.png`
|
||||
|
||||
`EMP_CLOUD` now renders as an arcane rune-field instead of a plain gray circle.
|
||||
|
||||
`ASTEROID` and `DEBRIS` can render as stylized magitech rock fragments instead of fallback circles.
|
||||
|
||||
## 4. Changed Runtime Paths
|
||||
|
||||
Important changed or generated paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/scripts/generate_magitech_assets.py`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameAssets.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/utils/SpriteUtils.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/supply_crate.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_emp.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_asteroid.png`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/vfx/vfx_hazard_debris.png`
|
||||
|
||||
## 5. Verification
|
||||
|
||||
Asset generation completed successfully.
|
||||
|
||||
Alpha inspection confirmed transparent corners and no low-alpha rectangle residue for the checked enemy/boss/supply/hazard sprites.
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The build still reports the existing `/sprites/player.png` static path warning, but it remains non-blocking and the production bundle was generated successfully.
|
||||
+177
@@ -0,0 +1,177 @@
|
||||
# Skybound Survivor-Like Balance Curve Pass
|
||||
|
||||
**Date**: 2026-04-24
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw gameplay balance pass from user playtest feedback
|
||||
|
||||
## 1. Playtest Feedback
|
||||
|
||||
The game shell looked close to Survivor.io / Vampire Survivors, but the actual gameplay did not feel like that genre.
|
||||
|
||||
Reported issues:
|
||||
|
||||
- gameplay did not deliver enough horde-survival pressure
|
||||
- stage balance felt uneven
|
||||
- TAC Level Up pacing felt unbalanced
|
||||
- growth did not form a satisfying user-facing curve
|
||||
|
||||
## 2. Diagnosis
|
||||
|
||||
The previous balance leaned closer to a shmup / tactical shooter.
|
||||
|
||||
Main causes found in code:
|
||||
|
||||
- simultaneous enemy cap was too low for a horde-survival feel
|
||||
- procedural spawn did not fully use the timeline `spawnIntervalMult`
|
||||
- early EXP requirement was too high
|
||||
- EXP growth multiplier was too steep
|
||||
- stage difficulty scaled enemy/bullet stats too aggressively
|
||||
- stage scripted events were compressed too early in the timeline
|
||||
- TAC Level Up card offers were weighted but not structured, so the user could receive awkward choices
|
||||
- starter skill offers could omit key horde-survival archetypes
|
||||
|
||||
## 3. Target Curve
|
||||
|
||||
New target:
|
||||
|
||||
- first meaningful upgrade should arrive quickly
|
||||
- player should see more enemies on screen
|
||||
- enemies should be individually weaker
|
||||
- danger should come from density and positioning, not bullet stat spikes
|
||||
- level-up choices should consistently support build formation
|
||||
- stage progression should rise smoothly rather than jump sharply
|
||||
|
||||
## 4. Applied Balance Changes
|
||||
|
||||
### EXP and Level-Up
|
||||
|
||||
Changes:
|
||||
|
||||
- initial required EXP lowered from `100` to `45`
|
||||
- normal enemy EXP increased from `5` to `7`
|
||||
- elite EXP increased from `25` to `32`
|
||||
- level-up EXP multiplier changed from steep `1.60 / 1.72 / 1.85` to smoother `1.24 / 1.30 / 1.36 / 1.42`
|
||||
|
||||
Expected result:
|
||||
|
||||
- early TAC Level Ups arrive faster
|
||||
- the player can form a build before the first spike
|
||||
- later progression still slows down without becoming a wall
|
||||
|
||||
### TAC Level Up Card Structure
|
||||
|
||||
The card generator now tries to offer:
|
||||
|
||||
- one owned skill upgrade
|
||||
- one synergy / spike-counter / EVO-supporting option
|
||||
- one flexible option
|
||||
|
||||
Expected result:
|
||||
|
||||
- fewer dead-choice screens
|
||||
- higher chance of completing coherent builds
|
||||
- less frustration from random-only card pools
|
||||
|
||||
### Starter Selection
|
||||
|
||||
Starter cards now come from three archetype buckets:
|
||||
|
||||
- primary damage
|
||||
- area / crowd control
|
||||
- utility / defense
|
||||
|
||||
Expected result:
|
||||
|
||||
- every run begins with a usable horde-survival foundation
|
||||
- the first choice feels strategic without becoming punishing
|
||||
|
||||
### Enemy Density and Spawning
|
||||
|
||||
Changes:
|
||||
|
||||
- hard enemy cap increased from `30` to `90`
|
||||
- timeline phase caps increased by stage and phase
|
||||
- procedural spawn interval now uses `spawnIntervalMult`
|
||||
- procedural spawns can arrive in small batches
|
||||
- formation spawns now occur more often
|
||||
- individual enemy HP and speed were reduced to support higher density
|
||||
- elite chance is now a gradual probability instead of flipping too hard by difficulty
|
||||
|
||||
Expected result:
|
||||
|
||||
- more screen-filling horde pressure
|
||||
- less empty movement time
|
||||
- more satisfying weapon-clearing moments
|
||||
|
||||
### Stage Curve
|
||||
|
||||
Changes:
|
||||
|
||||
- stage duration curve changed from `120 + stage * 30s` to `150 + stage * 18s`
|
||||
- stage difficulty scaling reduced from steep `+0.4 per stage` to smoother `+0.18 per stage`
|
||||
- phase difficulty multipliers were lowered
|
||||
- phase enemy caps were increased
|
||||
- scripted wave events are distributed across the stage instead of firing too early
|
||||
|
||||
Expected result:
|
||||
|
||||
- stages feel less spiky and more readable
|
||||
- difficulty rises through density and phase rhythm
|
||||
- player has time to grow before major pressure events
|
||||
|
||||
### Enemy Bullet and Damage Pressure
|
||||
|
||||
Changes:
|
||||
|
||||
- enemy bullet speed curves were reduced
|
||||
- damage curves were reduced
|
||||
- bullet caps were reduced
|
||||
- global enemy bullet speed multiplier reduced
|
||||
- enemy projectile damage multipliers reduced
|
||||
|
||||
Expected result:
|
||||
|
||||
- gameplay moves away from bullet-hell punishment
|
||||
- movement pressure still exists, but horde positioning becomes the main focus
|
||||
|
||||
### Weapon Rhythm
|
||||
|
||||
Several weapon cooldowns were shortened so early picks feel active sooner.
|
||||
|
||||
Nova Burst was also adjusted to trigger sooner and scale more clearly as an AoE crowd-control tool.
|
||||
|
||||
## 5. Changed Runtime Paths
|
||||
|
||||
Important changed paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weaponBehaviors.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
|
||||
## 6. Verification
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static path warning remains non-blocking.
|
||||
|
||||
## 7. Next Playtest Questions
|
||||
|
||||
Recommended next playtest checks:
|
||||
|
||||
- Does the first level-up happen within a satisfying time window?
|
||||
- Does the screen feel populated without becoming unreadable?
|
||||
- Do weapons feel like they clear hordes?
|
||||
- Do stage spikes feel earned rather than sudden?
|
||||
- Does TAC Level Up usually offer at least one desirable choice?
|
||||
+173
@@ -0,0 +1,173 @@
|
||||
# Skybound Core Gameplay Rebalance and Purpose Reset
|
||||
|
||||
**Date**: 2026-04-25
|
||||
**Project**: Skybound Protocol
|
||||
**Author**: Codex
|
||||
**Status**: Raw corrective gameplay pass after balance regression
|
||||
|
||||
## 1. User Playtest Feedback
|
||||
|
||||
The previous balance pass made the game worse.
|
||||
|
||||
Observed issues:
|
||||
|
||||
- TAC Level Up triggered repeatedly and too quickly.
|
||||
- Campaign and Blitz did not communicate a clear purpose.
|
||||
- It was unclear whether the player should dodge bullets, collect upgrades, survive waves, or simply idle.
|
||||
- Standing near the center could clear the stage with little interaction.
|
||||
- Skill choice did not feel strategic because almost any pickup worked.
|
||||
- The foundation felt like it had grown without a clear gameplay plan.
|
||||
|
||||
## 2. Diagnosis
|
||||
|
||||
The previous pass overcorrected toward reward frequency and enemy density.
|
||||
|
||||
Main problems:
|
||||
|
||||
- initial EXP requirement was too low
|
||||
- EXP gem values were too high
|
||||
- level-up carryover allowed too much momentum
|
||||
- no cooldown existed between TAC Level Up events
|
||||
- base magnet radius was too generous
|
||||
- base damage multiplier was too high
|
||||
- weapon cooldowns became too generous
|
||||
- enemy caps became too high for the current combat model
|
||||
- enemies were too weak for the amount of automatic player damage
|
||||
|
||||
The result was a reward flood without enough danger, movement, or tactical pressure.
|
||||
|
||||
## 3. New Gameplay Purpose
|
||||
|
||||
Skybound should not be a pure bullet hell and should not be an idle auto-clear game.
|
||||
|
||||
The intended player loop should be:
|
||||
|
||||
1. Survive incoming enemy formations and hazard pressure.
|
||||
2. Move deliberately to collect EXP gems and supply rewards.
|
||||
3. Choose upgrades that solve the current pressure pattern.
|
||||
4. Build toward synergies and evolutions.
|
||||
5. Enter boss or spike phases with a build that feels earned.
|
||||
|
||||
The main fun should come from:
|
||||
|
||||
- movement under pressure
|
||||
- risk-reward EXP collection
|
||||
- tactical skill choices
|
||||
- visible power growth
|
||||
- stage pressure that asks for different answers
|
||||
|
||||
The player should not be able to win reliably by standing still.
|
||||
|
||||
## 4. Corrective Fixes Applied
|
||||
|
||||
### TAC Level Up Flood Control
|
||||
|
||||
Applied:
|
||||
|
||||
- initial required EXP increased from `45` to `90`
|
||||
- normal enemy EXP reduced from `7` to `4`
|
||||
- elite EXP reduced from `32` to `20`
|
||||
- level-up multiplier increased to `1.42 / 1.48 / 1.55 / 1.62`
|
||||
- added a `360 frame` TAC Level Up lockout after each level-up
|
||||
- EXP carryover is capped to `35%` of the next requirement
|
||||
|
||||
Expected result:
|
||||
|
||||
- level-up moments become meaningful beats
|
||||
- no rapid-fire modal spam
|
||||
- players must keep playing between upgrades
|
||||
|
||||
### Movement Incentive
|
||||
|
||||
Applied:
|
||||
|
||||
- base magnet radius reduced from `180` to `90`
|
||||
- magnet passive now adds `35` per level instead of `60`
|
||||
|
||||
Expected result:
|
||||
|
||||
- EXP collection requires movement
|
||||
- standing still misses more progression
|
||||
- magnet becomes a strategic comfort/passive choice rather than free global collection
|
||||
|
||||
### Idle-Clear Reduction
|
||||
|
||||
Applied:
|
||||
|
||||
- base effective damage reduced from `1.5` to `1.0`
|
||||
- damage passive now provides growth from deliberate investment
|
||||
- several weapon cooldowns were pulled back from the previous overly generous pass
|
||||
- Nova Burst was returned closer to a periodic tactical tool rather than constant auto-clear
|
||||
|
||||
Expected result:
|
||||
|
||||
- early weapons no longer erase all pressure automatically
|
||||
- skill investment matters more
|
||||
- AoE tools help but do not replace positioning
|
||||
|
||||
### Enemy Pressure Recentered
|
||||
|
||||
Applied:
|
||||
|
||||
- hard enemy cap reduced from `90` to `56`
|
||||
- phase caps reduced from the previous overcorrection
|
||||
- enemy HP increased from the previous too-low values
|
||||
- enemies enter deeper into the playfield
|
||||
- enemy speed and bullet pressure were slightly restored
|
||||
- procedural spawn cadence reduced from the flood state
|
||||
|
||||
Expected result:
|
||||
|
||||
- fewer meaningless bodies
|
||||
- enemies apply actual positional pressure
|
||||
- player must dodge, reposition, and collect intentionally
|
||||
|
||||
## 5. Design Rule Going Forward
|
||||
|
||||
Future balance changes should follow this rule:
|
||||
|
||||
Do not increase rewards unless a matching risk or movement requirement exists.
|
||||
|
||||
Examples:
|
||||
|
||||
- faster level-up needs harder collection or less carryover
|
||||
- more enemies need weaker auto-clear or stronger enemy pathing
|
||||
- stronger skills need clearer spike counters or enemy behaviors
|
||||
- more pickups need better pickup affordance and danger around pickup zones
|
||||
|
||||
## 6. Changed Runtime Paths
|
||||
|
||||
Important changed paths:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weaponBehaviors.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
|
||||
## 7. Verification
|
||||
|
||||
Production build completed successfully with:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
The existing `/sprites/player.png` static asset warning remains non-blocking.
|
||||
|
||||
## 8. Next Necessary Design Work
|
||||
|
||||
This corrective patch stabilizes the worst problems, but the project still needs a stronger core design pass.
|
||||
|
||||
Recommended next work:
|
||||
|
||||
- define Campaign as objective-based stages with unique pressure patterns
|
||||
- define Blitz as score/survival mode with explicit risk-reward scoring
|
||||
- add clear stage objectives to HUD
|
||||
- add enemy archetypes that force movement differently
|
||||
- add pickup-risk zones so rewards are not free
|
||||
- review every skill for role identity: damage, crowd control, defense, mobility, economy
|
||||
+103
@@ -0,0 +1,103 @@
|
||||
# Skybound Player Airframe and 8 Stage Boss Continuity Rework
|
||||
|
||||
작성일: 2026-04-25 09:51 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 사용자 기체가 엔진에서 그린 도형 조립처럼 보여 시각적 완성도가 낮아 보이는 문제를 개선한다.
|
||||
- Stage 1 클리어 후 Stage 2로 넘어가는 흐름이 결과 화면으로 끊겨 게임이 단절되는 문제를 개선한다.
|
||||
- Aero Fighters처럼 보스를 처치하고 같은 런 안에서 다음 스테이지로 자연스럽게 이어지는 구조를 만든다.
|
||||
- 총 8개 스테이지를 유지하고, 스테이지가 올라갈수록 난이도가 올라가도록 보스 HP, 파츠, 패턴을 재조정한다.
|
||||
- 각 스테이지 보스가 서로 다른 공격 패턴을 체감할 수 있도록 실행부를 보강한다.
|
||||
|
||||
## 확인한 문제
|
||||
|
||||
### 플레이어 기체 렌더링
|
||||
|
||||
- `GameRenderer.renderPlayer()`에서 플레이어 스프라이트 위에 랜덤 원형 엔진 글로우를 직접 그려서, 기체 뒤쪽이 매 프레임 흔들리는 임시 도형처럼 보였다.
|
||||
- `renderWeaponAttachments()`에서 일부 장착 무기를 `fillRect`, `strokeRect`, 랜덤 원형 플래시로 그려서 톤앤매너에 맞는 완성형 파츠가 아니라 디버그 박스처럼 보일 수 있었다.
|
||||
- 특히 Hyper Sonic Vulcan, Gatling fallback, Missile Pod fallback이 사용자 기체 실루엣과 잘 섞이지 않았다.
|
||||
|
||||
### 스테이지 전환
|
||||
|
||||
- 보스 처치 후 `STAGE_CLEAR`가 되고, 300프레임 뒤 `BOSS_ACTION NEXT_STAGE` 이벤트가 발생한다.
|
||||
- 기존 `useGameEngine`은 이 이벤트를 곧바로 `finishMission('CLEAR')`로 연결했다.
|
||||
- 그 결과 Standard 캠페인에서도 Stage 1 보스 처치 후 결과 화면으로 끊기고, 다음 스테이지는 별도 런처럼 느껴졌다.
|
||||
|
||||
### 보스 패턴
|
||||
|
||||
- `bossActions.ts`에는 Stage 1부터 Stage 8까지 액션 테이블이 있다.
|
||||
- 하지만 `BossSystem.executePattern()`은 일부 액션만 처리하고 있었기 때문에, 실제 전투에서는 많은 액션이 기본 단발 탄으로 떨어질 수 있었다.
|
||||
- `StageDirectorSystem.instantiateBoss()`의 보스 파츠 turretId가 `T-CORE`, `T-WING`, `T-HEAVY`처럼 실제 `TURRET_CATALOG`에 없는 값이라 파츠 포탑이 의도대로 발사되지 않을 수 있었다.
|
||||
- 기존 보스 HP는 Stage 2부터 `5000 * currentStage`로 급격히 올라가 캠페인 커브가 자연스럽지 않았다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 플레이어 기체 완성도 개선
|
||||
|
||||
- 플레이어 엔진 글로우를 랜덤 원형에서 고정된 마기테크 추진 플룸으로 변경했다.
|
||||
- 스프라이트 크기를 72px에서 78px로 약간 키워 중심 기체의 존재감을 높였다.
|
||||
- `drawMagitechPod()` 헬퍼를 추가해 장착 무기를 작은 마기테크 포드 형태로 통일했다.
|
||||
- Vulcan, Gatling fallback, Missile Pod fallback을 박스 도형 대신 다크 블루 메탈 바디, 시안/옐로/핑크 액센트, 라운드 포드 실루엣으로 렌더링한다.
|
||||
- 장착 파츠의 랜덤 플래시를 줄이고 프레임 기반 pulse로 바꿔 덜 튀고 더 의도적으로 보이게 했다.
|
||||
|
||||
### 연속 캠페인 전환
|
||||
|
||||
- Standard 캠페인에서 Stage 1-7 보스 처치 후 `finishMission`을 호출하지 않고, 같은 엔진 런 안에서 다음 스테이지로 전환하도록 변경했다.
|
||||
- 전환 시 다음 작업을 수행한다.
|
||||
- `currentStage` 증가
|
||||
- `campaignStageIndex` 저장
|
||||
- `StageDirectorSystem.advanceToStage()`로 새 타임라인 로드
|
||||
- 활성 총알, 적, 파티클 풀 정리
|
||||
- 스포너 큐 초기화
|
||||
- 보스, 탄막, hazard, airdrop, exp gem, vortex 정리
|
||||
- `INTRO` 페이즈로 재시작
|
||||
- 체력 25% 회복과 120프레임 무적 부여
|
||||
- Stage 안내 텍스트와 HQ comms 출력
|
||||
- Stage 8 보스 처치 시에는 `GAME_COMPLETE`로 결과 화면에 진입한다.
|
||||
- Blitz 모드는 기존처럼 단일 전투 클리어로 유지한다.
|
||||
|
||||
### 8스테이지 보스 커브
|
||||
|
||||
- 보스 HP를 선형 폭증에서 완만한 곡선형 성장으로 변경했다.
|
||||
- Stage 1은 낮게 시작하고, Stage 8은 누적 성장과 보스 패턴 난이도를 고려해 높은 난이도를 갖도록 설계했다.
|
||||
- 보스 파츠 HP도 같은 stage curve를 사용해 코어, 날개, 포탑이 함께 성장한다.
|
||||
- 각 스테이지에 실제 `TURRET_CATALOG`에 존재하는 turretId loadout을 지정했다.
|
||||
|
||||
### 보스 패턴 실행 보강
|
||||
|
||||
- 다음 액션들이 실제 탄막/기믹으로 실행되도록 매핑했다.
|
||||
- `FAN_PART`, `DASH_PART`: 부채꼴 조준 사격
|
||||
- `SIDE_WAVE`: 좌우 측면 웨이브
|
||||
- `ZONE_BOMB`: 안전 구역 압박과 링 탄막
|
||||
- `WALL_WAVE`: 틈이 있는 벽 형태 탄막
|
||||
- `MISSILE_BARRAGE`, `HOMING_CHASE`: 유도성 탄막
|
||||
- `CROSS_CHASE`: 네 방향 교차 추격 탄
|
||||
- `SPIRAL_WEB`, `REVOLVING_FLAME`: 나선 탄막
|
||||
- `BURST_SPLITTER`: 분열형 부채 탄
|
||||
- `GEAR_STORM`: 고밀도 나선과 링 조합
|
||||
- `PRECISION_LOCK`, `SNIPE_GRID`, `LASER_AIM`, `LASER_SWEEP`: 크로스헤어 기반 고속 압박
|
||||
- `TELEPORT_STRIKE`: 보스 위치 변경 후 기습 사격
|
||||
- `GIMMICK_PULSE`, `CC_REVERSE`, `ZONE_COLLAPSE`: 중력장/페이즈존 기믹과 링 탄막
|
||||
- `ULTIMATE_SYMPHONY`: 기존 고난도 복합 패턴 유지
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/StageDirectorSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/BossSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/EntityManager.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 관련 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 플레이테스트 포인트
|
||||
|
||||
- Stage 1 보스 처치 후 결과 화면 없이 Stage 2 INTRO로 자연스럽게 이어지는지 확인한다.
|
||||
- Stage 8 보스 처치 후 `GAME_COMPLETE` 결과로 진입하는지 확인한다.
|
||||
- 장착 무기 파츠가 기체와 과하게 분리되어 보이지 않는지 확인한다.
|
||||
- Stage 3 이후 `ZONE_BOMB`, `WALL_WAVE`, `HOMING_CHASE`, `PRECISION_LOCK` 계열이 회피 목적을 명확히 만드는지 확인한다.
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
# Skybound Skill Concept and Hangar Layout Overlap Fix
|
||||
|
||||
작성일: 2026-04-25 10:09 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 스킬 업그레이드 후 화면에 긴 라이트 기둥만 보이는 문제가 있어 스킬 개념과 연출을 수정한다.
|
||||
- HUD/UI 관점에서 왼쪽에 여러 UI가 겹쳐 나오는 문제가 있어 필요하면 전체적으로 재설계한다.
|
||||
|
||||
## 확인한 문제
|
||||
|
||||
### Hyper-Sonic Vulcan 컨셉 불일치
|
||||
|
||||
- `Hyper-Sonic Vulcan`은 이름상 고속 벌컨/캐논 계열인데 실제 구현은 영구 지속되는 긴 레이저 빔이었다.
|
||||
- `GameRenderer`가 플레이어 기준으로 화면 끝까지 이어지는 두꺼운 시안 빔을 그려서, 스킬이 무기라기보다 긴 조명처럼 보였다.
|
||||
- `ModularWeaponSystem.updateHyperLaser()`도 라인 판정으로 지속 데미지를 넣고 있어 플레이어가 발사/탄막을 체감하기 어려웠다.
|
||||
|
||||
### Hangar UI 겹침
|
||||
|
||||
- `HangarOverlay.tsx`에서 `UPGRADE`와 `PASS` 탭 콘텐츠가 오른쪽 `craft-area` 패널 밖에 렌더링되고 있었다.
|
||||
- 그 결과 CSS Grid의 세 번째 아이템처럼 배치되어 왼쪽 패널/재료 영역과 겹쳐 보였다.
|
||||
- 특히 `UPGRADE` 탭 선택 시 `PERMANENT UPGRADES` 콘텐츠가 왼쪽 재료 패널 위로 올라오는 문제가 발생했다.
|
||||
|
||||
### 전투 보상 텍스트 겹침
|
||||
|
||||
- 적 처치 보상 텍스트가 화면 가장자리에서 생성될 경우 `TechMats`, `+TAC` 같은 텍스트가 잘리거나 서로 겹쳐 보일 수 있었다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Twin Arc Vulcan으로 스킬 컨셉 변경
|
||||
|
||||
- `HYPER_SONIC_VULCAN` 메타데이터 이름을 `Twin Arc Vulcan`으로 변경했다.
|
||||
- 설명도 `Twin magitech cannons fire rapid piercing arc rounds.`로 바꿔 실제 플레이 감각과 맞췄다.
|
||||
- 기존의 영구 레이저 빔 컨셉을 제거하고, 전방 관통 아크 탄환을 빠르게 발사하는 무기로 재설계했다.
|
||||
- 플레이어 좌우 포드에서 3갈래 관통탄을 빠르게 발사해 “벌컨 업그레이드” 느낌을 강화했다.
|
||||
- 스킬이 화면을 덮는 긴 빛이 아니라, 방향성과 탄막 밀도가 있는 공격으로 보이게 했다.
|
||||
|
||||
### 긴 라이트 렌더링 제거
|
||||
|
||||
- `GameRenderer`의 full-screen beam `fillRect()` 렌더링을 제거했다.
|
||||
- 대신 기체 앞쪽 포드에 짧은 muzzle bloom과 짧은 시안 streak만 표시하도록 변경했다.
|
||||
- 화면 전체를 가리는 시각 노이즈를 줄이고, 실제 공격은 projectile 렌더링이 담당하게 했다.
|
||||
|
||||
### Hangar 탭 레이아웃 수정
|
||||
|
||||
- `UPGRADE`와 `PASS` 탭 콘텐츠를 오른쪽 `craft-area` 내부로 이동했다.
|
||||
- 이제 탭 콘텐츠가 왼쪽 `Airframe Telemetry`/`Materials` 패널과 겹치지 않는다.
|
||||
- 기존 스타일을 유지하면서 구조적 렌더링 오류를 먼저 제거했다.
|
||||
|
||||
### Floating Text 안전 영역 처리
|
||||
|
||||
- `ctx.spawnText()`에서 텍스트 생성 위치를 화면 안전 영역 안으로 clamp한다.
|
||||
- 왼쪽 끝/오른쪽 끝에서 적이 죽어도 보상 텍스트가 화면 밖으로 잘리거나 HUD 영역에 과하게 겹치는 현상을 줄였다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/evolutions.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weaponBehaviors.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 플레이테스트 포인트
|
||||
|
||||
- Gatling 진화 후 더 이상 긴 레이저 기둥이 보이지 않는지 확인한다.
|
||||
- `Twin Arc Vulcan`이 빠른 관통 탄막 무기로 체감되는지 확인한다.
|
||||
- Hangar에서 `UPGRADES`, `EVENT PASS` 탭 선택 시 왼쪽 패널과 콘텐츠가 겹치지 않는지 확인한다.
|
||||
- 전투 보상 텍스트가 화면 가장자리에서 잘리지 않는지 확인한다.
|
||||
+105
@@ -0,0 +1,105 @@
|
||||
# Skybound Tac EXP Direct Kill and UI Productization Pass
|
||||
|
||||
작성일: 2026-04-25 10:01 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Tac Level 경험치는 적기를 처치했을 때 바로 획득하게 한다.
|
||||
- 바닥에 경험치 파티클/젬이 떨어져 화면을 어지럽히지 않게 한다.
|
||||
- 너무 빠른 레벨업으로 난이도 밸런스가 무너지는 문제를 완화한다.
|
||||
- Hangar, HUD, Tac Level Up 등 아직 남아 있는 예전 UI 톤을 Stylized Casual Magitech 톤앤매너에 맞게 통일한다.
|
||||
- `THRUST_OUTPUT`처럼 작동하지 않거나 내부 시스템 문자열처럼 보이는 UI 문구를 상품성 있게 정리한다.
|
||||
|
||||
## 확인한 문제
|
||||
|
||||
### Tac EXP
|
||||
|
||||
- `CombatSystem`이 적 사망 시 `spawnExpGem()`을 호출해 바닥에 경험치 젬을 생성하고 있었다.
|
||||
- `ProgressionSystem`은 바닥 젬의 이동, 자석 흡수, 수집을 통해 경험치를 지급했다.
|
||||
- 적 밀도가 올라갈수록 젬이 많이 쌓이고, 화면 가독성과 레벨업 속도 모두 불안정해질 수 있었다.
|
||||
- 기존 젬 값은 일반몹/엘리트몹 기준으로 레벨업을 빠르게 밀어 올리는 구조였다.
|
||||
|
||||
### HUD 문구
|
||||
|
||||
- `SYSTEM_ACTIVE`, `TAC_LEVEL`, `HIGH_SCORE_SYNC`, `COMBO_LINK`, `ENERGY_CELL`, `LOCK_ON`, `HEAT_SIG`, `SHIELD_OS`, `THRUST_OUTPUT` 같은 내부 변수명 스타일 문구가 사용자에게 그대로 노출되고 있었다.
|
||||
- `THRUST_OUTPUT`은 `dodgeCooldownPct`를 읽지만 엔진에서 값을 갱신하지 않아 실질적으로 반응하지 않는 상태였다.
|
||||
|
||||
### Hangar UI
|
||||
|
||||
- 장비 카드가 빈 박스처럼 보이며 아이템명/레벨/스탯 정보가 충분히 드러나지 않았다.
|
||||
- 탭 이름과 슬롯 이름이 기능적이지만 상품 화면처럼 자연스럽지는 않았다.
|
||||
- 전체 스타일이 이전의 얇은 선, 어두운 반투명 박스 중심이라 현재 게임의 굵은 외곽선/밝은 마법 액센트 톤과 어긋났다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Tac EXP 직접 지급
|
||||
|
||||
- `CombatSystem`에서 적 사망 시 더 이상 `spawnExpGem()`을 호출하지 않는다.
|
||||
- 대신 `ctx.grantTacExp()`를 통해 처치 즉시 경험치를 지급한다.
|
||||
- 일반 적: `+1 TAC`
|
||||
- 엘리트 적: `+5 TAC`
|
||||
- 미드 보스: `+16 TAC`
|
||||
- 엘리트 이상만 짧은 `+TAC` 텍스트 피드백을 표시해 화면 노이즈를 줄였다.
|
||||
- 바닥 경험치 젬은 신규 생성되지 않으므로, 플레이 중 먹을 수 없는 파란 점/구슬이 쌓이는 문제가 사라진다.
|
||||
|
||||
### 레벨업 속도 완화
|
||||
|
||||
- `ProgressionSystem.grantExp()`를 추가해 직접 경험치 지급과 기존 젬 수집 지급을 한 곳에서 처리한다.
|
||||
- Spike 전 EXP 부스트는 최대 `x1.25`로 제한했다.
|
||||
- 기존 레벨업 lockout과 carryover cap은 유지해 연속 레벨업 폭주를 방지한다.
|
||||
|
||||
### HUD 상품성 개선
|
||||
|
||||
- `HIGH_SCORE_SYNC` → `Best Run`
|
||||
- `SYSTEM_ACTIVE` → `Falcon Online`
|
||||
- `TAC_LEVEL` → `Tactical Level`
|
||||
- `THRUST_OUTPUT` → `Afterburner`
|
||||
- `ENERGY_CELL` → `Hull Core`
|
||||
- `COMBO_LINK` → `Chain Bonus`
|
||||
- `LOCK_ON` → `Lock-On`
|
||||
- `HEAT_SIG` → `Heat Trace`
|
||||
- `SHIELD_OS` → `Guard Field`
|
||||
- 페이즈 표시도 `BOSS_WARNING` 같은 내부 enum 대신 `Boss Incoming`, `Horde Surge`, `Route Secured` 같은 플레이어용 문구로 매핑했다.
|
||||
- 엔진에서 `setDodgeCooldownPct()`를 실제 dodge 상태에 맞게 갱신해 Afterburner 게이지가 부스트 중 반응하도록 연결했다.
|
||||
|
||||
### Hangar UI 톤 통일
|
||||
|
||||
- Hangar 배경과 패널을 Stylized Casual Magitech 톤으로 보강했다.
|
||||
- 굵은 네이비 외곽선, 청록/민트/골드 마법 액센트, 둥근 카드, 명확한 hover 피드백을 적용했다.
|
||||
- 장비 카드에 아이템 타입, 이름, 레벨, ATK, HP가 보이도록 개선했다.
|
||||
- 탭 이름을 `LOADOUT`, `SYNTHESIS`, `SALVAGE`, `ASTRAL FORGE`, `UPGRADES` 등 더 자연스러운 메뉴명으로 바꿨다.
|
||||
- 빈 슬롯 문구를 `NO MODULE`에서 `Available mount`로 바꿨다.
|
||||
- `SYSTEM MOUNTS`, `MODULE STORAGE`를 각각 `Mount Bays`, `Module Storage`로 정리했다.
|
||||
|
||||
### Level Up 모달 문구 개선
|
||||
|
||||
- `TAC LV`, `TAC LEVEL UP!`, `SELECT TACTICAL ENHANCEMENT` 중심의 시스템 문자열 느낌을 줄였다.
|
||||
- 일반 레벨업: `Tactical Upgrade`
|
||||
- 시작 선택: `Choose First Weapon`
|
||||
- 보급 선택: `Emergency Supply`
|
||||
- 카드 문구도 `NEW ACQUISITION`에서 `New module`로 완화했다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HUDOverlay.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.css`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
- 주요 내부 문자열 검색 결과, 요청에서 지적된 `SYSTEM_ACTIVE`, `THRUST_OUTPUT`, `TAC_LEVEL`, `HIGH_SCORE_SYNC`, `COMBO_LINK`, `ENERGY_CELL`, `LOCK_ON`, `HEAT_SIG`, `SHIELD_OS`는 현재 게임 UI 코드에서 제거되었다.
|
||||
|
||||
## 후속 플레이테스트 포인트
|
||||
|
||||
- 적 처치 후 바닥에 경험치 젬이 신규로 생성되지 않는지 확인한다.
|
||||
- 일반몹을 많이 잡아도 Tac Level이 연속 폭주하지 않는지 확인한다.
|
||||
- Afterburner 게이지가 회피/부스트 중 시각적으로 반응하는지 확인한다.
|
||||
- Hangar 장비 카드가 더 이상 빈 회색 박스처럼 보이지 않고 아이템 정보를 명확히 보여주는지 확인한다.
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# Skybound Vampire Survivors Loop and Stage Curve Preparation
|
||||
|
||||
작성일: 2026-04-25 23:52 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Skybound가 뱀파이어 서바이벌 계열 게임처럼 느껴지도록 재미 요소와 스테이지별 레벨 구조를 준비한다.
|
||||
- 단순히 적을 많이 내보내는 것이 아니라, 성장 선택, 밀도 상승, 진화 완성, 보스 체크포인트가 자연스럽게 이어지도록 만든다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
Skybound는 탑다운 생존 슈터이지만, 기존 구조는 스테이지 시간이 짧고 보스 진입이 빨라 빌드가 완성되기 전에 전투가 끊기는 문제가 있었다. 뱀서류 재미를 만들려면 다음 루프가 안정적으로 반복되어야 한다.
|
||||
|
||||
1. 초반: 첫 무기 선택 후 약한 적을 많이 처치하며 빠르게 1-2회 성장한다.
|
||||
2. 중반: 적 밀도와 엘리트 압박이 올라가며 광역/관통/방어 선택의 의미가 생긴다.
|
||||
3. 후반: 스웜과 미니보스가 들어오며 빌드 조합과 진화 무기가 필요해진다.
|
||||
4. 보스: 완성된 빌드가 제대로 작동하는지 검증한다.
|
||||
5. 다음 스테이지: 같은 빌드를 이어가되 적 밀도, 패턴, 보스 기믹이 상승한다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 8스테이지 Survivor 프로필 추가
|
||||
|
||||
`CombatTimeline.ts`에 `SURVIVOR_STAGE_PROFILES`를 추가했다. 각 스테이지는 아래 정보를 가진다.
|
||||
|
||||
- 스테이지 이름
|
||||
- 스테이지 길이
|
||||
- 기본 난이도 배율
|
||||
- 동시 적 수 기준
|
||||
- 스폰 템포
|
||||
- 오프닝 웨이브
|
||||
- 압박 엘리트 웨이브
|
||||
- 스웜 웨이브
|
||||
- 클라이맥스 엘리트 웨이브
|
||||
- 미니보스 체크포인트
|
||||
|
||||
### 스테이지별 구조
|
||||
|
||||
- Stage 1 `First Contact`: 첫 무기와 기본 생존 학습
|
||||
- Stage 2 `Fast Lanes`: 빠른 적과 이동 압박
|
||||
- Stage 3 `Ruined Circuit`: 혼합 편대와 엘리트 압박
|
||||
- Stage 4 `Crossfire Grid`: 길막/라인 클리어 압박
|
||||
- Stage 5 `Magma Forge`: 고밀도 스웜 시작
|
||||
- Stage 6 `Storm Foundry`: 빌드 완성 요구
|
||||
- Stage 7 `Arcane Collapse`: 진화 무기 권장
|
||||
- Stage 8 `Final Singularity`: 완성 빌드 검증
|
||||
|
||||
### 스테이지 시간 조정
|
||||
|
||||
기존 Standard 스테이지는 약 165초부터 시작해 빌드업 시간이 부족했다. 새 구조에서는 Stage 1이 240초, Stage 8이 420초까지 증가한다.
|
||||
|
||||
이렇게 하면 플레이어는 한 스테이지 안에서 다음 리듬을 경험할 수 있다.
|
||||
|
||||
- 0-25%: 세팅과 첫 성장
|
||||
- 25-48%: 엘리트 압박
|
||||
- 48-72%: 스웜 압박
|
||||
- 72%-보스 전: 클라이맥스와 미니보스
|
||||
- 마지막 35초 전후: 보스전 진입
|
||||
|
||||
### 스폰 밀도 조정
|
||||
|
||||
- 적 하드캡을 56에서 76으로 올렸다.
|
||||
- 스웜 배치 단위를 6에서 8로 올렸다.
|
||||
- 기본 절차 스폰 간격을 96프레임에서 84프레임으로 줄였다.
|
||||
|
||||
목표는 “가만히 있어도 클리어”가 아니라, 점점 밀려오는 압박을 움직임과 빌드 선택으로 해결하게 만드는 것이다.
|
||||
|
||||
### Tac EXP 커브 조정
|
||||
|
||||
바닥 EXP 젬을 다시 뿌리지는 않고, 처치 즉시 Tac EXP를 지급하는 현재 방향을 유지했다. 다만 뱀서류 성장 리듬을 만들기 위해 처치 경험치를 조정했다.
|
||||
|
||||
- 일반 적: `+2 TAC`
|
||||
- 엘리트 적: `+10 TAC`
|
||||
- 미드보스: `+30 TAC`
|
||||
|
||||
초기 요구 EXP는 `90`에서 `80`으로 낮췄다. 대신 레벨업 후 초과 EXP carryover는 25%만 유지해 연속 레벨업 폭주는 막는다.
|
||||
|
||||
레벨 요구량 배율은 아래처럼 조정했다.
|
||||
|
||||
- Level 1-4: `x1.34`
|
||||
- Level 5-8: `x1.42`
|
||||
- Level 9-14: `x1.52`
|
||||
- Level 15+: `x1.62`
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 “Vampire Survivors의 재미”를 다음 요소로 해석했다.
|
||||
|
||||
- 적은 점점 많아진다.
|
||||
- 플레이어는 더 자주 선택하고 강해진다.
|
||||
- 선택에는 빌드 방향성이 있다.
|
||||
- 중반 이후에는 광역, 관통, 방어, 기동 중 최소 하나가 부족하면 압박을 느낀다.
|
||||
- 보스는 단절된 엔딩이 아니라 빌드 검증 구간이다.
|
||||
- 다음 스테이지는 새 게임이 아니라 이전 빌드의 확장 시험이다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 각 스테이지별 고유 몬스터 역할 비중을 더 명확히 분리한다.
|
||||
- 스테이지별 보스 패턴을 현재보다 더 강하게 차별화한다.
|
||||
- 진화 무기별 화면 가독성과 성능을 플레이테스트로 검증한다.
|
||||
- 미니보스 처치 시 보물상자/카드 선택 보상을 확정 지급하는 구조를 추가하면 뱀서류 보상감이 더 강해진다.
|
||||
+123
@@ -0,0 +1,123 @@
|
||||
# Skybound Enemy Motion Damage Pressure and Projectile Visual Pass
|
||||
|
||||
작성일: 2026-04-26 12:46 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 1 적기의 이동이 어디에 낀 것처럼 바들바들 떨리는 문제를 개선한다.
|
||||
- 적 공격 데미지가 사용자 Tac Level에 정비례해서 오르는 느낌이 아니라, 소폭만 상승하도록 조정한다.
|
||||
- 사용자 기체의 일반 공격 탄환과 Gatling 탄환이 단순 렌더링 도형처럼 보여 아쉬운 문제를 개선한다.
|
||||
- 스킬과 탄환의 비주얼을 Skybound의 Stylized Casual Magitech 톤앤매너에 맞춰 더 상품성 있게 다듬는다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
### 적 이동 떨림
|
||||
|
||||
Stage 1에서 보이는 적기의 떨림은 주로 추적형 AI가 플레이어 근처에서 목표점을 매 프레임 다시 계산하면서 발생했다. 목표를 향해 직선 이동하다가 너무 가까워지면 다음 프레임에 방향이 반대로 튀고, 여기에 회전값도 즉시 플레이어를 향해 바뀌면서 시각적으로 “끼어서 떠는” 것처럼 보였다.
|
||||
|
||||
### 적 데미지 상승
|
||||
|
||||
적 데미지는 스테이지와 페이즈 압박에 따라 올라가야 하지만, 사용자 Tac Level과 동일한 폭으로 오르면 성장 보상이 무효화된다. 따라서 Tac Level은 적 데미지에 아주 작은 압박 보정만 주는 것이 맞다.
|
||||
|
||||
### 플레이어 탄환 비주얼
|
||||
|
||||
기본 공격과 Gatling 탄환은 기존 Canvas 사각형/막대 형태가 남아 있어, 현재 게임의 마법공학 기체와 스킬 아이콘 퀄리티에 비해 완성도가 낮게 보였다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 적 회전 안정화
|
||||
|
||||
적기의 회전을 즉시 목표 각도로 바꾸지 않고 `smoothEnemyRotation`을 통해 보간한다.
|
||||
|
||||
이제 적은 플레이어를 향해 부드럽게 회전하며, 근거리에서 회전값이 프레임마다 튀는 현상이 줄어든다.
|
||||
|
||||
### 추적형 적 이동 안정화
|
||||
|
||||
`chase` 패턴에 속도 보간과 근거리 감속을 추가했다.
|
||||
|
||||
- 목표점으로 바로 이동하지 않고 `vx`, `vy`를 보간한다.
|
||||
- 플레이어와 너무 가까워지면 속도를 줄인다.
|
||||
- 일정 거리 안으로 들어오면 살짝 밀려나며 겹침을 완화한다.
|
||||
|
||||
### 적끼리 겹침 완화
|
||||
|
||||
`applyEnemySeparation`을 추가했다. 적이 서로 너무 가까이 붙으면 약하게 밀어내어, 여러 적이 한 점에 몰려 떨리는 문제를 줄인다.
|
||||
|
||||
적 종류별 최소 거리도 다르게 적용한다.
|
||||
|
||||
- 일반 적: 작은 거리
|
||||
- 엘리트: 중간 거리
|
||||
- 미니보스: 더 큰 거리
|
||||
|
||||
### 적 데미지 보정 완만화
|
||||
|
||||
기존에는 페이즈 난이도 배율이 탄속/데미지에 직접적으로 강하게 반영될 수 있었다. 이제 아래처럼 완만하게 조정했다.
|
||||
|
||||
- 탄속은 페이즈 배율을 직접 곱하지 않고 작은 `phaseSpeedPressure`만 반영한다.
|
||||
- 데미지는 스테이지 커브를 기본으로 하되 `phaseDamagePressure`를 제한적으로 적용한다.
|
||||
- 사용자 Tac Level은 최대 `+18%`까지만 적 데미지에 반영한다.
|
||||
|
||||
의도는 다음과 같다.
|
||||
|
||||
- 플레이어가 성장해도 적이 완전히 무력해지지는 않는다.
|
||||
- 하지만 플레이어 레벨이 올랐다고 적 데미지가 같은 폭으로 따라오지는 않는다.
|
||||
- 성장 보상은 유지하고, 긴장감만 조금 보강한다.
|
||||
|
||||
### 플레이어 탄환 비주얼 개선
|
||||
|
||||
기본 탄환, Gatling 탄환, Rayce 탄환, 드론 탄환에 `visualKind`를 부여했다.
|
||||
|
||||
추가된 visualKind:
|
||||
|
||||
- `arc_bolt`
|
||||
- `gatling_round`
|
||||
- `rayce_lance`
|
||||
- `micro_missile`
|
||||
- `arc_vulcan`
|
||||
- `drone_shot`
|
||||
|
||||
### Magitech Projectile Renderer 추가
|
||||
|
||||
`GameRenderer`에 `renderMagitechProjectile`을 추가했다. 기존 사각형 탄환 대신 아래 요소를 가진 발사체로 렌더링된다.
|
||||
|
||||
- 밝은 코어
|
||||
- 마법공학 외곽 라인
|
||||
- 발사 방향 꼬리광
|
||||
- 글로우
|
||||
- 작은 룬/핀 라인
|
||||
- 기체/무기별 색상 차이
|
||||
|
||||
Gatling은 골드빛 짧은 고속탄, 기본 Falcon 탄은 시안 아크 볼트, Rayce는 마젠타 랜스형 탄환으로 보이게 했다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 조작감과 시각 품질을 동시에 개선하는 작업이다.
|
||||
|
||||
적 이동은 “불안정한 버그처럼 보이는 흔들림”이 아니라, 의도된 추적/회피 압박처럼 보여야 한다. 또한 적 데미지는 플레이어 성장과 같은 폭으로 따라오면 안 된다. 플레이어는 강해져야 하고, 적은 그 강함을 무효화하지 않는 선에서 압박을 유지해야 한다.
|
||||
|
||||
탄환 비주얼은 Skybound의 가장 자주 보는 이펙트이므로, 단순 도형이 남아 있으면 전체 완성도를 낮춘다. 이번 변경으로 기본 공격도 스킬과 같은 톤의 Magitech 무장처럼 보이게 했다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/PlayerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/WeaponBehaviorEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/23`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 일반 적이 플레이어 근처에서 바들바들 떨지 않는지 확인한다.
|
||||
- 적이 겹칠 때 자연스럽게 분산되는지 확인한다.
|
||||
- Tac Level이 올라가도 적 데미지가 과하게 따라오지 않는지 확인한다.
|
||||
- Falcon 기본탄과 Gatling 탄환이 사각형 도형이 아니라 마법공학 발사체처럼 보이는지 확인한다.
|
||||
- Rayce 탄환이 Falcon과 충분히 구분되는지 확인한다.
|
||||
- 이후 스킬별 전용 Canvas/PNG 이펙트를 더 세분화할지 결정한다.
|
||||
+172
@@ -0,0 +1,172 @@
|
||||
# Skybound HP Scarcity and Module Cache Rewards
|
||||
|
||||
작성일: 2026-04-26 13:01 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 1 플레이 중 하트 HP 회복 아이템이 너무 자주 드롭되어 위기감이 사라지는 문제를 개선한다.
|
||||
- 초반에는 어느 정도 회복을 주되, 항상 충분하게 주기보다 “조금 아쉬운” 수준으로 조정한다.
|
||||
- 전투 중 모듈이 자동 지급되어 획득 재미가 떨어지는 문제를 개선한다.
|
||||
- 보물 상자 혹은 모듈 상자 이미지를 만들고, 사용자 인벤토리에 stacking되게 한다.
|
||||
- 상자를 열었을 때 모듈 획득 이펙트와 연출을 추가한다.
|
||||
- 일반 등급은 기본 연출, 상급 이상은 개봉 중 기대감을 줄 수 있는 힌트 연출을 제공한다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
기존 보상 구조는 적 처치 시 장비가 곧바로 `inventory`에 추가되는 방식이었다.
|
||||
|
||||
이 구조는 기능적으로는 빠르지만, 사용자가 다음 감각을 느끼기 어렵다.
|
||||
|
||||
1. 내가 무언가를 얻었다는 소유감
|
||||
2. 전투 후 보상을 확인하는 기대감
|
||||
3. 상자를 열 때 “이번에는 뭐가 나올까” 하는 가챠/루팅 재미
|
||||
4. 등급별 보상의 차이
|
||||
|
||||
또한 하트 드롭은 대량의 적 처치 수와 결합되면서 체력 결핍이 거의 발생하지 않는 상태를 만들었다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### HP 회복 아이템 희소화
|
||||
|
||||
기존에는 적 처치 시 25% 확률로 필드 아이템이 나오고, 그중 일부가 HP 회복 아이템이었다.
|
||||
|
||||
변경 후에는 체력 상태와 쿨다운을 기반으로 HP 드롭을 계산한다.
|
||||
|
||||
- HP가 82% 이상이면 하트 드롭이 거의 발생하지 않는다.
|
||||
- HP가 60% 미만일 때부터 하트 확률이 의미 있게 상승한다.
|
||||
- HP가 35% 미만이면 긴급 회복 가능성을 열어둔다.
|
||||
- 하트 드롭 후에는 기본 900프레임 쿨다운을 둔다.
|
||||
- 위기 상황에서는 쿨다운을 480프레임으로 낮춰 완전한 운빨 사망은 줄인다.
|
||||
- 엘리트와 미니보스는 회복/보상 드롭 가능성이 조금 더 높다.
|
||||
|
||||
### 회복량 조정
|
||||
|
||||
하트 하나가 체력을 너무 크게 회복하지 않도록 회복량을 낮췄다.
|
||||
|
||||
변경 전:
|
||||
|
||||
- 필드 하트: 최대 HP의 20%
|
||||
- 회복 에어드롭: 최대 HP의 40%
|
||||
|
||||
변경 후:
|
||||
|
||||
- 필드 하트: 최대 HP의 14%
|
||||
- 회복 에어드롭: 최대 HP의 32%
|
||||
|
||||
목표는 “살았다”는 안도감은 주되, 바로 100% 안정권으로 돌아가지 않게 만드는 것이다.
|
||||
|
||||
### 자동 모듈 지급 제거
|
||||
|
||||
일반 적 처치 시 장비가 직접 지급되는 흐름을 제거했다.
|
||||
|
||||
변경 후:
|
||||
|
||||
- 일반 적은 장비/모듈 캐시를 지급하지 않는다.
|
||||
- 엘리트, 미니보스, 보스 보상은 즉시 장비 지급이 아니라 `Module Cache`로 전환된다.
|
||||
- 캐시는 격납고 인벤토리에 stacking된다.
|
||||
- 실제 장비는 사용자가 캐시를 열 때 생성된다.
|
||||
|
||||
이제 전투 중에는 “보상 상자를 회수했다”는 흐름이 되고, 장비 획득은 격납고에서 별도 개봉 경험으로 분리된다.
|
||||
|
||||
### Module Cache 인벤토리 추가
|
||||
|
||||
`useGameStore`에 `moduleCaches` 상태와 액션을 추가했다.
|
||||
|
||||
추가된 액션:
|
||||
|
||||
- `addModuleCache(cache)`
|
||||
- `openModuleCache(cacheId)`
|
||||
|
||||
`openModuleCache`는 캐시의 등급과 클래스 정보를 기반으로 장비를 생성하고, 해당 장비를 `inventory`에 `isNew` 상태로 추가한다.
|
||||
|
||||
### Module Cache 이미지 추가
|
||||
|
||||
톤앤매너에 맞춘 Stylized Casual Magitech 상자 SVG를 추가했다.
|
||||
|
||||
특징:
|
||||
|
||||
- 굵은 외곽선
|
||||
- 시안/라임 마력 코어
|
||||
- 블루 메탈 케이스
|
||||
- 골드 띠 장식
|
||||
- 상자 개봉 UI에서 재사용 가능한 벡터 에셋
|
||||
|
||||
추가 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/module_cache.svg`
|
||||
|
||||
### 격납고 Module Cache UI 추가
|
||||
|
||||
`HangarOverlay`의 Loadout 탭에 `Module Caches` 섹션을 추가했다.
|
||||
|
||||
UI 동작:
|
||||
|
||||
- 같은 등급/클래스/출처의 캐시는 하나의 카드로 stacking 표시된다.
|
||||
- 카드에는 `xN` 카운트가 표시된다.
|
||||
- Elite Cache, Command Cache, Boss Cache 출처가 표시된다.
|
||||
- 클릭하면 해당 캐시 1개를 개봉한다.
|
||||
|
||||
### 등급별 개봉 연출 추가
|
||||
|
||||
캐시 개봉 시 별도 오버레이가 뜨도록 했다.
|
||||
|
||||
연출 구성:
|
||||
|
||||
- 어두운 배경 블러
|
||||
- 캐시 중심 이미지
|
||||
- 등급 색상 기반 발광
|
||||
- 회전하는 아케인 링
|
||||
- 작은 마력 스파크
|
||||
- 개봉 중 힌트 텍스트
|
||||
- 최종 모듈 이름/타입/스탯 공개
|
||||
|
||||
일반 등급은 짧은 기본 개봉으로 처리하고, GOOD 이상은 개봉 중 다음 힌트를 보여준다.
|
||||
|
||||
- 모듈 타입 신호
|
||||
- 보상 출처
|
||||
- 등급 신호 안정화 문구
|
||||
|
||||
이를 통해 상급 이상 상자는 결과 공개 전 기대감을 주는 구조로 만들었다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 패스의 목표는 Stage 1의 생존 긴장감과 보상 기대감을 동시에 살리는 것이다.
|
||||
|
||||
하트는 플레이어를 완전히 방치하지 않되, 항상 충분하게 주지 않는다.
|
||||
|
||||
모듈은 자동 지급에서 상자 개봉으로 바꿔 다음 루프를 만든다.
|
||||
|
||||
1. 전투에서 엘리트/보스 처치
|
||||
2. 모듈 캐시 획득
|
||||
3. 격납고로 복귀
|
||||
4. 캐시 stack 확인
|
||||
5. 캐시 개봉
|
||||
6. 모듈 획득
|
||||
7. 장착/합성/분해 선택
|
||||
|
||||
이 구조는 Vampire Survivors류의 런 성장과 Survivor.io류의 메타 보상 사이를 이어주는 역할을 한다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/public/sprites/module_cache.svg`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/StageDirectorSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/HangarOverlay.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/24`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 초반 하트가 너무 부족해서 불합리하게 느껴지지 않는지 확인한다.
|
||||
- Stage 1 중반 이후 체력이 즉시 100%로 복구되는 빈도가 줄었는지 확인한다.
|
||||
- 엘리트/보스 처치 후 캐시 획득 문구가 보상처럼 느껴지는지 확인한다.
|
||||
- 격납고에서 캐시 stack UI가 충분히 명확한지 확인한다.
|
||||
- GOOD 이상 캐시 개봉 시 “뭐가 나올까” 하는 기대감이 생기는지 확인한다.
|
||||
- 캐시 개봉 후 모듈이 `Module Storage`에 자연스럽게 추가되는지 확인한다.
|
||||
+133
@@ -0,0 +1,133 @@
|
||||
# Skybound Invasion Response Stage Difficulty Curve
|
||||
|
||||
작성일: 2026-04-26 13:08 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 8 보스가 지구를 침략한 핵심 적이라는 스토리 구조를 난이도 곡선에 반영한다.
|
||||
- 초반에는 플레이어를 얕보고 소수의 적기만 보내는 느낌으로 시작한다.
|
||||
- 스테이지를 클리어할수록 보스가 플레이어를 점점 더 위험하게 판단하고, 단계적으로 더 많은 적기를 투입한다.
|
||||
- 적기의 수가 줄어든 구간은 너무 쉬워질 수 있으므로 적기의 공격력을 비례해서 보정한다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
이번 패스는 단순히 숫자를 올리는 밸런스가 아니라 “침공군의 대응 수위”를 만드는 작업이다.
|
||||
|
||||
설계 기준은 다음과 같다.
|
||||
|
||||
1. Stage 1: 정찰대. 적 수는 적지만 한 발은 무시할 수 없다.
|
||||
2. Stage 2: 빠른 대응기 투입. 아직 소규모지만 반응 속도가 오른다.
|
||||
3. Stage 3: 혼합 편대. 보스가 플레이어를 실제 변수로 인식한다.
|
||||
4. Stage 4: 제압 작전. 십자/라인 압박이 본격화된다.
|
||||
5. Stage 5: 전면 공격 승인. 적 수가 확실히 늘어난다.
|
||||
6. Stage 6: 제거 함대. 빌드 완성도를 검증한다.
|
||||
7. Stage 7: 예비 전력 투입. 물량과 엘리트 압박이 커진다.
|
||||
8. Stage 8: 지구 침공 본대. 최대 물량과 최대 화력으로 압박한다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Stage Profile 재정렬
|
||||
|
||||
`SURVIVOR_STAGE_PROFILES`를 8단계 침공 대응 곡선으로 재배치했다.
|
||||
|
||||
변경된 주요 축:
|
||||
|
||||
- `diffBase`
|
||||
- `capBase`
|
||||
- `spawnTempo`
|
||||
- opening wave density
|
||||
- swarm density
|
||||
- climax elite density
|
||||
- comms 문구
|
||||
|
||||
### 초반 적 수 감소
|
||||
|
||||
Stage 1과 Stage 2는 보스가 플레이어를 얕보는 단계로 설정했다.
|
||||
|
||||
Stage 1 변경:
|
||||
|
||||
- `capBase: 18` → `12`
|
||||
- `spawnTempo: 1.0` → `1.18`
|
||||
- opening density: `8` → `4`
|
||||
- swarm density: `18` → `12`
|
||||
- climax elite density: `3` → `2`
|
||||
|
||||
Stage 2 변경:
|
||||
|
||||
- `capBase: 28` → `16`
|
||||
- `spawnTempo: 0.86` → `1.02`
|
||||
- opening density: `14` → `7`
|
||||
- swarm density: `24` → `16`
|
||||
- climax elite density: `4` → `3`
|
||||
|
||||
초반에는 화면을 적으로 가득 채우기보다, 각 적기의 진입과 탄환을 플레이어가 인식할 수 있게 만들었다.
|
||||
|
||||
### 중후반 적 수 증가 곡선 강화
|
||||
|
||||
Stage 5부터는 침공군이 실제로 플레이어 제거를 목표로 움직이는 느낌을 강화했다.
|
||||
|
||||
후반 주요 변화:
|
||||
|
||||
- Stage 5 `capBase: 40` → `34`, 대신 `diffBase: 1.42` → `1.54`
|
||||
- Stage 6 `capBase: 46` → `42`, `diffBase: 1.58` → `1.74`
|
||||
- Stage 7 `capBase: 52` → `50`, `diffBase: 1.76` → `1.96`
|
||||
- Stage 8 `capBase: 58` → `60`, `diffBase: 1.96` → `2.22`
|
||||
- Stage 8 swarm density: `60` → `68`
|
||||
- Stage 8 climax elite density: `10` → `12`
|
||||
|
||||
Stage 5-7은 성능과 가독성을 고려해 단순 물량만 폭증시키지 않고, 공격 위협을 함께 올렸다.
|
||||
|
||||
### 공격력 보정
|
||||
|
||||
적 수가 줄어든 스테이지가 너무 쉬워지는 것을 방지하기 위해 `DAMAGE_CURVE`를 상향했다.
|
||||
|
||||
변경 전:
|
||||
|
||||
- `[0.95, 1.08, 1.24, 1.44, 1.68, 1.96, 2.28, 2.65]`
|
||||
|
||||
변경 후:
|
||||
|
||||
- `[1.08, 1.16, 1.32, 1.52, 1.78, 2.08, 2.44, 2.88]`
|
||||
|
||||
의도는 “적 수가 적으면 회피 기회가 많아지는 만큼, 맞았을 때는 실수로 느껴지게 하는 것”이다.
|
||||
|
||||
### Comms 서사 반영
|
||||
|
||||
스테이지 시작/주요 웨이브 문구를 침공 대응 서사에 맞게 수정했다.
|
||||
|
||||
예시:
|
||||
|
||||
- Stage 1: `Scout flight detected. The invader is probing our response.`
|
||||
- Stage 2: `Stage 2: the invader is testing faster response craft.`
|
||||
- Stage 4: `Stage 4: the invader is no longer probing. Suppression grid active.`
|
||||
- Stage 8: `Stage 8: planetary invasion force confirmed. Survive the crush.`
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경의 핵심은 플레이어가 난이도 상승을 “게임이 갑자기 어려워졌다”가 아니라 “보스가 나를 점점 더 심각한 위협으로 보고 있다”라고 받아들이게 만드는 것이다.
|
||||
|
||||
초반은 적 수가 줄어들었기 때문에 회피와 학습의 여유가 있다.
|
||||
|
||||
하지만 공격력은 낮추지 않고 오히려 보정했기 때문에, 가만히 있어도 쉽게 깨지는 구조는 피한다.
|
||||
|
||||
후반은 플레이어 빌드가 강해지는 것을 전제로, 적 수와 공격력이 함께 올라간다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/25`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 초반이 “적이 적어서 심심한지” 또는 “소수지만 긴장감이 있는지” 확인한다.
|
||||
- Stage 1에서 맞았을 때 피격이 의미 있게 느껴지는지 확인한다.
|
||||
- Stage 2가 Stage 1보다 확실히 대응 수위가 올라간 것처럼 느껴지는지 확인한다.
|
||||
- Stage 3-4에서 혼합 편대/제압 작전으로 플레이 양상이 달라지는지 확인한다.
|
||||
- Stage 5 이후부터 물량 증가가 명확하게 느껴지는지 확인한다.
|
||||
- Stage 8이 최종 침공군답게 가장 강한 물량과 화력을 보여주는지 확인한다.
|
||||
+111
@@ -0,0 +1,111 @@
|
||||
# Skybound Low Level First Upgrade Offer Balance
|
||||
|
||||
작성일: 2026-04-26 13:16 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 게임 플레이 중 Tactical Level Up으로 무기/스킬 업그레이드 후보가 나온다.
|
||||
- 이미 많이 레벨업한 무기가 계속 후보에 자주 나오면 특정 무기 몰빵이 쉬워진다.
|
||||
- 레벨이 낮은 무기/스킬이 다음 후보에 포함될 확률을 더 높인다.
|
||||
- 레벨이 높은 무기/스킬은 낮은 레벨 스킬 대비 후보 포함 확률을 낮춘다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
기존 `ProgressionSystem.generateSkillCards()`는 이미 보유한 스킬과 near-max 스킬에 보너스를 주는 구조였다.
|
||||
|
||||
기존 구조의 문제:
|
||||
|
||||
1. 한 무기가 빠르게 고레벨까지 몰릴 수 있다.
|
||||
2. Lv4 → Lv5 직전 스킬이 자주 후보에 떠서 성장 속도가 급격해진다.
|
||||
3. 다양한 무기를 경험하기보다 가장 강한 무기 하나가 빠르게 완성된다.
|
||||
4. Stage 1-2 중반부터 빌드가 너무 빨리 안정화될 수 있다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 후보 선택 방식 변경
|
||||
|
||||
기존에는 카테고리별로 후보를 고르고, 보유/시너지/near-max에 가중치를 더했다.
|
||||
|
||||
변경 후에는 각 스킬마다 `offer weight`를 계산한다.
|
||||
|
||||
가중치 기준:
|
||||
|
||||
- 남은 레벨이 많을수록 가중치 증가
|
||||
- Lv0/Lv1 스킬은 상대적으로 더 자주 등장
|
||||
- Lv3 이상 스킬은 가중치 감소
|
||||
- max 직전 스킬은 강하게 가중치 감소
|
||||
- 시너지/EVO 보너스는 유지하되, 고레벨 스킬을 압도적으로 밀어주지는 않음
|
||||
|
||||
### 고레벨 몰빵 완화
|
||||
|
||||
Near-max 스킬은 기존에 오히려 보너스를 받았지만, 이제는 낮은 확률로만 나온다.
|
||||
|
||||
적용 규칙:
|
||||
|
||||
- `currentLevel >= maxLevel - 1`: 가중치 35%로 감소
|
||||
- `currentLevel >= maxLevel * 0.6`: 가중치 58%로 감소
|
||||
|
||||
예시:
|
||||
|
||||
- Lv0/Lv1 스킬: 목록에 더 잘 등장
|
||||
- Lv3/Lv4 스킬: 등장 가능하지만 낮은 빈도
|
||||
- Lv4 → Lv5 완성: 운이 좋아야 뜨는 마무리 선택으로 변경
|
||||
|
||||
### 첫 선택 보정
|
||||
|
||||
아직 아무 스킬도 없는 첫 Tactical Level Up에서는 새 무기 후보를 우선 제공한다.
|
||||
|
||||
목표는 첫 선택이 빌드 방향을 정하는 순간으로 작동하게 하는 것이다.
|
||||
|
||||
### 새 무기 확장 선택 유지
|
||||
|
||||
이미 스킬을 보유한 이후에도 새 무기 후보가 완전히 사라지지는 않는다.
|
||||
|
||||
변경 후:
|
||||
|
||||
- 슬롯 여유가 있고 새 무기가 있으면 65% 확률로 하나의 build-expanding option을 제공한다.
|
||||
- 나머지 후보는 전체 가중치 풀에서 선택한다.
|
||||
|
||||
### Mini-boss Reward Cache 보정
|
||||
|
||||
미니보스 보상 카드도 가장 높은 레벨 무기를 무조건 우선하지 않도록 변경했다.
|
||||
|
||||
변경 후에는 보유 무기 중에서도 낮은 레벨/남은 성장 여지가 큰 무기가 더 잘 선택된다.
|
||||
|
||||
### UI fallback 보정
|
||||
|
||||
일반적으로 카드 후보는 엔진에서 생성되지만, 예외적으로 `LevelUpModal`에서 fallback 랜덤이 동작할 수 있다.
|
||||
|
||||
이 fallback도 동일한 low-level-first 가중치 규칙을 따르도록 변경했다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경의 목표는 성장 속도를 늦추는 것만이 아니다.
|
||||
|
||||
플레이어가 한 무기를 빠르게 완성해 “이미 빌드가 끝났다”라고 느끼는 시점을 뒤로 미루고, 여러 선택지 사이에서 더 오래 고민하게 만드는 것이 핵심이다.
|
||||
|
||||
원하는 플레이 감각:
|
||||
|
||||
1. 초반에는 새 무기와 낮은 레벨 무기가 자주 보인다.
|
||||
2. 중반에는 빌드 방향을 넓히거나 약한 축을 보완하게 된다.
|
||||
3. 고레벨 완성 선택은 자주 뜨지 않지만, 떴을 때 반갑다.
|
||||
4. 특정 무기 하나가 너무 빨리 완성되어 난이도를 붕괴시키는 일이 줄어든다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/26`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1에서 같은 무기가 너무 빠르게 Lv4/Lv5까지 올라가지 않는지 확인한다.
|
||||
- 낮은 레벨 무기/패시브가 기존보다 자주 후보에 뜨는지 확인한다.
|
||||
- 고레벨 완성 선택이 너무 안 떠서 답답하지 않은지 확인한다.
|
||||
- EVO 경로가 완전히 막힌 느낌이 들지 않는지 확인한다.
|
||||
- 미니보스 보상 카드가 여전히 보상답게 느껴지는지 확인한다.
|
||||
+109
@@ -0,0 +1,109 @@
|
||||
# Skybound Miniboss Treasure Cache Reward Loop
|
||||
|
||||
작성일: 2026-04-26 09:32 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 뱀파이어 서바이벌 계열의 재미를 더 강하게 만들기 위한 다음 단계로, 미니보스 처치 보상 루프를 추가한다.
|
||||
- 단순 EXP 성장만 반복되는 구조가 아니라, 중간 강적을 잡았을 때 빌드 방향을 강화하는 확정 보상을 제공한다.
|
||||
- 보상은 기존 Tac Level Up 화면을 재사용하되, 보물상자 성격의 `Emergency Supply` 카드 선택으로 연결한다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
Skybound의 현재 전투 루프는 적을 처치하면 Tac EXP를 바로 얻고, 일정 EXP에 도달하면 업그레이드를 선택하는 구조다. 이 방식은 화면 가독성에는 좋지만, 플레이 중간에 “강적을 잡아서 특별한 보상을 얻었다”는 뱀서류 특유의 보상감이 부족했다.
|
||||
|
||||
이번 변경의 목표는 미니보스를 다음 역할로 재정의하는 것이다.
|
||||
|
||||
1. 전투 흐름 중간의 압박 체크포인트
|
||||
2. 플레이어 빌드가 충분히 강한지 확인하는 작은 검증 구간
|
||||
3. 처치하면 현재 빌드를 더 선명하게 만드는 확정 업그레이드 보상
|
||||
4. 보스 전 진화/EVO 경로를 완성할 기회를 주는 중간 보물상자
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 미니보스 식별 플래그 추가
|
||||
|
||||
기존 `MINI_BOSS` 스폰은 내부적으로 `ELITE` 적을 생성했기 때문에, 처치 시 일반 엘리트와 구분되는 보상 처리가 어려웠다. `SystemEnemy`에 아래 플래그를 추가했다.
|
||||
|
||||
- `isMiniBoss`
|
||||
- `rewardClaimed`
|
||||
|
||||
`SpawnerSystem`의 `MINI_BOSS` 스폰에서는 이제 `isMiniBoss: true`를 부여한다.
|
||||
|
||||
### 미니보스 HP 스케일링
|
||||
|
||||
미니보스가 후반 스테이지에서도 너무 빨리 녹지 않도록 스테이지와 난이도 배율을 반영했다.
|
||||
|
||||
- 기본 HP: `620`
|
||||
- 스테이지당 증가: `+22%`
|
||||
- 현재 `difficultyMult` 반영
|
||||
|
||||
의도는 미니보스가 보스만큼 길지는 않지만, 플레이어가 위치와 공격 방향을 신경 써야 하는 짧은 전투 목표가 되게 하는 것이다.
|
||||
|
||||
### 처치 보상 인텐트 추가
|
||||
|
||||
`EngineProtocol`에 `MINIBOSS_REWARD` 인텐트를 추가했다. `CombatSystem`은 미니보스 처치 시 직접 UI를 열지 않고, 엔진 인텐트를 통해 보상 처리를 요청한다.
|
||||
|
||||
이렇게 한 이유는 다음과 같다.
|
||||
|
||||
- 전투 시스템이 UI 상태를 직접 제어하지 않게 한다.
|
||||
- 기존 `LEVEL_UP` 이벤트와 `LevelUpModal` 흐름을 재사용한다.
|
||||
- 추후 보물상자 연출, 룰렛, 보상 티어를 추가하기 쉽다.
|
||||
|
||||
### 빌드 우선 보상 카드 생성
|
||||
|
||||
`ProgressionSystem`에 `generateMiniBossRewardCards`를 추가했다. 이 보상은 일반 레벨업 카드보다 더 전략적으로 구성된다.
|
||||
|
||||
우선순위는 다음과 같다.
|
||||
|
||||
1. 이미 보유한 무기/스킬의 레벨업
|
||||
2. Lv.3 이상 무기의 EVO에 필요한 서포트 패시브
|
||||
3. 스웜/압박 구간 대응용 `isSpikeCounter` 스킬
|
||||
4. 부족한 자리는 기존 3카드 생성 규칙으로 보충
|
||||
|
||||
이 구조는 플레이어가 아무 카드나 고르는 것이 아니라, “내 빌드를 완성해가는 선택”을 하도록 유도한다.
|
||||
|
||||
### 보상 UI 연결
|
||||
|
||||
미니보스 처치 시 아래 흐름으로 동작한다.
|
||||
|
||||
1. 미니보스 사망
|
||||
2. `CombatSystem`이 `MINIBOSS_REWARD` 인텐트 발행
|
||||
3. `useGameEngine`이 현재 스킬 상태를 기반으로 보상 카드 생성
|
||||
4. 게임 일시정지
|
||||
5. `LEVEL_UP` 이벤트를 `isChest: true`로 발행
|
||||
6. 기존 `Emergency Supply` 카드 선택 UI 표시
|
||||
7. `COMMAND CACHE UNLOCKED` 피드백 텍스트 출력
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이 변경은 Skybound의 목적성을 더 명확하게 만들기 위한 작업이다.
|
||||
|
||||
- 일반 적 처치: Tac EXP를 쌓는 기본 성장
|
||||
- 엘리트 처치: 더 많은 EXP와 재료/장비 가능성
|
||||
- 미니보스 처치: 확정 빌드 강화 선택
|
||||
- 스테이지 보스 처치: 다음 스테이지 진행과 영구 보상
|
||||
|
||||
즉, 전투 중 목표가 “그냥 버티기”에서 “위험한 타이밍을 넘기고 빌드를 완성하기”로 바뀐다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/EngineProtocol.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 미니보스 처치 순간에 실제 상자/코어가 열리는 0.6초 전용 연출을 추가한다.
|
||||
- 보상 카드에 `EVO READY`, `BUILD CORE`, `SURVIVAL PICK` 같은 태그를 붙여 선택 이유를 더 명확하게 보여준다.
|
||||
- 스테이지별 미니보스 외형과 탄막 패턴을 분리해 “이번 스테이지의 중간 위협” 정체성을 강화한다.
|
||||
- 보물상자 보상을 1장 선택에서 3장 순차 오픈 또는 희귀도 보상으로 확장할지 플레이테스트 후 결정한다.
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
# Skybound Player Sprite Path Warning Fix
|
||||
|
||||
작성일: 2026-04-26 12:11 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- `npm run build` 시 반복되던 `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time` 경고를 해결한다.
|
||||
- 필요하다면 Skybound의 Stylized Casual Magitech 톤앤매너에 맞는 플레이어 기체 이미지를 새로 준비한다.
|
||||
|
||||
## 원인
|
||||
|
||||
경고의 원인은 실제 플레이 중 사용되는 Canvas 렌더링이 아니라, 선택 화면 CSS에서 존재하지 않는 `/sprites/player.png`를 참조하고 있었기 때문이다.
|
||||
|
||||
문제 위치는 `src/App.css`의 아래 클래스였다.
|
||||
|
||||
- `.plane-preview.falcon`
|
||||
- `.plane-preview.rayce`
|
||||
|
||||
현재 프로젝트에는 `/sprites/player.png`가 없고, 실제 준비된 기체 에셋은 아래 파일이다.
|
||||
|
||||
- `/sprites/Falcon.png`
|
||||
- `/sprites/rayce.png`
|
||||
|
||||
따라서 새 이미지를 생성하기보다, 이미 톤앤매너에 맞춰 준비된 실제 기체 에셋으로 경로를 정리하는 것이 적절했다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Falcon 미리보기 경로 수정
|
||||
|
||||
`/sprites/player.png`를 `/sprites/Falcon.png`로 교체했다.
|
||||
|
||||
### Rayce 미리보기 경로 수정
|
||||
|
||||
Rayce도 같은 `player.png`에 `hue-rotate`를 걸어 임시로 표현하고 있었기 때문에, 실제 `/sprites/rayce.png`를 직접 사용하도록 바꿨다.
|
||||
|
||||
또한 임시 색상 변환 필터를 제거했다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
선택 화면은 사용자가 처음 기체의 정체성을 보는 곳이기 때문에, 존재하지 않는 공용 `player.png`나 임시 색상 변환보다 실제 기체별 에셋을 보여주는 편이 상품성 측면에서 낫다.
|
||||
|
||||
이번 수정으로 다음 효과가 있다.
|
||||
|
||||
- Vite 빌드 경고 제거
|
||||
- Falcon/Rayce 선택 화면 미리보기 정확도 개선
|
||||
- 임시 에셋 참조 제거
|
||||
- 기존 Stylized Casual Magitech 기체 에셋 재사용
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/App.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- 기존 `/sprites/player.png` Vite 경고 사라짐
|
||||
- 출력 디렉터리: `dist/21`
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 선택 화면의 기체 미리보기를 정적 배경 이미지가 아니라, Canvas 렌더러와 동일한 축소 프리뷰 컴포넌트로 통일한다.
|
||||
- Falcon/Rayce의 실제 플레이 성능 차이가 UI 문구와 정확히 대응되는지 점검한다.
|
||||
- 선택 화면도 현재 게임 HUD/UI 톤과 완전히 맞도록 한 번 더 정리한다.
|
||||
+104
@@ -0,0 +1,104 @@
|
||||
# Skybound Reward Card Clarity and Command Cache UI
|
||||
|
||||
작성일: 2026-04-26 09:40 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 미니보스 보상 루프 다음 단계로, 보상 카드가 왜 좋은 선택인지 사용자가 즉시 이해할 수 있게 개선한다.
|
||||
- 미니보스 처치 보상과 위기 보급 보상을 같은 화면처럼 보이지 않게 구분한다.
|
||||
- Stylized Casual Magitech 톤앤매너 안에서 보상감 있는 카드 선택 UI를 강화한다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
이전 단계에서 미니보스 처치 시 확정 업그레이드 선택 보상이 추가되었다. 하지만 카드 3장이 뜨는 것만으로는 사용자가 “왜 이 보상이 지금 내 빌드에 좋은지” 바로 이해하기 어렵다.
|
||||
|
||||
이번 변경의 목표는 보상 화면을 단순 선택지가 아니라, 플레이어에게 다음 메시지를 전달하는 UI로 만드는 것이다.
|
||||
|
||||
1. 이 카드는 현재 주력 빌드를 강화한다.
|
||||
2. 이 카드는 EVO 진화 경로에 필요하다.
|
||||
3. 이 카드는 스웜/압박 상황에서 생존에 도움이 된다.
|
||||
4. 이 카드는 새로운 공격 패턴을 열어준다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 보상 출처 타입 추가
|
||||
|
||||
`LEVEL_UP` 이벤트에 `rewardSource`를 추가했다.
|
||||
|
||||
- `STARTER`
|
||||
- `LEVEL_UP`
|
||||
- `POWER_SPIKE`
|
||||
- `MINIBOSS`
|
||||
|
||||
기존에는 `isChest`만 있어서 미니보스 보상과 위기 보급 보상이 모두 같은 `Emergency Supply`처럼 보였다. 이제 보상 출처에 따라 헤더, 문구, 카드 태그를 다르게 표시할 수 있다.
|
||||
|
||||
### 미니보스 보상 헤더 차별화
|
||||
|
||||
미니보스 보상은 이제 `Emergency Supply`가 아니라 `Command Cache`로 표시된다.
|
||||
|
||||
- Badge: `Cache`
|
||||
- Title: `Command Cache`
|
||||
- Subtitle: `Choose one build-defining reward`
|
||||
|
||||
위기 보급은 기존 의도대로 `Emergency Supply`를 유지한다.
|
||||
|
||||
### 카드 선택 이유 태그 추가
|
||||
|
||||
각 카드 상단에 보상 이유 태그를 추가했다.
|
||||
|
||||
- `FIRST CORE`: 첫 무기 선택, 런의 시작 방향 결정
|
||||
- `CORE UPGRADE`: 현재 주력 무기 강화
|
||||
- `MODULE BOOST`: 보유 패시브/모듈 강화
|
||||
- `EVO LINK`: 현재 무기의 진화 조건을 지원
|
||||
- `EVO READY`: 진화 조건 완성
|
||||
- `SURVIVAL PICK`: 스웜/압박 구간 대응
|
||||
- `NEW WEAPON`: 새로운 공격 패턴 개방
|
||||
- `UTILITY MOD`: 기본 성능 강화
|
||||
|
||||
이 태그는 단순 라벨이 아니라, 카드가 “왜 지금 의미 있는 선택인지”를 설명하는 짧은 문장과 함께 표시된다.
|
||||
|
||||
### Command Cache 연출 추가
|
||||
|
||||
보상 화면 상단에 작은 마법공학 캐시 코어를 추가했다.
|
||||
|
||||
- 팝 인 애니메이션
|
||||
- 회전하는 점선 링
|
||||
- 미니보스 캐시는 청록/라임 계열 빛
|
||||
- 일반 보급은 오렌지/시안 계열 빛
|
||||
|
||||
실제 게임 시간을 더 지연시키지는 않지만, 화면이 뜨는 순간 보상 상자가 열린다는 감각을 강화한다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
뱀파이어 서바이벌 계열의 재미는 단순히 레벨업을 많이 하는 것이 아니라, “내가 고른 선택 때문에 빌드가 강해지고 있다”는 확신에서 나온다.
|
||||
|
||||
이번 변경은 그 확신을 UI로 보강한다.
|
||||
|
||||
- 미니보스 처치: `Command Cache`
|
||||
- 위기 보급: `Emergency Supply`
|
||||
- 일반 레벨업: `Tactical Upgrade`
|
||||
- 시작 선택: `Choose First Weapon`
|
||||
|
||||
이제 각 성장 이벤트는 같은 카드 선택이라도 서로 다른 의미를 가진다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/hooks/useGameEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/GameSceneRenderer.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 스테이지별 미니보스 패턴을 분리해 `Command Cache`를 얻는 과정 자체를 더 재미있게 만든다.
|
||||
- 보상 카드에 실제 EVO 결과 미리보기 아이콘을 추가한다.
|
||||
- 보물상자 보상을 1장 선택에서 희귀도 기반 다중 보상으로 확장할지 플레이테스트한다.
|
||||
- Command Cache가 열리는 짧은 0.5초 전용 컷인/상자 오픈 애니메이션을 Canvas 위에 추가한다.
|
||||
+136
@@ -0,0 +1,136 @@
|
||||
# Skybound Skill Slot Limit Weapon 5 Passive 5
|
||||
|
||||
작성일: 2026-04-26 13:29 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 사용자가 획득할 수 있는 스킬 수량에 제한을 둔다.
|
||||
- 총 10개 스킬을 보유할 수 있게 한다.
|
||||
- 10개 중 5개는 무기, 5개는 패시브로 분리한다.
|
||||
- 슬롯이 부족한 상태에서 새 스킬을 선택하려 하면 `슬롯이 부족합니다`에 해당하는 노티가 필요하다.
|
||||
- 슬롯 제한 때문에 사용하지 못하는 스킬이 목록에 나올 수 있으므로 `Skip Upgrade` 선택지도 계속 필요하다.
|
||||
- 5/5 구조가 적절한지 검토한다.
|
||||
|
||||
## 판단
|
||||
|
||||
현재 Skybound에는 무기와 패시브 풀이 이미 넓고, 8스테이지까지 성장해야 한다.
|
||||
|
||||
따라서 지금 시점에서는 `무기 5개 + 패시브 5개`가 적절하다.
|
||||
|
||||
더 줄이는 선택지도 가능하지만, 아직은 권장하지 않는다.
|
||||
|
||||
- 4/4는 빌드 정체성이 더 강해지는 대신 초반 선택 운 영향이 커진다.
|
||||
- 5/5는 Survivor.io/Vampire Survivors류의 성장 폭과 전략성을 적당히 유지한다.
|
||||
- 6/6 이상은 사용자가 거의 모든 것을 들고 가는 느낌이 강해져 빌드 선택 의미가 약해진다.
|
||||
|
||||
그래서 이번 패스에서는 5/5를 기본값으로 적용했다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Skill Slot Limit 추가
|
||||
|
||||
`skills.ts`에 슬롯 제한 상수를 추가했다.
|
||||
|
||||
```ts
|
||||
export const SKILL_SLOT_LIMITS = {
|
||||
WEAPON: 5,
|
||||
PASSIVE: 5,
|
||||
}
|
||||
```
|
||||
|
||||
이제 시스템 전반에서 동일한 기준을 사용한다.
|
||||
|
||||
### 후보 생성 필터링
|
||||
|
||||
`ProgressionSystem.generateSkillCards()`와 `generateMiniBossRewardCards()`에서 슬롯 제한을 반영했다.
|
||||
|
||||
규칙:
|
||||
|
||||
- 이미 보유한 스킬은 계속 레벨업 가능하다.
|
||||
- 새 무기 획득은 무기 슬롯이 5개 미만일 때만 가능하다.
|
||||
- 새 패시브 획득은 패시브 슬롯이 5개 미만일 때만 가능하다.
|
||||
- 슬롯이 꽉 찬 타입의 새 스킬은 정상 후보 생성에서 제외한다.
|
||||
|
||||
### 선택 시 슬롯 부족 방어
|
||||
|
||||
혹시 예외 경로로 선택 불가 카드가 들어오거나, UI/엔진 동기화 타이밍 문제로 새 스킬 선택이 들어올 수 있다.
|
||||
|
||||
그래서 `ProgressionSystem.applySkillSelection()`에도 최종 방어를 추가했다.
|
||||
|
||||
슬롯이 부족하면:
|
||||
|
||||
- 스킬을 추가하지 않는다.
|
||||
- 게임을 재개한다.
|
||||
- 전투 화면에 `WEAPON SLOTS FULL` 또는 `PASSIVE SLOTS FULL` 텍스트를 띄운다.
|
||||
- 보조 텍스트로 `Choose another module or skip`을 띄운다.
|
||||
|
||||
### Store 레벨 방어
|
||||
|
||||
`useGameStore.addSkill()`에도 동일한 슬롯 제한 방어를 추가했다.
|
||||
|
||||
이유:
|
||||
|
||||
- UI나 엔진 외부에서 `addSkill()`이 호출되더라도 잘못된 스킬이 저장되지 않게 하기 위함이다.
|
||||
- `__skip__`도 기존처럼 저장되지 않는다.
|
||||
|
||||
### Level Up UI 슬롯 상태 표시
|
||||
|
||||
`LevelUpModal` 상단에 현재 슬롯 상태를 표시한다.
|
||||
|
||||
표시:
|
||||
|
||||
- `Weapons 0/5`
|
||||
- `Passives 0/5`
|
||||
|
||||
슬롯이 가득 차면 해당 배지가 붉은 톤으로 바뀐다.
|
||||
|
||||
### SLOT FULL 카드 표시
|
||||
|
||||
정상 후보 생성에서는 사용 불가 카드가 거의 나오지 않지만, 예외적으로 pre-generated cards나 fallback 상태에서 들어올 수 있다.
|
||||
|
||||
이 경우 카드에 다음 표시를 추가했다.
|
||||
|
||||
- `SLOT FULL` 태그
|
||||
- `No empty weapon/passive slot` 설명
|
||||
- `WEAPON slots are full` 또는 `PASSIVE slots are full`
|
||||
|
||||
사용자는 이때 새로 추가된 `Skip Upgrade`를 선택해 넘길 수 있다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
슬롯 제한의 핵심은 빌드 선택을 더 전략적으로 만드는 것이다.
|
||||
|
||||
제한이 없으면 사용자는 결국 대부분의 무기와 패시브를 다 들고 가게 되고, 선택의 의미가 약해진다.
|
||||
|
||||
5/5 구조에서는 다음 판단이 생긴다.
|
||||
|
||||
1. 무기 슬롯 하나를 새 무기에 쓸 것인가?
|
||||
2. 기존 무기 레벨업을 기다릴 것인가?
|
||||
3. 패시브 슬롯을 EVO 재료에 쓸 것인가?
|
||||
4. 생존 패시브를 포기하고 공격 패시브를 가져갈 것인가?
|
||||
5. 지금 후보가 별로면 스킵할 것인가?
|
||||
|
||||
이번 변경은 `Skip Upgrade`의 존재 이유도 더 명확하게 만든다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/skills.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/28`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- 무기 5개를 보유한 상태에서 새 무기 후보가 정상 레벨업 목록에서 제외되는지 확인한다.
|
||||
- 패시브 5개를 보유한 상태에서 새 패시브 후보가 정상 레벨업 목록에서 제외되는지 확인한다.
|
||||
- 이미 보유한 무기/패시브는 슬롯이 가득 차도 레벨업 가능한지 확인한다.
|
||||
- 예외적으로 `SLOT FULL` 카드가 보일 때 선택하면 슬롯 부족 노티가 뜨는지 확인한다.
|
||||
- `Skip Upgrade`가 슬롯 제한 상황에서 자연스러운 탈출구로 작동하는지 확인한다.
|
||||
- 5/5가 너무 넉넉하거나 너무 답답하지 않은지 확인한다.
|
||||
+150
@@ -0,0 +1,150 @@
|
||||
# Skybound Skip Upgrade and Weapon Transform Reconfiguration
|
||||
|
||||
작성일: 2026-04-26 13:25 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Tactical Level Up 화면에서 마음에 들지 않는 업그레이드만 나올 수 있다.
|
||||
- 이 경우 사용자가 강제로 원하지 않는 업그레이드를 고르지 않도록 `업글 안하기` 선택지를 추가한다.
|
||||
- 새로운 무기가 장착되었을 때 사용자의 기체 외형도 그에 맞춰 변화해야 한다.
|
||||
- 연출적으로는 트랜스포머처럼 기체가 재구성되고 무장이 전개되는 느낌을 표현한다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
기존 레벨업 화면은 반드시 하나의 스킬을 선택해야 했다.
|
||||
|
||||
이 구조의 문제:
|
||||
|
||||
1. 현재 빌드와 맞지 않는 선택지만 나와도 강제로 선택해야 한다.
|
||||
2. 낮은 레벨 우선 후보 확률을 적용한 뒤에는 사용자가 원치 않는 저레벨/새 무기가 뜰 가능성도 생긴다.
|
||||
3. 새 무기를 획득해도 기체가 실제로 바뀌는 느낌이 약하다.
|
||||
4. 무기가 생긴 순간의 시각적 보상이 부족하다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Skip Upgrade 선택지 추가
|
||||
|
||||
`LevelUpModal`에 `Skip Upgrade` 카드를 추가했다.
|
||||
|
||||
동작:
|
||||
|
||||
- STARTER 첫 무기 선택에서는 스킵이 나오지 않는다.
|
||||
- 일반 Tactical Upgrade, Supply, Command Cache에서는 스킵 가능하다.
|
||||
- 스킵을 선택하면 스킬/무기 레벨이 증가하지 않고 전투로 복귀한다.
|
||||
|
||||
표시 문구:
|
||||
|
||||
- `HOLD UPGRADE`
|
||||
- `Skip Upgrade`
|
||||
- `No change this time`
|
||||
|
||||
### Skip 안전 처리
|
||||
|
||||
`__skip__`이 실제 스킬처럼 저장되지 않도록 여러 지점에 방어를 추가했다.
|
||||
|
||||
적용 지점:
|
||||
|
||||
- `GameSceneRenderer`
|
||||
- `ProgressionSystem`
|
||||
- `useGameStore.addSkill`
|
||||
|
||||
`__skip__`이 선택되면:
|
||||
|
||||
- Zustand `skills`에 추가하지 않는다.
|
||||
- 엔진 스킬 상태에도 추가하지 않는다.
|
||||
- `TACTICAL UPGRADE HELD` 텍스트를 띄운다.
|
||||
- 게임 pause를 해제하고 전투를 재개한다.
|
||||
|
||||
### 새 무기 장착 감지
|
||||
|
||||
`ProgressionSystem.applySkillSelection()`에서 선택 직전 스킬 레벨을 확인한다.
|
||||
|
||||
조건:
|
||||
|
||||
- 선택한 스킬이 `WEAPON` 타입
|
||||
- 선택 직전 레벨이 0
|
||||
|
||||
이 조건을 만족할 때만 새 무기 장착 연출을 발동한다.
|
||||
|
||||
기존 무기 레벨업이나 패시브 선택은 변신 연출을 발동하지 않는다.
|
||||
|
||||
### Airframe Reconfiguration 상태 추가
|
||||
|
||||
`GameState`에 새 무기 장착 연출용 상태를 추가했다.
|
||||
|
||||
추가 필드:
|
||||
|
||||
- `weaponTransformStartFrame`
|
||||
- `weaponTransformDuration`
|
||||
- `weaponTransformSkillId`
|
||||
|
||||
이 값은 렌더러가 현재 프레임 기준으로 변신 진행도를 계산하는 데 사용한다.
|
||||
|
||||
### 기체 변신/무장 전개 연출 추가
|
||||
|
||||
`GameRenderer.renderPlayer()`에 새 무기 장착 연출을 추가했다.
|
||||
|
||||
연출 요소:
|
||||
|
||||
- 기체 중심에서 확장되는 아케인 스캔 링
|
||||
- 무기 색상별 발광
|
||||
- 좌우 장갑 패널이 바깥으로 접히듯 전개
|
||||
- 전방 무장 레일이 앞으로 돌출
|
||||
- 작은 locking spark
|
||||
- `WEAPON LINK: 무기명`
|
||||
- `AIRFRAME RECONFIGURING`
|
||||
- 화면 흔들림과 파티클
|
||||
|
||||
무기별 액센트 컬러:
|
||||
|
||||
- Gatling Gun: 골드
|
||||
- Missile Pod: 핑크/레드
|
||||
- Nova Burst: 시안
|
||||
- Energy Shield: 라임
|
||||
- Sweep Laser: 화이트/시안
|
||||
- Plasma Torpedo: 오렌지
|
||||
- Ion Storm: 전기 시안
|
||||
- Attack Drone: 라임
|
||||
- Gravity Mine: 퍼플
|
||||
- Plasma Fire: 오렌지/레드
|
||||
- Plasma Blade: 시안
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 업그레이드 UX에 “선택하지 않을 권리”를 추가하는 작업이다.
|
||||
|
||||
업그레이드는 항상 이득처럼 보여야 하지만, 빌드 방향과 맞지 않는 선택을 강제하면 사용자는 선택권을 잃었다고 느낄 수 있다.
|
||||
|
||||
스킵 선택지는 다음 의미를 가진다.
|
||||
|
||||
1. 원하지 않는 업그레이드를 강제로 먹지 않는다.
|
||||
2. 빌드 순도를 유지할 수 있다.
|
||||
3. 낮은 레벨 우선 후보 시스템의 부작용을 완화한다.
|
||||
4. 선택 화면에서 사용자 판단 여지를 높인다.
|
||||
|
||||
새 무기 변신 연출은 “새 기능이 생겼다”를 UI 문구가 아니라 기체 자체 변화로 전달하기 위한 장치다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/GameSceneRenderer.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/ui/LevelUpModal.css`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/27`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- 일반 레벨업 화면에서 `Skip Upgrade`가 명확하게 보이는지 확인한다.
|
||||
- STARTER 첫 무기 선택에서는 스킵이 나오지 않는지 확인한다.
|
||||
- 스킵 선택 시 게임이 정상 재개되는지 확인한다.
|
||||
- 스킵 선택 후 `skills.__skip__` 같은 잘못된 값이 저장되지 않는지 확인한다.
|
||||
- 새 무기를 처음 선택했을 때 기체 변신 연출이 충분히 눈에 띄는지 확인한다.
|
||||
- 기존 무기 레벨업/패시브 선택 시 변신 연출이 과하게 반복되지 않는지 확인한다.
|
||||
+205
@@ -0,0 +1,205 @@
|
||||
# Skybound Stage 1 to 3 Playtest Balance Bomb and Visual Diversity Pass
|
||||
|
||||
작성일: 2026-04-26 12:35 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- Stage 1부터 Stage 3까지 실제 플레이 후 느낀 문제를 개선한다.
|
||||
- Stage 1 초반 적 탄속이 부담스럽고, 중반 이후 성장하면 너무 쉬워지는 문제를 조정한다.
|
||||
- Stage 2 시작 시 이미 Tac Level 6 정도로 강해져 적이 화면에 들어오기 전에 사망하는 문제를 완화한다.
|
||||
- Space/X 폭탄의 비주얼 이펙트가 약하므로 톤앤매너에 맞는 폭탄 연출을 강화한다.
|
||||
- 일반 적, 엘리트, 미니보스, 보스 외형 다양성을 확보한다.
|
||||
|
||||
## 핵심 문제
|
||||
|
||||
플레이 피드백 기준으로 Skybound의 현재 문제는 초반과 중반의 난이도 감각이 반대로 작동한다는 점이었다.
|
||||
|
||||
1. Stage 1 초반은 적 탄속이 빠르게 느껴져 부담스럽다.
|
||||
2. Stage 1 중반부터 스킬이 붙으면 플레이어 화력이 너무 급격히 상승한다.
|
||||
3. Stage 2에서는 적이 화면에 들어오기 전에 사망해 긴장감이 사라진다.
|
||||
4. Tac Level 성장 속도와 무기 효율이 합쳐져 “이미 완성된 빌드”처럼 느껴진다.
|
||||
5. 보스/적기 외형 반복으로 스테이지 진행감이 약하다.
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### Stage 1 적 탄속 완화
|
||||
|
||||
`balance.ts`의 적 탄환 기본 속도와 스테이지별 탄속 커브를 낮췄다.
|
||||
|
||||
변경 전:
|
||||
|
||||
- `BULLET_BASE_SPEED: 3.75`
|
||||
- `BULLET_SPEED_CURVE: [1.1, 1.28, 1.48, ...]`
|
||||
|
||||
변경 후:
|
||||
|
||||
- `BULLET_BASE_SPEED: 3.25`
|
||||
- `BULLET_SPEED_CURVE: [0.82, 0.96, 1.12, ...]`
|
||||
|
||||
Stage 1은 회피를 학습할 수 있는 속도로 낮추고, Stage 4 이후부터 탄속이 본격적으로 올라가도록 재배치했다.
|
||||
|
||||
### 적 사격 템포 완화
|
||||
|
||||
초반 탄막 부담을 줄이기 위해 `FIRE_RATE_CURVE`도 조정했다.
|
||||
|
||||
변경 후:
|
||||
|
||||
- `[280, 248, 222, 198, 176, 154, 134, 116]`
|
||||
|
||||
Stage 1-2는 더 읽을 수 있게 만들고, 후반 스테이지는 기존처럼 빠르게 압박하도록 유지했다.
|
||||
|
||||
### Tac Level 성장 속도 완화
|
||||
|
||||
Tac Level이 Stage 1 중반에 너무 빨리 누적되지 않도록 조정했다.
|
||||
|
||||
- 시작 요구 EXP: `80` → `100`
|
||||
- 레벨업 후 초과 EXP carryover: `25%` → `15%`
|
||||
- 레벨업 lockout: `360프레임` → `480프레임`
|
||||
- 일반 적 Tac EXP: `2` → `1`
|
||||
- 엘리트 Tac EXP: `10` → `8`
|
||||
- 미니보스 Tac EXP: `30` → `24`
|
||||
|
||||
목표는 Stage 2 시작 시 플레이어가 강해졌다는 느낌은 가지되, 이미 완성된 상태는 아니게 만드는 것이다.
|
||||
|
||||
### 플레이어 무기 초중반 효율 완화
|
||||
|
||||
무기 업그레이드가 의미는 있지만, Lv1-3에서 화면 전체를 지우지 않도록 주요 피해량을 조정했다.
|
||||
|
||||
- Gatling Gun 피해와 발사 효율 하향
|
||||
- Hyper Laser 피해 하향
|
||||
- Nova Burst 피해 하향
|
||||
- Missile Pod, Rocket Launcher, Ion Storm, Gravity Mine, Blade Orbit 등 데이터 기반 무기 피해 하향
|
||||
- EVO 무기도 일부 피해를 낮춰 Stage 2-3을 통째로 삭제하지 않게 조정
|
||||
|
||||
### 화면 밖 적 선삭제 방지
|
||||
|
||||
Stage 2에서 적이 화면에 나오기도 전에 사망하는 가장 큰 원인은 자동 조준/유도/빔/드론/오비트 무기가 `y < 0`에 있는 적까지 타겟팅하거나 피해를 주는 것이었다.
|
||||
|
||||
그래서 플레이어 무기 타겟팅과 충돌 판정에 `TARGETABLE_Y = -35` 기준을 추가했다.
|
||||
|
||||
적이 화면에 거의 진입하기 전까지는 다음 무기가 타겟팅하지 않는다.
|
||||
|
||||
- 유도탄
|
||||
- 자동 조준 무기
|
||||
- 빔
|
||||
- 오비트 무기
|
||||
- 드론
|
||||
- 설치/장판 무기
|
||||
- 일반 플레이어 탄환 충돌
|
||||
|
||||
이제 적이 화면에 들어와 위협을 보여준 뒤 처치되는 흐름이 만들어진다.
|
||||
|
||||
### Stage 2-3 압박 보강
|
||||
|
||||
Stage 2와 Stage 3은 이미 성장한 플레이어를 전제로 난이도를 다시 올렸다.
|
||||
|
||||
Stage 2:
|
||||
|
||||
- `diffBase: 1.02` → `1.12`
|
||||
- `capBase: 23` → `28`
|
||||
- `spawnTempo: 0.94` → `0.86`
|
||||
- opening density: `10` → `14`
|
||||
|
||||
Stage 3:
|
||||
|
||||
- `diffBase: 1.14` → `1.28`
|
||||
- `capBase: 28` → `34`
|
||||
- `spawnTempo: 0.88` → `0.78`
|
||||
- opening density: `12` → `16`
|
||||
|
||||
### 적 HP 스케일링 보강
|
||||
|
||||
일반/엘리트 적이 스킬 몇 개에 바로 삭제되지 않도록 기본 HP 공식을 조정했다.
|
||||
|
||||
추가 요소:
|
||||
|
||||
- 스테이지별 HP 증가
|
||||
- 플레이어가 예상보다 높은 Tac Level일 때 적 HP 보정
|
||||
- 엘리트 HP 배율 상향
|
||||
|
||||
이 보정은 플레이어가 잘 성장했을 때도 적이 최소한 화면에 들어와 압박을 만들도록 하기 위한 안전장치다.
|
||||
|
||||
### 폭탄 비주얼 개선
|
||||
|
||||
기존 폭탄은 얇은 원형 렌더링에 가까워 비주얼 피드백이 약했다. 이제 폭탄 사용 시 발동 위치를 저장하고, 그 지점에서 Magitech shockwave가 확장된다.
|
||||
|
||||
추가된 연출:
|
||||
|
||||
- 고정된 폭발 원점
|
||||
- 시안/라임/골드 3중 마법공학 링
|
||||
- 점선 링 회전
|
||||
- 중심 코어 플래시
|
||||
- 방사형 에너지 라인
|
||||
- 밝은 라디얼 플래시
|
||||
|
||||
Space/X를 눌렀을 때 “화면을 정리하는 기술”이라는 감각이 더 강해지도록 했다.
|
||||
|
||||
### 적기 외형 다양성 개선
|
||||
|
||||
기존 적기 스프라이트 선택은 역할별 고정값이 많아 반복감이 컸다. 이제 역할과 스테이지, 약간의 랜덤 salt를 반영해 더 다양한 스프라이트를 선택한다.
|
||||
|
||||
적용 대상:
|
||||
|
||||
- 일반 적
|
||||
- 엘리트 적
|
||||
- 미니보스
|
||||
|
||||
미니보스는 패턴별로 크기와 발광색도 달라져 작은 보스전처럼 보이게 했다.
|
||||
|
||||
### 보스 외형 다양성 개선
|
||||
|
||||
보스는 `spriteIdx`가 명시되지 않아 사실상 같은 보스 타일만 반복 사용되는 문제가 있었다. 이제 스테이지별 보스 비주얼 프로필을 갖는다.
|
||||
|
||||
프로필 요소:
|
||||
|
||||
- 보스 스프라이트 인덱스
|
||||
- 보스 크기
|
||||
- 보스 가로/세로 비율
|
||||
- 날개 포탑 위치
|
||||
- 하단 포탑 위치
|
||||
- 발광 액센트 색상
|
||||
|
||||
이제 Stage 1-8 보스는 같은 시스템을 쓰더라도 외형, 크기, 포탑 배치가 다르게 보인다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 패스의 핵심은 “초반은 읽기 쉽게, 중반은 무적감이 너무 빨리 오지 않게” 만드는 것이다.
|
||||
|
||||
원하는 플레이 감각은 다음과 같다.
|
||||
|
||||
1. Stage 1 초반: 탄을 보고 피하는 법을 배운다.
|
||||
2. Stage 1 중반: 첫 빌드가 강해지는 재미를 느낀다.
|
||||
3. Stage 1 후반: 미니보스와 보스로 빌드 검증을 한다.
|
||||
4. Stage 2: 성장한 상태지만 적도 더 빨리/많이 들어와 다시 긴장감이 생긴다.
|
||||
5. Stage 3: 단일 무기 강화만으로는 부족하고 광역/방어/관통 선택의 의미가 생긴다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/CombatTimeline.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/balance.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/config/weaponBehaviors.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/store/useGameStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/GameRenderer.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ModularWeaponSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/PlayerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/ProgressionSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/StageDirectorSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/WeaponBehaviorEngine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- `/sprites/player.png` 경고 없음
|
||||
- 출력 디렉터리: `dist/22`
|
||||
|
||||
## 후속 플레이테스트 체크 포인트
|
||||
|
||||
- Stage 1 첫 60초 탄속이 “부담스럽지만 불공정하지 않은지” 확인한다.
|
||||
- Stage 1 후반 Tac Level이 대략 3-5 사이인지 확인한다.
|
||||
- Stage 2 시작 시 적이 화면 안에 들어오기 전에 삭제되는 현상이 줄었는지 확인한다.
|
||||
- Space/X 폭탄 사용 시 충분히 강한 시각 피드백이 있는지 확인한다.
|
||||
- Stage 1-3 보스가 서로 다른 외형과 크기로 인식되는지 확인한다.
|
||||
- Stage 2-3에서 피격 압박은 생겼지만, 갑자기 불합리하게 어려워지지는 않았는지 확인한다.
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
# Skybound Stage Miniboss Pattern Differentiation
|
||||
|
||||
작성일: 2026-04-26 09:44 KST
|
||||
|
||||
## 요청 요약
|
||||
|
||||
- 미니보스 보상 루프 다음 단계로, 8개 스테이지마다 미니보스 전투 패턴을 다르게 만든다.
|
||||
- `Command Cache`를 얻는 과정 자체가 작은 보스전처럼 느껴지게 한다.
|
||||
- 스테이지가 올라갈수록 압박 방식이 달라져 반복감을 줄이고, 플레이어가 이동/회피/빌드 선택을 더 의식하게 만든다.
|
||||
|
||||
## 핵심 방향
|
||||
|
||||
기존 미니보스는 내부적으로 `ELITE + COMMANDER`에 가까웠고, 일반 적 사격 규칙을 타고 있었다. 그래서 미니보스를 처치하면 보상은 의미 있어졌지만, 전투 자체는 “체력이 많은 엘리트”처럼 느껴질 위험이 있었다.
|
||||
|
||||
이번 변경은 미니보스를 아래 역할로 재정의한다.
|
||||
|
||||
1. 각 스테이지 중반의 작은 실력 체크
|
||||
2. 스테이지 기믹을 미리 보여주는 압박 패턴
|
||||
3. `Command Cache` 보상을 얻기 위한 전투 목표
|
||||
4. 보스전 전 빌드가 충분한지 검증하는 중간 관문
|
||||
|
||||
## 적용한 변경
|
||||
|
||||
### 미니보스 패턴 타입 추가
|
||||
|
||||
`SystemEnemy`에 미니보스 전용 패턴 상태를 추가했다.
|
||||
|
||||
- `miniBossPattern`
|
||||
- `miniBossTimer`
|
||||
- `miniBossCooldown`
|
||||
- `miniBossDashFrames`
|
||||
- `miniBossActionSeed`
|
||||
- `dashTargetX`
|
||||
- `dashTargetY`
|
||||
|
||||
일반 적 AI에는 영향을 주지 않고, `isMiniBoss`가 true인 적만 전용 이동/사격 로직을 사용한다.
|
||||
|
||||
### 스테이지별 패턴 매핑
|
||||
|
||||
`SpawnerSystem`에서 현재 스테이지에 따라 미니보스 패턴을 자동 부여한다.
|
||||
|
||||
- Stage 1: `DUELIST`
|
||||
- Stage 2: `DASH_RAIDER`
|
||||
- Stage 3: `DRONE_CALLER`
|
||||
- Stage 4: `BARRAGE_WALL`
|
||||
- Stage 5: `MINE_LAYER`
|
||||
- Stage 6: `DRONE_RING`
|
||||
- Stage 7: `BLINK_SNIPER`
|
||||
- Stage 8: `OMEGA_COMMANDER`
|
||||
|
||||
### 전용 이동 AI 추가
|
||||
|
||||
`CombatSystem`에서 미니보스는 기존 `role` 기반 AI 대신 `updateMiniBossAI`를 탄다.
|
||||
|
||||
패턴별 이동/행동은 다음과 같다.
|
||||
|
||||
- `DUELIST`: 플레이어 x축을 따라가며 기본 팬샷 압박
|
||||
- `DASH_RAIDER`: 짧은 예고 후 플레이어 방향으로 돌진
|
||||
- `DRONE_CALLER`: 좌우에 스팅어 호위기를 주기적으로 소환
|
||||
- `BARRAGE_WALL`: 화면 가로 라인을 오가며 안전 구멍이 있는 탄막벽 생성
|
||||
- `MINE_LAYER`: 플레이어 근처에 위험 구름/지뢰형 압박 구역 생성
|
||||
- `DRONE_RING`: 헌터 호위기와 링 탄막으로 공간 압박
|
||||
- `BLINK_SNIPER`: 위치를 순간이동하며 빠른 저격 탄을 발사
|
||||
- `OMEGA_COMMANDER`: 팬샷, 링 탄막, 지뢰, 블링크를 순환하는 최종형 미니보스
|
||||
|
||||
### 전용 사격 패턴 추가
|
||||
|
||||
`spawnMiniBossBulletPattern`을 추가해 미니보스 사격을 일반 적과 분리했다.
|
||||
|
||||
- 팬샷
|
||||
- 빠른 저격탄
|
||||
- 링 탄막
|
||||
- 안전 구멍이 있는 라인 탄막
|
||||
- 느린 중력/지뢰형 탄
|
||||
- 최종 스테이지 혼합 패턴
|
||||
|
||||
스테이지가 올라가면 탄 수와 쿨다운이 자연스럽게 강해진다.
|
||||
|
||||
## 설계 의도
|
||||
|
||||
이번 변경은 “보상을 얻는 과정”을 재미있게 만들기 위한 작업이다.
|
||||
|
||||
이전 구조:
|
||||
|
||||
- 미니보스 등장
|
||||
- 체력이 많은 적을 처치
|
||||
- 보상 선택
|
||||
|
||||
변경 후 구조:
|
||||
|
||||
- 스테이지별 다른 압박을 가진 미니보스 등장
|
||||
- 사용자는 이동/회피/빌드 강점을 이용해 작은 보스전을 해결
|
||||
- 처치하면 `Command Cache`를 열고 빌드를 강화
|
||||
- 다음 구간을 버틸 준비가 된다
|
||||
|
||||
이렇게 하면 미니보스가 단순 보상 트리거가 아니라, 스테이지 리듬의 핵심 이벤트가 된다.
|
||||
|
||||
## 수정 파일
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/CombatSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/SpawnerSystem.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Skybound/src/features/game/systems/types.ts`
|
||||
|
||||
## 검증
|
||||
|
||||
- `npm run build` 성공
|
||||
- Vite 경고: `/sprites/player.png referenced in /sprites/player.png didn't resolve at build time`
|
||||
- 위 경고는 기존 런타임 경로 경고이며 이번 변경으로 인한 빌드 실패는 아니다.
|
||||
|
||||
## 후속 작업 제안
|
||||
|
||||
- 실제 플레이에서 Stage 4 `BARRAGE_WALL`과 Stage 7 `BLINK_SNIPER`의 탄속/쿨다운을 체감 기준으로 조정한다.
|
||||
- 미니보스 등장 시 패턴 이름을 더 상품성 있는 경고 문구로 표시한다.
|
||||
- 미니보스별 외형 색상, 엔진 이펙트, 코어 형태를 패턴에 맞게 분리한다.
|
||||
- `Command Cache` 오픈 전 0.5초 컷인 연출을 추가해 전투 승리 보상감을 더 강화한다.
|
||||
@@ -0,0 +1,37 @@
|
||||
# Index: Topics_GD > Skybound_Reports
|
||||
|
||||
## 📝 Documents
|
||||
- [[2026-04-24-Skybound_Code_Structure_Audit_and_Stabilization_Plan]]
|
||||
- [[2026-04-24-Skybound_Final_Stylized_Casual_Magitech_Redirection]]
|
||||
- [[2026-04-24-Skybound_HUD_and_TAC_LevelUp_Stylized_Casual_Magitech_Fix]]
|
||||
- [[2026-04-24-Skybound_Nova_Burst_Icon_and_Effect_Fix]]
|
||||
- [[2026-04-24-Skybound_Particle_and_Supply_Readability_Fix]]
|
||||
- [[2026-04-24-Skybound_Semirealistic_Magitech_Fantasy_Redirection]]
|
||||
- [[2026-04-24-Skybound_Stylized_Casual_Magitech_Art_Pack]]
|
||||
- [[2026-04-24-Skybound_Stylized_Casual_Magitech_Ingame_Asset_Fix]]
|
||||
- [[2026-04-24-Skybound_Survivor_Like_Balance_Curve_Pass]]
|
||||
- [[2026-04-25-Skybound_Core_Gameplay_Rebalance_and_Purpose_Reset]]
|
||||
- [[2026-04-25-Skybound_Player_Airframe_and_8Stage_Boss_Continuity_Rework]]
|
||||
- [[2026-04-25-Skybound_Skill_Concept_and_Hangar_Layout_Overlap_Fix]]
|
||||
- [[2026-04-25-Skybound_TacExp_DirectKill_and_UI_Productization_Pass]]
|
||||
- [[2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation]]
|
||||
- [[2026-04-26-Skybound_Enemy_Motion_Damage_Pressure_and_Projectile_Visual_Pass]]
|
||||
- [[2026-04-26-Skybound_HP_Scarcity_and_Module_Cache_Rewards]]
|
||||
- [[2026-04-26-Skybound_Invasion_Response_Stage_Difficulty_Curve]]
|
||||
- [[2026-04-26-Skybound_Low_Level_First_Upgrade_Offer_Balance]]
|
||||
- [[2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop]]
|
||||
- [[2026-04-26-Skybound_Player_Sprite_Path_Warning_Fix]]
|
||||
- [[2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI]]
|
||||
- [[2026-04-26-Skybound_Skill_Slot_Limit_Weapon5_Passive5]]
|
||||
- [[2026-04-26-Skybound_Skip_Upgrade_and_Weapon_Transform_Reconfiguration]]
|
||||
- [[2026-04-26-Skybound_Stage1_to_3_Playtest_Balance_Bomb_and_Visual_Diversity_Pass]]
|
||||
- [[2026-04-26-Skybound_Stage_Miniboss_Pattern_Differentiation]]
|
||||
- [[Skybound-Knowledge-Hub]]
|
||||
- [[Skybound_Asset_Generation_Roadmap]]
|
||||
- [[Skybound_Asset_Purity_Sync]]
|
||||
- [[Skybound_Defensive_Architecture_Reboot]]
|
||||
- [[Skybound_Enemy_Orientation_Fix]]
|
||||
- [[Skybound_Firepower_Overclock_v1.5]]
|
||||
- [[Skybound_Skill_Asset_Integration]]
|
||||
- [[Skybound_Skill_Image_Integration]]
|
||||
- [[Skybound_Weapon_Behavior_Engine_Migration]]
|
||||
@@ -0,0 +1,52 @@
|
||||
# 🛰️ Skybound Protocol: Strategic Knowledge Mesh (MOC)
|
||||
|
||||
Skybound 프로젝트의 모든 시스템은 유기적으로 연결되어 있습니다. 아래의 **핵심 키워드 클러스터**를 통해 시스템 간의 연관 관계를 파악하십시오.
|
||||
|
||||
---
|
||||
|
||||
## 🏷️ Keyword Cluster: #Core_Logic (엔진 및 인프라)
|
||||
프로젝트의 뼈대와 런타임 제어 메커니즘입니다.
|
||||
- **Master Plan**: [[01_Core_Engine/Skybound-Modular-Game-Architecture|Modular Architecture]]
|
||||
- **Data Flow**: [[01_Core_Engine/Stat-Injection-and-Visual-Renderer-Pipeline|Stat Injection & Renderer Pipeline]]
|
||||
- **Engine Loop**: [[01_Core_Engine/Game-Engine-Loop-and-System-Orchestration|Runtime Pipeline]]
|
||||
- **Campaign**: [[04_Mechanics_Progression/Campaign_and_Dual_Loop_System|Campaign & Dual-Loop Architecture]]
|
||||
- **Governance**: [[01_Core_Engine/Git_Synchronization_Protocol|Git & Knowledge Sync Protocol]]
|
||||
- **Visual Pattern**: [[01_Core_Engine/Visual_Feedback_Signal_Pattern|Visual Feedback Signal Pattern]]
|
||||
- **State Control**: [[01_Core_Engine/State-Machine-and-Phase-Transition-Events|Global State Machine]]
|
||||
- **Recent Reports**:
|
||||
- [[05_Project_Issues/2026-04-22_Engine_Stability_Audit|V12.1 Engine Stability Audit]]
|
||||
- [[05_Project_Issues/2026-04-21-Project-Report-V11.5-Combat-and-UI-Recovery|V11.5 Project Report (Recovery)]]
|
||||
|
||||
## 🏷️ Keyword Cluster: #Battle_Tactics (전투 및 AI)
|
||||
교전 규칙과 적 기체의 지능적 행동 양식입니다.
|
||||
- **Physics**: [[02_Combat_AI/Combat-System-and-Bullet-Interaction-Pipeline|Bullet Collision Pipeline]]
|
||||
- **Timeline**: [[03_Boss_Systems/Boss_Encounter_and_Timeline_Design|Boss Encounter & Timeline Design]]
|
||||
- **Rhythm**: [[02_Combat_AI/Staggered-Firing-Logic-and-Phase-Offset|Staggered Firing & Offset]]
|
||||
- **Implementation**: [[10_Wiki/Technical_Reports/2026-04-22_Boss_Battle_System_Implementation|V13.0 Boss Battle System Implementation]]
|
||||
|
||||
## 🏷️ Keyword Cluster: #Dopamine_UX (피드백 및 텐션)
|
||||
유저가 느끼는 '재미'의 수치화 및 연출 기법입니다.
|
||||
- **Feedback**: [[05_Project_Issues/2026-04-21-UX-Dopamine-Feedback-Upgrade|Dopamine Feedback Engine]]
|
||||
- **Visuals**: [[01_Core_Engine/Visual_Feedback_Signal_Pattern|Dynamic Color & Renderer Signal]]
|
||||
- **Tension**: [[04_Mechanics_Progression/Combat_Timeline_Difficulty_Scaling|World Tension Scaling]]
|
||||
|
||||
## 🏷️ Keyword Cluster: #Growth_Loop (성장 및 자원)
|
||||
루프물로서의 지속 가능성을 담보하는 시스템입니다.
|
||||
- **Evolution**: [[04_Mechanics_Progression/InGame_Progression_System|In-Game Progression & Evolution]]
|
||||
- **Economy**: [[04_Mechanics_Progression/Meta_Economy_Growth_Loop|Meta-Economy & Growth Loop]]
|
||||
- **Crafting**: [[04_Mechanics_Progression/Equipment_Crafting_and_Synthesis_Full|Equipment Crafting & Synthesis]]
|
||||
- **Logistics**: [[04_Mechanics_Progression/Tactical-Air-Drop-and-Supply-Logistics|Tactical Air-Drop & Supply]]
|
||||
|
||||
## 🏷️ Keyword Cluster: #Stability_QA (안정성 및 디버깅)
|
||||
시스템의 무결성을 유지하기 위한 기록입니다.
|
||||
- **Audit**: [[05_Project_Issues/2026-04-22_Engine_Stability_Audit|V12.1 Engine Integrity Audit]]
|
||||
- **Optimization**: [[05_Project_Issues/2026-04-22_Engine_Logic_Optimization_Report|Engine Logic & Physics Optimization]]
|
||||
- **Performance**: [[05_Project_Issues/2026-04-21-Engine-Stability-and-Optimization|Performance Tuning]]
|
||||
|
||||
---
|
||||
**Root Policy**: Ps-Reinforce v2.5 (Graph Expansion)
|
||||
**Last Audit**: 2026-04-22
|
||||
|
||||
---
|
||||
**Root Policy**: Ps-Reinforce v2.0
|
||||
**Project Status**: Knowledge Ingestion Complete (Batch 12.1-A)
|
||||
@@ -0,0 +1,25 @@
|
||||
# [LOG] Skybound Asset Generation Roadmap & Prompts
|
||||
|
||||
- **Timestamp**: 2026-04-23 23:03 (KST)
|
||||
- **Status**: Planning
|
||||
- **Lead**: Steve (Executive Director)
|
||||
|
||||
## 1. 작업 내용 (Task Summary)
|
||||
- **에셋 생성 가이드 수립**: 아직 이미지가 확보되지 않은 10종의 스킬(Gatling Gun, Energy Shield 등)에 대한 AI 이미지 생성 프롬프트 설계.
|
||||
- **시각적 가이드라인 정의**: Top-down view, 2D Sprite, Isolated on white background 등 Skybound 전용 에셋 표준 정의.
|
||||
|
||||
## 2. 설계 철학 (Design Philosophy)
|
||||
- **Consistency**: 모든 에셋은 '미래 산업(Future-Industrial)' 테마와 '고해상도 2D' 스타일을 공유해야 함.
|
||||
- **Clarity**: 인게임 화면에서 각 스킬의 기능(공격, 방어, 제어 등)이 실루엣만으로도 구분될 수 있도록 특징적 요소를 강조.
|
||||
|
||||
## 3. 프롬프트 리스트 (Prompt Inventory)
|
||||
- *상세 리스트는 위 대화 내용의 테이블 참조*
|
||||
|
||||
## 4. 향후 실행 계획 (Next Steps)
|
||||
- 생성된 이미지를 `public/sprites`에 배치.
|
||||
- `SpriteUtils.ts` 화이트리스트에 신규 경로 추가.
|
||||
- `skills.ts` 및 `useGameAssets.ts` 메타데이터 업데이트.
|
||||
|
||||
## 5. 관련 토픽 (Linked Topics)
|
||||
- [[Skybound]]: 비주얼 아이덴티티 확장.
|
||||
- [[Design & Experience]]: 시각적 직관성 확보를 위한 에셋 설계.
|
||||
@@ -0,0 +1,26 @@
|
||||
# [LOG] Skybound Asset Purity & Transparency Synchronization
|
||||
|
||||
- **Timestamp**: 2026-04-23 22:52 (KST)
|
||||
- **Status**: Completed
|
||||
- **Lead**: Steve (Executive Director)
|
||||
|
||||
## 1. 작업 내용 (Task Summary)
|
||||
- **스프라이트 자산 교체**: 사용자 기체(Falcon, Rayce), 일반 적기(Normal), 엘리트 적기(Elite), 보스 적기(Boss)의 이미지를 배경이 제거된 고해상도 PNG로 전면 교체.
|
||||
- **렌더링 로직 최적화**: `SpriteUtils.ts`의 `loadTransparentSprite` 함수 내에서 해당 에셋들이 'Fake Transparency Removal' 로직을 거치지 않고 원본 알파 채널을 그대로 사용하도록 화이트리스트 업데이트.
|
||||
|
||||
## 2. 작업 이유 (Rationale)
|
||||
- **미학적 완성도**: 대표님(Yesung)께서 직접 가공하신 배경 없는 고해상도 에셋의 무결성을 100% 보존하기 위함.
|
||||
- **성능 최적화**: 픽셀 단위의 색상 비교 및 배경 제거 연산(Flood-fill style algorithm)은 CPU 자원을 소모함. 이미 투명 배경이 확보된 에셋에 대해 이를 수행하는 것은 'Shit'이며, 이를 제거함으로써 로딩 속도와 런타임 효율성을 확보함.
|
||||
|
||||
## 3. 수정된 코드 (Code Changes)
|
||||
- **Target File**: `/Volumes/Data/project/Antigravity/Skybound/src/features/game/utils/SpriteUtils.ts`
|
||||
- **변경 사항**: `trueTransparencyAssets` 배열에 `'normal_enemy'`, `'elite_enemy'`, `'boss'` 키워드 추가. 이를 통해 해당 경로를 포함하는 모든 에셋은 원본 투명도를 신뢰하고 즉시 로딩됨.
|
||||
|
||||
## 4. 왜 했는가 (Why It Matters)
|
||||
- **Zero-Tolerance for Mediocrity**: 도구가 창작자의 의도를 훼손하게 두지 않기 위함. 엔진은 창작자가 제공한 완벽한 재료를 가장 순수한 상태로 유저에게 전달해야 함.
|
||||
- **System Integrity**: 에셋의 상태(Transparent vs Solid)에 따라 처리 파이프라인을 분기함으로써 시스템의 유연성과 전문성을 강화함.
|
||||
|
||||
## 5. 관련 토픽 (Linked Topics)
|
||||
- [[Skybound]]: 프로젝트 전체 에셋 관리 표준 수립.
|
||||
- [[Graphics & Performance]]: 불필요한 이미지 프로세싱 오버헤드 제거.
|
||||
- [[Design & Experience]]: 픽셀 퍼펙트한 실루엣을 통한 게임 몰입감 증대.
|
||||
@@ -0,0 +1,24 @@
|
||||
# [LOG] Skybound Defensive Architecture Reboot
|
||||
|
||||
- **Timestamp**: 2026-04-23 23:08 (KST)
|
||||
- **Status**: Completed / Integrity Guaranteed
|
||||
- **Lead**: Steve (Executive Director)
|
||||
|
||||
## 1. 작업 내용 (Task Summary)
|
||||
- **전방위적 타입 무결성 확보**: `Bullet`, `GameState` 인터페이스를 확장하여 `spriteKey`, `maxHp`, `novaBurstTimer` 등 누락된 속성들을 정식 명세로 통합.
|
||||
- **방어적 프로그래밍(Defensive Programming) 도입**: `WeaponBehaviorEngine` 및 `ModularWeaponSystem`에 `[INPUT/EXPECTED/FLOW]` 주석 체계 적용.
|
||||
- **시스템 엔트로피 감소**: `SpawnerSystem` 및 `WeaponBehaviorEngine` 내 미사용 변수 및 잘못된 스코프 참조(`weaponId`) 전량 수정.
|
||||
- **any 캐스팅 숙청**: `ModularWeaponSystem` 내 Nova Burst 로직 등에서 사용되던 `as any` 접근을 정식 인터페이스 접근으로 전환.
|
||||
|
||||
## 2. 수정한 이유 (Rationale)
|
||||
- **Anti-Fragility**: 시스템이 커짐에 따라 발생하는 타입 불일치와 참조 오류를 방지하기 위해 '수동적 디버깅'에서 '능동적 방어' 체제로 전환.
|
||||
- **Cognitive Load Reduction**: 명시적인 주석과 정교한 타입을 통해 코드를 읽는 즉시 로직의 의도와 제약 조건을 파악할 수 있게 함.
|
||||
|
||||
## 3. 핵심 설계 결정 (Key Decisions)
|
||||
- **Types-First Development**: 기능 구현 전 인터페이스 명세를 먼저 확정하고, 모든 시스템이 이를 준수하도록 강제함.
|
||||
- **Fail-Fast Principle**: 불완전한 초기 상태를 방지하기 위해 `createDefaultState`를 강화하여 런타임 안정성을 확보.
|
||||
|
||||
## 4. 연관성 (Linked Topics)
|
||||
- [[Skybound]]: 엔진 아키텍처 고도화.
|
||||
- [[Design & Experience]]: 시스템 안정성을 통한 유저 경험 보장.
|
||||
- [[Graphics & Performance]]: 리소스 참조 무결성 확보.
|
||||
@@ -0,0 +1,21 @@
|
||||
# [LOG] Skybound Enemy Orientation Fix (Crab Movement Bug)
|
||||
|
||||
- **Timestamp**: 2026-04-23 23:13 (KST)
|
||||
- **Status**: Resolved
|
||||
- **Lead**: Steve (Executive Director)
|
||||
|
||||
## 1. 버그 내용 (Bug Description)
|
||||
- **현상**: 적기가 화면 상단에서 등장할 때 정면(아래)을 보지 않고 오른쪽을 바라본 채 하강하는 '꽃게 이동' 현상 발생.
|
||||
- **원인**: 적기 생성 시 `rotation` 초기값이 `0`이었으며, 등장 단계(Entrance)에서 플레이어를 조준하는 로직이 조기 종료(Early Return)로 인해 실행되지 않아 렌더링 오프셋(`+PI/2`)만 적용되어 오른쪽을 바라보게 됨.
|
||||
|
||||
## 2. 해결 방법 (Resolution)
|
||||
- **초기화 강화**: `SpawnerSystem`에서 적기 생성 시 `rotation: Math.PI / 2`를 기본값으로 명시적 할당.
|
||||
- **로직 순서 재조정**: `CombatSystem`의 업데이트 루프에서 회전값 계산을 등장 단계 분기점 이전으로 전진 배치하여, 어떤 상태에서도 적기가 플레이어 방향(또는 아래 방향)을 유지하도록 보장.
|
||||
|
||||
## 3. 결과 (Expected Result)
|
||||
- 적기가 생성되는 즉시 플레이어를 향해 정면을 유지하며 하강함.
|
||||
- 시각적 직관성 및 전투 몰입도 향상.
|
||||
|
||||
## 4. 관련 토픽 (Linked Topics)
|
||||
- [[Skybound]]: 엔진 렌더링 무결성 확보.
|
||||
- [[Graphics & Performance]]: 스프라이트 회전 행렬 최적화.
|
||||
@@ -0,0 +1,23 @@
|
||||
# [LOG] Skybound Firepower Overclock (v1.5 Buff)
|
||||
|
||||
- **Timestamp**: 2026-04-23 23:23 (KST)
|
||||
- **Status**: Completed / Balanced
|
||||
- **Lead**: Steve (Executive Director)
|
||||
|
||||
## 1. 조정 내용 (Buff Summary)
|
||||
- **전역 공격력 계수 상향**: 초기 `effective.dmg` 스탯을 **1.0 → 1.5**로 변경하여 모든 스킬 데미지 1.5배 증강.
|
||||
- **기본 공격 로직 수정**: `PlayerSystem` 내 메인 웨폰 발사 로직에 `eff.dmg` 계수 연동. 이제 기본 공격도 전역 버프 및 업그레이드 효과를 정밀하게 반영함.
|
||||
- **필살기 밸런싱**: `GAME_BALANCE` 내 Bomb 데미지 수치 1.5배 상향 조정 (Falcon: 40→60, Rayce: 15→22.5 등).
|
||||
|
||||
## 2. 조정 이유 (Rationale)
|
||||
- **Player Empowerment**: 초기 게임 진입 장벽을 낮추고, 유저에게 더욱 시원한 파괴적 쾌감을 제공하기 위함.
|
||||
- **Architectural Fix**: 기본 공격이 스탯 계수를 무시하던 설계를 수정하여 시스템의 일관성 확보.
|
||||
|
||||
## 3. 세부 수치 변화 (Detailed Specs)
|
||||
- **Falcon Main**: 1.3 * 1.5 = 1.95 per bullet.
|
||||
- **Rayce Main**: 4.5 * 1.5 = 6.75 per shot.
|
||||
- **Skills**: All base damages defined in logic are now multiplied by 1.5 starting point.
|
||||
|
||||
## 4. 관련 토픽 (Linked Topics)
|
||||
- [[Skybound]]: 전투 밸런스 튜닝.
|
||||
- [[Design & Experience]]: 압도적인 화력을 통한 사용자 만족도 증대.
|
||||
@@ -0,0 +1,25 @@
|
||||
# [LOG] Skybound Custom Skill Asset Integration
|
||||
|
||||
- **Timestamp**: 2026-04-23 23:31 (KST)
|
||||
- **Status**: Fully Integrated
|
||||
- **Lead**: Steve (Executive Director)
|
||||
|
||||
## 1. 에셋 통합 내역 (Asset Integration)
|
||||
- **Gatling Gun**: 사용자 기체 코 부분(Nose)에 실물 스프라이트 부착 완료. 기체 회전과 실시간 동기화.
|
||||
- **Energy Shield**: 기존 더미 원형 이펙트를 `Energy Shield.png`로 교체.
|
||||
- **Nova Burst**: 충격파 발동 시 중심부에 `Nova Burst.png` 플레어 연출 추가.
|
||||
- **Ricochet Bolt**: `Ricochet Bolt.png`를 투사체 스프라이트로 적용.
|
||||
- **Missile Pod & Plasma Torpedo**: 렌더링 파이프라인 누락 수정으로 이제 정상적으로 고해상도 스프라이트 출력.
|
||||
|
||||
## 2. 기술적 해결 (Technical Fixes)
|
||||
- **Asset Pipeline Bug Fix**: `useGameAssets`에서 로드된 에셋이 `assets` 객체 누락으로 인해 `GameRenderer`에 전달되지 않던 문제 해결.
|
||||
- **Transparency Protection**: 화이트리스트 최적화를 통해 배경 제거 PNG 파일의 투명도 무결성 확보.
|
||||
- **Scaling Optimization**: 각 스킬 스프라이트의 성격에 맞춰 인게임 렌더링 사이즈(32px~48px) 최적화.
|
||||
|
||||
## 3. 향후 과제 (Next Steps)
|
||||
- 남은 스킬들에 대한 프롬프트 기반 이미지 생성 및 추가 통합.
|
||||
- 보스 파괴 시 발생하는 Physical Debris System에 대한 에셋 준비.
|
||||
|
||||
## 4. 관련 토픽 (Linked Topics)
|
||||
- [[Skybound]]: 비주얼 아이덴티티 완성.
|
||||
- [[Graphics & Performance]]: 60FPS 스프라이트 렌더링 최적화.
|
||||
@@ -0,0 +1,29 @@
|
||||
# [LOG] Skybound Skill Image & Icon Integration
|
||||
|
||||
- **Timestamp**: 2026-04-23 23:01 (KST)
|
||||
- **Status**: Completed
|
||||
- **Lead**: Steve (Executive Director)
|
||||
|
||||
## 1. 작업 내용 (Task Summary)
|
||||
- **스킬 아이콘 시각화**: `Missile Pod` 및 `Plasma Torpedo` 스킬의 아이콘을 텍스트 이모지에서 실제 경로 기반의 고해상도 이미지(`homing_missile.png`, `homing_missile04.png`)로 전면 교체.
|
||||
- **인게임 투사체 동기화**: 게임 플레이 중 발사되는 해당 무기들의 투사체(Projectile)가 실제 스프라이트로 렌더링되도록 `GameRenderer` 및 무기 시스템 업데이트.
|
||||
- **UI 렌더링 엔진 수정**: `LevelUpModal` 컴포넌트가 이미지 기반 아이콘과 텍스트 기반 아이콘을 모두 처리할 수 있도록 조건부 렌더링 로직 도입.
|
||||
|
||||
## 2. 작업 이유 (Rationale)
|
||||
- **Visual Consistency**: 유저가 선택 창에서 본 이미지가 전장에서 그대로 구현되는 '시각적 연속성'은 몰입감의 핵심임.
|
||||
- **Insanely Great UX**: 이모지는 프로토타입의 흔적임. 실제 에셋을 통한 'Stitch Fidelity'를 확보하여 제품의 격을 높임.
|
||||
|
||||
## 3. 수정된 코드 (Code Changes)
|
||||
- **Config**: `skills.ts` (아이콘 경로 업데이트)
|
||||
- **Assets**: `useGameAssets.ts` (신규 미사일 에셋 로딩 로직 추가)
|
||||
- **UI**: `LevelUpModal.tsx`, `LevelUpModal.css` (이미지 아이콘 지원 및 네온 글로우 스타일링)
|
||||
- **Engine**: `GameRenderer.ts`, `ModularWeaponSystem.ts`, `WeaponBehaviorEngine.ts` (`spriteKey` 메타데이터 연동 및 스프라이트 드로잉 로직 추가)
|
||||
|
||||
## 4. 왜 했는가 (Why It Matters)
|
||||
- **Brand Identity**: Skybound만의 독창적인 자산을 전면에 내세움으로써 타 게임과의 차별성을 확보함.
|
||||
- **Technical Scalability**: 향후 모든 스킬 아이콘을 이미지로 교체할 수 있는 확장 가능한 UI 구조를 구축함.
|
||||
|
||||
## 5. 관련 토픽 (Linked Topics)
|
||||
- [[Skybound]]: 메카닉 비주얼 아이덴티티 수립.
|
||||
- [[Design & Experience]]: 고품질 에셋을 통한 유저 리텐션 강화.
|
||||
- [[Graphics & Performance]]: 스프라이트 기반 렌더링 파이프라인 정립.
|
||||
@@ -0,0 +1,22 @@
|
||||
# [LOG] Skybound Weapon Behavior Engine Migration & Tuning
|
||||
|
||||
- **Timestamp**: 2026-04-24 01:28 (KST)
|
||||
- **Status**: Completed
|
||||
- **Lead**: Antigravity
|
||||
|
||||
## 1. 작업 개요 (Task Summary)
|
||||
- **WeaponBehaviorEngine 전면 도입**: 기존 `ModularWeaponSystem`에 남아있던 하드코딩된 레거시 무기 로직(`missile_pod`, `DIMENSION_SLAYER` 등)을 완벽히 제거하고 데이터 기반(Data-Driven) 엔진으로 마이그레이션 완료.
|
||||
- **수치 및 발사 좌표 동기화 (Tuning)**: `missile_pod` 스킬이 렌더러 파이프라인의 시각적 부착점(Attachment Point)과 일치하도록 발사 좌표(spawnX, spawnY)를 기체 양쪽 날개(x: -30, +30)로 재조정.
|
||||
|
||||
## 2. 주요 버그 해결 (Bug Fixes)
|
||||
- **미사일 중복 발사 문제 해결**: 구버전 레거시 로직과 신버전 데이터 주도 로직이 동시에 실행되며 중앙과 양측에서 미사일이 중복 발사되는 구조적 충돌을 `DATA_DRIVEN_WEAPONS` 배열 편입을 통해 완벽 해결.
|
||||
- **착시 현상(연속 발사) 진단**: 유저가 체감한 '초당 4~5발의 연속 발사'는 미사일 스킬의 오류가 아닌, **기본 무기(Falcon)가 3레벨에 도달했을 때 발동하는 '소형 유도 미사일(Homing Micro-Missiles)' 2발이 15프레임 단위로 발사되는 정상적인 시스템 기믹**임을 논리적 수치 분석으로 규명함.
|
||||
- **EXP Gem 투명도 버그 수정**: `SpriteUtils`의 투명도 제거 알고리즘 예외 목록(`trueTransparencyAssets`)에 `orb.png`를 명시하여 렌더링 무결성 확보.
|
||||
|
||||
## 3. 코드 설계 (Architectural Impact)
|
||||
- 무기별 고유 상태(`WeaponState`)는 `weaponStates` Map 객체를 통해 격리 관리되어 간섭 방지.
|
||||
- 스킬의 레벨업에 따른 발사체 쿨다운 단축 로직을 엔진 단에서 독립적으로 연산하여 확장성 부여.
|
||||
|
||||
## 4. 관련 토픽 (Linked Topics)
|
||||
- [[Skybound]]: 무기 아키텍처 및 렌더링 파이프라인.
|
||||
- [[Design & Experience]]: 시각적 피드백과 로직의 일치화.
|
||||
Reference in New Issue
Block a user