Refactor: Consolidate directory structure into 5 main categories and update metadata
This commit is contained in:
Antigravity Agent
@@ -1,41 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
현대 프론트엔드 디버깅은 런타임 에러 포착, 성능 병목 진단, 상태 불일치 해결을 아우르는 체계적인 분석 과정이다. 브라우저 개발자 도구(Chrome DevTools)를 통한 로컬 분석부터 Sentry, Datadog과 같은 관측성(Observability) 플랫폼을 활용한 프로덕션 모니터링까지 통합적인 접근을 통해 시스템의 신뢰성을 확보한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **프로덕션 관측성 (Observability Platforms)**
|
||||
- Sentry, LogRocket 등을 통한 실시간 에러 그룹화 및 사용자 여정(Breadcrumbs) 추적.
|
||||
- **세션 리플레이(Session Replay)**: 에러 발생 전의 사용자 조작과 상태 변화를 시각적으로 재현하여 재현 불가능한 버그 차단.
|
||||
- **분산 트레이싱**: 프론트엔드 에러와 백엔드 트레이스 ID를 연결하여 엔드-투-엔드 문제 진단.
|
||||
2. **메모리 누수 진단 (Memory Profiling)**
|
||||
- Chrome DevTools의 **Heap Snapshots**을 비교하여 분리된 DOM 노드(Detached DOM nodes)와 가비지 컬렉션(GC)되지 않는 객체 식별.
|
||||
- **Allocation Timelines**: 메모리 할당 시점과 리테이너 경로(Retainer paths)를 분석하여 객체 보존 원인 파악.
|
||||
3. **상태 및 렌더링 디버깅**
|
||||
- **Time-travel Debugging**: Redux DevTools 등을 통해 상태 변화를 기록하고 특정 시점으로 액션을 재생하여 비동기 버그 추적.
|
||||
- **Error Boundaries**: React의 렌더링 에러를 선언적으로 포착하여 전체 앱 크래시를 방지하고 에러 스택 정보를 확보.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **로깅 오버헤드**: 과도한 로깅 및 관측성 도구 도입은 번들 사이즈 증가와 런타임 성능 저하를 유발할 수 있으므로 샘플링 전략이 필요하다.
|
||||
- **데이터 프라이버시**: 세션 리플레이 및 클라우드 로깅 시 사용자 민감 정보(비밀번호, PII)가 노출되지 않도록 엄격한 마스킹 처리가 선행되어야 한다.
|
||||
- **디버깅 도구의 제약**: React Context 등 특정 상태 관리 모델은 전용 디버깅 툴의 부재로 인해 문제 추적이 상대적으로 어렵다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **Heap Snapshots**: 자바스크립트 메모리 구조의 정적 분석 도구 (관계: 메모리 진단 핵심)
|
||||
- **Error Boundaries**: 런타임 에러 전파를 차단하는 선언적 격리 장치 (관계: 안정성 확보)
|
||||
- **Time-Travel Debugging**: 상태 불일치 원인을 규명하는 시계열 분석 기법 (관계: 비동기 로직 검증)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. OpenTelemetry를 활용하여 프론트엔드와 마이크로서비스 백엔드 간의 트레이스 컨텍스트를 어떻게 안전하게 전파하는가?
|
||||
2. Heap Snapshot 분석 시 'Shallow Size'와 'Retained Size'의 차이가 의미하는 가비지 컬렉션의 실제 작동 원리는?
|
||||
3. 세션 리플레이 도구가 캔버스(Canvas)나 WebGL 기반 렌더링의 상호작용을 어떻게 기록하고 재현하는가?
|
||||
4. 프로덕션 환경에서 소스 맵(Source Map) 노출 없이 에러 스택을 정확히 복구하는 보안 가이드라인은?
|
||||
5. 메모리 리테이너 경로 분석을 통해 발견된 '클로저(Closure)에 의한 메모리 누수'를 해결하는 코드 패턴은?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **이슈 재현성 확보**: 고객사에서 보고된 불분명한 오류를 LogRocket 리플레이로 확인하여 재현 단계 생략.
|
||||
- **성능 튜닝**: 장시간 실행되는 대시보드 앱의 메모리 누수를 Allocation Timeline으로 추적하여 수정.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Performance Profiling (Lighthouse / Core Web Vitals)**
|
||||
- **Static Application Security Testing (SAST)**
|
||||
- **Unit & Integration Testing Strategies**
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# NDF (Neutral Data Format)
|
||||
|
||||
## 📌 Brief Summary
|
||||
NDF(Neutral Data Format)는 EugenSystems가 개발한 독자적인 텍스트 기반 스크립트 언어 및 데이터 포맷입니다 [1]. [[WARNO|WARNO]]의 게임 동작과 유닛의 세부 데이터를 저장하는 데 사용되며, 게임 코드와 데이터 값을 엄격히 분리하여 수천 개에 달하는 속성을 체계적으로 관리할 수 있게 합니다 [1, 2]. 이는 시뮬레이션의 '유전적 청사진' 역할을 수행하며, 게임 소스 코드의 수정 없이도 정교한 데이터 기반 밸런싱과 모딩을 가능하게 하는 핵심 기반입니다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
- **NDF의 구조와 객체 지향적 특성**
|
||||
NDF 파일은 텍스트 기반의 프로그래밍 형식을 띠며, 상속과 모듈화가 고도로 발달된 객체 지향적인 특성을 지니고 있습니다 [1]. 구조적 설계의 대표적인 예로, `UniteDescriptor.ndf` 파일 내의 개별 유닛 엔티티는 단일 데이터로 존재하는 것이 아니라 외형 모듈(ApparenceModel), 보급 모듈(TSupplyModuleDescriptor), 생존 모듈(THealthModuleDescriptor) 등 독립적인 기능을 수행하는 여러 디스크립터(Descriptor)들을 조립하는 방식으로 정교하게 구축됩니다 [1].
|
||||
|
||||
- **주요 NDF 파일과 담당 시뮬레이션 영역**
|
||||
WARNO의 모든 논리적 설계는 수천 개의 `.ndf` 파일에 나뉘어 정의되어 있습니다 [1, 2]. 가장 핵심적인 파일들은 다음과 같습니다:
|
||||
* `UniteDescriptor.ndf`: 유닛의 물리적 및 기술적 속성(가격, 시야, 이동성, 은신값 등)을 정의합니다 [3, 4].
|
||||
* `WeaponDescriptor.ndf`: 포탑 회전 속도, 조준 시간 등 무기 체계의 메커니즘을 설정합니다 [3, 4].
|
||||
* `Ammunition.ndf`: 철갑탄(AP) 관통력, 고폭탄(HE) 데미지, 제압력 등 탄약의 물리적 타격 로직을 담고 있습니다 [3, 4].
|
||||
* `Divisions.ndf` 및 `DivisionRules.ndf`: 사단 덱을 구성할 때 적용되는 카드당 유닛 수와 전략적 가용성 규칙을 제어합니다 [4, 5].
|
||||
|
||||
- **데이터 기반 밸런싱 및 모딩의 핵심 동력**
|
||||
NDF 시스템이 제공하는 고도의 유연성은 WARNO 특유의 '데이터 기반 밸런싱(Data-Driven Balancing)'을 가능케 합니다 [4]. 개발자와 모더들은 일반적인 텍스트 편집기나 전용 도구(WME: Warno Mod Editor)를 사용하여 게임 소스코드 변형 없이 유닛 성능 데이터를 즉각적으로 튜닝할 수 있습니다 [1, 5, 6]. 또한, `[[ndf-parse|ndf-parse]]`와 같은 Python 패키지를 활용하면 NDF 파일을 자동으로 파싱하고 수정 사항을 유효한 NDF 코드로 다시 기록하는 작업도 수행할 수 있습니다 [7].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[데이터 기반 설계 (Data-Driven Design)|데이터 기반 설계(Data-Driven Design]], Iriszoom 엔진, [[WARNO 모딩(Modding)|WARNO 모딩(Modding]]
|
||||
- **Projects/Contexts:** [[WARNO-DATA 프로젝트|WARNO-DATA 프로젝트]], ndf-parse 패키지, [[Warno-Armory|Warno-Armory]]
|
||||
- **Contradictions/Notes:** [[Eugen Systems|Eugen Systems]]는 공식적인 모딩 매뉴얼과 `.ndf` 참조 가이드를 통해 파일 형식을 설명하고 있지만, 수천 개의 파일에 분산된 실제 데이터 속성값에 대한 상세한 설명은 제공하지 않습니다 [2]. 이로 인해 유저 커뮤니티가 주도하여 WARNO-DATA 위키를 개설하거나, 데이터를 파싱해 숨겨진 스탯을 보여주는 War-Yes, [[Warno-Armory|Warno-Armory]] 등의 서드파티 도구를 개발하여 공식 문서의 빈틈을 메우고 있습니다 [2, 8].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,46 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
Naming Conventions(명명 규칙)은 코드의 가독성, 유지보수성, 그리고 협업 효율성을 높이기 위해 파일, 컴포넌트, 변수 등의 이름을 짓는 합의된 표준이다. 명확한 규칙을 통해 코드의 역할을 직관적으로 파악하게 하며, 특히 운영체제 간의 대소문자 구분 차이로 인한 빌드 오류를 방지하는 실질적인 엔지니어링 목적을 갖는다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **파일 및 폴더 (kebab-case)**
|
||||
- 대소문자 구분이 없는 OS(Windows, macOS)와 엄격한 OS(Linux) 간의 CI/CD 빌드 충돌을 막기 위해 소문자와 하이픈을 사용하는 `kebab-case`를 권장한다.
|
||||
- Next.js의 예약어(`page.js`, `layout.js`)나 라우트 그룹(`(folder)`) 등의 규칙을 준수한다.
|
||||
2. **React 컴포넌트 및 타입 (PascalCase)**
|
||||
- 컴포넌트명과 TypeScript의 Type/Interface, Enum 등은 첫 글자를 대문자로 하는 `PascalCase`를 사용하여 일반 변수와 구별한다.
|
||||
3. **변수, 함수, 프로퍼티 (camelCase)**
|
||||
- JavaScript 표준에 따라 첫 단어는 소문자로 시작하는 `camelCase`를 사용한다.
|
||||
- Boolean 값은 `is`, `has`, `should` 접두사를, 이벤트 핸들러는 `handle`, `on` 접두사를 붙여 의미를 명확히 한다.
|
||||
4. **커스텀 훅 (use 접두사)**
|
||||
- React의 Rules of Hooks를 준수하기 위해 반드시 `use` 접두사로 시작하는 `camelCase`를 사용한다.
|
||||
5. **상수 (UPPER_SNAKE_CASE)**
|
||||
- 변경되지 않는 고정 값은 대문자와 밑줄을 사용하는 `UPPER_SNAKE_CASE`로 작성하여 식별력을 높인다.
|
||||
6. **Git 및 워크플로우**
|
||||
- 브랜치명: `{type}/{ticket-id}-{description}` 형식의 소문자 kebab-case 사용.
|
||||
- 커밋 메시지: Conventional Commits(`feat:`, `fix:` 등) 형식을 준수하여 추적성을 확보한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **엄격함 vs 유연성**: 너무 복잡한 네이밍 규칙은 개발자의 인지 부하를 늘리고 생산성을 저하시킬 수 있으므로, 팀 규모에 맞는 적절한 수준의 합의가 필요하다.
|
||||
- **자동화 도구의 한계**: ESLint 등으로 많은 네이밍 규칙을 강제할 수 있으나, '의미론적(Semantic) 적절성'까지는 도구가 판단할 수 없으므로 여전히 코드 리뷰가 중요하다.
|
||||
- **프레임워크 제약**: 사용 중인 프레임워크(예: Next.js)의 예약어 규칙이 팀의 컨벤션과 충돌할 경우, 프레임워크의 규칙을 우선시해야 시스템 오류를 방지할 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **kebab-case**: 파일 시스템 호환성을 위한 소문자-하이픈 조합 (관계: 물리적 저장 표준)
|
||||
- **Conventional Commits**: 변경 이력 가독성을 위한 표준 (관계: 협업 워크플로우 규칙)
|
||||
- **PascalCase**: 컴포넌트 및 타입 식별을 위한 대문자 시작 조합 (관계: 논리적 식별 표준)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. OS별 대소문자 인식 차이가 실제 프로덕션 빌드 환경에서 유발하는 'Silent failure' 사례와 그 디버깅 방법은?
|
||||
2. 네이밍 규칙 준수가 TypeScript의 타입 추론 성능이나 트리 쉐이킹(Tree Shaking) 효율에 간접적인 영향을 미치는가?
|
||||
3. 대규모 리팩토링 시, 기존의 네이밍 컨벤션을 일괄 변경하기 위한 AST(Abstract Syntax Tree) 기반 자동화 도구 활용 방안은?
|
||||
4. `isVisible` vs `showComponent`와 같이 상태 중심 네이밍과 명령 중심 네이밍 중 어떤 것이 유지보수에 더 유리한가?
|
||||
5. 다국어 지원(i18n) 프로젝트에서 키값(Key) 네이밍을 도메인 중심으로 짓는 것과 페이지 중심으로 짓는 것의 트레이드오프는?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **협업 환경 구축**: ESLint 및 Prettier 설정을 통해 팀원 전체가 동일한 네이밍 케이스를 사용하도록 자동 강제.
|
||||
- **이슈 추적**: 브랜치명에 티켓 ID를 포함하여 Jira/GitHub Issues와 코드를 유기적으로 연결.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Clean Code & Meaningful Names**
|
||||
- **Feature-Sliced Design (FSD)**
|
||||
- **Git Branching Strategies**
|
||||
@@ -1,41 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
리팩토링(Refactoring)은 소프트웨어의 외부 동작을 변경하지 않으면서 내부 구조, 가독성, 모듈성을 개선하는 정교한 공학적 작업이다. React 환경에서는 비대한 컴포넌트 분할, 커스텀 훅을 통한 로직 추출, 그리고 기술 부채 상환을 위한 점진적 마이그레이션을 통해 시스템의 확장성과 유지보수성을 극대화하는 것을 목표로 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **점진적 마이그레이션 (Refactor, Do Not Rewrite)**
|
||||
- 전체 시스템을 한 번에 재작성하는 위험을 피하고, 기능 단위나 도메인 단위로 하나씩 새로운 아키텍처로 옮긴다.
|
||||
2. **커스텀 훅을 통한 로직 추출**
|
||||
- 비대한 컴포넌트 내의 데이터 패칭, 폼 처리, 복잡한 계산 로직을 커스텀 훅으로 추출하여 UI와 비즈니스 로직을 분리한다.
|
||||
- 이를 통해 독립적이고 빠른 단위 테스트(Unit Testing) 환경을 확보한다.
|
||||
3. **안전망으로서의 테스트 구축**
|
||||
- 리팩토링 전 기존 기능의 동작을 보장하는 테스트 수트를 먼저 작성하여, 변경으로 인한 기능 파손을 즉각 탐지한다.
|
||||
4. **구조적 표준화 및 거버넌스**
|
||||
- 클래스형 컴포넌트를 함수형으로 전환하고, TypeScript를 도입하여 정적 안정성을 강화한다.
|
||||
- ESLint 및 Prettier 등 자동화 도구를 통해 팀의 코드 컨벤션과 아키텍처 규칙을 강제한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **단기 생산성 저하**: 리팩토링은 당장의 비즈니스 기능 추가보다 많은 시간을 소요할 수 있으므로, 적절한 일정 조율과 경영진의 합의가 필요하다.
|
||||
- **과도한 추상화의 위험**: 리팩토링 과정에서 DRY 원칙에만 집착하여 만든 지나치게 복잡한 추상화는 오히려 코드 가독성을 해칠 수 있다(KISS 원칙과의 충돌).
|
||||
- **마이그레이션 중단의 위험**: 부분적인 리팩토링이 완료되지 않고 중단될 경우, 시스템 내에 두 가지 이상의 서로 다른 패턴이 혼재되어 유지보수 난이도가 상승할 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **Custom Hooks**: 로직 분리의 물리적 단위 (관계: 실천 도구)
|
||||
- **Incremental Migration**: 안전한 아키텍처 전환 전략 (관계: 핵심 방법론)
|
||||
- **Unit Testing**: 리팩토링의 안전을 보장하는 장치 (관계: 필수 선행 조건)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. 리팩토링 과정에서 기존의 통합 테스트(E2E)를 유지하면서 내부 로직을 단위 테스트로 분리해 나가는 최적의 프로세스는?
|
||||
2. 300줄 이상의 거대 컴포넌트를 분할할 때, 상태(State) 전달을 위해 Prop Drilling을 감수할 것인가, 아니면 전역 상태로 승격할 것인가에 대한 판단 기준은?
|
||||
3. 리팩토링 중 발견된 레거시 코드의 '잠재적 버그'를 즉시 수정할 것인가, 아니면 리팩토링 완료 후 별도 작업으로 처리할 것인가?
|
||||
4. 아키텍처 캡슐화(FSD 등)가 리팩토링 시 사이드 이펙트를 물리적으로 차단하는 구체적인 메커니즘은?
|
||||
5. 성능 리팩토링 시, 가독성 좋은 코드와 고성능(메모이제이션 남발 등) 코드 사이의 적절한 타협점은 어디인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **레거시 코드 현대화**: 오래된 React 프로젝트의 기술 스택(Redux -> Zustand 등) 및 컴포넌트 스타일 개선.
|
||||
- **지속적 품질 관리**: 기능 추가 전후로 관련 모듈을 SRP 원칙에 맞게 정돈하여 기술 부채 누적 방지.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Software Engineering Principles (SOLID)**
|
||||
- **Technical Debt Management**
|
||||
- **Automated Governance & Linting**
|
||||
@@ -1,45 +0,0 @@
|
||||
## 📌 Brief Summary
|
||||
리팩토링(Refactoring)은 소프트웨어의 외부 동작을 유지하면서 내부 구조를 개선하여 코드베이스의 건강함과 유지보수성을 확보하는 전문적인 개발 과정이다. 낡은 패러다임을 현대화하고 책임을 분리하며, 강력한 테스트 안전망을 구축함으로써 기술 부채를 상환하고 시스템의 복잡도를 제어하는 것을 목표로 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
1. **리팩토링 철학: 점진적 마이그레이션**
|
||||
- 위험이 큰 전면 재작성 대신, 기능 단위로 하나씩 새로운 아키텍처로 옮기는 점진적 방식을 취한다.
|
||||
- 이를 통해 시스템 현대화 중에도 신규 기능 개발을 지속할 수 있다.
|
||||
2. **React 리팩토링의 핵심: 커스텀 훅**
|
||||
- 비대한 UI 컴포넌트에서 비즈니스 로직을 추출하여 커스텀 훅으로 분리한다.
|
||||
- UI와 로직의 분리를 통해 모듈성을 높이고, 독립적이고 빠른 단위 테스트(Unit Testing) 환경을 확보한다.
|
||||
3. **실무적 개선 기법**
|
||||
- 클래스형 컴포넌트의 함수형 전환, JavaScript의 TypeScript 마이그레이션.
|
||||
- 불필요한 `useEffect` 제거 및 서버 상태 관리(TanStack Query) 도입.
|
||||
- DRY(중복 제거) 및 YAGNI(불필요 기능 제거) 원칙을 통한 코드 정리.
|
||||
4. **표준화 및 거버넌스**
|
||||
- CSS 작성 방식 표준화, 폴더 구조(FSD 등) 재정렬, 직관적 네이밍 적용.
|
||||
- ESLint 등 자동화 도구를 통해 팀의 모범 사례를 강제한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
- **마이그레이션 과도기 복잡성**: 구형과 신규 패턴이 공존하는 기간 동안 시스템의 일관성이 일시적으로 깨질 수 있으며, 개발자의 인지 부하가 증가한다.
|
||||
- **테스트 부재의 위험**: 충분한 테스트 안전망 없이 진행되는 리팩토링은 오히려 예기치 못한 회귀(Regression) 오류를 유발할 수 있다.
|
||||
- **과도한 추상화**: 중복 제거(DRY)에 너무 집착할 경우, 오히려 코드가 복잡해져 이해하기 어려워지는 'KISS 원칙 위반' 사례가 발생할 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
### Related Concepts
|
||||
- **Incremental Migration**: 안전한 아키텍처 전환 전략 (관계: 핵심 방법론)
|
||||
- **Custom Hooks**: 로직 분리의 기본 단위 (관계: 실천 도구)
|
||||
- **Unit Testing**: 리팩토링의 안정성 보장 (관계: 필수 전제 조건)
|
||||
- **Feature-Sliced Design (FSD)**: 캡슐화를 통한 부작용 차단 (관계: 구조적 목표)
|
||||
|
||||
### Deeper Research Questions
|
||||
1. 대규모 리팩토링 시 구/신규 아키텍처 공존 기간을 최소화하기 위한 'Feature Toggle' 활용 방안은?
|
||||
2. 테스트 코드가 전혀 없는 레거시 시스템에서 '안전한 리팩토링'을 시작하기 위한 최소한의 테스트 전략은?
|
||||
3. 순환 복잡도를 줄이기 위한 조건문 리팩토링(Guard Clauses 등)이 React JSX 내부 구조에 미치는 영향은?
|
||||
4. 리팩토링 중 발견된 '기존의 의도된 버그(Legacy Bug)'를 처리하는 아키텍처적 의사결정 기준은?
|
||||
5. AI 도구(LLM)를 활용한 대규모 코드 리팩토링 시, 로직 변질 여부를 자동으로 검증하는 파이프라인 구축 방법은?
|
||||
|
||||
### Practical Application Contexts
|
||||
- **기술 부채 상환**: 스파게티 코드로 변한 레거시 프로젝트의 구조 개선 및 현대화.
|
||||
- **시스템 안정성 강화**: 잦은 에러가 발생하는 모듈을 SRP 원칙에 따라 분해하고 테스트 코드를 보강.
|
||||
|
||||
### Adjacent Topics
|
||||
- **Technical Debt Management**
|
||||
- **Clean Code & Code Smells**
|
||||
- **SOLID Principles**
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# War-Yes
|
||||
|
||||
## 📌 Brief Summary
|
||||
War-Yes(war-yes.com)는 실시간 전술 게임 [[WARNO|WARNO]]의 유닛 데이터를 브라우징, 검색, 필터링 및 비교할 수 있도록 유저가 제작한 웹사이트입니다 [1]. 인게임 유닛 카드에서 제공하는 스탯뿐만 아니라 게임 내에서는 확인할 수 없는 숨겨진 수치(hidden values)를 제공하여 커뮤니티의 데이터 분석을 돕습니다 [2]. 이 도구를 통해 플레이어들은 명중률 곡선 시각화 및 세부 메커니즘 정보를 활용해 유닛 간의 상대적인 성능을 정밀하게 비교할 수 있습니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **웹사이트 개발 및 주요 기능:** War-Yes는 게임 내 제한적인 유닛 비교 기능의 불편함을 해소하기 위해 만들어졌습니다 [1]. 개발자는 AI 텍스트 파서를 이용해 유닛 카드 데이터를 추출했으며, 모바일 환경에서도 쉽게 유닛 데이터를 이해하고 유닛들을 차트로 비교할 수 있도록 강력한 검색 및 필터링 기능을 제공합니다 [1, 4].
|
||||
* **숨겨진 스탯(Hidden Stats) 및 메커니즘 분석:** 인게임 아머리(Armory) 화면에서는 볼 수 없는 게임 엔진 내부의 수치를 파싱하여 제공합니다 [2, 5]. 대표적으로 숨겨진 명중률 곡선을 시각화하여 보여주거나 [3], ECM 및 명중률 계산 공식 등 게임 밸런스에 직결되는 지식들을 제공하여 유저들이 데이터를 기반으로 전술적 분석을 할 수 있게 지원합니다 [6, 7].
|
||||
* **커뮤니티 생태계 역할:** War-Yes는 단순한 데이터베이스를 넘어 전용 Discord 서버를 운영하고 있습니다 [8]. 이 공간에서 캐주얼하게 게임을 즐기는 유저들이 모여 사이트의 버그나 새로운 기능에 대한 피드백을 주고받으며, 게임 생태계에 적극적으로 참여하고 있습니다 [8, 9].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Warno-Armory|Warno-Armory]], 숨겨진 수치 (Hidden Stats
|
||||
- **Projects/Contexts:** WARNO 커뮤니티 데이터 분석 및 파싱 도구
|
||||
- **Contradictions/Notes:** 한 유저의 경험에 따르면, 과거 War-Yes 사이트에는 장갑에 대한 고폭탄(HE) 데미지 변환과 같은 세부 메커니즘 정보가 있었으나 최근 사이트가 개편되면서 상당수의 정보가 누락된 것으로 보인다는 지적이 있습니다 [10].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# [[ndf-parse|ndf-parse]] 패키지
|
||||
|
||||
## 📌 Brief Summary
|
||||
`ndf-parse` 패키지는 EugenSystems의 NDF(Neutral Data Format) 파일을 구문 분석(파싱)하고 수정한 뒤, 이를 다시 유효한 NDF 코드로 작성할 수 있게 해주는 도구입니다 [1]. 게임에서 기본적으로 제공하는 자체 도구들보다 [[WARNO|WARNO]] 모드(mod)를 훨씬 쉽게 편집할 수 있도록 개발되었습니다 [1]. 다만, 이 패키지는 Windows 환경을 위해서만 제작되고 테스트되었다는 특징이 있습니다 [1].
|
||||
|
||||
## 📖 Core 소스에 관련 정보가 부족합니다.
|
||||
(※ 소스 내에 `ndf-parse` 패키지에 대한 정보가 한정적이어서 제공된 내용을 최대한 종합하여 작성했습니다.)
|
||||
|
||||
- **기능 및 목적**: `ndf-parse`는 WARNO의 모더들이 게임 데이터를 직접 수정할 수 있도록 지원하는 패키지입니다 [1]. 스크립트를 활용하면 모든 차량 유닛의 물류(logistics) 용량을 일괄적으로 두 배 늘리는 등 반복적이거나 복잡한 데이터 수정 작업을 프로그래밍 방식으로 쉽게 처리할 수 있습니다 [1].
|
||||
- **API 및 모듈 구성**: 코드와 데이터를 구문 분석하고 수정하기 위해 여러 API 참조를 제공합니다. 주요 구성 요소로는 `model` 및 `printer` 모듈이 있으며, `convert()`, `expression()`, `expressions()`, `walk()`, `Mod`, `Edit`와 같은 함수와 기능들이 포함되어 있습니다 [1].
|
||||
- **WARNO 데이터 설계와의 연관성**: WARNO의 시스템은 유닛 특성, 무기 체계, 탄약 등 모든 시뮬레이션 논리를 NDF 파일(예: `UniteDescriptor.ndf`, `Ammunition.ndf`) 내에 엄격히 정의하고 있습니다 [2, 3]. `ndf-parse`는 게임 소스 코드를 건드리지 않고 이 방대한 텍스트 기반 데이터 객체들을 직접 통제할 수 있는 수단을 제공하여 데이터 중심 설계의 모딩을 돕습니다 [1, 2].
|
||||
- **제약 사항 (Caveats)**: 개발 및 테스트가 오직 Windows 운영 체제에서만 진행되었기 때문에 다른 환경에서 사용할 때는 주의가 필요합니다 [1].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], [[WARNO 모딩|WARNO 모딩]]
|
||||
- **Projects/Contexts:** [[WARNO 데이터 기반 설계|WARNO 데이터 기반 설계]], [[WME (Warno Mod Editor)|WME (Warno Mod Editor]]
|
||||
- **Contradictions/Notes:** 소스에 `ndf-parse`에 대한 구체적인 작동 원리나 세부 코드는 부족하지만, Windows 전용으로 제작 및 테스트되었다는 명확한 제약 사항이 존재합니다 [1]. 또한, 커뮤니티가 사용하는 WME(Warno Mod Editor)와 같은 다른 모딩 도구들과 궤를 같이하여 NDF 데이터를 다루기 위한 서드파티 솔루션으로 기능합니다 [1, 4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
# ndf-parse
|
||||
|
||||
## ?뱦Brief Summary
|
||||
`ndf-parse`??EugenSystems??NDF(Neutral Data Format) ?뚯씪???뚯떛?섍퀬, ?댁슜???섏젙?????좏슚??NDF 肄붾뱶濡??ㅼ떆 ??ν븷 ???덈룄濡?吏?먰븯???뚰봽?몄썾???⑦궎吏?낅땲??[1]. 寃뚯엫 ?먯껜?먯꽌 ?쒓났?섎뒗 湲곕낯 ?꾧뎄?ㅻ낫???⑥뵮 ?쎄쾶 [[WARNO|WARNO]] 紐⑤뱶(mod)瑜??몄쭛?????덈룄濡?怨좎븞?섏뿀?듬땲??[1]. ???꾧뎄瑜??듯빐 ?좎??ㅼ? WARNO???곗씠???꾪궎?띿쿂??吏곸젒 ?묎렐?섏뿬 寃뚯엫 ???섏튂瑜??좎뿰?섍쾶 蹂寃쏀븷 ???덉뒿?덈떎 [1, 2].
|
||||
|
||||
## ?뱰 Core Content
|
||||
* **?듭떖 湲곕뒫 諛??ㅽ겕由쏀듃 ?쒖슜:** `ndf-parse`??NDF ?뚯씪???쎄퀬 ?섏젙 諛??ъ옉?깊븯??湲곕뒫???섑뻾?⑸땲??[1]. ???⑦궎吏瑜??댁슜?섎㈃ ?ㅽ겕由쏀듃瑜??듯빐 ??됱쓽 ?곗씠?곕? ?⑥쑉?곸쑝濡??섏젙?????덉쑝硫? ?덈? ?ㅼ뼱 '紐⑤뱺 李⑤웾??蹂닿툒(logistics) ?⑸웾????諛곕줈 ?섎━?? ?ㅽ겕由쏀듃瑜??묒꽦?섏뿬 ?쇨큵 ?곸슜?섎뒗 寃껋씠 媛?ν빀?덈떎 [1].
|
||||
* **?곗씠??以묒떖 ?ㅺ퀎? 紐⑤뵫 而ㅻ??덊떚 湲곗뿬:** WARNO??寃뚯엫 濡쒖쭅怨??좊떅 ?ㅽ럺(?깅뒫, 紐낆쨷瑜? 愿?듬젰 ??? 紐⑤몢 NDF ?뚯씪 援ъ“ ?댁뿉 ?띿뒪??湲곕컲?쇰줈 ?꾧꺽??遺꾨━?섏뼱 愿由щ맗?덈떎 [2]. `ndf-parse`? 媛숈? ?뚯떛 ?꾧뎄??議댁옱???좎??ㅼ씠 ?뚯뒪 肄붾뱶瑜?嫄대뱶由ъ? ?딄퀬???곗씠?곕? 議곗옉?????덇쾶 留뚮뱾?? 媛쒕갑?곸씤 紐⑤뵫 ?앺깭怨꾩? ?뺣????꾩닠 ?섍꼍 援ъ텞???뺣뒗 湲곗닠??湲곕컲???⑸땲??[2, 3].
|
||||
* **?쒖뒪???쒖빟 ?ы빆:** ???⑦궎吏??Windows ?댁쁺泥댁젣?⑹쑝濡??쒖옉?섏뿀?쇰ʼn, Windows ?섍꼍?먯꽌留??뚯뒪?멸? 吏꾪뻾?섏뿀?ㅻ뒗 ?쒓퀎瑜?媛吏怨??덉뒿?덈떎 [1].
|
||||
|
||||
## ?뵕 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], [[WARNO 紐⑤뵫 ?앺깭怨?]
|
||||
- **Projects/Contexts:** Warno ?곗씠??湲곕컲 ?ㅺ퀎
|
||||
- **Contradictions/Notes:** API ?덊띁?곗뒪(convert, expression, walk ??媛 紐⑸줉?쇰줈 議댁옱?쒕떎???먯? ?뺤씤?섎굹 [1], 援ъ껜?곸씤 ?⑥닔 援ы쁽 諛⑹떇?대굹 ?몃? ?묐룞 ?먮━ ?깆? ?뚯뒪??愿???뺣낫媛 遺議깊빀?덈떎.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 가변적 LOD(Level of Detail) 시스템
|
||||
|
||||
## 📌 Brief Summary
|
||||
가변적 LOD(Level of Detail) 시스템은 카메라와 대상 유닛 간의 거리에 따라 3D 모델의 정밀도를 동적으로 조절하는 기술입니다 [1, 2]. [[WARNO|WARNO]]에서는 이 시스템을 통해 수 킬로미터에 달하는 대규모 전장의 실시간 가시성과 엔진 성능을 확보합니다 [2, 3]. 가까운 시점에서는 고해상도의 정밀한 모델을 보여주고, 거리가 멀어질수록 형태를 단계적으로 단순화하여 시스템 연산 부담을 크게 줄여주는 역할을 합니다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
- **거리 기반 모델 정밀도 조절**: WARNO의 가변적 LOD 시스템은 카메라에서 객체(유닛)까지의 거리에 의존하여 모델의 디테일 수준을 결정합니다 [1]. 이를 통해 거리별 3D 모델의 정밀도를 동적으로 조절하여 대규모 전장에서 실시간 가시성을 효율적으로 확보합니다 [2].
|
||||
- **단계적인 디테일 변화**: 플레이어의 시점이 유닛에 근접할 경우, 격납고(Hangar) 메뉴에서 볼 수 있는 수준의 매우 상세하고 정교한 모델이 렌더링됩니다 [1]. 반대로 시점이 멀어지게 되면 몇 가지 중간 단계를 거쳐 최종적으로는 단순한 색상 상자(colourful box) 형태로 유닛의 묘사가 간략화됩니다 [1].
|
||||
- **Iriszoom 엔진과의 통합 및 최적화**: 이 시스템은 광활한 전장을 조감하는 전략적 시점부터 개별 병사의 장비까지 식별 가능한 전술적 시점을 단일 렌더링 파이프라인에서 매끄럽게 연결해 주는 Iriszoom 엔진의 줌(Zoom) 기능과 결합되어 작동합니다 [3]. 덕분에 매우 세밀한 시점부터 3x3km 크기의 넓은 전장 시점까지 전환할 때도 끊김 현상(stuttering) 없이 뛰어난 최적화 성능을 제공합니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], [[데이터 기반 설계 (Data-Driven Design)|데이터 기반 설계(Data-Driven Design]]
|
||||
- **Projects/Contexts:** [[WARNO|WARNO]]
|
||||
- **Contradictions/Notes:** 소스 내에서 이 시스템의 메커니즘에 대한 모순점은 발견되지 않습니다. 오히려 가변적 LOD 시스템의 원활한 작동 덕분에 세밀한 모델링과 애니메이션이 많은 환경에서도 대규모 10v10 전투를 4K 해상도와 최고 옵션에서 프레임 드랍 없이 안정적으로 실행할 수 있다는 플레이어들의 호평이 존재합니다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 데이터 파싱 (Data Parsing)
|
||||
|
||||
## 📌 Brief Summary
|
||||
데이터 파싱은 [[WARNO|WARNO]]의 내부 게임 파일인 NDF(Neutral Data Format) 등에서 유닛의 속성, 성능 수치 및 숨겨진 메커니즘 데이터를 자동으로 추출하고 해독하는 과정을 의미한다 [1-3]. 유저 커뮤니티와 개발자들은 데이터 파싱 도구를 활용하여 인게임 UI에서 제공하지 않는 세부적인 통계와 로직을 파악한다 [1, 3]. 이렇게 추출된 데이터는 Warno-Armory, [[War-Yes|War-Yes]]와 같은 서드파티 분석 웹사이트나 게임을 수정하는 모딩 도구를 구축하는 데 핵심적인 역할을 한다 [1, 3-5].
|
||||
|
||||
## 📖 Core 시Content
|
||||
* **데이터 파싱의 목적과 대상:** WARNO의 모든 논리적 설계와 유닛 데이터는 독자적인 스크립트 언어인 NDF 파일에 정의되어 있다 [2]. 데이터 파싱은 이 파일들을 자동으로 읽어들여 인게임 아머리(Armory) 화면에서는 볼 수 없는 게임 엔진 내부의 숨겨진 수치들을 발굴하고 분석하는 데 사용된다 [1, 3].
|
||||
* **커뮤니티 도구 및 웹사이트 구축:** 커뮤니티 멤버들은 파싱을 통해 추출한 데이터를 기반으로 유닛 비교 및 분석 웹사이트를 제작하여 생태계를 확장하고 있다 [3, 5, 6]. 대표적으로 'Warno-Armory'는 실제 WARNO의 내부 NDF 파일을 직접 파싱하여 전수 조사된 상세 수치 데이터를 읽기 편한 형태로 제공한다 [1, 3, 5]. 또한 'War-Yes' 웹사이트의 경우, 제작자가 유닛 카드의 정보를 읽기 위해 AI 텍스트 파서(AI text [[Parser|Parser]])를 활용하여 데이터를 캡처하는 방식을 사용하기도 했다 [4].
|
||||
* **모딩(Modding) 지원과 코드 수정:** `[[ndf-parse|ndf-parse]]` 패키지와 같은 전용 도구는 EugenSystems의 NDF 파일을 파싱하고, 그 내용을 수정한 뒤 다시 유효한 NDF 코드로 작성할 수 있게 해준다 [7]. 이를 통해 모더(Modder)들은 게임이 자체적으로 제공하는 툴을 사용할 때보다 훨씬 쉽고 효율적으로 게임 데이터를 수정할 수 있으며, 이는 정교한 모딩 환경을 조성하는 밑거름이 된다 [2, 7].
|
||||
* **숨겨진 데이터의 가시화와 전술적 활용:** 데이터 파싱은 플레이어들이 직관적으로 알기 어려운 '연사 준비 시간(TempsEntreDeuxTirs)'과 같은 숨겨진 무기 제원이나 상세한 계산 로직을 파악하게 해준다 [3, 8]. 이렇게 파싱된 데이터는 유저들이 게임 메커니즘을 더욱 깊이 있게 이해하고 데이터에 기반한 정교한 덱 빌딩 및 전술을 수립하는 데 직접적으로 기여한다 [3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], WARNO 모딩 (WARNO Modding), Warno-Armory, [[War-Yes|War-Yes]]
|
||||
- **Projects/Contexts:** WARNO 데이터 아키텍처 및 커뮤니티 도구 개발
|
||||
- **Contradictions/Notes:** 소스 간에 데이터를 추출하는 기술적 접근 방식의 차이가 존재한다. 'Warno-Armory'나 `ndf-parse`의 경우 시스템의 핵심 파일인 NDF를 직접 프로그래밍 언어로 파싱하는 정석적인 방식을 취하지만 [1, 3, 7], 'War-Yes'의 구축 초기에는 AI 텍스트 파서를 사용해 유닛 카드에 텍스트로 적힌 정보를 읽어내는(OCR 방식 등) 우회적 기법이 사용되었다고 언급된다 [4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 데이터 파싱(Data Parsing)
|
||||
|
||||
## 📌 Brief Summary
|
||||
[[WARNO|WARNO]]에서 데이터 파싱은 유저 커뮤니티가 게임의 내부 파일(주로 NDF 파일)을 읽어들여 게임 엔진 내부에 숨겨진 통계와 수치를 추출하고 분석하는 과정을 의미합니다 [1, 2]. 플레이어들은 이를 통해 수집된 데이터를 바탕으로 유닛의 성능을 비교 분석하는 도구를 만들거나, 모드(Mod) 제작 및 정교한 덱 빌딩에 활용합니다 [1-3]. 이는 결과적으로 게임의 메커니즘을 깊이 있게 이해하고 데이터에 기반한 전술을 수립하는 핵심 기반이 됩니다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **커뮤니티 파싱 도구의 개발 및 활용**
|
||||
WARNO 유저 커뮤니티는 실제 게임 파일을 직접 읽어들이는 데이터 파싱 기술을 활용하여 [[Warno-Armory|Warno-Armory]]나 [[War-Yes|War-Yes]]와 같은 온라인 무기고 및 유닛 비교 웹사이트를 구축했습니다 [2-4]. 예를 들어, 일부 웹사이트 제작자는 AI 텍스트 파서를 활용하여 유닛 카드 데이터를 추출함으로써 사용자들이 유닛을 검색하고, 정렬하며, 비교할 수 있는 도구를 제공합니다 [3].
|
||||
|
||||
* **[[ndf-parse|ndf-parse]] 패키지와 모딩 생태계**
|
||||
개발사 EugenSystems의 독자적인 스크립트 언어인 NDF(Neutral Data Format) 파일을 전문적으로 파싱하기 위해 'ndf-parse'라는 파이썬 패키지가 만들어졌습니다 [1]. 이 패키지는 NDF 파일을 파싱하고 내용을 수정한 뒤 다시 유효한 NDF 코드로 작성할 수 있게 해 주며, 기존 게임 자체 도구를 사용할 때보다 WARNO 모드(Mod) 편집을 훨씬 용이하게 만들어 줍니다 [1].
|
||||
|
||||
* **데이터 기반 전술 수립에의 기여**
|
||||
데이터 파싱은 게임 내 UI에서는 직접 확인할 수 없는 수치들(예를 들어 '연사 준비 시간(TempsEntreDeuxTirs)' 등)을 밝혀내는 데 핵심적인 역할을 합니다 [2]. 이렇게 발굴된 상세한 수치 데이터들은 플레이어들이 게임의 복잡한 교전 메커니즘을 명확하게 파악하도록 돕고, 결과적으로 직관이 아닌 데이터를 기반으로 한 정교한 덱 빌딩과 전술 수립을 가능하게 합니다 [2].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
* **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], Warno-Armory, [[War-Yes|War-Yes]]
|
||||
* **Projects/Contexts:** 모딩 생태계와 데이터의 민주화
|
||||
* **Contradictions/Notes:** 파서를 통해 데이터를 추출할 때, AI 텍스트 파서를 활용하여 유닛 카드를 읽는 방식을 사용할 경우 간혹 이상한 값(odd values)이 섞여 들어갈 수 있다는 기술적 한계 및 주의점이 언급되어 있습니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 지연 렌더링(Deferred Rendering)
|
||||
|
||||
## 📌 Brief Summary
|
||||
지연 렌더링(Deferred Rendering)은 전술 시뮬레이션 게임 [[WARNO|WARNO]]의 기술적 기반인 Iriszoom 엔진이 채택하고 있는 핵심 렌더링 구조이다 [1, 2]. 이 엔진 구조는 전면적인 물리 기반 렌더링(PBR) 지원과 통합되어 최신 산업 표준을 충족하도록 업그레이드되었다 [1]. 특히 수 킬로미터에 달하는 광활한 전장 환경에서 발생하기 쉬운 장거리 스펙큘러 노이즈 현상을 효과적으로 억제하는 역할을 수행한다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **Iriszoom 엔진과의 통합**: WARNO를 구동하는 EugenSystems의 독자적 엔진인 Iriszoom은 기술적으로 지연 렌더링 구조를 기반으로 작동한다 [2]. 개발사는 과거 타이틀부터 이어져 온 지연 렌더링 엔진을 전체 PBR을 지원하도록 전면적으로 업그레이드하였다 [1].
|
||||
* **지형 렌더링 및 장거리 시야 최적화**: 지연 렌더링 구조를 바탕으로 지형 렌더링 기술이 대대적으로 개선되었다 [2]. 전략적 조감을 위해 멀리 떨어진 거리에서 지형을 바라볼 때 흔히 발생하는 '장거리 PBR 스펙큘러 폭발(PBR-specular explosion from far)' 내지 노이즈 문제를 부드럽고 효과적으로 억제하여 시각적 가시성을 확보한다 [1, 2].
|
||||
* **에셋 생산 파이프라인 진화**: 지연 렌더링 엔진의 향상된 기능 덕분에 게임의 에셋(Asset) 생산 파이프라인도 최신화되었다 [3]. 기존의 구형 Specular/Glossiness 워크플로우를 폐기하고, 최신 형태의 [[Metal|Metal]]lic/Roughness/Ambient Occlusion 워크플로우로 전환함으로써 훨씬 정교하고 사실적인 재질감을 구현할 수 있게 되었다 [2, 3].
|
||||
* **성능 및 최적화 유지**: 그래픽과 렌더링 품질이 대폭 향상되었음에도 불구하고, 최소 사양 환경에서도 효율적으로 작동하도록 유지하는 것을 목표로 설계되었다 [3]. 그 결과 전작인 Steel Division 2보다 더 높은 컴퓨터 요구 사양을 필요로 하지 않으며 [3], 10v10 대규모 멀티플레이어 환경에서도 4K 해상도를 안정적으로 지원하는 높은 최적화 수준을 보여준다 [2].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Iriszoom 엔진|Iriszoom 엔진]], [[물리 기반 렌더링(PBR)|물리 기반 렌더링(PBR]]
|
||||
- **Projects/Contexts:** [[WARNO|WARNO]]
|
||||
- **Contradictions/Notes:** 소스 간의 모순점은 존재하지 않습니다. 지연 렌더링을 통해 그래픽 품질이 크게 개선되었음에도 불구하고 게임의 사양 요구치가 높아지지 않도록 최적화가 잘 이루어졌음이 강조되고 있습니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 텔레메트리 (Telemetry) 밸런싱
|
||||
|
||||
## 📌 Brief Summary
|
||||
텔레메트리 밸런싱은 [[WARNO|WARNO]]의 개발사인 EugenSystems가 게임 출시 이후 방대한 실제 플레이 데이터를 수집하여 게임의 밸런스를 정밀하게 조정하는 사후 관리 방법론입니다 [1, 2]. 이 시스템은 커뮤니티의 주관적이고 변덕스러운 여론에 전적으로 의존하지 않고, 유닛의 선택 빈도, 승률, 킬/데스 비율 등 객관적인 통계를 바탕으로 작동합니다 [1, 2]. 개발진은 수집된 데이터를 통해 유닛의 포인트 비용이나 세부 스펙을 조정함으로써, 게임이 지속적으로 경쟁적이고 균형 잡힌 전술 생태계를 유지할 수 있도록 지원합니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **텔레메트리 시스템의 데이터 수집**
|
||||
개발사는 유닛이 인게임에서 실제로 어떻게 사용되고 있는지 모니터링하기 위해 텔레메트리 시스템을 활용합니다 [1]. 이 시스템은 플레이어들의 특정 유닛 선택 빈도(Pick Rate), 실제 교전에서의 승률 및 킬/데스 비율, 평균 생존 시간 등을 실시간으로 기록하여 객관적인 지표를 산출합니다 [2].
|
||||
|
||||
* **객관적 데이터와 피드백의 교차 검증**
|
||||
개발진은 전문 테스터의 피드백과 커뮤니티 매체에서 취합된 대화 요약본을 텔레메트리 데이터와 비교 검증합니다 [1]. 유저들의 불만이나 변덕스러운 의견에만 휘둘리는 것이 아니라, 게임 내에서 사물이 '실제로' 어떻게 작동하는지에 대한 객관적 데이터를 바탕으로 밸런싱을 수행하는 것이 이 설계의 핵심입니다 [1, 2].
|
||||
|
||||
* **주요 밸런스 조정 변수**
|
||||
수집된 데이터를 바탕으로 NDF 파일 내의 수치를 수정하여 즉각적인 밸런스 변화를 전장에 반영합니다 [2]. 주요 조정 변수로는 텔레메트리 효율에 따른 유닛의 '포인트 비용(Point Cost)', 장전 시간·조준 시간·관통력 수치 등의 '무장 세부 스펙', 전술적 역할을 강화하기 위한 '특성(Trait) 할당', 그리고 특정 사단의 승률을 보완하기 위한 '사단별 유닛 카드 구성 및 가용성 데이터 상향' 등이 포함됩니다 [4].
|
||||
|
||||
* **밸런싱의 실제 적용 사례와 효과**
|
||||
예를 들어, 특정 대공 미사일이 항공기를 너무 쉽게 격추한다는 것이 텔레메트리 분석을 통해 확인되면 개발자는 해당 미사일의 명중률 곡선이나 가격 데이터를 수정합니다 [2]. 또한 수송 트럭의 도로 이동 속도와 같은 단순한 요소를 하나 변경하더라도, 해당 트럭을 사용하는 모든 유닛의 가치에 미치는 영향과 다른 유닛으로 대체할 때의 기회비용까지 종합적으로 고려하여 재조정을 거칩니다 [3]. 10v10 대규모 멀티플레이어 데이터 분석에 따르면, 이러한 지속적인 밸런싱 덕분에 플레이어의 숙련도가 높아질수록 진영 간 플레이 비중과 승률이 균형을 이루는 것으로 증명되었습니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], [[데이터 기반 설계 (Data-Driven Design)|데이터 기반 설계 (Data-Driven Design]]
|
||||
- **Projects/Contexts:** [[WARNO 사후 관리 (Post-Launch Management)|WARNO 사후 관리 (Post-Launch Management]], [[10v10 대규모 멀티플레이어|10v10 대규모 멀티플레이어]]
|
||||
- **Contradictions/Notes:** 개발진은 미숙하거나 변덕스러운 커뮤니티의 불만보다는 객관적인 텔레메트리 데이터를 우선시하여 밸런싱을 진행한다고 강조하지만 [1, 2], 잦은 너프나 특정 유닛의 변화에 대해 유저들 사이에서 불만이 제기되거나 해당 시스템의 효율성에 의문을 표하는 의견(예: Commandos de l'air 너프 사례)도 일부 존재합니다 [3, 5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 텔레메트리 (Telemetry)
|
||||
|
||||
## 📌 Brief Summary
|
||||
텔레메트리(Telemetry)는 [[WARNO|WARNO]]의 개발사인 EugenSystems가 게임 내 유닛의 실제 사용 방식과 성능을 모니터링하기 위해 사용하는 데이터 수집 시스템입니다 [1, 2]. 개발진은 플레이어들의 단순한 불만이나 주관적인 여론에 휘둘리지 않고, 유닛의 픽률, 승률, 킬/데스 비율 등의 객관적인 텔레메트리 데이터를 분석하여 정밀하고 합리적인 게임 밸런싱을 수행합니다 [1, 2]. 이는 게임 출시 이후에도 끊임없이 메타를 조정하고 관리하는 WARNO 데이터 기반 설계의 핵심적인 역할을 담당합니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
- **객관적 전장 지표의 실시간 수집:** 텔레메트리 시스템은 플레이어들이 특정 유닛을 얼마나 자주 선택하는지(Pick Rate), 해당 유닛이 실제 교전에서 거두는 승률과 킬/데스 비율, 평균 생존 시간 등을 실시간으로 기록합니다 [2]. 이를 통해 커뮤니티의 변덕스럽거나 경험이 부족한 의견(whims)에 의존하는 대신 게임 내에서 유닛과 시스템이 '실제로' 어떻게 작동하고 사용되는지 정확히 파악할 수 있습니다 [1].
|
||||
- **데이터 기반의 정밀 밸런싱 (Data-Driven Balancing):** 개발진은 수집된 객관적 텔레메트리 데이터를 피드백과 대조하여 밸런스 조정의 근거로 삼습니다 [1, 2]. 예를 들어, 특정 대공 미사일이 항공기를 너무 쉽게 격추한다는 사실이 텔레메트리 분석 결과로 확인되면, 개발자는 NDF 파일 내에서 해당 미사일의 명중률 곡선이나 가격 데이터를 직접 수정하여 밸런스를 교정합니다 [2].
|
||||
- **텔레메트리에 기반한 주요 밸런스 조정 변수:** 텔레메트리 효율과 전술적 가치 분석에 따라 게임 내 여러 변수가 지속적으로 재조정됩니다. 여기에는 유닛의 '포인트 비용(Point Cost)' 재책정, 장전 시간 및 조준 시간, 관통력 등 '무장 세부 스펙'의 미세 조정, 전술적 역할을 강화하는 '특성(Trait) 부여', 특정 사단의 승률이 낮을 경우 보조 카드를 추가하거나 가용성을 높이는 '사단별 유닛 카드 구성' 변경 등이 포함됩니다 [3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[데이터 기반 밸런싱 (Data-Driven Balancing)|데이터 기반 밸런싱 (Data-Driven Balancing]], NDF (Neutral Data Format), 게임 피드백 (Game Feedback
|
||||
- **Projects/Contexts:** Eugen Systems의 WARNO 사후 관리 및 패치 시스템
|
||||
- **Contradictions/Notes:** 커뮤니티의 일부 플레이어들은 잦은 단위 비용 및 성능의 너프/버프 변화에 대해 불만을 제기하기도 하지만, 이러한 밸런스 패치는 임의적인 결정이 아니라 텔레메트리를 통해 확인된 실제 유닛의 사용 빈도와 전술적 가치 영향(Value impact)을 철저히 계산한 결과입니다 [1, 4, 5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 텔레메트리 데이터 (Telemetry Data)
|
||||
|
||||
## 📌 Brief Summary
|
||||
[[WARNO|WARNO]]에서 텔레메트리 데이터(Telemetry Data)는 게임 출시 후 개발사인 EugenSystems가 게임 밸런스를 정밀하게 조정하기 위해 수집하는 방대한 실제 인게임 기록입니다 [1]. 이 시스템은 유닛의 선택 빈도(Pick Rate), 교전 승률, 킬/데스 비율, 평균 생존 시간 등을 실시간으로 추적합니다 [1]. 개발사는 변덕스러운 커뮤니티의 단순한 불만에 의존하기보다는, 이 객관적인 텔레메트리 데이터를 전문 테스터의 피드백과 교차 검증하여 유닛의 성능과 가용성을 수정하는 데이터 기반 설계를 유지합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
- **실시간 데이터 수집 지표:** 텔레메트리 시스템은 플레이어들이 실제로 게임 내에서 유닛을 어떻게 활용하는지 조용히 모니터링하는 역할을 합니다 [2]. 구체적으로는 어떤 유닛이 얼마나 자주 덱에 선택되는지(Pick Rate), 해당 유닛이 실제 교전에서 달성하는 승률과 킬/데스 비율, 그리고 평균 생존 시간 등을 실시간으로 기록하여 유닛의 실질적인 성능 데이터를 구축합니다 [1].
|
||||
- **데이터 기반 밸런싱(Data-Driven Balancing):** 개발사는 경험이 부족하거나 감정적인 커뮤니티의 여론에 휘둘리지 않고, 수집된 텔레메트리 데이터를 최우선 기반으로 삼아 밸런싱을 수행합니다 [1, 2]. 예를 들어, 특정 대공 미사일이 항공기를 너무 쉽게 격추한다는 사실이 텔레메트리 통계로 확인되면, 개발자는 게임의 뼈대인 NDF 파일에 접근해 해당 미사일의 명중률 곡선이나 포인트 비용(가격 데이터)을 즉각적으로 수정합니다 [1, 3].
|
||||
- **사단 및 유닛 구성 조정:** 텔레메트리 데이터는 개별 유닛뿐만 아니라 사단 단위의 밸런스 조정에도 개입합니다. 만약 특정 사단의 승률 데이터가 낮게 측정될 경우, 개발진은 보조 유닛 카드를 덱에 추가하거나 유닛의 가용성(Availability) 데이터를 상향 조정하여 균형을 맞춥니다 [3].
|
||||
- **피드백과의 교차 검증:** 텔레메트리는 독단적으로 사용되지 않으며, 전문 테스터의 피드백이나 커뮤니티 매체를 통해 집계된 대화 내용과 비교 및 대조되는 과정을 거칩니다 [2]. 특정 수치가 데이터상으로는 정상적으로 작동하더라도 플레이어들이 여전히 불쾌감을 느낀다면, 개발사는 이를 참고하여 추가적인 미세 조정을 단행합니다 [2].
|
||||
- **시뮬레이션의 지속 가능성 확보:** 이러한 텔레메트리 기반의 사후 관리 시스템은 WARNO의 사단 중심 제약 조건과 함께 맞물려, 게임이 정체되지 않고 살아있는 전술 생태계로서 장기적인 지속 가능성을 담보할 수 있도록 돕습니다 [3, 4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[데이터 기반 밸런싱 (Data-Driven Balancing)|데이터 기반 밸런싱 (Data-Driven Balancing]], NDF (Neutral Data Format), [[가용성 (Availability)|가용성 (Availability]]
|
||||
- **Projects/Contexts:** WARNO의 사후 관리 및 밸런스 패치 시스템
|
||||
- **Contradictions/Notes:** 소스 [2]와 [1]은 밸런스 조정 시 플레이어들의 단순한 불만(여론)보다는 텔레메트리를 통해 수집된 실제 유닛 사용량 및 성과(객관적 데이터)가 훨씬 우선적이고 결정적인 기준으로 작용함을 강조합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 텔레메트리 밸런싱 (Telemetry Balancing)
|
||||
|
||||
## 📌 Brief Summary
|
||||
텔레메트리 밸런싱은 [[WARNO|WARNO]]의 개발사 EugenSystems가 방대한 플레이어의 실제 게임 플레이 데이터를 실시간으로 수집하여 객관적으로 게임의 밸런스를 조정하는 사후 관리 방법론입니다 [1, 2]. 이 시스템은 커뮤니티의 주관적이고 변덕스러운 불만에 휘둘리지 않고, 유닛의 실제 사용 빈도와 교전 성능을 정확히 모니터링합니다 [1, 2]. 이를 바탕으로 포인트 비용이나 무기 스펙 등을 NDF 파일에서 지속적으로 수정하여 균형 잡힌 전술 생태계를 유지합니다 [2, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 수집 지표:** 텔레메트리 시스템은 플레이어들이 어떤 유닛을 얼마나 자주 선택하는지(Pick Rate), 해당 유닛이 실제 교전에서 거두는 승률과 킬/데스 비율, 그리고 평균 생존 시간 등의 방대한 데이터를 실시간으로 기록합니다 [2].
|
||||
* **객관적 의사결정의 근거:** 개발사는 경험이 부족하거나 감정적인 커뮤니티의 여론에만 의존하는 대신, 텔레메트리 데이터로 도출된 게임의 실제 작동 방식을 전문 테스터의 피드백 등과 비교 및 대조하여 밸런싱을 수행합니다 [1, 2].
|
||||
* **NDF 시스템을 통한 밸런싱 적용:** 객관적 데이터 분석 결과 특정 유닛이 과도한 성능을 내는 것으로 판명되면(예: 대공 미사일이 항공기를 너무 쉽게 격추하는 경우), 개발자는 NDF 파일 내의 명중률 곡선이나 가격 데이터 수치를 즉각적으로 수정하여 밸런스를 바로잡습니다 [2].
|
||||
* **주요 조정 변수:** 텔레메트리 효율에 따른 유닛의 '포인트 비용(Point Cost)' 재책정, 장전 및 조준 시간이나 관통력 같은 '무장 세부 스펙'의 미세 조정, 전술적 역할을 강화하는 '특성(Trait) 할당', 그리고 승률이 낮은 사단을 보완하기 위한 '사단별 유닛 카드 구성' 상향 등이 주요 밸런싱 데이터 변수로 활용됩니다 [3].
|
||||
* **진영 간 균형 달성:** 이와 같은 데이터 기반의 정밀한 밸런싱과 지속적인 패치 덕분에, 대규모 멀티플레이어 환경(10v10)에서 플레이어의 숙련도가 높아질수록 NATO와 PACT 진영 간의 플레이 비중과 승률은 객관적인 균형을 이루게 됩니다 [2, 3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[NDF (Neutral Data Format)|NDF (Neutral Data Format]], [[데이터 기반 설계 (Data-Driven Design)|데이터 기반 설계 (Data-Driven Design]]
|
||||
- **Projects/Contexts:** [[WARNO|WARNO]]
|
||||
- **Contradictions/Notes:** 제공된 소스들은 모두 공통적으로 텔레메트리 시스템이 유저들의 단순한 불만보다 실제 사용 및 성능 데이터를 우선시함으로써, 더 객관적이고 정확한 게임 밸런싱을 가능하게 한다는 점을 강조하고 있습니다 [1, 2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,28 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 텔레메트리 밸런싱(Telemetry Balancing)
|
||||
|
||||
## 📌 Brief Summary
|
||||
텔레메트리 밸런싱(Telemetry Balancing)은 [[WARNO|WARNO]]의 개발사 EugenSystems가 커뮤니티의 주관적인 불만이나 여론에 휘둘리지 않고, 게임 내에서 실제로 수집된 객관적인 플레이 데이터를 바탕으로 게임 밸런스를 조정하는 방법론을 의미합니다 [1, 2]. 이 시스템은 유닛의 픽률(선택 빈도), 승률, 킬/데스 비율, 평균 생존 시간 등을 실시간으로 기록합니다 [2]. 개발진은 이러한 원시 데이터를 분석하여 유닛의 실제 성능과 활용도를 파악한 후, 포인트 비용이나 무기 스펙, 사단별 카드 구성을 정밀하게 수정하여 경쟁적인 플레이 환경을 유지합니다 [2-4].
|
||||
|
||||
## 📖 Core Content
|
||||
* **데이터 수집 및 실시간 모니터링:**
|
||||
개발사는 텔레메트리를 통해 각 유닛이 인게임에서 실제로 어떻게 사용되고 있는지 면밀히 추적합니다 [1]. 플레이어들이 어떤 유닛을 얼마나 자주 선택하는지(Pick Rate), 교전에서의 실제 승률과 킬/데스 비율, 평균 생존 시간 등 방대한 수치 데이터를 실시간으로 기록하여 분석합니다 [2].
|
||||
* **객관적 밸런싱 기준과 교차 검증:**
|
||||
경험이 부족하거나 변덕스러운 커뮤니티의 주관적인 여론에 의존하기보다는, 수집된 텔레메트리 데이터를 우선시하여 밸런스 패치의 근거로 삼습니다 [1, 2]. 물론 전문 테스터와 커뮤니티 매체로부터 피드백을 수합하지만, 개발팀은 이를 항상 텔레메트리 데이터와 교차 검증(Cross-check)하여 게임 내에서 사물이 '실제로' 작동하는 방식을 파악합니다 [1].
|
||||
* **조정 변수 및 NDF 파일 적용:**
|
||||
텔레메트리 분석을 통해 특정 유닛이 과도한 효율을 내는 것(예: 특정 대공 미사일이 항공기를 너무 쉽게 격추하는 현상 등)이 확인되면, 개발자는 NDF 파일 내의 데이터를 직접 수정하여 즉각적인 변화를 줍니다 [2]. 밸런스 조정의 주요 데이터 변수로는 포인트 비용(Point Cost) 재책정, 장전·조준 시간 및 관통력 등 무장 세부 스펙 변경, 유닛의 전술적 역할을 강화하기 위한 특성(Trait) 부여, 승률을 보완하기 위한 사단별 유닛 카드 구성 및 가용성 데이터 상향 등이 있습니다 [4].
|
||||
* **지속 가능한 전술 생태계 유지:**
|
||||
게임에 새로운 유닛의 능력이나 사단이 추가될 때마다 다른 유닛들의 가치와 기회비용에 영향을 미치므로, 텔레메트리를 기반으로 한 지속적인 재조정이 필수적입니다 [3]. 이러한 데이터 기반의 지속적인 패치 적용은 WARNO가 정체된 게임에 머물지 않고 살아있는 전술 생태계로 기능하게 만드는 핵심 동력으로 작용합니다 [4].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[데이터 기반 설계 (Data-Driven Design)|데이터 기반 설계(Data-Driven Design]], NDF (Neutral Data Format), [[사단 시스템 (Division System)|사단 시스템(Division System]]
|
||||
- **Projects/Contexts:** [[WARNO|WARNO]], [[Eugen Systems|Eugen Systems]]
|
||||
- **Contradictions/Notes:** 플레이어 커뮤니티는 작은 포인트(비용) 변화에도 게임이 완전히 달라졌다고 느끼거나 큰 불만을 제기하는 경우가 많습니다. 그러나 텔레메트리 분석에 따르면 이러한 소규모 조정이 실제 플레이에 미치는 영향은 매우 작으며, 개발사는 플레이어들의 주관적 불만보다는 객관적 통계(텔레메트리)를 밸런스 조절의 최우선 근거로 삼습니다 [1, 3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
category: Programming & Tools
|
||||
status: Final
|
||||
converted_at: 2026-04-28
|
||||
---
|
||||
|
||||
# 텔레메트리(Telemetry) 데이터 분석
|
||||
|
||||
## 📌 Brief Summary
|
||||
텔레메트리 데이터 분석은 [[WARNO|WARNO]]의 개발사인 EugenSystems가 게임 밸런스를 정밀하게 조정하고 사후 관리를 수행하기 위해 활용하는 핵심 시스템입니다 [1, 2]. 이 시스템은 플레이어의 유닛 선택 빈도(Pick Rate), 교전 승률, 킬/데스 비율, 평균 생존 시간 등 실제 게임 플레이에서 발생하는 객관적 데이터를 실시간으로 수집하고 분석합니다 [2]. 이를 통해 커뮤니티의 불규칙한 여론이나 단순 불만에 휘둘리지 않고, 실제 데이터에 기반한 합리적이고 정교한 시스템 설계 및 유닛 밸런싱을 가능하게 합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **실시간 데이터 수집 및 모니터링:** [[Eugen Systems|Eugen Systems]]는 게임 출시 이후 방대한 텔레메트리 데이터를 통해 전장에서 유닛이 실제로 어떻게 사용되고 성능을 내는지 모니터링합니다 [1]. 텔레메트리를 통해 수집되는 핵심 지표에는 플레이어의 개별 유닛 픽률(Pick Rate), 해당 유닛이 실제 교전에서 거두는 승률과 킬/데스 비율, 그리고 평균 생존 시간 등이 포함됩니다 [2].
|
||||
* **객관적 밸런싱 방법론:** 개발사는 경험이 부족한 커뮤니티의 변덕스러운 불만에 의존하기보다는, 텔레메트리가 제공하는 객관적 데이터와 전문 테스터의 피드백을 교차 검증하여 패치를 진행합니다 [1, 2]. 예를 들어, 특정 대공 미사일이 항공기를 너무 쉽게 격추하는 현상이 텔레메트리 지표로 확인되면, 개발진은 즉각적으로 NDF(Neutral Data Format) 파일 내의 명중률 곡선 데이터나 가격을 수정하는 방식으로 밸런스를 통제합니다 [2].
|
||||
* **주요 밸런스 조정 변수:** 텔레메트리 분석 결과를 바탕으로 조정되는 시뮬레이션의 주요 데이터 변수로는 유닛의 전술적 가치에 따른 포인트 비용(Point Cost), 장전 시간이나 관통력 수치 등의 무장 세부 스펙, 유닛의 역할을 강화하는 특성(Trait) 할당, 그리고 특정 사단의 승률을 보완하기 위한 사단별 유닛 카드 구성 및 가용성 데이터 상향 등이 있습니다 [3].
|
||||
* **커뮤니티 차원의 데이터 통계 분석:** 개발사뿐만 아니라 유저 커뮤니티 내부에서도 10v10 대규모 멀티플레이어 데이터를 수집하여 팩션(진영) 밸런스를 분석하려는 시도가 꾸준히 이루어지고 있습니다 [4, 5]. 이러한 데이터 분석 결과에 따르면, 숙련도가 높아질수록 NATO와 PACT 진영 간의 플레이 비중과 승률은 비교적 균형을 이루는 경향이 확인되었습니다 [3, 6].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[데이터 기반 밸런싱|데이터 기반 밸런싱]], [[NDF (Neutral Data Format)|NDF (Neutral Data Format]]
|
||||
- **Projects/Contexts:** WARNO 밸런스 사후 관리
|
||||
- **Contradictions/Notes:** 개발사는 텔레메트리 시스템을 통해 실제 성능 기반의 밸런스 조정을 진행하고 있으나, 유저 커뮤니티 내에서는 여전히 특정 유닛의 너프에 대해 체감상 진영 편향(예: Pact bias)을 주장하거나 잦은 성능 변경에 불만을 표하는 등, 플레이어의 주관적 체감과 개발사의 객관적 데이터 지표 간에 시각 차이가 종종 발생합니다 [1, 7, 8].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-28*
|
||||
Reference in New Issue
Block a user