[📚정보] [책 번역] Jared Halpern의 유니티 2D인디 게임 Ch3-2

[ㅆㅇㅆ(112.109)]

객체(Entity)-구성요소(Component) 디자인

컴퓨터 과학에선 '관심사 분리(역자주: Separation of Concerns,통칭 SoC라고 불림)'로 알려진 개념이 있습니다.

관심사 분리는 소프트웨어가 수행하는 기능에 따라 모듈이 어떻게 나뉘는지 설명하는 설계 원리입니다.

각 모듈은 해당 모듈에 완전히 캡슐화되어야하는 단일 단일 기능인 '관심(Concern)'을 담당합니다.

구현과 관련하여 우려되는 사항은 다소 느슨한 해석학적인 용어(interpretive term)일 수 있습니다, 이러한 우려는 

화면에 그래픽을 랜더링하는 것에 대한 신뢰성의 원칙만큼 광범위하거나 공간상의 삼각형이 다른 삼각형과 겹칠때

계산하는 것만큼 좁은 범위의 문제일 수 있습니다.

소프트웨어 설계에 있어, 관심사(Concerns)를 분리하는 주된 이유 중 하나는 개발자가 중복되는 기능을 작성하는 개발력의 낭비를 줄이기 위함입니다.

예를들어 화면에 이미지를 렌더링하는 코드가 있으면, 해당 코드를 1회만 작성하면 됩니다.

비디오 게임은 그래픽을 화면에 렌더링해야하는 수십 또는 수백가지의 상황을 가지고 있으나, 개발자는 그 코드를 단 1회만 작성하면되고

어디에서나 재사용할 수 있습니다.

유니티는 개체-구성요소라고 불리는 게임 프로그래밍에서 매우 인기있는 디자인 패턴을 가지고, 

관심사를 분리하는 철학을 기반으로 합니다.(역자 주: 유니티 개발 철학 자체가 개체-컴포넌트 철학을 기반으로 하고 있다는 말)

객체-구성요소 설계는 '상속(inheritance)보다도 구성(Coposition)"을 선호합니다. 이것은 개체(Object)나 객체가 특정 기능을 캡슐화하는

클래스의 인스턴스(instances)를 포함함으로써, 코드의 재사용을 장려한다는 개념입니다.

객체는 이러한 구성요소 클래스의 인스턴스를 통하여 기능에 액세스(접근) 할 수 있습니다.

적절하게만 사용한다면 구성(Composition)을 더 적은 양의 코드로 얻을 수 있고, 

(코드에 대한) 이해와 유지 보수가 더 쉬워질것입니다.

이는 객체가 상위클래스로부터 기능을 상속받는 일반적인 설계 접근법과는 엄연히 다릅니다.

상속을 사용하는 것의 단점은 깊으면서도 넓은 상속 트리로 이어질 수 있다는겁니다.

부모 클래스에서 작은 한 가지를 바꾸는 것은 의도하지 않은 결과를 초래하는 파급 효과를 지닐 수도 있다는 것입니다.

유니티의 객체-구성요소 디자인에서 게임오브젝트라고 불리는 것들은 객체(엔터티,Entity)이며, 컴포넌트는 컴포넌트라고 부릅니다.

Unity Scnene의 모든 것은 게임 오브젝트로 간주됩니다만, 게임 오브젝트 자체로는 아무런 것도 하지 않습니다.

컴포넌트에서 모든 기능을 구현한 다음 이러한 컴포넌트를 게임 오브젝트에 추가하여야 우리가 원하는 것을 합니다.

객체에 기능과 행동(benhavior)를 추가하는 것은 그 객체에 구성요소를 추가하는 것만큼 간단합니다.

컴포넌트 자체는 하나의 모듈에만 초점을 맞추고 다른 문제 및 코드와 분리되는 별개 모듈이라고 생각할 순 있습니다.

다음 다이어 그램을 참조하여 가상의 게임 설정에서 객체-구성 요소 설계가 어떻게 사용되는지 알아보세요!

동작을 제공하는 컴포넌트는 Top X-axis(상단 X축)에 있고, 게임내 객체는 좌측의 y열(Column)에 있습니다.

보시다시피 플레이어와 적에게는 4가지 구성요소와 기능이 모두 필요합니다. 

창(wepaon)은 대부분의 기능,특히 던질때 물리학이 필요합니다만 오디오는 필요치 않습니다.

나무에는 물리적 상호작용이나 오디오가 필요하지 않습니다. 나무에 부딪히면 통과할 수 없도록하는 그래픽 렌더링 및 충돌 감지만 있으면 됩니다.

앞의 예에서 주민(Villager)은 그래픽과 충돌 감지가 필요하지만 씬(Scene)에서 주위를 그저 어슬렁 거리기 때문에 물리학이 필요치 않습니다.

하지만 게임에서 플레이와 상호작용하는 주민의 오디오 트랙을 재생할려면 오디오가 필요할 수 있습니다.

객체-구성요소 설계는 특히 대형 프로젝트에서 제한(Limitations)이 있었고, 수년이 지난 후에야 비로소 전성기가 왔습니다.

향후, 지금보다 더 데이터 지향적(data-oriented) 설계(디자인)으로 대체될 예정입니다. 이제 이 새로운 지식을 활용하여 봅시다.