God of War와 같은 전투 시스템에서 모든 "패링(parry)" 윈도우와 "스태거(stagger)" 상태를 일일이 하드코딩하는 것은 관리하기가 거의 불가능한 상태 전이의 조합 폭발(combinatorial explosion)로 이어집니다. 실제 제작 환경에서 저는 전투 FSM(유한 상태 머신)이 400개 이상의 상태로 늘어나는 것을 본 적이 있는데, 전이 로직의 단 하나의 버그 때문에 플레이어 캐릭터가 강공격의 특정 프레임에서 피격될 때마다 T-포즈(T-pose)를 취하는 문제가 발생하곤 했습니다. 이러한 수동 방식은 현대 AAA 타이틀에서 요구되는 고정밀의 반응형 애니메이션 블렌딩을 구현할 때 확장성이 매우 떨어집니다.
업계는 플레이어들이 기대하는 복잡성을 처리하기 위해 데이터 중심의 애니메이션 합성 및 강화 학습(RL)으로 선회하고 있습니다. 언리얼 엔진 5.4의 모션 매칭(Motion Matching)과 유니티의 센티스(Sentis) 출시로 이러한 시스템을 구현하는 장벽이 크게 낮아졌습니다. 이제 우리는 적의 행동을 위한 "if-then" 로직에서 벗어나, 고차원 특징 벡터(feature vectors)를 기반으로 가장 자연스러운 다음 포즈나 행동을 예측하는 시스템으로 이동하고 있습니다.
모션 매칭: 상태 머신을 특징 검색으로 대체하기
모션 매칭은 크레토스에게 무게감과 유연한 움직임을 부여하는 핵심 기술입니다. "달리기"와 "정지" 사이의 전이를 정의하는 대신, 애니메이션 프레임의 대규모 데이터베이스를 유지하고 캐릭터의 현재 포즈 및 원하는 궤적과 가장 잘 일치하는 프레임을 검색합니다. 이를 통해 수천 개의 수동 블렌드 노드가 필요 없게 됩니다.
선택 프로세스는 현재 상태와 잠재적인 미래 프레임을 비교하는 비용 함수(cost function)에 의존합니다. 각 프레임은 관절 위치, 속도 및 미래 궤적 포인트를 포함하는 특징 벡터로 표현됩니다. 시스템은 플레이어의 입력에 대해 가장 낮은 "비용"을 가진 프레임을 선택합니다.
import numpy as np
from dataclasses import dataclass
@dataclass
class FeatureVector:
pose_data: np.ndarray # 관절 위치/속도
trajectory: np.ndarray # 미래 위치 (0.5초, 1.0초, 1.5초)
class MotionMatcher:
def __init__(self, database: list[FeatureVector]):
self.database = database
# 각 특징에 대한 가중치 (이 수치를 튜닝하는 것이 핵심입니다)
self.weights = np.array([0.5, 0.5, 1.0, 1.0, 1.0])
def find_next_frame(self, current_query: FeatureVector) -> int:
"""가중치 L2 노름을 사용하여 가장 잘 맞는 프레임의 인덱스를 찾습니다."""
best_cost = float('inf')
best_idx = 0
for i, entry in enumerate(self.database):
# 가중 유클리드 거리 계산
pose_diff = np.sum((entry.pose_data - current_query.pose_data) ** 2)
traj_diff = np.sum((entry.trajectory - current_query.trajectory) ** 2)
total_cost = (pose_diff * self.weights[0]) + (traj_diff * self.weights[1])
if total_cost < best_cost:
best_cost = total_cost
best_idx = i
return best_idx
# 사용 예시: 틱당 100,000개의 프레임 검색
# 실제 서비스 시에는 O(N) 검색을 피하기 위해 KD-Trees나 Product Quantization을 사용하세요.
저는 실제 프로젝트에서 "궤적(trajectory)" 가중치가 너무 낮아 애니메이션이 실제 이동 속도와 일치하지 않아 캐릭터가 "미끄러지는(skating)" 현상이 발생하는 것을 본 적이 있습니다. 또한 검색을 위한 "데드존(dead zone)"을 구현해야 합니다. 매 프레임(60Hz)마다 프레임을 교체하면 애니메이션이 떨려 보일 수 있기 때문입니다. 보통 3~5프레임마다 또는 입력 벡터가 15% 임계값 이상 변할 때만 최적의 매칭을 다시 평가합니다.
검색 최적화
매 프레임마다 500MB의 애니메이션 데이터를 검색하는 것은 계산 비용이 많이 듭니다. 이를 60 FPS에서 가능하게 하려면 K-차원(KD) 트리나 HNSW(Hierarchical Navigable Small World) 그래프를 사용해야 합니다. 이러한 구조를 사용하면 선형 시간 대신 로그 시간으로 최근접 이웃 검색을 수행할 수 있어, 대규모 데이터셋에서 CPU 오버헤드를 거의 90%까지 줄일 수 있습니다.
반응형 적 AI를 위한 강화 학습
전통적인 행동 트리(BT)는 예측 가능합니다. God of War에서 발키리와 같은 적들이 "지능적"이라고 느껴지는 이유는 플레이어의 패턴에 반응하기 때문입니다. 산타 모니카 스튜디오는 매우 정교한 BT를 사용하지만, 많은 스튜디오에서는 디자이너가 스크립트로 작성하지 않은 방식으로 플레이어의 공격에 대응할 수 있는 에이전트를 훈련하기 위해 PPO(Proximal Policy Optimization)를 실험하고 있습니다.
액터-크리틱(Actor-Critic) 모델을 사용하여 "생존" 또는 "가한 데미지" 보상을 최대화하도록 AI를 훈련할 수 있습니다. "액터"는 다음 행동(예: 회피, 방어, 약공격)을 결정하고, "크리틱"은 그 행동이 유익했는지 평가합니다. 이를 통해 플레이어의 공격이 특정 프레임 윈도우 내에 있을 때만 패링하는 법을 배우는 에이전트가 만들어집니다.
import torch
import torch.nn as nn
import torch.optim as optim
class CombatPolicy(nn.Module):
def __init__(self, state_dim: int, action_dim: int):
super().__init__()
# 공유 특징 추출기
self.backbone = nn.Sequential(
nn.Linear(state_dim, 256),
nn.ReLU(),
nn.Linear(256, 128),
nn.ReLU()
)
# 액터: 행동에 대한 확률 분포 출력
self.actor = nn.Sequential(
nn.Linear(128, action_dim),
nn.Softmax(dim=-1)
)
# 크리틱: 현재 상태의 가치 추정
self.critic = nn.Linear(128, 1)
def forward(self, state: torch.Tensor):
features = self.backbone(state)
action_probs = self.actor(features)
state_value = self.critic(features)
return action_probs, state_value
# 훈련 루프 로직:
# reward = (플레이어가 받은 데미지 * 2.0) - (적이 잃은 체력 * 1.5)
# 이는 AI가 공격적이면서도 신중하게 행동하도록 유도합니다.
게임 개발에서 RL의 주요 함정은 "보상 설계(reward shaping)"입니다. AI가 죽는 것에 대해 너무 큰 패널티를 주면, AI는 단순히 도망치거나 아레나 가장자리에 머무르는 법을 배워 플레이어 경험을 지루하게 만듭니다. 플레이어와 AI 사이의 의미 있는 상호작용 빈도인 "교전 밀도(engagement density)"를 우선시하도록 보상의 균형을 맞춰야 합니다.
하이브리드 시스템
신경망이 NPC의 움직임을 완전히 제어하게 하는 경우는 드뭅니다. 대신 ML 모델은 "거리 좁히기(CloseDistance)", "방어 태세(DefensiveStance)"와 같은 "상위 수준의 의도"를 출력하고, 이를 전통적인 행동 트리에 전달합니다. 이렇게 하면 AI를 디자이너의 제약 조건 안에 유지하면서도 전투를 생동감 있게 만드는 미세한 반응성을 제공할 수 있습니다. 이러한 하이브리드 접근 방식은 행동 공간이 크게 줄어들기 때문에 모델 훈련 시간을 몇 주에서 몇 시간으로 단축시킵니다.
정밀한 접촉을 위한 신경 역운동학(Neural IK)
크레토스의 발은 울퉁불퉁한 지형에 완벽하게 정렬되어야 하며, 도끼는 적 방패의 정확한 지점에 맞아야 합니다. FABRIK과 같은 표준 역운동학(IK) 솔버는 빠르지만 관절 제한(joint limits) 처리에 어려움을 겪어 "무릎 꺾임(knee popping)"이나 부자연스러운 끊김 현상이 발생하곤 합니다. 신경 IK(NIK)는 사전 훈련된 소규모 네트워크를 사용하여 원래 애니메이션의 심미적 무결성을 유지하면서 접촉 제약 조건을 충족하는 관절 회전값을 예측합니다.
유효한 인간 포즈 데이터셋으로 훈련함으로써 NIK 솔버는 "자연스러운" 가동 범위를 학습합니다. 발이 현재 애니메이션보다 10cm 높은 지점에 닿아야 할 때, 네트워크는 단순히 수학적으로 가장 짧은 경로가 아니라 힙, 무릎, 발목에 대해 가장 인간다운 회전값을 제공합니다.
class NeuralIKSolver(nn.Module):
def __init__(self):
super().__init__()
# 입력: 목표 위치 (3), 현재 관절 회전 (N)
# 출력: 키네마틱 체인에 대한 델타 회전값
self.net = nn.Sequential(
nn.Linear(3 + 12, 64),
nn.Tanh(), # Tanh는 출력을 예측 가능한 범위 내로 유지합니다
nn.Linear(64, 12)
)
def solve(self, target_pos: torch.Tensor, current_rotations: torch.Tensor):
x = torch.cat([target_pos, current_rotations], dim=-1)
delta_rotations = self.net(x)
# 안전 클램프를 적용하여 현재 포즈에 델타 적용
return torch.clamp(current_rotations + delta_rotations, -3.14, 3.14)
# 추론 시간은 1ms 미만으로, 10개 이상의 캐릭터에 동시 적용이 가능합니다.
성능 측면에서 고려할 점은 CPU와 GPU 사이의 데이터 이동 오버헤드입니다. 유니티나 언리얼 같은 엔진에서 애니메이션 스키닝은 GPU에서 일어나지만, IK 로직은 종종 CPU에서 실행됩니다. DirectML이나 Metal 백엔드와 함께 ONNX Runtime 같은 프레임워크를 사용하면 이러한 소규모 추론 작업을 GPU에서 직접 실행할 수 있어, AI 집약적인 게임에서 프레임 속도를 저하시키는 PCIe 버스 병목 현상을 피할 수 있습니다.
제 경험상, 표준 CCD(Cyclic Coordinate Descent) 솔버를 소규모 MLP(Multi-Layer Perceptron)로 교체했을 때 계단에서의 "지터링(jitter)" 아티팩트가 40% 감소했습니다. 네트워크는 접촉 지점에 도달하기 위해 발목이 90도 회전해서는 안 된다는 사실을 암시적으로 학습하는데, 이는 전통적인 IK 시스템에서 수동으로 코딩하기 매우 까다로운 제약 조건입니다.
핵심 요약
AI 기반 전투 메커니즘으로의 전환은 이제 고정밀 게임에서 선택 사항이 아닌, 현대 애니메이션의 복잡성을 관리하기 위한 기술적 필수 사항입니다. 상태 머신의 비대화를 제거하기 위해 기본 캐릭터 이동에는 모션 매칭을 사용하고, 반응적이고 비패턴적인 행동이 필요한 보스전에는 강화 학습을 적용해 보세요. 즉각적인 효과를 보려면 기존의 IK 솔버를 신경 IK로 교체하여 3인칭 액션 게임의 고질적인 문제인 "발 미끄러짐"과 "관절 꺾임" 문제를 해결하십시오. 비결정적인 ML 출력과 관련된 리스크를 줄이기 위해, 엔진 전체를 다시 작성하기보다는 작고 독립된 모듈부터 구현해 나가는 것이 좋습니다.
