✍️Today I Learned

📅 2025-11-21

• 인터페이스 기반 상호작용 위젯 표시 시스템 추가
• 픽업 아이템 액터 구현 및 AddItem 테스트
• 컨테이너 액터 구현
• 서버/클라이언트 실행 분기 처리 (RunOnServer 패턴)

---

인터페이스 기반 상호작용 위젯 표시 시스템

기존 코드 (팀원 작업)

• 캐릭터에서 라인트레이스로 CurrentHitActor, LastHitActor 저장
• 액터 전환 감지 기능

추가 구현 내용

1. IInteractableInterface 확인 후 위젯 표시

// 이전 액터 처리
	if (IsValid(LastHitActor.Get()))
	{
		if (LastHitActor->Implements<UIInteraction>())
		{
			IIInteraction* InteractionInterface = Cast<IIInteraction>(LastHitActor);
			if (InteractionInterface)
			{
				InteractionInterface->HideInteractionWidget();
			}
		}
	}

	// 현재 액터 처리
	if (IsValid(CurrentHitActor.Get()))
	{
		if (CurrentHitActor->Implements<UIInteraction>())
		{
			IIInteraction* InteractionInterface = Cast<IIInteraction>(CurrentHitActor);
			if (InteractionInterface && InteractionInterface->CanInteract(this))
			{
				InteractionInterface->ShowInteractionWidget(this);
			}
		}
	}

2. 픽업 아이템 액터 구현

• FItemInstance 데이터 보유 (StaticDataID, CreationServerTime)
• Widget Component로 "줍기 [E]" 프롬프트 표시
• Interact() 호출 시 UTSInventoryMasterComponent::AddItem() 연동
• AddItem 성공 시 액터 Destroy <- 추후 풀로 반환하도록 수정 예정
• 멀티플레이어 테스트 완료

3. 컨테이너 액터 구현

• UTSInventoryMasterComponent 보유
• "열기 [E]" 프롬프트 표시
• Interact() 호출 시 PlayerController의 HUD에서 ToggleContainer() 실행

---

RunOnServer 패턴으로 서버/클라이언트 실행 분기 처리

문제 상황

E키 상호작용 시 실행 위치가 액터마다 달라야 하는 문제:

• 픽업 아이템: AddItem()은 인벤토리 데이터 수정이므로 서버에서 실행 필요
• 컨테이너: HUD의 ToggleContainer()는 UI 조작이므로 클라이언트에서 실행 필요

기존 방식으로는 모든 상호작용을 ServerInteract RPC로 보내면 컨테이너에서 HUD를 찾을 수 없는 문제 발생

해결 방법: RunOnServer() 인터페이스 함수 추가

1. 인터페이스에 실행 위치 판별 함수 추가

// IInteractableInterface
UFUNCTION(BlueprintNativeEvent, BlueprintCallable)
bool RunOnServer();

2. 각 액터에서 실행 위치 반환

// ATSPickupItem - 서버에서 실행해야 함
bool ATSPickupItem::RunOnServer_Implementation()
{
    return true;  // AddItem()은 서버에서 실행
}

// ATSContainerActor - 클라이언트에서 실행해야 함
bool ATSContainerActor::RunOnServer_Implementation()
{
    return false;  // ToggleContainer()는 클라이언트에서 실행
}

3. 캐릭터에서 실행 위치 분기

void ATSCharacter::OnInteract(const struct FInputActionValue& Value)
{
	UE_LOG(LogTemp, Log, TEXT("e pressed"));

	if (!IsValid(CurrentHitActor.Get()))
	{
		return;
	}
	if (CurrentHitActor->Implements<UIInteraction>())
	{
		IIInteraction* InteractionInterface = Cast<IIInteraction>(CurrentHitActor);
		if (InteractionInterface && InteractionInterface->CanInteract(this))
		{
			if (InteractionInterface->RunOnServer())
			{
				ServerInteract(CurrentHitActor.Get());
			}
			else
			{
				InteractionInterface->Interact(this);
			}
		}
	}
}

패턴의 장점

• ✅ 확장성: 새로운 액터 추가 시 RunOnServer()만 구현하면 자동으로 올바른 위치에서 실행
• ✅ 명확성: 각 액터가 자신의 실행 위치를 명시적으로 선언
• ✅ 유지보수성: 캐릭터 코드 수정 없이 액터별 동작 변경 가능

---

💡 느낀 점 (What I Felt)

1. 인터페이스 설계의 유연성

• RunOnServer() 함수 하나 추가로 서버/클라이언트 실행 분기를 깔끔하게 처리할 수 있었다.
• 각 액터가 자신의 실행 위치를 결정하는 방식이 객체지향 설계 원칙에 부합하고 확장성도 좋은 것 같다.

2. 멀티플레이어 아키텍처의 복잡성

• 같은 E키 입력이라도 액터 종류에 따라 서버/클라이언트 중 어디서 실행해야 하는지가 다르다는 점이 흥미로웠다.
• 데이터 수정은 서버, UI 조작은 클라이언트라는 기본 원칙을 명확히 이해하게 되었다.

3. 팀 작업의 효율성

• 팀원이 구현한 라인트레이스 시스템 위에 인터페이스 기반 기능을 추가하는 방식으로 협업이 잘 이루어졌다.
• 기존 코드를 최대한 수정하지 않고 기능을 확장할 수 있어서 협업 시 충돌을 최소화할 수 있었다.

---