공격·구르기·패리의 스태미너 비용과 회복 지연·재개

행동 비용과 다음 회복의 시작점을 함께 본다

DCB에서는 공격·구르기·패리에 스태미너를 한 번씩 사용한다. 공격의 기준 비용은 현재 오른손 무기의 데이터에서 가져올 수 있고, 구르기·패리는 공통 밸런스 설정을 사용한다. 여기에 맨몸·지게 착용 상태의 행동 배율과 적재 배율을 적용한다.

같은 비용을 차감해도 언제 회복을 허용하는지에 따라 연속 행동의 간격이 달라진다. 공격은 공격 흐름이 끝난 뒤, 구르기는 종료를 감지한 경로에서 회복 지연을 다시 시작한다. 패리에는 현재 이와 같은 종료 후 회복 재시작 처리가 없다. 세 행동을 모두 같은 회복 규칙으로 소개하면 실제 코드와 어긋난다.

2026년 10월 19일 DCB의 입력·플레이어·Animator 동작·장비 비용·카탈로그와 관련 커밋을 읽어 대조했다. 같은 날 배고픔·갈증의 단계와 스탯 보정도 추가로 확인했다. 글 날짜는 행동 배율을 지게 부담에 연결한 10월 1일 작업의 작성일이다. 회복 타이머와 구르기 안전장치 등은 그보다 앞선 작업이며 아래에 구분했다. 이번에는 DCB 코드·밸런스 값을 바꾸거나 Unity 컴파일·검사·Play Mode를 새로 실행하지 않았다.

기준 비용은 어디서 가져오는가

공통 행동 설정은 GameBalanceCatalog의 wanderer.actions에 있고, PlayerAttributeController.Initialize()와 ApplyBalance()를 통해 플레이어에 적용된다. 현재 저장된 기본 공격·구르기·패리 비용은 각각 10, 회복 지연은 0.3초다. 속성 컨트롤러 프리팹도 같은 값을 저장하고 있다.

공격은 ResolveAttackStaminaCost()에서 오른손 WeaponItemStatus.StaminaCost를 먼저 확인한다. 무기가 없거나 맨손 종류이거나 비용이 0 이하이면 기본 공격 비용 10으로 돌아간다. 따라서 무기 시트에 0을 적는 것만으로 무료 공격이 되지는 않는다. 장비 데이터의 StaminaCost는 무기 테이블의 staminaCost에서 들어온다.

Player.Attribute는 이 기준 비용에 ActionStaminaCostRate를 곱한다. 해당 배율은 착용 모드의 행동 배율과 적재 소모 곡선의 곱이다.

행동 비용 = 행동 기준 비용 × 착용 모드 행동 배율 × 적재 소모 배율

현재 맨몸 행동 배율 = 1.0
현재 지게 행동 배율 = 1.2
현재 저장된 적재 소모 배율 = 1.0

현재 적재 곡선은 배율 1이므로 짐을 추가로 실었다는 이유로 이 표의 비용이 더 늘지는 않는다. 착용 자체의 배율과 적재량에 따른 추가 배율은 구분한다. 지게 행동 배율을 적용한 결과가 소수일 수도 있어, 플레이어의 구르기·패리 비용 속성도 정수에서 실수로 바꿨다.

예를 들어 가상의 무기 비용이 17이라면 지게를 진 공격 비용은 17 × 1.2 = 20.4다. 17은 기존 비용 선택 검사에도 쓰인 예시이며 현재 게임에서 장착한 무기의 실제 값이나 실측 차감량이라는 뜻은 아니다.

행동 가능 판정은 전체 비용을 보유했는지와 다르다

일반 공격 입력·콤보 진입·구르기·패리는 각자의 다른 허용 조건과 함께 CanConsumeStamina()를 확인한다. 이 함수의 자원 조건은 현재 스태미너가 0보다 큰가다. 비용 12를 전부 낼 수 있는지 검사하는 구조는 아니다.

ConsumeStamina()는 양의 자원에서 비용을 빼고 음수가 되면 0으로 제한한다. 다른 조건을 충족한 지게 구르기를 스태미너 3에서 시작한다면, 비용 12 때문에 시작을 거절하는 대신 3을 모두 쓰고 0이 되는 계산이다. 이 예는 코드의 차감 규칙을 적용한 예상이며 이번 Play Mode 결과가 아니다.

또한 ConsumeStamina() 자체는 회복 타이머를 초기화하지 않는다. 차감 함수 호출과 회복 중단·재개는 서로 다른 경로다. 비용을 바꾸는 일과 행동 가능 조건을 바꾸는 일도 별도 조정으로 봐야 한다.

공격은 입력보다 Animator 상태 진입에 비용을 연결했다

일반 공격 입력의 StartPrimaryAttack()은 스태미너와 이동 상태를 확인해 일반 공격 또는 질주 공격 코루틴을 시작한다. 일반 Attack()은 공격 중 상태를 켜고 기존 회복 타이머를 끈다. 콤보를 진행할 때도 자원을 다시 확인하고 회복 중단을 유지한다.

실제 차감은 PlayerAnimatorSMB의 공격 상태 진입에서 DispatchPlayerAttackStarted()를 호출하고, 플레이어가 등록한 리스너가 ConsumeStamina(attackCost)를 실행하는 경로다. 기본 Wanderer 컨트롤러의 SMB 연결도 확인했다.

이 구조에서는 버튼을 눌렀다는 사실만으로 비용을 먼저 차감하지 않는다. 반대로 공격 상태에 들어갔다면 적중 여부를 기다리지 않는다. 빗나간 공격도 이 이벤트의 비용 대상이다. 콤보 역시 각 공격 상태의 진입을 기준으로 봐야 하며, 한 번의 공격 입력 묶음에 비용을 한 번만 낸다고 설명할 수 없다.

차징 준비 상태와 일반 공격·질주 공격의 이벤트 분기는 다르고, 처형 상태는 일반 공격 이벤트 분기에서 제외한다. 이 글의 비용 설명을 모든 특수 공격·활·처형의 공통 비용표로 확대하지 않는다. 무기별 실제 상태 전이와 이벤트 횟수는 실행 확인이 남아 있다.

일반 Attack()은 공격 흐름과 마지막 IsAttackToIdle 복귀를 기다린 뒤 IsAttacking을 내리고 PlayRegenStaminaCoroutine()을 호출한다. 일반 입력부터 차감을 거쳐 정상 종료하는 책임은 다음과 같이 나뉜다.

1. 입력 경로가 행동 시작 가능 여부를 확인한다.
2. 공격 코루틴이 회복을 중단하고 공격 흐름을 진행한다.
3. Animator 공격 상태 진입 이벤트가 현재 장비·착용 조건의 비용을 차감한다.
4. 공격 코루틴의 정상 종료 경로가 회복 지연을 다시 시작한다.

새 공격이나 다른 행동이 지연 중에 들어오면 그 행동의 중단 경로가 기존 타이머를 지운다. 중간 피격·행동 취소·무기 전환까지 모두 정상 종료와 같은 결과를 보장하는지는 별도 재현이 필요하다.

구르기는 시작 실패와 정상 종료를 나눠 복구한다

Roll()은 구르기 허용 여부와 양의 스태미너를 확인한다. 회피 방향을 정하고 질주를 취소한 뒤, 차감 직전 자원을 저장하고 구르기 비용을 먼저 차감한다. 이후 재구르기를 막고 회복을 끄며 애니메이션 트리거를 보낸다.

여기서는 트리거를 보낸 것과 실제 구르기 진입을 구분해야 했다. 현재 상태에서 Roll 전이가 불가능하면 트리거가 나중까지 남아 엉뚱한 시점에 구르거나, 대기 코루틴이 끝나지 않아 CanRoll=false와 무적이 남을 수 있었다. 7월 3일의 881770612 커밋에서 이 시작 실패를 복구하는 경로를 추가했다.

시작 대기 중 ModelController.IsRolling도 꺼져 있고 0.3초 이상 기다렸다면 트리거를 지운다. 저장한 스태미너로 복원하고 무적·회피 방향을 정리한 뒤 다시 구르기를 허용한다. 이어 회복 지연을 새로 시작하고 코루틴을 끝낸다. 이미 진입 전이가 시작됐다면 같은 타임아웃을 무조건 적용하지 않는다.

이때 0.3초는 구르기 시작 실패를 판단하는 상수다. 카탈로그의 회복 지연도 현재는 0.3초지만 서로 다른 값과 책임이다. 회복 지연을 조정한다고 시작 실패 제한이 같이 바뀌지는 않는다.

스태미너 복원은 비용만 더하는 방식이 아니라 차감 직전 값으로 대입하는 방식이다. 그 대기 중 다른 차감·회복이 겹쳤을 때의 결과는 따로 검증해야 한다. 구르기 전체를 언제 취소해도 비용을 환불하는 구조는 아니다.

정상 구르기는 Roll 상태에서 빠져나가는 전환을 감지한 경로에서 무적을 해제하고 회복 지연과 구르기 간격 처리를 시작한다. 회피 방향은 모션이 완전히 끝난 뒤 별도로 정리한다. 따라서 회복 지연 시작과 탈출 크로스페이드 종료를 같은 시점으로 보면 안 된다. 현재 구조가 방향 정리를 기다린 뒤 회복을 시작하도록 함께 미루는 것은 아니다.

회복 지연과 회복량은 별도로 계산한다

회복을 제어하는 공통 함수는 세 부분이다.

• RemoveRegenStaminaCoroutine()은 기존 지연 코루틴을 중단하고 회복 허용 플래그를 끈다.
• PlayRegenStaminaCoroutine()은 위 중단 처리를 먼저 호출한 뒤 새 지연 코루틴을 시작한다.
• RegenStaminaTimer()는 현재 적용된 지연을 기다리고 회복 허용 플래그를 켠다.

따라서 재시작 요청은 이전 대기 시간에 이어 붙이는 방식이 아니다. 새로 읽은 지연을 처음부터 기다린다. 대기가 시작된 후 설정값을 바꾼 경우 이미 만들어진 대기까지 자동 갱신하는 구조로 설명할 수도 없다.

flowchart TD
  A[공격 또는 구르기 시작] --> B[기존 회복 타이머와 허용 플래그 해제]
  B --> C[해당 행동의 종료 경로]
  C --> D[회복 지연을 새로 대기]
  D --> E[회복 허용 후 이동 소모가 없을 때 증가]

위 도식은 공격·구르기의 정상 종료 책임을 요약한 것이다. 패리에는 아래의 다른 경로가 있고, 실제 프레임별 재생을 촬영한 자료는 아니다.

실제 자원 증가는 플레이어의 FixedUpdate에서 처리한다. 초기화·생존·일시정지 등의 갱신 조건을 통과하고, 최대치 미만이며 회복 허용 플래그가 켜져 있고 이동 소모 중이 아니어야 한다. 최대치에 도달하면 회복 플래그를 끈다.

조건 반영 회복 시간 = 시트의 StaminaRegen × 배고픔 회복 시간 배율 × 갈증 회복 시간 배율
최종 초당 회복량 = 최대 스태미너 ÷ 조건 반영 회복 시간 × 착용·이동 중·적재 회복 배율
이번 스텝 회복량 = 최종 초당 회복량 × Time.fixedDeltaTime

여기서 StaminaRegen은 시트가 공급하는 회복 시간 성격의 값이며, 카탈로그의 StaminaRegenDelay와 다르다. 지연은 언제 회복을 허용할지, 회복량은 허용된 뒤 얼마나 채울지를 정한다. 실제 최대 자원·시트 값·배고픔과 갈증 등의 영향을 고정하지 않고 총 회복 시간을 숫자 하나로 단정하지 않는다.

이동 소모가 끝나는 StopLocomotionStaminaDrain()도 회복을 재개할 수 있다. 다만 공격·패리·구르기 중에는 여기서 타이머를 시작하지 않도록 조건을 둔다. 이 조건만 읽고 세 행동 모두 종료 시 재개가 구현돼 있다고 판단하면 안 된다. 실제 행동 종료 호출까지 이어서 확인해야 한다.

배고픔·갈증이 바꾸는 회복·운반 한도·이동·체력

HungerSystem과 ThirstSystem은 플레이어 생성 시 시작하며, 공통 PlayerNeedSystemBase가 현재 자원을 감소시키고 단계에 맞는 보정을 등록한다. 값은 카탈로그의 wanderer.needs.hunger와 thirst에서 읽는다. 문턱 25와 10은 최대치 대비 백분율이 아닌 현재 자원의 절대값이다. 정확히 25·10이어도 해당 단계에 들어간다.

2단계와 0에서도 1단계의 회복 패널티는 유지된다. 배고픔은 회복 시간과 운반 한도에, 갈증은 회복 시간과 이동 속도에 함께 영향을 준다. 현재 배고픔·갈증 보정은 앞에서 계산한 공격·구르기·패리의 차감 비용이나 0.3초 회복 지연을 직접 변경하지 않는다. 회복이 허용된 뒤 채워지는 양과 이동·운반 조건을 바꾼다.

회복 시간 ×2.1은 회복량 ×2.1이 아니다

PlayerStat은 보정마다 1 + modifierRate를 곱한다. 회복 패널티 1.1은 회복 시간을 1 + 1.1 = 2.1배로 늘리는 값이다. 10% 지연이라는 뜻이 아니다. 두 자원이 모두 25 이하이면 각각 등록한 보정이 곱해져 회복 시간은 2.1 × 2.1 = 4.41배, 초당 회복량은 다른 조건이 같을 때 정상의 약 **22.7%**가 된다.

예를 들어 최대 스태미너 100, 시트 회복 시간 5초를 가정하면 정상은 20/초, 배고픔·갈증이 모두 낮을 때는 100 ÷ (5 × 4.41) ≈ 4.54/초다. 여기에 지게를 지고 비용 없는 걷기를 하는 조건이라면 현재 회복 배율 0.8 × 0.6 = 0.48도 곱해 약 2.18/초가 된다. 100과 5초는 계산을 설명하는 가정이며 현재 플레이 실측값은 아니다. 이동 소모 중이거나 회복 허용 플래그가 꺼져 있으면 이 회복량을 적용하지 않는다.

운반 한도와 이동 속도는 별도 보정이다

배고픔의 WeightCapacity는 플레이어의 운반 가능 무게다. 지게 화물의 적재 용량 자체를 30% 줄이는 설정으로 설명할 수는 없다. 현재 무게가 줄어든 한도를 넘으면 과적 조건이 될 수 있고, 과적은 자원 감소를 더 빠르게 하는 내부 조건에도 연결된다.

갈증의 MoveSpeed 보정은 기존 속도 수정자에 등록돼 다른 수정자와 곱해진다. 기준 속도가 4.19이고 다른 수정자를 모두 제외한 계산이라면 갈증 보정 후 3.352가 된다. 실제 이동에는 인벤토리 무게·경사·물속·충돌 등이 더 관여하므로 이를 측정한 이동 속도로 사용하지 않는다. 인벤토리 무게·갈증·물속 감속의 중첩에서는 실제 프리팹 곡선, 한도 변경의 간접 영향, 물의 목표·적용 배율과 이동 경로를 이어서 설명한다.

자원 감소와 0 이후 체력 피해

평소 감소와 질주·과적 중 감소도 현재 설정에 포함된다. 아래 수치는 음식·물 보충과 외부 환경·상태 이상 수정자를 제외한 10초당 계산값이다. 실제 갱신은 고정 스텝 시간에 맞춰 나눠 적용한다.

질주·과적은 원인마다 ActiveDecayPer10s - BaseDecayPer10s를 더한다. 둘이 겹쳤을 때 4와 3을 단순한 최대값으로 고정하지 않는다. 이때 질주 통지는 StartSprint()·CancleSprint()에 연결되므로, 지게의 일반 달리기 MOVE_STATE를 같은 질주 조건으로 취급해서도 안 된다.

두 자원이 모두 0이고 생존·시스템 실행 조건을 유지하면 각각 2/초가 적용돼 합계 4/초의 체력 차감 경로가 된다. 이는 현재 설정의 합산이며 최신 실행에서 측정한 결과는 아니다. 체력 차감 함수는 일반 공격의 방어·피격 계산을 거치지 않고 자원을 줄인다. 로비에서는 자연 감소와 0일 때 체력 피해를 막지만, 이미 낮아진 수치에 따른 회복·운반·이동 보정까지 지우지는 않는다.

음식·물 등으로 문턱을 넘으면 다음 보정 갱신에서 해당 수정자를 해제한다. 같은 단계에서도 카탈로그 배율이 달라지면 적용했던 값과 비교해 다시 등록한다. 기본 능력치 보정은 현재 모두 0이고, CalcGritPenaltyReduction()도 0을 반환하므로 근성에 따른 패널티 완화를 적용 중이라고 쓰지 않았다. 코드의 오래된 주석에 남은 50·25 문턱이나 ‘연동 필요’ 안내 대신 현재 카탈로그·호출을 기준으로 확인했다.

이 절은 소스·저장값과 스탯 곱셈을 대조한 설명이다. 문턱 전후의 적용·해제, 두 회복 패널티와 지게 배율의 중첩, 과적 전환, 두 자원 0의 피해·사망·로비 예외는 이번 실행에서 재현하지 않았다.

패리는 비용과 모션 복구가 있지만 회복 경로는 다르다

Parry()는 무기 넣기 상태·장애물 동작·장비·중복 패리·구르기·처형 모션 등의 조건을 확인한 뒤, 양의 스태미너가 있으면 패리 비용을 차감한다. 이어 CancleSprint(), GuardOff(0f, false), 패리 코루틴 시작을 순서대로 호출한다.

패리 코루틴은 플레이어의 패리 플래그, 이동·회전 감속과 판정 콜라이더를 정리한다. 판정 창은 ParryWindowSMB가 담당하고, 코루틴에는 최대 1.5초의 상태 정리 제한이 있다. 모션 미배선 등으로 패리 상태가 계속 남는 문제를 다룬 별도 장치다.

스태미너 회복은 다음처럼 연결돼 있다.

따라서 현재 소스만 보면, 다른 경로가 타이머를 끊지 않고 이동 소모도 없다면 패리 종료 이전에 지연이 끝나 회복할 가능성이 있다. 반대로 이동 소모 종료 시점에 패리 플래그가 켜져 있으면 그 경로에서는 재개 요청을 생략한다. 이후 어떤 타이머가 남아 있는지는 호출 순서까지 기록해야 한다.

또한 이동 소모를 제외하는 TryGetMovingGait()의 조건에는 공격·구르기 등이 있지만 패리 플래그는 없다. 이동 요청과 비용 있는 걸음이 유지되는 조건에서는 패리의 이동 감속과 별개로 이동 소모가 이어지는지 확인할 필요가 있다. 실제 이동량 0과 이동 입력 없음도 같은 조건이 아니다.

이 내용은 소스에서 확인한 호출 차이와 그에 따른 예상이다. 패리 중 회복이나 추가 소모를 실제로 관찰했다고 쓰지 않았다. 패리 종료까지 회복을 막는 규칙으로 통일할지, 진입 후 일정 시간 뒤 회복을 허용할지는 아직 결정·수정하지 않았다. 1.5초 정리 장치도 비용 환불이나 회복 재시작까지 처리하지 않는다.

커밋에서 확인한 문제와 변경

패리 커밋의 과거 검증 기록은 판정 창 연결·장비 경로·몬스터 그로기 구조 등의 범위다. 이를 현재 패리의 비용·회복 시점까지 실행 검증했다는 근거로 사용하지 않았다. 구르기 안전장치도 현재 모든 피격·전이 조합의 복구를 새로 통과했다는 뜻은 아니다.

확인한 검사와 다음 실행에서 기록할 조건

PlayerEquipmentCombatStatTests에는 양수 무기 비용 우선, 0·음수·맨손·장비 없음의 기본 비용 복귀를 확인하는 검사가 있다. JigeCarryBurdenBalanceTests는 행동 배율과 적재 곡선의 곱을 검사한다. 기존 지게 부담 Play Mode 도구에는 적재 상태에서 구르기 호출 전후의 자원 차이를 비교하는 항목도 있다.

이번에는 이 검사들을 실행하지 않았다. 계산 검사와 도구가 있다는 사실만으로 Animator 이벤트 횟수나 패리 회복을 검증했다고 쓰지 않는다. 다음 항목은 미실행 재현 계획이다.

추가 확인한 GameBalanceCatalogTests에는 배고픔·갈증의 기본값, 단계 문턱, 질주·과적 감소량과 직렬화 연결 검사가 있다. 이 검사 역시 이번에는 실행하지 않았으며, 실제 스탯 적용·회복량·체력 피해의 플레이 재현과 구분한다.

비교에는 코드 ref, 실제 적용 카탈로그·무기 데이터, 시작 자원·착용·적재, 배고픔·갈증 등 보정 조건, 입력·상태 진입·차감·복귀·회복 시작 시각을 남긴다. 밸런싱 도구의 자원 설정과 상태 표시를 활용하되, 이벤트 횟수·타이머 요청 주체까지 모두 기존 창에서 기록해 준다고 가정하지 않는다.

담당 범위와 관련 분석

이 글에서 다룬 작업은 장비 비용의 적용, 착용·적재 배율, 차감과 회복 제어의 분리, 구르기 실패 복구와 패리 상태 정리다. 구르기 안전장치·패리 확장·지게 부담 커밋에는 Claude 공동 작성 기록이 있다. AI 보조를 받은 구현과 실제로 확보한 검증 근거를 구분했다. 이번 글 보완에서는 소스·저장값·diff를 대조했고 게임 동작 자체를 고치지는 않았다.

앞선 이동 전환·고갈 후 재입력은 지속 이동 소모와 입력 기록을 다룬다. 운반의 속도·스태미너 계산과 함께 보면 같은 자원을 쓰는 이동 비용과 행동 비용이 어디서 합쳐지는지 확인할 수 있다. 다음 이동 보정·행동 중 입력 제약 분석은 게임플레이 밸런싱과 제어 목록에서 이어진다.