1. 기존 monobehavior
- 스크립트 작성 -> 오브젝트에 딸깍
2. dots
- IComponent를 상속하는 ecs용 컴포넌트를 만들어야 함
- 게임오브젝트랑 연동하려면 컴포넌트와 최소 일대일대응이 되는 Authoring 데이터도 만들어야됨
- 메인스레드에서 돌리려면 SystemBase 상속받는 클래스로
- 다중스레드 작업으로 진행하려면 ISystem 상속받는 구조체로
- 컴포넌트가 담은 데이터가 많으면 IAspect를 상속받아야 함
- SystemAPI를 계속 호출해서 쿼리를 해야함. 쿼리는 어떤 컴포넌트를 가진 애들만 찾아서 for문 돌리는거임
- 값 받을때는 레퍼런스로 받아오는게 권장됨. 값도 ValueRW, ValueRO가 있음
- Aspect 만들때도 레퍼런스로 계속 받아오는게 권장됨
어 시발 안해~ 병목걸려도 그냥 쓰던데로 할거임
이거 딮하게 팔바엔 언리얼 함
- 스크립트 작성 -> 오브젝트에 딸깍
2. dots
- IComponent를 상속하는 ecs용 컴포넌트를 만들어야 함
- 게임오브젝트랑 연동하려면 컴포넌트와 최소 일대일대응이 되는 Authoring 데이터도 만들어야됨
- 메인스레드에서 돌리려면 SystemBase 상속받는 클래스로
- 다중스레드 작업으로 진행하려면 ISystem 상속받는 구조체로
- 컴포넌트가 담은 데이터가 많으면 IAspect를 상속받아야 함
- SystemAPI를 계속 호출해서 쿼리를 해야함. 쿼리는 어떤 컴포넌트를 가진 애들만 찾아서 for문 돌리는거임
- 값 받을때는 레퍼런스로 받아오는게 권장됨. 값도 ValueRW, ValueRO가 있음
- Aspect 만들때도 레퍼런스로 계속 받아오는게 권장됨
어 시발 안해~ 병목걸려도 그냥 쓰던데로 할거임
이거 딮하게 팔바엔 언리얼 함
iaspect도 어쩌면 없앨지도 모른다는 얘기 떠돌고있음. 얘내들 수시로 api바뀌는건 이젠 놀랍지도 않음. 예전엔 transform가지고도 막 바뀌었었디. 프로덕션버전이 맞나 싶을 정도. 정말 이대로 가다가 버려질거같은 느낌
ㅋㅋ자꾸 갈아엎는거 ㅈㄴ열받음 나도 걍 때려쳤음
배워도 지원 지속안해주고 버려질거같은느낌 그냥 시간아까움
SystemBase는 Managed Data(GC가 관리하는 데이터)도 써야할 때 쓰는 시스템이고, ISystem은 UnManagedData만 쓸 때 쓰는 시스템임. 다중쓰레드ystemBase는 Managed Data(GC가 관리하는 데이터)도 써야할 때 쓰는 시스템이고, ISystem은 UnManagedData만 쓸 때 쓰는 시스템임. 다중쓰레드랑은 상관 없음.
이상 특성으로 인해 ISystem은 BurstCompile이 될 수 있어서 SystemBase보단 훨씬 빠름. 그래서 메인쓰레드에서만 돌릴 작업은 가능하면 ISystem으로 하는 것을 추천함.
IAspect는 데이터가 많이 담긴 컴포넌트를 부를 때 쓰는 것이 아님. IAspect는 여러개의 컴포넌트를 동시에 부를 때 쓰는 것인데 별로 쓰이진 않음. 애초에 데이터가 많이 담긴 컴포넌트는 차라리 여러개의 컴포넌트로 나누는 것을 권장함.
Authoring은 게임 오브젝트랑 연동하는 것이 아님. 게임 오브젝트를 Entity World의 Entity로 변환하는 과정임. 이 과정을 Bake라고 부름. 이건 dots에서 가장 쉬운 부분임. 유니티 공식 예시 코드를 그대로 복붙해서 원하는 컴포넌트만 만들어서 복붙하면 되니까.
ValueRW, ValueR0는 그냥 읽기/쓰기 권한이랑 읽기 전용 권한의 차이일 뿐, 그냥 전부 다 ValueRW으로 해도 문제 없음