설계 목표

<aside> 💡

• 적/캐릭터 모두 동일한 스킬 시스템 사용
• 시스템 간 직접 의존 최소화
• Skill / Status / UI 책임 분리
• 다중 보스 패턴 및 독립 쿨타임 지원 </aside>

초기 구조

초기에는 FSkillEntry 내부에 ESkillSlot 정보를 포함하여, Skill이 자신의 슬롯 정보를 직접 가지는 구조였습니다.

USTRUCT(BlueprintType)
struct FSkillEntry
{
	GENERATED_BODY()
	
	UPROPERTY(EditAnywhere)
	TSubclassOf<class USkillBase> SkillClass;

	UPROPERTY(EditAnywhere)
	FSkillConfig BaseConfig;

	**UPROPERTY(VisibleAnywhere)
	ESkillSlot SkillSlot;**
};

이를 기반으로 Skill → Status Component → UI 로 슬롯 정보를 전달하여 쿨타임 및 UI를 업데이트했습니다.

문제 상황

Enemy에도 동일한 Skill 시스템을 적용하는 과정에서 문제가 발생했습니다. Player와 Enemy는 스킬을 분류하는 기준 자체가 달랐습니다

최종 구조

Skill 사용자 -> Skill -> Status Component -(BroadCast)-> UI HUD

주요 특징

1. 공통 Skill 시스템

   Player는 ESkillSlot, Enemy는 ESkillRange를 사용하지만, Skill 실행 단계에서는 공통 int32 Key 기반으로 처리하도록 설계했습니다.

   이를 통해 다음과 같은 장점이 발생했습니다.

   • Player / Enemy 공통 로직 재사용
   • Skill 내부 타입 분기 제거
   • 확장성 확보

2. 독립 쿨타임 구조

   보스의 동일 Range 내 다중 Skill을 지원하기 위해, Skill ID기반 독립 쿨타임 구조를 도입했습니다.

   TMap<int32, float> CooldownEndTime;
   

3. 책임 분리

   각 시스템은 서로의 구체 타입을 직접 참조하지 않고, 필요한 데이터만 전달받아 자신의 역할만 수행하도록 설계했습니다.

   시스템	책임
   AI / Weapon	Skill 선택
   Skill	실행
   Status Component	상태 계산
   UI	화면 표시

트레이드 오프

<aside> 💡

장점

• Player / Enemy 공통 Skill 시스템 구축 가능
• 시스템 간 직접 의존 최소화
• Skill / Status / UI 책임 분리
• 다중 보스 패턴 및 독립 쿨타임 대응 가능

단점

• int32 Key 기반 구조로 인해 의미 파악 어려움 </aside>

트러블 슈팅