멋쟁이사자처럼 X 넥슨 MOD Suppoters Hackathon Chapter 8 회고

멋쟁이사자처럼 X 넥슨 MOD Suppoters Hackathon Chapter 3주차 19일 회고

 

 

 

부족하지만 멋쟁이사자처럼 X 넥슨 MOD Suppoters Hackathon에 합격하게되어서 MOD를 먼저 사용해볼 수 있는 감사한 기회를 얻게 되었습니다...! 최선을 다해 공부하고, 리뷰하겠습니다! 부족한 글 보러 와주셔서 감사드립니다!

// 해당 글은 멋쟁이 사자처럼 공동 학습 교안을 바탕을 작성되었습니다.

 

 

오늘도 사랑합니다

 

 

 

 

오늘은 Chapter 8. Event와 컴포넌트 확장에 대해 배웠다. 

 

 

 

MOD에서는 Event 처리를 위해 Entity Event System을 제공한다.

이벤트는 특정 상황에서만 발생된다.

 

 

 

아래는 Event System에 해당하는 3가지 구성 요소이다.

• Event : 로직 상에서 사건의 발생을 의미 (Event의 종류의 식별 정보, 추가 정보 소유)
  • ex) 공격을 받은 사건
• Handler : 해당 Event를 받았을 때 처리하는 행동의 주체 
  • ex) 플레이어가 공격을 받았을 때 호출되는 함수
• Sender : 해당 이벤트를 발송하는 객체 
  • AttackComponent에서 이벤트를 발송했으면 AttackComponent가 Sender이다.

 

 

이해하기 쉽게 우리가 만들었던 코드를 들고왔다.

 

 

위 코드를 예시로 용어를 좀 더 쉽게 이해해보자

Event : 엔티티간 충돌이 있어난 사건을 의미한다.

 

Handler : 이벤트가 일어났을 때 호출 될 HandlerTriggerEnterEvent를 의미한다.

 

Sender : 해당 이벤트를 발송하는 객체는 self.Entity인 유저가 될 것이다.

 

 

 

 

MOD에서 사용하는 Event 시스템의 장단점은 아래와 같다.

• 장점
  • 다른 component나 기능 단위에서 결합성이 떨어진다.
  • 행위에 대한 액션 추가 희망 시 행위 수행하는 곳 수정 없이 추가 가능하다.
  • 다른 Component의 정보를 필요로 하지 않는다.
• 단점
  • 사건 발생 시 전체적 플로우 찾기 어렵다 (각각 처리하는 로직으로 인해 실행되는 시점에서 알 수 없다)
  • 디버깅이 어렵다.
  • 순차적 행위 수행이 어렵다.

 

 

 

이번에는 핸들러의 등록 구조에 대해서 알아보자

 

 

각 엔티티들은 컴포넌트들을 포함하고 있다.

중학생 형만 하더라도 수많은 컴포넌트들을 지니고 있다.

 

 

 

 

 

엔티티 이벤트 시스템은 다음과 같이 동작한다.

 

가장 먼저 컴포넌트는 각 엔티티를 중계자로 사용할 수 있으며, 각 컴포넌트는 엔티티를 통해 핸들러를 등록한다. (이벤트 발생 역시 엔티티를 통해 가능하다.)

 

 

위 말을 Bbing Component로 설명해보겠다.

 

Bbing Component는 DefaultUser 엔티티(Self)를 중계자로 사용하며, DefaultUser를 통해 핸들러인 HandlerTriggerEnterEvent 함수를 등록한다.

 

 

 

 

sender 역시 엔티티를 통해 이벤트를 발생하는 것이 가능하며, 이 때 엔티티는 Handler들에게 해당 이벤트를 전송하는 역할을 한다.

 

 

정리를 해보자면, 어떤 event를 감지하였을 때 이것을 처리하는 부분을 component내의 로직에 넣는다. 그리고 이벤트 수신 등록을 register, addListener 등으로 하며, MOD에서는 entity에 등록을 하는 구조이다.

 

 

 

 

 

 

 

엔티티끼리 이벤트를 주고받을 때에 대해서 알아보자

 

엔티티끼리 이벤트를 주고 받는 경우는 2가지가 있다.

 

 

 

1. 같은 엔티티에서 이벤트를 주고 받을 때

짤 출처 : 이승훈님

 

 

 

 

 

 

2. 다른 엔티티끼리 이벤트를 주고 받을 때

 

 

 

 

 

먼저 같은 엔티티에서 이벤트를 주고 받을 때의 프로세스를 알아보자

1. component1이 특정 타이밍에 의해 엔티티로 발송
2. 로그 이벤트를 수신하겠다고 등록한 컴포넌트들에게 이벤트 발송
   • 로그 이벤트를 객체로 불러온 컴포넌트들
3. 해당 컴포넌트들은 이벤트를 받아서 처리

 

Ex) component1에서 이벤트 발생 시, component3의 이벤트를 실행시키고 싶을 때를 가정한다. 두 component간에 연관이 없기 때문에 component에서 바로 호출하지 않고 엔티티를 통해 호출하는 구조이다. 

 

-> 이러한 이유로 위에서 컴포넌트는 엔티티를 중계자로 활용한다고 말했던 것이다.

 

 

 

 

 

그럼 다른 엔티티에서 이벤트를 주고 받을 때의 프로세스를 알아보자

1. 신호를 보내는 엔티티 쪽에서 component들이 이벤트 발송
2. 받는 엔티티 쪽에서 신호를 받고 이벤트 수행

 

위 프로세스를 구현하는 방법을 이야기해보자!

1. Entity1의 Component1에서 이벤트 등록

2. Entity2의 Component2에서  Entity1로 이벤트 발송

 

 

 

 

Ex) Entity1이 Entity2 쪽으로 이벤트를 쏘면 Component가 수신해서 Component 안의 로그 메시지가 출력 되는 구조이며, 특히 Map Entity와 World Entity는 서로 Event를 주고받는 경우가 많아 자주 사용된다.

 

 

 

 

 

이벤트 처리는 아래의 순서로 이루어진다.

1. 이벤트를 처리할 컴포넌트 & 엔티티 생성
2. 핸들러 로직 추가
   • 핸들러 로직이 이루어지는 방법
     1. Entity Event Handler 추가
     2. 핸들러 상단 이벤트 중계자 설정
     3. 이벤트 처리 로직
3. 이벤트 발생 로직 추가

 

위 순서를 중학생 형 Entity에서 Bbing Component를 생성하는 걸 예로 들어보자

1. 중학생 형 엔티티에 이벤트를 처리할 Bbing Component를 생성

 

2. 충돌을 감지했을 때 실행될 HandleTriggerEnterEvent 핸들러 로직 추가

 

중계자 설정하는 방법

 

3. 충돌 이벤트 발생시 실행될 로직 추가

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

오늘도 부족하디 부족한 글 보느라 정말 감사하고, 제발 또 봤으면 좋겠다.

꼭 다시 놀러와주라!

 

 

사랑해요 여러분