게임 개발자 해외 취업 얘기.

한국에서만 일하는 것 보다 전혀 다른 환경이 해외에서 일하는 것도 나쁘지 않은 거 같습니다.
또는 외국 개발사의 한국지사에서 일하는 것도 좋으 경험이 될 거 같습니다.

운 좋게도 요즘의 해외 회사들은 한국 개발자 구인에 적극적인 편입니다.
이유는.

1. 한국이 최고의 미들웨어 시장이 된 것에 기인하는 거 같습니다. 즉 많은 게임 미들웨어 회사들이 한국에서 서포트를 해야 되고 한국어를 하는 개발자를 뽑고 싶어합니다. 한국어 되는 개발자 해외에서는 찾기 어렵습니다. 국내에서 모시고 가야겠지요.

2. MMO 라는 새로운 환경에 이미 적응한 개발자들이 많습니다. 해외에서 관련된 경험자가 필요할때 한 번쯤 눈여거 보게 되는 것입니다.

허나 뽑고 싶어도 몇가지 문제가 있는데요.

1. 영어 말하기/쓰기가 잘 안됩니다. 많은 경우 읽기는 완벽한 편이고, 듣기는 그럭저럭 됩니다만, 외국인 상대할일이 많지 않던 우리는 잘 안됩니다.  지인 중 한 분은 전화영어로(저는 회화학원에서--) 이런 부분을 해결했다고 하네요. 덤으로 전화영어는 외국 회사 면접의 첫번째 코스이기도 합니다. 저는 처음에 전화 면접에서 몇 번 떨어졌습니다.

2. 보통 한국에서는 잘 없는 코딩 시험을 봐야 합니다. 보통 지인을 통해 움직이거나, 간단한 코딩 시험과 구술 시험이 주였던 한국 과는 다르게 하루에서 이틀 짜리 코딩 시험을 보는게 일바적입니다. (넥슨에서는 하는 거 같습니다.) 보실 때 귀찮아하시지 말고 있는 힘 다해서 보셔야 됩니다. 이게 실제 당락을 가르는 중요 요소이고 한국 개발자분들이 많이 떨어진다고 합니다.  진지하게 지원해 주시고, 진지하게 코딩 시험에 임해주시면 문제가 없을 거 같습니다.

간단한 팁이라면,
사람에 따라 말이 다르긴 합니다만,
북미권은 제가 볼땐 영어가 많이 필요한 거 같습니다.
현지인하고 경쟁해야 되는데다가, 북미에선 프로그래머는 대우가 좋은 직업인데다가, 다들 영어도 잘하니까요--+(그래봐야 안 가봐서 잘은 모릅니다.;;;)

그럽 이제 제가 밟고 있는 유럽(독일)은 조급 다릅니다.
여기도 나름 각국의 언어가 있어서, 영어가 보통 제2 외국어 입니다만,
게임 회사의 경우 나라 상관없이 뽑는 경우가 많고, 유럽내 국가끼리는 취업이 자유로운 편이니, 회사에서는 영어를 쓰게 되는 경우가 많습니다.
즉 회사안에서 이미 영어를 잘하고 못하는 사람들이 있는 경우가 많습니다.
(그래도 보통 잘하더군요, 같은 언어권의 이점인가요;;)
암턴 이런 환경이기 때문에 영어에 관대한 경우가 많습니다. 게다가 보통 프로그래머가 많이 없어서 인력부족인 편입니다.
그래도 영어 쓰기는 좀 보는편이기 때문에 이력서나 커버레터는 (당연하지만) 에러가 없는 게 좋습니다. 원어민이 한번 봐주면 좋겠지요.

완전히 다른 환경에서 일한다는 게, 그리고 익숙하지 않은 언어로 말한다는게,
생각보다 스트레스가 있긴 합니다만,
즐거운 스트레스가 아닐까 싶습니다.

저 같은 경우에는 한국 회사에서 이래저래 좀 고생한편이었는데요, 해외로 오고 그런 것들이 많이 사라졌습니다.  자기 문화와 익숙한 회사를 찾아만 다닐 수는 없겠지만, 그래도 자신에게 좀 더 맞는 회사가 있는것도 아닌 가 싶습니다.

해야할일 목록 입니다.

1. 영어 공부 - 우선 순위가 높을 수 밖에 없습니다. 언제 바짝해서 평생 써먹어야 되는데 말이져. 아직도 틀린 문법에 어설픈 발음으로 연명하고 있습니다.
    => 아이패드 동화책보기 - 디즈니 책 읽어주기 어플들이 멋지더군요!!중간중간 게임도 그럭저럭 재미나다눈(한권당 3불정도라서 약간 지출이 생깁니다.)

   => 안병규 미드 보기 - 기존에 학원 다니면서 괜찮은 느낌이라 보고 있습니다. 많은 분들이 발음이 이상하다고, 하던데 --저는 그런 거에 별로 예민하진 않아서,어차피 미드 따라하기인데요 뭐.(제 발음을 보면 좀 에민해야 될 거 같기도 합니다만, 그러면 너무 팍팍하잖아요.ㅎ)

   => Grammer in Use - 문법도 가끔씩 살랑살랑 봐주면 좋은 거 같습니다.

   => 아이패드에서 영어책 보기.!!

   => 그리고 토플이나 IELTS 등도 준비하면 좋을 거같습니다.

2.프로그래밍 공부
    => 꾸준히 필요한 책을 읽어야겠습니다. 엔진 사용하면 게임 개발하는 중간 역할만 오래했더니, 실제 기본 개념이 좀 부족합니다. - 소프트웨어 렌더러 만들어 보기!(학교 다닐때 한번 했었는데 거의 실패작이라,,,그래도 그때 배운걸로 렌더링 개념 써먹고 있으니 교수님께 감사의 메일이라도 써야 될듯...--물론 써도 누군지 모르실거라서--으음)

    =>  아이패드 취미 플밍 - 현재 맥북과 아이패드 환경이니 취미로 플밍은 맥으로 아이패드용. (음 그래도 역시 개발은 비쥬얼 스튜디오인데---황홀한 디버깅 세상이라는 걸 다른 IDE 를 써보고 알게되었습니다.) MS 최고의 제품은 비쥬얼 스튜디오가 아닐까 싶습니다.-_-

   => 멀티 코어 개념이 급 필요해지고 있습니다. 렌더링은 일할때 필요하니 책좀 읽어야겠고요.

3. 건강
   => 운동해야 됩니다. 매일 땀 한방울이라도 흘려야겠습니다. 운동할때 안할때 체력과 집중력차이가 많이 나는군욤!!.

그리고 제일 중요한 건 즐기면서 살자 입니다. 즐거운 마음으로 프로그래밍을 대하고 생각하고 장인이 되려하는 마음가지. 이것만큼 중요한게 없을 거 같습니다. 돈 받으니 일한다는 마음으로 다닌 적도 있고, 대충 회사 다닌 적도 있습니다만, 제일 즐거운 건 돈이나 회사에 상관없이 열시히 즐겁게 내 길을 걸어가면 프로그래밍 하는 것입니다.

집에서도 심심하지 않게 어떻게 하면 프로그래밍을 잘할까 고민하구요.!!ㅎ 이런 저런 문제를 머리속으로도 풀어보고 해야 겠습니다.

물리 엔진

요즘 열심히 글쓰기를 해보려고 하는데, 역시 블로그 초보라서 글 쓰는게 많이 어렵네요.

요즘 락프리니 헤스켈이니 하면서 멀티 코어에 대비해야 되니 하면서 말이 많은데요.  막상 일하는데서 안 쓰니 생각보다 공부는 안하게 되는군요. 반성해야겠습니다.

 그러 면에서 물리 엔진을 어떻게 돌리느냐가 클라이언트에서 고민할 수 있는 멀티 코어 문제인 거 같습니다.

이상적인 구조는 물리 엔진은 따로 남는 시간에 계속 돌면서 원하는 한프레임 전 데이타를 저장해두는 것일 겁니다.
(뭐 락 안걸고 최신 데이타 가져올 수 있으면 더 이상적인 건가요--가능은 할 거 같은데 어떻게 되는지 모르니...음 공부공부)

일단 근데 한프레임 전 데이타를 굳이 저장해두느니 렌더링할때 CPU 가 놀테니 요때 바짝 돌리고 업데이트 타임에 쉬어주는 방법도 있습니다. 이상적인 구조는 아닙니다만, CPU 가 노는 타이밍을 안다면 사용하기도 편리하고--그냥 그럭저럭 괜찮은 거 같습니다.

더 좋은 구조 있나요? 기타 엔진에서 어떻게 사용하는 지 아시는 분은 답글 좀 달아주세요~~

엔진 사용.

게임 엔진 사용 하면서 많이 듣는 얘기 중에 하나가,
아 엔진 잘못 골라서 게임 안나왔어.+_+ 이런 종류의 얘기입니다.

생각했던 거하고 다르다면 뭐 도망가고 싶을 때도 있겠습니다만, 안타까운 얘기입니다.
(물론 이런 저런 정치적인 이유로? 엔진 핑계를 대는 경우도 많지요;;;ㅎ)

사실 게임 엔진에는 크게 2가지 스타일이 있는 거 같습니다.
자체개발 게임이 있는 경우와 아닌 경우 입니다.

1. 자체 게임이 없는 경우.
    이 경우는 사실 아무리 잘 되있고 다 있는 것 처럼 보여도, 실제 게임을 개발하려면 많은 부분을 작업 해야 됩니다. 특히나 디자이너나 기획자하고 데이타를 주고 받는 부분이 약할 수 밖에 없는 거 같습니다. 보통 프로토타이핑 까지는 어찌어찌 되나, 이후에는 엄청난 툴 작업과, 중간 중간 어이 없는 병복을 맞딱 드리게 됩니다.(물론 자체개발 보다는 보통 낫지 않을까 싶습니다.) 물론 차근 차근 서포트를 받아가면 수정하면 됩니다만 어쨌든 생각보다 게임 후반으로 갈수록 개발 시간이 예상보다 길어지는 경우가 많은 거 같습니다.

2. 자체 게임이 있는 경우
    이 경우는 코드가 이해하기 어려울 가능성이 매우 높은 듯 합니다. 마지막 최적화라던가, 툴을 위해 이상한 인터페이스를 꼬아 넣었다던가 하는 말입니다.  이 경우는 프로타이핑을 아무것도 안고치고 쉽게 내놓거나, 조금 고치려고 하다가 시간이 많이 걸리는 경우가,,,ㅎㅎ
그래도 많은 게임을 위한 툴이 있고, 최적화 부분등도 실제로 게임을 만들면서 진행된 부분이기 때문에 동일한 스타일의 게임이라면 편안하게 개발 가능합니다.

저는 개인적으로 1번의 경우를 선호합니다. 이미 다 있는 거 헐어내는 것 보단, 조금 부족해도 열심히 분석해가면서 넣는 재미도 있고, 실제 프로그래밍도 좀 더 적극적으로 하게 되는듯 합니다.

심심 풀이 게임 엔진 이야기...(주관적인 생각입니다)

1. 유니티3 => 아직 제대로 안써봤지만
     => 툴이 멋지다.
     => 상당히 게임 디자이너(기획자) 친화적인 툴
     => 많이 수정하지 않다고 다자이너 중심으로 게임을 만든다면 최고 일듯
     => 플래쉬의 3D 버전. 음?!!
 
2. 게임브리오 => 3.1 까지만 써본,,(3.2부터 툴이 좋아졌다고 합니다...이제 월드툴에서 터레인도 수정 가능??-_-)
     => 툴은? 괜찮아지고 있다. 그래도 완전 프로그래머 친화적인 엔진인듯.><
     => 디퍼드를 지원안한다. 엔진을 샀는데 거대 렌더링구조를 집어넣는 건 좀 삽질이지 않은가? 포워드로 저사양을 노릴 계획이라면 제대로인듯!!
     => 한국에 있는 프로그래머라면 게임브리오는 한번씩은 해본듯 => 인력 충원 후 바로 일에 투입하기 좋다.
     => 뛰어난 게임브리오 프로그래머가 있다면 좋은듯,,,
     => 그러나 서포트는 없다.!!
     => 툴이 부족하므로 뛰어난? 또는 많은 툴 프로그래머가 필요하다. 또는 3rd 파티 인테그레이션을 제대로 활용 해야 되는(근데 스피드트리5는,,아직도 지원 안한다눈,,,)

3. 비전 엔진
    => 아티스트 친화적?인 툴은 아니지만 그럭저럭 비쥬얼 쉐이더 에디터와 파티클 툴도 있다.
        (겜브리오 라이트스피드 정도의 툴 + 비쥬얼 쉐이더 에디터 + 파티클 툴 인듯)
    => 게임브리오처럼 뛰어난? 또는 많은 툴 프로그래머가 필요한 것은 아니지만 그래도 툴 수정이 지속적으로 필요하다!!
    => 게임브리오처럼 프로그래머 친화적인 엔진인듯(게임 안 만드는 회사들은 프로그래머밖에 없어서,,,음)
    => 디퍼드 렌더링을 기본으로 지원한다.=> 디퍼드를 기본으로 한다면 당연히!!
    => 해본 프로그래머가 없다 -> 교육해야 한다,,, -> 이해하기는 좋은 소스이다.!!><
    => 서포트가 매우 좋다.? -> 아티스트들이 직접 데이타를 주고 받으며 한글로 서포트를 받는 것이 가능하다 => 프로그래머가 직접 교육하고 서포트에 질문 보내지 않아도 되니,,,편하다.=> 알파 같은 머리 아픈 문제를 개발사에서 해결하도록,,,,유도 가능+_+

4. 언리얼 엔진 (조금만 써 봤습니다.)
    => 개인적으로 테크니컬 디자이너 친화적인 엔진이라고 생각
    => 뛰어난 테크니컬 디렉터가 필요(디자인 감각있는 플머 또는 플밍 잘하는 디자이너--)
    => 엔진을 커스토 마이즈하고 고쳐야 하는 프로젝트라면 뛰어난 프로그래머가 많이? 필요하다.
    => 코드가 좋다고는 하나, 기본적으로 내용이 방대하므로 수정은 쉽지 않음.
    => 기본적으로 구색? 을 맞추려면 팀 규모가 커지는 듯/

5. 크라이 엔진 (듣기만 했습니다...)
    => 디자이너 친화적인 툴(멋지고 이뻐요.) = 프로그래머 비친화적인 엔진?
    => 이해하고 파악하는 데 상당한 시간 소요(물리 엔진만 봐도 PhysX 를 이용하지 않아서 기존에 PhysX 다뤄본 사람이 있어도;;; 음)
    => 엔진을 수정하지 않고 사용하면 좋다는 소문도( 영화 프리프로 덕션이나,,군사 시뮬 같은거?)
    => 신기술을 제일 빨리 넣는 듯.

  

    

PeekMessage HWND...

PeekMessage 에 기본 윈도우 핸들을 넘길때와 NULL 을 넘길때의 작동이 완전히 다르군요.
전 NULL 이면 내부적으로 윈도우 핸들을 찾아서 넣어주지 않을까 싶었습니다만,
MSDN 을 살펴보니--  NULL 일 경우에는 스레드가 어쩌고 저쩌고 합니다.

IME 메시지가 안와서 반나적을 헤매었는데, 저런 함정이 있었군요.
그러고보면 항상 NULL 을 자연스럽게 넣어주어서 생각지 못했네요.

요즘은 클래스 인터페이스 구성에 대해 많은 걸 배우고 있습니다.
범용 적인 인터페이스에,
실수할 가능성을 줄여주는(함수인자라든가.
그 어느 책에서 본 실수하기 힘들게 만들어주는 인터페이스 구성 하는 것을 배우고 있습니다.

그리고 이제서야 조금씩 디퍼드렌더링에 대해서 배우고 공부하고 있습니다.
서포트 해야 되니까요. 알파나 앤티앨리어싱 문제가 왜 생기는 지 이제서야 조금씩 이해하고 있습니다.(뭐 핑계를 대자면 온라인게임에선 별로 안 썼는데,,,---공부해야지..훔냐랑)

아무튼 그리하여 점점 의도하진 않았지만 제너럴 프로그래머가 되어가고 있습니다.
정말 하고 싶은 게 생기면 제대로 파서 전문분야는 하나쯤 있어야 되려나요.ㅎ

그래도 제게 제일 재미난 분야는
게임엔진과 게임 로직 사이의 징검다리 같은 역할 입니다.
인터페이스를 구성하고 게임에서 실제 사용할 수 있도록 해주는 이런쪽이요.
그런 의미에서 서포트 엔지니어를 택했습니다. 그리고 재미있네요^^

다시 블로그 시작

오랜 시간 동안 블로그를 방치해두었었는데,
우중충한 글들도 좀 치워버리고 새롭게 작성해보려고 합니다.

요즘 게임엔진회사에서 열심히 이것저것 엔진 서포트 작업을 하고 있습니다.

주로 하는 일은
문제가 생기면 개발사와 같이 고민하고 디버깅 하는 것과,
많은 회사에서 요청이 들어온 기능을 개발하는 일입니다.

지금까지는 한국에서 온 제가 잘 할수 있는,
IME 나 폰트 관련 작업이 가능하도록 엔진 내부 쪽을 수정하는 일이었네요.

그리고  PS3, XBOX360, WII 와 관련된 콘솔 디버깅 기법을 배웠습니다.
기계치인 저에게 이런 것들은 좀 어지럽더군요.

해외에서 일하면 좋은 것은,
말단이 제가 의견을 낼 수 있다는 것입니다.
물론 아직 파악하지 못한 것이 많아서 의견이 많진 않습니다만,
한국쪽에 관련 된 것이라든가 하는 것에 대해서는 이것저것 얘기도 하고
같이 고민도 하고 있습니다.

좋은 것은 의견이 나오면 왠만하면 귀 기울여 듣고 같이 의논해봅니다.

뭐 힘든 점은 아직까지 당연히 영어 문제입니다.
특정 단어를 못 알아들어서 아는 것인데도 모르는,
가끔 아주 기초적인걸 모른다고 잘못 말해서 무시를 당하기도 합니다. 흑흑;
뭐 영어 공부 열심히 하는 수밖에요.ㅎㅎ

가끔 갈굼도 당하고, 실수도 하곤 합니다만,
저한테는 한국에서 일할 때보다 훨씬 마음편하고 열심히 하게 되는 거 같습니다.

엔진들 엔진들,,,

요즘 유니티 3D 가 멋지게 떠오르면서,,,

GDC2010 내용들을 보니 주 화제인듯 합니다.

이걸 보면서 게임 엔진 시장은 완전히 재편된 거 같은데요.

고가 엔진 시장(퀄리티를 중심으로 무수한 사람과 인력을 쏟는,,,) : 언리얼/크라이 가,,,

=>이쪽은 TD 의 역할이 매우 크므로,,,프로그래밍 디자인 모두 센스 있는 인재가 많이 필요해보입니다.

중가? MMO 처럼 소스 코드를 많이 고쳐야 하는 쪽은 : 게임브리오/비젼,,,,

=>이쪽은 아직 엔진 프로그래머들이 열심히 렌더러도 고치고,

=> 새로운 미들웨어를 붙여보기도 하는,,재미난 곳,!!ㅎ

그리고

저가/무료 : 유니티3D, Shiva3D(이건 그냥 잘 모르겠음-_-)

원래는 자체 엔진은 개발하던 미니 게임(서양에서는 캐쥬얼 게임이라고 부르는 플레이타임 5분 정도의 게임들,,,)이나 스마트폰 게임들은,,,,거의 여기로 가는게 아닐까 싶네요.

=>이쪽은 프로그래머가 급격히 필요없어지는 느낌입니다.

=>프로그래머 대신 스크립터가 필요한듯,,,(뭐 액션스크립트를 프로그래머가 하듯이 이것도 프로그래머가 하겠지만!!0

저는 개인적으로 게임브리오나 비젼처럼 엔진도 이것저것 건드리고,

미들웨어도 붙여보고 이런쪽이 재밌긴 한데요.

(이쪽이 MMO 에 제일 맞는 거 같기도 하고요,,,개인적인 생각입니다만,,,)

유니티3D 쪽도 돌아가는 건 파악해야 되겠다는 생각이 드네요.

(주변에서 이걸로 뭘해보자고 많이들 하시는데-_-아아 저도 뭔가 해보고 싶긴 한데. 게을러서,,,)

게임 산업의 미래.

요즘 여러 사람들과 얘기하면서,

게임 산업은 어떨지 그리고 프로그래머의 미래는 어떨지 궁금해 지곤 합니다.

1. 스마트 폰, SNS 등으로 인한 캐쥬얼 게임의 폭발!!!

여기에는 Unity3D 나 Shiva3D 같은 안정적이고 빠르게 만들 수 있는 게임플랫폼 덕분도 있는듯!~

페이스북 게임도 많이들 하져~~

2. 거대 자본이 들어가야 하는 AAA 온라인게임?

거대 자본과 체계화된 시스템이 필요한 거대 온라인 게임은 블리자드사가 거의,,,

주변 개발사도 보면 뛰어나고 우수한 인재들은 많은데, 뭔가 체계화되고 관리된 시스템이 없어서,

무너지는 것처럼 보이는 경우가 많습니다. (적절한 PM 의 부재랄까요,,,-_-)

3. 프로그래머?엔진?

소규모 인디팀에서 자체 엔진으로 개발하는 경우가 많이 사라진듯 합니다.

자체 엔진의 경우 안정성이나 문서화 등이 쉽지 않아서, 개발자 한명 한명이 소중했는데 말이져~~

아무튼 그래서

대규모 - 언리얼,크라이

중간규모 - 게임브리오, 비젼,,,등

소규모 - 유니티

저렇게 규모별로 맞는 엔진이 존재하는 듯 합니다. (물론 게임 타입에 따라 다르겠지만요)

소규모 팀에서 사실 선택할 수 있는 옵션이 많다는 건 좋은 거 같기도 합니다.

예전처럼 오픈소스 엔진위의 자체 엔진 이런 형태는 많이 사라지지 않을까 생각합니다.

결국 이렇게 되면 엔진하시던 분들은 전문화 되어 미들웨어사나 엔진사를 차리거나 그런 회사로 들어가게 될 거 같네요.

(아니면 중간규모 급에서는 엔진 수정이 많으니 그쪽 엔진에 필요 기능 추가도 있을 수 있겠네요)

아무튼 게임 시장은 커질거라고 생각합니다.

(다들 스마트폰-게임기를 한대씩 들고 다닐테니까요,,,)

하지만 늘어나는 만큼 순수 프로그래머들이 많이 필요하진 않을 거 같네요,

예전 게임처럼 대규모로 프로그래머들이 우르르 일하는 경우도 적어지지 않을까 싶고요.

그리고 점점 엔지니어보다는 어느 정도 아트 감각을 가지고,

TD 로 활동하는 분들이 많아지지 않을까 싶습니다.

UDK(언리얼) 나 유니티를 써보면 어느 정도 툴 사용 감각있는 개발자가 확실히 유리하는 생각이 들거든요.

아무튼 결론은 ,,, 이것저것 할께 많아지네요. 늘 그래왔듯이...

요새 디자이너 분들도 스크립트 공부 많이 하시던데,

우리도 툴 공부 열심히 해야 될 듯 합니다.!!

컴포넌트 시스템 정리 - 1

안녕하세요. 게임 프로그래밍은 기획자와 디자이너를 위한 서비스라고 생각하는 harry입니다. 요즘 온라인 게임이 유행하고 또 대형화 되면서 게임 개발 이후에 유지 보수 및 패치의 중요성이 대두 되고 있습니다. 그럼 쉽고 가볍게 패치를 하기 위해서는 게임 코딩에 어떤 걸 고려해야 할까요.

우선 컨텐츠로 인한 코드가 증가하여도 전체 클라이언트 어플리케이션 내의 복잡도가 증가하지 않아야 합니다. 그러나 이는 전통적인 오브젝트 - 오리엔트 프로그래밍에서는 쉽지 않습니다. 새 객체 추가 요청을 받았는데 기존과 어느 정도 비슷합니다. 그럼 기존 코드를 상속받아 새로운 코드를 작성합니다. 그러나 완전히 똑같질 않고 제거해야 되는 부분도 있습니다. 상속이므로 이미 사용되고 있는 기존 코드의 내용을 제거하기는 어렵습니다. 오버라이딩을 하게 됩니다.

그럼 컴포넌트 방식은 어떻게 될까요?

새롭게 추가 되는 내용을 머리 구상합니다. 이를 하나의 기능단위로 클래스로 만듭니다. 이 클래스는 상속으로 부터라기보다는 기본 컴포넌트 인터페이스로 부터 받습니다. 그리고 이 기능은 객체에 추가 됩니다.

쉽게 보면.

Human 라는 클래스가 있고,

여기에 CTransform(Translation,Rotation,Scale) 등의 정보를 갖는 클래스가 있습니다.

Human

  CTransform m_transform

  CAnimation m_animation

이러한 형태가 됩니다.

그러나 그냥 이렇게 코드를 짜게 되면

클래스가 늘어나게 되면 Entity 클래스가 복잡해지게 되고,

서로 다른 작동을 하는 사람 Entity와 나무 Entity는 각각 따로 클래스를 만들어야 됩니다.

그럼 어떻게 하면 될까요? 어떻게 하면 공통된 인터페이스로 처리할 수 있을까요?

Entity

  List<ComponentInterface*> m_componentList

ComponentInterface는 상속 받아서 CTransform,CAnimation 등의 컴포넌트를 가질 수 있습니다.

그럼 이렇게 했을 때는 기존의 경우와 비교해서 어떤 문제가 생길까요?

CAnimation은 캐릭터를 애니메이션 하기 위해서 Transform 정보가 필요합니다.

즉 CHuman::Update()

에서는 m_animation.Update(m_transform)

과 같이 m_animation 에 transform을 알려줄 필요가 생깁니다.

그럼 Entity 의 List 구조는 위와 같은 형태를 어떻게 해결할까요?

Entity 클래스는 리스트만 담고 있을 분 어떤 것들을 가지고 있는지 스스로 알 수 없습니다.

이런 경우에는

ComponentInterface 클래스에 다른 컴포넌트의 변수를 가지고 올 수 있는 인터페이스가 필요합니다.

보통 컴포넌트 간에 주고 받아야 하거나, 세이브/로드가 필요한 데이타의 경우 Property라고 부릅니다.

이 Property들을 주고 받으려면 인터페이스가 필요하게 됩니다.

즉 ReadProperty(Translate,&Vector3),ReadProperty(Rotation,&Vector3),ReadProperty(Scale,&Vector3)

과 같은 형태로 Transform을 읽어올 수 있도록 인터페이스를 만들 수 있습니다.

Entity

 ReadProperty(String,&Vector3)

    이 함수는 내부적으로 모든 프로퍼티를 돌면서 String에 해당하는 Property의 밸류를 찾아서 리턴 해줍니다.

물론 다른 컴포넌트의 값을 찾기 위해 String을 쓴다면, 프레임 저하가 생길것으로 예상됩니다.

스트링 비교는 매 프레임마다 하기에는 부하가 큰 연산입니다.

이럴 경우 스트링을 관리하는 클래스를 만들고,

String을 전체 테이블로 관리하게 하고 같은 이름의 스트링은 레퍼런스로 처리하면 됩니다.

같은 스트링의 경우는 같은  메모리 주소를 갖게 되므로 단순 비교로 처리할 수 있습니다.

C#의 StringBuilder등을 참조하세요.

그럼 Component Interface 를 어떻게 해야 할지 알아볼까요.

위에서 보았던 CTransform을 컴포넌트로 구성해 봅시다.

우선 ReadProperty 라는 함수가 필요합니다.

ReadProperty(string name,Point3& pt3)

 if(name == RotationString)

   pt3 = m_rotation;

 else if(name == ScaleString)

   pt3 = m_scale;

위와 같이 변수를 이름과 매핑 시켜서 가져옵니다. 상황에 따라서는 Map을 사용해서 빠르게 접근할 수 있도록 만들수 있습니다.

그럼 SetProperty 도 위와 같이 구성할 수 있습니다.

if...

else....

다른 컴포넌트에서 Entity의 ReadProperty를 호출하게 되면 모든 컴포넌트를 돌면서 해당하는

Property를 가지고 오게 됩니다.

그럼 다시 돌아가서 공통의 인터페이스를 가지는 컴포넌트를 만들어서

속성을 관리할 경우 어떤 이점이 있을까요?

우선 속성의 추가/삭제가 쉬워집니다.

게임을 개발하다 보면 기획에서 캐릭터가 새처럼 날게 해줘라고 어느날 갑자기 말합니다.

그래서 날기 기능을 열심히 기존 코드의 Update함수를 수정하여 넣습니다.

그리고 어느 날 아 나는 건 우리 게임에 어울리지 않고 유저들이 사용하지 않으니 빼달라고 합니다.

이미 기능을 추가한지 한참이 지났고 롤백으로 기능을 제거 할 수 없습니다. 이 경우 하나하나 찾아서 빼거나 최악의 경우

게으름을 이유로 호출하는 부분말 살짝 지웁니다.

Legacy 코드가 증가하게 되고, 결국 코드는 점점 방대해집니다.

그리고 컴포넌트로 했을 경우에는 어떨까요?

새처럼 날 수 있게 하는 FlyComponent가 추가 됩니다.

Entity의 ComponentList 에 추가 되겠지요.

그리고 어느 날 빼달라고 하면 그저 리스트에서 제거 됩니다.

그리고 두번째 장점은 직렬화-Serialization이 쉽게 가능해집니다.

스트링으로 매피되는 프로퍼티들을 처음에 추가 해주고,

GetProperty로 모두 얻어와 하나하나 저장할 수 있겠지요.

물론 이게 가능하려면 타입에 대한 어느 정도 구조화가 필요합니다.

즉 게임에서라면 자주 쓰이는 데이타인

INT,FLOAT,POINT3,MATRIX 등등의 기본 데이터가 있을테고,

이런 기본적인 데이타에 대해서는 어떻게 저장할지 미리 규칙을 정해둡니다.

그리고 이후 프로퍼티들은 위 규칙에 따라 매핑되는 이름으로 저장하게 됩니다.