콘텐츠로 이동
GameDesign

리스크

이 문서는 “이건 위험해 보여”로 분류된 항목과 코드–기획서 불일치를 정리한다.

본문 기준은 자료 기준 정책에 따라 **코드(현재 구현)**다. 본 페이지의 항목은 그 충돌 자체를 기록한 논의사항이며, 추후 검토를 거쳐 의도된 차이로 받아들이거나 한쪽을 수정하는 결정을 내린다.

  • PDF: Weapon / Armor / Parts / Utility / Material / Money (6종).
  • 코드 (ItemManager.Category1): 위 6종 + Accessory, Belt, Bag (9종 + None).
  • 본문(policies/item-category-policy.mdx)은 코드 기준으로 9종을 채택했다.
  • 결정 필요: PDF에 누락된 Accessory/Belt/Bag이 의도된 추가인지, 아니면 정리되지 않은 코드 잔재인지.
  • PDF: Zone / Fixed / Move + Monster / Chest / Patrol / Item (배치 모듈 4종).
  • 코드 (MapModuleType1): Main / Sub / Monster / Item / Chest / Escape (6종).
  • 차이:
    • PDF의 Zone은 코드의 Main에 대응한다고 추정.
    • PDF의 Fixed/Move 구분이 코드의 Main/Sub로 통합·재정의되었을 가능성.
    • PDF의 Patrol 모듈은 코드에 별도 존재하지 않고 MonsterGroup 내부에 통합된 것으로 보임.
    • 코드의 Escape는 PDF의 “탈출 지점” 운영을 모듈화한 항목.
  • 본문(systems/map-module.mdx)은 코드 기준 6종을 채택했다.
  • 결정 필요: PDF의 분류를 코드 기준으로 재기술할지, 코드를 PDF에 맞춰 재구성할지.

세션 시간 초과 처리 — 해소 (2026-05-21)

섹션 제목: “세션 시간 초과 처리 — 해소 (2026-05-21)”
  • 결정: 사망과 동일 처리 (현재 코드 동작 채택). 일관성·단순성 우선.
  • 자발적 탈출 포기도 동일.

Hunger / Thirst의 HP 직접 감소 — 해소 (2026-05-21)

섹션 제목: “Hunger / Thirst의 HP 직접 감소 — 해소 (2026-05-21)”
  • 결정: HP 직접 감소 채택 (코드 동작 그대로). PDF에는 효과 미정이었으나 코드 운영을 본문 기준으로 채택.
  • 임계치·초당 감소량·회복 수단은 밸런싱 단계 (open-questions에 잔존).
  • PDF: 명시 없음.
  • 코드 (PlayerHpLossCause.HpConsumption): HP 손실 원인의 한 종류로 존재. 스킬·아이템·재료가 HP를 비용으로 사용하는 케이스로 추정.
  • 본문(systems/combat.mdx §9)에 코드 기준으로 명시했다.
  • 결정 필요: 어떤 액션이 HpConsumption을 일으키는지 정의.

Patrol(정찰) 모듈 — 부분 확정 (2026-05-21)

섹션 제목: “Patrol(정찰) 모듈 — 부분 확정 (2026-05-21)”
  • 결정: 현재는 코드 그대로 MonsterGroup 내부 운영. 독립 Patrol 모듈 도입은 추후 결정.
  • 그룹·몬스터 시스템이 충분히 자랄 때 재검토.

모듈 관리 테이블의 Min–Max 추첨

섹션 제목: “모듈 관리 테이블의 Min–Max 추첨”
  • PDF: 존(Zone) 단위와 모듈 단위 모두 Min–Max 추첨 모델 제시 (예: Move 23개, Monster 35개).
  • 코드: MapModuleTableData는 모듈마다 monsterGroupIDs[]/itemGroupIDs[]/chestGroupIDs[]를 직접 명시하는 방식. Min–Max 추첨 로직이 어디서 적용되는지(또는 적용 예정 여부)가 코드에서 명확하지 않음.
  • 결정 필요: 현재 운영에서 Min–Max 추첨을 사용하지 않는 것인지, 아직 미구현인지, 다른 곳에 있는 것인지.

MentalPointBar / PenaltyPointBar — 해소 (2026-05-21)

섹션 제목: “MentalPointBar / PenaltyPointBar — 해소 (2026-05-21)”
  • MentalPointBar (정신력) = 두려움·공포 누적 자원. 도깨비·괴람 노출로 감소, 0% 도달 시 멘탈 붕괴 (환각·컨트롤 상실). 다크 판타지 핵심 압박. 자연 회복 + 안전 지점 회복.
  • PenaltyPointBar (디버프 축적) = 독·저주 같은 디버프의 고정 축적값. 임계 도달 시 효과 발동. 해독·정화·시간으로 차감.
  • 본문 승격: UI/UX §1 HUD에 반영.

Chest 해제 — 시간 기반 (PDF 미명시)

섹션 제목: “Chest 해제 — 시간 기반 (PDF 미명시)”
  • 코드 (ChestInfoTableData.unlockTime/minUnlockTime): 상자 해제가 시간 기반 점유 메커니즘.
  • PDF: LockedChest 해제 방식 미정 표기.
  • 본문(tables/map-monster-tables.mdx §6)에 코드 기준으로 시간 기반으로 확정.
  • 결정 필요: unlockTime을 단축하는 스탯·아이템·스킬 (예: dexterity 영향) 정의.
  • 결정: 아주 나중에. 무기 자체에 속성 부착 없음, 부가 아이템(부적·주문 등) 형태로만 도입 검토.
  • WeaponTableData.elementType/elementDamage 코드 필드는 그대로 두되 운영 안 함.

일반 치명타 (criticalRate) — 보류 (2026-05-21)

섹션 제목: “일반 치명타 (criticalRate) — 보류 (2026-05-21)”
  • 결정: 추후 결정. 현재는 앞잡·뒤잡만 운영. criticalRate 필드는 보존.

누락된 시스템 — 부분 해소 (2026-05-21)

섹션 제목: “누락된 시스템 — 부분 해소 (2026-05-21)”
  • 방어 흡수율 (physicsAbsorption/elementAbsorption) → 정식 도입 확정. 데미지 계산: 방패 막기 → 방어력 감산 → 흡수율 곱적용 순서.
  • 소모품 캐스팅 (preDelay) → 정식 도입 확정. 모든 Utility 아이템이 사용 시 preDelay 동안 동작 잠금.
  • 은밀 이동 (covertMovement) → 소음 감소율 + 특수 은행 특성치 복합 정의. 기본은 발생 dB 감소, 임계 이상 몬스터는 시야·청각 회피.
  • 일반 치명타·속성/원소는 보류 (상단 항목 참조).

태그 시스템 — 분류 만능 오용 & 비대칭 기본값 트랩

섹션 제목: “태그 시스템 — 분류 만능 오용 & 비대칭 기본값 트랩”
  • 기획 의도: 태그는 의미 시너지 전용 (지역·컨셉·문화·재료 등). 카테고리·등급·슬롯은 전용 컬럼. 매칭은 같은 계열 OR / 다른 계열 AND.
  • 코드 (ItemTag.cs): 매칭 알고리즘은 의도와 일치 (line 238~243). 그러나 계열 5종(MainCategory/SubCategory/Tier/Parts/MonsterType)이 모두 분류·슬롯·등급 중복으로 채워져 있어 의미 시너지 자리가 0개.
  • 빈 칸 처리 버그: 의도는 **양쪽 빈 칸 모두 통과(대칭)**인데, 코드는 Entity.Matches에서 Entity 빈 계열을 fail 처리 → 의미 계열(예: region) 도입 시 그 축을 안 적은 기존 아이템이 부당하게 누락.
  • Query 측 None→All 자동 채움(line 358~377)은 결과상 통과라 의도와 같으나, Entity 측 fail과 짝이 안 맞아 비대칭. 수정 지점은 Entity 쪽.
  • 본문(systems/tags.mdx)에 의도·매칭 규칙·AS-IS/TO-BE·마이그레이션 메모를 정리.
  • 결정 필요: 분류 중복 enum 제거 시점, Any 명시 토큰 도입, 의미 계열 어휘 확정.

드랍 파이프라인 — 100% 드랍 & 같은 아이템 폭주 (2026-05-28)

섹션 제목: “드랍 파이프라인 — 100% 드랍 & 같은 아이템 폭주 (2026-05-28)”
  • 증상: 몹이 착용 아이템을 100% 드랍 + 스택 안 되는 빗자루가 한 시체에 5개씩 반복 등장.
  • 원인 (코드):
    1. Corpse.Setup — 후보 리스트를 전부 인벤토리에 추가. 노출 확률(§3.1) 미구현 → 100% 드랍.
    2. ItemManager.GetDropMiscItemInfoList 스택 분배 루프(line 9821032) — 스택 불가(stack=1) 아이템을 구분 안 함. 스택 포인트 배정 시 plusedCount>stack이 되어 “새 칸 생성” 분기(line 10071021)로 빠져 칸 복제 → 빗자루 5개. (종류 추첨 단계는 Remove로 1차 중복 제거가 있어 정상 — 태그·중복검사 문제 아님.)
    3. 잡템 풀이 6개 카테고리를 한 리스트로 합쳐 추첨 → 등록 수 많은 카테고리 독점.
    4. 스택 분배가 균등 무작위(RandomElement) → 한 아이템에 쏠림.
    5. dropEquipKindsValue 한 컬럼이 무기·방어구 개수를 함께 결정 → 인위적 상관.
    6. RemoveWeaponItemKeysWithAvailableParts — 파츠 호환 무기 제외, 기획 근거 없음.
  • 방향: 패치가 아니라 전면 재설계로 해소. 신규 모델 systems/drop-redesign.mdx (생성→노출→품질 3단계, 슬롯 모델, 비스택 아이템 스택 분배 제외).
  • 본문(systems/item-loot-drop.mdx) “코드–기획 불일치” 절에 표로 정리.

태그 시스템 — 의미 계열 추가됨 + Material 어휘 충돌 (2026-05-28 갱신)

섹션 제목: “태그 시스템 — 의미 계열 추가됨 + Material 어휘 충돌 (2026-05-28 갱신)”
  • 지난 진단(의미 계열 0개) 이후 개발자가 의미 계열 4종(Area/Force/Location/Type)을 추가 → 방향 검증됨.
  • 신규 버그: MaterialMainCategory/SubCategory/Type 3계열에 중복 존재. FromTags 파싱 순서가 MainCategory로 먼저 잡아 Type:Material 의도가 가로채임. BuildEntityTags의 카테고리 자동 주입과 겹쳐 잡템 풀이 엉뚱하게 필터됨.
  • 분류 중복 계열 제거가 근본책. 상세는 systems/tags.mdx §8.1.1.
  • PDF: 무기 카테고리별 세부 슬롯명 정의 (도검: 검날/검자루/찌름끝/무게추, 대검: 5종).
  • 코드 (Category2): 모든 파츠가 MainParts 또는 SubParts 2종으로 분류. ChestGroup·ItemGroup도 mainPartsQueryTags/subPartsQueryTags 2축으로 드랍 추첨.
  • PartsTableData.partsType/availableParts 컬럼이 PDF의 세부 슬롯명을 표현할 가능성 있지만 운영 명확하지 않음.
  • 본문(systems/parts.mdx)은 코드 기준 2분류를 본문, PDF의 세부 슬롯은 컨셉 예시로 적었다.
  • 결정 필요: 세부 슬롯명을 데이터(태그/partsType)로 운영할지, 코드 enum을 확장할지.
  • PDF: 손재주는 Precision 스테이터스에 영향을 받는다고 표기.
  • 코드 (CharacterStatusTableData): Precision이 없고 Agility 기반 dexterity 스탯이 손재주를 담당.
  • 본문은 코드 기준 dexterity = f(Agility)로 적었다.
  • 결정 필요: PDF의 Precision을 도입할지, Agility 기반 운영을 유지할지.

뒤잡·질주공격·차지공격 — 해소 (2026-05-21)

섹션 제목: “뒤잡·질주공격·차지공격 — 해소 (2026-05-21)”
  • 결정: 세 시스템 모두 정식 채택. 코드 구현 그대로 운영.
  • 뒤잡: 무자각 상태 + 후면 공격 (CheckBackFatalAttackCoroutine 자동 체크).
  • 질주 공격: 질주 중 공격 입력 → sprintAttackDamageRate 적용.
  • 차지 공격: 공격 버튼 홀드 → 차지 → chargeAttackDamageRate 적용.
  • 전투 시스템 치명타·차지 공격 페이지에 본문 승격 완료.
  • 결정: ID/태그 기반 데이터 주도형 채택. NPC 마스터 시트를 진실의 원천으로.
  • 후속 작업: NPCType enum 마이그레이션 (Merchant01/02 → NPC ID 문자열 참조).
  • NPC 마스터 시트 생성 필요 (tables 영역 다음 작업).
  • PDF: Before1, Before2 — 2그룹 (그룹 끼리 OR, 그룹 안 AND).
  • 코드 (MissionConditionTableData): condition1, condition2, condition3 — 3그룹.
  • 본문은 코드 기준 3그룹으로 적었다.
  • 결정 필요: 3그룹 운영의 의도된 확장인지, PDF 모델로 다시 줄일지.
  • 코드: Map02.cs 클래스 파일은 존재하나 MapType.enum에는 None/Map01만 등록.
  • 결정 필요: Map02의 향후 등록 계획과 운영 단계.

(아직 기록된 일반 리스크 없음)