본문 바로가기
개발 (Game)/Unity (DOTS)

[DOTS] 기본 이론 및 ECS 내용 정리

by 진현개발일기 2025. 3. 1.

■ 참고

https://www.youtube.com/watch?v=Bz24Jp30nkM

 

■ DOTS Packages 

Dots와 연관된 사항은 아래와 같다.

 

1. Entities (ECS)
2. Entities Graphics
3. Netcode for Entities
4. Physics
5. Jobs
6. Collections
7. Burst
8. Mathematics

■ ECS (Entity Component System) 

(출처) 맨 위에 기재된 영상

 

(1) 기존 OOP와 달리 ECS는 Data-Oriented Design (DOD) 원칙을 기반으로 게임 로직과 데이터를 분리하는 기법이다.
· 이는 효율적인 데이터 처리 및 코드 모듈화와 확장성 증대 효과를 가져다준다.

(2) ECS의 이름을 정확히 표현하자면 Entity & Component & System 로 생각하면 된다.

구성 설명
Entity  A "Thing"
: Actually Nothing. Index and a version number
Component Data
: Actual Data associated with an Entity. C# Job System이랑 쉽게 작용 가능
System  Transformation
: Modifies data to make gameplay happen,

(게임 로직이라고 생각하면 됨. 메인 스레드에서 동작하며, 워커 스레드에 Jobs를 스케쥴링함으로써 병렬 처리를 할 수 있게 해줌)
※ 요약하자면, ECS 자체가 멀티스레딩은 아니지만, C# Job System과 같이 잘 활용한다면 멀티스레딩의 이점을 얻을 수 있다.

■ Entities Graphics (Optional Package)

· Allows rendering of Entities in the game world
· UPR, HDRP Compatible
· Unity ECS를 사용한다면, 일반적으로 사용하는 것이 이상적임. 수동적으로 개체들에 대한 데이터 및 렌더링 과정을 동기화할 필요 없이 알아서 렌더링해주기 때문

■ ECS 사용 고려 시 유의할 점

 처음에 Monobehaviour 방식으로 설계를 한 뒤 ECS 구조로 변경하려고 하는 것은, 큰 프로젝트 일수록, 매우매우 어렵다.
그러므로 처음부터 여러 요소를 고려한 뒤 설계 방향을 ECS를 쓸지 혹은 Monobehaviour 방식으로 갈지 정해야 한다.

 

[언제 ECS를 써야할까?]

· 정말 많은 Entity가 CPU-side에서 컨트롤 되어야 할 때 (Large entity counts that need to be controlled by the CPU)
· 경쟁 멀티플레이 게임 (Competitive Multiplayer)
· 저사양 기기에서도 높은 비용을 가진 연산을 많이 수행해야할 때 (Other performance intensive workloads)
· DOD 기법을 원할 때


[언제 ECS를 쓰지 말아야 하는가?]

· 위에서 언급한 [ECS를 써야하는 상황] 중 어느 곳에도 포함이 안될 때
· 처음으로 만들어본 게임일 때 (DOD는 경력이 있는 개발자에게 추천하는 기법임)
· 그냥 새로운 기술이라서 써보고 싶을 때

 

■ DOTS의 단점 

 

· 아직 관련 기술에 대한 채용 풀이 적다.

 

· 나온지 오래된 기술이 아니다보니, 아직 발견되지 않은, 버그가 발생할 수 있다.

 

· low-level computing concepts (ex. 컴퓨터 구조, 운영체제 등), learn DOD, a whole new API 모두 배우기 까다롭다.

 

· 만약 충분한 컴퓨터 관련 지식이 없다면 본인의 코드가 더 안좋은 성능을 야기할 수 있을뿐더러 잘 알고 있어야 DOD의 이점을 잘 활용할 수 있기 때문이다.

 

· 여러가지 syntax, API 등 너무 많기 때문에 거의 새로운 언어를 배우는 것이나 다름 없다.

 

■ 유의할 점

DOTS방식으로 간다고 해서 모든 스크립트 및 구조를 DOD방식으로 갈 필요가 없다.
몇몇개는 기존대로 GameObject 방식으로 가도 괜찮다.
오히려 이상적인 방식이 둘을 적절히 혼합해서 사용하는 방식이다.