로그라이크 덱빌딩 시스템 밸런싱 표 만드는 법
로그라이크 덱빌딩의 카드·적·보상·유물 데이터를 한 표에서 비교 가능한 지표로 바꾸는 방법을 설명합니다. 스프레드시트 수식과 시뮬레이션용 데이터 구조를 이용해 밸런싱 가설을 빠르게 검증합니다.
밸런싱 표의 목적은 숫자 관리가 아니다
로그라이크 덱빌딩에서 밸런싱 표는 카드의 수치를 나열하는 문서가 아니라 플레이어가 선택하는 전략의 효율을 비교하는 도구다. 비용 1의 공격 카드가 6 피해를 준다는 값만으로는 충분하지 않다. 같은 비용의 방어 카드, 덱 순환 카드, 상태이상 카드와 비교했을 때 어느 상황에서 우위인지까지 드러나야 한다.
처음부터 모든 조합을 완벽하게 계산하려 하면 표가 유지되지 않는다. 대신 다음 질문에 답할 수 있는 최소 지표부터 만든다.
- 이 카드는 기본 카드보다 언제 더 좋은가?
- 이 보상은 현재 덱에 실제로 들어갈 이유가 있는가?
- 이 적은 특정 전략만 과도하게 억제하거나 보상하지 않는가?
- 난이도가 층과 전투 종류에 따라 예측 가능한 폭으로 상승하는가?
1. 비교 기준을 먼저 고정한다
카드의 가치를 비교하려면 기준 카드와 기준 상황이 필요하다. 예를 들어 기본 공격이 비용 1에 피해 6, 기본 방어가 비용 1에 방어도 5라면 이를 각각 1 비용당 6 피해, 1 비용당 5 방어의 기준점으로 둔다.
단, 피해와 방어를 하나의 숫자로 무리하게 합치지는 않는 편이 좋다. 공격력, 생존력, 덱 순환, 자원 생성은 서로 대체되지 않는 경우가 많기 때문이다. 처음에는 아래처럼 역할별 열을 분리한다.
| 열 | 의미 | 예시 |
|---|---|---|
| 비용 | 사용에 필요한 에너지 | 1 |
| 즉시 피해 | 사용 턴에 주는 피해 | 8 |
| 즉시 방어 | 사용 턴에 얻는 방어도 | 0 |
| 다음 턴 가치 | 지속 효과, 자원, 예약 피해 | 드로우 1 |
| 조건 | 발동 조건과 실패 비용 | 출혈 대상에게만 추가 피해 |
| 덱 영향 | 드로우, 소멸, 생성, 패 제거 | 카드 1장 뽑기 |
| 역할 | 공격, 방어, 엔진, 마무리 등 | 단일 공격 |
이 표의 목표는 “가장 높은 점수의 카드”를 고르는 것이 아니라 카드가 어떤 축에서 기준을 넘는지 찾는 것이다.
2. 카드 표에는 원시 값과 파생 값을 함께 둔다
원시 값은 디자이너가 직접 입력하는 비용, 피해, 방어도다. 파생 값은 원시 값으로 계산되는 효율 지표다. 둘을 분리하면 수치를 바꾸었을 때 어떤 비교 결과가 달라졌는지 빠르게 확인할 수 있다.
다음은 스프레드시트의 간단한 카드 시트 예시다.
| 카드 | 비용 | 피해 | 방어 | 드로우 | 조건부 추가 피해 | 피해/비용 | 방어/비용 | 메모 |
|---|---|---|---|---|---|---|---|---|
| 기본 타격 | 1 | 6 | 0 | 0 | 0 | 6.0 | 0.0 | 기준 공격 |
| 강타 | 1 | 9 | 0 | 0 | 0 | 9.0 | 0.0 | 희귀도와 단점 확인 필요 |
| 수비 | 1 | 0 | 5 | 0 | 0 | 0.0 | 5.0 | 기준 방어 |
| 전술 후퇴 | 1 | 0 | 7 | 1 | 0 | 0.0 | 7.0 | 드로우의 가치는 별도 판단 |
| 처형 | 1 | 5 | 0 | 0 | 12 | 5.0 | 0.0 | 체력 조건을 충족할 때만 강함 |
피해/비용 열은 다음처럼 계산할 수 있다. 비용이 0인 카드에서는 0으로 나누는 오류가 생기므로 별도 표기가 필요하다.
=IF(C2=0, "별도평가", D2/C2)여기서 C2는 비용, D2는 피해라고 가정했다. 하지만 드로우 1장을 단순히 피해 몇 점으로 환산하는 것은 위험하다. 드로우의 가치는 손패, 남은 에너지, 덱 크기, 찾으려는 카드의 유무에 따라 크게 달라진다. 따라서 초반 표에서는 드로우를 독립 열로 관리하고 실제 전투 로그나 시뮬레이션에서 효과를 검증한다.
3. 조건부 효과는 평균값보다 발동률을 기록한다
출혈 상태의 적에게 피해 +12 같은 카드의 기대 피해는 다음과 같이 계산할 수 있다.
예를 들어 기본 피해가 5, 추가 피해가 12, 실제 전투에서 조건 발동률이 40%라면 기대 피해는 9.8이다. 이 값은 비교에는 유용하지만 카드의 체감 성능을 완전히 설명하지는 못한다. 조건을 이미 갖춘 덱에서는 거의 항상 발동하고 그렇지 않은 덱에서는 보상 화면에서 선택되지 않을 수 있기 때문이다.
그래서 카드 표에는 전역 평균 발동률 하나만 두기보다 최소한 다음 두 열을 추가하는 것이 좋다.
| 지표 | 설명 |
|---|---|
| 독립 성능 | 조건을 전혀 충족하지 못했을 때의 성능 |
| 시너지 성능 | 조건을 안정적으로 충족할 때의 성능 |
이렇게 하면 특정 카드가 “약한 카드”인지 “구축 보상(build-around payoff)”인지 구분하기 쉬워진다. 구축 보상이라면 독립 성능이 기준보다 낮아도 괜찮지만 조건을 달성했을 때의 성능과 조건을 만드는 카드의 비용을 함께 확인해야 한다.
4. 적 데이터는 플레이어의 요구량으로 환산한다
적 밸런싱 표에서 중요한 것은 적의 체력 자체가 아니라 플레이어에게 요구하는 피해량, 방어량, 준비 시간이다. 다음 열부터 시작하면 충분하다.
| 적 | 층 | 체력 | 턴당 피해 | 행동 주기 | 방어/약화 | 예상 전투 턴 | 요구 방어도 |
|---|---|---|---|---|---|---|---|
| 훈련 봇 | 1 | 28 | 6 | 매 턴 공격 | 없음 | 3~4 | 6 |
| 방패 드론 | 1 | 36 | 8 | 공격-방어 반복 | 방어 8 | 4~5 | 8 |
| 독성 야수 | 2 | 52 | 10 | 공격-약화 반복 | 중독 부여 | 5~6 | 10+ |
예상 전투 턴은 덱의 기준 피해량을 이용한 거친 추정치다. 예를 들어 기준 덱이 턴당 평균 9 피해를 낸다면 체력 36의 적은 약 4턴을 요구한다. 실제 게임에서는 방어, 드로우, 무작위성 때문에 달라지지만 적 체력 증가가 전투 시간을 얼마나 늘리는지 빠르게 비교할 수 있다.
적의 공격 패턴도 반드시 표에 기록한다. 동일한 평균 피해라도 6, 6, 6, 6과 0, 0, 0, 24는 필요한 덱 구성이 다르다. 전자는 꾸준한 방어를 후자는 폭발 턴을 막을 방어 카드나 약화 수단을 요구한다.
5. 보상 표로 카드 풀의 인플레이션을 감시한다
강한 카드가 존재하는 것보다 위험한 문제는 강한 카드가 너무 자주 나와 기본 카드를 빠르게 무의미하게 만드는 상황이다. 카드 자체의 수치 표와 별도로 보상 빈도 표를 둔다.
| 보상 등급 | 등장 확률 | 목표 역할 | 허용 성능 범위 | 예시 |
|---|---|---|---|---|
| 일반 | 높음 | 기본 전략 보강 | 기준 대비 소폭 우위 | 피해 7~8 또는 방어 6 |
| 고급 | 중간 | 전략 전환 또는 명확한 시너지 | 조건부로 높은 성능 | 출혈 연계, 에너지 생성 |
| 희귀 | 낮음 | 덱의 승리 방식 강화 | 높은 성능 또는 규칙 변경 | 다단 공격 강화, 핵심 유물 |
여기서 확률만 보지 말고 한 런에서 몇 번 해당 등급을 볼 수 있는지도 계산한다. 보상 화면이 12번 등장하고 고급 카드가 화면마다 평균 0.8장 보인다면 플레이어는 고급 카드를 대략 9~10장 보게 된다. 실제 획득 수는 선택률까지 반영해야 한다.
선택률이 지나치게 낮은 카드는 약할 수도 있지만 이미 덱에 넣기 어려운 역할일 수도 있다. 선택률만으로 즉시 상향하지 말고 카드가 등장하는 층, 필요 조건 같은 보상 화면의 경쟁 카드도 함께 확인한다.
6. 시트 구조는 데이터와 판단을 분리한다
유지하기 쉬운 워크북은 보통 다음 시트로 나뉜다.
Cards: 카드 원시 데이터와 파생 지표Enemies: 적 체력, 패턴, 상태이상, 보상Rewards: 등급별 등장률과 보상 규칙Runs: 실제 플레이 또는 자동 전투 결과Dashboard: 핵심 지표와 경고값
Runs 시트에는 한 전투 또는 한 런을 한 행으로 기록한다. 최소 열은 시드, 층, 적, 시작 체력, 승패, 전투 턴, 받은 피해, 사용한 핵심 카드, 사망 원인 정도면 된다. 자동화가 없더라도 내부 테스트 몇십 판의 기록은 “느낌상 너무 세다”를 검증 가능한 가설로 바꾸는 데 도움이 된다.
7. 코드에서는 밸런싱 값을 한곳에 모은다
Unity 프로젝트라면 카드 수치를 여러 스크립트에 흩어 두기보다 데이터 에셋이나 테이블로 관리하는 편이 좋다. 아래는 ScriptableObject 기반의 최소 예시다.
using UnityEngine;
[CreateAssetMenu(menuName = "Deckbuilding/Card Definition")]
public class CardDefinition : ScriptableObject
{
public string cardId;
public int energyCost;
public int damage;
public int block;
public int drawCount;
public int conditionalBonusDamage;
}밸런싱 표의 cardId와 게임 데이터의 cardId를 같게 유지하면 시트에서 조정한 값을 에셋이나 JSON으로 옮길 때 대조가 쉬워진다. 다만 스프레드시트를 게임의 유일한 실행 데이터로 곧바로 연결하기보다 검증된 값을 내보내는 원본으로 사용하는 편이 디버깅에 유리하다.
8. 한 번에 하나의 가설만 검증한다
밸런싱에서 가장 흔한 실수는 전투가 어렵다는 이유로 적 체력, 카드 피해, 보상 확률을 동시에 바꾸는 것이다. 결과가 좋아져도 어느 변경이 원인인지 알 수 없다.
예를 들어 “1층 엘리트 전투가 지나치게 오래 걸린다”는 문제는 다음처럼 쪼갠다.
- 기준 덱으로 엘리트 전투의 평균 턴 수와 받은 피해를 기록한다.
- 목표 전투 턴 수를 정한다.
- 적 체력만 낮춘 결과를 측정한다.
- 목표를 충족하지 못할 때에만 공격 카드 등장률 또는 기본 덱 성능을 별도 가설로 검증한다.
목표값도 명시한다. 예를 들어 “1층 일반 전투는 평균 3~5턴, 엘리트는 5~8턴”처럼 범위를 정하면 단순히 이기고 지는 것보다 전투 리듬을 기준으로 조정할 수 있다.
마무리
좋은 밸런싱 표는 복잡한 공식보다 비교 가능한 기준, 분리된 지표, 실제 플레이 기록에서 나온다. 카드 효율·조건 발동률·적의 요구량·보상 빈도를 별도 축으로 관리하면 특정 숫자를 바꾸었을 때 어떤 전략과 난이도 구간이 영향을 받는지 훨씬 명확하게 판단할 수 있다.
