2010년 12월 25일 토요일

서포트 엔지니어란?

벌써 게임 엔진 서포트 엔지니어로 근무한지도 6개월이 넘었습니다.
생각했던 부분과 다른 면이 많아서(대부분 긍정적인 부분이긴 합니다만,) 서포트 엔지니어에 대해서 살짝 남겨보려고 합니다.

1. 장점.
  a) 많은 써드 파티사들과 메일을 주고 받으면서 재미난 문제나 버그에 대해서 얘기해 볼 수 있습니다. => 견문이 넓어집니다.
  b) 깊이 생각하기 => 보통 문제를 보내는 당사자는 많은 고민과 생각을 해보고 문제를 보냅니다. 그러나 메일이기 때문에 많은 내용을 유추해야만 합니다. 사고 훈련? 에 도움이 됩니다.
  c) 문제를 해결하고 고맙다는 한마디에 남을 돕는 재미난 직업이라고 생각하게 됩니다.
  d) 매일 문제들과 씨름하면서 집중력이 좋아집니다.
  e) 다양항 문제를 내외부 다양한 개발자들과 얘기하면서 여러가지 상황에 유연하게 대처하는 방법을 배우게 됩니다.
  e) 영어 메일 실력이 늡니다. 더불어 글로 의사소통하는 능력이 급속도로 향상됩니다. (이건 해외 회사라서 그런 부분도 있지만 서포트 엔지니어의 경우에는 서드 파티와 대화할일도 많기 때문에 어떤 경우에도 영어 쓸일이 많은 거 같습니다.)

2. 단점
   a) 오랜 시간 고민하는 task 가 존재하지 않습니다.
       대부분의 경우 하루 이내에 풀 수 있는 문제로 고정되게 됩니다. 보통 그 이상의 시간이 걸릴 경우는 feature list 형태로 들어가게 됩니다.
   b) 가끔 출시 압박에 놓여있는 고객사의 짜증과 항의가 들어오는 경우도 있습니다. MMO 경우는 별로 없습니다만 많은 콘솔의 경우 마지막에 많이 예민해집니다. 그리고 보통 그 단계에서 문제가 생기면 해결하기 어려운 문제라 시간도 오래 걸리기 마련입니다.^^

그럼 1부는 여기서 마치고-ㅁ- 다음에 시간이 나면 더 적어보도록 하겠습니다.

2010년 12월 23일 목요일

스테이트 기반 언어.

요즘 가끔 짜다가 잊는 것 중 하나가,
C++(대부분의 다른 랭규지도 마찬가지겠지만 일단 이거만 주로 했으니) 는 state 기반 언어라는 것입니다.

누구나 알고 있는 사실입니다만, 코딩을 할때는 잊기가 쉽습니다.;

함수 실행전과 실행후의 스테이트를 맞춰 주는 것이 꽤 중요하다는거지요!
특히나 중간에 에러가 나서 리턴을 할때는 앞에서 생성한 것들을 꼭 살랑살랑 지워주고 리턴.
Try/Catch 를 잘 써서 관리하면 좋겠지만,,,ㅎ

2010년 12월 19일 일요일

개발에서 사소한지만 중요한 것들

요즘 사소하지만 그냥 넘어가서 후회 했던 일들을 반성하면 몇가지 적어봅니다.
다음 번에 또 똑같은 문제를 겪지 않기 위해서 말입니다.

1. 빌드/테스트/커밋/CI 과정은 최대한 편하고 간단하게.

빌드는 언제든지 한번에 모든 걸 빌드/리빌드 가능한 스크립트가 있어야 합니다.
뭔가 이상하면 탁 리빌드 누르고, 차한잔또는 책한챕터 읽는게 최고이지요!!.

테스트는 처음부터 고려된 것이 마음 편하지만, 또 그게 쉽지는 않은 경우가 많아서 regression test 라도 반드시 있으면 좋은 거 같습니다.(한번버그 생기면 관련 테스트코드를 만들어서 고치고 남겨서 다음에는 자동으로 테스트 하도록)

커밋은 obj,ncb 파일이니 이상한 것들 안 딸려올라가도록 자동으로 세팅해두고, 혹시라도 올라가면 사용자에게 반드시 이메일을 주는 것이 좋은 듯 합니다. 지워주센..=_=

CI 는 대략 커밋하고 5분내에 리포트를 받을 수 있는 것이 좋은 거 같습니다. 이거 기다리는 게 오래 걸리면 이래저래 귀찮아지지요. 그리고 CI가 실패일때는 다른 사람이 커밋/업데이트하지 못하도록 간단하게라도 해두면 좋은 거 같습니다. 빌드 안되는 거 업데이트 받는 거처럼 개발 의욕을 꺾는 건 없지요;;ㅎㅎ

2. 개발자의 자유시간 확보.
하다보면 조금만 이렇게 하면 효율성이 확 좋아질 거 같은데 도저히 건드릴 수가 없는 부분이 있습니다. 상사가 개발한 부분이거나, 시간이 좀 걸린다거나 하는 부분 말이져.  개인의 이런 아이디어는 상당히 소중하다고 생각합니다. 결국 1%라도 효율이 좋아지도록 생각하면서 회사도 개인도 발전하는 거니까요. 그런 면에서 구글처럼 까지는 못하더라도, 일주일중 어느 정도 시간은 하고 싶은 쪽 하센!! 이런 게 좋은듯 합니다.

3. Think Hard!!
대충 생각하고 대충 짜보고 대충 컴파일 해보고 다시 수정하고, 되면 넘어가고, 이런 것처럼 위험한 코딩은 없다고 생각합니다. 당장은 별 무리 없겠지만, 일단 프로그래머 본인 자체에게 치명타입니다. 생각을 한만큼 코딩이 느는거니까요. 저도 한때는 코딩하기 싫어서 대충 저렇게 한적이 있었는데 버그나 구조적 불합리합은 둘째치고 실력이 오히려 줄고 있는듯한 느낌이 들 정도였습니다.(뭐 따로 공부를 안한면도 크겠지만요)
따라서 아무리 사소한 걸 짜더라도 깊이 생각하고, 좀 더 좋은 방법은 없는 지 고민하고, 좀 더 재미난 방법이 없는지도 고민하면서 프로그래밍의 깊이와 즐거움도 느끼고, 본인의 실력도 향상시키고, 더불어 남이 보기도 좋은 코드를 짜면 1석3조라고 생각합니다.!!!

4. 새로운 툴/언어 등의 적용
처음 플밍 시작할때는 누구나 새로운 툴,언어 또는 재미난 오픈소스를 좋아합니다만, 시간이 지날 수록 귀찮아집니다. 역설적으로 이는 현재 사용중인 언어와 툴을 너무 잘해서-ㅅ-편해져서 그렇지 않을까 싶습니다.(아직도 VS 6.0 쓰는데는 해킹쪽 빼곤 없겠지요? 전 2007년까지 봤습니다.;; ) 그러나 새로운 걸 배우기 귀찮아하는 순간 우리는 퇴보하는게 아닐 까 싶습니다. 끊임없이 코딩이 재밌고, 우리 코딩 열정의 아궁이에 남은 씨를 꺼트리지 않으려면, 새로운 걸 계속 배우는 게 중요하지 않을 까 싶습니다. 여기서도 보면 Quick Learner 를 상당히 중요시하는 거 같습니다.

2010년 12월 16일 목요일

최근에 읽은 책 2권

<이외수 - 황금비늘>

단숨에 읽게 만드는 매력적인 작품인듯 합니다.
약간의 판타지와 현실 비판도 재밌게 읽어졌습니다.
근데 좀 뭔가 밝고 희망찬 느낌의 책을 읽고 싶었는데 조금 아쉽습니다.
제목은 뭔가 엄청난 희망과 사랑이 가득할 거 같았거든요.ㅎㅎ
(그럴려면 무협/판타지를 읽어야 되는걸까요. 붕붕 슝슝 이제 내가 왕임. ㅋㅋ 이런거 -ㅁ-)

<화성에서 온 남자 금성에서 온 여자>

당연히 읽었는 지 알고 있었는데, 내용은 처음보는 거네요. 하도 인용이 많이 되서 읽었는지 알고 있었습니다.-ㅅ- 고전이든 명서든 꼭 직접 읽어봐야 된다는 걸 알게 해주는 책입니다.
작가의 통찰력이 대단한 거 같습니다. 뭐랄까요, 많이들 알고 있지만 실제로 책으로 써내긴 어려울 거 같은 것을 이렇게 재밌고 쉽게!!!! 이래서 어딜가나 이 책의 인용이 있는 건가봅니다.
암턴 열심히 보면서 저의 무지를 깨우쳐 가는 재미가 있습니다.

요즘은 해외의 시골에서 살다보니 뭔가 따로 할일이 많지 않습니다.
덕분에 사색과 책에 조금씩 빠져가고 있는 거 같습니다.

IME

잊을만 하면 IME 문제가 한번씩 나타나는데요.

이유인즉슨 IME는 WindowProcedure 에 예민해서 메시지를 못 받게 되는 경우가 이런 저런 이유로 생겨서 입니다.

따라서 SPY++ 를 적극 활용하면 대부분 쉽게 해결이 가능하기도 합니다.

스케일폼이 다 해준다고 해서 편하게 생각하고 있었는데, 결국 바인때마다 또 이런 문제가 생기는 거보면 공짜는 없는 거 같습니다.(게다가 매버전마다 곁들여지는 스케일폼의 사소한 버그는-ㅁ-).
뭐 훌륭한 미들웨어 입니다만, 한국인 플머 한명 뽑으면 안 생길만한 버그들이 늘 생기네요.ㅎㅎㅎ

2010년 12월 10일 금요일

좋은 회사란?

좋은 회사를 찾기에 앞서 좋은 직원이 되어야 겠습니다만^^.
간단힌 좋은 회사를 생각해 보면,

1.우선 직원의 아이디어를 적극 수용할 수 있는 회사,
즉 직원이 자유롭에 아이디어를 제출하고 현실화되는 것이 제일 중요한 거 아닐까 싶습니다.
(어딘가에서 읽었던 호텔 청소 직원에게 호텔 청소 비품을 사는 아이디어를 제출하게 하는?)
즉 실제 현장에서 일하는 사람이 아이디어를 만들고 그 아이디어를 위로 전달할 수 있고, 그것이 실제로 반영 되는 구조가 좋지 않을까 싶습니다. 위의 청소 예도 저걸로 직원들의 효율성이 엄청나게 증가했다는 걸 읽었습니다.


2. 일정시간 자유롭게 회사를 위해 일할 수 있는 회사.
그 유명한 구글의 업무시간의 20%는 자유를 들 수 있겠습니다.물론 아이디어를 제출하고 어느 정도 확인이 필요한 부분이기도 합니다만,
많은 경우에 실제로 어느 정도 시간을 투자해서 한 번 해두면 작업 효율이 대폭 증가할 만한 일들이 꽤 있습니다. 자유롭게 일하라고 하면 대부분 하고 싶은 걸 할텐데요 사실 회사 업무와 관련된 일중에 하고 싶은 걸 찾으라 하면, 결국 저렇게 효율성이 대폭 증가되는 부분이지 않을까 싶습니다.(제 생각에는,,,ㅎ)


3. 같이 발전해가는 걸 인지하는 것?
직원과 회사는 같이 발전해 가는 것이라고 생각합니다 어느 한쪽만 쭈욱 발전할 수도 없는 듯 하고요. 일례로 회사만 발전하면 직원은 떠나게 되고, 직원만 발전해도 또 쉬이 떠나게 됩니다.^^ 같이 발전하고 같이 움직이는 것, 근데 이건 뭐 생각처럼 쉽게 되지 않는 거 같습니다. 후우;;

뭐 이러쿵 저러쿵 해도 최고의 회사는 결국 우리 말단? 직원이 같이 만들어가는거겠지요~~라고 생각하고 있습니다.^^

2010년 12월 9일 목요일

게임 엔진 내의 글로벌 VS 지역화

스타크래프트 2 렌더링 문서를 보다보면 글로벌한 라이트는 그냥 포워드로 지역 라이트는 디퍼드로 처리했다는 이야기가 나옵니다. 지역적인 알파오브젝트를 포워드로 렌더링하는 건 이런 저런 디퍼드렌더링 문서에 제법 나오고요.
요즘 렌더링은 이렇게 글로벌한 부분과 지역적인 부분으로 많이 나눠지고 있는 거 같습니다.
쉐이더의 경우도 글로벌한 우버 쉐이더(큰 하나의 파일에 디파인으로 구분)와 지역적인 비쥬얼 쉐이더 에디터가 같이 쓰이는 경우가 있습니다.

덕분에 게임 하나에 이런 저런 렌더링 기법이 들어가고, 여러가지 쉐이더 형태도 들어가고 하는 거 같네요-ㅅ- 글로벌한 녀석은 빠른 녀석으로, 지역적인 녀석은 다양하게 대응할 수 있는 녀석으로,,ㅎㅎ

2010년 12월 7일 화요일

boost

여지껏 프로그래밍은 회사에서 집에선 책이라는 모토아래,
개인 프로젝트를 해본 적이 없습니다만,(쉬는 틈틈이 알바한적은 있습니다만,)
프로그래머의 길, 멘토에게 묻다 의 장난감 패턴을 본뒤로 집에서도 살살 프로젝트를 진행해야겠다는 생각을 하고 있습니다. 뭐 책만 보고 회사에서 프로젝트로 진행하지 않을 경우 다 잊어버리는 문제도 있구요(실제로 렌더링 집에서 공부한 것들은 대체적으로 현실감 잊게 와닿지 않고 있습니다.) - (기존 제 블로그개발 환경 구성 참고)

일단 소프트웨어적으로 실제로 해봐야 할 건,
1. 멀티쓰레드 개념 잡기 / 테스트 패턴 적용(테스트 주도까진 모르겠습니다만, 일단 테스트를 염두에 두는 코딩이 기본이 될 거 같습니다 - 테스트를 나중에 작성하는 건 고통스러우니까요-ㅅ-)

2. 기타 표준 라이브러리 제대로 사용.
    => 보통 게임 엔진은 stl / boost  와 거리감이 있는 듯 합니다.(콘솔 지원등의 이유가 있겠지요). 그래서 집에선 stl , boost(tr1,tr2? , 0x) 등의 C++ 표준 따라가기를 진행해야 할 거 같습니다. 이번에 저번에 메모리풀 등을 보면서 여러가지로 좀 더 봐야할 필요성도 느꼈구요.

일단 베이스 프로젝트를 만들어야 하니,
boost + google io stream + stl(or eastl) + debug(ignore 가능한 assert) + dump(에러리포트 포함) + log(level 단위) + google test + component(+object pool}
정도로 생각하고 있습니다. 쓰고나니까 많아 보입니다만 뭐 늘 많이 하던거니 금방되겠지요^^.

boost 에 flyweight 이 있던데 MMO를 예로 들더군요 관심있게 봐바야겠습니다. 이번 기회에 람다와 bind 도 좀 보구요~

2010년 12월 3일 금요일

메모리 !!

매일 매일 다른 걸 하고 있습니다.
오늘은 한번쯤은 만나게 되는 메모리.

어느 게임엔진이나 비슷합니다만,
메모리는 자체 얼로케이터를 사용하게 됩니다.
(물리 엔진이나 뭐 이것저것들 보면 대부분 자체 메모리 얼로케이터가 따로 있는 것을 볼 수 있습니다. 귀찮게시리요-ㅅ- 스케일폼도 따로 있었던듯; )

기본적인 인터페이스만 제공하는 new / delete 또는 malloc;;만으로는 불가능하니까 그렇겠지요?
참고 : http://jacking75.cafe24.com/Tip/AboutHeap.htm

오늘 생겼던 문제는 align 문제 였습니다. 물리나 시뮬레이션 같은 경우는 아무래도 SIMD(SSE?) 버전을 사용하기 마련이고,  16비트 align이 기본적으로 작동해야 하는 경우가 있더군요-ㅅ-(물론 그쪽 라이브러리 데이타를 사용할 경우이겠지요).

일단 제일 깔끔한 건
외부 라이브러리 데이타만 모아서 외부 라이브러리에서 제공하는 얼로케이터를 이용하는 할당 받고 사용하는 것이라고 생각합니다.
(이래서 클린 코드에서 무조건 인터페이스 만들라고 하는 듯 합니다;;; )

대략 코드상으로 생각해보면

3rdPartyPhysicsComponent
{
   MacroFor3rdPartyAllocator()
    property1 , property2
}

MyEngineComponent
{
  3rdPatyPhysicsComponent* data;
  my datas,,,
}

대략 이런 형태가 될 거 같습니다.

하지만 뭐 내쪽 컴포넌트에서 살짝 서드파티 컴포넌트를 붙여서 쓸 수도 있겠지요-_-;
암턴 이런 경우 때문에 메모리 얼로케이터는 엔진껄로 데이타는 서드파티 클래스 이런 경우가 생깁니다.

보통은 특별한 문제는 안 생깁니다만, SIMD 버전등을 사용해야 하는 경우라면, 16바이트 얼라인을 맞춰줘야 겠지요.

__declspec(align(16)) 하고 열심히 선언해주면 new/delete를 오버라이트 해주지 않았을 경우에는 문제가 없습니다.(내부적으로 어떻게 처리하는 지는 모르겠네요.)

오버라이드를 했을 경우에는 편안한 방법은 없는 거 같습니다.
일단 좀 찾아보니 얼라인이 필요한 클래스에서 new/delete를 따로 얼로케이트 하는 방법이 있네요

Class MyEntity : public BaseEntity, Allocater<16>
{
}

이런 형태로 하면 된다고 하는 군요.
뭐 전 매크로로 필요한 경우 디파인해서 쓰도록 했습니다.;;후우;;

요즘 시스템쪽 기초 공부하느라 정신이 없군요;
메모리 얼로케이션 1.5 기가 정도 넘어가면 불안해진다는 것도 알게 되었구요;
(이건 왜 그럴까요?--+)

2010년 12월 2일 목요일

클린코드 #3 - 서드파티 라이브러리 통합

클린 코드 책을 본 뒤로, 널 값으로 튕기는 버그들을 보면서 널을 다 없애버려야 되는데 하는 생각을 하고 있습니다. 널 리턴 없는 세상을 꿈꾸며,,

이제 막 서드파티를 어떻게 통합할지에 대한 장을 마쳤습니다.

상당히 재미난 서드파티 붙이기 아이디어였는데요.
일단 서드파티 공부는
문서 읽기->테스트 작성하며 살살 실제 공부->레이어 제작(내 입맛대로,,,)->내 어플은 레이어와 깔끔하게 통신.

이중에서 테스트 작성하면서 공부하라는 아이디어가 참 좋은 거 같습니다.
새로운 서드파티를 공부하는 것도 어렵고,
인테그레이션을 만드는 것도 어려운 일인데,
둘은 한꺼번에 하지 말라는 얘기지요^^.

저도 저렇게 한꺼번에 하다가 몇 번 고생한 기억이 있습니다. 그리고 새버전이 나올때마다 또 고생했지요;;;
저렇게 테스트를 작성해두면 새버전이 나와도 안심하고? 테스트 돌리고 버전에 맞춰서 테스트 성공시키면 깔끔하게 돌아갈 것이다...라는 느낌이네요^^.

일단 실제에 부딪히면 몇가지 더 문제가 있겠습니다만, 테스트 작성이 요새 유행하는 이유는 서드파티를 많이 써야 되는 환경에서 비롯되지 않을까 싶기도 합니다.

프로그래밍 패턴.

요즘 새삼 프로그래밍 패턴이 필수적으로 자리잡았다는 것을 느낄 수 있습니다.
최근에 사용했던 두 게임엔진도 공통적인 프로그래밍 패턴들을 살펴 볼 수 있어서 간단히 적어봅니다.

1. 컴포넌트/엔티티/이벤트 패턴을 이용하여 툴과 엔진이 교류하게됩니다.
    엔티티는 대략 컴포턴트들로 이루어져 있고, 컴포넌트 다시 프로퍼티와 함수(Behavior)로 이루어져있습니다.
    그리고 C# 툴에서 프로퍼티 그리드를 이용하여 작업하도록 되어있습니다.

2.  자체 RTTI 와 STL 그리고 스트링 시스템을 가지고 있습니다.
     이 부분은 콘솔에서 이점이 있지 않나 싶습니다.PC 에서만이라면 속도나 편리성 대신에 범용성이나 편리함을 제법 잃어버리는 거 같기도 합니다. 최근에 EA STL 이 공개되었으니 이부분도 좀 살펴보고 싶긴 하네요. 그래도 그냥 표준적으로 사용하는 STL 이 마음은 편한 거 같습니다. (이제 별로 쓸일이 없어서 잊어버리고 있습니다만, BOOST C++ 0x 니 하는 것들도 나오는데 말입니다--+)

3. 오브젝트들은 항상 자식 노드를 가지고 있을 수 있습니다. 꼬리에 꼬리를 무는 노드 구조입니다. 이걸 무슨패턴이라고 하던데요--기억이;;

2010년 11월 28일 일요일

프로그래밍과 수학.

http://digestingduck.blogspot.com/2010/02/simple-stupid-convex-hull.html

예전에 엄청나게 고민했던  convex hull 관련 내용이네요.
이게 결과는 간단한데 -- 뭔가 잘 정리가 안되는 내용들이 많았습니다..

게임쪽은 굳이 그래픽스 플머가 아니더라도 어느 정도 수학이 필요한 경우가 많은 거 같습니다.
물론 알면 좋다 식의 경우가 많지요 모르면 찾아보면 되지 뭐 이정도인 경우가 사실 대부분이긴 한 거 같기도 합니다만!!
수학공부 취미로라도 열심히 해야겠습니다. 근데 역시 수학공부는 학교스타일이 좋은 거 같습니다. 교수님께 수업듣고 시험 때 복습하고-ㅅ-.
뭐 정말 플밍을 좋아하는 분들은 학교에 수학 공부할때도 하나하나 플밍해보면서 한다는 소문이-ㅅ-

요즘 개발 환경 구성

요즘 집에서 개발 환경 구성을 어떻게 꾸밀 까 생각중입니다.
일단  당분간은 열심히 구상하고, 어느 정도 정착하게 되면 개인 프로젝트 환경을 꾸며볼까 합니다.
일단 오픈소스 프로젝트를 할 계획이고, 또 오픈소스들을 최대한 활용할 계획입니다.(코드 읽기 연습도 더하고요).

1. 컴퓨터,
    일단 본격적인 개발엔 아직 데스크톱인 거 같습니다. 이사를 많이 다니는 관계로-_- 노트북만 써왔는데 본격적인 개발은 힘든 거 같습니다(현재 집에서는 거의 개발서적만 일고 있습니다.)
   SSD 를 일단 2개 달고, 메모리는 최소 8기가, 나머지는 적당히.라고 생각하고 있습니다.?

2. 빌드 환경
    단연 비쥬얼 스튜디오(집이니까 익스프레스+플랫폼 SDK)일테고(다른 건 사실 써본적도 거의 없습니다. 학교 다닐때 빼고는요-)
    여기에 CruiseControl.net 과 Ant 나 요새 뭐 유행하는 다른  CI 등을(오픈소스 인것들로)로 가볍게 구성할 계획입니다.
   코드 짜기전에 문서화 환경도 어느 정도 구축해야 되니 Doxygen 세팅등도 확인해야겠지요.
   그리고 VCS로는 Mercurial(DVCS) 로 일단!!
   여기에 유닛테스트 구글 유닛 테스트나 CppUnit  이었나요? 이걸로.!
   그리고 스테이티스틱 코드체크는 CPPCheck 등이 있겠네요(http://jooyunghan.da.to/blog/?p=57)
   그리고 디버깅용으로는 Pix 와 Process Monitor, Depend 등이 있겠네요(뭐 당연합니다만 가끔 잊어버리는 경우가 있어서 적어둡니다.;;; 뭐 sysinternal  페이지에 가면 다 있겠지만요)

3. 외부 오픈 소스 라이브러리.(물론 오픈소스가 아니더라도 공짜면, 물론 오픈소스가 아닐 경우에는 사용자 그룹이 있는지가 정말 중요한 거 같습니다.)
     일단 해본 다면 툴쪽을 많이 해보고 싶으니 C# (+MonoProejct) 가 일단 제일 관심이 갑니다.
     그리고 Nocturnal  쪽이 이것저것 잘 들어가 있으니 그냥 쓰면 좋을 거 같습니다.
     따로 따로 구성한다면 gpg 에서 본 미니덤프와 애서트는 기본으로 넣고,
     메모리 얼로케이터는  loki 나 인터넷에서 유명한 걸 가져다 써야 할테고.
     PhysX(+Visual Debugger) 를 주로 써왔으니 이걸 쓸 거 같습니다.(오픈소스인 ODE 를 써보기 싶긴 합니다만, 써본적이 없으니)
    위의 Nocturnal  을 쓴다면 컴포넌트 구성은 따로 할 필요가 없을 거 같습니다만, 따로 하게 되면 gpg 에서 보고 시작해야겠지요. 이쪽은 RTTI 부터 Serialization  까지 있어서 왠만하면 다 되어있는 걸 쓰고 싶군요!!)
   C# 을 쓰면 프로퍼티 그리드 라이브러리도 어디선가 멋진 걸 가져다 써야겠지요.

4. 데이타 !
   간단한 클라이언트 스타일의 DB 를 찾아서 써보고 싶은 생각이 있군요.
   그리고 JSON(Insomniac 에서 뭔가 편리해보는 걸 본거 같습니다.)  이나  FastXML 라이브러리등을 쓸 거 같습니다.
   메모리 맵드 파일 / 구글에서 공개한 크롬 패치 툴도 써보고 싶네요-ㅅ-

사실 만드는 방법이야 다양합니다만 뭘 만들지가 중요하겠지요 열심히 고민해봐야겠습니다.!! 그래도 개인 프로젝트는 제일 잘하는 방법으로 그리고 조금 최신의 경향으로 개발해보겠다는 생각입니다.~_~

lighting! lighting!

http://c0de517e.blogspot.com/2009/12/lighting-compendium-part-1.html

위의 글은 간단히 라이트 방식에 대해( 포워드/디퍼드/라이트 프리패스) 간단하게 설명하고 있습니다.

요즘  MMO 들도 슬슬 디퍼드라이팅을 적용하는 거 같은데요(타뷸라라자가 처음인가요?).

일단 제일 큰 장점은 라이트 갯수보다도 라이트맵을 매번 굽지 않고 테스트해볼 수 있는게 크지 않나 싶습니다. 디자이너가 프로그래처럼 빌드해야 되는 건--안타깝지요.(우리(프로그래머?)도 언제가 빌드 없는 세상이 되면 엄청나게 생산성이 높아지겠지요?).

1. 포워드 렌더링
   => 기본적으로 라이트를 많이 쓴다는 가정하에 => 열심히 baking 해서 쓰게 됩니다.
   => 물론 미리 구워진 녀석이니 다이내믹으로 뭔가 연동하기는 쉽지 않겠지요;;;
   일단 아티스트 분들의생산성이 지형이 클수록 뚝뚝 떨어지니(엄청난 빌드타임으로);
   그리고 덤으로 라이트 문제가 생길때마다 데이타가 제대로 구워졌는지 한번씩 체크해봐야되는 문제가 있지요.
  => 그래도 다이내믹 환경이 필요없고, 편하게 라이트 스태이틱으로 마구 넣어서 적절한 크기의 맵에 쓰기는 좋은 솔루션이 아닌가 싶습니다.
  일단 Beast 같은 미들웨어의 경우 최신 버전에서는 매우 Scalable? 해서, 사용성이 좋아보입니다. 포워드로 수십명의 아티스트와 일할 계획이라면 당연히 써야 되는 거 아니라는 생각이 들 정도입니다.(물론 비싸니, 소규모 프로젝트에서 쓰기는 좀 그런 거 같습니다.)

2. 디퍼드 렌더링.
   => 이런 류의 솔루션은 이상하게 관심이 안가서,  안 보고 있었습니다만, 시대의 흐름을 무시할 수 없어서,(질문도 많이 들어오고-  기존 블로그 참고;;) 공부하고 있습니다.
   => 뭐 장점은 많은 수의 라이트를 다이내믹하게 사용할 수 있다 일테이고,
   => 기타 g-buffer 를 이용해서 포스트 프로세싱시에 이것저것 해볼 수 있는 점도 있겠습니다.;
   => 아직 하드웨어적으로 지원되지 않는( MSAA?) 기능이 있어서, 좀 더 발전할 구석이 있는 거 같습니다.
   => 알파블렌딩 이슈 - 요즘 많은 질문으로 저를 괴롭히고 있습니다.(원래 전 렌더링이 아니라서요-_-;; 이제 흰띠를 메었는데..흐음) 해결방식도 다양해서 어렵네요. 일단은 디퍼드라이팅을 즐하거나, 포워드로 렌더링하거나-ㅁ-

3. 라이트 프리패스/인퍼드 라이팅
   => 뭐 쓰질 않아서 잘 모르겠습니다만, 일단 3 패스로 라이트를 적절히 미리 계산해두거나 하는 거 같습니다.
   => 어차피 디퍼드의 알파블렌딩 이슈등을 처리하기 위해서 등등 디퍼드의 단점은 어떻게든 메꾸어야 되니 비슷한 여러가지 알고리즘이 생기는 거 같습니다.!
  

라이팅하니까 또 다른 문제인 쉐도우쪽도(이쪽은 이제 공부중이라서-ㅁ-)
그래도 이쪽은 카스케이드 쉐도우 맵으로 거의 하고 있는 거 같습니다.

몇몇 분은 그래픽스 쪽은 이론 쪽으론 정립이 끝난다고도 하시는 듯, 전 그런 걸 잘 모르겠습니다만, 하드웨어의 변동에 맞추어서 앞으로도 쭈욱 변화가 지속될듯 하네요. 따라서 엔진 개발은 쉽지 않은 일일 거 같습니다. 그러니 한동안은 이렇게 미들웨어와 엔진에 의존해서 개발해야 되겠지요. 렌더링 엔진도 로직 부분 처럼 점점 컴포넌트+그래프(언리얼의 그래프로 연결 만능-_-) 세상이 되는 거 같습니다.

2010년 11월 26일 금요일

Clean Code 를 읽으며 #2.

Clean Code 를 읽는 내내 드는 머릿속을 떠나지 않는 생각은,
저자분 대답합니다. 얼마나 고민하며 코드를 짰는지 책속에서 제대로 느껴지네요.

코드를 짜는 건 글을 쓰는 것과 같고, 다른 사람의 입장에서 읽어보면서 계속 고쳐야 되는 거라는 비유도 참 맘에 들었습니다.(그러고보면 많은 실력있는 프로그래머 분들이 블로그등에서도 참 글 잘 쓴다는 생각이 든적이 많은 듯도 합니다.^^)

아무튼 저자의 클린 코드에 대한 열정을 보며,
회사에서 10년이나 짜오면서 얼마나 고민하면서 해왔는지 반성하게 됩니다.
(오래 일한게 중요한게 아니라는 생각이 많이 드네요 잠깐을 일해도 바짝 정신차리고 고민하면서 했어야 했는데 말입니다.^^지금 부터라도!!)

조금 더 읽기 쉽게, 우리 프로그래머도 소설가? 라는 생각이 느껴지는 글이네요.
고스트 바둑왕에서 바둑판이 우주라고 말하던 주인공이 생각납니다.
우리에게 우주는 한줄 한줄의 코드겠지요^^

그럼 다 잊기전에 몇가지 코드 지침을 적어봅니다.

1. 함수인자는 최대한 적게 -> 함수를 소리내어 읽어보면 확실히 알 수 있습니다. 인자가 없으면 확실히 읽기 좋다고 하네요.
     덤으로 테스트하기도 편해진다고 하네요.
     사실 인자가 있으면 인자값을 뭘 넣어도 돌아가야 할 거 같아서 이래저래 귀찮긴 한 거 같습니다.

2. 널을 인자로 받거나 리턴하지 말것 -> 널객체 쓰세요(널 체크 없는 코드 만세! 저도 개인적으로 널은 싫습니다만, 널객체 만드는 것도 일이라, 네 널객체 열심히 맏들겠습니다.^^ )

3. 의도가 드러나도록 함수이름 잘 지으셈 -> 영어 공부가 필요한 코드?

4. 클래스는 전체적으로 하나의 일을, 함수는 반드시 하나의 일만(인자가 없거나 하나여야 되는 이유와도 일치한다고 읽은 듯 하네요.)

5. 중복은 죄악(비슷한 스위치문이 함수의 여러군데서 쓰여야 된다면->팩토리 패턴 써야 되는 신호?)
    함수가 하나의 일만 하면 사실 중복 생기게 짜기도 어렵겠지요;;(후우 말은 쉽습니다만 지키려면 늘 머리속에 두고 고민해야되겠네요)

6. 주석은 필요악 - 코드를 보고 바로 아는게 제일 좋음(주석은 시간이 지나면 관리되지 않으니 나중엔 거짓말이 가득한 주석이 되기 쉽다 합니다.)

7. 코드 짜고 나면 독자의 눈으로 한 번 읽어보자. 글 쓰고 퇴고하듯이.(저도 이거 읽고 블로그글도 퇴고 처음으로 해보고 있습니다. 아 제 글이 뭔가 어설퍼보이는 이유중 하나인 거 같네요. 좋은 거 배웁니다.^^ 당연한건가요~)

코드 짜는 것도 어떻게 하면 노가다가 되고, 어떻게 하면 책 쓰는 것처럼 고상하게 되고 그런 게 아닐까 하는 생각이 드는 책이었습니다.

강추!!(이미 다들 보셨을지도^^)

2010년 11월 25일 목요일

XBOX 360 게임 개발

요즘에 어쩌다 보니 Wii / PS3 /XBOX 360 모두 가끔씩 디버깅 할 기회가 있네요.
가끔씩이다 보니 한번 세팅하는 데 제법시간이 걸리긴 합니다만,
최소한 엑박은 재밌네요,(네 나머지는,,음,, 개념이 쪼오끔 다른 듯 합니다.)

개발 환경이 다른 문제도 있습니다만 일반적으로 윈도우라는 운영체제에서 당연하게 생각되던 것들이 가끔씩 안되니 당황스러울 때가 많네요.

오늘은 말로만 듣던 쓰레도 고사를 처음 겪어 봤네요.
시간이 지나도 쓰레드의 우선순위가 올라가지 않나 봅니다.( 낮은 놈은 다른 놈이 바쁘면 영영 ㅃ)
윈도우처럼 그래도 오래 기다리면 차곡차곡 올려주는 거하고 다른 거 같습니다.(제가 아는 한;; )

다양한 환경에서 다양한 디버깅을 해보는 것은 서포트 엔지니어의 특권이 아닌 가 싶습니다.^^

2010년 11월 23일 화요일

[Book] Clean Code

오늘은 Clean Code 를 꺼내 들어서 일고 있는 중입니다.

얼마전에 게임코디 눈팅을 하다가 본 getter/setter
=> 최대한 클래스 내에서 처리하도록 해서 getter/setter 없는 세상을 - 멋진 말인듯 합니다.
=> 사실 엔진 회사에서는 쉽지는 않은 듯(인터페이스를 어떻게 제공해야 할지가 문제.)
=> 무작정 상속받아서 처리하라고 그러기엔-ㅅ-

return null, pass null
=> 사실 이런 저런 악의 근원인데요.  포인터가 없는 언어가 많은 것도 이런 이유이겠지요-ㅁ-
=> 뭐 최대한 안쓰고 널객체를 넣어주면 좋긴 한 듯 합니다.
=> 최근에 널 사운드 시스템을 넣었습니다. 널 렌더러등도 필요한듯 한데요(이건 뭐 일단 제 당담이 아니니; =_=) 크게는 여러 객체들이 널 타입을 갖는 것이 테스트 하기도 좋고 한 거 같습니다. MockObject (이 개념이 맞는지는 정확히 모르겠습니다만) 처럼 행동을 흉내내고 테스트 하는 하나의 요소가 될 수도 있을 거 같습니다.

함수 이름 잘 짓기
=> 일단 영어라는 압박이, 제가 요즘 코드 리뷰시 지적받는 사항이 함수 이름과, 코멘트입니다.
=> 일단 영어는 둘째 치고 뭐하는 지 고민하고 함수 이름 짓는게 중요한 거 같습니다.(생각보다 쉽지 않은 거 같습니다.

리팩토링의 생활화
=> 회사에서 자주 하는 일이 여러 군데 흩어진 비슷한 코드를 모아서 이쁘게 함수를 작성 후 테스트 돌리기(완벽한 유닛 테스트가 없어서 손 테스트도 해야 되긴 합니다만,,=_=) 어느 정도 규모가 되면 전체적인 코드양이 일정하게 유지 되야 하는 거 같습니다.(기존 기능들이 통폐합,,,비슷한 기능들을 묶다 보면---+)

클래스는 한가지일만, 함수도 한가지 일만,
컴포넌트 패턴하고도 잘 맞는 얘기인 거 같습니다.
요즘 대세는 리플렉션(뭔지 정확하게 이해는 안갑니다만,,,) 시리얼라이제이션, RTTI 그리고 멀티코어에 중요한 메시징 시스템 까지 이미 있는 컴포넌트 라이브러리가 많으니 잘 가져다 써야 할 거 같습니다. 결국 C#의 프로퍼티 그리드로까지 깔끔하게 연결;; gpg 책에도 내용이 많고, http://nocturnal.insomniacgames.com/   여기에는 깔끔하게 통짜로 제공하니 함 가져다 쓰면 좋을 거 같습니다.!!!

그리고 요즘 느끼는 건데, 소프트웨어라는게 어디서 만들 던 초반에 버그가 없을 수는 없나봅니다. 뭐든 x.0 버전을 쓰면 고생하네요 -ㅁ- 최소한 좀 기다렸다 작업하는 게 내 코드도 깔끔하게 만들고 마음도 편한 듯 합니다.!!><

2010년 11월 22일 월요일

[Book]Apprenticeship Patterns

That's a great book for me.

I'm reading for second time now.

I know I need to wear white belt for programming now since I need more & different knowledge.

I've been working for 10 year at game company already.
I realized that I didn't study enough. ><

But it's okay. I have a great passion for programming. And I really enjoy it.
And I'm working now in great environment.
I hopefully can wear yellow belt soon.

Now I know that the most important thing is the passion and study & research everyday.!!

2010년 11월 21일 일요일

렌더링 공부 스타일

원래 공부 스타일이 처음부터 쭈욱 하나하나 인데,
렌더링하고는 잘 안 맞는 거 같다.
아니 공부할 양이 방대해지면 효율이 급속도로 저하되는 느낌이다.
(나름의 장점은 있지만.)

생각해보면 GDC 나 GPG 등등을 다 읽어 본다고 도움이 많이 되진 않는 거 같다.

특정한 문제(예, Deferred Rendering 에서 DOF 버퍼 처리?)
뭐 이런 게 있다고 한다면,
위의 관련 자료를 검색해보고,
모르는 게 있으면 타고 들어가고 들어가다 보면
Grpahic Gems 도 몇개 거치고 GDC 논문도 몇개 거치고 하면서 어떻게 구현해야 될지 감을 잡는 거 같다.

그동안 공부를 너무 안했더니, 공부 방법도 계속 변해야 된다는 것을 잊었던 거 같다.!!!

이상 프로그래밍 공부 방법 패턴을 모아놓은 듯한,
프로그래머 멘토에게 묻다를 읽다가 생각난 것이었습니다.~~

2010년 10월 30일 토요일

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

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

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

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

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

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

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

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

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

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

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

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

2010년 10월 19일 화요일

해야할일 목록 입니다.

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

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

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

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

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

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

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

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

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

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

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

물리 엔진

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

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

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

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

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

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

엔진 사용.

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

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

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

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

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

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

2010년 10월 11일 월요일

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

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

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

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

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

  

    

2010년 9월 10일 금요일

PeekMessage HWND...

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

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

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

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

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

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

다시 블로그 시작

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

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

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

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

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

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

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

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

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

2010년 3월 18일 목요일

엔진들 엔진들,,,


요즘 유니티 3D 가 멋지게 떠오르면서,,,
GDC2010 내용들을 보니 주 화제인듯 합니다.

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

고가 엔진 시장(퀄리티를 중심으로 무수한 사람과 인력을 쏟는,,,) : 언리얼/크라이 가,,,
=>이쪽은 TD 의 역할이 매우 크므로,,,프로그래밍 디자인 모두 센스 있는 인재가 많이 필요해보입니다.

중가? MMO 처럼 소스 코드를 많이 고쳐야 하는 쪽은 : 게임브리오/비젼,,,,
=>이쪽은 아직 엔진 프로그래머들이 열심히 렌더러도 고치고,
=> 새로운 미들웨어를 붙여보기도 하는,,재미난 곳,!!ㅎ

그리고
저가/무료 : 유니티3D, Shiva3D(이건 그냥 잘 모르겠음-_-)
원래는 자체 엔진은 개발하던 미니 게임(서양에서는 캐쥬얼 게임이라고 부르는 플레이타임 5분 정도의 게임들,,,)이나 스마트폰 게임들은,,,,거의 여기로 가는게 아닐까 싶네요.
=>이쪽은 프로그래머가 급격히 필요없어지는 느낌입니다.
=>프로그래머 대신 스크립터가 필요한듯,,,(뭐 액션스크립트를 프로그래머가 하듯이 이것도 프로그래머가 하겠지만!!0

저는 개인적으로 게임브리오나 비젼처럼 엔진도 이것저것 건드리고,
미들웨어도 붙여보고 이런쪽이 재밌긴 한데요.
(이쪽이 MMO 에 제일 맞는 거 같기도 하고요,,,개인적인 생각입니다만,,,)

유니티3D 쪽도 돌아가는 건 파악해야 되겠다는 생각이 드네요.
(주변에서 이걸로 뭘해보자고 많이들 하시는데-_-아아 저도 뭔가 해보고 싶긴 한데. 게을러서,,,)

2010년 3월 16일 화요일

게임 산업의 미래.

요즘 여러 사람들과 얘기하면서,
게임 산업은 어떨지 그리고 프로그래머의 미래는 어떨지 궁금해 지곤 합니다.

1. 스마트 폰, SNS 등으로 인한 캐쥬얼 게임의 폭발!!!
여기에는 Unity3D 나 Shiva3D 같은 안정적이고 빠르게 만들 수 있는 게임플랫폼 덕분도 있는듯!~
페이스북 게임도 많이들 하져~~

2. 거대 자본이 들어가야 하는 AAA 온라인게임?
거대 자본과 체계화된 시스템이 필요한 거대 온라인 게임은 블리자드사가 거의,,,
주변 개발사도 보면 뛰어나고 우수한 인재들은 많은데, 뭔가 체계화되고 관리된 시스템이 없어서,
무너지는 것처럼 보이는 경우가 많습니다. (적절한 PM 의 부재랄까요,,,-_-)

3. 프로그래머?엔진?
소규모 인디팀에서 자체 엔진으로 개발하는 경우가 많이 사라진듯 합니다.
자체 엔진의 경우 안정성이나 문서화 등이 쉽지 않아서, 개발자 한명 한명이 소중했는데 말이져~~
아무튼 그래서
대규모 - 언리얼,크라이
중간규모 - 게임브리오, 비젼,,,등
소규모 - 유니티

저렇게 규모별로 맞는 엔진이 존재하는 듯 합니다. (물론 게임 타입에 따라 다르겠지만요)
소규모 팀에서 사실 선택할 수 있는 옵션이 많다는 건 좋은 거 같기도 합니다.
예전처럼 오픈소스 엔진위의 자체 엔진 이런 형태는 많이 사라지지 않을까 생각합니다.
결국 이렇게 되면 엔진하시던 분들은 전문화 되어 미들웨어사나 엔진사를 차리거나 그런 회사로 들어가게 될 거 같네요.
(아니면 중간규모 급에서는 엔진 수정이 많으니 그쪽 엔진에 필요 기능 추가도 있을 수 있겠네요)

아무튼 게임 시장은 커질거라고 생각합니다.
(다들 스마트폰-게임기를 한대씩 들고 다닐테니까요,,,)

하지만 늘어나는 만큼 순수 프로그래머들이 많이 필요하진 않을 거 같네요,
예전 게임처럼 대규모로 프로그래머들이 우르르 일하는 경우도 적어지지 않을까 싶고요.

그리고 점점 엔지니어보다는 어느 정도 아트 감각을 가지고,
TD 로 활동하는 분들이 많아지지 않을까 싶습니다.

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

아무튼 결론은 ,,, 이것저것 할께 많아지네요. 늘 그래왔듯이...
요새 디자이너 분들도 스크립트 공부 많이 하시던데,
우리도 툴 공부 열심히 해야 될 듯 합니다.!!



2010년 3월 15일 월요일

컴포넌트 시스템 정리 - 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 등등의 기본 데이터가 있을테고,
이런 기본적인 데이타에 대해서는 어떻게 저장할지 미리 규칙을 정해둡니다.

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