Wikify: Categorize all topics into folders and generate index pages
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-D3F316
|
||||
category: Unified
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 2026-04-15"
|
||||
---
|
||||
|
||||
# [[2026-04-15|2026-04-15]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 지식 요약 정보 추출 중...
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
본문 구조화 작업 중...
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** General Knowledge 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- Raw Source: 00_Raw/2026-04-20/2026-04-15.md
|
||||
---
|
||||
@@ -0,0 +1,27 @@
|
||||
# Engine Stability and Optimization (2026-04-21)
|
||||
|
||||
Skybound 엔진의 성능 저하 및 런타임 크래시 이슈에 대한 해결 및 방지 가이드입니다.
|
||||
|
||||
## 1. Issue: Effect Overload (이펙트 폭주)
|
||||
- **증상**: 대폭발 시 수백 개의 파편(Shard) 객체가 화면에 잔존하여 프레임 드랍 발생.
|
||||
- **해결책**:
|
||||
- **Hard Cap**: 파편 최대 생성 개수를 500개로 제한.
|
||||
- **Resource Recycling**: 파편의 수명 감소 속도를 6배 상향(0.1 -> 0.6)하여 자원 회수율 증대.
|
||||
|
||||
## 2. Issue: Rendering and API Type Mismatch
|
||||
- **증상**: `undefined` 배열 순회 시 발생하는 런타임 에러.
|
||||
- **해결책**:
|
||||
- **Optional Chaining**: `GameRenderer.ts` 내 모든 엔티티 순회 로직에 `?.` 및 `|| []` 적용.
|
||||
- **Interface Sync**: `WorldModel`에 `items`, `expGems` 등 누락된 필드를 정식 등록하여 정적 분석 강화.
|
||||
|
||||
## 3. Lesson Learned (조직적 교훈)
|
||||
- **Silo Warning**: 엔진 고도화 중 인터페이스 명세서를 동시에 업데이트하지 않을 경우, '느슨한 계약 관리'로 인해 대규모 런타임 에러가 발생할 수 있음.
|
||||
- **Defensive Programming**: 외부 주입 데이터가 언제든 `undefined`일 수 있음을 가정하고 순회 로직을 작성해야 함.
|
||||
|
||||
---
|
||||
**Status**: Resolved
|
||||
**Context**: Infrastructure / Performance Tuning
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Optimization]]
|
||||
@@ -0,0 +1,39 @@
|
||||
# Skybound Implementation and Architecture Report (V10.5)
|
||||
|
||||
Skybound 프로젝트의 Phase 2 인프라 고도화 결과를 기록한 통합 보고서입니다.
|
||||
|
||||
## 1. Core Architecture (마스터 타임라인)
|
||||
시스템은 시간의 흐름에 따라 긴장감을 제어하는 **4단계 페이즈 시스템**(`StageDirectorSystem`)을 채택하고 있습니다.
|
||||
|
||||
| 페이즈 | 시간 | 주요 특징 |
|
||||
| :--- | :--- | :--- |
|
||||
| **INTRO** | 0~3분 | 기초 파밍 및 적응 단계 |
|
||||
| **ELITE_PRESS** | 3~7분 | 정예 기체 중심의 압박 |
|
||||
| **SWARM** | 7~12분 | 대규모 물량 습격 (Survivor-like) |
|
||||
| **FINAL_BOSS** | 12분~ | 최종 결전 시퀀스 |
|
||||
|
||||
## 2. Evo-Engine Mechanics (데이터 기반 진화)
|
||||
데이터(Registry)와 로직(Engine)을 분리하여 확장성을 확보했습니다.
|
||||
- **SKILL_REGISTRY**: 스킬 메타데이터 중앙 관리 허브.
|
||||
- **Evolution Recipe**: 특정 주무기(Lv.5)와 보조 모듈의 조합을 통한 상위 티어 진화 공식 정의.
|
||||
|
||||
## 3. High-Dopamine Feedback System
|
||||
유저의 시각적/촉각적 몰입을 극대화하기 위한 연출 가이드입니다.
|
||||
- **Red Critical & Screen Shake**: 타격 시 텍스트 연출과 흔들림 이펙트.
|
||||
- **Glitch Effect**: 진화 성공 시의 강렬한 연출.
|
||||
|
||||
## 4. Meta-Game Economy (순환 구조)
|
||||
장비의 합성(`NORMAL` ~ `ETERNAL`)과 분해를 통한 자원 회수 루프를 구축하였습니다.
|
||||
- **Triple Merge**: 동일 등급 3개 합성 방식.
|
||||
- **Core Extraction**: S급 장비 분해를 통한 상위 제작 재화 확보.
|
||||
|
||||
---
|
||||
**Status**: Approved (2026-04-21)
|
||||
**Lead**: AI 개발부장 '코다리'
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Dopamine]]
|
||||
* [[_report]]
|
||||
* [[_system]]
|
||||
@@ -0,0 +1,33 @@
|
||||
# Project Report V11.5: Combat and UI Recovery (2026-04-21)
|
||||
|
||||
Skybound 프로젝트의 치명적인 결함을 복구하고 유저 인터페이스를 고도화한 통합 개발 보고서입니다. 🟢 [NOMINAL]
|
||||
|
||||
## 1. Combat Engine Recovery (전투 엔진 복구)
|
||||
현장 QA에서 발견된 핵심 결함들을 즉각 조치하였습니다.
|
||||
|
||||
- **Exp-Gems Drop**: 적 처치 시 경험치 보석이 드랍되지 않던 현상을 `CombatSystem.ts` 수정을 통해 해결.
|
||||
- **Engine Synchronization**: 레벨업 UI에서의 선택 사항이 `useGameEngine.ts`에 즉시 반영되지 않던 채널 장애 복구.
|
||||
- **Starter Loadout**: 초반 무기 부재 문제를 해결하기 위해 **'Gatling Gun Lv.1'**을 모든 기체에 기본 장착 사양으로 고정.
|
||||
|
||||
## 2. UI/UX Innovation (직관성 강화)
|
||||
유저의 정보 인지 속도를 높이기 위한 시각적 개선 작업을 수행했습니다.
|
||||
|
||||
- **Terminology Standardization**: 스토리지의 모호한 약자(A, E)를 **Armor, Engine** 등 명확한 전문 용어로 전면 교체.
|
||||
- **Acquisition Alerts**: 신규 모듈 획득 시 등급별 고유 색상(Tier-Colored)과 애니메이션이 포함된 알림 노출.
|
||||
- **New Indicator**: 창고 내 미확인 아이템에 **'NEW'** 뱃지 및 발광(Glow) 효과 적용.
|
||||
|
||||
## 3. Infrastructure & Roadmap
|
||||
- **Git Automation**: 작업 완료 즉시 커밋 및 푸시가 이행되는 자동화 파이프라인 구축.
|
||||
- **Next Step**: 드론 병합(Merge) 및 아트 리소스 실장(Real-Asset Loading) 작업 예정.
|
||||
|
||||
---
|
||||
**Status**: Critical Recovery Complete
|
||||
**Reviewer**: AI 개발부장 '코다리' 🫡🐟
|
||||
**Tags**: #Stability_QA #Dopamine_UX #Core_Logic
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Innovation]]
|
||||
* [[Roadmap]]
|
||||
* [[Terminology]]
|
||||
* [[_report]]
|
||||
@@ -0,0 +1,28 @@
|
||||
# UX and Dopamine Feedback Upgrade (V10.0)
|
||||
|
||||
단순한 발사 로직을 넘어, 유저에게 강렬한 피드백을 전달하기 위한 설계 사양입니다.
|
||||
|
||||
## 1. Probabilistic Critical Hit (슬롯머신 경험)
|
||||
- **공식**: `damage *= 1.5 + Math.pow(Math.random(), 3) * 3.5`
|
||||
- **심리적 효과**: Cubic Power를 사용하여 초고속 데미지가 극도로 희귀하게 발생하게 함으로써, 소위 '잭팟(Jackpot)' 효과 유도.
|
||||
|
||||
## 2. Visual Feedback Engine
|
||||
타격의 세기에 따라 시각적 계층을 분리했습니다.
|
||||
- **Normal**: 작은 흰색 숫자 출력.
|
||||
- **Critical**: 대형 황금색 "CRITICAL!" 텍스트 및 `shadowBlur` 이펙트(부유 후 페이드아웃).
|
||||
|
||||
## 3. Difficulty Scaling Algorithm
|
||||
플레이어가 지루함을 느끼지 않도록 시간이 지날수록 난이도를 복리로 상승시킵니다.
|
||||
- **Factor**: `difficultyMult = 1.0 + (frame / 3600) * 0.1`
|
||||
- **영향 범위**: 적 생성 쿨다운 감소, 적 HP 상승, 환경 장애물(Asteroids) 보정률 상승.
|
||||
|
||||
## 4. Policy: FALCON Streamlining
|
||||
통계적 밸런싱의 용이성을 위해 현재 주력 기체를 `FALCON`으로 단일화하고 집중 케어합니다.
|
||||
|
||||
---
|
||||
**Status**: Verified High-Dopamine Content
|
||||
**Category**: Game Design / User Experience
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Dopamine]]
|
||||
@@ -0,0 +1,32 @@
|
||||
# ⚡ Skybound: Stability & [[Optimization|Optimization]] Report (2026-04-21)
|
||||
|
||||
## 1. Executive Summary (요약)
|
||||
대규모 교전 및 아이템 사용 시 발생하는 성능 저하와 런타임 크래시를 해결하기 위한 엔진 안정성 보강 작업을 수행하였습니다.
|
||||
|
||||
## 2. Key Optimization Areas (주요 최적화 영역)
|
||||
|
||||
### 💥 Particle Effect [[Management|Management]] (이펙트 제어)
|
||||
- **Problem**: 폭탄 사용 시 수천 개의 파편(Shard) 객체가 생성되어 FPS 급락.
|
||||
- **[[Solution|Solution]]**:
|
||||
- **Hard Cap**: 최대 파티클 개수를 500개로 제한.
|
||||
- **TTL (Time To Live) Acceleration**: 파티클 소멸 속도를 6배 상향(0.1 -> 0.6)하여 자원 회수 주기를 단축.
|
||||
|
||||
### 🛡️ Runtime [[Robustness|Robustness]] (런타임 강건성)
|
||||
- **Problem**: 존재하지 않는 엔티티 배열 접근으로 인한 `TypeError`.
|
||||
- **Solution**:
|
||||
- `GameRenderer` 내 모든 순회 로직에 옵셔널 체이닝(`?.`) 및 기본값(`|| []`) 처리 의무화.
|
||||
- 인터페이스(`types.ts`)와 실제 상태 객체 간의 동기화 정밀 검수.
|
||||
|
||||
### 🔄 Entity Pool Intelligence (엔티티 풀 고도화)
|
||||
- **Problem**: ID(String)와 객체 참조 간의 혼선으로 인한 해제 실패.
|
||||
- **Solution**:
|
||||
- `EntityManager`에 `releaseById` 메서드 추가.
|
||||
- 객체 여부와 관계없이 안전하게 리소스를 반납할 수 있는 추상화 레이어 구축.
|
||||
|
||||
## 3. Post-Mortem (사후 분석)
|
||||
- **Silo Effect**: 엔티티 매니저 도입과 같은 대규모 인프라 변경 시, 관련 인터페이스를 동시에 업데이트하지 않아 발생한 '느슨한 계약(Loose Contract)' 문제가 근본 원인이었습니다.
|
||||
- **Guideline**: 시스템 간 데이터 교환 방식(ID 기반 vs 참조 기반)을 프로젝트 표준으로 확정하고 준수해야 합니다.
|
||||
|
||||
---
|
||||
**Related Cluster**: Performance Tuning
|
||||
**Status**: Verified by QA 🫡
|
||||
@@ -0,0 +1,52 @@
|
||||
# [TECH-REPORT] Skybound Boss Battle Architecture (v1.0)
|
||||
**Date**: 2026-04-22
|
||||
**Author**: Antigravity (Dev Lead)
|
||||
**Status**: COMPLETED / STABLE
|
||||
|
||||
## 1. 개요 (Overview)
|
||||
Skybound Protocol의 8단계 캠페인 시스템 완성을 위한 '데이터 주도형 보스 전투 시스템'의 구현 상세를 기록한다. 본 시스템은 하드코딩된 보스 로직을 탈피하고, 외부 레지스트리 기반의 페이즈 제어 및 플레이어 숙련도(Mastery)에 따른 최종 보스 분기 로직을 핵심으로 한다.
|
||||
|
||||
## 2. 주요 구현 사항 (Key Implementations)
|
||||
|
||||
### 2.1 기체별 데미지 감쇄 시스템 (Damage Mitigation)
|
||||
- **목적**: 기체(Airframe)별 개성을 강화하고 생존 전략의 차별화 제공.
|
||||
- **로직**: `CombatSystem.ts` 내 피격 판정 시 `GAME_BALANCE`의 감쇄율 적용.
|
||||
- **수치**:
|
||||
- **FALCON**: 탄환 -17% / 충돌 -34%
|
||||
- **RAYCE**: 탄환 -13% / 충돌 -26%
|
||||
|
||||
### 2.2 보스 레지스트리 아키텍처 (Boss Registry)
|
||||
- **파일**: `src/features/game/config/bossRegistry.ts`
|
||||
- **역할**: 스테이지별 보스 데이터(이름, ID, 페이즈 구성, 패턴 밀도)의 Single Source of Truth.
|
||||
- **특징**: `resolveNextPhase()` 유틸리티를 통해 HP 임계값, 부하 기체 전멸(`MINIONS_CLEARED`), 부품 파괴 등 다양한 조건에 따른 동적 페이즈 전환 지원.
|
||||
|
||||
### 2.3 최종 보스 분기 로직 (Mastery Branching)
|
||||
- **위치**: `StageDirectorSystem.ts` -> `instantiateBoss()`
|
||||
- **조건**: 인게임 모든 업그레이드(6종)가 **Level 10 (Mastery)**에 도달했는지 체크.
|
||||
- **분기**:
|
||||
- **Normal**: 험프티 덤프티 (Humpty Dumpty)
|
||||
- **Mastery**: 디바인 램파트 (Divine Rampart) - 기본 체력 1.5배 증가 및 4단계 페이즈 구성.
|
||||
|
||||
## 3. 데이터 구조 (Data Structure)
|
||||
|
||||
```typescript
|
||||
export interface BossPhase {
|
||||
phaseIndex: number;
|
||||
attackPatterns: Pattern[];
|
||||
transformationTrigger: 'HP_THRESHOLD' | 'ALL_PARTS_DESTROYED' | 'MINIONS_CLEARED' | null;
|
||||
hpThreshold: number | null;
|
||||
}
|
||||
```
|
||||
|
||||
## 4. 향후 유지보수 가이드 (Maintenance)
|
||||
- **보스 추가**: `bossRegistry.ts`의 `BOSS_REGISTRY` 배열에 신규 `BossDefinition`을 추가하는 것만으로 신규 보스 및 페이즈 설계 가능.
|
||||
- **밸런스 조정**: `balance.ts`의 `PLAYER.AIRFRAMES` 섹션에서 감쇄율 수치 즉시 조정 가능.
|
||||
|
||||
---
|
||||
**Approval Status**: 🫡 (Kodari Approved)
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Mastery]]
|
||||
* [[Single_Source_of_Truth]]
|
||||
@@ -0,0 +1,34 @@
|
||||
# 📝 [Technical Report] 보스 스폰 시스템 안정화 및 AI 교전 로직 개선
|
||||
|
||||
## 1. 개요 (Overview)
|
||||
본 문서는 Skybound 프로젝트의 최종 보스 미출현 이슈 해결 및 적기 AI의 공격성 강화를 위한 기술적 수정 사항을 기록합니다.
|
||||
|
||||
## 2. 적기 AI 개선 (Enemy AI Overhaul)
|
||||
기존의 '낙엽 효과(Wobble)'와 '회피(Avoidance)' 로직을 제거하고 공격적 교전 패턴을 도입했습니다.
|
||||
|
||||
- **낙엽 효과 제거**: `CombatSystem` 내 `Math.sin` 기반 좌우 흔들림 로직 삭제.
|
||||
- **회피 로직 삭제**: 플레이어 근접 시 발생하는 기피력(Repulsion) 제거.
|
||||
- **예측 요격(Predictive Interception)**: 플레이어의 현재 속도($v_x, v_y$)를 기반으로 12프레임 뒤의 위치를 타격하는 로직 적용.
|
||||
- **근접전 페널티**: 플레이어와 거리 250px 이내에서 연사력 2배 부스트 적용.
|
||||
|
||||
## 3. 보스 스폰 안정화 (Boss Spawn Fix)
|
||||
트리거와 페이즈 전환 간의 동기화 오류를 해결했습니다.
|
||||
|
||||
- **트리거 선행 배치**: `CombatTimeline`의 보스 스폰 트리거를 페이즈 시작 10초 전으로 앞당김 (870s -> 860s).
|
||||
- **시퀀스 가속**:
|
||||
- `FINAL_BOSS` -> `BOSS_WARNING`: 180프레임 -> 60프레임 (1초)
|
||||
- `BOSS_WARNING` -> `BOSS`: 300프레임 -> 120프레임 (2초)
|
||||
- **응답성 개선**: 보스 경고 발생 후 실제 등장까지의 체감 대기 시간을 총 8초에서 3초로 단축.
|
||||
|
||||
## 4. 엔진 무결성 점검 (Integrity Check)
|
||||
- `StageDirectorSystem.ts`의 코드 단절(Truncation) 여부를 확인하고 정상 작동을 검증함.
|
||||
- `CombatSystem.ts`의 타입 안전성 확보 및 AI 역할별 이동 패턴 정상화 확인.
|
||||
|
||||
---
|
||||
**Status**: Green (Operational)
|
||||
**Author**: Antigravity (AI Dev Director 'Kodari')
|
||||
**Date**: 2026-04-22
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[_report]]
|
||||
@@ -0,0 +1,47 @@
|
||||
# ⚙️ Engine Logic Optimization & Modernization
|
||||
|
||||
**Category:** Architecture / Physics
|
||||
**Status:** Completed (v12.1)
|
||||
**Related:** Engine Loop, Boss Encounter Design
|
||||
|
||||
---
|
||||
|
||||
## 1. Tactical Logical Modernization
|
||||
Skybound의 초기 '무작위성' 중심 로직을 '의도된 연출' 중심으로 전환한 핵심 최적화 내역입니다.
|
||||
|
||||
### 🛡️ Reactive Stat Sync (실시간 스탯 동기화)
|
||||
- **메커니즘**: `useGameStore.subscribe`를 통해 장비 교체나 영구 업그레이드 발생 시, 엔진의 `effectiveStats`를 런타임에 즉시 재계산.
|
||||
- **효과**: "인벤토리에서 공격력을 올렸는데 왜 바로 강해지지 않는가?"라는 모순을 해결.
|
||||
|
||||
### 🛰️ Priority-Based Spawning (우선순위 기반 스폰)
|
||||
- **Logic**: 하드캡(`MAX_ENEMIES_HARD_CAP`) 도달 시, `ELITE` 이상의 등급은 일반 적(`NORMAL`)을 **강제 퇴거(Despawn)**시키고 자리를 확보함.
|
||||
- **효과**: 물량에 밀려 보스가 등장하지 못하는 치명적인 결함 방지.
|
||||
|
||||
---
|
||||
|
||||
## 2. Combat Physics & HP Revamp
|
||||
|
||||
### 📏 100-Base HP System
|
||||
- **구형**: 하트 5칸 기반의 단순 생명력 시스템 (회복 및 성장 가시성 낮음).
|
||||
- **신규**: 100 기준의 체력 시스템으로 통합하여 퍼센트 단위 회복 및 영구 HP 업그레이드 반영이 가능하도록 구조화.
|
||||
|
||||
### 💥 Mutual Knockback (물리 충돌)
|
||||
- 단순히 겹칠 때 대미지를 입는 방식에서 벗어나, 충돌 벡터(`vx`, `vy`)를 기반으로 서로 밀려나는 물리 작용 구현.
|
||||
- **타격감**: 기체 간 충돌 시의 '묵직함' 확보.
|
||||
|
||||
---
|
||||
|
||||
## 3. Engagement Compression
|
||||
- **Blitz Mode**: 보스 출현 시간을 **60초**로 단축하여 파밍 효율 극대화.
|
||||
- **Standard Mode**: 보스 조우 타임라인을 **2분**으로 압축하여 검증 및 플레이 텐션 강화.
|
||||
|
||||
---
|
||||
**Last Updated:** 2026-04-22 🫡
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Logic]]
|
||||
* [[Optimization]]
|
||||
* [[Physics]]
|
||||
* [[_system]]
|
||||
@@ -0,0 +1,38 @@
|
||||
# 🔍 Skybound 엔진 구조 정밀 감사 보고서 (V12.1)
|
||||
|
||||
> **카테고리**: Skybound, Software Reliability, Governance & Reliability
|
||||
> **상태**: ✅ 감사 완료 (Audited)
|
||||
> **최종 업데이트**: 2026-04-22
|
||||
|
||||
---
|
||||
|
||||
## 📌 개요 (Overview)
|
||||
엔진 안정성에 대한 의구심(코드 잘림, 상태 단절 등)이 제기됨에 따라, 전체 시스템 파이프라인(ECS-like Update, Zustand Sync, Progression Flow)을 전수 조사하여 아키텍처적 건전성을 검증함.
|
||||
|
||||
## 📊 감사 요약 (Audit Summary)
|
||||
|
||||
| 이슈 항목 | 실제 상태 | 심각도 | 판정 결과 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **#1 Engine Execution Gap** | **정상** — `ctx` 객체 완전 구성됨 | 🟢 Low | 단순 파일 읽기 초과로 인한 오판 |
|
||||
| **#2 State-Physics Disconnect** | **정상** — `setExp/setLevel` 액션 완결 | 🟢 Low | 15프레임 Dirty Checking 동기화 확인 |
|
||||
| **#3 Gimmick Manager 빈 껍데기** | **부분 유효** — 구현 완료, 타입 불일치 1건 | 🟡 Med | `spawnParticle` 인자 불일치 수정 완료 |
|
||||
| **#4 Collision-to-EXP 미연결** | **정상** — Combat → Progression 연결됨 | 🟢 Low | Gem 수집부터 카드 생성까지 연결 확인 |
|
||||
|
||||
## 🛠️ 정밀 분석 (Detailed Analysis)
|
||||
|
||||
### 1. 엔진 컨텍스트 (`ctx`) 및 루프 구조
|
||||
- **Context Integrity**: `useGameEngine.ts` 내에서 플레이어, 상태, 입력, 엔티티 매니저 및 각종 스폰 함수가 `ctx` 객체에 완전히 맵핑되어 각 시스템에 전달되고 있음.
|
||||
- **Loop Flow**: `StageDirector` → `System Logic` → `Combat/Progression` → `Renderer` 순의 고전적 ECS 파이프라인이 매 프레임(60FPS) 정상 작동함.
|
||||
|
||||
### 2. 상태 관리 브릿지 (Store Sync)
|
||||
- **Zustand Interface**: 엔진 내부 상태(`state.currentExp` 등)와 외부 UI 스토어(`useGameStore`) 간의 데이터 동기화는 `useGameEngine.ts`에서 15프레임마다 수행되는 브릿지 로직을 통해 효율적으로 관리됨 (불필요한 React Re-render 방지).
|
||||
|
||||
### 3. 실제 수정 사항 (Bug Fix)
|
||||
- **GravityGimmick.ts**: `ctx.spawnParticle` 호출 시 엔진 시그니처와 불일치하는 5번째 인자(`'DIR'`)가 전달되는 문제를 식별하여 제거함. 이는 시스템 오류를 유발하지는 않으나 타입 정결성을 위해 조치됨.
|
||||
|
||||
## 📋 최종 결론
|
||||
Skybound 엔진은 **구조적으로 건강하며, 모든 핵심 파이프라인이 완전히 구현된 상태**임. 향후 확장을 위한 아키텍처적 기반(Intent Protocol, Signal Pattern)이 견고하게 구축되어 있음을 확인함.
|
||||
|
||||
---
|
||||
**승인인**: AI 개발부장 코다리 🫡
|
||||
**관련 문서**: 02_Architecture_Principles, [[Visual_Feedback_Signal_Pattern|Visual_Feedback_Signal_Pattern]]
|
||||
@@ -0,0 +1,34 @@
|
||||
# ISSUE REPORT: [v13.1] Engine Stabilization & Tactical Boundary Overhaul
|
||||
|
||||
## 1. 개요
|
||||
Skybound 엔진의 초기 구동 안정성을 확보하고, 게임의 장르적 성향(전략 슈터)을 강화하기 위한 적기 이동 로직 및 레벨업 시스템의 결함을 해결함.
|
||||
|
||||
## 2. 해결된 결함 (Level-Up Loop)
|
||||
### 2.1 현상
|
||||
- 게임 시작 직후 `TAC LEVEL UP` 모달이 무한 반복 출력되어 조작 불능 상태 발생.
|
||||
- 엔진 내부 레벨과 Zustand 스토어 레벨 간의 동기화 불일치.
|
||||
|
||||
### 2.2 원인 분석
|
||||
- `StageDirectorSystem`: 타임라인 이벤트가 최소 시간 가드 없이 초기화 시점에 조기 발동.
|
||||
- `ProgressionSystem`: 스킬 선택 시 Zustand 구독과 엔진 로직 양쪽에서 레벨을 이중 증가시킴.
|
||||
|
||||
### 2.3 수정 사항
|
||||
- **StageDirectorSystem**: 15초/30초 최소 시간 가드 및 `processed[[Events|Events]]econds` 중복 발동 방지 락 도입.
|
||||
- **ProgressionSystem**: 이중 증가 로직 제거 및 Zustand [[Single_Source_of_Truth|Single Source of Truth]](SSOT) 강화.
|
||||
- **UI**: `LevelUpModal`에 `isChest` 플래그를 추가하여 일반 레벨업과 보급품(Supply Drop) 보상을 시각적으로 분리.
|
||||
|
||||
## 3. 기능 개선 (Enemy Tactical Boundary)
|
||||
### 3.1 현상
|
||||
- 적기가 격파되지 않은 상태에서 화면 하단으로 유유히 사라짐 (전통적 슈팅 게임 방식).
|
||||
- 플레이어의 전략적 대응 영역 및 경험치 수급 기회 상실.
|
||||
|
||||
### 3.2 수정 사항 (CombatSystem)
|
||||
- **Boundary Clamp**: 적기의 이동 허용 범위를 `height + 300`에서 `height - 40`으로 타이트하게 조정.
|
||||
- **Chase Pattern**: 플레이어 추격 시 화면 하단 경계를 인식하도록 가드 추가.
|
||||
- **Zigzag Pattern**: 화면 하단 도달 시 방향을 반전시키는 '핑퐁(Ping-pong)' 패턴으로 업그레이드.
|
||||
- **Striker AI**: 하단 돌진 후 상단으로 복귀하는 순찰 로직 추가.
|
||||
|
||||
## 4. 기대 효과
|
||||
- **안정성**: 게임 초기화 및 재개 시 발생하는 상태 데드락 원천 차단.
|
||||
- **전략성**: 모든 적이 화면 내에 유지됨으로써 플레이어의 통제권 강화 및 생존 슈터로서의 긴장감 극대화.
|
||||
- **경제**: 경험치 젬 및 루트 아이템의 화면 밖 유실 방지.
|
||||
@@ -0,0 +1,34 @@
|
||||
# POST-MORTEM: Skybound Meta-Game Stabilization & Loot Economy Overhaul (2026-04-23)
|
||||
|
||||
## 1. 프로젝트 개요
|
||||
보스전 이후 스테이지 전이가 멈추는 치명적 버그를 해결하고, 기획안에 맞춘 전리품(Loot) 경제 밸런스 재조정 및 보급품 시스템의 논리적 결함을 수정한 포스트모텀.
|
||||
|
||||
## 2. 주요 해결 과제 및 분석 (Key Issues)
|
||||
|
||||
### 2.1 보스 처치 후 진행 불가 (Stage Progression Stall)
|
||||
- **현상**: 보스를 처치하고 폭발 연출까지 완료되었으나, 다음 스테이지로 넘어가지 않고 화면에 갇히는 현상.
|
||||
- **원인**: `StageDirectorSystem`에서 보스 사망 시 `NEXT_STAGE` 이벤트를 발행했으나, 엔진의 메인 루프(`useGameEngine`)에 해당 이벤트를 수신하여 UI/상태를 전환하는 핸들러가 누락되어 있었음.
|
||||
- **해결**: `useGameEngine.ts`의 `emitEvent` 리스너에 `BOSS_ACTION: NEXT_STAGE` 케이스를 추가하고, `finishMission('CLEAR', ...)`을 호출하도록 연결.
|
||||
|
||||
### 2.2 전리품 드롭 확률 불균형 (Loot Economy Inflation)
|
||||
- **현상**: 보스 처치 시 무조건 S급 아이템이 나오거나, 일반 적들의 드롭률이 너무 높아 아이템 희소성이 결여됨.
|
||||
- **원인**: `LootGenerator.ts` 내부에 하드코딩된 확률 임계값이 초기 테스트용으로 과하게 설정되어 있었음.
|
||||
- **해결**: 대표님 제시안에 맞춰 보스 드롭률을 **67%**로 제한하고, 등급별 확률(S: 5%, Epic: 1% 등)을 정밀 재조정함. 엘리트 및 일반 적의 드롭률도 대폭 하향하여 파밍의 재미를 강화.
|
||||
|
||||
### 2.3 보급 상자 '가짜 업그레이드' (Phantom Upgrades)
|
||||
- **현상**: 보급 상자(Chest)를 통해 무기를 골라도 실제 무기 레벨이 오르지 않아, 겉모습만 레벨업인 상태(레벨 3에서 무한 업그레이드 느낌)가 지속됨.
|
||||
- **원인**: UI(`GameSceneRenderer`)에서 `isChest` 플래그가 활성화된 경우, "레벨업이 아니므로 스킬을 적용하지 않는다"는 잘못된 방어 로직이 적용되어 있었음.
|
||||
- **해결**: `isChest` 유무와 관계없이 선택된 스킬을 엔진과 스토어에 적용(`addSkill`, `applySkill`)하도록 수정하여 보급 상자의 실질적 효용성 확보.
|
||||
|
||||
## 3. 잘된 점 (What Went Well)
|
||||
- **신속한 원인 파악**: 엔진 이벤트 루프와 UI 상태 간의 단절 지점을 정확히 찾아내어 최소한의 코드 수정으로 버그 해결.
|
||||
- **기획 충실도**: 텍스트로 전달된 복잡한 확률 테이블을 엔진 코드에 오차 없이 반영.
|
||||
- **동기화 성공**: 엔진 내부 상태와 Zustand 글로벌 스토어 간의 싱크를 맞춰 '가짜 업그레이드' 현상을 원천 해결.
|
||||
|
||||
## 4. 교훈 및 향후 과제 ([[Lessons Learned|Lessons Learned]] & Next Steps)
|
||||
- **이벤트-리스너 쌍 검증**: 새로운 시스템 이벤트를 정의할 때 반드시 수신 측(Listener)이 구현되었는지 체크리스트화 필요.
|
||||
- **UI/엔진 역할 분담**: `isChest`와 같은 상태 플래그가 비즈니스 로직(스킬 적용)까지 차단하지 않도록 설계 시 주의.
|
||||
- **모니터링 강화**: 현재 확률에 따른 드롭 현황을 로깅하여 장기적인 밸런싱 데이터 확보 예정.
|
||||
|
||||
## 5. 결론
|
||||
이번 안정화 작업을 통해 Skybound의 **'전술적 긴장감'**과 **'성장 루프'**가 정상 궤도에 진입함. 보스전 - 보급 - 스테이지 전환으로 이어지는 핵심 게임 루프의 기술적 무결성 확인 완료. 🫡🐟
|
||||
+145
@@ -0,0 +1,145 @@
|
||||
# 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.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[2026-04-22_Boss_Battle_System_Implementation]]
|
||||
* [[2026-04-22_Engine_Stability_Audit]]
|
||||
* [[Analysis]]
|
||||
* [[Architecture]]
|
||||
* [[Blocking]]
|
||||
* [[Campaign_and_Dual_Loop_System]]
|
||||
* [[Combat-System-and-Bullet-Interaction-Pipeline]]
|
||||
* [[ESLint]]
|
||||
* [[Events]]
|
||||
* [[Game-Engine-Loop-and-System-Orchestration]]
|
||||
* [[InGame_Progression_System]]
|
||||
* [[React]]
|
||||
* [[Single_Source_of_Truth]]
|
||||
* [[Skybound-Knowledge-Hub]]
|
||||
* [[Skybound-Modular-Game-Architecture]]
|
||||
* [[State]]
|
||||
* [[goal]]
|
||||
+158
@@ -0,0 +1,158 @@
|
||||
# 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.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Blocking]]
|
||||
* [[Metal]]
|
||||
* [[Noise]]
|
||||
* [[Reports]]
|
||||
* [[Scripts]]
|
||||
* [[Support]]
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
# 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.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Affordance]]
|
||||
* [[Blocking]]
|
||||
@@ -0,0 +1,89 @@
|
||||
# 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.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Behavior]]
|
||||
* [[Blocking]]
|
||||
* [[Scripts]]
|
||||
+79
@@ -0,0 +1,79 @@
|
||||
# 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.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Affordance]]
|
||||
* [[Blocking]]
|
||||
+145
@@ -0,0 +1,145 @@
|
||||
# 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.
|
||||
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Metal]]
|
||||
@@ -0,0 +1,161 @@
|
||||
# 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`
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Hardware]]
|
||||
* [[Metal]]
|
||||
* [[Noise]]
|
||||
* [[Purpose]]
|
||||
* [[Scripts]]
|
||||
+108
@@ -0,0 +1,108 @@
|
||||
# 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.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Blocking]]
|
||||
* [[Reports]]
|
||||
* [[Scripts]]
|
||||
@@ -0,0 +1,184 @@
|
||||
# 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?
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Blocking]]
|
||||
* [[Events]]
|
||||
* [[Support]]
|
||||
* [[Synergy]]
|
||||
@@ -0,0 +1,64 @@
|
||||
# Datacollector - 인증 복구 후 자동 재개 상태 전환 수정
|
||||
|
||||
- 작성 시각: 2026-04-25 22:39:30 KST
|
||||
- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
- 관련 파일: `src/components/AgentDashboard.tsx`, `src/lib/engine.ts`
|
||||
|
||||
## 상황
|
||||
|
||||
NotebookLM 인증 복구 로직을 강화했지만, 화면에서는 여전히 `CONTINUE MISSION` 버튼을 사용자가 눌러야 다음 큐가 이어지는 것처럼 보였다.
|
||||
|
||||
사용자 관찰:
|
||||
|
||||
- 작업은 일부 완료됨.
|
||||
- 큐에는 아직 작업이 많이 남아 있음.
|
||||
- 헤더 상태가 `IDLE`로 보임.
|
||||
- `CONTINUE MISSION` 버튼이 사용자의 수동 클릭을 기다림.
|
||||
|
||||
## 원인
|
||||
|
||||
프론트엔드 상태 전환에 빈틈이 있었다.
|
||||
|
||||
`AgentDashboard`의 `useEffect`는 `status !== 'running'`일 때 `KnowledgeEngine.stop()`을 호출한다. 그런데 기존 `stop()`은 내부 실행 플래그만 끄는 것이 아니라 항상 Zustand 상태까지 `idle`로 바꿨다.
|
||||
|
||||
그 결과 인증 오류 등으로 `paused` 상태를 유지해야 하는 경우에도 React effect를 지나면서 `paused -> idle`로 바뀌었다. 이렇게 되면 앱은 "복구 후 자동 재개 가능한 일시정지"가 아니라 "사용자가 다시 Continue를 눌러야 하는 대기 상태"처럼 동작했다.
|
||||
|
||||
## 조치
|
||||
|
||||
`src/lib/engine.ts`:
|
||||
|
||||
- `stop(updateStatus = true)` 형태로 변경했다.
|
||||
- 내부 엔진만 멈춰야 할 때는 UI 상태를 덮어쓰지 않도록 했다.
|
||||
|
||||
`src/components/AgentDashboard.tsx`:
|
||||
|
||||
- `status !== 'running'` effect에서는 `engine.stop(false)`를 호출하도록 변경했다.
|
||||
- `status === 'paused'`이고 큐가 남아 있으면 NotebookLM 연결 확인 후 자동으로 `running`으로 되돌리는 auto-resume effect를 추가했다.
|
||||
- 기존 버그로 이미 `idle`에 갇힌 화면도 구제하기 위해, 수동 정지나 작업 완료 로그가 없는 `idle + 남은 큐` 상태도 복구 가능한 멈춤으로 보고 자동 재개하도록 보강했다.
|
||||
- 중복 자동 재개를 막기 위해 `autoResumeRef` 잠금을 추가했다.
|
||||
|
||||
## 검증
|
||||
|
||||
다음 검증을 완료했다.
|
||||
|
||||
```bash
|
||||
npm run lint
|
||||
curl -sS -I http://127.0.0.1:3000
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
결과:
|
||||
|
||||
- TypeScript 검사 통과
|
||||
- 프론트엔드 서버 응답 정상
|
||||
- NotebookLM 브리지 연결 확인 `success: true`
|
||||
|
||||
## 운영 메모
|
||||
|
||||
앞으로 인증 복구나 연결 복구로 인해 `paused` 상태가 되면 앱이 NotebookLM 연결을 확인하고 자동으로 다음 큐를 이어서 실행한다.
|
||||
|
||||
사용자가 직접 `STOP / PAUSE`를 누른 경우는 기존처럼 `idle`로 유지되므로, 수동 정지는 자동 재개 대상이 아니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[React]]
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
# Datacollector Bridge Connection Refused Run Script Fix
|
||||
|
||||
Date: 2026-04-25 21:07:52 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
사용자가 앱 실행 후 `POST http://127.0.0.1:3002/api/check-connection net::ERR_CONNECTION_REFUSED` 오류를 확인했다.
|
||||
이는 NotebookLM 인증 실패가 아니라 MCP Bridge 서버가 실행되지 않아 브라우저가 `3002` 포트에 연결하지 못한 상태였다.
|
||||
|
||||
## Root Cause
|
||||
|
||||
실행 경로가 여러 개였고 일부 경로는 프런트엔드 Vite 서버만 실행했다.
|
||||
|
||||
- `run_mac.command`: Bridge와 Vite를 함께 실행
|
||||
- `run_app.sh`: Vite만 실행
|
||||
- `npm run dev`: Vite만 실행
|
||||
|
||||
따라서 `run_app.sh` 또는 `npm run dev`로 앱을 켜면 UI는 열리지만 `/api/check-connection` 요청을 받을 Bridge 서버가 없어 `ERR_CONNECTION_REFUSED`가 발생했다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/run_app.sh`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/README.md`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/api.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- `run_app.sh`가 Bridge 서버와 Vite 서버를 함께 실행하도록 변경
|
||||
- `run_app.sh` 시작 시 기존 `3000`, `3002` 포트 프로세스를 정리
|
||||
- 종료 시 Bridge 백그라운드 프로세스도 함께 종료하도록 trap 추가
|
||||
- README의 실행 안내를 `npm run dev` 단독에서 `./run_mac.command` 또는 `npm run start-full`로 변경
|
||||
- `src/lib/api.ts`에 `bridgeFetch()` 추가
|
||||
- Bridge 연결 실패 시 `Failed to fetch` 대신 “Bridge 서버가 실행되지 않았다”는 안내 메시지를 표시하도록 변경
|
||||
- `VITE_BRIDGE_URL`로 Bridge 주소를 override할 수 있게 함
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
node --check [[Scripts|Scripts]]/mcp_bridge.mjs
|
||||
npm run lint
|
||||
npm run build
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- 브리지 문법 체크 통과
|
||||
- TypeScript 타입체크 통과
|
||||
- Vite 프로덕션 빌드 통과
|
||||
|
||||
## [[Opera|Opera]]tional Note
|
||||
|
||||
앞으로 앱은 아래 방식으로 실행해야 한다.
|
||||
|
||||
```bash
|
||||
./run_mac.command
|
||||
```
|
||||
|
||||
또는 수동으로 두 서버를 같이 실행한다.
|
||||
|
||||
```bash
|
||||
npm run start-full
|
||||
```
|
||||
|
||||
`npm run dev`만 실행하면 프런트엔드만 뜨므로 NotebookLM, Wiki save, 인증 복구 API가 동작하지 않는다.
|
||||
+177
@@ -0,0 +1,177 @@
|
||||
# Datacollector Codebase Structure Review and Initial Risk [[Assessment|Assessment]]
|
||||
|
||||
Date: 2026-04-25 20:38:01 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
Knowledge Vault: `/Volumes/Data/project/Antigravity/Wiki/00_Raw`
|
||||
|
||||
## Summary
|
||||
|
||||
이 문서는 Datacollector 프로젝트의 첫 구조 파악 및 초기 코드 리뷰 결과를 정리한 기록이다.
|
||||
이번 검토의 목적은 이후 기능 개발 전에 현재 시스템의 책임 분리, 실행 흐름, 외부 의존성, 그리고 우선적으로 손봐야 할 위험 요소를 이해하는 데 있다.
|
||||
|
||||
현재 프로젝트는 단순한 프런트엔드 앱이 아니라, React 기반 UI와 Zustand 상태 저장소, 자율 실행 엔진, 그리고 NotebookLM MCP 및 로컬 LM을 연결하는 Express 브리지 서버가 결합된 자동화 연구 도구 형태로 구성되어 있다.
|
||||
|
||||
## High-Level [[Architecture|Architecture]]
|
||||
|
||||
전체 흐름은 아래와 같다.
|
||||
|
||||
`React UI -> Zustand Store -> KnowledgeEngine -> Express Bridge -> NotebookLM MCP / Local LM / GitHub / Wiki [[Storage|Storage]]`
|
||||
|
||||
핵심 책임 분리는 다음과 같이 이해했다.
|
||||
|
||||
- `src/components/AgentDashboard.tsx`
|
||||
사용자 인터페이스, 미션 시작/중지/재개, 설정 입력, 로그 표시, 수동 커밋 등 상호작용 담당
|
||||
- `src/store/agentStore.ts`
|
||||
앱 전체 설정값과 실행 상태를 보관하는 단일 전역 상태 저장소
|
||||
- `src/lib/engine.ts`
|
||||
큐를 소비하며 연구, 합성, 링크 추출, 다음 토픽 확장을 반복하는 자율 엔진
|
||||
- `src/lib/gemini.ts`
|
||||
NotebookLM 미연결 시 사용하는 로컬 LM 프롬프트 생성 및 응답 파싱
|
||||
- `src/lib/github.ts`
|
||||
결과 Markdown을 GitHub 저장소의 `00_Raw/` 경로로 업로드
|
||||
- `[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
NotebookLM MCP 서버와 통신하는 지속 프로세스형 브리지 서버
|
||||
|
||||
## Execution Flow
|
||||
|
||||
실행 흐름은 다음 순서로 이해했다.
|
||||
|
||||
1. 사용자가 `AgentDashboard`에서 주제를 입력하고 미션을 시작한다.
|
||||
2. 주제와 설정이 `agentStore`에 기록되고 상태가 `running`으로 바뀐다.
|
||||
3. `status` 변경을 감지한 UI가 `KnowledgeEngine` 싱글톤을 시작한다.
|
||||
4. `KnowledgeEngine`는 큐의 첫 항목을 읽고 현재 깊이와 루트 주제를 기준으로 처리 여부를 결정한다.
|
||||
5. NotebookLM 연결 상태가 좋으면 브리지 서버를 통해 리서치와 합성을 수행한다.
|
||||
6. NotebookLM이 없으면 로컬 LM 프록시(`/api/lm`)를 통해 대체 연구를 진행한다.
|
||||
7. 생성된 Markdown에서 위키 링크를 추출해 다음 큐를 구성한다.
|
||||
8. 결과는 pending commits, completed 목록, 로컬 위키 Raw 저장소 등에 반영된다.
|
||||
|
||||
## Current Structure Notes
|
||||
|
||||
이번 시점에서 구조적으로 눈에 띈 특징은 다음과 같다.
|
||||
|
||||
- 상태 관리가 거의 전부 Zustand store 하나에 집중되어 있어 흐름 추적은 쉽다.
|
||||
- 대신 엔진과 UI가 store를 매우 직접적으로 공유해서 결합도가 높다.
|
||||
- NotebookLM 경로와 Local LM 경로가 모두 존재해 fallback 전략은 분명하다.
|
||||
- 브리지 서버가 프런트엔드 백엔드이자 외부 도구 래퍼 역할까지 함께 맡고 있어 책임이 넓다.
|
||||
- 문서 저장 흐름이 GitHub 업로드와 로컬 위키 저장으로 이중화되어 있다.
|
||||
|
||||
## Review Findings
|
||||
|
||||
### 1. Sensitive secrets are persisted in [[Browser|Browser]] storage
|
||||
|
||||
`githubToken`과 `notebookLmCookies`가 Zustand persist 설정에 포함되어 있어 브라우저 localStorage에 평문으로 저장된다.
|
||||
이 방식은 세션 쿠키나 GitHub 토큰 같은 민감 정보의 저장 위치로는 안전하지 않다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
|
||||
영향:
|
||||
|
||||
- 같은 브라우저 프로필을 사용하는 다른 코드나 도구가 정보에 접근할 수 있다.
|
||||
- 장기적으로 토큰 유출 위험이 커진다.
|
||||
|
||||
### 2. Bridge server is exposed too broadly
|
||||
|
||||
브리지 서버는 `0.0.0.0:3002`로 열리고 CORS도 전부 허용한다.
|
||||
또한 `/api/lm`은 클라이언트가 전달한 임의의 URL로 요청을 프록시할 수 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_bridge.mjs`
|
||||
|
||||
영향:
|
||||
|
||||
- 로컬 개발용으로는 편하지만, 같은 네트워크 안에서 예상하지 않은 접근 통로가 될 수 있다.
|
||||
- 사실상 무인증 프록시처럼 동작할 여지가 있다.
|
||||
|
||||
### 3. Environment portability is weak
|
||||
|
||||
MCP 실행 파일 경로와 위키 저장 경로가 절대경로로 하드코딩되어 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_bridge.mjs`
|
||||
|
||||
영향:
|
||||
|
||||
- 다른 개발자 머신, 다른 사용자 계정, 다른 운영체제에서 그대로 실행하기 어렵다.
|
||||
- 배포보다는 특정 개인 작업 환경에 강하게 종속된다.
|
||||
|
||||
### 4. Manual handoff [[State|State]] is not fully cleared
|
||||
|
||||
`resolveManualNext`가 store에 함수 형태로 저장되는데, `clearState()`에서 정리되지 않는다.
|
||||
수동 합성 대기 중 reset 또는 새 미션 시작이 발생하면 상태 꼬임 가능성이 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
|
||||
영향:
|
||||
|
||||
- 이전 미션의 대기 상태가 다음 미션에 잔존할 수 있다.
|
||||
- UI 버튼 상태와 실제 엔진 대기 상태가 어긋날 수 있다.
|
||||
|
||||
### 5. API endpoint usage is duplicated and hardcoded
|
||||
|
||||
프런트엔드에는 이미 Vite 프록시가 설정되어 있지만, UI와 엔진 코드 곳곳에서 `http://127.0.0.1:3002`를 직접 호출하고 있다.
|
||||
|
||||
관련 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/vite.config.ts`
|
||||
|
||||
영향:
|
||||
|
||||
- 포트 변경이나 배포 환경 변경 시 수정 지점이 늘어난다.
|
||||
- 런타임 경로 설정이 한 군데에서 관리되지 않는다.
|
||||
|
||||
## Validation Performed
|
||||
|
||||
이번 검토 중 아래 확인을 수행했다.
|
||||
|
||||
- 저장소 파일 구조 및 진입점 확인
|
||||
- UI, store, engine, bridge, GitHub, Local LM 계층 코드 확인
|
||||
- `npm run lint` 실행
|
||||
|
||||
검증 결과:
|
||||
|
||||
- TypeScript 타입체크는 현재 통과했다.
|
||||
|
||||
## Suggested Next Priorities
|
||||
|
||||
우선순위는 아래 순서가 적절하다.
|
||||
|
||||
1. 민감 정보 저장 방식을 localStorage 바깥으로 이동하거나 최소한 분리
|
||||
2. 브리지 서버 바인딩 범위와 CORS 정책 축소
|
||||
3. 절대경로를 환경변수 또는 설정 파일로 치환
|
||||
4. `resolveManualNext`를 포함한 미션 종료 정리 로직 강화
|
||||
5. API 베이스 URL을 단일 설정 지점으로 통합
|
||||
|
||||
## Working Agreement For Future Notes
|
||||
|
||||
사용자 요청에 따라, 앞으로 Datacollector 관련 조사/분석/리뷰 결과는 가능하면 이 지식 창고 경로에 계속 기록한다.
|
||||
|
||||
기본 원칙:
|
||||
|
||||
- 위치: `/Volumes/Data/project/Antigravity/Wiki/00_Raw`
|
||||
- 파일명: `YYYY-MM-DD-<Project>_<Topic>.md` 또는 기존 저장소 관례와 유사한 읽기 쉬운 영어 제목
|
||||
- 내용: 작업 목적, 파악한 구조, 핵심 발견사항, 다음 액션을 포함
|
||||
|
||||
## Source Files Reviewed
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/README.md`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/package.json`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/vite.config.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/main.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/App.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/gemini.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/github.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_bridge.mjs`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/scripts/mcp_caller.py`
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
# Datacollector - processed 카운터 정체 및 엔진 루프 정지 감시 보강
|
||||
|
||||
- 작성 시각: 2026-04-25 22:52:25 KST
|
||||
- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
- 관련 파일: `src/lib/engine.ts`, `src/components/AgentDashboard.tsx`
|
||||
|
||||
## 상황
|
||||
|
||||
사용자는 작업이 되는 것처럼 보이지만 `processed` 수치가 계속 오르지 않고, 서버를 재시작하면 1개가 추가된 뒤 다시 멈춘 것처럼 보인다고 보고했다.
|
||||
|
||||
## 확인한 내용
|
||||
|
||||
브리지 서버 상태는 정상이고 `/api/health` 기준 `pendingRequests`도 0이었다. 따라서 서버 요청이 계속 물려 있는 문제보다는 프론트엔드 엔진 루프가 한 번 처리한 뒤 다음 반복으로 자연스럽게 이어지지 않는 가능성이 높았다.
|
||||
|
||||
코드상 `processedCount`는 `executeTask()`가 마크다운 생성까지 끝낸 뒤 `store.incrementProcessed()`를 호출할 때만 오른다. 즉 카운터가 오르지 않는다는 것은 다음 중 하나일 가능성이 있다.
|
||||
|
||||
- 다음 작업 합성이 아직 완료되지 않았다.
|
||||
- 프론트엔드 엔진 루프 타이머가 끊겼다.
|
||||
- UI 상태는 `running`인데 엔진 내부 싱글톤의 루프가 실제로는 잠든 상태가 되었다.
|
||||
|
||||
## 조치
|
||||
|
||||
`src/lib/engine.ts`:
|
||||
|
||||
- `isLoopActive`, `lastActivityAt`, `loopTimer`를 추가했다.
|
||||
- `runLoop()` 중복 실행을 막으면서도, 루프가 잠든 경우 다시 깨울 수 있게 했다.
|
||||
- `kickIfStalled()`를 추가해 `running` 상태인데 45초 이상 루프 활동이 없으면 자동으로 다음 루프를 시작한다.
|
||||
- 다음 루프 예약을 `scheduleNextLoop()`로 통합해 타이머를 추적할 수 있게 했다.
|
||||
- 작업 완료 후 `processedCount`가 반영된 값을 로그로 남기도록 했다.
|
||||
|
||||
`src/components/AgentDashboard.tsx`:
|
||||
|
||||
- 상태가 `running`일 때 15초마다 엔진 heartbeat를 실행한다.
|
||||
- 엔진 루프가 잠든 것으로 판단되면 `kickIfStalled()`가 자동으로 다시 깨운다.
|
||||
|
||||
## 검증
|
||||
|
||||
다음 검증을 완료했다.
|
||||
|
||||
```bash
|
||||
npm run lint
|
||||
```
|
||||
|
||||
결과:
|
||||
|
||||
- TypeScript 검사 통과
|
||||
|
||||
## 운영 메모
|
||||
|
||||
이제 작업 하나가 완료될 때 Mission Telemetry에 다음 형태의 로그가 추가된다.
|
||||
|
||||
```text
|
||||
[ENGINE] '토픽명' 처리 카운트 반영 완료: N
|
||||
```
|
||||
|
||||
이 로그가 보이면 `processed` 값도 함께 올라가는 것이 정상이다. 만약 이 로그가 보이지 않고 `최종 데이터 합성 중...` 이후 오래 멈춘다면, 그때는 카운터 문제가 아니라 NotebookLM 합성 요청이 오래 걸리거나 실패 응답을 기다리는 상태로 봐야 한다.
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
# Datacollector Local Wiki Save Only Output Mode
|
||||
|
||||
Date: 2026-04-25 20:50:41 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
Datacollector의 생성 결과 저장 방식을 GitHub 업로드 중심에서 로컬 Wiki 저장 전용으로 정리했다.
|
||||
앞으로 앱에서 생성되는 연구 문서는 `/Volumes/Data/project/Antigravity/Wiki/00_Raw`에 저장되고, Git 업로드는 사용자가 나중에 별도로 한 번에 처리하는 운영 방식으로 둔다.
|
||||
|
||||
## Previous [[Behavior|Behavior]]
|
||||
|
||||
기존 흐름은 결과 생성 후 두 경로가 동시에 존재했다.
|
||||
|
||||
- 로컬 Wiki Raw 폴더에 자동 저장
|
||||
- `pendingCommits`에 결과를 쌓고 UI의 `BATCH COMMIT` 버튼으로 GitHub 업로드 가능
|
||||
|
||||
이 방식은 앱 안에 GitHub 토큰과 저장소 설정을 유지해야 했고, 사용자가 의도하지 않아도 Git 업로드 기능이 계속 노출되는 구조였다.
|
||||
|
||||
## New Behavior
|
||||
|
||||
새 흐름은 다음과 같다.
|
||||
|
||||
1. 연구 결과 Markdown 생성
|
||||
2. `saved[[Reports|Reports]]`에 프리뷰용 로컬 캐시 저장
|
||||
3. 브리지 서버의 `/api/wiki/save`를 통해 `/Volumes/Data/project/Antigravity/Wiki/00_Raw`에 Markdown 파일 저장
|
||||
4. GitHub 업로드 버튼이나 토큰 설정 없이 완료
|
||||
|
||||
GitHub 업로드는 앱이 수행하지 않는다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/store/agentStore.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/engine.ts`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/.env.example`
|
||||
|
||||
삭제 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/lib/github.ts`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- `githubToken`, `githubRepoUrl` 상태 제거
|
||||
- `pendingCommits` 제거
|
||||
- `addPendingCommit`, `clearPendingCommits` 제거
|
||||
- `savedReports`와 `addSavedReport` 추가
|
||||
- `BATCH COMMIT` 버튼 제거
|
||||
- 설정 모달의 GitHub Wiki Sync 섹션 제거
|
||||
- `.env.example`의 GitHub 설정 제거
|
||||
- 생성 결과는 기존 Wiki 저장 API를 통해 로컬 Raw 폴더에만 저장
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
npm run lint
|
||||
npm run build
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- TypeScript 타입체크 통과
|
||||
- Vite 프로덕션 빌드 통과
|
||||
|
||||
## Notes
|
||||
|
||||
로컬 Wiki 저장은 기존 브리지 서버의 `/api/wiki/save` 라우트를 그대로 사용한다.
|
||||
저장 대상 경로는 현재 브리지 서버에 하드코딩된 `/Volumes/Data/project/Antigravity/Wiki/00_Raw`이다.
|
||||
추후 이 경로도 `.env` 설정으로 분리하면 다른 머신이나 폴더 구조에서도 더 쉽게 운영할 수 있다.
|
||||
@@ -0,0 +1,50 @@
|
||||
# Datacollector Mac Windows Launcher [[Scripts|Scripts]]
|
||||
|
||||
Date: 2026-04-25 21:09:42 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
Datacollector 실행 시 Vite 프런트엔드만 뜨고 MCP Bridge 서버가 뜨지 않아 `ERR_CONNECTION_REFUSED`가 발생할 수 있었다.
|
||||
이를 막기 위해 맥용과 윈도우용 실행 파일을 명확히 정리했다.
|
||||
|
||||
## Main Launchers
|
||||
|
||||
- macOS: `/Volumes/Data/project/Antigravity/Datacollector/run_mac.command`
|
||||
- Windows: `/Volumes/Data/project/Antigravity/Datacollector/run_win.bat`
|
||||
|
||||
두 실행 파일 모두 아래를 수행한다.
|
||||
|
||||
1. 프로젝트 폴더로 이동
|
||||
2. `node_modules`가 없으면 `npm install`
|
||||
3. 기존 `3000`, `3002` 포트 프로세스 정리
|
||||
4. MCP Bridge 서버 실행
|
||||
5. Vite 앱 실행
|
||||
|
||||
## Compatibility Wrappers
|
||||
|
||||
기존 실행 파일과의 호환성을 위해 아래 파일은 메인 실행 파일로 위임하도록 단순화했다.
|
||||
|
||||
- `run_app.sh` -> `run_mac.command`
|
||||
- `run_app.bat` -> `run_win.bat`
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
bash -n run_mac.command
|
||||
bash -n run_app.sh
|
||||
npm run lint
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- macOS shell script 문법 통과
|
||||
- TypeScript 타입체크 통과
|
||||
|
||||
## [[Opera|Opera]]tional Note
|
||||
|
||||
앞으로 맥에서는 `run_mac.command`, 윈도우에서는 `run_win.bat`만 실행하면 된다.
|
||||
`npm run dev` 단독 실행은 프런트엔드만 켜므로 NotebookLM, Wiki save, 인증 복구 API가 동작하지 않는다.
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
# Datacollector - NotebookLM 인증 브라우저 유지 및 오래된 .env 쿠키 우선순위 문제 해결
|
||||
|
||||
- 작성 시각: 2026-04-25 21:31:00 KST
|
||||
- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
- 관련 파일: `[[Scripts|Scripts]]/mcp_bridge.mjs`, `auth_mac.command`, `auth_win.bat`, `.env.example`
|
||||
|
||||
## 상황
|
||||
|
||||
앱에서 `/api/check-connection` 호출이 500으로 실패했고, 화면에는 다음과 같은 메시지가 반복되었다.
|
||||
|
||||
- `Authentication expired`
|
||||
- `인증 자동 복구 실패. 브라우저 로그인이 필요한 상태일 수 있습니다.`
|
||||
- `MCP initialized: true, pending: 0`
|
||||
|
||||
사용자는 NotebookLM 인증 중 [[Chrome|Chrome]]이 열렸다가 닫히는 점을 보고, 인증 브라우저를 유지해야 하는 것 아니냐고 질문했다.
|
||||
|
||||
## 확인한 내용
|
||||
|
||||
`notebooklm-mcp-auth` 소스 확인 결과, 기본 자동 실행 모드는 인증 후 자신이 띄운 Chrome 프로세스를 종료한다. 반면 `--no-auto-launch --port ... --user-data-dir ...` 모드는 이미 떠 있는 Chrome 디버깅 세션에 붙기 때문에 인증 브라우저를 유지할 수 있다.
|
||||
|
||||
브리지에서 Chrome을 유지하도록 바꾼 뒤 인증 CLI는 성공했다. 하지만 MCP 서버의 `notebook_list`는 여전히 `Authentication expired`를 반환했다.
|
||||
|
||||
추가 확인 결과, `.env`에 예전 `NOTEBOOKLM_COOKIES` 값이 남아 있었다. `scripts/mcp_bridge.mjs`가 `dotenv/config`를 로드한 뒤 MCP 서버를 자식 프로세스로 실행하면서 이 오래된 환경변수 쿠키가 `~/.notebooklm-mcp/auth.json`의 최신 인증 캐시보다 우선 적용되고 있었다.
|
||||
|
||||
즉 실제 핵심 원인은 다음 조합이었다.
|
||||
|
||||
- 인증 CLI는 최신 쿠키를 `~/.notebooklm-mcp/auth.json`에 정상 저장함.
|
||||
- 브리지는 `.env`의 오래된 `NOTEBOOKLM_COOKIES`를 MCP 자식 프로세스에 전달함.
|
||||
- MCP 서버는 캐시 파일보다 환경변수를 우선 사용함.
|
||||
- 결과적으로 새 인증 후에도 MCP는 계속 오래된 쿠키로 NotebookLM API를 호출함.
|
||||
|
||||
## 조치
|
||||
|
||||
`scripts/mcp_bridge.mjs`에서 기본적으로 MCP 자식 프로세스와 인증 CLI 자식 프로세스에 `NOTEBOOKLM_COOKIES`, `NOTEBOOKLM_CSRF_TOKEN`, `NOTEBOOKLM_SESSION_ID`를 넘기지 않도록 수정했다.
|
||||
|
||||
명시적으로 환경변수 인증을 사용해야 할 경우에는 `.env`에 아래 값을 둔다.
|
||||
|
||||
```env
|
||||
USE_NOTEBOOKLM_ENV_AUTH="true"
|
||||
```
|
||||
|
||||
기본값은 `false`이며, 이 경우 `notebooklm-mcp-auth`가 생성한 `~/.notebooklm-mcp/auth.json` 캐시를 우선 사용한다.
|
||||
|
||||
또한 `auth_mac.command`, `auth_win.bat`는 별도 Chrome 프로필과 디버깅 포트를 사용해 NotebookLM 인증 브라우저를 열어두는 방식으로 변경했다.
|
||||
|
||||
## 검증
|
||||
|
||||
다음 검증을 완료했다.
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
결과:
|
||||
|
||||
```json
|
||||
{"success":true,"count":0}
|
||||
```
|
||||
|
||||
직접 Python MCP 클라이언트로도 같은 인증 캐시를 사용해 `list_notebooks` 호출이 성공했고, 노트북 89개를 읽는 것을 확인했다.
|
||||
|
||||
## 운영 메모
|
||||
|
||||
앞으로는 `.env`에 오래된 `NOTEBOOKLM_COOKIES`가 남아 있어도 기본 브리지 실행에는 영향을 주지 않는다. 다만 혼란을 줄이려면 장기적으로 `.env`에서 `NOTEBOOKLM_COOKIES` 줄을 삭제하거나 주석 처리하는 것이 좋다.
|
||||
|
||||
NotebookLM 인증용 Chrome 창은 닫지 않는 것이 좋다. 인증이 풀렸을 때 브리지가 같은 디버깅 포트의 Chrome 세션에 붙어 자동 복구를 시도할 수 있다.
|
||||
+85
@@ -0,0 +1,85 @@
|
||||
# Datacollector NotebookLM Automatic Auth Recovery
|
||||
|
||||
Date: 2026-04-25 20:47:05 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
컴퓨터 포맷 이후 NotebookLM MCP 인증이 자주 실패하고, 20-30분마다 `auth_mac.command`를 수동 실행해야 하는 문제가 있었다.
|
||||
이번 작업에서는 인증 만료 시 브리지 서버가 자동으로 복구를 시도하도록 개선했다.
|
||||
|
||||
## Root Cause Hypothesis
|
||||
|
||||
기존 구조는 MCP 서버의 `refresh_auth` 도구 호출에만 의존했다.
|
||||
하지만 포맷 이후 로컬 토큰 저장 위치나 [[Chrome|Chrome]] 세션 상태가 달라지면서 `refresh_auth`만으로 복구되지 않는 상황이 발생할 수 있다.
|
||||
|
||||
사용자가 직접 실행하던 파일은 다음 명령의 래퍼였다.
|
||||
|
||||
```bash
|
||||
/Users/g1nation_mac/.local/bin/notebooklm-mcp-auth
|
||||
```
|
||||
|
||||
따라서 자동 복구 흐름에도 이 CLI 인증 명령을 포함시키는 것이 가장 직접적인 개선 방향이다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/.env.example`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- 브리지 서버가 `.env`를 읽도록 `dotenv/config`를 추가했다.
|
||||
- `AUTH_PATH`, `AUTH_ARGS`, `AUTH_TIMEOUT_MS`, `AUTH_REFRESH_INTERVAL_MS` 설정을 추가했다.
|
||||
- MCP 인증 에러 발생 시 `refresh_auth`를 먼저 시도한다.
|
||||
- `refresh_auth` 실패 시 MCP 프로세스를 재시작하고 다시 갱신을 시도한다.
|
||||
- 그래도 실패하면 `notebooklm-mcp-auth` CLI를 브리지 서버가 직접 실행한다.
|
||||
- CLI 인증 후 MCP 프로세스를 재시작해 새 토큰을 읽게 만든다.
|
||||
- 장시간 실행 중에는 15분 간격으로 요청이 없는 시점에 인증 상태를 사전 갱신한다.
|
||||
- UI 안내 문구를 수동 재인증 중심에서 자동 복구 중심으로 수정했다.
|
||||
|
||||
## Runtime [[Behavior|Behavior]]
|
||||
|
||||
새 인증 복구 순서:
|
||||
|
||||
1. NotebookLM MCP 요청 실패
|
||||
2. 에러 메시지가 인증 관련인지 판단
|
||||
3. `refresh_auth` 호출
|
||||
4. MCP 프로세스 재시작 후 `refresh_auth` 재시도
|
||||
5. `notebooklm-mcp-auth` CLI 자동 실행
|
||||
6. MCP 프로세스 재시작
|
||||
7. 원래 실패했던 NotebookLM 요청 재시도
|
||||
|
||||
주기적 갱신:
|
||||
|
||||
- 기본 간격: 15분
|
||||
- 설정값: `AUTH_REFRESH_INTERVAL_MS=900000`
|
||||
- 진행 중인 MCP 요청이 있을 때는 건드리지 않고 건너뛴다.
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
npm run bridge
|
||||
curl -s http://127.0.0.1:3002/api/health
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- `node --check` 통과
|
||||
- TypeScript 타입체크 통과
|
||||
- 브리지 서버 시작 성공
|
||||
- MCP 서버 초기화 성공
|
||||
- `/api/health`에서 `connected: true`, `version: 3.3.0`, `authPath` 확인
|
||||
|
||||
## Notes
|
||||
|
||||
완전히 백그라운드 인증이 가능한지는 Google/Chrome 세션 상태에 의존한다.
|
||||
브라우저 로그인이 만료되어 실제 사용자 로그인이 필요한 상태라면 자동 CLI 실행도 브라우저 로그인을 요구할 수 있다.
|
||||
다만 기존처럼 매번 사용자가 batch 파일을 직접 실행하는 흐름보다, 일반적인 토큰 만료와 MCP refresh 실패 상황은 브리지 서버가 먼저 복구하도록 개선되었다.
|
||||
+60
@@ -0,0 +1,60 @@
|
||||
# Datacollector - NotebookLM 자동 재인증 검증 강화 및 동시 복구 잠금
|
||||
|
||||
- 작성 시각: 2026-04-25 22:17:33 KST
|
||||
- 프로젝트: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
- 관련 파일: `[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
|
||||
## 상황
|
||||
|
||||
인증 브라우저 유지와 오래된 `.env` 쿠키 우선순위 문제를 해결한 뒤에도, 실제 작업 중 인증이 풀렸을 때 완전히 자동으로 재인증되지 않는 문제가 남아 있었다.
|
||||
|
||||
화면에서는 작업은 진행되지만 사용자가 기대한 "인증 만료 감지 -> 자동 재인증 -> 원래 작업 재시도" 흐름이 안정적으로 보장되지 않았다.
|
||||
|
||||
## 원인
|
||||
|
||||
브리지에는 자동 복구 로직이 있었지만 두 가지 빈틈이 있었다.
|
||||
|
||||
- `refresh_auth` 호출이 성공해도 실제 NotebookLM API 호출이 가능한지 검증하지 않았다.
|
||||
- `/api/re-auth`와 `/api/check-connection` 같은 요청이 동시에 들어오면 각각 MCP 재시작과 인증 복구를 시도해서 프로세스 재시작 경합이 생길 수 있었다.
|
||||
|
||||
추가로 인증 오류 판별 문자열에 `expired`, `RPC Error 16`, `csrf`, `만료` 같은 케이스가 충분히 포함되지 않아 일부 인증 만료 메시지가 일반 오류로 처리될 가능성이 있었다.
|
||||
|
||||
## 조치
|
||||
|
||||
`scripts/mcp_bridge.mjs`에서 다음을 수정했다.
|
||||
|
||||
- 재인증 성공 기준을 `refresh_auth` 성공이 아니라 실제 `notebook_list` 호출 성공으로 강화했다.
|
||||
- 인증 만료 감지 시 `refreshAuth({ allowExternalAuth: true })`를 통해 자동 CLI 인증 복구까지 이어지도록 정리했다.
|
||||
- 주기적 인증 점검도 필요 시 외부 인증 CLI 복구를 허용하도록 변경했다.
|
||||
- `_refreshAuthPromise` 잠금을 추가해 동시 재인증/재시작 요청이 서로 충돌하지 않게 했다.
|
||||
- 인증 오류 감지 키워드에 `expired`, `rpc error 16`, `csrf`, `unauthorized`, `forbidden`, `인증`, `만료`를 추가했다.
|
||||
|
||||
## 검증
|
||||
|
||||
다음 검증을 완료했다.
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/re-auth
|
||||
curl -sS -X POST http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
결과:
|
||||
|
||||
- `/api/re-auth`: `success: true`
|
||||
- `/api/check-connection`: `success: true`
|
||||
|
||||
또한 `/api/re-auth`와 `/api/check-connection`을 동시에 호출해도 둘 다 성공하는 것을 확인했다.
|
||||
|
||||
## 운영 메모
|
||||
|
||||
이제 인증이 풀린 상태에서 NotebookLM MCP 호출이 인증 오류를 반환하면 브리지가 다음 순서로 자동 복구한다.
|
||||
|
||||
1. MCP의 `refresh_auth` 실행
|
||||
2. 실제 `notebook_list` 호출로 인증 유효성 검증
|
||||
3. 실패 시 MCP 프로세스 재시작 후 재검증
|
||||
4. 그래도 실패하면 `notebooklm-mcp-auth` CLI 실행
|
||||
5. 인증 캐시 정리 후 MCP 재시작 및 실제 호출 검증
|
||||
|
||||
NotebookLM 브라우저 세션이 완전히 로그아웃된 상태라면 자동 CLI도 브라우저 로그인을 요구할 수 있다. 이 경우 사용자가 열린 NotebookLM [[Chrome|Chrome]] 창에서 로그인만 해두면 이후 자동 복구가 다시 이어질 수 있다.
|
||||
+84
@@ -0,0 +1,84 @@
|
||||
# Datacollector NotebookLM Connection Guard and MCP Restart Fix
|
||||
|
||||
Date: 2026-04-25 21:02:35 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
실행 중 NotebookLM 연결 체크가 500 에러를 반환한 뒤에도 미션이 계속 시작되어 Local LM fallback으로 넘어가고, 결국 `Local LM returned an empty or invalid response` 에러가 발생했다.
|
||||
또한 브리지의 MCP 재시작 로직에서 자동 재시작과 수동 재시작이 겹쳐 여러 `notebooklm-mcp` 프로세스가 남는 문제가 확인되었다.
|
||||
|
||||
## Observed Errors
|
||||
|
||||
브라우저 콘솔:
|
||||
|
||||
```text
|
||||
:3000/favicon.ico 404 (Not Found)
|
||||
127.0.0.1:3002/api/check-connection 500 (Internal Server Error)
|
||||
```
|
||||
|
||||
앱 로그:
|
||||
|
||||
```text
|
||||
NotebookLM 연결 실패: 인증 자동 복구 실패...
|
||||
GENERAL MODE
|
||||
ENGINE ERROR Local LM returned an empty or invalid response.
|
||||
```
|
||||
|
||||
## Root Causes
|
||||
|
||||
1. `testNotebookLmConnection()`이 성공 여부를 반환하지 않았다.
|
||||
2. `handleStart`, `handleResume`, `handleGlobalResume`이 연결 실패 후에도 그대로 `running` 상태로 넘어갔다.
|
||||
3. `restart()`가 MCP 프로세스 종료 이벤트를 기다리지 않고 바로 새 프로세스를 띄울 수 있었다.
|
||||
4. `close` 이벤트의 자동 재시작이 수동 재시작과 겹쳐 MCP 하위 프로세스가 누적될 수 있었다.
|
||||
5. favicon 파일이 없어서 브라우저가 `/favicon.ico` 기본 요청을 404로 표시했다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/index.html`
|
||||
|
||||
추가 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/public/favicon.svg`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- `testNotebookLmConnection()`이 `Promise<boolean>`을 반환하도록 변경
|
||||
- NotebookLM 연결 실패 시 신규 미션 시작, 개별 재개, 전체 재개를 보류
|
||||
- 연결 실패 후 Local LM fallback으로 자동 진행되는 흐름 차단
|
||||
- MCP 프로세스를 종료할 때 `close` 이벤트를 기다리는 `_stopCurrentProcess()` 추가
|
||||
- 재시작 중 자동 재시작이 중복 실행되지 않도록 제어
|
||||
- 재시작 테스트 후 MCP 하위 프로세스가 하나만 남는지 확인
|
||||
- SVG favicon 추가 및 `index.html`에 명시
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
npm run build
|
||||
npm run bridge
|
||||
curl -s http://127.0.0.1:3002/api/health
|
||||
curl -s -X POST http://127.0.0.1:3002/api/restart
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- 브리지 문법 체크 통과
|
||||
- TypeScript 타입체크 통과
|
||||
- Vite 빌드 통과
|
||||
- 브리지 시작 성공
|
||||
- `/api/health` 응답 정상
|
||||
- `/api/restart` 후 `notebooklm-mcp` 프로세스가 하나만 남는 것 확인
|
||||
|
||||
## [[Opera|Opera]]tional Note
|
||||
|
||||
현재 실행 중이던 오래된 브리지와 누적된 MCP 하위 프로세스는 종료했다.
|
||||
앱은 다시 실행해야 새 브리지 로직이 적용된다.
|
||||
+70
@@ -0,0 +1,70 @@
|
||||
# Datacollector NotebookLM Progress Visibility and Auth Diagnosis
|
||||
|
||||
Date: 2026-04-25 21:17:24 KST
|
||||
Project: Datacollector
|
||||
[[Repository|Repository]]: `/Volumes/Data/project/Antigravity/Datacollector`
|
||||
|
||||
## Summary
|
||||
|
||||
사용자가 UI에서 `NotebookLM 연결 상태 점검 중...` 로그만 반복되고 실제 진행 상황을 알 수 없다고 보고했다.
|
||||
확인 결과 앱이 프로젝트 생성 단계까지 가지 못하고 있었으며, 원인은 NotebookLM 연결 확인 단계에서 MCP 인증이 만료 상태로 판단되기 때문이었다.
|
||||
|
||||
## Observed [[State|State]]
|
||||
|
||||
확인한 상태:
|
||||
|
||||
- Vite 서버 `3000` 실행 중
|
||||
- MCP Bridge 서버 `3002` 실행 중
|
||||
- `notebooklm-mcp` 프로세스 실행 중
|
||||
- `/api/health` 응답 가능
|
||||
- `/api/check-connection`은 NotebookLM 인증 만료 오류 반환
|
||||
|
||||
브리지 로그상 자동 인증 CLI는 [[Chrome|Chrome]]을 열고 로그인 및 토큰 추출까지 수행했다.
|
||||
그러나 MCP 서버는 이후에도 `Authentication expired`로 판단하여 NotebookLM notebook list 호출에 실패했다.
|
||||
|
||||
## Changes Made
|
||||
|
||||
수정 파일:
|
||||
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/[[Scripts|Scripts]]/mcp_bridge.mjs`
|
||||
- `/Volumes/Data/project/Antigravity/Datacollector/src/components/AgentDashboard.tsx`
|
||||
|
||||
핵심 변경:
|
||||
|
||||
- MCP 초기화 타임아웃 추가: `MCP_INIT_TIMEOUT_MS`
|
||||
- NotebookLM 연결 확인 타임아웃 추가: `MCP_HEALTH_TIMEOUT_MS`
|
||||
- `/api/health`에 상세 상태 추가
|
||||
- `initialized`, `processRunning`, `processPid`, `pendingRequests`, `authStatus` 노출
|
||||
- 인증 CLI 진행 단계(`starting`, `running`, `restarting`, `success`, `failed`) 추적
|
||||
- UI 연결 점검 중 5초마다 Bridge/MCP/auth 진행 상태 로그 출력
|
||||
- 중복 연결 점검 요청은 기존 Promise를 재사용하도록 변경
|
||||
|
||||
## Verification
|
||||
|
||||
실행한 검증:
|
||||
|
||||
```bash
|
||||
node --check scripts/mcp_bridge.mjs
|
||||
npm run lint
|
||||
npm run build
|
||||
curl -sS --max-time 5 http://127.0.0.1:3002/api/health
|
||||
curl -sS --max-time 25 -X POST -H 'Content-Type: application/json' -d '{}' http://127.0.0.1:3002/api/check-connection
|
||||
```
|
||||
|
||||
검증 결과:
|
||||
|
||||
- 브리지 문법 체크 통과
|
||||
- TypeScript 타입체크 통과
|
||||
- Vite 빌드 통과
|
||||
- Bridge/MCP 프로세스는 실행됨
|
||||
- NotebookLM 연결 확인은 인증 만료 오류로 실패
|
||||
|
||||
## Current Diagnosis
|
||||
|
||||
현재 문제는 앱 실행이나 Bridge 연결 문제가 아니라 NotebookLM MCP 인증 상태 문제다.
|
||||
자동 인증 CLI가 토큰을 저장해도 MCP 서버가 계속 만료로 판단하므로, 다음 단계에서는 NotebookLM MCP 패키지의 인증 저장 형식 또는 권장 인증 방식(`--file` 모드 등)을 확인해야 한다.
|
||||
|
||||
## [[Opera|Opera]]tional Note
|
||||
|
||||
확인용으로 실행했던 Bridge/Vite/MCP 프로세스는 종료했다.
|
||||
새 진행 상태 로그를 보려면 앱을 `run_mac.command`로 다시 실행해야 한다.
|
||||
+181
@@ -0,0 +1,181 @@
|
||||
# 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
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Affordance]]
|
||||
* [[Blocking]]
|
||||
* [[Events]]
|
||||
* [[Purpose]]
|
||||
* [[State]]
|
||||
+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` 탭 선택 시 왼쪽 패널과 콘텐츠가 겹치지 않는지 확인한다.
|
||||
- 전투 보상 텍스트가 화면 가장자리에서 잘리지 않는지 확인한다.
|
||||
+109
@@ -0,0 +1,109 @@
|
||||
# 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 장비 카드가 더 이상 빈 회색 박스처럼 보이지 않고 아이템 정보를 명확히 보여주는지 확인한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Storage]]
|
||||
+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 이펙트를 더 세분화할지 결정한다.
|
||||
+176
@@ -0,0 +1,176 @@
|
||||
# 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`에 자연스럽게 추가되는지 확인한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Storage]]
|
||||
+137
@@ -0,0 +1,137 @@
|
||||
# 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이 최종 침공군답게 가장 강한 물량과 화력을 보여주는지 확인한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Testing]]
|
||||
+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장 순차 오픈 또는 희귀도 보상으로 확장할지 플레이테스트 후 결정한다.
|
||||
@@ -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 위에 추가한다.
|
||||
@@ -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,32 @@
|
||||
# 📜 2026-04-30 회사 대화록
|
||||
|
||||
_모든 명령·분배·산출물·대화가 시간순으로 누적됩니다. 두뇌가 자동 인덱싱·동기화합니다._
|
||||
|
||||
## [16:07:45] 👤 **사용자**
|
||||
|
||||
[모닝 브리핑] 오늘 날짜는 2026-04-30입니다. 회사 목표(goals.md)와 지금까지의 의사결정 로그를 바탕으로 오늘 우리 회사가 우선순위로 처리해야 할 작업 3가지를 결정하고, 각 작업을 적절한 에이전트에게 분배하세요.
|
||||
|
||||
## [16:28:10] 🧭 **CEO** · _작업 분배_
|
||||
|
||||
회사 목표와 로그가 초기화 상태이므로, 시장 분석을 통한 닉슈 선정 → 수익화 전략 및 KPI 도출 → 일일/주간 실행 계획 수립 순으로 3가지 우선 작업을 정의합니다.
|
||||
|
||||
**할당:**
|
||||
- 🔍 **[[Research|Research]]er**: AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개월 내 진입 가능한 최적의 1개 닉슈와 핵심 타깃 키워드 5개를 정리해 보고하세요.
|
||||
- 💰 **[[business|business]]**: re[[Search|Search]]er의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안하고, 월별 조회수·구독자·변환율 목표를 포함한 KPI 프레임워크와 가격/수익 구조를 1페이지 분량으로 작성하세요.
|
||||
- 📱 **secretary**: 리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전트·진행 상태를 명시한 데일리 브리핑과 1주일 액션 플랜을 텔레그램 보고 형식으로 출력하세요.
|
||||
|
||||
## [16:33:10] 🔍 **[[researcher|researcher]]** · _AI/기술/콘텐츠 관련 상위 3개 시장 트렌드와 주요 경쟁 채널의 성장 패턴을 분석한 후, 우리 회사가 1개_
|
||||
|
||||
⚠️ Researcher 에이전트 호출 실패: aborted
|
||||
|
||||
## [16:37:31] 👤 **사용자**
|
||||
|
||||
[자율 사이클 — 2026-04-30] 사용자가 자리를 비웠습니다. 회사 목표·각 에이전트의 개인 목표(_agents/{id}/[[goal|goal]].md)·최근 의사결정·메모리를 검토해서 지금 가장 가치 있는 단일 작업 1개를 결정하고, 적절한 1~2명 에이전트에게 분배해서 실행하세요. 같은 산출물을 반복하지 마세요 — 메모리에 비슷한 항목이 24시간 내에 있으면 다른 각도로 진전시키세요.
|
||||
|
||||
## [16:38:10] 💰 **Business** · _researcher의 분석 결과를 기반으로 초기 수익화 모델(광고/스폰서/디지털 제품 중 1개 선택)을 제안_
|
||||
|
||||
⚠️ Business 에이전트 호출 실패: aborted
|
||||
|
||||
## [16:43:10] 📱 **Secretary** · _리서치와 비즈니스 전략 결과를 종합해 오늘 하루의 핵심 작업 3가지를 최종 확정하고, 마감 시간·담당 에이전_
|
||||
|
||||
⚠️ Secretary 에이전트 호출 실패: aborted
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-D7150244
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# AI-Human Discussion Log
|
||||
|
||||
## Topic
|
||||
Project Chronicle Guard sidebar Designer menu and Markdown record system.
|
||||
|
||||
## User Request Summary
|
||||
The user wants a Designer menu in the sidebar and a staged implementation of a project planning, decision, and development record system.
|
||||
|
||||
## AI Questions
|
||||
|
||||
### Question
|
||||
No blocking question was asked.
|
||||
|
||||
### Reason
|
||||
The current workspace, project root, and a reasonable record location were available from local context.
|
||||
|
||||
### Impact On Decision
|
||||
The first implementation can proceed with `ConnectAI` as the active project and `docs/records/ConnectAI` as the planning record location.
|
||||
|
||||
## Main Discussion
|
||||
The feature should not replace code generation or existing agent execution. It should sit beside those features as a recording and decision support layer.
|
||||
|
||||
## Decisions
|
||||
- Use an independent `src/features/projectChronicle` module.
|
||||
- Add a sidebar Designer control similar to existing Brain and Agent controls.
|
||||
- Keep the MVP file-based and Markdown-only.
|
||||
- Do not implement full automatic transcript capture in the first stage.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Blocking]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Support]]
|
||||
* [[_system]]
|
||||
* [[decisions]]
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-5B04311B
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Feedback Response
|
||||
|
||||
## Purpose
|
||||
Improve Chronicle Guard behavior after testing showed the assistant still answered like a general idea proposer instead of a project planning and record guard.
|
||||
|
||||
## Feedback Summary
|
||||
The tested response understood the broad idea, but missed key guard behaviors:
|
||||
- Project target check
|
||||
- Record path check
|
||||
- Question intent and question reasons
|
||||
- Pending decision candidates
|
||||
- Low-dependency MVP first
|
||||
- Candidate records at the end
|
||||
- Plain engineering tone
|
||||
|
||||
## Implementation Summary
|
||||
- Made Chronicle Guard context apply by default unless explicitly disabled from the webview payload.
|
||||
- Strengthened the Guard response contract for new ideas and feature requests.
|
||||
- Added required response order: summary, intent, project check, record path check, blocking questions, question reasons, direction review, MVP, later expansion, candidate records.
|
||||
- Added decision policy so unconfirmed decisions stay pending.
|
||||
- Added tone rules against inflated consulting language and premature Vector DB / relational DB / knowledge graph suggestions.
|
||||
- Extracted Guard prompt generation into `buildProjectChronicleGuardContext`.
|
||||
- Added tests that lock the most important Guard rules.
|
||||
- Added base system prompt guidance to prefer practical MVP-first answers for product and architecture discussions.
|
||||
|
||||
## Changed Files
|
||||
- `src/features/projectChronicle/guardPrompt.ts`
|
||||
- `src/features/projectChronicle/index.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `src/utils.ts`
|
||||
- `tests/projectChronicleGuardPrompt.test.ts`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
Chronicle Guard should now behave less like a general ideation assistant and more like a project planning, decision, and record guard.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Behavior]]
|
||||
* [[Blocking]]
|
||||
* [[Index]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
* [[Testing]]
|
||||
* [[_system]]
|
||||
* [[decisions]]
|
||||
+66
@@ -0,0 +1,66 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-D4A6E581
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Stage 1
|
||||
|
||||
## Purpose
|
||||
Add the first stable stage of the Designer menu and Project Chronicle Guard without coupling it tightly to chat execution.
|
||||
|
||||
## Implementation Summary
|
||||
- Added an independent `src/features/projectChronicle` module.
|
||||
- Added typed project, planning, discussion, decision, development, bug, and retrospective records.
|
||||
- Added a Markdown writer with folder creation and filename collision protection.
|
||||
- Added templates for project seed files and record documents.
|
||||
- Added a Designer row in the sidebar with project selection and explicit record actions.
|
||||
- Added VS Code-side handlers for creating/selecting record projects and writing planning, development, and bug records.
|
||||
|
||||
## Architecture
|
||||
|
||||
```text
|
||||
Sidebar Designer UI
|
||||
-> Webview postMessage
|
||||
-> SidebarChatProvider handlers
|
||||
-> ProjectChronicleManager
|
||||
-> MarkdownFileWriter
|
||||
-> docs/records/{Project}/...
|
||||
```
|
||||
|
||||
## Changed Files
|
||||
- `src/features/projectChronicle/types.ts`
|
||||
- `src/features/projectChronicle/markdownFileWriter.ts`
|
||||
- `src/features/projectChronicle/templates.ts`
|
||||
- `src/features/projectChronicle/index.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `docs/records/ConnectAI/...`
|
||||
|
||||
## Dependency Notes
|
||||
The implementation uses only TypeScript, Node `fs`/`path`, and VS Code extension APIs already available in the project.
|
||||
|
||||
## Verification
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Known Limits
|
||||
- The records are generated through explicit sidebar actions.
|
||||
- Full automatic conversation analysis is not implemented in this stage.
|
||||
- Retrospective and ADR writing are available in the module, but the sidebar only exposes Plan, Dev, and Bug actions in this first pass.
|
||||
|
||||
## Next Development Notes
|
||||
- Add a richer Designer panel for ADR, discussion, and retrospective creation.
|
||||
- Capture AI question intent more directly during the conversation flow.
|
||||
- Add tests for the Project Chronicle manager.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Analysis]]
|
||||
* [[Architecture]]
|
||||
* [[Index]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
* [[Seed]]
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-A3F62F03
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Stage 2
|
||||
|
||||
## Purpose
|
||||
Expand the Designer menu from basic Plan/Dev/Bug writing into a fuller MVP record writer.
|
||||
|
||||
## Implementation Summary
|
||||
- Reworked the Designer sidebar controls into a project selector plus a record type selector.
|
||||
- Added explicit write flows for discussion, decision, and retrospective records.
|
||||
- Preserved the existing planning, development, and bug writers.
|
||||
- Added question intent capture in the discussion writer through optional prompts.
|
||||
- Added ADR numbering for decision records and timeline updates for every record type.
|
||||
- Expanded tests to verify all major record categories are written to their expected folders.
|
||||
|
||||
## Design Adjustment
|
||||
The first pass exposed separate buttons for Plan, Dev, and Bug. Stage 2 changes this to a more scalable pattern:
|
||||
|
||||
```text
|
||||
Designer Project Selector
|
||||
Record Type Selector
|
||||
Write / Open / Add actions
|
||||
```
|
||||
|
||||
This keeps the sidebar usable as more record types are added.
|
||||
|
||||
## Changed Files
|
||||
- `src/sidebarProvider.ts`
|
||||
- `tests/projectChronicle.test.ts`
|
||||
- `docs/records/ConnectAI/development/2026-05-02_project-chronicle-guard_stage-2_implementation.md`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
The Designer menu can now create the MVP record types:
|
||||
- Planning
|
||||
- Discussion
|
||||
- Decision
|
||||
- Development
|
||||
- Bug
|
||||
- Retrospective
|
||||
|
||||
## Next Development Notes
|
||||
- Add a dedicated Designer panel for editing richer record content before writing.
|
||||
- Add automatic conversation event capture so records can be generated with less manual input.
|
||||
- Add settings for default record detail level and automatic timeline behavior.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Behavior]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-718C7EBB
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Project Chronicle Guard Stages 3 to 5
|
||||
|
||||
## Purpose
|
||||
Complete the remaining MVP support around Designer mode, record browsing, and project configuration persistence.
|
||||
|
||||
## Stage 3: Chronicle Guard Mode
|
||||
- Added a `Guard` toggle in the sidebar header.
|
||||
- When enabled, active Designer project context is injected into the agent system context.
|
||||
- The guard context asks the assistant to summarize requests, infer intent, explain blocking questions, identify decisions, and name records that should be written.
|
||||
- The mode is restored through webview state.
|
||||
|
||||
## Stage 4: Record Browser
|
||||
- Added a record list selector for generated Chronicle Markdown files.
|
||||
- Added refresh and open actions for selected records.
|
||||
- Added record listing to `ProjectChronicleManager`.
|
||||
- Added path validation before opening selected Markdown records.
|
||||
|
||||
## Stage 5: Project Config File
|
||||
- Added `chronicle.config.json` generation under each project record root.
|
||||
- The config file stores project id, project name, root, record root, description, purpose, detail level, and timestamps.
|
||||
- This gives the record folder its own portable project metadata, independent of VS Code global state.
|
||||
|
||||
## Changed Files
|
||||
- `src/agent.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `src/features/projectChronicle/index.ts`
|
||||
- `src/features/projectChronicle/types.ts`
|
||||
- `tests/projectChronicle.test.ts`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
The staged MVP is now functionally complete:
|
||||
- Select or create Designer project
|
||||
- Generate project record structure
|
||||
- Persist project config
|
||||
- Enable Chronicle Guard response mode
|
||||
- Write all MVP record types
|
||||
- Browse and open generated Markdown records
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Blocking]]
|
||||
* [[Browser]]
|
||||
* [[Index]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
* [[State]]
|
||||
* [[Support]]
|
||||
* [[_system]]
|
||||
* [[decisions]]
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-EC4DA38B
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Second Brain Trace Collapsible UI
|
||||
|
||||
## Purpose
|
||||
Reduce visual noise from Second Brain Trace details while keeping the evidence available when the user wants to inspect it.
|
||||
|
||||
## Implementation Summary
|
||||
- Wrapped Second Brain Trace output in a collapsed HTML `<details>` block.
|
||||
- Added a compact summary line showing usage status and note counts.
|
||||
- Kept detailed referenced notes, unused notes, grounding metrics, and debug JSON inside the expanded section.
|
||||
- Updated tests to verify the collapsible structure is rendered.
|
||||
|
||||
## Changed Files
|
||||
- `src/features/secondBrainTrace.ts`
|
||||
- `tests/secondBrainTrace.test.ts`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
Trace evidence is still available, but it no longer dominates every answer by default.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[Noise]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
id: P-REINFORCE-WIKI-18722064
|
||||
category: Unified
|
||||
confidence_score: 0.95
|
||||
tags: ['architecture-principles']
|
||||
last_reinforced: 2026-05-02
|
||||
---
|
||||
|
||||
# Development Log: Second Brain Trace Mode
|
||||
|
||||
## Purpose
|
||||
Make Second Brain usage visible and testable in AI answers.
|
||||
|
||||
## Implementation Summary
|
||||
- Added `src/features/secondBrainTrace.ts`.
|
||||
- Added trace scoring over active Second Brain Markdown files.
|
||||
- Added user-facing trace Markdown with usage status, referenced documents, unused documents, and grounding metrics.
|
||||
- Added debug JSON output when debug mode is enabled.
|
||||
- Added Trace and Dbg sidebar buttons.
|
||||
- Connected trace context into `AgentExecutor`.
|
||||
- Added tests for retrieval, rendering, debug JSON, and no-use cases.
|
||||
|
||||
## Changed Files
|
||||
- `src/features/secondBrainTrace.ts`
|
||||
- `src/agent.ts`
|
||||
- `src/sidebarProvider.ts`
|
||||
- `tests/secondBrainTrace.test.ts`
|
||||
- `docs/records/ConnectAI/planning/2026-05-02_second-brain-trace-mode.md`
|
||||
- `docs/records/ConnectAI/development/2026-05-02_second-brain-trace-mode_implementation.md`
|
||||
|
||||
## Verification
|
||||
- `./node_modules/.bin/tsc --noEmit`
|
||||
- `npm run compile`
|
||||
- `./node_modules/.bin/jest --runInBand`
|
||||
|
||||
## Result
|
||||
When Trace mode is on, answers can now include:
|
||||
- 2nd Brain usage status
|
||||
- Reason for use or non-use
|
||||
- Referenced note paths and excerpts
|
||||
- Searched but unused notes
|
||||
- Retrieval and grounding metrics
|
||||
- Optional debug JSON
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts (Auto-Linked)
|
||||
* [[Architecture]]
|
||||
* [[P-Reinforce]]
|
||||
* [[Principles]]
|
||||
* [[Purpose]]
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
category: Unified
|
||||
tags: [category-index, project_logs]
|
||||
title: Project Logs Directory
|
||||
last_updated: 2026-05-02
|
||||
---
|
||||
|
||||
# Project Logs Directory
|
||||
|
||||
이 문서는 `Project_Logs` 카테고리에 속한 모든 지식 문서들의 목록을 제공합니다.
|
||||
|
||||
## 📄 문서 목록
|
||||
- [[2026-04-15]] : [[2026-04-15|2026-04-15]]
|
||||
- [[2026-04-21-Engine-Stability-and-Optimization]] : Engine Stability and Optimization (2026-04-21)
|
||||
- [[2026-04-21-Implementation-and-Architecture-Report]] : Skybound Implementation and Architecture Report (V10.5)
|
||||
- [[2026-04-21-Project-Report-V11.5-Combat-and-UI-Recovery]] : Project Report V11.5: Combat and UI Recovery (2026-04-21)
|
||||
- [[2026-04-21-UX-Dopamine-Feedback-Upgrade]] : UX and Dopamine Feedback Upgrade (V10.0)
|
||||
- [[2026-04-21_Stability_and_Optimization_Report]] : ⚡ Skybound: Stability & [[Optimization|Optimization]] Report (2026-04-21)
|
||||
- [[2026-04-22_Boss_Battle_System_Implementation]] : [TECH-REPORT] Skybound Boss Battle Architecture (v1.0)
|
||||
- [[2026-04-22_Boss_Spawn_Logic_Fix]] : 📝 [Technical Report] 보스 스폰 시스템 안정화 및 AI 교전 로직 개선
|
||||
- [[2026-04-22_Engine_Logic_Optimization_Report]] : ⚙️ Engine Logic Optimization & Modernization
|
||||
- [[2026-04-22_Engine_Stability_Audit]] : 🔍 Skybound 엔진 구조 정밀 감사 보고서 (V12.1)
|
||||
- [[2026-04-23_Engine_Stabilization_Report]] : ISSUE REPORT: [v13.1] Engine Stabilization & Tactical Boundary Overhaul
|
||||
- [[2026-04-23_Post-Mortem_Loot_Rebalance]] : POST-MORTEM: Skybound Meta-Game Stabilization & Loot Economy Overhaul (2026-04-23)
|
||||
- [[2026-04-24-Skybound_Code_Structure_Audit_and_Stabilization_Plan]] : Skybound Code Structure Audit and Stabilization Plan
|
||||
- [[2026-04-24-Skybound_Final_Stylized_Casual_Magitech_Redirection]] : Skybound Final Stylized Casual Magitech Redirection
|
||||
- [[2026-04-24-Skybound_HUD_and_TAC_LevelUp_Stylized_Casual_Magitech_Fix]] : Skybound HUD and TAC Level Up Stylized Casual Magitech Fix
|
||||
- [[2026-04-24-Skybound_Nova_Burst_Icon_and_Effect_Fix]] : Skybound Nova Burst Icon and Effect Fix
|
||||
- [[2026-04-24-Skybound_Particle_and_Supply_Readability_Fix]] : Skybound Particle and Supply Readability Fix
|
||||
- [[2026-04-24-Skybound_Semirealistic_Magitech_Fantasy_Redirection]] : Skybound Semirealistic Magitech Fantasy Redirection
|
||||
- [[2026-04-24-Skybound_Stylized_Casual_Magitech_Art_Pack]] : Skybound Semirealistic Magitech Fantasy Art Pack
|
||||
- [[2026-04-24-Skybound_Stylized_Casual_Magitech_Ingame_Asset_Fix]] : Skybound Stylized Casual Magitech Ingame Asset Fix
|
||||
- [[2026-04-24-Skybound_Survivor_Like_Balance_Curve_Pass]] : Skybound Survivor-Like Balance Curve Pass
|
||||
- [[2026-04-25-Datacollector_Auto_Resume_After_Reauth_Fix]] : Datacollector - 인증 복구 후 자동 재개 상태 전환 수정
|
||||
- [[2026-04-25-Datacollector_Bridge_Connection_Refused_Run_Script_Fix]] : Datacollector Bridge Connection Refused Run Script Fix
|
||||
- [[2026-04-25-Datacollector_Codebase_Structure_Review_and_Initial_Risk_Assessment]] : Datacollector Codebase Structure Review and Initial Risk [[Assessment|Assessment]]
|
||||
- [[2026-04-25-Datacollector_Engine_Processed_Count_and_Stalled_Loop_Guard]] : Datacollector - processed 카운터 정체 및 엔진 루프 정지 감시 보강
|
||||
- [[2026-04-25-Datacollector_Local_Wiki_Save_Only_Output_Mode]] : Datacollector Local Wiki Save Only Output Mode
|
||||
- [[2026-04-25-Datacollector_Mac_Windows_Launcher_Scripts]] : Datacollector Mac Windows Launcher [[Scripts|Scripts]]
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Auth_Browser_and_Stale_Env_Cookie_Fix]] : Datacollector - NotebookLM 인증 브라우저 유지 및 오래된 .env 쿠키 우선순위 문제 해결
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Automatic_Auth_Recovery]] : Datacollector NotebookLM Automatic Auth Recovery
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Automatic_Reauth_Verification_and_Lock]] : Datacollector - NotebookLM 자동 재인증 검증 강화 및 동시 복구 잠금
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Connection_Guard_and_MCP_Restart_Fix]] : Datacollector NotebookLM Connection Guard and MCP Restart Fix
|
||||
- [[2026-04-25-Datacollector_NotebookLM_Progress_Visibility_and_Auth_Diagnosis]] : Datacollector NotebookLM Progress Visibility and Auth Diagnosis
|
||||
- [[2026-04-25-Skybound_Core_Gameplay_Rebalance_and_Purpose_Reset]] : Skybound Core Gameplay Rebalance and Purpose Reset
|
||||
- [[2026-04-25-Skybound_Player_Airframe_and_8Stage_Boss_Continuity_Rework]] : Skybound Player Airframe and 8 Stage Boss Continuity Rework
|
||||
- [[2026-04-25-Skybound_Skill_Concept_and_Hangar_Layout_Overlap_Fix]] : Skybound Skill Concept and Hangar Layout Overlap Fix
|
||||
- [[2026-04-25-Skybound_TacExp_DirectKill_and_UI_Productization_Pass]] : Skybound Tac EXP Direct Kill and UI Productization Pass
|
||||
- [[2026-04-25-Skybound_Vampire_Survivors_Loop_and_Stage_Curve_Preparation]] : Skybound Vampire Survivors Loop and Stage Curve Preparation
|
||||
- [[2026-04-26-Skybound_Enemy_Motion_Damage_Pressure_and_Projectile_Visual_Pass]] : Skybound Enemy Motion Damage Pressure and Projectile Visual Pass
|
||||
- [[2026-04-26-Skybound_HP_Scarcity_and_Module_Cache_Rewards]] : Skybound HP Scarcity and Module Cache Rewards
|
||||
- [[2026-04-26-Skybound_Invasion_Response_Stage_Difficulty_Curve]] : Skybound Invasion Response Stage Difficulty Curve
|
||||
- [[2026-04-26-Skybound_Low_Level_First_Upgrade_Offer_Balance]] : Skybound Low Level First Upgrade Offer Balance
|
||||
- [[2026-04-26-Skybound_Miniboss_Treasure_Cache_Reward_Loop]] : Skybound Miniboss Treasure Cache Reward Loop
|
||||
- [[2026-04-26-Skybound_Player_Sprite_Path_Warning_Fix]] : Skybound Player Sprite Path Warning Fix
|
||||
- [[2026-04-26-Skybound_Reward_Card_Clarity_and_Command_Cache_UI]] : Skybound Reward Card Clarity and Command Cache UI
|
||||
- [[2026-04-26-Skybound_Skill_Slot_Limit_Weapon5_Passive5]] : Skybound Skill Slot Limit Weapon 5 Passive 5
|
||||
- [[2026-04-26-Skybound_Skip_Upgrade_and_Weapon_Transform_Reconfiguration]] : Skybound Skip Upgrade and Weapon Transform Reconfiguration
|
||||
- [[2026-04-26-Skybound_Stage1_to_3_Playtest_Balance_Bomb_and_Visual_Diversity_Pass]] : Skybound Stage 1 to 3 Playtest Balance Bomb and Visual Diversity Pass
|
||||
- [[2026-04-26-Skybound_Stage_Miniboss_Pattern_Differentiation]] : Skybound Stage Miniboss Pattern Differentiation
|
||||
- [[2026-04-30]] : 📜 2026-04-30 회사 대화록
|
||||
- [[2026-05-01]] : 📜 2026-05-01 회사 대화록
|
||||
- [[2026-05-02_project-chronicle-guard]] : AI-Human Discussion Log
|
||||
- [[2026-05-02_project-chronicle-guard_feedback-response]] : Development Log: Project Chronicle Guard Feedback Response
|
||||
- [[2026-05-02_project-chronicle-guard_stage-1_implementation]] : Development Log: Project Chronicle Guard Stage 1
|
||||
- [[2026-05-02_project-chronicle-guard_stage-2_implementation]] : Development Log: Project Chronicle Guard Stage 2
|
||||
- [[2026-05-02_project-chronicle-guard_stage-3-to-5_implementation]] : Development Log: Project Chronicle Guard Stages 3 to 5
|
||||
- [[2026-05-02_second-brain-trace-collapsible-ui]] : Development Log: Second Brain Trace Collapsible UI
|
||||
- [[2026-05-02_second-brain-trace-mode_implementation]] : Development Log: Second Brain Trace Mode
|
||||
Reference in New Issue
Block a user