[📜일지] 캐릭터 시스템 설계 공유 (피드백환영)

[일본뇌염모기2(mosquitoindie1)]

튜토리얼이나 샘플 코드 같은거 보면 한 기능에 다른 기능이 필요할 경우 직접 그 기능을 GetComponent나 인스펙터에서 할당하는것을 볼 수 있음.

그런데 그렇게 할 경우 의존성이 생겨버려서 기능의 삭제가 매우 어려워지는건 물론이고 추가 변경도 매우 귀찮아 지는것을 경험함.

그것을 해결하기 위해서 여러가지 시도를 해 봤고, 현재 가장 편하게 사용중인 캐릭터 시스템 설계를 공유하기로 한다.

(무슨 디자인 패턴 비슷한게 있던거 같던데 모르겠음. 아는사람 알려줘)

이 설계의 목표는 아래의 두가지임.

1. 각 기능의 추가, 변경, 삭제가 매우 쉬울것.

2. 각 기능의 단위 테스트가 쉽게 가능 할 것.

설계의 컨셉을 한줄 요약하자면,

캐릭터의 모든 데이터와 모든 기능함수를 중앙에서 관리하고, 각 기능은 중앙과의 커뮤니케이션만 가능하도록 해 기능간의 의존성을 완전히 없애는것.

그림으로 나타내면 아래와 같다.

그림의 중앙을 설명하자면,

1. 캐릭터 데이터 -> 캐릭터의 모든 데이터를 관리. 각 기능은 이 데이터를 업데이트 하거나 참조함.

2. 기능 직접 호출 -> 각 가능에게 직접 명령을 내리는 함수를 모아둔 클래스. 각 기능의 공개함수를 모아둔것 뿐.

3. 이벤트 채널 -> 각 기능에서 특정 상황일 경우 이벤트를 발생시키는 클래스.

이렇게 세가지 클래스를 가지고 있음.

각 기능의 경우 아래의 룰을 철저하게 지키고 있음.

1. 다른 기능을 절대 참조하지 않음.

2. 각 기능의 공개 데이터는 중앙의 "캐릭터 데이터"를 통해서만 공개

3. 각 기능의 공개 함수는 중앙의 "기능 직접호출"을 통해서만 공개

4. 기능 실행으로 인한 이벤트는 중앙의 "이벤트 채널"을 통해서만 공개.

매우 간단한 예를 들어서, 캐릭터의 이동 기능을 생각해보자.

아래와 같은 처리가 필요하다고 가정한다.

1. 현재 캐릭터가 이동 가능한 상태인지 체크

2. 이동을 시작

3. 이동 방향으로 캐릭터 모델을 회전 & 걷는 애니메이션 발동.

정말 기본적인 기능이지만 이것만으로도 몇개의 의존성이 발생한다.

1. 캐릭터의 현재 상태를 체크하는 기능

2. 이동 기능

3. 캐릭터 모델 제어 기능

이동 기능을 정말 대충 코드로 써보자면 아래와 같은 코드가 될것

위의 코드로 작성할 경우 몇가지 문제가 생기는데, 가장 알기 쉬운것 2가지만 보면,

1. CharacterCondition 또는 CharacterModelCtrler 컴포넌트가 없을경우 에러 발생.

2. Movement 단위 테스트가 불가능. 컨디션과 모델 컨트롤러도 테스트를 위해 준비해야 함.

위의 코드를 새로운 시스템 설계로 변경하면 아래와 같이 변경할 수 있음.

보면 캐릭터 모델 컨트롤러와 오리엔테이션 의존성이 없어진것을 확인 가능.

이렇게 변경하는것으로 단위 테스트 할 때에는 중앙 데이터를 알맞게 설정해주기만 하면 다른 컴포넌트의 유무는 신경안쓰고 바로 테스트 가능. 

게다가 모델 컨트롤러를 설정 안해도 이동 기능은 아무 문제 없음. 

참고로 중앙 센터의 세가지 클래스 코드를 매우 간단하게 써보자면 아래와 같음.

여태까지 여러가지 방법을 시도해봤는데, 현재 이 방법이 가장 테스트 하기도 쉽고 기능 추가 변경 삭제도 마음대로 되는듯.

피드백 환영.

[소닉쫄따구테일즈(dcz3xv7zgu14)]

근데 저렇게 변경해도 CharacterMovement에서 기능테스트를 하려면 CenterMethod의 SetOrientation을 만져야 하는거아님? 아니면 SetOrientation에 Mock기능을 달아놓고 CharacterMovement만 일단 기능테스트를 한다는건가. 근데 SetOrientation자체가 CharacterMovement에 구현할 '기능'인거잖어. 뭔가 생각하는 독립성 느낌은 크게 안나네. 대신 장점으로는 CenterMethod에서 모든 말단(Leaf)액션들을 들고 있고, CharacterMovement같은 기능은 추상적인 기능(Move같은)을 래핑하는 효과같은게 있긴 하것네. 단위테스트하기에는 좋긴할듯

[일본뇌염모기2(mosquitoindie1)]

SetOrientation은 모델 컨트롤러에서 담당함. Movement는 단지 오리엔테이션을 설정한다는 함수를 부르고 있을 뿐이라 실제로 모델이 돌아가는지는 신경 안씀. SetOrientation 테스트는 모델 컨트롤러의 단위 테스트에서 실시

[일본뇌염모기2(mosquitoindie1)]

Movement의 단위 테스트에서 체크하는건, 1. 데이터를 체크하는가 2. 오리엔테이션 변경 함수를 부르는가 3. 애니메이션 이벤트를 발동시키는가 이것 뿐이라 다른 기능과는 완전 독립되게 생각할 수 있게 됨. 실제로 모델이 돌아가는지 어떤지는 Movement는 신경 안쓴다는거

[소닉쫄따구테일즈(dcz3xv7zgu14)]

나쁘지 않은 구조같네. ModelController가 없어도 일단 CenterMethod에 SetOrientation빈껍데기 함수 만들어놓고 CharacterMovement기능만 신경써서 구현을 해도 되고. ModelController도 실제 구현이 되면 SetOrientation에 연결만 지어주면 되고. CharacterMovement가 안붙어있으면 그냥 실행안되면 되기도 하고. 기발한데? 현업하면서도 이런구조로 짜는건 첨본듯

[소닉쫄따구테일즈(dcz3xv7zgu14)]

생각나는 유일한 단점이라고하면 기능 만들때마다 Center쪽함수랑 기능캐시변수하나씩 만들어야 하는 번거로움정도? 근데 그건 한번만 하면 되서 단점이라고하기엔 미미하네. 난 좋은듯

[일본뇌염모기2(mosquitoindie1)]

ECS 로 하면 이런 고민 안해도 되는거 아닌가 싶음.

[익명(1.235)]

현업 3n아니지?

[소닉쫄따구테일즈(dcz3xv7zgu14)]

3n 한군데서 5년정도 있다 나왔음. 네가 말하는 컴퍼넌트 패턴은 수도없이 봤지만, 내가 첨본다고 말한 의미는 Center에서 기능별 의존성을 하드코딩하는 방식을 이렇게 적극적으로 한걸 첨봤다고 한거임. 솔직히 순수하게 컴퍼넌트 패턴이면 Center에서 저렇게 하드코딩하면 안되지. 근데 명시적으로 Center에서 의존성을 하드코딩으로 커플링하는것도 난 나쁘다고 생각하지 않다는거임.

[소닉쫄따구테일즈(dcz3xv7zgu14)]

ECS에서는 일단 기능A는 정말로 A기능만 하고 B는 B기능만 함. 보통은 if 무적이 아니면 데미지 주고, 무적이면 데미지 주는 식의 로직을 짜는데 ECS에서 예를들면 A기능이 데미지시스템이고, B기능이 데미지무시(무적) 시스템 이라 하면 A에서는 일단 데미지를 전부 계산해서 데미지데이터를 주욱 만들고 B에서 무적인 대상에 가해진 데미지데이터를 삭제하는 식임 A는 무적여부를 따지지 않으니 B랑 의존성이 없음 B도 데미지계산시스템에 대한 의존성 없이 그냥 무적대상에 가해진 데미지데이터를 삭제만 하면 됨.

[소닉쫄따구테일즈(dcz3xv7zgu14)]

근데 ECS라고 다 의존성 분리가 되는건 아님. 의존성을 피하기 위해 그만큼 중간에 데이터(컴퍼넌트) 타입이 많이 생성됨 설계하기도 쉽지 않고. 그래서 일단은 OOP관점으로 시스템 설계하고, ECS에서는 하나씩 분리해나가는 방식으로 함. 어쨌든 DOD는 데이터지향방법론이라 직관적인 코드랑은 많이 멀어지거든.

[소닉쫄따구테일즈(dcz3xv7zgu14)]

솔직히 위에 있는건 순수한 컴포넌트 패턴이라기보단, 구성요소(Composition)패턴이라고 보는게 낫겠네.

[일본뇌염모기2(mosquitoindie1)]

소쫄 // 근데 ECS 설명 듣다보면 매우 매력적임. 이번 프로젝트 끝나면 나도 도전해볼거 같음. 여러가지로 피드백 감사감사

[익명(1.235)]

그냥center c,m,e를 하나로묶으면 흔한구조아니냐 이벤트가 원래그런거지..

[익명(1.235)]

예시를 하드코딩 컴포지션처럼 들어놓고..

[일본뇌염모기2(mosquitoindie1)]

튜토리얼이나 샘플코드 보면 다 인스펙터로 컴포넌트 가져오거나 겟 컴포넌트로 불러서 함수 부르던데 다른 구조가 있음?

[익명(1.235)]

말그대로 컴포넌트패턴 너는 유니티예제만본거같음

[익명(1.235)]

https://mentum.tistory.com/579
뭐가크게다른지설명가능
?
통신방식 디커플링시킨거랑

[일본뇌염모기2(mosquitoindie1)]

내가 시도하고 있는건 컴포넌트 패턴에서 자주 나오는 커플링을 완전히 없애려고 하는거임. 니가 건 링크에도 나와있네. 가장 밑에 컴포넌트들은 어떻게 통신하는가? 여기에. 1. 컨테이너 객체의 상태를 변경하는 방식 -> 컴포넌트의 실행 순서에 의존하게 됨. 2. 컴포넌트가 서로 통신하는 방식 -> 커플링이 강해진다. 3. 메시지로 통신하는 방식 -> 이걸로 구현 불가능한 기능이 존재함.

[소닉쫄따구테일즈(dcz3xv7zgu14)]

저 사이트에서는 컴포넌트 패턴이라 부르는데, 외국애들은 컴포지션 패턴이라고 많이 부르는거같던데. 왜냐면 클래스가 기능들을 소유하는 방식으로 정의를 해서 그렇게 말하는듯

[일본뇌염모기2(mosquitoindie1)]

링크의 예시에서 나오는 Action을 활용한 컴포넌트 패턴이 이 글의 "이벤트 채널"인데, 이것만으로는 구현이 불가능한 기능이 몇개 있었음. 예를 들어서 상대방의 캐스팅을 방해 성공 했을 때 만 침묵을 건다 라는 스킬의 경우, 상대방에게 공격을 시도 한 뒤 그 공격의 성공 여부를 리턴값으로 받아야함. 근데 액션가지고는 리턴값이 없어서 그게 안됨. 결국 직접 컴포넌트끼리 서로 통신하는 방법을 해야 하는데, 그러면 강한 커플링이 발생해서 테스트나 변경 같은게 너무나 힘들어졌음. 그래서 본문처럼 중앙 레이어를 하나 더 집어넣어서 커플링을 없애려고 하는거

[일본뇌염모기2(mosquitoindie1)]

요약하자면, 체인으로 발동하는 기능의 경우 컴포넌트 끼리의 커플링을 피할 수 없었고 그 커플링으로 인해서 테스트와 변경이 매우 어렵게 됨. 그것을 해결하기 위해서 중앙 레이어라는 빈 껍데기를 만들어놓고 각각의 컴포넌트에게는 빈 껍데기만 들게 함. 빈 껍데기가 실제로 발동 하는지 안하는지는 각각의 기능들이 신경쓸 필요가 없으므로 커플링 문제가 해결되고, 추가 변경 테스트를 매우 쉽게 할 수 있었음. 위의 댓글 초반 부분에 구체적인 설명 있으니 참고해