컴퍼넌트 패턴 & 이벤트 큐 정리

보통 다른 코드는 서로 격리해야 한다고 배운다.

한클래스안에서 많은 내용을 처리하게 된다면 하나 수정에 엄청나게 많은 작업이 필요하다는것 이다.

머잖아 이런 클래스는 기능보다 버그가 더 빨리 늘어난다.

디커플링 패턴이 컴퍼넌트 패턴임..

예를 들어

if(물리상태 && 그래픽 상태 != 안보임)

플레이 사운드

이런 코드가 있다면 전부 알아야 한다. 보통 하나가 게임 코드를 분야별로 스레드에 분배하는 것이다. 각각...

이렇게 하려면 디커플링이 되어야 하는데..

커플링과 코드 길이 문제는 서로 악영향을 미친다. 한 클래스가 너무 많은 분야를 건드리다 보니 모든 프로그래머가 그 클래스를 작업해야 하는데, 클래스가 너무 크다 보니 작업하기가 굉장히 어렵다. 이런 상황이 심해지면 프로그래머들이 뒤죽박죽이 된 클래스를 손대기 싫어서 다른곳에 땜빵코드를 넣기 시작한다.

우선 기능별로 분리해서 클래스를 생성한다.

물론 그 클래스에서는 게임오브젝트를 수정할 수 있도록 게임오브젝트를 매개변수로 받는 함수나 멤버변수로 있어야 한다.

모든 컴퍼넌트에서 사용하는것들?? 은..애매해서 보통은 게임오브젝트에 둔다라..

컴퍼넌트도 상속이 될 수 있도록 인터페이스와 구현부를 나누고..

어떤 컴퍼넌트 집합이 필요한가? 대답은 만들고 있는 게임 장르와 필요에 따라 다르게 된다. 게임 코드가 크고 복잡할 수록 컴퍼넌트를

더 세분화해야한다.

어쩄든 컴퍼넌트끼리의 통신은 필요하게 된다. 왜냐면 한 객체를 이루는 부분이기 떄문이다.

(우리 프로젝트에선

씬이 레이어들 순회 레이어는 게임오브젝트를 순회 게임오브젝트는 map 자료구조가 있고 컴퍼넌트들이 담긴다. 이걸 순회 함..)

메시지를 전달하기 위해서...

컴퍼넌트들이 상위의 보관?된 구조에 메시지를 호출하고 매개변수로 메시지값과? 데이터를 던지거나..등등 그러면 될듯..

---

동기적 이벤트에서는 뭔가 발생했다는 알림을 받으면 바로 상황을 확인할 수 있지만, 큐 이벤트는 그렇지 못하다

그래서 현재 월드 상태가 이벤트가 만들어진 당시 상황과 다를 수 있다 그렇기 때문에 동기적으로 처리되는 이벤트보다 큐에 들어가는 이벤트에는 데이터가 훨씬 많이 필요하게 된다.

비동기적이란 : 하나씩 하나씩 처리..?? 하아..이개념이아닌데..

---