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