게임 엔진의 원리
게임 오브젝트와 컴포넌트
- 게임 엔진을 사용하는 이유
도구를 만드는 것이 아닌 도구를 어떻게 사용할 지 정의 (게임 로직)
이미 만들어진 기반(API, 컴포넌트 등)의 재사용 - 기존 상속 (inheritance) 시스템의 한계
상속 시스템의 이해
이미 만들어진 클래스를 기반으로 기능을 덧 붙여서 새로운 클래스를 만드는 방법
base class (기반이 되는 부모 클래스)
derived class (부모 클래스를 확장해서 만든 자식/확장 클래스)
부모 클래스를 가진 채로 자신 만의 코드를 덧 붙여서 만들어짐
부모 클래스에 작성된 코드를 다시 작성할 필요가 없음
ex1) class Monster → class Orc : Monster → class OrcChieftan : Orc
ex2) class Character → class Player : Character, class NPC : Character, class Monster : Character
상속이 항상 잘 동작하는 것은 아님
완벽하게 순수한 base class를 만드는 것은 힘듬
A is B
자식 클래스는 선택적으로 상속할 수 없음 (자식 클래스가 필요로 하지 않는 기능도 상속하게 됨)
미래에 사용될 "최소 필수 집합"을 미리 예상하는 것은 힘듬
상속에만 너무 의존하면 오히려 코드를 재사용하기 어려운 상황이 발생
기획자가 프로그래머에게 의존하게 됨 - 게임 오브젝트-컴포넌트 방식 / 컴포넌트 패턴 / 컴포지션 패턴 (상속 시스템 대안 방법 )
A has B,C,D...
비어있는 컨테이너(게임 오브젝트)를 만들어 놓고 선택적으로 기능(컴포넌트)들을 골라서 붙이는 방식
게임 오브젝트
단순 홀더(Holder), 빈 껍데기
컴포넌트를 붙일 수 있음
컴포넌트
미리 만들어진 부품으로 각자 대표 기능을 가짐 (스스로 동작하는 독립 부품)
게임 오브젝트에 붙일 수 있음
유연한 재사용 / 기획자의 프로그래머 의존도가 낮아짐 / 독립성 덕분에 추가와 삭제가 쉬움
ex1) Transform Component : 게임 오브젝트에게 위치 크기 회전을 가질 수 있는 기능을 부여
ex2) Ridgidbody Componet에 로직(스크립트작성)을 추가하여 기능을 부여
컴포넌트 덕에 바닥부터 만드는 것이 아닌, 이미 존재하는 다양한 부품들에 로직만 추가하여 조립하는 형태
메시지와 브로드캐스팅
- 컴포넌트 : 자신의 기능을 스스로 내부에서 완성시킨 독립적인 개체
외부의 간섭을 받지 않는 각각의 컴포넌트들이 어떻게 스스로를 동작 시킬까? - 컴포넌트의 구조
MonoBehaviour를 상속 + 컴포넌트 고유의 기능
MonoBehaviour (컴포넌트로서 필요한 필수 기능들이 존재)
컴포넌트로서 게임 오브젝트에 추가될 수 있음
유니티의 통제를 받음
유니티 이벤트 메시지를 감지할 수 있게 됨
메시지
보내는 쪽은 누가 받는지 신경쓰지 않음
받는 쪽은 누가 보냈는지 신경쓰지 않음
메시지에 명시된 기능을 가지고 있으면 실행, 없으면 무시
브로드캐스팅
메시지를 무차별적으로 많이 보내는 것
유니티는 실행해야 될 기능이 있으면 해당 기능을 메시지에 담아서 게임 오브젝트 전체에 브로드캐스팅을 보냄
이 방법 덕분에 유니티 엔진은 이곳 저곳을 거쳐서 원하는 오브젝트를 겨우 찾아 간 다음, 원하는 기능을 쓰는 수고를 하지 않아도 됨. 그저 메세지를 게임 세상에 뿌리면 됨. 이 때문에 컴포넌트들이 서로 얽혀 있을 필요가 없어 컴포넌트들은 자유롭게 게임 오브젝트에 독립적으로 붙이고 떼어낼 수 있음. - 유니티 이벤트 메서드
이름만 맞춰 구현하면, 해당 타이밍에 자동으로 실행
Start, Update, OntriggerEnter... - 메시지/브래드캐스팅 시스템
복잡한 참조 관계를 끊고 각각의 게임 오브젝트들이 라이프 싸이클을 스스로 관리할 수 있게함
정리
유니티의 모든 컴포넌트는 MonoBehaviour 기반
컴포넌트는 메시지를 받을 수 있음
메시지에 해당하는 기능을 가지고 있으면 실행
이벤트 기반 메서드는 메시지를 통해 "실행되야 할 타이밍에" 자동 실행
hi