기존 유니티 컴포넌트 시스템은 객체지향적, 즉 OOP로 설계되어있다. 유니티에서는 객체지향의 성격에 따라 각 컴포넌트들은 게임 오브젝트에 더해지는 방식으로 작동되었다.
이때 컴포넌트들은 메모리에 연속적으로 저장되는 것이 아니라 메모리 랜덤위치에 저장되어 게임 오브젝트와 연결이 된다. 이 방식은 캐시 적중률이 낮아져 여러개의 오브젝트들이 쌓일수록 효율성이 떨어지고 만다.
이러한 단점들을 해결하기 위해 유니티는 새로운 컴포넌트 시스템을 만들었다. 그것이 바로 ECS(Entity Component System) 이다.
ECS은 객체지향이 아닌 데이터 지향 기술 스택(DOTS)으로 설계된 시스템이다. 여기서 E, C, S는 해당 시스템을 구성하는 요소라고 볼 수 있다.
데이터 집합을 말한다. 예를들어 Position 컴포넌트는 x 좌표, y좌표, z좌표의 '위치'데이터만 가질 것이다.
컴포넌트의 집합이다. 우리가 아는 게임 오브젝트를 엔티티라고 한다. 예를들어 큐브 엔티티는 Position, Rotation 컴포넌트를 가질 수 있을 것이다.
객체지향에서의 메소드의 개념이다. 예를들어 moveSystem은 Position, Rotation 컴포넌트를 가진 엔티티들을 대상으로 키 입력시 Position 데이터를 변경할 것이다.
OOP에서는 행위와 상태를 같은 엔티티가 가지고 있었던것과 다르게, ECS에서의 엔티티는 단순히 데이터를 가리키는 인덱스일 뿐이다. 행위는 시스템이 결정한다.
그럼 여러가지 의문점이 든다. '아니, 그래서 데이터가 어떻게 저장되는건데?', '시스템이 어떻게 동작 하는건데?' 이 부분에 대해서 차례대로 살펴보자.
ECS에서의 컴포넌트의 저장 방식은 두 가지가 있다. 하나는 컴포넌트별로 묶어서 배열로 만든 방식인 Sparse Set 방식, 또 하나는 같은 컴포넌트 조합별로 묶은 방식인 Archetype 방식이다.
Sparse Set 방식은 컴포넌트 배열을 만들어 거기에 해당 id 엔티티의 데이터값을 저장한다. 이렇게 하면 아무리 많은 엔티티가 있더라도 for loop만 돌면 작동을 한다.
이렇게 하면 편하지만 문제는 데이터가 낭비되고 캐시 적중률이 낮다는 문제가 있다.
- 배열의 묶음을 이야기한다. 다르게 말하면 Chunk의 묶음이라고도 할 수 있다.
### Chunk란?
- 16kb로 크기가 정해져 있는 배열의 묶음 - 예를 들어 'Rigidbody, Collider, Controller' 컴포넌트들을 가지는 엔티티는 저 세개의 컴포넌트 세트를 가지는 청크로 묶어 저장하는 것이다.
Chunk 하나의 데이터는 메모리상에 촘촘히 저장된다. 따라서 캐시 적중률이 높아진다. 그러나 Chunk는 크기가 정해져 있기 때문에, 꽉 차면 연결리스트로 새로운 청크를 생성한다. 이렇게 되면 캐쉬미스가 좀 더 발생하겠지만, 데이터를 다루기는 편하다.
아키타입은 이렇게 같은 컴포넌트 묶음의 Chunk들로 이루어져 있기 때문에 **컴포넌트 Set이 같다면 같은 아키타입으로 저장된다고 볼 수 있다.**
기존 특정 컴포넌트에 접근하여 함수를 사용하는 방식이 아니라, 따로 만든 시스템에 접근하여 원하는 컴포넌트 묶음을 가지는 모든 엔티티들을 찾고, 그 엔티티들을 "다음과 같이 가공하고 실행시키겠다"고 정적으로 선언하여 동작시킨다.
메모리에 연속으로 할당된 청크 리스트에 접근하여 엔티티를 찾는것이기 때문에 기존 컴포넌트 시스템보다 캐시 적중률이 높아 명확하게 성능 향상을 가져올 수 있다.