뭐 당연한 거지만 위의 그림은 콘솔 쪽 PT 라 L3 캐시가 없습니다만.

메모리는 느립니다. 프로세서는 빠릅니다.

그래서 메모리에서 데이타를 읽어서 캐시에 옮겨 놓는데에는 아주 많은 클럭이 소모됩니다.

이런 함수를 실행한다고 했을때

데이타를 옮기는데 1900 클럭 실제 계산에는 20 클럭 밖에 소모 되지 않습니다.

이걸 4번 루프문을 돌면서 수행하면 ( Actor 나 GameObject 같은 인스턴스를 사용할 경우)

거의 8000 클럭이 소모됩니다.

그런데 이걸 이런 식으로 바꾸면 어떻게 될까요.

CNT 가 있는 루프문과 데이타를 어레이화 시키면 말입니다.

이렇게 최초 1번은 이전과 변함없이 2000 클럭이 소모됩니다.

하지만 데이타를 어레이로 묶어서 이미 캐시에 옮견놨기 때문에 이후의 호출에서는 데이타 이동 클럭은 발생하지 않게 됩니다.

그래서 4번 수행해도 여전히 2000 클럭입니다.

이게 4번이 아니라 100 번이나 1000 번이나 10000 번이면 어떻게 될까요?

10000 개의 오브젝트를 처리하는 시간에서 10000 배의 성능차이가 발생해 버립니다. ( 실제로는 캐시 라인 사이즈에 한계가 있기 때문에 1000 배 이상 차이가 나지는 않습니다. )

이걸 디자이너나 기획이나 아티스트가 극복가능하다고요? 무슨 그런 헛소리가 있습니다.

TA 가 없어서? 웃기지 마세요.

그냥 프로그래머가 나쁜 겁니다.

모른다면 무능한거고

안다면 배임이죠.

성능차이가 2배만 되도 불공정한 싸움인데..

최소 40 배 최대 2000 배 성능차이가 발생합니다.

저렇게 데이타를 모아서 묶어서 처리하는 것을 ECS 라고 합니다.

그렇다면 저렇게 하기 위해서는 어떻게 해야 할까요?

당연히 제일 처음에 할 일은 게임엔진을 바꾸는 겁니다.

다행이도 전세계 모든 게임엔진은 이미 대부분 저런 방식 ( ECS ) 를 채택해서 사용 중입니다.

ECS 를 사용한 AAA 급 게임은… 그냥 여러분이 아는 거의 모든 게임입니다. GTA 5 같은 것이죠. GTA 의 경우는 4 에서 5 로 넘어가면서 ECS 로 전환 했습니다.

아무튼 모든 엔진이 ECS 면 아무 문제없는 걸까요?

아닙니다. 딱 하나의 엔진이 ECS 를 거부하고 있습니다.

그 하나의 엔진은 언리얼 엔진입니다.

한국에서 그렇게 빨고 햩고 찬양하는 언리얼 엔진이지만 실제로 해외 개발사들 눈에는 … 이뭐병 스러운 엔진이죠.

엔진이 ECS 여도 프론트 엔드 단의 프로그래밍도 ECS 를 제대로 활용하는 방식이어야 하는데..

언리얼로는 가능할 리도 없죠.

에픽이란 회사가 얼마나 사악한지.. 지들 데모 만들 때는 지들도 ECS 를 사용합니다.

자존심이 있는지 ECS 대신에 EFS 라고 다른 이름을 붙였더군요. 그나마 언리얼 5 의 기능으로 추가한게 아니고

데모팀에서 정말 답이 없어서 별도 코딩으로 추가했었습니다. 

자 그렇다면 왜 넥슨은 문제가 없는 걸까요?

무슨 넥슨광고 아니고요.

제가 올린 저 PT 만든 사람은 EA 의 DICE 팀입니다.

그 다이스 팀에서 배틀필드 관련해서 여자 병사의 존재 유무 때문에 인생의 낭비 네트워크(SNS)에 uneducated 발언을 하신 분이 계십니다.

그 양반은 당연히 쫒겨났고 저 Data Oriented Design 에 전문가들을 데리고 나와서 회사를 차립니다.

근데 나와서 보니 더 이상 EA 전용 엔진인 프로스트바이트를 쓸 수도 없고

그렇다고 0에서 부터 게임엔진을 만들자니 깝깝합니다.

그래서 쓸만한 오픈소스 게임엔진을 찾아봤지만 쓸만한 건 둘째치고 오픈소스 게임엔진이 언리얼 밖에 더 있습니까.

근데 까보니까 쓰레기 인거예요.

그래서 언리얼 엔진을 저렇게 바꿉니다.

언리얼 엔진에서 최상위 클래스가 Actor 입니다.

근데 데이타 기반은 인스턴스가 제일 큰 적이기 때문에 Actor 를 갈아 엎어야 합니다.

Actor , Physics , Network 를 Rust 로 데이타 기반으로 갈아 엎습니다.

어떻게 아냐고요? 자기들이 유튜브에 올렸더라구요. 우리가 갈아 엎었습니다 하고..

그 회사의 이름은 엠바크 입니다.

넥슨이 인수한 그 엠바크 맞습니다.

넥슨의 큰 프로젝트 진행하는 스튜디오가 상당 수 엠바크로 바뀐 것을 눈치 채신 분들이 있을 겁니다.

엠바크가 직접 만든다기 보다는 컨설팅을 해주고 있는 상황일 거라고 추측합니다.

사실 언리얼 엔진도 엠바크 나 에픽 데모팀 같이 고쳐서 쓸 수만 있다면 큰 문제가 되지 않습니다.

문제는 그럴 능력 있는 사람 국내에서 1명 봤습니다. 

크래프톤에 있을 때 유럽의 크래프톤 협력 스튜디오에서 불쌍하다는 듯이..

천동설 믿어서는 배를 항해해서 바다로 나아갈 수 없다. 

농사지을 때는 천동설 가지고 되겠지만 지동설로 별의 정확한 운행을 알아야지만 대항해 시대를 맞아서 상업을 할 수 있다.

라면서 지동설을 ECS에 천동설을 OOP 에 비유하더군요.

그리고 크래프톤은 그 스튜디오에 대한 지원을 중단했습니다. 왜냐고요? 모릅니다. 경영진이 알겠죠.

한국 게임에 큰 기대 하지 마세요. 일단 프로그래머들이 글러 먹어서 수직 절벽에서 축구해야 하는 상황이거든요. 

성능 1000 배 차이를 기획으로 극복?