몬트리올 겨울 살아남기... 폭설편....

어저께 눈이 왔습니다.. 많이 왔습니다.... 한 45~50cm왔다네요 하루만에..

어제는 집앞의 통로를 한 30분정도 걸려 다 치우고... 

집뒤의 주차장을 한 2~3시간 치우다 (한 2/3쯤 치운듯) 친구랑 술먹으러 나갈시간이 되어서 멈추고 나갔었죠. 큰길들은 이미 정부에서 잘 치웠더군요. 도로 옆에 수북히 쌓인 눈들은 차차 다른데로 옮겨간답니다. 많이 와서 한 1주 걸릴거라 하네요....

사람들이 다 집에서 눈치우고 있었던지.. 술집엔 사람들이 별로 없어서 아늑하고 좋았습니다.. ^_^. 

그래서 같이 술먹으면서 친구에게 물어봤죠.. 이정도 눈오는게 보통이냐고.. .그러니 "응, 이정도면 양호한거야.." 라고 하더군요..그래서 그런가보다 했는데.... 이글 쓰면서 뉴스를 보니.... 몬트리올 역사 사상 하루에 온 눈으로는 최고라고 합니다.....이 ㄱㅅㄲ 죽었어 -_-+

뭐든간에 살아남았으니... 뭐 앞으로 눈오는거 살아남는건 어렵지 않을듯.... (오늘도 3시간 더 눈 치웠지만... 꾸엥....)

제 유투부 비디오에 광고가 달렸군요...

뷰가 845밖에 안되는데 .. 갑자기 유투브에서 광고를 달아주겠답니다. -_-  제가 거절 할리 없지요....

http://youtu.be/2oJVhqPXJyo


역시 뛰어난 음악인은 되고 볼일입니다...... -_-

Fast Object Picking

예제코드 다운받기

• C#과 XNA를 이용해서 만들었습니다.
• XNA를 설치하셔야 합니다.

게임보다는 에디터 따위의 툴에서 더 유용한 기법입니다. 예전에 개인 프로젝트에서 장난삼아 만들어 봤던 놈인데 그뒤로도 몇번이나 동일한 기법을 여러 툴에서 구현하다보니 올리면 유용하겠다 싶어서..... 이미 알고계시는 분들도 많겠지만 혹시나 모르시는 분들을 위해 여기 올리면 좋겠다고 생각해서 올립니다.

이 기법이 해결하려고 하는 건 간단합니다. 맵 에디터 같은 프로그램에서 화면에 있는 물체를 마우스로 클릭해서 선택하는걸 졸라~ 빠르게 구현하는 겁니다.

말로는 쉽죠?... 그런데 보통 구현들 어떻게 하셨나요?

흔히 쓰던 광선 vs AABB 충돌검출 방법
제가 흔히 봤던 방법중 하나는 마우스 클릭한 위치부터 화면 안쪽으로 광선(ray)를 쏴주면서 그 광선과 각 물체의 AABB의 충돌검사를 한뒤 가장 가까이에 있는 물체를 선택하는 거였습니다.

예를 들어 아래 이미지에서 오른쪽 가장자리가 화면이라고 가정하면 이런식으로 ray를 쏴서 aabb를 찾는거죠.

그런데 이 방법에 문제들이 좀 있습니다

• 월드에 물체들이 많으면 충돌검사 시간 꽤 걸립니다
• AABB와 충돌검사를 하므로 픽셀단위로 정확한 충돌검사가 불가능합니다.

제가 쓰는 렌더타겟과 물체 ID를 이용한 방법

저는 GPU를 이용해서 위 문제점들을 해결했습니다. 알고리듬은 매우 간단합니다. 자세한 코드는 위에 첨부해 놓은 예제코드를 봐주세요.

1. 각 물체마다 고유 해쉬 아이디(32비트 정수)를 부여한다.
2. 화면크기와 동일한 A8R8G8B8 렌더타겟을 하나 만든다. (이후 ID맵이라 부름)
3. ID Map맵 렌더타겟을 설정한다.
4. 모든 물체를 그려주면서 물체 해쉬(32비트)값을 8비트씩 짤라 R,G,B,A채널에 써준다
5. 마우스가 클릭된 위치의 픽셀을 읽어온다
6. 그 해쉬값과 동일한 물체를 선택한다.
7. 선택된 물체로 하고 싶은 짓을 한다 -_-
8. 끝 -_-

해쉬아이디

해쉬 아이디는 아무렇게나 생성이 가능합니다. 각 물체마다 고유하기만 하면 되죠. 제 예제에서는 그냥 물체 이름인 string으로부터 해쉬 아이디를 생성했습니다.

해쉬아이디를 색상으로 바꾸는 법

해쉬 아이디를 RGBA로 바꾸는 코드는 다음과 같습니다.

private static Color HashIDToColour(int hash)

{

    int a = (hash >> 24) & 0xff;

    int b = (hash >> 16) & 0xff;

    int g = (hash >> 8) & 0xff;

    int r = hash & 0xff;

    return new Color(r, g, b, a);

}

이 후 이걸 셰이더 함수로 대입해준 뒤

ColourFX.Parameters["Colour"].SetValue(HashIDToColour(go.Hash).ToVector4());

셰이더 안에서 다음과 같이 그려만 주면 됩니다.

float4 ps(VtxOut In) : COLOR

{

return Colour;

}

해쉬아이디 읽어오기

매우 간단합니다. 그냥 그 픽셀값을 32비트로 읽어오면 끝입니다. (이미 해쉬 ID에서 색상으로 변환할때 byte순서및 엔디안 문제를 고려했거든요

public int PickObject(int x, int y)

{

    int hash = Hash.INVALID;

    int [] pickedPixel = new int[1];

    IDMap.GetData<int>(0, new Rectangle(x, y, 1, 1), pickedPixel, 0, 1);

    hash = pickedPixel[0];

    return hash;

}

예제 결과

일단 제 샘플 코드를 실행해보면 다음과 같은 그림이 보일겁니다.

메인 화면에 3개의 공이 있고.. 오른쪽 아래는 ID맵입니다.

여기서 파란색 공위에 마우스를 클릭하면 다음과 같이 됩니다.

현재 선택된 물체를 노란색으로 표현했습니다. 그리고 현재 선택된 물체를 ID 맵에 안그려서 다시 한번 더 클릭을 하면 그뒤에 있는 물체가 대신 선택되게 만들었습니다.

이정도면 대충 보여드린듯 하죠? 자세한건 직접 받아서 실행해보세요.. -_-;

기타 응용

최근에 이 기법을 응용해서 물체 ID 대신에 물체의 깊이를 저장도 해봤답니다. 마우스 클릭 위치 근처에 있는 복셀(voxel)들을 전부다 고칠일이 있어서... 그냥 마우스 클릭 깊이만 찾아다 그로부터 월드위치 구한 뒤, octree를 뒤져서 근처에 있는 복셀들을 찾아냈죠.

기타 등등의 응용법이 있을 겁니다.

오랜만에 글써본 포프였습니다.

[링크] SSD에 fadeout효과 적용하기

ttmayrin 님이 SSD를 본인 엔진에 적용하시면서 개량 해주셨네요. fadeout을 넣으셨습니다. 제가 예전에 시도했다가 아트 다 고쳐야하는 이유때문에 관둔 방법과는 다르네요... 결과는 아주 훌륭합니다. 가서 한번 보세요 ^_^/


http://ttmayrin.tistory.com/37

인벤하고 한 인터뷰 입니다. (그리고 추가부연 설명)

KGC 2012 동안 인벤에 잠시 들려서 2시간 동안이나 인터뷰를 했습니다. 제가 굉장히 횡설수설 했는데 다행히 기자분들이 너무나 글을 잘 써주셨네요.

일단 인터뷰기사 부터 읽어보시고....

인터뷰에서 딱히 잘못된 건 없는데... 잘못 해석하면 의미전달이 잘못될거 같은 부분이 있어서 여기에 추가부연 설명을 합니다. (물론 의미전달이 잘못되면 제가 더 멋져보이지만... 거짓말하는 듯한 느낌이 들어 이런건 깔끔하게 밝힙니다..)

1) 기사에서 '엔진' 이라고 나온건 '그래픽 엔진'입니다.
정확히 말하면 엔진에서 그래픽 부분만 제가 담당한거죠. 뭐, 그 외에도 파이프라인 및 도구 프로그래밍 등에도 당연히 참여했습니다.

2) 그래픽 엔진 개발을 단 둘이 한 건 아닙니다.
그래픽 프로그래밍 팀이 처음에는 3명이다가 나중에 5명까지 되었는데... 처음부터 끝까지 (3.5년간) 개발한 사람은 저 포함 두명입니다. 그 중 다른 한 명은 1년에 2달 정도씩 휴가를 갔었습니다. (육아휴가 2번 및 안식년 등등 다 포함)... 고로 제가 가장 오래 그 팀에 있었고 그만큼 가장 많은 부분을 담당한 겁니다.

3) 외국 게임회사들의 소스공개
반드시 소스코드를 공개한단 의미는 아니었습니다. 단 그 게임에서 사용했던 기법들을 드러내놓고 소개한단 것이었죠.

4) 변하지 않는 진실... 꽃미남 -_-v
제가 꽃미남이라 한거 아닙니다. 남들이 먼저 그렇게 불렀고 전 그냥 남들이 그랬다고 말할 뿐입니다.. -_-



포프

[2012 대학 특강] 아티스트 + 프로그래머 = ?

2012년에 서강대와 부산 게임아카데미에서 특강했던 자료입니다.

스페이스마린에서 사용한 기법들을 아티스트와 프로그래머가 협력해서 개발한 과정을 설명했으며, 그로부터 아티스트와 프로그래머는 적대관계가 아니라 협력관계라는 걸 학생들이 배웠으면 합니다.

[2012 대학특강] 아티스트 + 프로그래머 from 포프 김

셰이더 프로그래밍 입문 정오표

새 페이지로 옮겼습니다.

천재 미남 프로그래머 인터뷰 나갔습니다...

KGC 강연 끝나마자마 산왕님께 끌려가서 어리버리 한 인터뷰.. 제가 한 말에 비해 인터뷰가 너무 멋지게 나와서 화들짝...

특히 천재 미남인걸 부각해주셔서... 앞으로 사는데 편할듯한 -_-;;;

사진이 실물보다 좀 못나와서 ... 미남.. 앞에 꽃을 못붙이는게 아쉽........ -_-;;;;


인터뷰 보기

스크린 스페이스 데칼 (KGC 2012 발표자료)

KGC 2012에서 발표했던 "스크린 스페이스 데칼에 대해 자세히 알아보자"의 슬라이드 자료 공개합니다.

뒤에 서서 보시는 분들도 여럿 계실정도로 강의실이 꽉 찼던데.... 모두들 찾아와주셔서 감사합니다.

스크린 스페이스 데칼에 대해 자세히 알아보자(워햄머 40,000: 스페이스 마린) from 포프 김


제 시그래프 자료는 이보단 약간 부실한데.. 굳이 궁금하신 분들은 영문 블로그를 참고해주시기 바랍니다.

KGC 2012 강연갑니다..

이미 아시는 분들은 아시겠지만.. 작년에 이어 올해도 KGC 2012의 발표자로 뽑혔습니다. 작년에 처음 갔을때는 사실 저를 아시는 분들이 거의 없어서 그냥 좀 편하게 다녀왔는데.. 올해는 과연 어떨지 모르겠습니다. 가기전부터 벌써 이리저리 일정이 잡히는 것들 보면 작년처럼 여유롭지만은 않을듯 하네요.

뭐 어차피 발표하러 가는거니까.. .^_^


올해 발표할 주제는 Screen Space Decals입니다. 올해 시그래프에서 발표한 자료를 더 보강한 놈이죠..

• 시간: 10월 9일, 오전 9:20~10:20분
• 장소: 코엑스...강의실은 102호

그럼 KGC에서 뵙겠습니다. ^_^/

p.s. 셰이더 책 사신 분중에 싸인 받고 싶으신 분들은 강의 끝나고 저에게 받으시던가.. 아니면 저 보이면 그냥 잡고 해달라고 하세요.. ^_^/

p.s.2 최근에 몬트리올로 옮겨서 직항이 없는관계로.. 집에서 떠나서 호텔까지 들어가기까지 대략 24시간 걸릴거 같습니다... 좀비처럼 돌아다녀도 이해해주세요 -_-

KGC 2011 강연 동영상이 공개되었네요.

KGC 2011에서 강연했던 "스페이스마린의 렌더링 기법" 동영상이 공개되었네요. 즐감하세요.. ^_^/

http://www.kocca.kr/knowledge/seminar/1775011_3306.html

공개사랑 고백을 받았습니다.

게임개발 랩소디 10화에서 공개사랑 고백을 받았습니다. -_-

들어보세요...

http://agebreak.iblug.com/index.jsp


한 13분 40초에서 15분 50초 사이에서 가장 강하게 나오네요 -_- 물론 그뒤에도 한 두어번 더 나옵니다만.....

일단 목소리가 이쁘신 분이라 괜히 설레하고 있습니다... -_-

오늘도 존경받았습니다...

자세한 내용은 아래에...

http://frosthoya.egloos.com/260055

스퀘어 에닉스/아이도스 몬트리올로 옮깁니다

제 옛학생이자 친구인 Friso란 친구가 오늘 갑자기 물어오더군요. 스퀘어에닉스/아이도스 몬트리올로 옮기는걸 왜 블로그에 밝히지 않냐고... 딱히 이유는 없었는데... 졸라 느린 이삿짐 회사 때문에 골치썩어서 였을지도 모르고.... 몬트리올이란 새 도시에서 새 집 찾느라 바빠서 였을지도... 어쨌든 정식으로 밝히지요.

스퀘어 에닉스 산하의 아이도스 몬트리올이란 스튜디오에 Senior Rendering Programmer로 들어가기로 했습니다. 제가 참가할 프로젝트가 아직 극비라 밝힐순 없지만 그냥 아직 미발표 AAA 프로젝트라고만 말해두겠습니다. 이 팀의 Programming Director가 이미 링크드인 프로필에 그렇게 밝혀두고 있으니 이정도는 크게 문제가 없을거라 생각...

자, 그럼 어쩌다 몬트리올까지 가기로 맘을 먹었을까요...? (현재 있는 곳은 뱅기로 5시간 거리인 밴쿠버...)

일단 제 계획은 시그래프 2012 발표를 마친 뒤에 본격적으로 Job Hunting을 시작할 계획이었습니다. 그런데 시그래프 1~2주 전부터 리쿠르터들의 연락이 오더군요. (시그래프 발표자로 뽑히면 리쿠르터들이 먼저 연락해 오는듯?) 그래서 시그래프 전에 리쿠르터들하고 대화를 시작했고 전화면접도 좀 봤습니다. 아이도스 몬트리올도 전화면접 본 회사중 하나였죠. 그 뒤, 시그래프 도중에 아이도스 몬트리올 사람들이 잠시 만나자 하더군요. 그래서 그랬습니다.

솔직히 말하면 이 때까지만 해도 이 회사를 가진 않을 거라 생각했었습니다. 몬트리올로 옮겨야 하니까요. 제가 워낙 밴쿠버를 좋아하고 이미 밴쿠버 회사에서 훨씬 나은 offer를 받아놓은 상황이어서요. 근데 아이도스 몬트리올 사람들과 10분 정도 대화하고 나서 생각이 바뀌었습니다. 프로젝트가 너무 좋아요... 절대 놓치고 싶지 않은 프로젝트.. 그래서 거의 10분만에 맘을 대충 정했죠...

대략 8월 20일쯤 offer에 싸인했을겁니다. 그리고 다음주에 짐 빼고, 그 담주에 근무시작하니... 꽤 빠르죠... 사실 이놈의 이삿짐 회사가 이리 말도안되게 느려터지지만 않았다면 사실 담주부터라도 시작했을겁니다. 올해 10월 초에 KGC 2012에서 또 발표를 하게 되서.... 그전에 새 회사에서 한달 정도는 좀 진득히 일한 뒤에 휴가를 빼고 싶었거든요.

새 프로젝트 기대되냐구요? 많이 그랬죠. 지금은 조금..... 원래부터 쉽게 뭐에 기뻐하며 흥분하는 성격도 아니고 설사 그러더라도 오래 못가거든요. 이제부터 어떨지 두고보자구요. 일단 프로젝트에 참가해서 일하게 되면 더 신나할 수도 있으니까요... 함 두고보자구요....

그럼 이정도면 지난 한달 동안 있던 일을 대충 정리 잘 한듯 하니..... 다음번에 다시 글을 쓸때까지 뱌뱌~

셰이더 프로그래밍 입문 책 리뷰들

Update: 2012년 11월 10일 기준으로 온라인 책방에 실린 리뷰들을 긁어왔습니다. 앞으로도 종종 업데이트할 생각입니다.

한빛미디어 웹사이트에 달린 제 책의 리뷰 둘입니다. 당연히 좋은 리뷰니까 올립니다 -_-;

교보문고를 보니.... 리뷰가 더 있습니다... 역시 별이 최소 4개입니다 꺄아~ -_-

YES24 에도 있네요.

인터파크에도 4개 있습니다... 평점이 무려 9.5점! -_-v

역시 책은 잘 쓰고 볼일입니다.... (왜 마지막엔 꼭 자뻑일까 -_-)

셰이더 프로그래밍 입문 책 예약판매 시작합니다.

셰이더 책이 드디어 예약판매에 들어갔답니다. ^_^ 줄간일이 7월 31일이군요.. 알려주신 김경진님꼐 감사드립니다.

셰이더 프로그래밍 입문 예약판매

대체 왜 이걸 다시 구현해야하는 거지?

요번주에 마무리짓고 싶은일... 다음달에 시그래프 2012에서 발표할 스크린 스페이스 데칼 프리젠테이션 마무리하기. 그냥 PPT파일만 하나 만들면 되는거였다면 좀더 열심히 해서 끝냈을지도 모르겠다. 하지만 Relic Entertainment에서 퇴시한 지금 코드도 내 수중에 없고 맵 에디터도 없다는것... 따라서 이 모든 기능들을 다시 대충 만들어서 데모 프로그램을 만들었음... 그래야 스샷도 찍을수 있을테니까.

솔직히 말하면 꽤 지겨운 일이다. 이거 재구현함으로써 새로 배우는것도 없고 개인적인 발전이 있는것도 아니니까. 이미 너무나 잘 알고 있던거 그냥 반복하는 수준.. -_-; 뭐든간에 모든 기능 구현은 끝냈고, 테스트 아트들도 다 배치해놨으니.... 요번주에만 끝내면 되겠지...

프리젠테이션 준비 마무리하면 좀더 시간을 투자하고 싶은 프로젝트가 2개 있으니.. 그걸 구실삼아 어떻게든 프리젠테이션 준비를 요번주에 마무리할 수 있지 않을까... 하는 희망만 품어봄..

어디 어찌되는지 두고보자.. -_-

XML 데이터를 읽어올수 있는 C# 클래스 자동생성하기

예전에 작성해놨던 작업일지에 보니 이게 있네요. 그래서 까먹기전에 재빨리 포스팅합니다. 뭐 혹시 다른 분께 도움이 될 수도 있으니....

XML 파일을 그대로 읽어올 수 있는 C# 클래스를 자동으로 생성하는 것... 예전에 CAT 릭을 사용한 애니메이션 데이터를 3DS Max에서 읽어와서 Unity안에서 쓰려고 할 때 시도해봤던 겁니다. FBX파일을 CAT 릭에서 IK를 사용한 애니메이션 데이터를 제대로 export하지 않거든요. FBX에서에서 돌게하는 유일한 법은 애니메이션을 각 프레임 별로 bake하는건데 전 key frame 정보를 사용하고 싶었어요. 그래서 FBX 대신에 3DS Max에서 곧바로 XML 파일로 애니메이션을 저장할 수 있는 자체 기능을 써볼려고 했죠.

XML 파일을 저장해낸 뒤에 이 파일을 한번 문서편집기에서 열어봤죠. 데이터 구조가 그리 복잡하지 않다면 XML 파일을 곧바로 deserialize할 수 있는 C# 클래스를 손수 작성할수 있을거라 생각했거든요. 근데.... 그게 아니더군요.. 너무 복잡해요 -_-;;; 그래서 다음으로 생각한게.. '이걸 자동으로 해주는 툴이 있지 않을까?' 하는 것...

구글에서 검색을 해보니 스택오버플로우 에서 비주얼 스튜디오에 딸려나오는 xsd.exe을 이용하면 이게 가능하더다군요:

• http://stackoverflow.com/questions/226599/deserializing-xml-to-objects-in-c-sharp
• http://stackoverflow.com/questions/87621/how-do-i-map-xml-to-c-sharp-objects

뭐 결국 제가 실행해야할 컴맨드라인 명령은 다음 두 줄 뿐이었습니다.

xsd test.xml /classes -> test.xsd
xsd test.xsd /classes -> test.cs

첫째 라인은 XML 파일로부터 XML 스키마 파일을 만드는거구요. 두번째 라인은 스키마 파일로 부터 C# 클래스를 생성하는 겁니다. 일단 test.cs 파일을 만든 뒤에 제가 할 일은 C#에서 자체적으로 지원하는 XML Serializer를 이용해서 C# 개체로 모든 데이터를 읽어오는 게 전부였죠. 대충 이렇게 보이는 코드입니다.

XmlSerializer x = new System.Xml.Serialization.XmlSerializer(typeof(test));
FileStream stream = File.Open(@"test.xml", FileMode.Open);
var a= (test)x.Deserialize(stream);

매우 간단하죠? 저도 너무 간단해서 놀랐어요 -_-;;; 근데 불행히도 XML 파일에서 제가 원하던 키프레임 정보를 읽어올 수 있어서..... 결국 사용하지 않았죠.. 뭐든간에... 알아두면 유용한 지식!

효과적인 온라인 대화 스타일

온라인에서 가끔 메신저나 또는 문자 메시지로 들어오는 질문들에 대한 내 default 대답.

너: "내일 시간 있어?"

나: "없어" 또는 (씹음)

너: "뭐해?"

나: (씹음)

너: "있어?"

나: (씹음)

너: "뭐좀 물어봐도 돼?"

나: "안돼" 또는 (씹음)

뭐 싸가지가 없다고 보는 사람도 있겠지만.. 난 온라인상에서 매우 비효율적으로 대화하는 사람을 싫어한다. 위와 같이 물어보는 것은 사실 오프라인 대화에서 적절한 방법 아닌가? 예를 들어 내가 다른 일에 신경을 쏟고 있을때 누군가 다가와서 "시간좀 있어?"라고 물으면 잠시 하던 일을 멈추고 대화모드로 전환해야 하니까... 그러면 그때부터 실시간으로 짧게 대화하면서 할말 끝내고 끝... (오프라인처럼 질질 끄는 대화가 아니라 실제 곧바로 이야기하면서 일 처리 후다닥 끝낼수 있음...)

하지만 위와 같은 대화를 온라인에서 하게 되면 정말 짜증난다. 일단 온라인 상에서 또는 문자로 대화할때는 상대방이 곧바로 대답을 하지 않는 것이 일반적... 일방적인 소통 수단이니까... 보통 한쪽이 말을걸면 다른쪽이 그 메시지를 확인하는데 시간이 좀 걸림... 그리고 상대방이 메시지를 확인할 때가 되면 이미 이걸 확인하려고 다른 일을 멈춘 상태... 즉 이미 질문자가 물어볼 "본론"을 읽을 자세가 되어있다는 이야기다.

본론을 받아들을 자세가 되어있을때에도 보이는 메시지라곤 아무 속알맹이 없는 "있어?"따위의 메시지라면 엄청난 시간 낭비이다. 여기에 "응, 있어"라고 대답하면 원래의 질문자는 또 자리를 뜨거나 다른 일을 하느라고 답하지 않는 경우도 허다하고.... 그냥 처음부터 본론부터 말해놓으면 내가 메시지를 보고 곧바로 답을 보내주면 끝날 것을.. 왜 이따위로 비효율적으로 대화를 하는지 모르겠다.

물론 위의 예에서 한가지 예외는 "내일 시간 있어?"라는 질문... 이 질문에 내가 곧바로 "없어"라고 대답하는 이유는... 상대방이 실제 뭘 원하는지 모르는 상황에선 내가 시간을 내줄 수 있는지 없는지 모르기 때문이다. 내가 다른 약속이 잡혀 있더라도 상대방이 내게 하고 싶어하는 일에 더 흥미가 간다면 이전 약속을 취소해서도 시간을 내줄거고.. 그 반대라면 설마 내가 시간이 있더라도 하기 싫다고 거절할 수도 있으니까...

왜 다른 약속이 안잡혀 있으면 당연히 자기들 일을 처리해줄거라고 생각하는거지? 지 하기 싫은 일들을 거절할때 바쁘다는 핑계를 대는게 일반화되어 있는 문화라서 그런가?..

아.... 참고로 이건.... 한국인들과 온라인으로 대화할때 생기는 문제점을 말한 것... 캐나다쪽에선 이런 문제를 겪은 적이 없지만.. 내가 사람만나는 서클이 주로 개발자에 한정되어 있어서 일수도 있음.... 한국인중에서도 사실 개발자들은 이런 문제가 적으니까... 워낙 단도직입적으로 일 처리하는게 일반화 되어있는 직군이라서 그런듯... 한마디로 한국에서 몇 안되게 제대로 사는 직군이라 생각함..

어째든 오늘의 rant는 이정도로 끝

북미취업 가이드 독자 리뷰 2개. (인터파크)

안녕하세요 연두 이유식 좋은거 먹여보겠다고 여전히 책광고에 여념이 없는 포프입니다... 인터파크에 가보니 독자리뷰가 두개나 달려있어서 후다닥 올립니다.. ^_^

• 리뷰 1: 게임개발자의 꿈을 가지고 있다면...
• 리뷰 2: 게임으로 북미취업을 하고싶거나 관심이 있는 모든 이들을 위한

좋은 리뷰 모두 감사드립니다. ^_^

북미취업 가이드 독자 리뷰 #1 by 슈~♥

슈~♥님이 제 책을 읽으시고 본인 블로그에 남기신 리뷰가 있길래 링크를 퍼옵니다. 제 책이 다른 사람들의 이정표 비스무리한게 된다니 기분이 좋네요. ^^ 리뷰는 아래 링크를 눌러주세요.

슈~♥님의 리뷰 보기

KGC 2011 베스트 스피커 상을 받았습니다.

2011년에 KGC에서 "스페이스마린의 렌더링 기법" 발표를 했는데 말 잘했다고 상이 날라왔습니다. 정성스럽게 포장해서 캐나다까지 보내주신 KGC 관계자 분들께 감사의 말씀을 드립니다. ^_^

ㄱㄱㅑ~ 오랜만에 상탔다!

Unity는 C#으로 작성했다?

요즘들어 Unity가 인기를 많이 끌고 있고, 저도 어쩌다 유니티를 주무르는 동안에 발견한 내용들을 짧게짧게 블로그에 올려볼 생각입니다. 유니티를 체계적으로 배우시고 싶다면 아마 게임개발포에버에서 도플광어님이 연재하시는 글을 보시는게 젤 좋을겁니다.

자, 그렇다면 오늘의 짧은 정보는... 과연 Unity는 어떤 언어로 작성되었나? 입니다. Unity가 Mono를 이용해서 .NET 프레임워크를 자체적으로 지원하고, 저희가 유니티에서 사용할 수 있는 스크립트 언어도 C# 이다보니

'유니티가 C#으로 작성 되었구나. 그럼 이 엔진이 속도가 너무 느리지 않을까?'

라는 걱정을 하는 분들이 계실겁니다. (저도 그랬다는..)

그래서 그에 대한 답을 좀 찾아보니 영문 질답란에 이미 유니티 개발자가 답을 해놨더군요.


이걸 대충 번역하면...

"유니티는 C++로 작성되었으나 다음과 같은 예외가 있습니다.


.NET API를 노출시켜서 여러분들이 C++로 게임을 짤 필요를 없게 만든 것 뿐이지요. 자바스크립트나 C# 또는 Boo를 이용해서 코딩을 할 수 있는 이유가 바로 .NET API 덕분입니다.


에디터 프로그램의 UI는 C#으로 작성했습니다. 유니티를 사용하시는 게임 개발자들에게 공개된 API와 거의 동일한 API를 쓰지요. (아직 공개되지 않는 API를 조금 쓰기도 합니다만 그리 많진 않습니다.)


이것이 바로 "UnityEngine.dll 파일을 다른 C# 프로젝트에서 사용할 수 있나요?"라는 질문에 대한 답이 언제나 "아니요"인 이유입니다. UnityEngine.dll에는 거의 아무 기능도 들어있지 않습니다. 이건 그저 C#/자바스크립트 호출들을 C++ 엔진에 연결해줄 뿐입니다. C++ 엔진이 없이는 그냥 속빈강정이랄까요?"



한마디로 대충 정리하면:

• 유니티 내부는 C++이여서 C#보단 성능이 빠릅니다. 단, C#/C++ 컨텍스트 스위치 되는 부분에서 약간의 성능저하는 있을수 있습니다만 언리얼엔진에 비해 크게 문제는 안될거 같습니다.
• 유니티 에디터는 C#으로 작성되어 있습니다. (에디터에서 리플렉션을 자동으로 지원해주는것도 이때문일듯...)
• 유니티를 사랑합니다.. (응?)

참조:

• Unity Answers: Is Unity Engine written in Mono/C#? or C++

차세대 엔젠개발에 대해 예전만큼 꼴리지 않는 이유는?

차세대 콘솔용 그래픽엔진 개발하자고 러브콜이 종종 오는데... 여기에 한 번에 혹~ 끌리지 않는건 이미 몇 번 해먹어서인듯 하다. 최근에 PC, PS3, Xbox 360 용으로 멀티 플랫폼 엔진을 처음부터 끝까지 만들어서 스페이스마린을 출시한 것도 있지만 그보다 더 자랑스러운 업적은 사실 그전에 이뤘었음.

캡콤 밴쿠버(내가 일할 때 이름은 블루캐슬게임스 이었음)에서 일 할 때 PS3, Xbox 360, Wii, PSP, PS2, PC 6개 플랫폼에서 동시에 도는 엔진을 개발했으니까.... (PC용은 내부용이었기에 PC를 제외한 5개 플랫폼으로 동시에 The Bigs를 출시했었음. 평점도 80점.)

아마 게임개발 역사상 한 스튜디오에서 50~60명 인력가지고 5개 플랫폼으로 동시에 게임을 출시한 적이 없었을껄...? 하는 생각을 하다보니 새로운 차세대 엔진 만드는 게 예전에 했던 것보다 더 대단한 일이 아닌거 같단 생각이 들어서 완전히 꼴리는 일이 없음 -_- 그냥...

'응, 하면 재미는 있겠지... 근데 뭐 좀 더 커다란 성취감을 주는 일이 없을까?'

하는 생각이 더 강함 -_-; 아니면 그냥 좀더 쉬면 다시 꼴릴지도...... 아니면 민근님 따라 우즈벡에 가서 게임회사라도 차려야할까....

시그래프 발표일정이 잡혔습니다 훗훗훗훗...

시그래프 2012에서 스크린 스페이스 데칼 기법을 발표하게 되었습니다. 월요일날 발표한다고 나왔네요... 후후후후..... 이 링크에서 젤 밑을 보시면 제 이름이 보입니다. 후후후후.. 네 본명이 포프입니다 -_-+

신나긴 하는데.. 지금 어디에 몸을 담고 있지 않아서 모든 비용을 제가 내야한다는게.. 엄하군요... 끄응 -_-;

Unity, 널 사랑하지만 너의 UV만은 용납할 수 없다

새 블로그로 옮겼습니다

북미취업 가이드북, 분야 1위를 달리고 있습니다.

지금 막 인터파크에 들어가보니.... 순위가 멋지군요.

• 자기계발서 순위: 1 위
• 이북 전체 순위: 2 위
• 인터파크 전체순위: 62 위

게임개발자 랩소디 3화에 출현했습니다. 훗~

민근님이 진행하시는 게임개발자 랩소디 3화에 출현했습니다. 라디오 방송이라 잘생긴 얼굴이 나올 순 없지만.... 그래도 시작부터 낯간지럽게 잘했습니다.. -_- 훗훗훗....

들으시려면 여기를 눌러주세요.

사진은 민근님의 팟캐스트 대표사진입니다. 절대 제가 그린게 아닙니다. -_-

북미취업 가이드북 이제 인터파크에서도 구매하실수 있습니다.

인터파크 보니까 올라왔네요.


여기를 누르시면 인터파크 페이지로 갑니다. 룰루랄라~

위대한 게임의 탄생 2 에 제 인터뷰가 실렸습니다.

방금 이 책의 편저자이신 박일님이 보내주신 책을 받았습니다.

197페이지엔 제 인터뷰도 실려있습니다.... ^_^/

저는 공짜로 얻었으니.... 여러분들은 사서 보세요.. 훗훗 -_-;

7월 10~20일날 쉐이더 책 나옵니다.

원래 한빛 미디어에 5월 출간예정으로 올라와서 기대하고 있었는데 안나와서 확인해보니 일이 많아서 좀 연기되었답니다. 이번엔 7월 10일에 반드시 출판할거라고 하시니 기대해봅시다.

계속 책 출판이 늦어져서 죄송합니다. 생각보다 많이 늦어졌네요. 좀 일찍 나왔으면 다음학기 교재가 될 가능성도 있었을텐데 저도 개인적으로 좀 아쉽습니다.

그래도 더 좋은 책이 나오기 위해 이러는 거라고 생각하고 긍정적으로 기다려주시기 바랍니다. ^_^

업데이트(2012-06-12):
출판사에서 온 이멜을 다시 읽어보니 7/10일 출간.. 7/11일~20일 인쇄배본.. 이라고 하는데.. 이게 무슨 차이인지 헷갈 -_-;

OpenCL에서 OUT_OF_RESOURCE 또는 CL_MEM_OBJECT_ALLOCATION_FAILURE 에러가 날 때

현재 개발중인 애플리케이션에서 OpenCL을 써서 속도를 높이고 있는데...

clEnqueueNDRangeKernel() 함수를 호출할때 갑자기 CL_MEM_OBJECT_ALLOCATION_FAILURE 에러가 나지 않나 나중엔 OUT_OF_RESOURCE 에러도 나고... 그래서 니가 삽질/해결한 방법을 잠시 노트로 남김.

1. 우선 실제 allocation을 하는 메모리가 얼마나 되는지 확인
실제 사용하고 있는 cl_mem 버퍼는 다 더해봐야 3MB 이하. OpenCL 최소 global 메모리 지원이 128MB 이니. 아무 문제가 없음.

2. Notification 함수
이리저리 뒤지다보니 에러가 날 때 notification 하는 함수를 안붙여놨음. 이 함수를 구현해서 컨텍스트를 생성할때 함수포인터를 전달. 그러니 clEnqueueWriteBuffer() 를 호출할때도 CL_MEM_OBJECT_ALLOCATION_FAILURE 발생하는걸 확인. 그래도 여전히 문제 해결엔 도움이 안됨.

3. CPU OpenCL 디바이스로 실행
인텔 CPU에서 아무 문제없이 실행됨... NVidia GPU에서 돌릴때만 문제가 생김... 순간 드라이버 문제가 아닌가 싶어 최신 드라이버 설치.. 아무 문제 없음

4. 메모리 stomp 확인
코드를 잘 살펴보니 allocation한 local memory의 범위를 넘어서 쓰기/읽기를 하고 있었음... 이걸 제거하니 아무 문제 없이 실행.. 드디어 고쳤다.. 만세..!




오늘의 교훈: OpenCL에서 CL_MEM_OBJECT_ALLOCATION_FAILURE 따위의 에러가 나온다면 메모리 stomp를 확인해보세요.

북미취업 가이드 책이 나왔습니다.

몇년전에 블로그를 통해 연재했던 북미취업 가이드가 드디어 전자책으로 책이 나왔습니다. 몇 년이 지난 만큼 블로그에 있던 내용을 조금 다듬고 내용도 조금 업데이트했습니다. 편집 및 출판은 연두미디어에서 맡아 주었습니다. 현재 애플 아이북스용으로 올라왔고 기타 국내 온라인 출판사 홈피에도 곧 올라온다 합니다. 전자책 구매 방법은 연두미디어의 홈페이지를 참조하시기 바랍니다.

P4SandBox를 3주간 사용해본 소감

몇주전에 말씀드린 것처럼 P4SandBox를 한 3주 사용했습니다. 매우 만족스럽네요. private repo가 꽤 좋아요. 새로운 스트림(브랜치라고 생각하세요)를 만들고 여러 스트림 사이에서 switch하는것도 빠르구요. (뭐 내부적으로 당연히 Perforce의 shelve 기능을 이용하죠). 스트림을 그냥 브랜치 + 자동 shelving이라고 생각하시면 될 거 같아요.

내가 찾은 버그 하나:

• 스트림안에서 손수(manually) shelving을 해주면 이걸 다시 unshelve 할수가 없네요 -_-; 따라서 현재 저는 스트림 안에서 아예 manual shelving을 안합니다. 작업중이던걸 shelving하고 다른 작업을 해야 한다면 그냥 간단히 새로운 스트림을 추가하고 말죠. 참고로 이 버그는 P4SandBox에서만 발생하는 버그입니다. 퍼포스의 전통적인 방법은 중앙관리방식을 쓰면 이런 문제는 없어요.

한가지 짜증나는 점:

• copy 또는 merge(Git 에서 push/pull의 개념입니다)를 할 때 change 히스토리를 자동으로 넣어주지 않네요. Perforce측 말로는 다음 버전에 이 기능을 구현한답니다.

민근님이 진행하시는 게임개발자 팟캐스트

톡톡한 입담으로 저에게 듬뿍 사랑을 받고 계시는(네.. 여친이 없으세요 -_-) 민근님이 새로 게임개발자 팟캐스트를 시작하셨습니다. 1편(상)을 들어봤는데 역시 재밌네요... 한번 꼭 들어보세요.. 저도 앞으로 종종 듣게 될 거 같습니다... ^^

팟캐스트 링크는 민근님의 블로그 포스트에 잘 소개되어 있습니다.

DX9/11 에서 COM 스마트 포인터 쓰기?

원래 쓰려고 했던 글...
최근에 만들고 있는 real-time 소프트웨어가 있는데(게임은 아님), 여기에 사용할 매우 얇은(thin) DX9 렌더링 엔진을 만들었었습니다. 근데 이게 OpenCL과 같이 사용하기가 만만치 않아서 이걸 다시 DX11로 포팅을 했죠. 이 소프트웨어는 윈도우 PC용으로 제작중인데, 좀 편하더군요. 지난 6+ 년동안 다뤘던 하드웨어인 현세대 콘솔 게임기(엑박 360, 플스3 등) 보다훨씬 파워풀한 하드웨어에서 도니까요.

이번에 코딩을 하다가 깨달은게... Direct3D는 COM인데 게임 렌더링 엔진에서 COM 스마트 포인터를 쓰는걸 본적이 없더라구요. 제작에 참여한 게임 수만해도 15개가 넘고, 다뤄본 게임엔진만도 7개가 넘는데 말이죠. 아마도 성능이 딸릴 걸 걱정해서 그러는거 같은데 이젠 그냥 기우가 아닌가 하고 생각을 하게 되었습니다. 아무래도 5년전 하고만 비교해도 컴퓨터 성능이 엄청나게 떳으니까요. 그리고 최근 몇 년 동안의 동향이 게임코드에서 스마트 포인터를 많이 사용하는 거였거든요. (물론 렌더링 엔진은 아직도 예외인듯..) 그리고 게임코드에서 사용하는 스마트 포인터때문에 성능저하가 일어나는 걸 본 것도 몇 번 안되구요. (뭐 생기더라도 고치는 것도 어렵지 않았음). 그래서 'D3D 오브젝트에서 COM 스마트 포인터를 써도 상관 없을 것 같은데...?' 라는 생각이 듭니다. 혹시 상용게임에서 이거 써보신 분 계신가요? 그렇다면 어땠는지 좀 알려주시죠 ^_^?

그래도 뭔가 유용한 정보를 써야....
이렇게 글을 끝내기엔 뭔가 남에게 도움이 되지 않은 거 같지 않아 죄책감이 듭니다...(이렇게 허접한 글을 쓰시는 분들도 있지만... 전 양심에 걸림... -_-). 그래서 DX9하고 DX11 에서 COM 스마트 포인터를 쓰는 법을 소개하기로.... 쿨럭쿨럭... -_-

스마트 포인터를 안쓴다면?
D3D를 비롯한 COM 개체의 라이프사이클은 참조카운터(reference counter)에 따라 좌우됩니다. 예를 들어 CreateTexture() 함수를 통해 생성한 텍스처는 참조카운터가 1입니다. 이제 D3D가 내부적으로 이 텍스처를 사용할 떄마다 참조카운터를 1씩 증가시켰다가 사용을 끝마치면 1씩 감소시키죠. 프로그래머가 일일이 참조카운터를 증가/감소시킬 수도 있습니다. AddRef()함수와 Release()함수를 통해서요. 나중에 이 텍스처가 더이상 필요없어서 지우고 싶을 때도 그냥 Release() 함수를 호출합니다. D3D 가 내부적으로 아직 이 텍스처를 이용하고 있을지도 모르니 delete를 호출해서 곧바로 지워버리면 안되지요. 참조카운터가 0으로 떨어지면 D3D가 알아서 지워줍니다.

따라서 렌더링 엔진의 destructor()를 보면 Release()를 호출해주는 코드가 꽤 많죠. 뭔가 귀찮아 보이죠? 네 -_-... 그래서 이걸 자동적으로 되게 하려는 시도가 COM 스마트 포인터입니다. (더 자세한건 구글형님께 물어보세요. -_-) 그럼 다음은 각 DX 버전별로 스마트 포인터를 쓰는 법을...

DX9:
DX9에서 스마트포인터 형을 선언하려면 d3d9.h를 인클루드 하기전에 comdef.h를 인클루드 하시면 됩니다.

#incldue <comdef.h> 
#include <d3d9.h>

이러면 모든 ID3D형에 대해 ~Ptr 접미사를 붙인 스마트 포인터가 선언됩니다. 이제 D3D 디바이스의 스마트 포인터를 선언하려면 이렇게 하면 되죠.

IDirect3DDevice9Ptr mDevice;

이제 이 스마트 포인터를 사용하는 건 그다지 어렵지 않습니다. 다른 스마트 포인터랑 비슷해요. 특별한 함정도 없죠. (DX11엔 함정이 있음 -_-)

DX11:
d3d11.h은 D3D 인터페이스마다 COM 스마트 포인터형을 선언하는 preprocessor 매크로가 없어요. 따라서 전 atlbase의 COM 스마트 포인터를 써야했답니다.

일단 atlbase.h를 인클루드 하시구요.

#include <atlbase.h>

이제 다음과 같이 일일이 스마트 포인터를 선언해주시면 됩니다.

CComPtr<ID3D11Device> mDevice;

사용법은 DX9의 COM 스마트 포인터와 비슷한데요.. 한가지 함정이 있죠. CComPtr<>의 속이 비어있지 않은데 주소를 구해오려면 assert가 발생합니다. 그리고 디렉트X를 사용해 보신 분이라면 얼마나 자주 포인터의 포인터(**)를 매개변수로 전달해줘야 하는지 아시죠? (렌더타겟 텍스처를 만들 때라던가가 아주 좋은 예죠.) 따라서 이런 상황이라면 & 연산자를 쓰기전에 우선 스마트 포인터의 속을 비워줘야 합니다. 간단히 nullptr를 대입해주면 되네요.

mRenderTarget = nullptr;

여기서 한가지 함정.... 사실 전 CComPtr<>의 detach() 함수가 nullptr를 대입해 주는 것과 똑같은 일을 하는 줄 알았거든요. 근데 아니더군요..... detach()를 호출하면 내부적으로 Release()를 호출하지 않은 채 그냥 포인터를 내던져요... 그래서 메모리 누수가 생기게 되죠 GPU상에.... 켕 -_-; detach() 쓰지 마시고 nullptr대입하세요.


자, 이정도면 그나마 쓸만한 정보를 제공해드린 듯 하니.. 전 이만 뱌뱌....


p.s. 오랜만에 글 쓴 포프였습니다. 물론 여전히 꽃미남 입니다 -_-;

[방명록 답변] 게임기획자가 UDK로 게임을 만드려면?

전에 써놨던 블로그글 "게임개발자 지망생님들, 질문에 답해드리겠습니다"에 장문의 질문이 달렸는데 거기에 답글을 달자니 너무 길어지는거 같아 아예 새 글로 올립니다.

제가 답변은 달지만 아무래도 기획쪽 질문이라 저보단 다른 현직 기획자분들이 좀 더 멋진 댓글을 달아주셨으면 합니다...

(불행히도 이번엔 저 잘난척 할 내용은 없군요.. 쳇 -_-)


질문:  UDK로 게임을 만들려고 하는 게임기획 지망생인데요...

안녕하세요 우선 포프님에게 감사의 말씀부터 드리겠습니다.
제가 옛날부터 가지고 있던 북미에 관한 많은 궁금증에 대해 개인의 경험과 함께 상세하게 써내려 풀어주신 것 정말 진심으로 감사 드립니다.

다만 제가 기획자를 꿈꾸는지라 프로그래밍이 중심인 글들에서는 제가 얻고 싶었던 정보를 얻기가 쉽지 않았습니다. 게다가 한국과 거리가 먼 곳이고 게임유형이 다르기 때문에 PC나 콘솔게임산업에 대해서도 기본적으로 원하는 능력이 각국마다 틀릴 것 같아 개인적으로 많은 궁금증을 가지고 질문을 하겠습니다.

제 소개가 늦었습니다만 우선 저는 한국의 직업전문학교를 다니는 학생이며 과는 게임기획과입니다.

최종적인 저의목표는 북미에서 전세계 사람들에게 시대가 변해도 불변하지 않는 사람의 의지나 감정을 담아내는 게임을 만들고 게임이 가지고 있는 기술들이 앞으로 어떻게 발전하고 다른 산업에 앞으로 어떻게 도움을 줄지 또 타 유형의 문화 콘텐트와 접목해가며 지향해 나가야 할 바를 알고 들으며 보고 논의해 가고 싶습니다.

온라인게임은 한국의 큰 특징인 시시각각 변모하는 유행을 축으로 하여 발 빠르게 소비자의 욕구를 지속적으로 충족시키는 장점을 조합한 성격을 지닌 유형으로 기존에 있던 유형들의 게임들과 크게 대비되며 잘은 모르지만 여러 해에 걸쳐 많은 성과를 일궈낸 걸로 압니다. 그러나 한국이라는 지역적 특성에도 불구하고 저는 온라인게임을 좋아하지도 잘하지도 않습니다. 어릴 적부터 팩을 꽂아 하는 비디오게임에 친숙해진 이유도 있겠지만 RPG이외의 장르는 시나리오의 존재가 눈에 띄게 부족하고 캐릭터의 존재의의가 희박했습니다. (단적으로 밖에는 모르지만 제 생각에는 다수의 인원이 모여서 하는 게임에서는 혼자 하는 게임 시나리오나 캐릭터의 비중에 비해 많이 희석되는 것 같습니다. 세계관을 토대로 시나리오나 캐릭터 존재의의를 궁금해하는 것이 게임 내나 공동의 목표가 아닌 타 진영을 이기는 것에 초점을 두고 이 효율성을 강조하기 때문으로 압니다.) 따라서 온라인은 게임으로서의 재미는 주어지지만 개인적으로 감명이나 감흥을 받기에는 힘들었습니다.

하지만 저희 학과는 철저히 온라인게임 중심의 수업입니다. 학생들이 팀을 이뤄 대략적인
온라인 게임 기획서를 만들고 특정 이용자 층을 공략하고 사람을 어떻게 모으고 유료화 콘텐트를 만들어 많은 이익을 창출해낼 것인가를 주 프로젝트로 삼고 있으니까요. 프로젝트마감이 최고조에 이르는 동안에는 학교에서 잠을 자서 완성하기도 합니다.

이런 연유로 PC게임이나 콘솔게임을 만들려는 저의 꿈이 너무나 멀게만 느껴져서 뭘 해야 될지 모르겠습니다.

그러던 와중 포프님께서 계속 언급하시던 중요한 항목인 게임을 만들어보라는 말을 듣고 게임을 만들려고 하는데요. UDK를 이용해 보려고 합니다.

여기서 질문이 있습니다.

첫 번째 질문으로
제가 개념이 부족해서 그러는데 엔진이 정확히 어디에 쓰이는지 잘 모르겠습니다. 게임개발에 핵심적인 것이라고 밖에는 인식을 못하는데요. 게임엔진이 가볍다거나, 무겁다는 의미를 모를 정도입니다. 엔진 시연 동영상을 보면 질감이라든지 물체의 양각을 두드러지게 하거나, 물리작용을 적용하거나, 광원을 조절하는 것으로 아는데 정확한 설명과 기획자들은 주로 엔진을 어디에 쓰는지 가르쳐주시면 감사하겠습니다.

두 번째 질문으로
저는 고등학교를 다닐 때 수리영역은 최하 점에 영어도 못합니다. 그림도 못 그리고 C언어를 배운 적도 없습니다. 따라서 코드, 스크립트, 함수 값의 개념도 모르는데요. 기껏 해본 건 콜 오브 듀티 개발자 콘솔을 아주 조금 이용해 본 것 밖에 없습니다.

show fps로 fps수치를 본다거나
sensitivity로 마우스 민감도를 조정하거나
cg_fov로 field of view값을 변환시킨다 정도로 말이죠

이런 제가 UDK를 만지기 전에 기본적으로 알고 배워야 할게 뭐가 있는지 어디에 쓰이는지 알고 싶습니다. 또 기획자가 가져야 될 지식도 될 수 있으면 알고 싶습니다.

끝으로 이렇게 긴 글 읽어 주셔서 감사합니다.
이 글을 쓰기까지 일주일이 넘게 생각과 시간이 걸렸네요. 개인적으로 많은 고민과 한숨을 섞어서 쓰게 됐습니다. 또한 쓰면서 많은 수정과 저 자신을 되돌아보는 계기가 됐습니다만 한편으론 주위에 온라인게임 개발에만 중점을 둬서 PC와 콘솔게임에 대한 정보를 얻기 힘들다는 게 슬프네요. 모쪼록 유익한 답변 부탁 드립니다.



답변:


일단 고통 잘 이해합니다. 본인이 하고 싶은게 있는데 정작 비싼 돈내고 다니는 학교에서 그걸 얻지 못하는 기분.... 기대가 클수록 실망도 크지요. 전 사실 게임개발 자체가 학교에서 배울수 있는거라 생각하는 놈이 아닌지라.. (전 독학팝니다.. -_-)   그래서 UDK로 뭔가를 만들어보겠다고 결정하신거 아주 잘하신거라 생각합니다. 정말 단순한 게임부터라도 만들면서 즐거움을 다시 찾으시길 바랍니다. (직접 손으로 주무르보면 재미를 느껴야 더 열심히 할 마음이 생기죠.)


그럼 마지막에 달아주신 질문에 대해 답을 제멋대로 답을 달아드리겠습니다. (위에도 밝혀놨듯이 전 기획자가 아니라 제 답에 모자른 부분이 많을겁니다. 다른 현직 기획자분들이 댓글로 좀 달아주시길 바래봅니다.)

1) 게임엔진의 역할
"게임엔진의 역할이 뭐냐?"라는 질문을 받으니 갑자기 머리속이 하애지는걸요? -_-; 사실 저도 이 놈의 정확한 정의가 뭔지는 잘 모릅니다. 원래의 개념은 자동차 엔진처럼 게임을 실행하는데 필요한 기술들을 모아놓은 거였던거 같은데(즉, 아티스트가 만든 모델들을 화면에 보여주거나, 사운드를 출력하거나.. 게임 이벤트를 관리하거나 등등...) 요즘은 그 외에 게임에 들어갈 리소스들을 만드는데 필요한 툴/에디터까지 총괄하는 개념이 되어가는거 같아요.

UDK나 Unity가 인기를 끄는 이유도 사실 엔진자체의 성능보다는 에디터가 좋아서거든요. 제가 언리얼 엔진 3을 제대로 써본지 한 7년되어놔서 이젠 잘 모르지만...  게임이벤트등을 노드로 연결하며 만들 수 있는 툴이 있는 걸로 알고 있고요. 스크립팅도 손수 하실 수 있을거에요. UDK보단 Unity쪽이 더 사용하긴 쉽습니다. UDK가 좀더 고성능이란 장점이 있죠. 그만큼 엔진이 무겁긴 하지만요...(하드웨어 사양이 높아야 한다는 뜻인듯...)

뭐, 다시 말씀드리면 저도 게임엔진의 정확한 정의를 아직 모릅니다. 그러면서도 제가 엔진 프로그래머인데.... 그냥 게임을 제작 및 실행하는데 필요한걸 무조건 만들어서 추가할 뿐이죠 -_-; 게임을 제작/실행하는데 필요한 기술들을 구현하는거죠 뭐. 뭐든간에 저 개인적으로는 어떤 걸 이해부터 하려고 노력한다면서 시간낭비하기 보다는, 직접 몸으로 체험하가면서 대충 감을 잡은 뒤 나중에 한발 물러서서 전반적인 걸 이해하는걸 선호합니다.

당장 조그만 게임부터 하나 만들려고 해보시면, 만들면서 "아 이건 어떻게 하지?" 하는 질문들이 수백만개 생길것이고 그것에 대한 해답을 찾아가면서 (구글 검색이면 왠만하면 다 나옵니다. 아님 UDK 웹사이트를 참조) 익히게 됩니다.

2) UDK를 만지기 전에 알아야 할 것
이 질문은 그냥 무시하겠습니다. '준비한 뒤에 뭘 만진다.' 라는 자세보다는 '일단 만지면서 뭐가 필요한지를 찾아낸다.'란 자세를 가지도록 하세요. 혼자 게임을 만드시려면 그냥 기획서만 작성하시기 보다는 맥스나 마야같은 아트 패키지도 약간 만지셔야 할거고 스크립팅도 약간 하셔야 할 겁니다. 반드시 그래야 한다는 것보다는 그래야 본인이 편합니다.

아무리 백날 '이런 이런 게임을 만들거니까 이 문서를 읽고 이렇게 만들어주세요.'라고 해봐야 그거 제대로 이해할 수 있는 사람 없습니다. 그게 바로 상용게임들도 실제 게임이 출시되고 게이머들이 플레이해본 뒤에야 제대로 평가를 할 수 있는 이유기도 하고요. '이렇게 이렇게 해주세요.'라고 말만하고 프로그래머가 (혹은 다른 개발자가) 그걸 만들어주기만 기다리는건 효율적이지도 않습니다 중간에 miscommunication 생길 가능성도 더 많죠. 남에게 의존하지 않고 본인 스스로 할 수 있는 일이 많아질수록 그만큼 본인의 정신건강에도 좋고 본인이 만들고자 하는데로 게임을 만들 수도 있습니다.

가끔 '다른 거 안하고 자기분야만 열심히 해도 된다' 라고 생각하시는 분들을 좀 봤는데.. 정말 아주 뛰어난 실력자 아닌 이상 별로 환영받지 못하는 분위깁니다. 회사 규모가 클수록 그렇죠. 다른 분야를 잘 이해하는 게 자기 분야에 대한 실력을 높이는 방법이기도 합니다. 크 ㄴ회사일 수록 다양한 사람들이 같이 일하니 서로의 업무에 대해 잘 이해해야만 팀 다이나믹이 좋아지죠. (저 스스로만 해도 프로그래밍 뿐만 아니라 온갖 프로그램 다 만질줄 압니다. 포토샵, 맥스, 마야 등은 기본이구요.. 기획자분들이 다루는 툴들도 필요하면 만지고 배웁니다.)


이 정도면 제가 달 수 있는만큼 답은 단듯 합니다. 다른 기획자분들의 멋진 댓글을 기다려보죠. 이제.

내가 수학점수를 60점 -> 100점으로 올린 방법

새 블로그로 옮겼습니다

내가 선택한 버전컨트롤 시스템(2012년 판)

작년에 영문 블로그에 제 개인적으로 사용하는 버전컨트롤 시스템은  Subversion이란 글을 올
렸었습니다. 근데 그 뒤에 Perforce에 두가지 변화가 생겨서 다시 한 번 생각을 하게되었지요. Perforce에 생긴 두가지 변화는 다음과 같습니다.

• P4SandBox란 이름의 새 기능
• 공짜버전의 한도가 20명 사용자, workspace 20개로 널럴해졌음

P4SandBox란 무엇인가?
이 새로운 기능이 Perforce 2012.1 에서 소개되었는데요. 이건 Git처럼 각 개인컴퓨터에서 local private 버전 컨트롤을 가능하게 해주는 기능입니다. 하지만 Git처럼 완전히 분산시스템은 아니고요. 중앙서버에 있는 depot을 개인 컴터 HDD에 mirror 복사를 해놓은 뒤 오프라인상태로 작업을 할 수 있게 해주는거지요. 그리고 나중에 중앙서버에 파일들을 checkin할 준비가 되면 그때까지 local 서버에 제출했었던 모든 파일들을 전부다 중앙서버에 올리는 겁니다. 또한 P4SandBox는 Stream이라는 게 있는데요. Git의 막강한 브랜치 시스템과 거의 비슷하게 작동하네요.

이 기능들에 대한 더 자세한 내용은 이 비디오를 참고하세요. 저보다 더 자세히 설명해 줍니다. ^_^

Background
게임업계에 대략 10년간 몸담았고 여러가지 오프소스 프로젝트를 주무르다보니 정말 다양한 버전컨트롤 시스템(VCS)를 만져봤답니다. 그냥 파일들을 손수 복사해주는 것부터 매우 값비싼 상용 프로그램 Perforce에 이르기 까지요.

제가 여태까지 집에서 써오던 버전 컨트롤 시스템은 Subversion이었습니다. 물론 더 나은 프로그램이 있다고 입에 침튀기시는 분들도 많았지만 그 분들이 맞다/틀리다곤 하지 않겠습니다. 제가 Subversion을 써왔던 이유는 (예전 블로그 글에도 밝혔듯이) 가장 간편하게 사용할수 있으면서도 제가 원하는 기능을 적당히 잘 지원하던 놈이었기 때문입니다. 하지만 내일부로 다시 Perforce로 돌아갈 계획입니다. 왜냐면 이제 Perforce가 더 제 필요를 잘 충족시켜 줄거거든요. 다음은 제가 개인프로젝트용으로 사용하는 VCS로부터 원하는 것과 시중에서 널리 사용되는 VCS들이 얼마나 그런 일을 잘 하는지를 목록으로 정리해논 것입니다.

윈도우즈 지원
전 MS빠입니다. 언제나 윈도우즈를 사용하지요. 게임 프로그래인 저로써는 사실 Linux를 사용할 필요를 못느낍니다. 운영체제를 하나만 사용할 수 있다면 그게 확실히 덜 골치거리겠지요?

• Git(-2): 사실 전 Git을 꽤나 선호합니다. 특히 브랜칭을 처리하는 거 보면 아주 침을 질질 흘리죠. 문제는 .... Git을 윈도우즈에서 돌리려면 좀 피곤하죠. 제가 아는 한은 Cygwin이나 msysgit을 설치하는 건데 Cygwin은 사실 Linux를 에뮬레이션 하는 것과 다르지 않고, Cygwin을 윈도우즈 PC에 설치하는게 그닥 달갑지 않습니다. msysgit은 그보단 윈도우즈에 설치하기 쉽지만 SSH도 따로 설정해줘야 하고..... 한마디로 그냥 마우스 클릭 한번만으로 윈도우즈에 Git을 설치할 방법이 없단 거지요. 따라서 MS빠인 저에게는 좀... no-no입니다.
• Perforce(+1): Perforce는 윈도우즈를 매우 잘 지원하죠. 윈도우즈용 서버/서비스 프로그램도 인스톨러를 통해 한번에 설치 가능합니다.
• Subversion(+2): 사실 이건 매우 큰 surprise였는데요. 그리고 그게 바로 제가 Subversion을 지금까지 이용해온 이유기도 하구요. VisualSVN Server이란 프로그램이 있는데 마우스 한번 클릭으로 윈도우즈에 Subversion을 깔아줍니다. 알아서 https 액세스도 잡아주고 사용자 관리 및 뭐니 모두 매우 간단한 GUI 툴에서 잡아줄수가 있습니다. Perforce를 설치하는 것보다도 쉬워요 -_-;

(가끔 있는 일이지만) 다중의 사용자 지원
개인 VCS는 사실 제 스스로의 코드의 히스토리를 저장하고 백업을 보관하는 용도이지만 가끔 제 친구들도 제 코드를 받아보게 할 일이 있지요. 절 도와준다거나 할때요. 따라서 여러명의 사용자를 지원할 수 있어야 편합니다.

• Git(+1): Git에서 여러 사용자 지원하는건 전혀 어렵지 않죠. 하지만 윈도우즈에서 각 사용자별로 액세스 컨트롤을 해주는 게 왕 짜증입니다.. 새로운 윈도우즈 사용자를 추가한 뒤, 각 사용자의 public키를 받아서 디렉토링 ㅔ넣어줘야 하죠.. 
• Perforce(+1): 작년까지인가 Perforce는 공짜에 한도가 있었죠. 다음 중에 한 조건에서만공짜였습니다. i) 2명의 사용자와 5 개의 클라이언트 워크스페이스 또는 ii) 사용자 제한 없이 1000개 파일까지만. 하지만 이제는 20명의 사용자와 20개의 클라이언트 워크스페이스까지가 공짜입니다. 파일 수의 제한은 없구요. 하지만 새로운 P4SandBox기능을 쓰려면 각 사용자별로 2개의 워크스페이스가 필요합니다. (하나는 중앙서버용 하나는 local 미러용). 그리고 각 컴퓨터별로 이렇게 해줘야 하니 보통 사용자가 2대의 컴퓨터를 쓴다고 가정하면 한사람이 4개의 워크스페이스를 잡아먹죠. 따라서 결국에 5명의 사용자만 제대로 지원할 수 있다는 건데... 제 개인 프로젝트용으로는 이정도면 매우 충분한거 같습니다. 따라서 예전에 줬던 -1점을 +1 점으로 바꿨습니다.
• Subversion(+2): 윈도우즈 지원 섹션에서 말씀드렸듯이 VisualSVN Server에서 GUI 툴을 통해 간단히 액세스 컨트롤을 할 수 있습니다. 너무너무 쉬워요~ 사용자 수 제한도 없고~  강추입니다.

비용
아무래도 공짜가 좋죠.. 공짜가 최고 -_-d

• Git(+1): 공짜
• Perforce(0): 특정 조건하에 공짜. 하지만 최근들에 그 제한이 완화되었음. 따라서 점수를 -1에서 0점으로 바꿨습니다.
• Subversion(+1): 역시 공짜

GUI 클라이언트
Perforce만큼 멋진 GUI 클라이언트가 없습니다. 사실 P4V 보단 P4Win이 좋았지만 P4Win은 더이상 안나오니.. 중얼중얼...P4V도 충분히 좋아요~  물론 GUI 클라이언트로 할 수 없는 일은 컴맨드 라인을 쓰지만 거의 대부분 GUI 클라이언트를 사용하는 것이 훨씬 빠르고 훨씬 쉽더라구요.

• Git(-1): 아직 공짜이면서도 쓸만한 GUI 클라이언트를 못찾았습니다. 몇개 개발중인건 봤는데 아직 맘놓고 쓸만큼 자리잡은 놈들이 없어요. 그나마 TortoiseGit이 좀 쓸만하지만 P4V처럼 진정한 GUI클라이언트가 아니지요.
• Perforce(+2): P4Win은 죽여주고, P4V도 매우 좋습니다. ㄱㄱㅑ~
• Subversion(+1): SmartSVN이란 프로그램을 한동안 써왔습니다. 프로 버전을 사지 않으면 좀 기능에 제한이 있지만 사실 공짜버전만으로도 충분히 쓸수있습니다. 공짜 버전에서 제공하지 않는 기능이 있다면 그냥 TortoiseSVN으로 해주면 되고, 그것도 안되면 컴맨드라인을 쓰면 되죠. 하지만 거의 SmartSVN만 쓰시고 사실 겁니다... ㅎㅎ

브랜칭

브랜칭... 꽤 멋진 놈이죠... 전 이거 사랑합니다. 코드가지고 장난칠 때(실험적인걸 할 때 라고 읽어주십쇼 -_-) 기존 코드에 깽판치고 싶지 않다면 이만한 놈이 없죠.

• Git(+2): Gt의 막강한 브랜칭 지원 매우 사랑스럽습니다. 다른 디렉토리로 파일을 복사할 필요가 없죠. 따라서 코드에서 파일 경로를 참조하는걸 바꿔줄 필요조차 없습니다. 예를들어 Awesome이란 이름의 라이브러리가 있는데 이 라이브러리를 브랜칭을 하고 싶다고 해보죠. Git에서는 그냥 다른 브랜치로 switch한 뒤 코드만 빌드하면 됩니다. 하지만 다른 소스컨트롤 시스템에서는 이 라이브러리를 다른 디렉토리로 복사해야하니 코드에서 라이브러리의 경로까지 다시 고쳐줘야 하죠...
• Perforce(+2): 바로 위 Git에서 말씀드렸듯이 다른 폴더로 브랜칭을 해야하는 거 참 귀찮습니다. 그리고 Perforce는 중앙관리시스템이다 보니 그 수많은 파일들을 브랜칭 하는것도 되게 느리죠. 네트워크 스피드가 아무래도 HDD속도보단 느리니까요. 하.지.만. 이제 세상이 바뀌었습니다. P4SandBox를 이용하면 브랜칭이 Git의 브랜칭과 거의 같아집니다. 샌드박스안에서 모든게 이뤄지거든요. 중앙서버에 접속할 필요조차 없이... 따라서 점수를 -2에서 +2로 바꿨습니다.
• Subversion(-1): 속도는 빠릅니다. 하지만 다른 디렉토리로 브랜칭 해야하는거... 흠냐.. 여전히 맘에 안듭니다.

최종 점수

점수를 다 더해보니 이렇게 나옵니다.

• Git: +1
• Perforce: +6.  Oh there it is. Winner, winner, chicken dinner
• Subversion: +5. 

다시 한번 말씀드리는데 이건 제 개인적인 용도에 맞게 산출해낸 점수입니다. 대형 게임회사용이 아니에요. 따라서 여기다 "하지만 Perforce가 사용자 200명도 쉽게 지원하니 최고야!" 따위의 답글을 남기신다면 잠드시기 전에 이 비디오를 2시간동안 보게 만들겠습니다. -_-;

시그래프 2012 발표자로 뽑혔습니다

시그래프...... 애니메이션 영화, 게임을 망라하고 전세계 최고의 컴퓨터 그래픽 축제인데 올해 발표자로 뽑혔습니다. 사실 발표자로 뽑힌 이야기 자체가 더 웃기다죠...

시그래프 발표신청 마감 바로 전일날 친한 회사동료인 Daniel 박사님과 Vladmir하고 술을 마시고 있었죠. Daniel이

"내일 오후 10시가 마감이니 니 Decal 기법을 발표신청 해보는게 어때?"

라고 해서... 생각해보니 나쁜 생각이 아닌거 같아서... 그러겠다고 했습니다. 뭐 오후 10시 마감이니 회사에서 쓸 시간이 충분할 듯 해서....과음을 했죠 -_-;; 부어라 마셔라~

그리고 담날 오전 11시쯤 출근을 했는데.. 아뿔사... 마감이 오후 2시더군요.. -_-; (아마 오후 10시는 영국시간이었던듯....) 그래서... 점심도 다른 동료보고 좀 사다가 배달해달라고 하고... 그때부터 졸 3시간 한장짜리 abstract(논문에 보면 한장짜리 요약문?)써서 제출을 마쳤습니다.. 마감 시간 30초전에 업로드 완료.. ㅎㅎ

근데 발표자로 선택이 되었네요 -_-;; (물론 잘난척입니다. 그럼요 그걸 빼면 제가 시체죠.. 3시간만에 써도 선정되는 천재....)

근데 지금 렐릭에서 퇴사한 상태라... 발표해도 된다는 허락을 다시 또 받아야 했어요.. 뭐 이젠 그것도 마물 되었으니 가서 발표합니다.. 8월달에 LA에서 한다는군요.... (전에 북미취업 보시던 분 중 한분이 LA오면 이쁜 누님"들"을 소개시켜준다 하셨는데....... 중얼중얼...)

사실 발표신청을 하지도 않았던 이유중 하나가... 저희 회사에서 일하던 팀장중 하나가 시그래프의 검토위원인데... 작년에 이 기법을 가지고 나가겠다고 하니 이 정도 기법은 시그래프에서 발표하기엔 수준이 딸린다고 했었거든요. 검토위원이 그정도 말을 하니 그렇겠거니 하고 믿었었는데.... 2011년에 다른 회사에서 발표한 자료를 보니 제 발표자료가 더 나은거 같아서 그냥 추진 -_-

뭐든간에 마지막으로 하고 싶은 말...

내가 전공 파괴자가 된 이유 (방명록 답변)

방명록에 톨스토이님이 올려주신 질문에 답글을 달다가.... 너무 길어져서 그냥 블로그 포스트로 만듭니다. (잘난척 할 수 있는 기회가 생겨서 자랑하는 것도 맞습니다. 질문에서 밑줄친 곳를 봐주세요.... 두번.. 아니... 세번 봐주세요..... -_-;;)


질문: (툴스토이)

음...몇달전 정도부터 쭉 읽어보다가 질문올립니다.
뭐... 기술 능력적인 부분보다는, 인생새내기로서 인생선배님께 미래에대한 질문정도 몇 해볼까 하는데요...
특히, 포프님께서는 원래 전공이 다르다고 들어서 질문을 해봅니다.
저도 막연하게 게임쪽을 정말 제가 하고싶으면서 즐길 수 있는 분야라고 생각하면서 혼자
포프님 강의 열심히 해보긴 하는데요... 정말 갈팡질팡 합니다. 전공을 살리는것이
지금 나로서는 더 현명하다고 생각되는 한편, 어릴 적 부터 게임분야를 만들면 즐기면서
재밌게 일 할 수 있다고 생각하는데, 잘하는것과 하고싶은 것은 차이가 있잖아요... 저에겐 재능이 없어보여요:'( 혹시 포프님께서는 게임만드시는 것을 잘해서(이해가 빠르시다거나 응용력이 좋다거나...)인가요 아니면 정말 하고싶어했던 일이어서 정하신건가요? 아니면 재능도 뛰어나고 정말 가슴뛰는 일이 게임분야 이었던 것인가요..? 포프님은 천재에다가 노력까지 하셨으니...(부러워ㅠㅠㅠㅠ!!) 또, 요즘은 전공파괴자가 정말 많은데 그런분들이 많은 분야에서 막대한 영향력을 끼친다고 생각합니다. (이를테면 안철수 교수님이라던지...) 포프님도 제 생각엔 이러한 분들중 한분 이라고 생각하는데요... 혹시 없으시겠지만 전공을 살리지 못한부분을 후회해보신적이 있는지요? 제가 갈팡질팡 해서 질문드립니다...
게임제작에 대해 노력을 해도 갈길이 멀고 조금 막연한 상태에 있기에 마지막으로 여쭤볼게요, 혹시 게임제작에서 정말 아끼는 게임은 무엇인가요? 또 그 게임을 제작하실때 즐거웠던 부분이 있다면 그러지 않은 부분도 당연히 있을건데... 힘들었던 부분도 말씀해주세요... 좀 더 냉철하게 제 인생에 대해 고려해봐야 할 것 같아서요...

주저리주저리 문맥상 이상하게 급하게 썻는데 그런부분은 양해해주세요. (실력부터 외모까지 완벽하시니까ㅠㅠ)하하...

답변:

게임을 만들게 된 계기는 사실 만드는게 재밌어서 였어요. 이것만큼 재밌는 일이 없더라고요. 근데 사실 제가 게임을 많이 하는 편은 아니거든요. 그런데도 게임 프로그래밍은 언제나 재밌었어요. 지금와 생각해보면 이 일이 두뇌를 엄청 요구하는 어려운 일이고, 또 같은 일을 반복하기보다는 언제나 새로운걸 하게 되서 그런게 아닐까 싶어요. 제가 어떤 성취감에 희열을 느끼는 기간이 길지 않거든요(한 1~2주?)

다른 일을 하면 금새 지루해 지더라구요. 따라서 제가 정말 하고 싶은 일이어서 했다는게 맞죠. 그럼 제가 이쪽에 재능이 있었을까요? 전혀 없진 않았던거 같아요. 어릴때부터 좀 논리적이고 디테일에 강했으니까요. 근데 어릴때부터 제가 프로그래밍쪽에 재능이 있다고 봐준 사람은 하나도 없는거보니 그렇게 주목할만한 재능도 아니었다고 생각해요. (사실 뭐에 재능있단 이야기 들은건 유치원 때 피아노에 재능있단 이야기 들은게 전부인듯..... 근데 지금 졸 못치는거 보면 -_-;;;;)

일례로 제가 처음 컴퓨터 프로그래밍이란걸 해보게 된게 초등학교 4학년때쯤에 학교에서 GW-BASIC을 배운 때였거든요. 거기서도 그냥 겨우 따라가는 거였지 크게 두각을 나타낸적은 없어요. 오히려 저보다는 다른 학우들이 잘했죠. 그 후 중학교 때부터 취미로 게임개발을 시작할 때도 저보다는 다른 프로그래머가 훨씬 프로그래밍을 잘했어요. 전 오히려 그 친구에게 배우는 수준이었죠... 하지만 이 때부터도 전 언제나 거만함을 잃지 않았어요. '내가 노력하면 최고가 될 수 있다.'라는 거만함이죠. 그리고 그게 단순한 거만함이 아니란 걸 증명하기 위해 언제나 노력해 온 거 같구요. (지금은 제가 그 친구보다 프로그래밍 수백배 잘해요. ^^) 하지만 아직도 전 제가 최고라고 생각하지 않는 다는게 또 재밌는거죠. 그리고 지금부터 몇십년이 지나더라도 '아, 이제 내가 최고구나.'라고 생각하는 날은 오지 않을 거 같아요. 사실 제가 걱정하는 건 최고가 못되는 것보다, 뒤돌아 봤을 때 6개월전보다 발전하지 않은 제 모습을 발견하는 거거든요.

전 한번도 천재란 이야긴 들은적이 없어요. 요즘들어 제가 혼자 사람들 세뇌시켜 놓은거지 -_-;;; 노력으로 왠만한 천재들은 다 누를 수 있어요. 단 천재인데도 저만큼 노력하는 사람들은 못누르죠. 그런 천재는 매우 극소수에요. (그런 사람들이 노벨상 받는 거겠지요. -_- ) 저희 가족에서도 전 멍청하다고 구박 많이 받았어요. 언어 때는 것도 너무 느렸고... 암기력도 약하고... 단순 수리(덧셈 뺄셈 곱셈) 속도도 집에서 젤 딸려요. 그런데도 학업쪽으로 성취한 건 제가 젤 뛰어나죠.

제가 학벌도 좋고 이것저것 적당히 잘하는 게 많아서 재능을 타고 낫다고 생각하시는 분들이 계신 것 같아요. 근데 제가 이걸 다 이룰수 있었던 이유는 재능보다는 진득하게 노력한 영향이 커요. 공부만 해도 제가 연세대를 가기로 결정한 게 중학교때거든요. 그 때 사람들이 엄청 비웃었어요. 제가 반에서 50명중에 등수가 한 30등되었거든요. 중학교때 수학도 너무 못해서 수학은 5~60점 받었구요. 근데 연세대를 가고 싶었고(이유는 모름 -_-) 간다고 했으니 중학교 졸업하고 공부를 시작했죠. 그래서 고3졸업할땐 전교 10등에 수학은 평균 98~9점이었어요. 그것도 8학군에서요 -_-; 그 당시 게임개발도 병행했던 때인데.. 사실 그럴 수 있었던 이유는 공부/농구/게임개발 외엔 다른걸 전혀 한게 없어서에요. 한마디로 몇가지만 몰아하는걸 잘했죠. 이것저것 다 조금씩 하는 것보다...

근데 제 전공이었던 법대 성적은 형편이 없어요. 한마디로 별로 재미가 없으니 공부보단 괜히 다른거에 시간을 낭비한거죠. 그래도 좋은대학 졸업한 덕에 좋은 기회는 좀 있었어요. 사고만 안치면 5년안에 은행장 시켜준다는 제의도 받아 봤었구요. 사실 한국에 머물렀으면 지금쯤 돈은 더 벌거 같아요. 주변을 둘러보니  계속 사법고시 공부했으면 붙었을것도 같고.. 못붙었어도 은행장이 되지 않았을까? 하는 생각이 들죠. 그래도 후회는 없어요. 제가 즐기지 않는 일을 하면서 돈을 엄청 버는것보단... 제가 즐기는 일을 더 잘하면서 돈도 버는게 좋아요. 하지만 문제는... "난 내가 좋아하는거 하면서도 너네보다 더 성공했다!"라고 보여주고 싶은 맘이 강하거든요. 명예욕이라고 하나요? "인생에 실패했으니 괜히 자기 좋아하는 일을 하는 거라고 구라치면서 현실도피하는군."이란 소릴 듣기 싫어서요.

아직도 이야기하고 지내는 법대 동기들도 몇 있어요. 판사도 있고 검사도 있고 변호사도 있고 여전히 고시생도 있고... 전 사실 그 친구들이 참 대견해 보이는게... 그 지루한 공부를 잘 참고해서 성공했다는 건데.. 그 친구들은 저를 대견해 하더라구요. 하고 싶은일 하며 성공했다고... 그것도 딴나라 가서 바닥부터 기어서.... 그리고 즐겁게 살아서 세상에 안찌든거 같다고....

하지만 언제나 순탄한건 아니었어요. 제가 써놨던 북미취업 가이드에서 제 이야기 써놓은 거 보면 아시겠지만 제가 정말 '다시 게임만들어야겠다'라고 맘 먹은 뒤 실제로 제대로 게임 프로그래머로 자리잡기 까지 걸린 기간이 한 4~5년 되거든요. 그 동안 불확실한 미래에 대한 걱정때문에 맘고생이 많았어요. 주변에서 사람들이 '그건 해도 안돼'라고 말할 때마다 '저 사람들 말이 맞는게 아닐까?'하는 생각도 많이 해봤구요. 컴터서적 번역일 할 때도 '포프님이 이 책 번역하시기엔 프로그래밍 실력이 좀 모자르신 거 같아서 못드리겠어요'라는 말도 들었어요. ㅎㅎ

당연히 직업으로 게임개발하면서도 가끔 정치하는 애들 때문에 성질나는 경우도 있었고.. 회사가 개판인 경우도 있었고요. 그리 많진 않았지만 불필요한 야근을 하는 경우도 간간히 있기도 했고요...

그래도 제가 버텼던 이유를 말씀해 드릴께요.

전 고등학교 때 열심히 다른 학우들과 경쟁해서 더 좋은 점수 받고 대학만 가면 모든게 끝나는줄 알았어요. 근데 그게 아니더라구요. 몇년이 지나니 고시준비를 하고 있더라구요. 이렇게 열심히 다른 고시생들과 경쟁해서 더 좋은 점수로 사법고시만 패스하면 인생이 풀릴줄 알았죠. 근데 고시공부를 몇년하다보니 그게 아니란걸 깨달았어요. 고시패스하면 사법연수원에 들어가죠. 또 거기서 2년 열심히 경쟁해야 판검사 임용을 받을 수 있어요. 그리고 판검사가 된 이후에도 또 열심히 경쟁을 해야 직위도 올라가고 나중에 변호사로 나와도 또 열심히 경쟁해야 성공하는 거더라고요.

그러고 보니 인생이란거 자체가 끝없는 경쟁이더라구요. 뭔 일을 하기로 맘 먹어도 결국엔 경쟁이에요... 매일 발전하는게 없이 도태하면 그대로 실패하는... 그래서 내 자리를 지키려면 매일같이 경쟁해야 하는 챗바퀴.... 그래서 결정했어요.. 어차피 평생 경쟁하고 살아야 한다면 나 좋아하는걸로 경쟁하고 살겠다고. 그러면서 즐기겠다고... 또 즐겨야 더 열심히 노력할거고 그래야 더 성공할거라고... 그래서 저 하고 싶은 일을 고수했고... 후회는 없답니다.

제 말에 동의하시면 하고 싶은 일 하세요. 단 좀 거만해지시고... 그 거만함이 구라가 아니란걸 보여주기 위해 죽어라 하세요. -_-;

게임개발자 지망생님들, 질문에 답해드리겠습니다

안녕하세요. 이젠 하도 들어서 꽃미남이란 별명이 좀 질릴까 하다가도 여전히 부정할 수 없는 현실임이 안타까운 여전히 꽃미남 게임 프로그래머 포프입니다. (제가 태어나서 써 본 것 중 가장 긴 문장입니다. 뿌듯합니다.... -_-)

이제 본문 입니다... -_-

요즘 나름 바빠졌습니다

개인 블로그에 북미취업 가이드와 쉐이더 입문 강좌를 연재하고, 게임개발포에버를 시작한 후로 한국에서 이런저런 문의를 해오시는 분들이 상당히 많으십니다. 현직 게임개발자분들도 계시고 게임개발자 지망생분들도 계시지요. 저도 답변해드리면서 배우는 점도 많고 새로 깨닫는 것도 많아서 여태까지 모든 분께 열심히 답을 해드렸습니다만...

하지만 가끔 당혹스러운 질문이....

사실 가끔 너무나 광범위한 질문을 해오시는 분들에게는 답을 해드리기가 참 어렵습니다. 보통 현직 개발자분들 보다는 지망생 분들이 좀 이런 경항이 강하지요. 예를 들어..

"게임개발자가 되는게 제 인생의 꿈입니다. 어떻게 해야 게임개발자가 될 수 있죠?"

이런 질문을 볼 때마다 솔직히 당혹스럽습니다. 제가 영미권에서도 학생들의 질문도 많이 받는 편인데 이런 질문을 해오는 사람들이 거의 없었거든요. 그래서 첨엔 정말 많이 당혹스러웠죠. (물론 아직도 많이 당혹스럽습니다.) 뭐든간에 이렇게 질문이 시작되면보통 8~90프로는 다음과 같이 마무리 됩니다.

포프: "게임을 만들어는 보셨어요?"
지망생: "아뇨. 아직 만드는 법을 안배웠어요. 아직 대학을 안가서요.(아니면 그와 유사한 이유들...)"
포프: "학교에서 배운다고 게임개발자 되는거 아니에요. 일단 게임부터 만드세요. (그리고 이런저런 리소스들을 알려준다)"

현직 개발자분이시라면 다들 한번 쯤은 지망생들과 이런 대화를 해보셨을거고, 그리고 실력이 너무나 출중하신 많은 분들이 더 이상 이런 질문에 답변을 해주지 않으십니다. 왜 그럴까요? 이런 질문 하시는 분들 중의 상당히 대다수가 결국 게임개발자가 안되고 현직 개발자 분들은 이런 분들의 개인비서가 되서 게임제작 자료나 찾아주는 일을 해주는데 질렸기 때문이지요. 한마디로 더이상 이용당하고 싶지 않으신 겁니다.

게임개발자가 되려면 게임을 만드세요

저도 한 때 게임개발자가 되고 싶어하던 어린이었던 때가 있고, 잠시 게임개발하다가 법대생이 되서 외도한뒤에 다시 게임계로 돌아오려고 나름 고생한 놈으로써 제 경험담을 말하자면.....

제가 "난 게임을 만들꺼야"라고 꿈을 꾸고 살던 때에 만났던 친구들이 꽤 있습니다. 저랑 비슷한 꿈을 가진 친구들이었지요. 하지만 정작 말만하고 이런저런 핑계 실제 허접한 거 하나라도 만들지 않은 친구들, 또는 그냥 관련학과만 가서 졸업한 친구들 중에 게임개발자 된 친구들이 없습니다. 다들 게임을 만드는게 인생의 꿈이라고 했던 친구들인데.... 네... 없습니다.

이건 사실 매우 당연한 이친데 왜 이해를 못하시는 분들이 있으신지 모르겠습니다. 소설가가 되는게 인생의 꿈인데 어릴 때부터 글을 한번도 안써본 학생이 있을까요? 단 남의 소설은 많이 읽었지요. 춤추고 노래하는 가수가 되고 싶은데 어릴 때부터 춤 안추고 노래 안해본 학생이 있을까요? 물론 TV에서 가수들 노래하고 춤추는건 많이 봤지요. 야구선수가 되고 싶은데 어릴 때부터 한번도 농구를 안해본 학생이 있을까요? 물론 프로 야구선수들이 경기하는건 많이 봤지요.

이쯤되면 대충 제가 하려는 말이 무엇인지 아실겁니다. 정말 게임을 만드는 게 인생의 꿈이고 정말 이걸 안하면 죽는다고 믿고 계신데 아직 만들어본 게임(또는 그와 유사한게) 없다면 한 95프로는 그냥 세뇌당하셨거나 자기최면 거신겁니다. (물론 정말 사정이 있어서 못하신 분들이 한 5프로 있다고 해드리지요. 근데 다들 본인이 5프로 안에 든다고 우기시면.... 못써요.....) 뭐가되었든 간에 전 이런 분들에게도 답변을 최대한 한다고 해왔는데 사실 마음이 무거웠습니다.

"이렇게 이렇게.. 게임을 우선 만들어보세요.(또는 그림을 그려보세요. 또는 게임 아이디어를 정리해보세요 등등)"

라고 제가 드리는 답변은 말은 사실...

"그렇게라도 안하시면 가망성이 좀 많이 없어보여요."

라는 뜻이거든요. 물론 제 판단도 가끔 틀립니다. 틀릴땐 틀렸다고 인정도 하고요. 근데 거의 십중팔구는 제 판단이 맞습니다.

위에서 영미권 학생들로부터도 질문을 많이 받는다고 말씀을 드렸었습니다. 근데 한가지 다른 점은 영미권 학생들의 질문이 매우 구체적이라는 겁니다. 보통 자기 스스로 뭔가 만들어보려고 깨작여봤고 거기서 막히는 것들에 대한 질문.. 혹은 더 나은 방법이 없는지 조언을 구하는 질문 등이 대부분입니다. (물론 게임업계의 근무여건이 대해 묻는 사람들도 있긴 합니다.) 이런 질문에 대답을 할 때는 정말 그 학생에게 뭔가 큰 힘이 되는거 같아 제 마음도 뿌듯합니다. 한국분들 중에도 이렇게 뿌듯한 질문을 해오시는 분들이 있는데 안그런 분들이 좀 너무 많습니다. 현재론....

게임개발자 지망생님들... 질문하시려면요...

언제나 그렇듯이 또 주저리 주저리 말만 많이 썼습니다. 제가 사실 하고픈 말은 이겁니다.

1. 전 아직도 게임개발자가 될 꿈을 꾸시는 분들에게 힘이 되고 싶습니다. 그리고 저도 이런 분들하고 대화하면서 얻는 게 많습니다.
2. 하지만 꿈만 꾸시는 분들에게 일일이 답해드리느라, 정말 뭔가 열심히 하시는 분들에게 소홀해지는 게 아쉽습니다.
3. 따라서 앞으로는 직접 만드신 게임(또는 유사한것.. 예: 그림, 프로그래밍, 게임 아이디어 등등)을 먼저 보여주시지 않는한 진로에 관한 질문에는 답변을 드리지 않겠습니다.
4. 그리고 혹시나 해서 하는 말인데.... 어떻게든 제 허접한 답변 받아보시겠다고... 남의 작품을 훔쳐서 본인이 만든 것인척 하시는 분들이 계시면 게임업계에 이름을 널리 퍼뜨려 드리겠습니다.
5. 그리고 질문하시기전에 충분히 리서치(구글에서라도)도 해보시기 바랍니다. 구글에서 쉽게 나오는 질문에도 답변 해드리지 않겠습니다.
6. 이렇게 하면 질문자 분들께서도 알아서 포트폴리오를 만드는 겪이 되니 본인 인생에도 도움이 되는 거라고 믿습니다.

마지막으로 한마디

제가 한 악담(?)이 틀렸다는걸 보여주기 위해 이 악물고 열심히 해서 멋진 게임개발자 되신 분들이 있다면 디스 쏴주세요. 진심으로 축하해 드리겠습니다.


p.s. 사실 요번엔 게개포 연재 거를려고 했는데 게임개발자지망생 진우님이 글 쓸 거리를 주셨습니다. 감사합니다. 올해 대학들어가신 새내기인데 학교에서 가르쳐 주지도 않는 C/C++을 독학하며 나름 간단한 게임부터 만들어보고 있으십니다. 이런 자세 본받으시길 바랍니다.

Canstruction 2012

어제 다운타운을 걸어다니다가 HSBC 빌딩 안에 독수리가 한마리가 있는것을 포착.. 뭔가 해서 재빨리 들어가서 보니... Canstruction 2012이란걸 하고 있었다. 그래서 사진 몇장 찍은김에 올림.. 후다닥~

I'm pretty sure it's humping

참고로 이놈은 전세계적으로 열리는 컨테스트란다....

손가락이 안굽혀지는 문제를 고쳐보자

한 15년쯤에 농구하다가 왼손 새끼 손가락으로 공을 받아서(?) 한참 붓고 그런 뒤부터 이놈이 쉽게 굽혀지지가 않았다. 굽히면 중간에 잠시 걸렸다가 아주 힘을 쌔게 주면 갑자기 탁 꺽이면서 굽혀지는 느낌이랄까? 그래서 기타를 칠때도 많이 불편했고(사실 이게 기타 잘 못치는 거의 핑계였지만..) 요즘엔 피아노 칠 때도 불편하고 그랬는데...

어차피 캐나다는 병원가도 땡전 한푼 안내니.. 큰맘을 먹고 의사에게 문제를 이야기하니... 이걸 trigger finger라고 보통 부른단다... 치료법은 일단 magnesium citrate를 자기전에 3~4알씩 한 달간 먹어보란다.. 많이 나아지는 경우가 있다고... 그래서 이게 해결되면 죽을 때까지 계속 그리 먹고.. 아니면 그 때가서 수술을 생각해보자고...

어디 고쳐지나 보자. 고쳐지만 최고의 기타리스트로 거듭나 주리라.....

p.s. 부작용에는 설사가 있단다... 쿨럭쿨럭 -_-

쉐이더 입문강좌 책 계약했습니다

생각해보니 트위터에만 올리고 여기엔 글을 안남겼었군요. 사실 쉐이더 강좌 보시는 분들은 블로그로 더 많이 오실텐데 말이지요..... ㅎㅎ 며칠전에 계약서에 출판 서명했습니다. 여태까지 한빛 출판사에서 편집은 하고 있었는데 멀리 살다보니 이제서야 계약서를 작성했네요.

가장 궁금해 하시는 출판예정일은 5월정도랍니다.

콘솔게임에는 미래가 없다? (방명록 답변)

뭐, 최근에 한국의 모 게임회사 사장님이 '콘솔게임에는 미래가 없다'라는 발언을 해서 이런저런 토론이 일어나고 있는 모양이네요. 이런 발언들이 보통 회사의 이익과 관련된 경우가 많아서 전 보통 대충 뉴스의 헤드라인만 읽어보고 넘어가는게 보통이고 이번에도 그랬는데... (그리고 제가 별로 기여를 할 수 있는 주제가 아니라고 생각해서 대충 넘어간 것도 있음)... 방명록에 '미고'님이 제 의견을 물어보셔서 거기에 답글을 단 김에 그대로 긁어서 블로그 포스트로도 올립니다.

우선 이게 미고님이 던져주신 질문:

북미관련을 비롯해 다양한 게시물을 정독하며 많음 도움 얻고 있는 게임쪽 취업준비생입니다.
일단 게임계의 선구자(?)역할을 해주시는 pope님게 감사드리며..

한가지 궁금한게 있습니다. 게임의 스킬이나 방법적인 질문은 아니고
어떻게 보면 게임계의 동향의 관한 질문이 될수도 있겠는데요. 최근의 한국에서
"게임 매니아 다 모여라!" 라는 공개 토론회가 서강대학교에서 열렸습니다. 전문가 패널로는
아키에이지를 제작중이신 XL games의 대표이사 송재경님이 참여하셨습니다. 그외에도 몇분의
패널이 계셨습니다만 논외로 하겠습니다~

근데 이 토론장에서 마지막 질의응답시간이 주어졌는데 한 학생이 이렇게 대표님께 물었습니다. "저는 온라인게임보다는 콘솔게임을 만들고 싶은데 어떻게 해야되죠? 어떻게 생각하시나요?" 대충 질문의 요지는 이랬습니다. 하지만 전 현장이 있지 않았으니 정확한 질문의 요지까지는 모르겠습니다.

이에 대한 답변이 좀 우리나라 게임계의 파장이 일어날 정도였는데.. 대답은
"콘솔게임에는 희망이 없다" 라는 말이었죠. 비록 한국에 국한댄 얘기였겠지만 이 이후로도
게임사이트나 게임종사자 들간에는 찬반여론이나 토론분위기가 형성이 되었습니다.

저도 지극히 한국이란 나라에서 콘솔쪽은 힘들다고 생각합니다만.. 콘솔쪽 종사하고 싶으면
북미로 가야되는게 현실이기도 하죠.. 비록 아이폰/아이패드 게임들이 나오고 있긴 하지만
콘솔시장에 비해서 혹은 퀄리티에 비해서 많이 개인적으로 딸린다고 생각합니다.

제가 말한 내용을 정리해서 올려논 게시글을 첨부 했습니다

http://www.thisisgame.com/board/view.php?id=1123473&category=102

pope 님께서는 송재경 대표님의 발언과 관련해서 어떤 생각을 하시는지..
동감하시는지.. 아니면 대표로써 경솔한 발언이었는지..

아 그리고 링크따라서 읽으시다보면 게임계의 단합과 관한 내용도 추가적으로 있습니다.
저는 저 발언에 대해서는 오히려 위의 내용보다 더 경솔한 발언이라고 생각하는데요.

창의적인 게임도 중요하지만 더 크게보면 게임계의 산업을 이끌어갈 대표들이 모여서
게임제작 얘기만 하는게 아니라 전반적인 사업계의 흐름을 읽고 앞으로의 방향성에 대해서
제시를 해야되는데..
대표들이 모이는 것에 대해서 꺼려하는 분위기 더군요

이에대해서도 어떻게 생각하시는지 궁금합니다.

내용이 많이 길어졌군요-_-...
간단 명료한 대답도 좋습니다~
감사합니다 항상 도움이 되고 있습니다!

이게 제 대답:
아니, 이리 어려운 질문을... 송재경님이 누군지조차 몰라서 검색을 해봤어야 했어요 ㅎㅎ 어쨌든 대충 제 답변입니다....

송재경님이 이 발언 하셨던 주(week)에 epic games의 팀 아저씨가 인터뷰를 한게 있지요. 그 분의 입장은 '콘솔게임은 아직도 미래가 있다'였습니다. 일단 아이패드나 이런놈들이 "현재" 콘솔게임의 파워를 따라잡는데에는 최소 5~6년이 걸릴것이고 게임을 하는 최적의 환경은 역시 대형 TV를 앞에 두고 하는 것이니까요... 대형 TV가 게임을 하기에 최적의 환경이라는 것은 저도 예전부터 생각해오고 있던거라 팀 아저씨의 말에는 일단 공감하죠.

하지만 송재경님이 한 말이 경솔하다거나 생각하지는 않습니다. 본인의 의견을 강력히 피력하는 건 좋은 것이고, '공인이라면 이런 말은 하지 말아야한다'라는 시각도 옳지 않다고 보니까요. 그리고 회사를 이끄는 입장에서 이미 상당히 기술투자를 한 본인회사에게 유리한 방향으로 업계동향을 몰아가는게 도움이 될테니까요. 아니면 본인이 업계동향을 이미 그렇게 보고 있어서 그쪽으로 투자하고 계신걸수도 있고요. 뭐든간에 나쁘다고 생각하진 않습니다.

그보다 제가 문제삼고 싶은건 송재경님이 콘솔의 미래가 없다는 주장의 근거로 드신 내용이죠. 이 분이 근거로 삼은게 다음 2개 같은데....

1) 아이패드의 발매주기: 1년
2) 앱스토어 가격: 1 ~ 20달라

1)은 이미 콘솔시장이 뜨기전부터 PC 쪽에서 있어왔던 일이죠. PC쪽은 매년, 혹은 매달이 멀다하고 계속 발전을 하지요. 그럼에도 불구하고 콘솔게임쪽은 여전히 발전해 왔습니다. 따라서 콘솔기계가 주기적으로 노후되는게 콘솔시장이 죽어야 하는 이유는 아니라고 봅니다.

2)은 콘솔게임의 가격이 비싸다고 하는건데... 요즘은 콘솔에서도 5~20불짜리 게임은 많습니다. 보통 digital download로요. 그리고 사실 다달이 내는 MMO가 결과적으로 가격은 더 비싸지 않나요? 그 가격에 소비자가 뭘 원하는지가 중요한거지... 실제 가격이 중요한건 아닙니다.

그럼 지금부터는 제 의견:
게임개발하는 사람으로서 제가 필요한 근거는 '소비자가 무얼 원하느냐?'일 뿐입니다.

한국에서 콘솔게임이 뜨지 않은 이유는 사실 애들이 밖으로 나돌아서라고 생각해요. 콘솔은 사실 거실에 있는 TV에 연결해서 하는 맛에 하는거죠. 컴터로 또는 핸폰으로 TV 프로 볼 수 있는데 굳이 많이 분들이 거실에 앉아서 보는 이유가 뭐겠어요? 똑같은 이치입니다. TV가 멀리있어서 눈에도 편하고, 화면도 크죠. 여러명이 같이 볼수도 있고요.

게임도 마찬가지입니다. TV에 연결하는 콘솔게임이 정말 쾌적해요. 근데 TV에 연결해놓고 콘솔게임을 하기엔 부모님 눈치가 너무 보이니까.. 학생들이 밖으로 나갑니다. 공부하러 간다고 하고 나가는거죠.. 그러고 가는 게 PC방... -_- 부모님들은 애들이 공부하러 간다고 했으니까... '저놈이 분명 저러고 놀거야~'라는 의심이 들면서도 그냥 모른척 하는 경우도 많죠... '내 눈에 안보이면 내 책임이 아니다.'란 주의.... 게임셧다운제니 뭐니 하는 개소리법도 그래서 생긴거구요. 부모들이 애들을 제대로 키울 책임을 지기 싫어서 회피해서 생긴... 뭐, 이렇게 중고등학교 시절을 거쳐 대학생이 된 애들 역시 집보다는 밖에 나도는걸 좋아하구요..

그래서 결론은.. 한국에서는 게임의 주 소비자가 결국... 콘솔 게임보다는 PC게임을 원한다는 거죠. (요즘은 모바일도 많이).. 그래서 MMO쪽 수요도 큰거였고 등등... 이게 고쳐지려면 일단 부모님들 의식이 애들은 '놀 땐 놀고 공부할땐 공부해야한다'로 바뀌어야 하고, 집에서 부모님 감독(?)하에 오락을 할 수 있게 허락해줘야 하는거죠.

미국/캐나다의 소비자는 조금 다릅니다. 여기는 PC방이 거의 없습니다. 그 이유가 부모들님들이 집에서 오락하는 걸 허락하니까요.. 차라리 '내 눈 앞에서 그러는게 적당히 감독도 할 수 있어서 좋다.'라는 개념이요. 흔히들 하루 몇시간 이상 오락을 하지 못하게 하거나 그런제한을 가하더라구요. 한마디로 부모가 자기 책임을 지고... 애들은 오락하기 가장 쾌적한 환경인 콘솔게임기 + TV를 즐길 수 있고... 그러다보니 소비자도 콘솔게임쪽을 더 원하고...

대표들이 모이는 것에 대해서 꺼리는 거에 대해서는 잘 모르겠어요. 아마 한국이라는 좁은 공간에서 서로 치열하게 경쟁해야 하니까 꺼리는게 아닐까요? 참고로 NC소프트 같은 경우는 직원들이 컨퍼런스에서 강연하는것도 못하게 한다는군요... 저 개인적으로는 적당히 퍼주는걸 좋아하는지라 좀 아쉬운 면이죠...

업데이트(2012/03/29): ParkPD님에 따르면 NC소프트에서 강연 못하게 한다는건 사실이 아니랍니다. 정정해주셔서 고맙습니다~

질문이 기니 대답도 길어지는군요.. 대충 대답이 되었기를 바라며... 이 글 차라리 제 블로그에 올려야겠어요.. (길게 쓴게 아까워요~!)


확실한 입장 표명?
생각해보니 방명록 답변에는 제 확실한 입장을 표명하지 않은 것 같아서...

1. 소비자가 원하는걸 만들면 된다....
2. 한국: 콘솔게임의 현재가 없다. 미래가 생길려면 문화가 변해야 한다. (고로 힘들것 같다고 생각)
3. 외국: 여전히 콘솔게임의 미래가 있다. (최소한 한 5년정도는... 그 이상을 예측하는게 의미가 있나? 언젠가는 다른 고성능 기기에서 게임을 하되 영상 및 음향은 무선으로 TV에 HD품질로 쏴줄 수 있는 날이 올거다. 물론 실시간으로.... 그러면 콘솔이라는 개념이 좀 바뀔지도...)
4. 업계 대표끼리 연락을 하거나 지식울 공유하는 것은 좋다고 생각한다. (빌 게이츠와 스티브 잡스도 연락을 종종 했다고 하며, 구글의 CEO도 페이스북의 보드멤버이지 않나?)

p.s. 위에 '게임계의 선구자 역할을 하시는 pope님'이란 문구에 밑줄 긋고, 폰트 크게 하고, 볼드체로 처리하고 싶었으나... 참았음 -_-;

컴파일 경고하나당 3 대씩 맞습니다

컴파일 경고(warning) 얼마나 신경쓰세요? 현재 작업중인 코드베이스를 컴파일하면 경고가 몇개나 나오나요? 하나라도 있다면 반드시 다 고치세요. 구차한 변명따윈 필요없습니다. 하나도 안나오게 다 고치세요. 왜인지는 얼마전에 있던 제 경험담을 통해 아주 짧게 주저리주저리 설명드립니다.

며칠 전에 발견한 컴파일 경고 하나
현재 마무리를 도와주고 있는 콘솔게임을 PS3용으로 컴파일하다(즉 g++을 사용하면) 운좋게(왜 운좋은건지는 나중에 설명) 다음과 같은 컴파일 경고를 봤습니다.

1>..\..\src\monster.cpp(2814): warning : unused variable 'temp'

보통 때 같으면 무시하겠는데(왜 무시하는지도 나중에 설명.. 원래는 절대 무시하면 안됨) 그날 따라 무슨 신내림을 받았던지...

'응? 이놈이 뭐지? 궁금한걸?'

이란 생각이 더블클릭을 해서 소스코드를 봤지요.


bool swapped = false;
if( dist1 > dist2 )
{
  swapped = true;
  float temp = dist1;
  dist1 = dist2;
  dist2 = dist1;
}

어라... 버그가 보이는군요. 무슨 버그일까요.... 잠시 여백을 두어 생각하실 기회를 드리겠습니다... 한 눈 팔지 말고 코드 분석하세요...

한 눈 팔지 말랬잖아요.. 이 이미지를 보시면 이미 한눈 파신 겁니다. (그래도 출처는 http://curiousanimals.net)

자, 문제점을 찾으셨나요? 찾으셨을거라 믿습니다... 아니시라면.... 당신은 프로그래머가 아니야~ 버럭!

그래도 또 설명하는 친절한 포프씨 -_-
위 코드가 하려는 일은 두 거리(dist1, dist2) 중에 dist2가 언제나 dist1보다 크도록 변수값을 교환해주는 거군요. 매우 간단하죠. 근데... 뭔가 이상하죠? temp 변수가 안쓰였다니... 프로그래머가 아니신 분들을 위해 친절하게 예를 들어 한 단계씩 보여드리죠..


1. 일단 대충 변수값을 제맘대로 대입
다음과 같이 변수값을 정해서 이게 왜 버그인제 예를 보여드리겠습니다.

• dist1 = 20
• dist2 = 10

2. float temp = dist1;이 라인을 실행하면 변수값이 다음과 같이 됩니다. 별문제는 없죠 아직.

• temp = 20
• dist1 = 20
• dist2 = 10

3. dist1 = dist2; 
이 놈 이후엔 변수값이 이리 됩니다. 역시 괜찮습니다.

• temp = 20
• dist1 = 10
• dist2 = 10

4. dist2 = dist1;  

이게 마지막 라인이군요. 드디어 버그가 보이는군요. 이걸 실행하면 최종 변수값이 이따위가(?) 됩니다.

• temp = 20
• dist1 = 10
• dist2 = 10

temp에 저장해눴던 값을 dist2에 대입하는 대신 dist1을 대입함으로 해서... 버그가 생긴거지요...  그럼, 이 버그로 인해서 생기는 문제는 뭐였을까요?

전.모.릅.니.다.

정말 몰라요....(출처: http://knowyourmeme.com)

대충 코드를 훑어봤는데... 파일 이름은 monster.cpp이고 함수이름은 updateTail() 이었습니다. 사실 정확히 어떤 버그가 생기는지는 제대로 살펴보지 않았습니다. 그냥 대충 생각해보니 몬스터들이 팔을 휘두르거나 그럴 때 자취를 보여주기 위해 띄를 하나 그려 주거든요? 가끔, 그 띄가 뒤로 역류해서 겹쳐보이는 경우가 있었습니다. 그게 바로 이 버그 때문일지도 모릅니다. 하지만... 귀찮아서 더 자세히 보진 않았습니다. 그냥

'이 버그 발견했으니 고쳐주세요.'

라고 이메일만 보냈습니다.

버그는 어느 프로그래머나 만든다.
뭐 이정도 버그야 어느 프로그래머도 만들 수 있는 버그입니다. 그 부분에 대해선 프로그래머를 탓하지 않겠습니다. 저같은 꽃미남 프로그래머도 만드는 버그입니다.

뭐, 위의 예는 약간의 비주얼적인 하자.... 별 큰 문제는 아니었죠... 근데... 이게 뭔가 더 중요한 코드였다면 엄청난 하자가 될수도 있죠. 특히나 이처럼 특정조건에서만 생기는 문제였다면 디버깅도 쉽지 않습니다.

하지만 버그를 안만들기 위해 노력은 해야할거 아닌가?
따라서 제가 탓하고 싶은 건 컴파일 경고가 떡하니

"너 뭔가 잘못하고 있을지도 몰라. temp변수가 안쓰였잖아"

라고 말해주는데 그걸 무시한 만행(?)입니다.

컴파일러 경고를 고치는 것만으로도 상당히 많은 수의 버그를 미리 잡아낼 수 있습니다. 이 코드가 들어가있는 게임... 수백만장 팔립니다... 개발비도 수백만불 됩니다. 이런 프로젝트에서 가장 쉽게 코드품질을 보장할 수 있는 법을 무시하는 프로그래머의 자세 좋지 못하죠. -_-

보통 이따위로 깔끔하지 못하게 프로그래머하시는 분들... 전 타박해 드립니다... 하지만, 이번에는 그러지 못하는 이유가 있었습니다. 그것은....

너도 범인이다.
사실 문제는 이 코드를 작성한 프로그래머에게만 있는 건 아니었습니다. 이 회사의 모든 프로그래머 또는 제대로 된 정책을 만들지 않은 리드급 프로그래머에게도 문제가 있었습니다.

왜냐면..... 이 코드베이스를 컴파일하면 컴파일 경고가 1019개 나오기 때문입니다. -_- 1019개나 되는 경고속에 파묻힌 경고 하나를 찾으라고 하는게 어불성설이지요.....

자네...나보고 어쩌라는 겐가....?

보통 때 같으면 전 이런 경고 다 고쳐버리고,

"앞으로 경고 나오면 경고 하나당 저에게 3대씩 맞습니다."

라고 통보를 해드립니다. 하지만 그럴 수 없었던 이유가 이미 너무 늦었다는거죠.  -_-.... 게임 마무리 단계에서는 아무리 사소한 거라도 안건드립니다. (이건 전에 '게임 출시전 개발자가 갖춰야할 마음가짐'이란 글에서 말씀 드렸었습니다.) 딱히 발견된 버그가 있지 않는한 절대 안고칩니다. 코드를 바꿀 때마다 새로운 버그가 나올 위험이 있거든요. 그래서.... 안고칩니다.... 무조건 안고칩니다.

게임 출시하고 나서 고치죠. 근데 이 프로젝트 이후에 제가 이 팀을 도와줄 일이 없을거 같으니....

아마 평생 안고칠지도.... -_-

컴파일 경고를 방지하는 무대뽀 실용적인 방법
자, 그럼 저희처럼 너무 늦기전에 이런 일이 발생하는 것을 방지합시다. 당장 오늘부터라도 시작합시다.

컴파일러 경고를 오류로 처리한다.
가장 실용적인 방법은 컴파일러 경고가 나는 경우 이걸 아에 오류(error)로 처리해서 실행파일 조차 안만들어지게 하는겁니다. 아주 무대뽀 실용적이지요. 간단히 Visual Studio에서 컴파일 옵션만 켜주면 됩니다.

아주 실용적(?)인 방법

이러면 경고가 날 때마다 아예 실행파일이 안만들어지니 테스트를 못하지요! 그래서 프로그래머는 반드시 이 경고를 고쳐야만 합니다. 그래야 제대로 도는지 테스트라도 하니.... 근데 문제는.... 임시적으로 뭐 테스트하고 지우기 위해 대충 코드짜놨는데 경고가 나면...... 짜증나지요... 프로그래머들의 반란(?)을 부추기는 계기가 됩니다.... -_-

그래서 이 옵션은 release 빌드용으로만 켜주는게 좋습니다. debug 빌드에서는 프로그래머가 뭔짓을 해도 냅두는게 장수의 비결입니다. 문제는 프로그래머가 debug 빌드에서만 테스트하고 경고있는 코드를 그대로 check-in 했을 때인데요.

뭐, 이럴 때는 자동빌드머쉰(automatic build machine)이 release 빌드에 실패한뒤 그 프로그래머에

"당장 경고를 고치지 않으면 구워먹겠다!"

라는 협박 이메일을 보낼 거라고 믿습니다. 자동빌드머쉰이 없다면 만드세요. 이것도 없이 어떻게 게임 개발하지...? -_-;;;

정말 말도 안되는 경고는 꺼준다
가끔 정말 말도 안되는 경고도 있습니다. 별 의미가 없는 경고도 있고요. 이런 건 꺼주시면 됩니다. 단, 자기 맘대로 끄지 마시고 다른 프로그래머들과 상의한 뒤 동의를 얻어 꺼주세요. 자기 맘대로 끄는 것을 허용하면 경고 고치기 싫어서 그냥 꺼버리는 몰상식한 프로그래머들 꼭 나옵니다. 이런 분들 발견하시면 퇴사처리 해버리셔도 됩니다. -_-

끄는 법에는 2가지가 있습니다. 프로젝트 전체로 꺼주는 법도 있고, 각 파일별로 (또는 그보다 작은 단위로) 꺼주는 법도 있습니다. 원하는 대로 골라서 쓰시면 됩니다.

프로젝트 전체에서 경고 꺼주기
아래처럼 프로젝트 속성에서 꺼주면 됩니다. 아래 예는 프로젝트 전체에서 경고 #4507을 다 꺼주는 겁니다.

파일별로 꺼주기
그냥 아래처럼 #pragma warning()을 써주시면 그 뒤부터는 경고가 안나옵니다.

#pragma warning( disable : 4507 )

이걸 나중에 다시 켜줄려면

#pragma warning( default: 4507 )

을 해주면 됩니다.


대충 정리
뭐... 결국 할 말은.... '경고를 반드시 고쳐주세요.'였으나 역시나 너무나 주저리주저리 써서 대충 정리.

• 컴파일 경고만 살펴봐도 정말 명백한 버그들을 고칠 수 있다.
• 릴리즈 빌드에서는 컴파일 경고를 컴파일 오류로 처리해서 프로그래머들이 언제나 경고없는 소스코드를 유지할 수 있게 돕는다.
• 필요없는 경고는 프로젝트 속성에서 전역적으로 꺼주거나 파일별로 #pragma warning()을 이용해서 꺼준다.

p.s. 앞으로도 대충 어이없는 경험을 바탕으로 '제발 이러지 맙시다.'라는 글을 종종 올리겠습니다. 은근 좋아하는 분들이 많으신듯..... -_-

코딩스탠다드, 정말 이리 빡셀 필요있나?

이젠 피할 수 없는 진실이 되고 말았습니다. 사실 실력도 좋은데... 워낙 꽃미남이 되어놓으니... 비주얼로 자꾸 기억해주시는군요.... 뭐 사실은 사실 겸허하게 받아들이겠습니다... -_-

거부할 수 없는 진실은 힘들다.. 어쩌지 이제 잡지 표지모델 제의도 들어오는데...

왠만한 게임 회사에는 프로그래머가 준수해야하는 코딩스탠다드(코딩 스타일이라고도 하죠)가 있는 것 같습니다. 제가 여태까지 프로그래밍을 해오면서도 상당히 많은 코딩 스탠다드들을 봤는데요  (수백만장씩 팔린 패키지 게임에 사용한 엔진만도 5~6개 만져봤으니 뭐 온갖 꼴은 다 봤죠) 요즘들어 코딩스탠다드가 정말 이렇게 빡셀 필요가 있나 하는 의문이 들고 있답니다. (잡생각이 많죠.. 때로...)

우선, 대충 배경지식..... 코딩스타일에서 정의하는 것은 대충 다음과 같습니다.

• 인덴테이션/줄바꿈
• 빈칸의 사용
• 변수이름 짓는 법
• 함수이름 짓는 법
• 주석다는 규칙
• 등등...

코딩스타일의 존재이유?

결국 코딩스타일을 강제함으로 인해 회사에서 얻으려고 하는 건 가독성입니다. 코드 스타일을 통일시키면 다른 프로그래머의 코드를 읽을 때 쉽게 이해할 수 있고, 따라서 생산성을 높일 수 있다는 미신적인 믿음이 존재하죠.

이렇게 하면 프로그래머의 생산성이 높아진다는 부두교의 미신이 있다..... (믿거나 말거나)

코딩 스타일에서 정의하는 것들의 예
우선 코딩 스타일의 예부터.....

인덴테이션/줄바꿈

다음 형태 중에 어떤 놈을 이용할까? 하는 고민...

a)

for ( int i = 0; i < 10; ++i ) {

  sum += i;

}

b)

for ( int i = 0; i < 10; ++i )

{

    sum += i;

}

c)

for ( int i = 0; i < 10; ++i )    sum += i;

등등

빈칸(white space)의 사용

대충 이런 것들 중에 어떤 놈을 써야하는지...

a)

int a = c * ( d + e );

b)

int a=c*(d+e);

등등

변수이름 짓는 법

단어별 대소문자, 멤버변수앞에 m 접두어를 붙이는지 등등...

a)

mMemberVariable = temp_variable * 2.0f;

b)

MemberVariable = tempVariable * 2.0f;

등등

함수이름 짓는 법

단어별 대소문자, private, public 대소문자 등등

a)

int MyClass::getNumPrivate();

int MyClass:GetNumPublic();

int do_something();

b)

int MyClass::_getNumPrivate();

int MyClass:getNumPublic();

int doSomething();

등등

주석다는 규칙

• 클래스 선언 마다 주석을 달아야 하는가?
• 함수 선언마다 주석을 달아야 하는가? 변수명 설명? 반환값 설명?
• 그 외 어떤 코드에 주석을 달아야하는가?
• 주석 달때 스타일은 어떤걸로? /* ... */,  //, ///, /**...**/ 등등
• 기타 잡다한 것들...

하지만 의문이 들다

저도 좀 뭔가 깔끔하게 정리되어 있는 걸 좋아하는 놈이라 한동안 이런 미신에 푹 빠져살았습니다. 그런데 최근 몇 년 동안에 '정말정형화된 코딩스타일이 생산성을 향상시키나?'하는 의문이 들더군요. (물론 게임업계에 한정된 이야기입니다. 의료업계에서는 계속 빡세게 해주세요... 수술대 올라갔다가 버그 때문에 뻗은 기계 대문에 죽긴 싫습니다... -_-)

사실 코딩 스타일이란게 종교와도 같은 것이어서 이렇다 할 정답이 없습니다. 프로그래머 10명 잡고 물어보면 다들 선호하는 코딩 스타일이 다릅니다. 일례로 함수이름만 들어도 어떤 프로그래머는 private함수는 getNum() 이란식으로 작성하고 public 함수는 GetNum()이라고 작성하자고 하는 반면 다른 프로그래머는 get_num()과 GetNum()이라고 하자고도 할 겁니다.

어차피 회사란 집단체니까 그냥 일률적으로 정해놓고 프로그래머들을 다 강요하면 된다고 생각하는 건데... 정작 문제는 이 스타일로 개종해야하는 사람들에게는 이게 오히려 생산성 저하의 요소가 됩니다.

중요한건 프로그래머의 상식/배려/역량

그리고 참 웃겼던건.. 제가 지금까지 함께 작업했던 프로그래머만 해도 수백명인데... 그리고 이 엔진 저 엔진 옮겨다니면서 거친 코딩 스탠다드만도 대여섯은 될텐데..... 코딩 스탠다드하고 가독성은 정말 별 상관이 없었단 겁니다. 그보다는 오히려 어떤 코딩 스타일을 사용하던 간에 깨끗한 코드를 작성할 수 있는 프로그래머의 역량이 더 중요하더군요. 이런 분들이 대부분 이었습니다. 즉 굳이 코딩 스탠다드가 필요없는 인간들이 대부분...

회사에서 아무리 철저한 코딩 스탠다드를 만들어 놓아도 코드 드럽게 쓰는 애들(소수에 그칩니다)은 여전히 코드 이해 안되게 쓰더군요. 그래서 이런 애들을 좀 더 잘 관리하려고 코딩 스탠다드에 규칙을 더 추가합니다. 이러면 얘네들이 좀 나아질까요? 아닙니다. 얘네들이 코드가 드러운 이유가 있습니다. 남생각을 별로 안하거든요. 규칙이 얼마나 철저하던 간에 어떻게든 빠져나갑니다. 그 덕에 오히려 원래부터 깔끔한 코드 쓰던 사람들만 고생하죠. 이 사람들은 악법도 법이라고 존중하고, 다른 프로그래머들도 배려할 줄 아는 분들이므로 새로 생긴 규칙에 맞게 또 열심히 코드를 작성합니다. 이 규칙 없어도 원래부터 이해잘되는 깔끔한 코드를 작성하던 사람들인데 따라야 할 규칙만 늘어버렸죠. 

이게 배려라는 거다....  밥그릇 까지도 깔끔하게... (이미지 출처: http://garul.tistory.com)

결국 제값주고 산 놈들만 손해란 건가?

이렇게 생각을 하다보니.... 꼭 게임에 DRM 입히는거와 마찬가지란 생각이 들더라구요. DRM을 아무리 빡세게 입혀도 해적질 할 애들은 다 해적질하고 쓰니 아무 상관없는데, 정가내고 산 사람들만 그 DRM에 얽매여서 온갖 귀찮은 일을 다 당해야 하는....

해석은 귀찮으니 생략..... 그림만 봐도 대충 뭔 귀찮은 일을 당하는 지 알거다...

차라리 개별적으로 갈구자. 짜르던가. 칼부림도 가끔?

결국 제가 내린 결론은 저희가 너무도 당연하게 여기며 쓰던 코딩 스탠다드가 생각보다 별로 효과적이지 않단 겁니다.

물론 코딩스탠다드를 싸그리 없애자는 건 아닙니다. 좀 최소한으로 줄이자는 거죠. 그리고 코드 드럽게 쓰는 애들을 개별적으로 갈궈서 좀 고치게 하던가... (인간이 직접 갈구는게 문서 던져주고 따라하라는 것보다 훨씬 효율적입니다... 칼부림이 가끔 날 뿐이지... -_-)...... 안되면 그냥 짜르던가....

이런 생각을 하게 된 또 다른 계기는 게임업계가 엄격한 코딩스타일이 필요한 분야가 아니란 겁니다. 어차피 코드작성한 건 다 내부적으로 쓰는거고, 문제 있으면 소스코드가 다 떡하니 있으니 아무나 가서 고칠 수 있으니까요. 게임업계가 아니라 미들웨어를 만들어서 판매하는 회사라던가 군사업체 및 의료장비에 들어가는 소프트웨어를 만드는 회사에서는 이게 좀 더 엄격해야겠죠. 미들웨어 회사는 라이브러리만 던져주는 경우가 많으니 그렇고, 군사업체 및 의료장비는 사람 생명이 걸린 일이라서 어쩌다 뭔 짓을 하더라도 버그를 아예 처음부터 만들지 않는게 중요하니까요. 어차피 게임이 엔터테인먼트 산업이고, 게임의 요구사항은 하루가 멀다하고 바뀌므로 차라리 유연하게 재빨리 코드를 작성할 수 있는게 게임 품질 향상에 더 기여한다고 봅니다. 게임의 품질이란건 사실 게이머가 느끼는 품질일 뿐이거든요. 인간의 목숨이 걸린 의료소프트웨어에서의 품질하고는 전혀 다르죠.

그냥 이정도면 하면 안될까요?

그래서 과연 '코딩스탠다드를 어디까지 줄일 수 있을까?' 하는 걸 좀 생각해봤죠. 이게 좀 간단해야 정작 남 배려할 줄 아는 프로그래머의 인생도 편해지지 않을까 해서....

나도 좀 단순히 편하게 살고 싶다... 물론 패리스 힐튼과 함께.... 근데 토토샵 질이 좀 심한데? -_-

위에서 들었던 목록을 한번씩 살펴보면서 이야기하죠.

인덴테이션

코드의 가독성을 위해서는 여전히 중요하다고 생각합니다. 특히나 코드의 scope를 보여주는데 도움이 되니까요. 근데 이제 Visual Studio 가 이런 인덴테이션을 직접 알아서 해주므로 크게 걱정할 필요가 없습니다. 20년 전에 이런 게 자동으로 안될때나 문제였지...

빈칸사용

뭐 이건 사실 int k = a * ( b + c );로 해주냐 int k=a*(b+c);로 해주냐 차인데... 어떻게 쓰던 코드 이해하는데 별 차이가 없습니다.... 굳이 목숨 걸 필요 없지 않나요? -_-

변수명/함수명

일단 멤버변수 이름앞에 m을 붙이니 public 함수는 대문자로 시작하니 마니 하는 건 이젠 별 의미가 없는거 같습니다. 어차피 IDE가 워낙 좋아져서 그냥 마우스만 올려도 나오는 경우가 많고 아니면 F12키 한번 누르면 곧바로 선언된데로 이동하니까요. 그리고 다시 돌아올땐 Ctrl + -키 누르면 끝이고... Visual Studio의 인텔리센스가 잘 작동안하면 Visual Assist 를 깔아도.....

단, 가독성을 위해 변수명이나 함수명을 잘 작성해주는 건 찬성입니다. 즉 int a = 1; 이라기보단 int numLoop = 1; 이란 식으로 변수명을 작성해주는거죠.. 딱 보면 이해가 되게... 함수명도 마찬가지고요.

주석다는 규칙

사실 주석달아야 할 곳에 안달아서 헷갈리는 경우도 많고, 달지 않아도 될 곳에 달아서 오히려 코드만 지저분해지는 경우 허다하죠... 이건 사실 어떻게 정의해도 코드 드러운 애들은 여전히 드럽고 코드 깔끔한 분들은 여전히 깔끔한.. 그런 부분...

저 개인적으로는

1. 클래스 이름만 잘 정하면 굳이 클래스마다 주석을 달 필요가 없다. 이름보고 이해안될때만 기재.
2. 함수/변수 이름만 잘 정하면 굳이 함수/변수마다 주석을 달 필요가 없다. 이름보고 이해 안되거나 변수의 반환값이 기묘할 떄만 기재.
3. 코드에서 곧바로 이해되면 주석은 필요없다.
4. 옆에 앉은 놈이 코드만 보고 곧바로 이해가 안되면 코드블럭 별로 그 위에 주석으로 기재

정도가 젤 난거 같습니다.

대충 정리

이렇게 써보고 보니 결국 제가 괜찮다고 생각하는 법은 코딩 스타일의 통일성을 유지하려고 괜히 쓸데없는 규칙을 만드는 대신에 개발자들의 상식을 믿으란 쪽이 되어버린듯...

어쨌든 제가 좋다고 생각하는 코딩스타일은 이것 정도입니다.

• 변수명/함수명에 의미를 담을것
• 코드의 스코프를 보여주기 위해 인덴테이션을 잘 할 것
• 동료 프로그래머가 코드에서 곧바로 이해못할 만한 내용이면 코드 블럭 위해 간단히 주석을 달 것

개종 안하셔도 되요~

뭐, 다들 이러세요~ 라는 걸로 쓴 글은 아니고.... 그냥 한 번 생각해보시라고... 그리고 토론 좀 해보잔 의도로... (어차피 종교적인 토론이라... 난장판이 될 가능성이 높지만...-_-)