rein님의 '게임 서버 관련된 책들을 보면'로부터 트랙백

rein님의 포스트 중에 이와 관련한 것이 있어 주의 깊게 읽어 봤습니다. 서버 사이드에서 요구되는 사항들이 잘 정리되어 있는 것 같습니다.

서버 사이드의 스크립트와 관련해서는 속도에 대한 부담 때문인지 JIT 기술이 사용된 스크립트 언어가 많이 주목을 받고 있는 듯한 느낌입니다. 그래서 윈도우 플랫폼만을 고려한다면 C#이, 다른 것으로는 Tamarin에 스포트라이트가 많이 가는 것 같습니다.

개인적인 사항을 덧붙이자면 초기 개발이 아닌 런칭 후 서비스 개발과 관련된 내용들에 갈증도 해갈할 수 있는 연구 내용들도 포함이 되었으면 하는 바램입니다.

우선 아키텍쳐와 개발 조직에 대한 내용을 꼽을 수 있습니다. 시간에 쫓겨 런칭만을 위한 개발이 아니라 개발 기간보다 긴 서비스 기간을 고려한다면 기본 아키텍쳐에 대한 접근도 일반적인 트렌드와는 많이 다를 수 있습니다. 예를 들어 서비스 단계에서는 안정성과 더불어 빠른 컨텐츠 추가가 필수적인데 아무래도 전통적인(?) 방식으로 하나의 컨텐츠 추가를 위해서 서버 프로그래머와 클라이언트 프로그래머가 필요한 구조라면 그만큼 작업 진행이 느릴 수 밖에 없을테고 이것은 당연히 비용 증가로 귀결될 것입니다. 이런 문제들은 꼭 게임 서버에 국한된 문제는 아닌 것 같습니다만 그래도 앞으로 온라인 게임이 더욱 발전하기 위해서는 꼭 연구가 필요한 분야라고 고집합니다.

다음으로는 rein님의 포스트 내용의 마지막에도 나와 있는 치팅(cheating) 문제입니다. 이것 역시 개발 단계에서 미리 예측을 통해 방지할 수 있는 부분도 있겠지만 이 부분은 역시 서비스를 통해 대응해야 하는 부분이 훨씬 더 많기 때문에 다양한 경험에서 우러 나온 노하우를 공유할 수 있다면 많은 도움이 되겠지요.

마지막으로 떠오르는 것은 현지화(localization) 문제입니다. 만들었다면 팔 수 있는데(서비스가 가능한 지역이라면)는 모두 팔고 싶은 것은 당연한 일입니다.(프로그래머 입장에서는 아니겠지만 말입니다 ^^;) 일단 런칭되어서 서비스가 성공적으로 이루어지면 해외 서비스는 물 흘러 가듯이 자연스럽게 추진되는 것이 요즘의 추세인데 개발 당시에 이런 부분을 전혀 염두에 두지 않고 개발을 진행했다면 낭패보기 십상입니다.

이렇게 보태고 보니 대략 전집 수준이 될 것 같습니다. ㅡㅡ;

ps. 서적에 대한 아쉬움은 출판도 사업이라 아무래도 상업성이 약하면 진행이 어렵겠지요.

남들에게는 주말이지만 밀린 일이 있는 본인에게는 평일인지라 집에서 애인 갈구면서 노가다 중 몇 가지 므흣한 것들 발견~

Visual Studio에서 Vim 사용하기.

비슷한 것으로 vim for VS라는 것을 일찍이 사용한 경험이 있긴 하지만 그닥 맘에 들지 않아 잊고 지냈는데, rein님의 사이트에서  ViEmu라는 것을 발견! 업무상 유닉스(혹은 리눅스)를 사용하는 것도 아니고 그렇다고 vi의 대가는 더더욱 아니지만 MS Word나 Exel, Powerpoint 외의 대부분의 문서 편집은 vi에서 하는지라 OS 설치후 드라이버 세팅 이후 먼저 설치하는 프로그램 중의 하나입니다. 물론 "xx님, 이게 뭐예요?", "xx님, 이거 쓰시기 불편하시지 않으세요?", "아니, 이걸로 코딩도 하세요?" 등등의 이야기도 많이 듣긴 합니다만...이제는 일일이 설명하기도 귀찮고 그냥 웃지요 - 로 회피한답니다. ^^ 우선 다음 주 출근하면 평가판 사용하고 구매는 그 후에 결정 - $79이 아니라 원래 가격 $99도 비싸 보이지는 않습니다. 그런데 vsplit을 지원하지 않는 것은 조금 안습. ㅡㅡ; 개인적으로 많이 사용하는 명령어인데 말입니다.



rein님 사이트의 ViEmu: First Impression에서 참고.


Visual Studio에서 빌드시 모든 코어를 사용하는 방법.

회사에서는 IncrediBuild를 사용하고 있는지라 빌드에 모든 프로그래머의 코어를 빌려 쓰고 있긴 하지만, 작년 초에 쿼드 코어 머신을 받은 다음 왜 이게 VS에서 지원 안하나 궁금하긴 했었는데 - 이제야 답을 얻음. 답은 아래 Azyu님 사이트 글 참고. ^^

Azyu님 사이트의 Visual Studio 2005/2008에서 멀티코어 CPU를 활용한 Native C++ 컴파일에서 참고.


Intel's Threading Building Block 2.0(TBB)

멀티 코어와 관련한 서칭 중 발견 - TBB로 통칭되는 템플릿 기반의 병렬 처리용 런타임 라이브러리.


MIT의 멀티 코어 강의

듣고 싶은데 공개 강의는 아니군요. 좀 해주시지들~ ^^;

멀티 코어(multi-core)와 멀티 쓰레드(multi-thread)는 구분해야 하는 것이 분명하지만 하드웨어의 관점이 아닌 소프트웨어의 관점에서 먼저 바라 보게 되는 프로그래머의 입장에서는 두 개의 의미 차이를 명확하게 구분하는 것이 쉽지만은 않아 보입니다. 이 두 가지에 대한 구분은 멀티 코어를 언급하는 여러 글에 나와 있지만 간단하면서도 명확한 글이 있어 소개합니다.

서광열의 프로그래밍 언어 이야기의 'Parallelism and Concurrency 1'으로부터 트랙백




Concurrency를 설명하는 부분에서 밑줄 친 부분이 두 개의 의미 구분을 명확하게 할 뿐만 아니라 실제로 구현할 때에도 쓰레드를 사용해야 할지에 대한 판단을 하는데에 대한 기준으로 참고하기에도 좋은 것 같습니다.

그런데 사실 서광열님의 글의 논지는 Parallelism과 Concurrency를 우리말로 번역할 때의 어떤 단어를 사용해서 두 개의 의미를 분명히 전달하면서도 명확하게 구분할 수 있을까에 관한 글입니다. 본문에서는 답이 나와 있지 않지만 아래 코멘트나 트랙백에 나와 있는 병렬(Parallelism)과 병행(Concurrency)으로 구분한 것이 의미가 통해 보입니다.

ps. 텍스트 상에서 병렬과 병행 사이의 간극을 분명히 이해한다손 치더라도 병렬이던 병행이던 실제 구현의 문제는 여전히 어려워 보입니다. ^^

이 친구가 한국에 온 지도 벌써 2년이 넘었습니다. 회사 나왔다는 소식을 듣고 연락했었던게 작년이었는데 웬걸, 메일도 전화도 감감 무소식. 같이 일했던 팀원들도 글쎄요와 갸우뚱 콤보만 치는지라 궁금했었는데 최근에 연락이 되었네요. 그 동안 고향에도 다녀오고 여기 저기 돌아 다녔답니다.

<사진은 2차로 맥주 마시러 간 곳에서 서빙하는 언니에게 한 컷 부탁 - 그런데, 앉은 곳이 아주 아주 긴 테이블이었답니다. 그래서 저쪽 끝에 앉은 두분 머리만 저렇게 작게 나온거랍니다...쿨럭 ㅡㅡ+ >

한국에 처음 도착해서 술 가르친 것이 엊그제 같은데(^^;) 벌써 이년이 훌쩍 넘었습니다.(아, 저는 두 손으로 받는 것만 가르쳤습니다. 원샷은 도대체 누가 가르친겨~~ ^^;) 일은 일대로 힘들었고 사업도 잘 안된 모양입니다. 아, 연애 사업 말입니다. -_-;

어린 나이에도 불구하고 외국에서 일하는게 한국이 처음이 아니었는지라 회사 생활에 대한 걱정은 생각치도 못하고 문화적 차이만 염려 되었는데 - 결국 회사라는 곳도 그 문화가 다른 사람들이 있는 곳이라 매 한가지였나 봅니다. 뭐, 별 수 있나요. 부어라 마셔라, 휑한 가슴켠 마냥 비어진 잔을 부지런히 채워 봅니다. 
소주 한잔 하면서 푸념도 들어 주고 위로도 건넸습니다. 예전에 수줍던 모습은 오간데 없고 이제는 대화 중에 간간히 욕까지 나옵니다. 아, 물론 영어로 해서 덜 X 팔리긴 했습니다. ㅡㅡ; 네, 원래 girl에는 fuxx이라는 단어가 따라 다니죠. 같이 있을 때는 fuxx me, 헤어지면 fuxx you - 그런거죠. ㅡ.ㅡ

어쨌던 지금은 본인이 좋아하는 일을 하고 있다길래 보기 좋았습니다. 안심도 되구요. (사실은 부러웠어요. ㅠㅠ 맨날 해외 출장 간답니다. 이번에는 도쿄 건너 샌프란시스코 돌아서, 상해 찍고 돌아 온답니다.) 만나서 반가웠고, 잘 살고 있는 모습을 봐서 좋았습니다. 그리고 옛날 이야기하면서 즐거웠습니다.

내일이면 출발인데 잘 다녀오길 빌어 봅니다. 돌아오면 또 모여서 즐거운 이야기거리들이나 한번 만들어 봐야겠습니다. ^^

전통적인 렌더링 방식인 Forward Shaing 방식의 단점을 극복하기 위해 대안으로 나온 Deferred Shading 역시 bandwidth라는 약점을 가지고 있어, 이를 보완한 몇 가지 변형된 방법들이 최근에 나오고 있습니다. Forward Shading과 Deferred Shading 사이의 스펙트럼을 관찰해 보는 것도 재미 있어 보입니다.

Forward Shading <- SOME OTHER VARIATIONS -> Deferred Shading

Deferred Shading

여러 가지 다양한 자료들이 많이 있지만 개인적으로는 GPG6에 나온 Fast Per Pixel Lighting with Many Light이 Deffered Shading을 처음 접하는 분들도 쉽게 이해될 수 있도록 설명이 되어 있다고 보여 집니다. 일단 이해가 된 다음에는 GPU Gems 2권과 3권에 나오는 Deferred Shading의 사례 연구(Case Study)에 해당하는 글들을 한번 읽어 보는 것도 이 방법이 실제 게임에 어떻게 응용되어 사용되었고 어떻게 적용하는지에 대해서 쉽게 이해할 수 있는 방법입니다. 마지막으로 이 쪽으로는 궁극이라고 보여지는 - 현재 발표된 스펙을 전부 믿는다는 가정하에 - 킬존2도 놓치지 마시길~

• Fast Per Pixel Lighting with Many Lights, Game Programming Gems 6, Frank Puig Placeres
• Deferred Shading in S.T.A.L.K.E.R., GPU Gems 2
• Deferred Shading in Tabula Rasa, GPU Gems 3
• KillZone2, http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf

Variatoins of Deferred Shading

변형된 방법과 관련한 내용은 아래 내용을 참고 하시기 바랍니다.

Light Indexed Deferred Shading의 경우 첫 번째 패스에서 각 라이트 마다 고유의 ID를 부여해서 라이트 볼륨 값만을 렌더링한 다음 두 번째 패스에서는 전통적인 Forward Shading 방식으로 렌더링하는 방식입니다. G-Buffer를 사용하지 않기 때문에 bandwidth에 대한 걱정을 하지 않아도 되는 대신에 Light ID에 대한 정렬을 해 주어야 합니다.

Light Pre-Pass 방식은 일반적인 Deferred Shading 방식의 G-Buffer에 Zbuffer 와 normal 값만을 채우고 다음 패스에서 라이트를 값을 기록합니다. 그리고 렌더링하는 방식입니다.

• Light Indexed Deferred Shading
• http://levelofdetail.wordpress.com/2008/01/24/light-indexed-deferred-rendering/
• http://code.google.com/p/lightindexed-deferredrender/
• Light Pre-Pass Renderer
• Light Pre-Pass Render, Wolfgang Engel

변형된 방식이 모두 G- Buffer를 우회하는 방법인 것을 보면 Deferred Shading의 bandwidth가 생각보다 많이 부담스러운가 봅니다.

블로그 꾸미기 - 어디에 사는 사람들이 내 홈페이지에 접속하는걸까(ClustrMaps)으로부터 트랙백

가끔씩 이글루스의 서비스 중에서 통계 페이지를 열어서 방문한 분들의 기록을 보곤 하는데 오늘 문득 보니 일본어로 번역해서 보신 분의 흔적이 있어 이참에 일본어 및 영어 번역 링크와 방문자 위치 표시기를 달았습니다.

방문자 표시기는 위의 트랙백 링크에서 참고한 것이고 번역기는 아래에서 참고했습니다.

블로그 꾸미기 - 번역기 달기

같은 분 블로그죠~ ^^