250122 TIL - ECS Architecture

ECS 구조 맛보기

개요

"Entity-Component-System"

게임의 오브젝트를 엔티티, 컴포넌트, 시스템으로 분할해 다루는 기법!!

• Entity : 어떤 값도, 어떤 함수도 아닌 순수 식별자!!
• Component : 어떠한 조작도 가해지지 않는 순수 데이터!!
• System : 어떠한 데이터도 저장하지 않는 순수 처리 로직!!

라고 하면 무슨 말인지 도통 와닿질 않으니, 그림을 하나 그려보자면?!

게임 오브젝트들을 이런 느낌으로 분할해볼 수 있다!! Entity는 명찰 같은 거고,

Component는 오브젝트들의 속성, System은 오브젝트들의 행위를 담는다고 생각해보자!! 조금 더 그려보자면?!

 

각각의 Entity에는 관련된 Component들이 존재하고, (속한다는 개념이 절대 아님!!)

System도 필요로 하는 Component들이 있다!! 이렇게 연관된 요소들이 서로 불러오고,

어우러지면서 게임 오브젝트의 행위들이 수행되게 된다는 것!!

---

ECS 모델의 장점

• Performance : 캐시화하기 용이한 데이터 구조기 때문에!! 인메모리를 잘 활용하는 서버라면 효율이 극대화될 듯?!
• Modularity : 분할된 구조기 때문에, 게임의 로직 각각을 관리하거나, 새로운 로직으로 확장하는 일 등이 수월함!!
• Scalability : 이어지는 이야기지만, 확장성이 뛰어남!! 아래에서 그림 또 그려보자!!
• Maintainability : 데이터(Entity, Component)와 로직(System)이 분리되어있기 때문에, 디버깅이나 최신화하기도 좋음!!

전진이라는 System은 위치 Component를 가진 모든 오브젝트를 이동시킨다고 가정해보자!! 

만약 좀비라는 새로운 오브젝트를 구현해야하고, 이 녀석 역시 전진을 시킬 필요가 있다면,

그저 새로 만든 좀비 Entity에 위치 Component를 연관시키기만 하면 된다!!

전진 System은 이미 모든 녀석을 이동시켜주고 있으니 수정할 필요가 없고,

위치 Component도 기존에 있던 녀석을 그대로 쓰면되니 수정할 필요가 없다!!

 

유지 보수 측면에서도 분할된 구조는 아주 유용하다!!

특히 ECS는 데이터와 로직으로 딱 구분이 되기 때문에,

데이터 자체가 유효하지 않아 생기는 문제인지, 로직 상에 문제가 있는 건지 등을 파악하기 수월하다!!

원인 발견 후에 수정 역시 간단!!

---

ECS 모델의 단점

• Learning Curve : 고차원적인 구조기 때문에, 이를 습득하기 위한 수고가 크다...!
• Complexity : 모델을 최적의 환경과 접목시키기 위해선 정말 치밀한 기획 설계가 필요함!!
• Overhead : 분할 구조의 필연적인 문제, 분리된 요소들을 모으느라 처리 시간에 지연이 약간은 생길 수 있다!!