게임 엔진의 원리: 게임 오브젝트와 컴포넌트, 메시지와 브로드캐스팅

게임 엔진을 사용하는 이유?

이미 완성된 기반 코드를 제공한다. 이를 재사용하므로써 생산성을 올린다.

그래서 게임 로직에 집중할 수 있다.

 

상속(Inheritance)

base Class - derived class 

부모클래스에서 작성된 코드를 자식 클래스에서 재사용할 필요가 없다.

 

상속이 항상 잘 동작하는 것은 아니다.

완전 순수한 base class를 만드는 것이 어렶다. 그래서 자식 클래스는 원하지 않는 기능을 상속하기도 하고 한다.

 

NPC는 죽으면 안되기 때문에 Health System을 상속받으면 안되고 움직이면 안되니까 Physics도 없어도 된다!

그러면 NPC가 character를 상속한 후, 오버라이드로 해당 기능들을 지우고 필요기능들을 덮어쓰면 원본도 훼손 될 우려가 있다.

이처럼 상속이 늘 정답인 것은 아니다.

 

즉 상속에만 의존하면 오히려 코드를 재사용하기 힘들다.

미래에 사용될 "최소 필수 집합"을 미리 예상하는 것이 힘들기 때문이다.

완벽하기 순수한 베이스 클래스를 만드는 것은 어렵다.

 

그래서 is-A 관계가 아닌 has-A 관계

 

그래서 유니티의 GameObject, Component 방식

• GameObject: 게임 속에 존재하는 사물을 가리키는 단위, 단순 홀더(Holder) 빈 껍데기
• Component: 미리 만들어진 부품, 각자 대표기능을 가진다.

GameObject에 Component를 붙이는/조립하는 방식으로 게임을 구성!

 

컴포넌트 방식의 장점

• 유연한 재사용
• 기획자의 프로그래머 의존도가 낮아짐
• 독립성 덕분에 추가와 삭제가 쉽다

컴포넌트는 스스로 동작하는 독립 부품이다.

어떤 컴포넌트를 추가하거나 뺀다고 해서 게임오브젝트가 망가지지 않는다!

로우 레벨이 아니라 게임 로직에 집중할 수 있게 된다!

 

컴포넌트가 독립적이라면 누가 컴포넌트 역할을 수행시킬까?

Start와 Update를 가지고 있다.

외부의 간섭을 받지않는 부품이 어떻게 스스로 동작시키지?

 

---

메시지와 브로드캐스팅

모든 컴포넌트는 MonoBehaviour를 상속한다.

 

MonoBehaviour

• 컴포넌트로서 게임 오브젝트에게 추가될 수 있다.
• 유니티의 통제를 받는다
• 유니티 이벤트 메시지를 감지할 수 있게 된다.

일일히 Start를 찾아서 실행하는 것이 아니라 Start를 한 번 broadcasting해주면 모든 컴포넌트가 실행됨

 

같은 게임오브젝트에 붙은 컴포넌트들끼리 서로 일부러 찾기 전까지는 모른다.

유니티의 기본 컴포넌트들은 예를 들어 초기화 메소드들은 반드시 실행해야 한다.

 

메시지

• 보내는 쪽은 누가 받는지 신경쓰지 않는다.
• 받는 쪽은 누가 보냈는지 신경쓰지 않는다
• 메시지에 명시된 기능을 가지고 있으면 실행, 없으면 무시한다.

 

브로드캐스팅

• 메시지를 무차별적으로 많이 보내는 것

유니티 이벤트 메서드

• 이름만 맞춰 구현하면 해당 타이밍에 자동으로 실행된다.
• Start, Update, OnTriggerEnter ... 등

 

메시지/브로드캐스팅 시스템

 

복잡한 참조 관계를 끊고 라이프 사이클을 스스로 관리할 수 있게 함

 

예) Update()

외부에서 직접 찾아 실행할 필요 없고 스스로 매 프레임 실행된다.

 

---

유니티의 모든 컴포넌트 MonoBehaviour기반.

컴포넌트는 메시지를 받을 수 있다. 메시지에 해당하는 기능을 가지고 있으면 실행한다.

 

이벤트 기반 메서드는 메시지를 통해 "실행되야 할 타이밍에"