협동 게임 연속 전멸을 막는 Revive Economy 설계: 부활 자원·무적 시간·구조 우선순위 조정법

핵심 요약

협동 게임의 연속 전멸은 플레이어의 실수보다 부활 자원 고갈, 구조 경로의 위험도, 다운 타이머, 부활 후 취약 시간이 서로 맞물리면서 발생하는 경우가 많습니다. Revive Economy는 부활 토큰의 공급과 소비뿐 아니라 구조 채널 시간, 무적 시간, 구조 대상의 우선순위까지 하나의 경제 시스템으로 다루는 설계 방법입니다.

핵심은 실패를 공짜로 만들지 않으면서도 한 번의 실수가 즉시 전멸로 이어지지 않도록 회복 여지를 계량하는 것입니다.

Revive Economy란 무엇인가?

Revive Economy는 플레이어가 쓰러졌을 때 팀이 지불하는 비용과 다시 전투에 복귀할 수 있는 회복 기회를 설계하는 체계입니다. 여기서 자원은 부활 토큰만 의미하지 않습니다.

• 부활 토큰 또는 공유 부활 횟수
• 다운 상태의 지속 시간
• 구조 상호작용의 채널 시간
• 구조 지점까지 이동하는 거리와 위험도
• 부활 직후의 무적 시간과 피해 감소
• 한 명의 구조자가 전투에서 이탈하는 기회비용
• 보스 페이즈나 퀘스트 목표를 포기하고 구조할지 판단하는 비용

이 요소들은 독립적으로 조정되지 않습니다. 예를 들어 부활 토큰을 넉넉하게 제공해도 구조 채널이 너무 길면 토큰은 사용되지 못한 채 전멸로 이어집니다. 반대로 무적 시간을 지나치게 길게 주면 쓰러짐의 비용이 약해지고 위험한 패턴을 무시하는 플레이가 효율적인 선택이 될 수 있습니다.

부활 경제를 구성하는 세 가지 변수

변수	의미	주요 파라미터	밸런싱 질문
공급	팀이 사용할 수 있는 부활 기회	시작 토큰, 회복 토큰, 체크포인트 보상	이 구간에서 몇 번의 실수를 흡수할 것인가?
마찰	부활을 실행하기 위해 치러야 하는 비용	이동 거리, 채널 시간, 적의 압박	구조가 긴장감을 유지하면서도 가능한가?
회복	부활 후 다시 정상적인 전투 상태로 돌아가는 과정	무적 시간, 체력, 위치, 쿨다운	부활한 플레이어가 즉시 다시 쓰러지지 않는가?

팀의 체감 난이도는 단순히 부활 횟수로 결정되지 않습니다. 실제로 중요한 값은 구조를 시도했을 때 성공할 수 있는 시간과 위험도입니다.

협동 게임의 연속 전멸은 왜 발생하는가?

연속 전멸은 첫 번째 쓰러짐 이후 선택지가 빠르게 줄어드는 구조에서 발생합니다. 다음과 같은 순환이 대표적입니다.

1. 플레이어 A가 쓰러진다.
2. 플레이어 B가 구조를 시도하면서 화력과 시야 통제가 약해진다.
3. 플레이어 B도 피해를 받아 다운된다.
4. 남은 플레이어가 둘을 동시에 구조하려다 이동 경로와 채널 시간이 부족해진다.
5. 부활 자원을 사용하지 못하거나 모두 소진한 뒤 전멸한다.

이 문제는 실패의 난이도가 높아서만 발생하지 않습니다. 팀이 회복할 수 있는 시간이 실제로 음수가 되는 회복 불가능 구간이 존재하기 때문입니다.

구조 가능성을 계산하는 방법

구조 설계에서는 다운 타이머만 보지 말고 이동, 채널, 위협 회피 시간을 분리해 측정해야 합니다.

$$M_{\text{rescue}} = T_{\text{bleedout}} - T_{\text{travel}} - T_{\text{channel}} - T_{\text{threat}}$$

• $M_{\text{rescue}} > 0$: 이론상 구조 가능
• $M_{\text{rescue}} \approx 0$: 특정 클래스나 숙련자만 구조 가능
• $M_{\text{rescue}} < 0$: 구조 명령이 존재해도 실질적으로 전멸을 기다리는 상태

이 식은 이동, 채널, 추가 위협 회피 시간이 순차적으로 발생한다고 가정한 단순 모델입니다. 일부 시간이 겹친다면 중복해서 빼지 말고 실제 측정한 추가 소요 시간만 $T_{\text{threat}}$에 포함합니다. 플레이어가 구조 버튼을 누르는 데 걸리는 시간만 채널 시간으로 계산하면 실제 난이도를 과소평가하게 됩니다.

부활 자원은 어떻게 설계할까?

1단계: 자원의 소유 단위를 결정한다

먼저 부활 자원이 개인 소유인지 팀 공유인지 결정해야 합니다.

방식	장점	위험	적합한 상황
개인 부활 횟수	역할별 책임과 차이가 명확함	자원이 많은 플레이어에게 구조가 편중될 수 있음	캐릭터별 생존 능력이 크게 다른 게임
팀 공유 토큰	팀이 함께 판단하므로 협동 의사결정이 쉬움	한 플레이어의 실수가 팀 자원을 소진할 수 있음	3~5인 파티 기반 PvE
부활 쿨다운	토큰 UI가 단순하고 반복 전투에 적합함	쿨다운 중에는 선택지가 급격히 줄어듦	짧은 전투와 잦은 교전이 있는 게임
무제한 구조 + 전투 페널티	전멸보다 재정비를 유도함	실패 비용이 약해질 수 있음	캐주얼 난이도와 탐험 중심 콘텐츠

초기 프로토타입에서는 팀 공유 토큰이 경제 흐름을 관찰하기 쉽습니다. 한 구간에서 팀이 몇 번의 다운을 감당할 수 있는지 바로 확인할 수 있기 때문입니다. 이후 클래스 특성이나 장비 차이를 강화해야 한다면 개인 부활 횟수 또는 개인 구조 스킬을 추가할 수 있습니다.

2단계: 부활 자원의 공급과 소비를 분리한다

부활 토큰의 기본값은 다음처럼 기록할 수 있습니다.

$$B_{\text{end}} = B_{\text{start}} + G_{\text{guaranteed}} + G_{\text{optional}} - U_{\text{revive}}$$

• $B_{\text{start}}$: 전투 또는 임무 시작 시 지급되는 토큰
• $G_{\text{guaranteed}}$: 체크포인트, 주요 목표 달성 등으로 보장되는 공급
• $G_{\text{optional}}$: 탐험이나 추가 목표로 얻는 선택적 공급
• $U_{\text{revive}}$: 실제 부활에 소비된 토큰

중요한 것은 공급원을 무작위 드롭에만 의존하지 않는 것입니다. 플레이어가 토큰을 모두 사용한 뒤 다음 회복 지점을 예측할 수 있어야 위험을 감수할지 안전하게 진행할지 판단할 수 있습니다.

권장되는 공급 구조는 다음과 같습니다.

• 전투 시작 시 최소 1회의 실수를 흡수할 수 있는 토큰을 제공한다.
• 긴 연속 전투 사이에는 최소 1개의 보장된 회복 지점을 둔다.
• 선택적 탐험 보상은 추가 안전성을 제공하되 필수 자원이 되지 않게 한다.
• 보스 직전에는 토큰을 완전히 회복시키기보다 일부만 보충해 긴장감을 남긴다.

이 수치는 모든 게임에 적용되는 정답이 아닙니다. 중요한 것은 플레이테스트에서 예상 다운 횟수와 보장 공급량의 비율을 확인하는 것입니다. 학습 구간에서는 보장 공급량이 예상 다운의 상당 부분을 흡수하도록 설정하고 숙련 구간에서는 선택적 보상과 구조 실행 능력이 결과를 바꾸도록 설계할 수 있습니다.

3단계: 자원 고갈 상태의 규칙을 정의한다

토큰이 0개가 되었을 때 게임이 곧바로 전멸 판정을 내릴 필요는 없습니다. 다음 중 하나를 명시적으로 선택해야 합니다.

토큰 0개 상태	플레이 경험
쓰러진 플레이어는 관전만 가능	가장 명확하지만 남은 인원의 부담이 큼
다음 체크포인트에서 자동 복귀	전멸 스트레스를 줄이고 진행성을 높임
구조는 가능하지만 체력과 장비에 큰 페널티	자원 소비와 회복의 절충안
제한 시간 동안 생존하면 임시 부활	위기 상황에서 역전 기회를 제공함

규칙을 숨기면 플레이어는 시스템이 고장 났다고 느낍니다. 토큰 수, 다음 회복 시점, 현재 다운 인원, 구조 가능 여부를 HUD와 월드 피드백으로 함께 보여주는 것이 좋습니다.

다운 타이머와 무적 시간은 어떻게 조정할까?

다운 타이머는 반응 시간이 아니라 의사결정 시간이다

다운 타이머가 너무 짧으면 플레이어는 구조를 판단할 틈 없이 사망합니다. 너무 길면 구조를 미루고 전투를 계속하는 것이 항상 유리해집니다. 따라서 타이머는 다음 세 구간으로 나누어 설계하는 편이 좋습니다.

1. 안정 구간: 팀이 위험을 평가하고 구조자를 선택하는 시간
2. 압박 구간: 구조를 지금 실행하지 않으면 자원을 잃는 시간
3. 임박 구간: 구조 실패가 임박했음을 강하게 전달하는 시간

예를 들어 전체 다운 타이머가 20초라면 처음 8초는 상태 확인과 위치 조정에 사용할 수 있어야 합니다. 다음 8초에는 구조를 실행해야 하고 마지막 4초에는 타이머 경고, 화면 효과, 음향으로 긴급성을 전달합니다. 실제 수치는 전투의 평균 이동 시간과 적 공격 주기에 맞춰 조정해야 합니다.

부활 후 무적 시간과 구조 중 무적 시간은 분리한다

두 종류의 무적을 같은 파라미터로 처리하면 문제가 생깁니다.

• 구조 채널 중 무적: 구조자가 채널을 완료하는 동안 피해를 무시하는 규칙
• 부활 직후 무적: 부활한 플레이어가 전투에 재진입할 시간을 얻는 규칙

구조 채널 중 무적은 구조의 위험을 크게 낮추므로 신중하게 사용해야 합니다. 대신 적의 공격 전조를 표시하거나 구조 위치에 짧은 피해 감소를 적용하는 방식이 더 세밀합니다.

부활 직후 무적 시간은 부활한 플레이어가 이동, 카메라 조정, 조작 재개를 할 수 있도록 주는 안전 구간입니다. 무적 시간이 적의 공격 전조보다 짧으면 부활 즉시 다시 피해를 입을 수 있습니다.

무적 시간이 적의 공격 전조 시간보다 짧다고 해서 곧바로 위험한 것은 아닙니다. 플레이어가 무적 시간이 끝난 뒤 공격을 피하거나 안전 지점으로 이동할 시간이 남는지, 그리고 부활 위치가 공격 범위 안인지 플레이테스트로 확인해야 합니다. 시간이 부족하다면 무적 시간을 무작정 늘리기보다 부활 위치를 조정하거나 부활 직후 이동을 돕는 방법을 검토할 수 있습니다.

무적 시간은 피해 면역보다 행동 창으로 설계한다

부활 직후의 무적 시간을 다음 행동에 연결하면 악용 가능성을 줄일 수 있습니다.

• 이동 입력을 시작하면 무적 시간이 서서히 감소한다.
• 공격을 시작하면 무적 시간이 종료된다.
• 구조 직후 첫 1초는 완전 무적을 주고, 다음 1초에는 80% 피해 감소를 적용한다.
• 보스의 즉사 판정이나 낙사 판정에는 별도 규칙을 둔다.

이렇게 하면 무적 시간이 공격을 위한 보너스가 아니라 전투에 재진입하기 위한 안전장치로 기능합니다.

구조 우선순위는 어떻게 조정할까?

구조 대상은 단순히 먼저 쓰러진 플레이어가 되어서는 안 됩니다. 팀의 생존 확률과 목표 달성 가능성을 기준으로 판단해야 합니다.

구조 우선순위 점수

구조 대상마다 다음과 같은 점수를 계산할 수 있습니다.

$$S_{\text{rescue}} = \frac{U \times V \times O \times Q}{C + 0.1}$$

• $U$: 남은 다운 시간에 따른 긴급도
• $V$: 부활 후 팀에 제공하는 전투 가치
• $O$: 현재 목표나 퀘스트에 대한 기여도
• $Q$: 구조 성공 가능성을 나타내는 안전도
• $C$: 구조 지점까지의 예상 비용과 이동 거리

점수는 절대적인 진실이 아니라 팀 의사결정을 돕는 기준입니다. 예를 들어 힐러가 쓰러졌다면 전투 가치 $V$가 높을 수 있지만 보스의 광역 공격 직전이라면 안전도 $Q$가 낮아 우선순위가 내려갈 수 있습니다.
점수를 서로 비교하려면 $U, V, O, Q$를 0~1 범위로 정규화하고 $C$도 같은 범위의 경로 비용 점수로 둡니다. 분모의 0.1은 0으로 나누는 일을 막는 예시 완충값이며 실제 데이터로 조정해야 합니다.

구조 우선순위에 사용할 수 있는 실제 요소는 다음과 같습니다.

• 남은 다운 시간
• 현재 체력과 방어 쿨다운
• 부활 후 사용할 수 있는 궁극기 또는 핵심 스킬
• 퀘스트 아이템을 소지했는지 여부
• 보스의 다음 패턴까지 남은 시간
• 구조자와 대상 사이의 경로 위험도
• 부활 위치가 안전 지점인지 여부
• 해당 플레이어가 팀의 유일한 원거리 또는 회복 역할인지 여부

자동 추천과 플레이어 선택을 함께 제공한다

자동 우선순위만 사용하면 플레이어가 시스템의 판단을 신뢰하지 않을 수 있습니다. 가장 실용적인 방식은 자동 추천을 기본값으로 제공하되 직접 대상을 변경할 수 있게 하는 것입니다.

// C# 10 스타일의 엔진 비종속 의사 코드
public int? SelectRescueTarget(IReadOnlyList<DownedPlayer> targets, RescueContext context)
{
    if (targets == null || targets.Count == 0)
        return null;

    return targets
        .OrderByDescending(target =>
            target.Urgency
            * target.TeamValue
            * target.ObjectiveValue
            * target.Safety
            / (target.PathCost + 0.1f))
        .ThenBy(target => target.DownTimeRemaining)
        .First()
        .PlayerId;
}

네트워크 협동 게임에서는 이 계산을 클라이언트의 장식 기능과 서버의 판정 기능으로 분리해야 합니다. 부활 토큰 차감, 다운 타이머 만료, 구조 채널 완료는 server-authoritative 상태로 처리하고 클라이언트는 예측 UI와 입력만 담당하게 합니다. 클라이언트가 계산한 우선순위는 추천용일 뿐이며 최종 대상과 토큰 소비는 서버가 검증해야 합니다.

구조 UX는 의사결정 비용을 줄여야 한다

구조 시스템의 UX는 다음 정보를 한 화면에서 읽을 수 있어야 합니다.

• 대상의 남은 다운 시간
• 구조까지 예상되는 거리 또는 경로
• 필요한 부활 토큰
• 다른 플레이어가 이미 구조 중인지 여부
• 구조 성공 시 예상되는 부활 위치
• 구조를 중단해야 하는 적 공격 경고

특히 여러 플레이어가 같은 대상을 구조하는 중복 입력을 막아야 합니다. 첫 번째 구조자가 채널을 시작하면 다른 플레이어에게 구조 중 표시를 보여주고 협동 구조를 지원한다면 채널 시간이 얼마나 줄어드는지 명확하게 전달해야 합니다.

구조 시스템의 상태 흐름은 어떻게 구현할까?

다운, 구조 중단, 사망, 부활을 별도 상태로 관리하면 예외 처리가 쉬워집니다.

flowchart TD
    A[HP 0] --> B[Downed]
    B -->|구조 채널 시작| C[Reviving]
    C -->|피해 또는 입력 취소| B
    C -->|채널 완료| D[Revived]
    B -->|다운 타이머 만료| E[Dead]
    D --> F[Post Revive Invulnerability]
    F --> G[전투 복귀]

상태 전환에는 명확한 권한과 이벤트를 둡니다.

• EnterDowned: 체력 0, 다운 타이머 시작, 이동과 스킬 제한
• StartRevive: 구조자와 대상의 거리, 시야, 토큰 상태 검증
• CancelRevive: 구조자 이동, 피해, 입력 취소, 대상 상태 변경 처리
• CompleteRevive: 서버에서 토큰 차감 후 부활 상태 확정
• ExpireDowned: 다운 타이머가 0이 되었을 때 사망 처리
• EnterPostRevive: 무적 시간, 체력, 위치, UI 상태 적용

동일한 프레임에 CompleteRevive와 ExpireDowned가 발생할 수 있으므로 서버에서는 이벤트 처리 순서를 명시해야 합니다. 일반적으로 서버의 단조 증가 시각과 상태 버전을 사용해 이미 종료된 다운 상태에 대한 부활 요청을 거부합니다.

부활 경제는 어떤 순서로 튜닝할까?

1단계: 전멸 이전의 회복 지점을 측정한다

먼저 다음 이벤트를 텔레메트리로 기록합니다.

이벤트	기록할 값
downed_at	플레이어 ID, 위치, 원인, 현재 페이즈
revive_started	구조자 ID, 대상 ID, 거리, 토큰 수
revive_cancelled	취소 원인, 채널 진행률, 적 공격 여부
revive_completed	채널 시간, 사용 토큰, 부활 위치
downed_expired	구조 시도 횟수, 마지막 안전도
wipe_at	전멸까지의 다운 순서와 시간 간격
post_revive_damage	부활 후 첫 피해까지의 시간

이 데이터를 보면 토큰이 부족한지 구조 시간이 부족한지 구분할 수 있습니다. 토큰이 남아 있는데도 전멸한다면 경제 공급보다 구조 마찰이나 안전도 문제가 먼저입니다.

2단계: 자원보다 구조 마찰을 먼저 조정한다

다음 순서로 조정하면 원인을 분리하기 쉽습니다.

1. 이동 거리와 구조 지점의 안전성을 조정한다.
2. 채널 시간을 적의 평균 공격 주기와 비교한다.
3. 다운 타이머가 의사결정 시간을 제공하는지 확인한다.
4. 부활 후 무적 시간과 부활 위치를 조정한다.
5. 마지막으로 시작 토큰과 회복 토큰을 조정한다.

구조가 거의 불가능한데 토큰만 늘리면 플레이어는 자원을 소모하지 못합니다. 먼저 구조가 가능한 선택지인지 확인한 뒤 부활 자원의 희소성을 조절해야 합니다.

3단계: 플레이테스트에서 세 가지 지표를 비교한다

핵심 지표는 평균 전멸 횟수 하나가 아닙니다.

• Revive Success Rate: 구조 시도 중 부활 완료 비율
• Chain Down Interval: 첫 다운부터 두 번째 다운까지의 시간
• Post Revive Survival: 부활 후 다시 쓰러지기까지의 시간

Revive Success Rate가 낮고 토큰 잔량이 높다면 구조 채널이나 위협도가 과도한 것입니다. Chain Down Interval이 짧다면 구조자가 전투에서 빠지는 동안 팀 방어가 무너지는지 확인해야 합니다. Post Revive Survival이 매우 짧다면 무적 시간보다 부활 위치, 체력, 적의 공격 전조가 문제일 수 있습니다.

자주 묻는 질문 FAQ

부활 토큰과 부활 쿨다운 중 무엇이 더 좋은가?

팀이 자원 사용 시점을 협의해야 하는 게임이라면 공유 토큰이 적합합니다. 짧은 교전이 반복되고 HUD를 단순하게 유지해야 한다면 쿨다운이 편리합니다. 두 방식을 동시에 사용한다면 토큰과 쿨다운의 역할이 겹치지 않도록 하나는 전투 단위 자원으로 다른 하나는 개인 스킬로 구분해야 합니다.

부활 직후 무적 시간은 몇 초가 적절한가?

고정된 정답은 없습니다. 부활한 플레이어가 카메라를 돌리고 위험 범위를 벗어나는 데 필요한 시간과 적의 공격 전조 시간을 비교해야 합니다. 무적 시간보다 공격 전조가 길다면 짧은 무적과 명확한 부활 위치만으로도 충분할 수 있습니다. 반대로 부활 위치가 고정되고 보스가 즉시 광역 공격을 사용한다면 무적 시간 또는 위치 보호가 필요합니다.

구조 우선순위를 자동으로 결정하면 플레이어의 자유가 줄어들지 않는가?

자동 결정이 아니라 자동 추천으로 제공하면 됩니다. 시스템은 남은 시간, 안전도, 역할 가치에 따라 기본 대상을 제시하고 플레이어는 핑이나 대상 변경 입력으로 선택을 바꿀 수 있어야 합니다. 추천 근거를 아이콘과 색상으로 보여주면 자동화가 통제권을 빼앗는 대신 판단을 보조하게 됩니다.

정리

Revive Economy의 목표는 모든 실수를 무효화하는 것이 아니라 팀이 실패를 해석하고 회복할 시간을 제공하는 것입니다. 부활 토큰의 공급량만 조절하면 전멸 문제의 절반만 다루게 됩니다.

먼저 $M_{\text{rescue}}$를 계산해 구조가 실제로 가능한지 확인하고 다운 타이머를 의사결정 시간으로 설계해야 합니다. 그다음 부활 후 무적 시간을 행동 재개 창으로 조정하고 구조 대상은 긴급도와 팀 가치와 안전도를 함께 고려해 추천합니다. 마지막으로 Revive Success Rate, Chain Down Interval, Post Revive Survival을 수집하면 감에 의존하지 않고 부활 시스템을 튜닝할 수 있습니다.

좋은 협동 게임의 부활 시스템은 전멸을 없애지 않습니다. 대신 한 번의 실수가 팀 전체의 선택지를 즉시 제거하지 않도록 경제적 완충 장치를 설계합니다.