[📜일지] Deviants 개발일지 #7 - UI 구현 및 리팩토링

[오더리움(othereum)]

2주만의 개발일지네

그동안 바쁘기도 했고 리팩토링만 존나 하느라 못올렸음

이번에는 캐릭터 머리 위에 뜨는 정보 UI를 구현함

개발일지 쓸 정도로 대단한 기능은 아니지만 안쓴지 너무 오래돼서 걍 올림

리팩토링에 오랜 시간이 걸렸다고 했는데

작업이 많아서 오래걸린건 아니고 어떤 구조가 최선일까 고민하느라 시간 많이 썼음

전에 올렸던 [미친 언리얼...] 글에서 언급했던

블루프린트에서 런타임에 추가한 컴포넌트가 에디터에서 편집하면 삭제되는 문제가 생각보다 너무 불편해서

결국 리플렉션을 이용한 의존성 주입은 포기하고 평범하게 CreateDefaultSubobject 썼음

이번 프로젝트의 설계원칙 두가지

• 독립적으로 분리될 수 있는 기능/데이터는 Autorun 시스템을 이용해 별개의 액터로 만들어 사용한다
• PlayerController/Character 등 특정 액터에 반드시 종속되어야 하는 코드/데이터는 컴포넌트로 만들어서 붙인다

예를 들면, 채팅 시스템은 이 원칙에 따라 세 가지 객체로 나뉨

• AChatSystem - Autorun 시스템에 의해 자동 생성되어 채팅과 명령어 처리 및 관련 전역 데이터 저장 담당
• UChatControllerComponent - PlayerController에 붙어서 채팅 송수신 등의 RPC 담당
• UChatStateComponent - PlayerState에 붙어서 해당 플레이어가 채팅을 치고있는지 등의 상태정보 리플리케이션 담당

이번에 만든 이 UI도

• UPlayerInfoWidgetComponent - Character에 붙어서 위젯의 표시여부 결정과 렌더링을 담당
• ULookingAtComponent - PlayerController에 붙어서 LineTrace를 수행하여 어떤 캐릭터를 바라보는지 판단

이런식임

기능간의 커플링을 극단적으로 줄여보려는 노력의 결과라고 볼수이따

참고로 ULookingAtComponent는 이 UI 전용이 아니고 범용임

하지만 사소한 데이터 저장을 위해 일일히 컴포넌트를 만드는건 귀찮기 때문에

Lua의 table 개념에서 영감을 얻어서 VariantTable이라는걸 만들었음

문자열 Key로 다양한 타입의 값을 읽고 쓸 수 있는 자료구조임

막 대단하거나 새로운 개념은 아니지만 있으면 편함

블루프린에서도 쓸수있게 API 만듦

이 기능을 ULookingAtComponent 구현에 응용했음

원래라면 Character에 새 변수를 만들어야 하지만 이 기능 덕분에 그럴 필요가 없다

실수 방지를 위해 템플릿 인자는 명시적으로 넘겨야만 컴파일 되도록 만들었음

이상이다

이런 개발속도라면 내년에나 완성할 수 있을듯 하다 시발

다들 힘내자

[oo(182.208)]

느리더라도 꾸준하면 됫다

[오더리움(othereum)]

[익명(14.56)]

설계에 궁금한거 있는데, 혹시 특정 컴포넌트에 종속되는 기능이 있으면 그 기능을 따로 컴포넌트로 떼서 만듬?

[오더리움(othereum)]

너무 추상적인데? 예시 줘봐 - dc App

[익명(14.56)]

예를 들어, 롤에서의 인벤토리와 상점에서의 조합기능이 있다고 하면?

[익명(14.56)]

그 상점에 조합컴포넌트를 가지고 있고, 플레이어에 인벤토리 컴포넌트가 있으면, 구매 버튼을 클릭하는 로직자체는 어디에 있어야하나 싶어서

[익명(14.56)]

(플레이어 컨트롤러에 구매로직을 컴포넌트로 따로 떼서 만드나 싶어서)

[오더리움(othereum)]

ㄴㄴㄴ 너무 객체지향적으로 생각할필요 없음. 내가 '특정 액터에 종속되어야 하는 코드/데이터' 라고 말한건, 말 그대로 반드시 종속되어야만 동작하거나, 종속되는게 명백하게 자연스러운 경우에 한함 - dc App

[오더리움(othereum)]

내가만든 채팅시스템도 대부분의 로직은 AChatSystem에 집중되어있고, UChatControllerComponent랑 UChatStateComponent는 반드시 PC/PS에 있어야하는 코드랑 데이터만 넣은거임 - dc App

[오더리움(othereum)]

내가 질문을 잘 이해하고 대답한건지 모르겠다 - dc App

[오더리움(othereum)]

근데 애초에 그 예시같은 경우에는 컨트롤러에 입력처리 컴포넌트가 있을거고, 버튼 UI는 스스로를 글로벌 이벤트 시스템에 등록해서, 서로를 모르는 상태로 입력컴포넌트가 이벤트를 디스패치하는 식으로 작동하는게 맞겠지 - dc App

[오더리움(othereum)]

본질적인 원칙은 서로다른 기능 사이의 커플링을 최소화 함으로써 애초에 종속관계를 없애는게 중요한것임. 그러니 '상점 UI'와 '클릭 입력 처리'는 애초에 서로 관계가 없어야 함. 컴포넌트화는 이러한 원칙을 지키기 위한 도구의 하나일 뿐임 - dc App

[익명(14.56)]

그 구매 이벤트를 디스패치했을때 받아서 처리하는 코드가 님같은경우엔 UChatControllerComponent에 있다는거?

[오더리움(othereum)]

에... 그건 케바케겠지. 솔직히 질문 자체를 이해못하겠다 미안

[익명(14.56)]

내가 아까 잘못말한게 구매버튼 클릭하는 로직 얘기한게 아니라, 구매버튼을 클릭해서 이벤트 디스패치를 했을때 이 디스패치를 받아서 인벤토리 내용을 가지고 상점에 존재하는 조합 컴포넌트와 통신하는 코드는 어디에 존재하는게 좋을까라는 얘기임

[익명(14.56)]

그 코드를 컴포넌트로 또 따로 빼서 분류하나 싶어서 물어본거였구

[오더리움(othereum)]

그건 짜보기 전까진 모를것같은데.. 너무 케바케 아니냐

[익명(14.56)]

그렇구만.. 답글 고맙다.

[익명(222.112)]

이사람은 전형적인 프로그래머 느낌이나 ㅋㅋ

[오더리움(othereum)]

[익명(114.202)]

형 잘보고 있어!

[오더리움(othereum)]