AI 생성 로그라이크 이벤트 스크립트 난이도 피로도 제어 원칙

AI 생성 로그라이크 이벤트의 핵심 위험은 이벤트 하나의 문장 품질이 아니라 연속 이벤트가 누적시키는 위협·판단·손실 압력이다. 해결책은 생성 모델에 자유로운 서사를 맡기되 게임은 위협 예산(Threat Budget), 회복 창(Recovery Window), 선택 밀도(Choice Density)를 수치 규칙으로 검증해 채택 여부와 강도를 결정하는 것이다.

AI 생성 로그라이크 이벤트에서 난이도 피로도는 왜 발생하는가?

로그라이크의 이벤트는 전투만큼이나 플레이어의 자원을 소모한다. 체력, 골드, 소모품처럼 눈에 보이는 자원뿐 아니라 다음 세 가지도 함께 줄어든다.

피로도 원인	플레이어가 느끼는 현상	생성 스크립트에서 흔한 원인	제어 지표
위협 누적	계속 손해를 보는 느낌	피해, 저주, 적대 전투가 연속 등장	최근 위협 점수
판단 누적	읽기와 비교가 귀찮아짐	선택지마다 조건과 예외가 과도함	선택 수, 텍스트 길이
보상 불신	무엇을 골라도 억울함	위험 대비 보상이 불명확하거나 변동 폭이 큼	기대 보상 대비 위험
리듬 붕괴	한 판이 지나치게 길고 무거움	휴식·상점·무위험 이벤트가 부족함	회복 창 간격

특히 LLM이 만든 이벤트는 개별적으로는 흥미로워도 “대가를 치르는 선택”을 과도하게 선호할 수 있다. 이는 드라마를 만들기에는 유리하지만 런 전체의 리듬을 보장하지는 않는다.

난이도 피로도를 어떻게 수치화할까?

먼저 이벤트의 감정적 인상을 직접 점수화하지 말고 플레이 결과에 영향을 주는 항목을 간단한 공통 단위로 환산한다. 아래는 구현하기 쉬운 예시다.

$$T_e = D + C + R + I - H$$

• $T_e$: 이벤트의 위협 점수
• $D$: 예상 체력 손실 비율 × 100
• $C$: 영구적 비용 점수. 카드 제거, 저주 획득, 핵심 자원 소모 등을 포함한다.
• $R$: 실패 또는 최악 결과의 위험 점수
• $I$: 정보·판단 부담 점수
• $H$: 회복 점수. 치유, 확정 보상, 위험 제거가 있으면 차감한다.

정밀한 경제 모델이 없더라도 초기에 0~100 범위를 정해 두면 충분하다. 중요한 점은 절대값보다 이벤트를 같은 기준으로 비교하는 것이다.

권장 초기 등급표

위협 점수 $T_e$	이벤트 등급	사용 원칙
0~15	휴식·정보·소보상	고위협 이벤트 뒤에 우선 배치
16~35	일반 선택	런의 기본 구성
36~55	긴장 이벤트	최근 위협이 낮을 때만 허용
56 이상	위기 이벤트	보스 전, 핵심 보상, 명확한 회피 선택이 있을 때만 사용

여기서 $I$는 종종 빠진다. 선택지가 4개이고 각 선택에 조건문과 수치 예측이 길게 붙는다면 체력 손실이 없어도 플레이어는 피로를 느낀다. 일반 이벤트는 선택지를 2~3개로 제한하고 결과 예측 문장을 짧고 명확하게 제공하는 편이 안전하다.

AI 이벤트 스크립트의 위협 예산은 어떻게 구현할까?

생성 모델이 이벤트 후보를 만들고 게임 규칙이 후보를 필터링하는 구조가 가장 단순하다. 모델에게 난이도 균형을 완전히 맡기지 않는다.

1. 최근 이벤트의 누적 압력을 계산한다

최근 3~5개 이벤트의 위협 점수를 합산한다. 최근 결과에 가중치를 주면 방금 겪은 손실을 더 민감하게 반영할 수 있다.

$$F_t = \sum_{k=0}^{n-1} w_k T_{t-k}$$

예를 들어 최근 이벤트부터 $w = [1.0, 0.7, 0.4]$를 사용한다. $F_t$가 임계값을 넘으면 다음 이벤트는 휴식·정보·확정 보상군에서만 고른다.

2. 생성 프롬프트에 허용 범위를 넣는다

프롬프트에는 분위기만 전달하지 말고 수치 제약도 넣는다. 예를 들어 threatScore 15~35, choiceCount 최대 3, 명시적 회피 선택 1개 이상을 요구한다. 다만 프롬프트 결과는 신뢰 경계가 아니므로 반드시 후처리 검증이 필요하다.

const canUseEvent = (event, fatigue) =>
  event.threatScore <= (fatigue > 90 ? 15 : fatigue > 55 ? 35 : 55) &&
  event.choices.length <= 3 &&
  event.choices.some((choice) => choice.isSafeExit);

3. 탈락 후보는 재생성보다 기존 풀로 대체한다

검증에서 탈락한 이벤트를 즉시 재생성하면 지연 시간과 비용이 늘어난다. 먼저 검증된 정적 이벤트 풀 또는 이전에 캐시한 저위협 이벤트로 대체하고 다음 생성 요청에서만 부족한 유형을 보충한다.

이 방식은 AI를 콘텐츠 생산 도구로 쓰면서도 런타임 밸런싱을 결정론적으로 유지한다.

회복 창은 얼마나 자주 제공해야 할까?

회복은 체력 회복만 뜻하지 않는다. 쉬운 선택, 손실 없는 퇴장, 규칙을 학습시키는 정보, 확정적인 작은 보상도 회복 창이 될 수 있다. 플레이어는 위험을 피할 수 있다는 감각을 통해 다음 긴장 구간을 받아들인다.

flowchart LR
  A[이벤트 후보 생성] --> B{최근 피로도 F_t}
  B -->|낮음| C[일반·긴장 이벤트 허용]
  B -->|중간| D[일반 이벤트와 회복 이벤트 혼합]
  B -->|높음| E[회복·안전 퇴장 이벤트 우선]
  C --> F[규칙 검증 후 노출]
  D --> F
  E --> F

권장 시작점은 다음과 같다.

• 위협 등급 3 이상 이벤트 뒤에는 1개 이상의 저위협 이벤트를 배치한다.
• 연속 3개 이벤트가 모두 자원 손실을 요구하면 다음 노드는 회복 창으로 강제한다.
• 보스 직전에는 무작위 위기 이벤트보다 덱·장비·소모품을 정리할 기회를 제공한다.

선택지 수와 결과 공개는 어느 정도가 적절한가?

선택지는 많을수록 전략적이지 않다. 서로 다른 계산을 요구하는 선택지가 늘면 게임의 핵심 판단보다 이벤트 해석이 앞선다.

상황	권장 선택지	결과 공개 방식
일반 이벤트	2~3개	비용과 즉시 결과를 명시
고위험 이벤트	2개 + 안전 퇴장	실패 조건과 최대 손실을 명시
발견·서사 이벤트	2개	수치보다 장기 효과를 간결히 설명
희귀 보상 이벤트	2~3개	보상 후보와 대가를 모두 공개

확률형 결과를 쓰더라도 “성공 70%“만 보여 주지 말고 실패했을 때 무엇을 잃는지 함께 보여 준다. 정보 비대칭은 긴장을 만들 수 있지만 AI 생성 문구의 해석 오차까지 겹치면 불공정으로 읽히기 쉽다.

자주 묻는 질문 (FAQ)

AI가 만든 이벤트를 모두 실시간으로 사용해도 될까?

권장하지 않는다. 생성 결과는 스키마 검증, 금지 효과 검사, 위협 점수 계산을 통과한 뒤 사용해야 한다. 검증 실패 시에는 준비된 이벤트 풀로 대체한다.

피로도 점수는 플레이어마다 다르게 계산해야 할까?

처음에는 최근 이벤트의 위협과 현재 체력 비율만으로 시작해도 된다. 이후 데이터가 쌓이면 실패율, 이벤트 이탈률, 선택 시간으로 보정한다.

쉬운 이벤트를 넣으면 로그라이크의 긴장감이 약해지지 않을까?

회복 창은 긴장감의 반대가 아니다. 다음 위험을 감당할 여지를 만들기 때문에 고위협 이벤트의 의미와 보상 만족도를 오히려 높인다.

정리

AI 생성 로그라이크 이벤트는 창의성보다 제어 규칙이 먼저다. 이벤트마다 위협 점수를 계산하고 최근 누적 피로도가 높으면 회복 창을 강제하며 선택지 수와 정보량을 제한하자. 이 세 가지 규칙만 있어도 생성 콘텐츠가 런의 리듬을 무너뜨리는 문제를 크게 줄일 수 있다.