38강. GAS, RPC, RepNotify, Multicast의 책임 경계

?1. 이번 강의에서 해결할 문제

GAS를 도입했다고 모든 네트워크 코드를 Ability로 바꿀 필요는 없습니다. 반대로 공격마다 사용자 RPC와 Multicast를 추가하면 GAS의 예측·Effect·Tag 수명 관리와 중복됩니다. 먼저 데이터가 명령인지, 지속 상태인지, 일회성 표현인지 분류해야 합니다.

✓2. 학습 목표

✓이 강의를 마치면

• GAS와 RPC·RepNotify·Multicast의 적합한 책임을 구분합니다.
• 지속 상태를 재접속 가능한 형태로 설계합니다.
• GAS 밖 시스템과 연결되는 최소 인터페이스를 만듭니다.

◇3. 핵심 개념

Ability 활성화·Cost·Cooldown·전투 Effect·Tag는 GAS 흐름을 우선합니다. 매치 타이머·팀 점수처럼 GAS 밖의 공유 상태는 GameState의 복제 변수와 RepNotify가 자연스럽습니다. 로비 요청 같은 소유 클라이언트 명령은 검증된 Server RPC가 맞을 수 있습니다. Multicast는 유실되어도 규칙이 깨지지 않는 일회성 표현에 제한하며 상태 동기화로 남용하지 않습니다.

§4. 구현

요구	권장 수단	이유
공격 입력과 Cost·Cooldown	Ability + Effect	예측·검증·수명 통합
체력·버프·스턴	Attribute + Effect + Tag	현재 상태 복원 가능
매치 점수·남은 서버 시간	GameState 복제 변수	모든 관찰자 공유 규칙
로컬 조준 UI	로컬 코드/Ability Task	권한 상태가 아님
비 GAS 로비 참가 요청	소유 객체 Server RPC	명시적 서버 명령

GAS 밖 매치 상태 예시

UPROPERTY(ReplicatedUsing=OnRep_RoundState)
ERoundState RoundState;

UFUNCTION()
void OnRep_RoundState();

GAS Ability가 라운드 승리를 직접 복제하기보다 서버 GameMode가 승리 조건을 계산하고 GameState를 갱신하게 합니다. 반대로 PlayerState의 팀 정보가 바뀌면 ASC에 팀 Tag를 적용하는 작은 어댑터를 둡니다.

→5. 코드가 동작하는 이유

각 시스템이 잘하는 수명과 관찰 범위를 유지합니다. GAS는 능력 실행과 전투 상태, GameState는 매치 공유 상태, PlayerController는 소유 입력·UI 경계를 담당하므로 복제 경로가 중복되지 않습니다.

§6. 실패 사례와 해결

!자주 하는 실수

• Effect 적용 뒤 Multicast로 체력도 갱신: Attribute 복제와 충돌하므로 UI는 Attribute Delegate를 봅니다.
• 라운드 규칙을 Character Ability에 저장: 서버 GameMode와 GameState로 분리합니다.
• 모든 입력에 직접 Server RPC 추가: Ability 활성화 경로가 이미 처리하는 요청을 중복하지 않습니다.
• Multicast를 지속 상태로 사용: RepNotify, Attribute, Effect, Tag 중 복원 가능한 원본을 고릅니다.

✎7. 직접 실습

✎직접 실습

현재 프로젝트의 공격, 팀 점수, 라운드 시간, 스턴 VFX, 로비 준비 요청을 표에 분류하세요. 중복 RPC 하나를 제거하고 원본 상태가 늦게 접속한 클라이언트에서도 복원되는지 테스트합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 체력을 Multicast로 맞추면 안 되는 이유는 무엇인가요?
2. 매치 전체 점수를 GameState에 두는 이유는 무엇인가요?
3. GAS 밖 Server RPC가 여전히 적합한 사례는 무엇인가요?

■9. 핵심 요약

■핵심 요약

명령, 지속 상태, 표현을 먼저 분류한 뒤 GAS와 기본 네트워크 수단을 선택합니다. 다음 강의에서는 스턴·침묵·무적을 Tag 중심 제어 상태로 설계합니다.