2013년 11월 11일 월요일

데이터 중심 디자인



데이터 중심 디자인(Data-Oriented Design)이란 내용이 또 작년정도에 한번 들썩했었는데. 그에 대한 제 생각을 적어봤습니다. 비디오에서는 '번역하면 데이터 주도적 디자인인가?'라고 했는데 올바른 번역은 데이터 중심 디자인이네요. 데이터 주도적 디자인은 Data-Driven Design은 DOD하고는 다른 겁니다.

댓글 5개:

  1. 안녕하세요. 늘 좋은 동영상 감사히 잘 보고있습니다. ^_^)>
    9분 45초에 보면 컴포넌트 디자인을 실험하다 DOD를 해본적이 있다고 하셨는데요.
    제가 아는 컴포넌트 디자인은 이라고 알고있는데요.
    이를 구현하려면 상속, 포인터등이 거의 필수라고 생각되는데
    제가 알고있는게 맞다면 DOD와 컴포넌트 기반 디자인은 정 반대되는것 아닌지요?
    내용상 실수가 아니시라면 좀더 설명해주셨으면 합니다. 지금까지 저는 DOD를 추구하려면 개발 초기부터 DOD를 목적으로 설계하지 않으면 안된다고 생각하고 있거든요.

    답글삭제
  2. 이야.. 컴포넌트 디자인을 부등호로 감쌌더니 테그로 인식했는지 사라졌네요;;
    제가 아는 컴포넌트 디자인은
    동일한 인터페이스를 가지는 여러 컴포넌트들을 조합하여 객체를 구성하는 것
    기능 변화에 따라 동일한 인터페이스의 다른 컴포넌트들을 조합하여 재사용성을 높인다.
    라고 알고있는데요.

    답글삭제
    답글
    1. 게임 오브젝트/컴포넌트를 업데이틑 방법에 따라 DOD 가능합니다.

      그당시 제 엔진은 컴포넌트 별로 global array(fixed size)가 하나 있었구요(이미 할당을 다 해놓은 상태라 메모리상 바로 옆에 붙어있습니다). 업데이트 루프에서는 물체별로 업데이트를 한게 아니라... 컴포넌트 별로 업데이트를 했습니다. 즉 우선 AI 컴포넌트 배열을 전부 다 돌아가면서 업데이트 한뒤.. 그다음에는 physics 컴포넌트 배열을 전부 다 돌면서 업데이트 하는 식이었죠...

      컴포넌트 기반 게임오브젝트 시스템의 장점이 이런식으로 컴포넌트 종류따라 순서대로 업데이트 하는게 가능해서 메모리를 여기저기 뛰어다니지 않아도 된다는 거죠. 예전에 한참 태스트 시스템이 처음 소개되기 시작할때 나온 아이디어입니다.

      역시 말로 설명하려니 힘드네요 -_-a

      삭제
    2. 오호.. 결과적으로 여러 다른 객체에 사용된 같은 컴포넌트들을 순회하며 memcpy하는 방식으로 구현된거군요. 답변 감사합니다. ㅋ
      그래서 결과는 어땠나요?
      메모리를 뛰어다니며 같은 컴포넌트의 데이터를 수집해 복사하는 비용보다 캐시히트를 일으켜 빠르게 동작하는 편이 엔진의 코어에 쓰기에 괜찮을정도로 성능향상이 있었나요??

      삭제
    3. 일단 memcpy는 전혀 없었습니다. 실제 게임 object란 개념도 없었어요. .각 컴포넌트가 본인을 소유한 object가 누구인지를 저장하고 있었죠.. 단순한 int32 해쉬 넘버로... 캐쉬 히트/미스로 인한 성능문제보다는 cpu가 몇개가 되던 task system을 돌리기에 용이한점이 있어서 이렇게 한거니... 음 future-proof라고 할까요? 멀티쓰레딩에 장점이 있었던거죠 캐쉬 히트/미스 보다는..

      삭제