[Study] Part 3 - 액터의 역할과 커넥션 핸드셰이킹 (4/15)

 

 

• 정리
  • 액터의 역할과 커넥션 핸드셰이킹
    1. 게임 로직을 구현하기 위해 알아야 하는 액터의 역할
    2. 리슨 서버에서 액터 역할을 구분하기 위한 API와 이의 활용 방법
    3. 클라이언트와 서버간의 접속이 맺어지고 게임이 준비되는 과정의 심층적인 이해

 

• 서버와 클라이언트에 위치한 액터의 역할
  • 클라이언트-서버 모델에서는 항상 서버에 있는 액터만이 신뢰됨
  • 이를 Authority를 가진다고 표현
  • 클라이언트의 액터는 대부분 서버 액터를 복제한 허상에 불과
  • 이러한 액터를 Proxy라고 표현

 

서버와 클라이언트에 위치한 액터의 역할

 

 

• 로컬 역할과 리모트 역할
  • 리슨(Listen)서버의 경우 플레이어로서 게임에도 참여하므로, 어플리케이션의 게임 로직을 사용한다.
  • 어플리케이션의 게임 로직은 서버 액터에 대해서만 게임에 관련된 작업을 수행해야 한다.
    • 현재 실행된 어플리케이션이 서버인가 클라이언트인가를 구분할 수 있어야한다.
  • 이를 구분하기 위해 현재 동작하는 어플리케이션에서의 역할을 로컬 역할(Local Role), 커넥션으로 연결된 어플리케이션에서의 역할을 리모트 역할(Remote Role)이라고 한다.

 

로컬 역할과 리모트 역할

 

• 이렇게 액터에 설정된 역할을 사용해서 서버와 클라이언트가 동일하게 사용하는 어플리케이션에서 클라이언트 서버 모드를 구현할 수 있게 된다.
• 액터 역할의 종류
  • None : 액터가 존재하지 않음
  • Authority : 서비스를 대표하는 신뢰할 수 있는 역할. 게임 로직을 수행
  • Autonomous Proxy : Authority를 가진 오브젝트의 복제품. 일부 게임 로직을 수행함
  • Simulated Proxy : Authority를 가진 오브젝트의 복제품. 게임 로직을 전혀 수행하지 않음
    • 서버의 변경된 사항을 그냥 반영만 해주는 허상 액터

 

액터 역할의 종류

 

• Autonomous Proxy와 Simulated Proxy
  • 클라이언트의 Proxy는 크게 Autonomous와 Simulated로 구분
  • Autonomous는 클라이언트의 입력 정보를 서버에 보내는 능동적인 역할을 일부 수행
  • Simulated는 일방적으로 서버로부터 데이터를 수신하고 이를 반영
    • 주로 배경 액터들이 해당
  • Autonomous 역할을 하는 액터로는 플레이어 컨트롤러와 폰이 있다.
• 액터의 역할을 파악하는 API
  • 신뢰할 수 있는 액터, 즉 Authority를 가진 액터만 게임 로직을 수행할 수 있음
    • AActor::HasAuthority
  • Autonomous Proxy는 예외적으로 입력에 관련된 로직을 수행할 수 있음
  • 따라서 입력에 관련된 게임 로직의 실행은 Authority와 Autonomous Proxy에서만 허용됨
    • AController::IsLocalController
    • APawn::IsLocallyControlled

 

 

넷모드에 따라 액터의 역할이 계속해서 바뀌는 모습을 볼 수 있다.

 

• 넷모드에 따른 오브젝트 배치
  • 서버에만 존재하는 액터 : 게임 모드(GameMode)
  • 서버와 모든 클라이언트에 존재하는 액터 : 배경 액터와 폰 / SimulatedProxy
  • 서버와 소유하는 클라이언트에만 존재하는 액터 : 플레이어 컨트롤러 / Autonomous Proxy
  • 클라이언트에만 존재하는 오브젝트 : 애니메이션 블루프린트 및 HUD
• 오브젝트 배치에 따른 API의 사용
  • 게임 모드는 HasAuthority 함수를 호출할 필요가 없음
  • 폰은 Autonomous와 Simulated가 혼재되어 있음. API를 사용해 로직을 구분해야 한다.
  • 애니메이션 재생이나 UI 관련 로직은 클라이언트에만 사용함 (서버는 변경된 속성을 전달하고, 변경된 속성에 따라 애니메이션과 UI를 바꾸도록 설계)

 

넷모드에 따른 오브젝트 배치

 

 

void AABCharacterPlayer::SetCharacterControl(ECharacterControlType NewCharacterControlType)
{
	if (!IsLocallyControlled())
	{
		return;
	}

	UABCharacterControlData* NewCharacterControl = CharacterControlManager[NewCharacterControlType];
	check(NewCharacterControl);

	SetCharacterControlData(NewCharacterControl);

	APlayerController* PlayerController = CastChecked<APlayerController>(GetController());
	if (UEnhancedInputLocalPlayerSubsystem* Subsystem = ULocalPlayer::GetSubsystem<UEnhancedInputLocalPlayerSubsystem>(PlayerController->GetLocalPlayer()))
	{
		Subsystem->ClearAllMappings();
		UInputMappingContext* NewMappingContext = NewCharacterControl->InputMappingContext;
		if (NewMappingContext)
		{
			Subsystem->AddMappingContext(NewMappingContext, 0);
		}
	}

	CurrentCharacterControlType = NewCharacterControlType;
}

• ABCharacterPlayer.cpp

 

• SetCharacterControl 함수에서 IsLocallyControlled 함수를 호출해서 현재 내가 소유한 캐릭터의 로직인지 아닌지를 걸러낼 수 있다.
  • 내부 로직은 GetLocalRole이 AutonomousProxy인지, Authority인지 등등.. 넷모드에 따라 반환값이 달라지게 되어 있다.
• 커넥션 핸드셰이킹(Connection Handshaking)
  • 핸드셰이킹이란? 네트웍으로 접속하는 두 컴퓨터가 잘 연결되었는지 확인하는 과정
  • 언리얼 네트웍 멀티플레이 접속을 위한 핸드셰이킹 과정

 

커넥션 핸드셰이킹(Connection Handshaking)

 

• 게임의 준비
  • 커넥션을 허용하면 게임을 시작할 수 있도록 클라이언트와 서버는 준비 과정을 거침
  • 클라이언트 : 맵의 로딩
  • 서버 : 클라이언트를 대표하는 플레이어 컨트롤러의 생성

 

 

게임의 준비

 

• 알아두면 좋은 언리얼 네트웍 시스템 구성
  • 관련 소스코드 : NetDriver.h
  • 용도에 따라 패킷을 처리하는 다양한 NetDriver 클래스를 제공
    • GameNetDriver : 게임 데이터를 처리하는데 사용하는 네트웍 드라이버
    • DemoNetDriver : 게임 리플레이 데이터를 처리하는데 사용하는 네트웍 드라이버
    • BeaconNetDriver : 게임 외 데이터를 처리하는데 사용하는 네트웍 드라이버
  • 언리얼 엔진은 게임 데이터를 처리하는 게임넷드라이버로 IpNetDriver를 사용함
  • 초기 접속에 관련된 데이터 패킷은 ControlChannel을 통해 분석됨
  • 언리얼 엔진에서 번치(Bunch)를 처리하는데 사용하는 주요 채널
    • ControlChannel : 클라이언트 서버 간의 커넥션을 다룰 때 사용하는 채널
    • ActorChannel : 액터 리플리케이션 작업을 다룰 때 사용하는 채널
    • VoiceChannel : 음성 데이터를 전달할 때 사용

 

 

 

 

 

 

 

해당 포스트는 인프런의 <이득우의 언리얼 프로그래밍 Part3 - 네트웍 멀티플레이어 프레임웍의 이해>
강의를 수강하고 정리한 내용입니다.

이득우의 언리얼 프로그래밍 Part3 - 네트웍 멀티플레이 프레임웍의 이해 강의 | 이득우 - 인프런