전투 시스템

시너지 7종의 값 티어, 중첩 판정, 속성 상성 배율, 전투력 페널티, 피해 계산식. 규칙 대부분은 엔진 원본 데이터로 확정됐고, 커뮤니티 연구는 따로 표기해 병기한다.

원본 데이터커뮤니티상충 병기

피해 배수 체인

kernel.rs:137-148 · 10항 전부 곱연산 · 최종 floor() 후 max(0)

#	항	식	조건
1	공격력	attack_point	—
2	스킬 계수	damage_multiplier	스킬별
3	최종 피해	1 + final_damage_rate	—
4	방어 감쇠	1 / (1 + ln(1 + 방어력/500))	—
5	속성	1 + 보너스 또는 1 / (1 + 감소)	배타적 분기
6	스킬증폭	1 + ability_amplify	—
7	피해감소	1 − target.damage_decrease	screen 합성으로 ≤1 보장
8	보스	1 + boss_damage_rate	대상이 보스일 때만
9	치명	1 + 치명피해 × 스택수	스택 > 0 일 때만
10	전투력 페널티	combat_power_penalty_damage_multiplier	대상이 Enemy일 때만

힐은 별도 계산이다 — heal = 공격력 × 스킬계수 × (1 + 스킬증폭). 방어 감쇠 · 속성 · 치명타가 전부 관여하지 않는다.

시너지 7종 값 티어

resource.json §modifiers MODIFIERTYPE_SYNERGY_MODIFIER 54행 · 게임 내 문구와 8건 교차검증

원본 데이터

시너지 7종의 값 형태는 일원화되어 있지 않다

add_synergy가 두 계열로 분기한다. 개수형 4종(관통·연쇄·다발·연타)은 truncate_to_int32로 정수 절삭되고, 배율형 3종(탄속·범위·지속)은 float를 유지해 %가 된다. 따라서 "시너지 7종의 증가율(%)"이라는 질문 자체가 성립하지 않는 시너지가 4종 존재한다.

개수형 4종정수 절삭 · 단위 = 회 / 개

시너지	티어 전량	그룹	이론 최대
관통	+2회 / +3회	1	+3회
연쇄	+1회 / +2회	2	+4회
다발	+1개 / +2개 / +3개	1	+3개
연타	+1회 / +2회	1	+2회

강화 대상 — 관통: 유효 타수 (HIT_COUNT_LIMIT) · 연쇄: 연쇄작용 횟수 (REPRODUCE_COUNT) · 다발: 사용당 투사체 수 (SPAWN_COUNT) · 연타: 연속발동 횟수 (MAX_SPAWN_COUNT)

배율형 3종float 유지 · 단위 = %

시너지	티어 전량	그룹	이론 최대
탄속	+30% / +50% / +75% / +100%	2	+150%
범위	+20% / +30% / +50% / +70%	2	+100%
지속	+25% / +40% / +75%	2	+115%

강화 대상 — 탄속: 투사체 속도 · 최고 · 최저 · 선회 속도 · 범위: 효과 반경 · 영역 · 각도 · 지속: 유지 시간 + 버프/디버프 51종의 지속시간

"이론 최대"는 그룹마다 최고 티어를 하나씩 보유했다고 가정한 상한이다. 실제로 한 팀에서 두 그룹을 동시에 확보할 수 있는지는 편성 문제다. 관통 · 다발 · 연타는 경쟁 그룹이 1개뿐인데, 이는 영구 패시브형(펫) 시너지가 없기 때문이며 아래 "강화 펫 없음"과 정확히 같은 사실의 다른 표현이다.

시너지 수급 분포

70종 중 주는 쿠키는 18종뿐 · 받는 쿠키 합 74 (2개 동시 수혜 4종 포함)

시너지	주는 쿠키	받는 쿠키	강화 펫
범위	4	18	사바나나 사자(SSR)
지속	3	15	와사비 문어(SSR)
다발	3	10	없음
연타	2	12	없음
탄속	2	8	털뭉치 멍뭉이(SSR)
관통	2	6	없음
연쇄	2	5	치즈뭉치 고양이(SSR)
합계	18	74	4종

2개를 동시에 받는 쿠키 4종 — 전갈맛(다발+지속) · 쿨링민트맛(다발+지속) · 마들렌맛(탄속+범위) · 도넛행성 에일리언 도넛킹(연타+지속). 펫 시너지는 passiveFilterId 1209506291 = 아군 전체라 거리·범위 조건이 없다. 쿠키 공급자가 "주변 아군"·"가까운 아군" 조건에 묶이는 것과 대조된다.

중첩 판정 규칙

stat_systems.rs:83 recalculate_character_modifier_groups · bonus.rs:320

원본 데이터

경쟁 단위는 스탯이 아니라 modifierGroup이다

소스 주석 원문: "그룹의 어느 모디파이어가 활성인지 정한다. 한 그룹에서 한 번에 하나만 적용된다. 값이 가장 큰 하나이며, 동점이면 뒤쪽 항목이다. 상태 트리거에 걸린 모디파이어는 트리거가 꺼진 동안 함께 꺼진다." 판정에 스택 수는 곱해지지 않는다. 나머지는 enabled = false가 된다.

조합	판정
시너지 ↔ 시너지 (같은 그룹)	최고 1개만 — modifyValue 최대, 동점이면 테이블 뒤쪽
시너지 ↔ 시너지 (다른 그룹)	가산 — 정수형은 정수 덧셈, 배율형은 float 덧셈
시너지 ↔ 시너지 (다른 종류)	완전 독립 슬롯. 7종이 서로 간섭하지 않음
버프 ↔ 버프 (같은 그룹)	최고 1개만. 스택 수는 판정에 미반영
버프 ↔ 버프 (다른 그룹, 같은 스탯이어도)	같은 raw 슬롯에 가산 — 38개 정수 슬롯 단순 덧셈
버프 ↔ 버프 (피해감소 계열)	screen 합성 a+b−ab, [0,1] 클램프
버프 ↔ 버프 (modifierGroup = 0)	경쟁 없음. 전부 적용
시너지 ↔ 버프	완전 독립 파이프라인 (SynergyAppliedData vs CombatBonusProperty)
같은 id 재적용	스택 +1 (maxStack 클램프), 효과는 스택 선형 배수
_ADDITION ↔ _MULTIPLIER	승산 아님 — addition + base×(1 + Σmultiplier)

사례 — 마카롱 치확 12%×10스택이 오렌지 60%×1스택에 진다

마카롱맛비활성화

치명확률 증가 12% · maxStack 10

120%실효 (12% × 10스택)

10스택을 다 쌓아 실효 120%여도 판정값은 단일 값 1200이다. 스택 수는 그룹 승자 판정에 곱해지지 않는다.

오렌지맛적용

치명확률 증가 60% · maxStack 1

60%실효 (60% × 1스택)

판정값 6000이 1200을 이긴다. 두 버프는 동일 그룹 2109530977(치명확률 증가 버프 18행)에 있다.

이 사례는 커뮤니티 DC 갤 FAQ(공지 5438)의 "마카롱 치명타 확률 12% + 오렌지 치명타 확률 60% = 60%"가 먼저 지적한 것이고, 이후 원본 데이터로 정답임이 확인됐다.

예외

피해감소만 screen 합성 — 30% + 30% = 51%

피해감소 계열은 가산도 최고값 선택도 아닌 screen(a, b) = a + b − ab이며 [0, 1] 클램프가 걸린다. 0.3 + 0.3 − 0.09 = 0.51 → 51%. 구조상 절대 100%를 넘을 수 없다.

그룹이 다르면

가산되어 연쇄 +4회 · 탄속 +150%까지 간다

"시너지는 중첩이 전혀 안 된다"는 통설은 정확하지 않다. 같은 시너지라도 modifierGroup이 다르면(버프 그룹 + 펫 패시브 그룹) 가산된다. 그래서 이론 최대치가 연쇄 +4회 · 탄속 +150% · 범위 +100% · 지속 +115%까지 나온다. 같은 그룹 안에서만 최고 1개 규칙이다.

상충 병기

"가장 최근 것만 적용" 주장은 원본과 다르다 — 다만 관측 경위는 설명된다

· 크럼블 헬퍼 — "겹쳐도 쌓이지 않고 더 센 쪽 하나만 켜집니다"

· 훈TV — "효과는 하나만 적용되고 나머지는 무효화" (선택 기준은 미명시)

· 커뮤니티 DC 9127 — "중복되지 않고 가장 최근 것만 적용"

원본 판정은 값 기준이며 적용 순서·시전 시점은 관여하지 않는다. 단 동점일 때는 테이블 뒤쪽이 이기므로, 같은 티어 공급자 둘을 넣은 상황에서는 결과가 "나중 것"처럼 보일 수 있다. 편성 결론: 중복 공급자는 무해한 잉여다. 약한 공급자를 더 넣어도 강한 쪽이 항상 이기므로 손해가 아니다.

남은 공백

어느 쿠키가 어느 티어를 거는지는 미확인

값 티어 자체는 전량 확정됐지만, 쿠키 ↔ 티어 매핑은 프리팹 데이터 부재로 확인되지 않았다."이 공급자가 저 공급자보다 센가"는 실사용에서 아직 답할 수 없다. 또 소비 공식의 synergy_multiplier는 스킬 프리팹이 필드별로 저작하므로(기본 0.0), 시너지 +50%를 받아도 해당 필드 계수가 0.5면 실효는 +25%다.

속성 상성

property.rs:28 is_element_strong_against · gameSettings combatConstantBaseElementDamage*

3속성 순환 — 가위바위보식

  불 ──→ 풀
  ↑        │
  │        ↓
  물 ←─────┘

2속성 상호 — 양쪽 모두 주고 받는다

  빛 ←──→ 어둠

불→풀→물→불, 그리고 빛↔어둠. 역방향은 성립하지 않는다.

원본 데이터

두 항은 합산되지 않는 배타적 분기다

attack_element_bonus     = 공격자 우위이면 (0.15 + 속성피해), 아니면 0
defense_element_decrease = 방어자 우위이면 (0.0  + 속성방어), 아니면 0

element_factor = (defense_element_decrease > 0)
               ? 1 / (1 + defense_element_decrease)
               : 1 + attack_element_bonus

소스 주석 원문: "방어자에게 속성 우위가 있으면 공격자의 속성 보너스는 계산에 전혀 들어가지 않는다. 둘은 합산되지 않는다."

공격자 우위 추가 피해

+15%

combatConstantBaseElementDamageIncrease = 1500 bp

속성 열세 기본 감소

combatConstantBaseElementDamageDecrease = 0 bp

힐에 적용되는 속성 계수

없음

heal = 공격력 × 스킬계수 × (1+스킬증폭)

상황	element_factor	실효
공격자 우위 (예: 불 → 풀)	1.15 + 속성피해	+15%
방어자 우위 (예: 풀 → 불), 방어자 속성방어 = 0	1.0	감소 없음
방어자 우위, 방어자 속성방어 d > 0	1 / (1+d)	d=0.2 → ×0.833
무관계 (예: 불 → 물)	1.0	없음
빛 ↔ 어둠 (양쪽 우위), 방어자 속성방어 = 0	1.15	공격자 +15%
빛 ↔ 어둠, 방어자 속성방어 d > 0	1 / (1+d)	공격자 +15%가 완전히 소멸

반직관

속성 열세라는 사실만으로는 피해가 전혀 줄지 않는다

base_element_damage_decrease 필드는 실재하지만 출하값이 0이다. 감소는 오직 방어자의 「속성방어」 스탯이 0보다 클 때만 발동한다. 그리고 그 순간 빛↔어둠 상호 우위 상황에서는 공격자의 +15%가 통째로 사라진다 — 두 항이 배타적 분기이기 때문이다.

적용 범위

메인 스테이지 보스전에서는 상성이 작동하지 않는다

monsters 기준 메인 스테이지 보스 37슬롯이 전부 무속성이다. 상성은 속성을 보유한 적이 나오는 던전·이벤트에서만 의미가 있다.

커뮤니티 DC 갤 32255의 자원 던전 약점 속성 정리 — 경험치=빛 / 코인=어둠 / 반죽=풀 / 연구석=물 / 룬결정=불. 단일 제보이며 던전 테이블에 속성 필드 자체가 없어 원본 미확인이다.

전투력 페널티 8구간

gameSettings combatPowerDamagePenaltyPve* · basis point ÷10,000

권장 전투력 대비	최종 피해	원본 필드	원시값
10% 미만	1%	combatPowerDamagePenaltyPveUnder10p	100
10% 이상	5%	...PveUnder20p	500
20% 이상	15%	...PveUnder40p	1,500
40% 이상	35%	...PveUnder60p	3,500
60% 이상	55%	...PveUnder80p	5,500
80% 이상	75%	...PveUnder100p	7,500
100% 이상	100%	...PveUnder120p	10,000
120% 이상	120%	...Pve120porAbove	12,000

경계 판정

99%면 곧바로 75%로 꺾인다

경계는 미만(<) 판정이다. 비율이 정확히 1.0이면 "100% 이상 120% 미만" 구간 → 배율 1.00. 120%가 상한이라 1.2배를 넘겨도 증폭은 1.20배에서 고정된다. 또 플레이어가 적에게 주는 피해에만 적용된다 — 적→플레이어 피해에는 붙지 않는다.

아레나

PvP는 8개 구간 전부 ×1.0이라 무효

combatPowerDamagePenaltyPvp* 8구간이 전부 원시값 10,000으로 출하됐다. 소스 주석 원문: "모든 아레나 구간이 10,000으로 출하되므로, 평가되지만 아무것도 바꾸지 않는다."메인 스테이지 5,040행 중 권장 전투력이 0인 행은 하나도 없어 전 스테이지가 보정 대상이다.

역할 계수와 전투력 산출

power.rs:57-90 · 개인별 산출 후 floor, 팀 전투력 = 개인 floor값 단순 합

역할	원본 필드	원시값(bp)	계수
방어형 (Tanker)	combatPowerConstantTanker	10,000	1.000
돌격형 (Attacker)	combatPowerConstantAttacker	10,270	1.027
지원형 (Supporter)	combatPowerConstantSupporter	10,420	1.042
사격형 (Shooter)	combatPowerConstantShooter	10,950	1.095

offense  = 공격력 × (치명피해 × 치명확률 + 1)
         × √(명중/500 + 1) × √(집중/500 + 1)
         × (명중률 + 1) × (집중확률 + 1)
         × (속성피해 × 0.5 + 1) × (보스피해 × 0.5 + 1)

survival = (치명저항 + 1) × 체력 × (ln(방어력/500 + 1) + 1)
         × √(회피/500 + 1) × √(저항/500 + 1)
         × (회피율 + 1) × (저항확률 + 1)

combined = √( survival/(1 − 피해감소)
             × 1/(1 − 속성방어×0.5) × offense )
utility  = (이동속도/100 + 스킬가속/100 + 스킬증폭) × 0.7

전투력   = floor( (utility + 1) × combined × 역할계수 )

보조 상수 — 명중/회피/집중/저항 제수 500 · 전투력용 방어 로그 제수 500 · 스킬가속·이동속도 제수 100 · 유틸리티 계수 0.7.

같은 스탯이라도 사격형(1.095)이 방어형(1.000)보다 표시 전투력이 9.5% 높게 찍힌다. 역할 계수는 표시값에만 붙는 보정이다.

핵심 공식 3종

쿨다운 · 방어 감쇠 · 치명타 초과분

원본 데이터쿨다운

실제 쿨타임 = 기본 쿨타임 × 100 / (100 + 스킬가속)

combatConstantAbilityHaste가 basis point 1,000,000 ÷ 10,000 = 100으로 확정됐다. 가속 1당 발동 빈도가 정확히 +1% 선형으로 오르지만, 쿨타임 감소량 자체는 체감한다.

커뮤니티 DC 31305 — 레딧에서 나온 이 공식을 작성자가 직접 클라이언트 데이터마이닝으로 재확인했고, 다단계 스킬의 「내부 쿨타임」은 스킬가속 적용을 받지 못한다고 덧붙였다. 쿠키마다 스킬가속 효율이 달라 보였던 원인으로 추정한다. 클라이언트 내부 저장 스케일은 표시값 × 10,000.

원본 데이터방어 감쇠

피해 배율 = 1 / (1 + ln(1 + 방어력 / 500))

combatConstantDefense = 500.0 확정. 소스 주석: "defense는 방어 감쇠 로그의 분모이며 0이어서는 안 된다." 수확 체감이 매우 강하다 — 방어력 100→1,000(10배)에서 감소율은 15.4%→52.3%지만, 1,000→10,000(10배)에서는 52.3%→75.3%다. 상한은 없으나 배율이 0에 도달하지는 않는다.

방어력	ln(1+def/500)	defense_factor	실효 피해 감소
0	0.000	1.0000	0.0%
100	0.182	0.8458	15.4%
250	0.405	0.7116	28.8%
500	0.693	0.5906	40.9%
1,000	1.099	0.4765	52.3%
2,000	1.609	0.3833	61.7%
3,000	1.946	0.3395	66.1%
5,000	2.398	0.2943	70.6%
10,000	3.045	0.2472	75.3%
20,000	3.714	0.2122	78.8%
50,000	4.615	0.1781	82.2%
100,000	5.303	0.1586	84.1%

원본 데이터치명타 — 100% 초과분은 버려지지 않는다

유효 치명확률 = 치명확률 − 대상 치명저항(감산). 정수부는 확정 스택, 소수부만 난수 굴림 대상이다. 따라서 치명확률 100% 초과분은 다중 치명타(multi-crit)로 전환된다. 치명피해 배율 = 1 + 치명피해 × 스택수로 스택 선형 가산이며 곱연산이 아니다. 소스 주석: "치명타 확률의 정수부는 확정 스택이고, 소수부만 굴림 대상이다. 따라서 확률이 1을 넘으면 다중 치명타가 된다."

유효 치명확률	확정 스택	굴림 대상	기대 배율
0.30	0	30% → 1스택	1.0 (70%) / 1.5 (30%)
1.00	1	0%	1.5 확정
1.75	1	75% → 2스택	1.5 (25%) / 2.0 (75%)
2.40	2	40% → 3스택	2.0 (60%) / 2.5 (40%)
3.00	3	0%	2.5 확정

위 표는 치명피해 0.5 기준 예시다. 유효 치명확률이 음수면 스택이 0 이하가 되어 배율은 1.0이다. 모든 쿠키 공통 기본값은 치명확률 10% / 치명피해 +50%이며 70종 전원 동일하다.

커뮤니티 연구 — 스증 vs 공증

네이버 카페 연구글 · 출처와 결론이 글마다 다르므로 병기한다

커뮤니티카페 24351 · 작성자 자체 계산 (댓글 검증 없음)

공격력 10,000 / 스킬 계수 30% 기준 6조건

#	조건	결과	기준 대비
1	버프 없음	3,000	기준값
2	스증 20%	3,600	+20%
3	공증 20%	3,600	+20%
4	석류 버프만	4,800	+60%
5	석류 + 스증 20%	5,400	+80%
6	석류 + 공증 20%	5,760	+92%

버퍼가 없으면 스증 20%와 공증 20%가 3,600으로 완전히 같다. 둘이 갈리는 것은 석류 버프가 붙은 뒤다 — 석류+스증 5,400 vs 석류+공증 5,760. 원문 결론: "수치가 커질수록 더 크게 차이가 나며, 한 옵션에만 몰두하기보다 두 수치를 적절히 배분하는 쪽이 약 1.07배 더 좋다".

표의 6개 수치는 원문이 제시한 설정(공격력 10,000 · 스킬 계수 30% · 스증/공증 20% · 석류 스증 +60%)에서 따라 나오는 값이다. 원문의 화면 캡처 자체는 이미지로만 남아 있다.

환산비 3종 — 상충하므로 병기한다

커뮤니티카페 15995

공증 1% = 스증 1.7424%

허브맛 쿠키(공격력 26,079 / 스킬 계수 35.1%)로 스증 4단계를 실측해 펫 스증은 합연산, 석류 스증은 곱연산임을 도출한 뒤 환산했다. 최종 스증 = 본인 최종 스증 + 석류 계수 × (1 + 석류 스증).

⚠️ 환산치 자체는 ChatGPT 계산 결과라고 본문이 명시한다.

커뮤니티카페 24362

공격력 1% = 스킬증폭 0.617%

168-30 보스 비겁한 쿠키를 기준으로 공증·스증 적용 계산식을 역산해 추정한 값이다.

⚠️ 상세 실험 방식은 외부 블로그 링크에 있고 본문에는 결론만 요약돼 있다. 댓글 없음.

커뮤니티카페 19380 댓글

스증이 약 1.24배 우위

"같은 치피일 때, 스증과 공증은 약 1.24배 차이로 스증이 조금 더 좋다. 대미지 공식에 의하면 치피가 가장 고점은 높다."

⚠️ 같은 작성자가 다른 글(15995)에서는 공증 우위 방향의 환산치를 냈다. 기준 쿠키·조건이 다르다.

상충 병기

세 값은 하나로 통일되지 않는다

글마다 기준 쿠키 · 계산식 · 실험 대상이 다르므로 임의로 판정하지 않고 그대로 병기한다. 세 연구가 공통으로 언급하는 판단 기준은 스킬 설명 문구다 — 스킬에 "공격력의 ~%"가 적혀 있으면 공증이 유리하고, 그냥 "스킬 공격력 ~%"면 스증이 유리하다(15995). 전갈맛은 예외로, 독침딜은 공증의 영향을 받고 지속딜도 공증·스증 양쪽 영향을 받아 "버그로 판단해 문의를 넣어둔 상태"라고 원문이 적고 있다.