GameFeatureAction_AddInput #1 강의를 수강... - 인프런

[Rookiss University] UE5 Lyra 클론 코딩 (Haker)

GameFeatureAction_AddInput #1 강의를 수강한 후 궁금한 점이 생겼습니다.

해결된 질문

작성

수정됨

안녕하세요 언제나 좋은 배움의 기회를 제공해주셔서 감사드립니다.

특히 지금 수강하고 있는 Lyra 클론 코딩을 통해 모범적이고 체계적인 언리얼 엔진 코드 구조를 배울 수 있어 너무 기쁩니다.

GameFeatureAction_AddInput #1 를 수강한 후에 제 나름대로 엔진 Subsystem을 사용하는 이유를 아래와 같이 정리하였습니다.

혹시 틀린 부분이 있는지 궁금합니다.

첫번째로, GameFeature 플러그인 별로 생성된 GameFeatureSubsystem이 자신의 플러그인의 Action을 활성화하는데

GameFeature 플러그인끼리의 전환이 빈번한 상황에서 이전에 사용한 플러그인이 비활성화되면

해당 플러그인의 SubSystem도 비활성화되고 Action 역시 비활성화된다.

이런 경우에 FGameFeatureActivatingContext는 비활성화된 Action을 참조하게 되므로 문제가 발생한다.

두번째로, FGameFeatureActivatingContext는 플러그인마다 존재하므로

모든 플러그인에 대해 바인딩을 할 수 없으므로 EngineSubsystem의 Context를 사용하는 것이 합리적이다.

위와 같이 정리하였는데 틀린 부분이 있는지 알고 싶습니다.

다시한번 언제나 좋은 배움의 기회를 제공해주셔서 감사합니다.

답변 1

지식공유자

게임 피처 시스템을 엔진 서브시스템으로 구현했는지는 명확히 알 수 없으나, 엔진 서브시스템으로 관리될 때 발생하는 몇 가지 특수성이 존재합니다.

GameFeature 관리자 구현 및 PIE 환경 특수성
- 실제 라이라에서는 GameFeaturePlugin 관리를 위해 별도의 관리자를 구현했습니다.
- 이는 PIE(Play In Editor) 환경에서 여러 개의 세션 중 하나가 종료되더라도, 나머지 세션에서 플러그인이 유지되도록 하기 위함입니다.
- 단일 PIE 종료 시 플러그인을 비활성화하면 다른 세션에도 영향을 주는 문제를 방지하기 위한 설계입니다.
첫 번째 문제 답변
- 플러그인이 비활성화되더라도 엔진 서브시스템은 비활성화되지 않습니다.
두 번째 문제 답변
- 말씀하신 문제 해결은 엔진 서브시스템 덕분에 가능하지만 1번에서
  말한 새로운 문제가 발생합니다.
그래서 엔진 서브시스템을 사용한 이유는 제 생각에는
GameFeatureSubsystem 내부를 보면 네트워크 관련 실시간 패치나 기타 복잡한 기능을 소유하고 있습니다. 그래서 중요한 시스템이므로 싱글톤 패턴과 유사하게 동작해야 한다는 판단에서 비롯된 것으로 추측됩니다.

질문자

상세한 답변에 감사드립니다.

Lyra의 구조가 익숙하지 않고 기존에 프로젝트를 만드는 방식과 다르게 새로운 부분이 많아

정말 헷갈리네요.

익숙해질 때까지 학습해야 할 것 같습니다.