꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 김포프
얼마 전에 GPU상에서 텍스처의 밉맵을 만드느라 tex2Dlod() 함수를 사용할 일이 있었습니다. HLSL 함수인 tex2Dlod()는 텍스처좌표를 float4 변수로 받는데 이 float4의 네번째 성분이 텍스처 샘플링에 사용할 밉 레벨을 가리킨다고 하더군요.

여기서 절 다소 혼란스럽게 한 부분이 "2번째 밉맵을 샘플링하려면 다음 둘 중에 정확히 어떤 값을 전달해줘야 하는거지?" 였습니다.

texcoord = float4(u, v, 0, 1);


또는
 

texccord = float4(u, v, 0, 1 / 총 밉맵 수);


불행히도 이걸 제대로 설명해 놓은 문서를 찾지 못했고, MSDN에도 설명되어 있지 않고, 구글 검색에서도 실패....

괜히 쓸데없이 검색하느라 시간 낭비하는 사이 직장동료인 다니엘(저와 같이 KGC 발표 했던 그 박사님이십니다)이 렌더 몽키를 사용해서 재빨리 테스트를 해봤더니 첫번째가 정답이라더군요. 즉, 두번째 밉맵을 읽어오려면 float4의 4번째 성분에 1을 대입해줘야 합니다. 다시 한 번 생각해보니 D3D 샘플러 상태인 D3DSAMP_MAXMIPLEVEL을 살펴보면 제대로 유추할 수도 있었더군요. MSDN은 D3DSAMP_MAXMIPLEVEL을 다음과 같이 설명하고 있거든요.

D3DSAMP_MAXMIPLEVEL: level-of-detail index of largest map to use. Values range from 0 to (n - 1) where 0 is the largest. The default value is zero.


두번째 문장을 대충 번역하면 "0 부터 n-1 까지의 값을 사용할 것. 0이 가장 크기가 큰 밉맵(즉, 첫번째 밉맵)이다."입니다.

참고로 이렇게 정수로 밉맵 레벨을 가리키는 것은 OpenGL과 DirectX에서 동일합니다.

포프였습니다.
반응형
,
Posted by 알 수 없는 사용자

안녕하세요.
15, 30일이 연재를 맡게된 이태성이라고 합니다.

제 소개를 드리자면 초등학교 때 파이널 판타지 7을 보고 그래픽 디자이너의 꿈을 키우다 친구집에서 우연히 한 블랙&화이트로 기획자를 해야겠다라고 마음먹은 갈대같은 남자 이태성이라고 합니다. (-_-);

제가 작성할 내용은 "화려한 기획서는 좋지 못한 기획서이다" 라는 주제입니다. 간단히 이야기하면 "기획서가 허전해 보인다고 이것 저것 그림 넣고 참고 자료 넣다 보면 화려해지고 가득 채워 진 듯 싶지만 그 만큼 위험해질 수 있다"라는 내용입니다. 자 그럼 자세히 알아 보도록 하겠습니다.

..........................


...............................어라?


(물론 농담입니다. ㅎㅎㅎㅎ)

자 이런 일도 있고 해서..
저는 다른 주제로 글을 쓰기로 마음 먹었습니다. (T.T)

기본기 탄탄하고 멋진 다른 분들이 기획에 대한 여러가지 뼈있는 글들을 쓸 것이라고 믿고, 저는 이번에 더욱 유연한 플레이를 할 수 있도록 순수 게임 개발 외의 관련 테스트에 대한 중요성에 대해 쓰려고 합니다. (어찌 보면 영양가가 없을 수 있습니다.) 유저 트래킹과 흡사한 내용이지만 제가 주장하는 내용은 유저 트래킹이 가기 전까지 기획자가 해당 역활을 미리 수행하여 생기는 문제를 막자입니다.

많은 회사에서 "유저 트래킹"시스템이 게임 내부에 설계 되어있지 않아 오프라인 테스트를 진행하여, 각각 테스터의 모니터를 녹화하여 분석하는 팀도 꽤나 있더군요. 그러나 저는 그 전에 개발자가 중점으로 해야하는 테스트가 바로 "게임 플레이 플로우 테스트"라 말합니다.


아시다 싶이 해당 테스트는 아래와 같은 상황을 막아주기 위해 있습니다.
 발로만들었냐?: "저 이게임 해봤는데 5분만에 지움ㅋ"


그렇다면 유저들이 언제 게임을 떠나고 싶어할까요?
 그것은 바로
자신이 생각한 대로 게임의 내용이 흘러가지 않을 때” 라고 전 생각합니다.


물론 모든 유저에게 만족스러운 게임을 만들기라는 매우 힘든 일이란 것을 잘 알고 있지만, 5~10분만에 접속을 끊는다는 것은 매우 위험한 요소가 초반에 있기 때문에 문제가 생기는 것 입니다. 개발자 역시 "5~10분안에 유저들이 이 게임을 떠날 것인지 더 플레이할 것인지 판단한다"라고 말합니다. 그러나 개발자가 해당 사항을 인지하면서도 왜 유저들을 떠나게 게임을 만들까요? 왜 놓칠까요. 여자친구 보다 소중한 유저들을 왜 놓칠까요? (전.. 여자친구가 더 좋습니다. 근데 없네요..)


게임 플레이 플로우 테스트의 정의는 무엇인가?
게임의 각각의 구간 (초반 유저가 꼭 거쳐야 할 길)들을 모두 테스팅해서,
지루한 부분이 생기는 곳, 그리고 답답한 곳, 헤매는 곳, 어이없이 사망하는 곳 등등
유저가 불편하고 필요 없는 요소를 체크해서, 유저가 유연하게 플레이 할 수 있도록
걸러내는 작업
을 말합니다.


그렇습니다. 게임을 개발하다보면 아무것도 모르는 햇병아리와 같은 마음으로 테스트에 임하지 않습니다. 당연히 유저들도 이정도는 파악할 것이다. 익숙하기 때문에 괜찮다.라는 마음에 테스트는 단순히 개발에 대한 버그가 있는지에 중점으로 테스트 합니다. 초기 개발이나, 라이브 게임이나 시스템 혹은 퀘스트를 만들면 모든 개발자들이 사내 테스트를 거치게 됩니다. 그리고 완성이 되면 해당 구간은 잊어버리고 또 새로운 철로를 만들기 위해 기획하고 만들고 그립니다. 또 개발이 완료되면 테스트하고 문제 없으면 다시 잊어 버립니다.


바로 이 부분에서 일어나는 "개발 -> 테스트 -> 다음"이 반복될 때 입니다. 이 상황이 쉽게 발생할 수 있는 함정은 바로 "다음"에 있습니다. "개발" -> "개발" -> "개발" 사이의 유연한 연결고리를 이끌어 주는 것에 대한 것을 놓쳐 생기는 문제 입니다. 왜 놓치게 될까요?


대부분의 팀의 기획자는 1명이 아니기 때문입니다. 때문에 각각의 개성이 지닌 기획자들이 만든 시스템/퀘스트가 잘 어울려지게 묶는 것이 쉽지가 않습니다. 그렇기에 플레이 테스트가 필요한 것입니다. "과연 유연한가?"에 대해 끊임없이 고민해봐야 합니다. 프로그래머, 그래픽 디자이너가 놓쳐도 기획자는 절대 놓쳐선 안되는 중요한 핵심입니다.


정리하자면
유저가 좀더 몰입할 수 있게 인터랙티브 요소를 유연하게 다가가게 하자, 귀찮게 하지말자


미야모토 시게루의 "밥상 뒤집기"라는 사건이 매우 유명하죠? 다 만들어놨더니 플레이해보고나서 "다시 만들자"라고 말하는 것이죠. 전 이 것이 "게임 플레이 플로우 테스트"라고 생각합니다. 게임을 개발할 때 버그 테스트가 아닌 플레이 테스트가 지속적으로 이루어지지 않는다면, 유저들이 밥상을 뒤집을 것 입니다. 중요한 것은 초반에만 테스트가 진행되다면 5~10분짜리가 1~2시간 더 지속되는 게임으로 남을지도 모릅니다. 지속적으로 컨텐츠가 될 때 마다 많은 고민을 하여 2~3시간, 100~ 영구!로 쭉쭉 늘립시다!


감사합니다. :)
반응형
,
Posted by 알 수 없는 사용자
객관적으로 타당하거나 뚜렷한 근거는 없지만 그동안 경험상 느껴왔던 생각들을 좀 풀어보겠습니다. 너무 당연한 말을 하는게 아닌가 하는 걱정도 들지만 개발 초년생들에게는 적당히 도움이 될 것 같습니다.

참고로 여기에서 '아티스트'의 범위는 컨셉 일러스트레이터, 3D 모델러, 3D/2D 애니메이터 등 시각적으로 보여지는 무언가를 만들어내는 사람들입니다.

말하려는 주제는 두 가지인데요,
1. 작업 전 - 머리 속에서 구체화를 하는 것이 중요하다
2. 작업 할 때 - 숲을 먼저 보고 나무를 보자

당연한가요? ^^

먼저 '머리 속에서 구체화를 하는 것이 중요하다'에 대해 얘기 해보겠습니다.

작업자 머리 속에서 완성된 모습이 구체적으로 그려지지 않은 상태로 비주얼 작업을 하는 개발자를 가끔 볼 수 있습니다. 개인적으로 이런 사람은 아티스트라는 단어를 붙이기도 민망한데요. 그래픽 툴의 화려한 필터나 플러그인들을 주로 사용해서 사람들의 눈을 현혹시키는 결과물을 곧잘 만들어내긴 하지만 그게 다입니다. 툴이나 플러그인을 무시해서가 아니라 무엇이 우선이고 더 중요한지를, 세계를 놀래킬만한 창작의 레벨을 말하는겁니다. 요즘은 전반적인 수준이 상향 평준화 되어서 찾기 힘든 레어(Rare) 클래스입니다.

사전 이미지화는 비주얼 그래픽 파이프라인의 최초를 담당하는 컨셉 아티스트에만 해당되는 얘기는 아닙니다. 컨셉 원화나 개발 원화가 아무리 충실하게 만들어져있더라도 3D 입체로 만들어지려면 생각보다 많은 부분을 상상하고 창조해야합니다. 애니메이터 역시 상상하고 창조해야 하는게 정말 많습니다. 이펙트도 마찬가지구요.

아주 오래 전 손 그림(연필이나 붓 등)을 지지하는 사람들과 타블랫(포토샵 등)을 지지하는 사람들의 논쟁이 있었습니다. 요즘도 어디선가 있을법한 논쟁인데요. 천리안 하이텔 뭐 이런 시절의 얘기입니다. 정말 옛날이죠. 당시 결론이 어떻게 났는지 잘 모르지만 지금 생각으로는, 손도 타블랫도 도구라서 자신의 머릿 속 이미지를 가장 빠르고 편하게 전달할 수 있는 도구를 쓰는게 정답이라고 생각합니다. 다시 말해서 도구는 무엇을 쓰던지 상관 없고 사실 중요한건 그 사람의 머릿 속 이미지라는거죠.

그런데 여기에 말하고싶은 것이 한 가지 더 있습니다. 창의적으로 이미지화를 해야한다는 건데요. 이미지화는 익숙한 소재에서 좀더 쉽게 가능하겠지만 익숙하다고 해서 쉽게 넘겨서는 안됩니다. 예를 들어 마법사가 강력한 마법을 쓰기 위해서 공중에 살짝 뜬채 옷이 펄럭거리고 주변의 기운이 회오리치며 몰려들고 등과 목을 뒤로 꺾으며 캐스팅을 하는 설정은 너무 뻔하죠. 이런건 너무 뻔해서 사전 이미지화가 너무 쉽습니다.

그러면 어떻게 해야할까요? 예를 들어 실생활에서 서로 다른 사람 열명이 동일한 속도로 나란히 걸어가는 상황을 가정해보면 체중이나 성격 등 수많은 변수에 의해서 모든 걸음걸이가 다 개성이 있습니다. 만약에 셜록 홈즈가 열명의 걷는 모습을 주의깊게 관찰한다면 아마도 30초만에 그 사람들의 서로 다른 성장 환경이나 성격, 어쩌면 질병 까지도 유추해낼 수 있을 것입니다. 사소한 장신구에서부터 미묘한 시선의 변화 등 수 많은 단서들이 가득할테니까요. 마찬가지로 우리가 만들어야 하는 게임 컨텐츠에는 기획을 반영할 수 있는 수 많은 가능성들이 잠재되어 있습니다. 이런 가능성에 대해서 좀더 상상력을 발휘해서 고민하고 기획을 표현해야 합니다.

하지만 창의적인 고민은 그 자체만으로도 고민할 시간을 필요로 하지만 게임에 구현하기 위해 기술적인 장벽을 만나기 쉽습니다. 공짜는 없으니까요. 든든한 투자자와 서로의 실력과 열정을 믿는 동료 개발자들을 만난다면 좀더 쉬워지겠지만 많은 경우 개발 기간이 늘어나거나 야근을 낳기도 합니다. 이에 대해서 뚜렷한 기준이나 해결책은 없고 매 상황마다 최선을 다해서 똑똑한(Smart) 결정을 해야겠죠.

첫 번째 주제를 요약하면 이렇습니다.
 - 창의적으로 미리 상상하고 머릿 속에서 구체화된 것을 묘사하는 아티스트가 되자.

두 번째, '숲을 먼저 보고 나무를 보자'에 대해 얘기 해보겠습니다. 앞서 첫 번째가 작업 전 준비단계에 대한 것이였다면 두 번째는 작업을 진행할 때의 얘기입니다. 먼저 그림 한 장 보겠습니다.

그래픽 작업을 할 때 소요되는 시간 대비 향상되는 품질(Quality)을 간략하게 보여주는 그래프입니다. 10은 열흘을 의미합니다. 정확히 자를 대고 그린건 아니라서 위치가 삐뚤어졌다거나 하는 지적은 참아주시구요~ ^^

예를 들어 어떤 아티스트에게 열흘이라는 기간에 해야하는 일이 주어지면 의외로 많은 경우 열흘 째에 결과물을 내놓습니다. 그런데 미리 완성 해두고 널럴하게 놀던 피를 토하며 철야를 해서 열흘쨰에 겨우 맞추던 상관 없이 열흘 째에 첫 결과물이 나온 것은 잘못된 것이며 숲을 보지 못하고 나무만 완성한 것입니다.

만약에 1.5일이나 3일째에 다소 민망한 품질의 결과물일지라도 협업을 하는 연관 작업자에게 가 데이터(Dummy)를 일찍 전달했더라면 좀더 넓은 시각으로 다른 오브젝트들과의 밸런스를 살필 수 있고, 이 단계에서 생각지도 못한 시스템적인 문제점들을 많이 찾아낼 수 있습니다. 때로는 새로운 문제점이 너무나 강력해서 그전까지 고민했던 이슈들이 하찮게 느껴지기도 합니다.

이처럼 넓은 시각으로 숲을 먼저 봐야 되는 것의 중요성은 사실 아티스트들도 본능적으로는 알고 있습니다. 예를 들어 캐릭터가 5명 등장하는 포스터용 일러스트를 혼자서 그린다고 했을 때 캐릭터 한 명만 죽어라 방망이 깎으며 퀄리티를 올리진 않을테니까요. 다른 캐릭터와의 조화도 봐야 하겠지만 배경도 같이 고민하면서 전체적으로 퀄리티가 상승하는 쪽이 일반적입니다.

하지만 아티스트는 미완성인 결과물을 설익은 채 공개하는 것을 무척 꺼려합니다. 그리고 평범하지 않은 성격들도 유난히 많은 직군인지라 별의별 일들이 다 있습니다. 혹은 아티스트와 상관 없이 팀의 운영이나 커뮤니케이션 문화가 잘못 정착되어서 별다른 커뮤니케이션 없이 모두가 묵묵히 결과물만 제 시간에 뽑아내는 상황일 수도 있습니다. 팀에 안좋은 의미의 정치가 심해서 커뮤니케이션을 위한 설익은 결과물에 대해 반대를 위한 반대를 하거나 감정적인 꼬투리를 잡는 상황도 있겠죠.

글을 쓰면서도 좀 우울해지는군요...

쉽진 않겠지만 '좀더 일찍 커뮤니케이션 하는 것'의 중요성을 다 같이 공감하고 서로 믿으면서 개발하는 것이 중요하다고 생각합니다.

언젠가 블리자드 개발자의 강연에서도 비슷한 취지의 내용을 들었었는데요, 실버문 지역이 처음 제작될 때 다들 각자의 구역만 열심히 만들고 모두 붙여보는 시도를 너무 늦게 해서 엄청나게 고생했다고 하더군요. 그 이후로 블리자드에서는 미리 미리 붙여보지 않고 부분적인 퀄리티만 신경쓰는 모습에 대해서 '실버문 짓 한다' 라는 말이 생겼다고 합니다. 오래 전 들은 강연이라 정확하진 않아도 대충 내용은 맞을겁니다.

여기까지가 이번에 말하려는 두 가지입니다.

첫 번째는, 미리 생각좀 하자는 것
두 번째는, 방망이 깎지 말자는 것

(본 내용 끝)

(잡설 시작)
이곳은 재미있는 글이 자주 올라와서 매일 오지만 올 때마다 마감의 압박이 대단합니다.
게다가 최근에 쓴 책에서 밑천을 대부분 탕진한 터라 고민이 많네요... T_T
날짜 한달 주기로 어떻게 안될까요~~
반응형
,

Reprojection Cache

프로그래밍 2011. 12. 27. 02:00
Posted by 알 수 없는 사용자
안녕하세요. 12일, 27일에 글을 올리고 있는 cagetu입니다. 벌써 2번째 글을 올리는군요. 후후...

제 주요 관심사가 게임에 관련된 그래픽스입니다만, 다른 분들처럼 전공을 한 것이 아닌 그냥 언더그라운드에서 야매(?)로 익힌 것인지라, 최대한 제가 만들어보면서 터득(?)한 내용을 중심으로 이야기를 해볼 생각입니다.
또한,
"나가시와 젠지의 3D 게임 팬을 위한 그래픽스 강좌" 에 올라오는 글들을 잘 보고 있는데 (구글 번역 만쉐!), 2번 중 한 번 정도는 이런 형식의 그래픽스 관련 내용을 올려볼까 생각하고 있습니다.



이번에는 Temporal Coherence 라는 주제로 적어볼까 하는데요?! 제 나름대로는 이 녀석이 꽤 활용도가 높을 것 같다는 생각이 들어서 주제를 정해봤습니다. 동영상 압축 기술에 사용된 녀석이 실시간 렌더링에 적용된 것으로 알고 있구요. 게임에서는 그림자나 Screen-Space Ambient Occlusion과 같은 기술에 주로 사용 됩니다.

핵심 아이디어는 간단합니다. 현재 보고 계시는 화면은 이전 프레임과 현재 프레임을 비교해 봤을 때, 변경된 부분은 아마도 그렇게 많지는 않을 것입니다. 그렇다면, 이전 프레임의 화면과 비교해서, 달라진 부분만 기록하는 방식으로 동영상 압축등의 처리가 가능하겠지요? 이게 Temporal Coherence의 아이디어입니다. (해석하면, "시간에 대한 일관성"?! -_-;;)

이걸 실시간 렌더링으로 가져온 녀석이 Reprojection Cache (혹은 Reverse Reprojection Cache) 입니다.


게임 화면도 마찬가지로, 캐릭터가 뛰어가는 장면을 생각해보신다면, 아마도 평화롭게 뛰어가고 있는 캐릭터는 한 프레임의 장면과 이전 프레임의 장면과의 차이가 아마 거의 없을 것입니다. 물론 속도가 엄청나게 빠른 캐릭터가 있다고 하더라고, 화면에 절반 정도는 이전 프레임에서 보여졌던 장면일 것입니다.
거기에 최근 게임의 그래픽이 이전에 비해서, 높은 수준으로 구현되고 있기 때문에, 더욱 많은 Pixel 연산을 처리하고 있습니다.

이런 게임 화면에서 Reprojection Cache를 이용해서, 변경된 부분만 Pixel 연산을 하고 나머지는 이전 프레임에서 계산된 결과를 재활용할 수 있다면, 화면 대부분의 무거운 Pixel 연산을 그냥 Pass 해버릴 수 있을 것입니다


영상을 보면서, 이야기를 이어가도록 하겠습니다.

Accelerating Real-Time Shading with Reverse ReprojectionCaching[1]
(http://www.cse.ust.hk/~psander/)

영상에서 빨간 부분이 이전 프레임과 비교해서, 없었던 새로운 부분입니다. 생각보다 별로 없지요?!
이 도표가 Reprojection Cache의 전체적인 흐름입니다. 간단하죠?! ㅎ


물론, 가장 이상적인 상태라면, 이전 프레임에서 셰이딩이 완료된 픽셀을 그대로 가지고 와서, 현재 프레임에서 바로 사용하는 것입니다만, 라이팅 계산과 같이 위치에 영향을 받는 픽셀 계산의 경우에는 이전 픽셀을 그대로 가지고 오면 오차가 발생할 것 입니다. 이럴 때에는 Hybrid 하게 이전 프레임의 색상 정보에, 픽셀 정보만 새로 계산하는 형태로 처리를 한다면, 어느 정도는 재활용이 가능할 것입니다. (동영상의 오리 부분을 보세요.)

또한, Reprojection Cache의 이전 프레임의 값을 얻어올 수 있다는 성질을 이용해서, 이전 프레임들의 값들을 시간에 따라 지속적으로 누적시키는 방법을 이용하면, 저렴한 비용으로 높은 퀄리티의 결과를 얻을 수도 있습니다. 이 방식은 그림자나 SSAO에서 주로 사용됩니다.  


[Pixel Correct Shadow Maps With Temporal Reprojection ... [4]]


그림자의 경우에는 알리아싱(지글거림)문제를 해결하기 위해서나  이전 프레임의 그림자 정보를 저장하고 있다가 현재 프레임의 정보에 누적을 시켜줍니다. 이런 형태로 n 프레임이 지나게 되면, 지속적으로 누적된 결과로, 안정적인 결과를 얻을 수 있게 됩니다. (물론, 현실적으로 몇 가지 처리를 해주어야 겠지요?!)

그리고, 게임에서 가장 많이 사용되는 활용되는 부분은 아마도, Screen Space Ambient Occlusion일 것입니다. 그림자와 마찬가지로, 이전 프레임에서 렌더링된 SSAO 결과와 현재 프레임에서 구현 AO의 결과를 누적시키는 방법인데요. 이 방식을 이용해서, 많은 수의 sampling을 하지 않아도, 누적된 결과를 통해서, 많은 수의 sampling을 한 것 과 같은 높은 품질의 AO를 만들어 낼 수 있습니다. (
이에 관련한 논문[2]을 통해서 구현 내용을 보실 수 있습니다.)
 
하지만, 이렇게 시간에 따라 누적을 하게 되면, 움직이는 물체의 경우에는 한 가지 눈에 띄는 오류(artifact)가 있는데요. 움직임에 따라, 누적된 결과의 잔상이 보인다는 것입니다. 
UDK의 사례로 한번 보도록 하겠습니다. UDK 샘플 테스트맵에서 박스를 움직여보면, AO가 미세하게 뒤늦게 따라오는 것을 볼 수 있습니다 . (보이시나요?! ㅎㅎ)


하지만, 얻어지는 이점에 비하여, 이해할 만한 수준의 오류라고 판단이 되기 때문에, 최소한으로 잔상이 보이도록만 유지하는 선에서 구현을 하고 있습니다. (사실 집중해서, 들여다 보니까 저게 보이지, 게임 할 때에는 보이지도 않습니다.)

실제로 Reprojection Cache의 구현 방법은 복잡하지 않습니다. 하지만, 상당히 좋은 효과를 얻을 수 있고요.  이 방식은 motion blur, light shaft와 같이 퀄리티를 위해서는 많은 수의 샘플링이 필요하지만, 많이 blur되어서, 정밀도에 많은 영향이 없는 형태의 처리에서는 충분히 응용할 수 도 있습니다. 

Reprojection Cache의 소개(?) 정도로 글을 적어보았습니다. 간단하게 정리하면, 그냥   
"이전 프레임의 Pixel 정보를 가지고 와서, 재활용한다"
가 되겠군요. (그냥 이렇게 이해하시면 될 듯 합니다. ㅎㅎ)

직접 구현할 경우가 많지는 않을 수 있겠지만, 현/차세대 게임 엔진에서 사용을 하고 있는 기술이고, 앞으로도 계속적으로 다른 기술들의 기초가 될 수 있는 기술이기도 하니 알아두시면 좋지 않을까요?! ^^

[참고자료]
[1] Accelerating Real-Time Shading with Reverse ReprojectionCaching
[2] Bilateral Filtering / Reprojection Cache 소개
[3] http://gl3d.net/148
[4] Pixel Correct Shadow Maps with Temporal Reprojection
[5] 
http://portsnake.tistory.com/entry/gears-of-war2
[6] 
Exploiting temporal and spatial coherence 

반응형
,
Posted by 알 수 없는 사용자

제가 게임개발 교육기관에서 시스템 기획 강의를 할 때, 학생들이 가장 이해하기 힘들어 하던 부분은 바로 추상화(abstraction)였습니다. 물론 초급 경력자들 중에도 추상화를 개념적으로만 이해하지 실무적으로 제대로 활용하는 사람은 그리 많지 않을 것입니다. 아무래도 직접 코드를 짜면서 만들어보지 않고서는 정확하게 이해하기가 어려운 개념이기도 하고, 또 개념적으로는 이해하더라도 실전에서 잘 활용하려면 그만큼 훈련과 경험이 필요한 것이 바로 추상화일 것입니다.

보통 객체지향을 설명하는 책에서는 추상화를 이렇게 설명합니다. 닭이 최하위 개념이면, 그보다 추상화된 상위 개념으로 조류, 그 윗단계로 동물, 그 다음은 생물... 혹은 한국인 -> 동양인 -> 인간... 뭐 이런식이죠. 이런 설명을 들으면, "아, 추상화란 것은 뭔가 구체적인 개념에서 추상적인(포괄적인) 범주로 올라가는 거로구나..."라고 개념적으로는 이해할 수 있습니다. 하지만 프로그래머로서 공부를 더 깊이 있게 하고 코드를 실습하지 않는 한, 대개는 거기까지만 이해하고 끝납니다. 쉽게 말하면, 뭔가 알아 먹긴 했는데 써먹지는 못하는 그런 상태에서 그치는 거죠.

그래서 이런 기획자에게 무기 아이템을 기획하라고 하면 보통은 이렇게 됩니다:
"무기에는 한손 무기, 양손 무기가 있고, 한손 무기 중에는 단검, 도검, 한손 도끼, 망치... 양손 무기에는 양손 검, 양손 도끼... 어? 활이나 석궁은 어디에 분류하지? 근접무기, 원거리 무기로 나누어야 하나? 어 이거 어떻게 하지? 안돼~에! 사람 불러야 돼~!!!"

대부분의 경우, 프로그래밍을 모르는 기획자에게 객체지향에 대해서 가르치면, 클래스, 인스턴스, 상속 같은 주요 개념들은 이해를 합니다. 하지만 실전에서 그것을 써먹지 못하는 이유는 (제가 판단하기에) '가상함수와 다형성'을 모르기 때문이라고 생각합니다. 이거야 말로 직접 코드를 만져보지 않으면 제대로 이해하기 어려운 개념이지요.

이글이 프로그래머를 위한 아니기 때문에 아주 쉽게 설명하자면, 가상함수란, 어떤 명령을 내리는데 구체적으로 뭘 할지는 명령을 받는 놈에 따라서 다르게 들어가는 것입니다. 

일단 예를 들어봅시다. 스타크래프트에서 각 유닛들은 이동방식이 다릅니다. 질럿이나 마린 같이 지면에서 걸어다니는 유닛이 있는 반면에, 레이쓰나 캐리어 같이 공중에서 날아다니는 비행유닛도 있습니다. 하지만 플레이어들이 이 유닛들에게 너는 걸어서 이동하고 너는 날아서 이동해라! 라고 유닛별로 다른 이동명령을 내리지는 않죠? 플레이어는 단지 Move 나 Patrol 같은 명령만 내릴 뿐이고, 각각 어떤 방식으로 이동할지는 유닛이 알아서 합니다.



이런 것이 가능한 이유는 객체지향 프로그래밍 언어에서는 상위 클래스에서 가상함수로 선언한 (추상화된) 기능을 그 하위 클래스들마다 다르게 재정의(Override)해서 받아들일 수 있기 때문입니다. 그렇기 때문에 Move라는 동일한 명령을 내려도 어떤 놈은 걸어서 가고 어떤 놈은 날아서 갈 수 있는 것이죠.

이와 같이, 추상화를 제대로 이해하려면 가상함수와 재정의를 이용한 객체지향의 특성인 다형성(Polymorphism)을 이해해야 합니다. 대부분의 경우 추상화란 각각의 최하위 객체(인스턴스)들이 갖게될 요소들 중에서 공통적인 부분을 찾아내서 그것을 상위 클래스로 올리는 작업인데, 다형성을 이해하지 못하고서 '공통성'을 제대로 찾아낼 수 없기 때문입니다.

객체지향을 설명하는 책을 보면, 객체지향적으로 설계된 프로그램에서는 객체와 객체 사이에 메세지를 주고받으며 동작한다고 말합니다. 위에서 예를 든 바대로 설명하자면 Player 객체가 Unit 객체에게 Move라는 메세지를 주면 Unit이 이동하는 것이죠. 그리고 다형성이란, 각각의 Unit들의 속성에 각자 고유한 이동방식이 설정되어 있어서, Player가 Move라는 가상함수 메세지를 각 Unit들에게 보내면, 각 Unit들은 자신이 가진 이동방식에 따라 Walking 방식으로 이동하기도 하고 Flying으로 이동하기도 하는 것입니다. - 만약 확장팩이 나와서 잠수항행이라든지, 물위에서 떠다니는 호버크래프팅 같은 새로운 이동방식이 추가된다 하더라도 Player는 단지 Move라는 명령만 내리면 됩니다. 한 마디로 유연성, 확장성을 갖는 프로그램이 되는 것이죠.

블로그 포스팅에서 무한정 설명을 할 수는 없는 노릇이니, 더 자세한 부분은 객체지향의 개념을 잘 설명한 책이나 문헌을 참고하시기 바랍니다. 다음에 이어질 포스팅에서는 실제 시스템 기획에서 제대로 된 추상화를 하기 위한 보다 실무적이고 구체적인 예시를 써볼까 합니다.

to be continued...

[주의] 본 필자는 전문 프로그래머가 아니므로 포스팅 내용 중에 사소한(!) 오류가 있을 가능성을 부인하지 않습니다.


반응형
,
Posted by 월하

안녕하세요. 월하(달땡땡) 입니다.
먼저 이렇게 미천한 실력으로 글을 써서 다른분들에게 누가 되지는 않을지 걱정이 앞서네요.
워낙에 훌륭하신 분들이 많고 전문적인 이야기가 오고 가지만....
어쩌면 저같이...
아무런 기본 지식도 없이 맨땅에 해딩하듯 기획자를 지망 하시는 분들에게
제가 겪은 실수를 되풀이 하지 마시라고 적는 글 입니다.


기획서는 어떻게 써야 할 까요?

어떻게 보면 답이 없는 문제일 수도 있습니다.
아래 글은 제 주관적인 의견이 다분히 반영된 글이기도 하니 하나의 참고로만 보시기 바랍니다.

잘 쓴 기획서... 그 이전에 기획서는 무엇일까요?

기획서는 아이디어를 구현 하는 방법을 개발자에게 설명 하기 위한 글 입니다.
즉, (잘 쓴)기획서는

  1. 아이디어가 담겨 있으며
  2. 해당 아이디어의 구현 방안이 담겨 있으며
  3. 개발자가 이해하기 쉬워야 한다

는 조건을 가지게 됩니다.

일반적으로 기획서와 잘 쓴 기획서의 차이는 위 사항 중 2번, 혹은 3번이 부족한 경우입니다.

  1. 구현 방법이 구체적이지 않거나
  2. 개발자가 이해하기 어려운 경우

입니다.

두 개로 나누어 적었지만 "뭔 소리인지 모르겠다!"의 한 문장으로 설명 할 수도 있죠.
즉, 뭔 소린지 알아 들을 수 있는 기획서가 좋은 기획서라고 볼 수 있습니다.

그래서 좋은 기획서는 "세 살배기 꼬마와 여든 살 어르신이 읽어도 어떤 말인지 이해를 해야한다." 고 합니다.
(글 쓰는 주제에 부끄럽지만 전 아직 저 정도 수준이 못 됩니다.)

그럼 기획서가 직관적으로 보이려면 어떻게 해야 할까요?

  1. 이미지화
  2. 도표화

해야 합니다.

위에서 언급한바와 같이 기획서는 개발자를 위한 글입니다.
하지만... 모든 개발자가 그렇지는 않지만 발자분들은 기획서를 읽지 않습니다.[각주:1]
정확히 말하면 기획"서"를 읽지 않습니다.[각주:2]
위의 이미지, 도표, 수식을 중심으로 보지 그 옆에 주석(혹은 메모)처럼 달려 있는 글은 잘 안 읽습니다.
더욱이 글로만 작성된 부분은 거의 안 읽습니다.
(개발자분들에게 돌 맞을지도 모르겠네요.)



1. 이미지화
너무나도 당연한 이야기지만 텍스트로 적힌것 보다 이미지로 설명하는게 훨씬 알아보기가 편합니다.
보통 UI나 화면 연출등을 위해 사용 됩니다. 

어떤 장면을 묘사한 글과 촬영한 사진. 둘 중에 사진이 해당 장면을 명확하게 전달 할 수 있죠.

HP / MP 게이지 표현

텍스트 버전
HP 게이지와 MP 게이지는 막힌 원형이되 캐릭터의 키에 맞게 세로로 늘어져 있으며 
유저 캐릭터 좌, 우에 각기 바깥쪽으로 90도 회전해 있으며 HP는 붉은색, MP는 푸른색이다

이미지 버전


위 두 가지 버전을 보면 분명 아래 이미지 버전이 좀 더  눈에 잘 들어 옵니다.
이미지만 있는것 보다 간략한 메모를 달아 두는게 조금 더 효율적입니다.

위의 이미지 같은 경우에는

 
 
  HP / MP 게이지는 캐릭터 좌, 우에 배치
  HP 게이지: 붉은색 계통의 색상
  MP 게이지: 푸른색 계통의 색상

라고 설명을 달아 줍니다.

즉, 사진에 제목과 설명을 달아 주는 겁니다.[각주:3]


2. 도표화
비슷한 성격의것 중 도표로 만들 수 있는것은 도표로 정리를 하는것이 더 좋습니다.
보통 데이터나 수치적인 부분을 설명 할 때 사용 됩니다.

메신저의 기능과 사용 조건은 아래와 같다.

텍스트 버전
  1. 친구 추가
    1. 로비 / 대기방 / 인게임에서 사용 가능
    2. 친구 리스트가 가득차지 않을 경우 사용 가능
  2. 친구 삭제
    1. 로비 / 대기방 / 인게임에서 사용 가능
    2. 1명 이상의 친구가 리스트에 등록되어 있을 경우 사용 가능
  3. 친구 초대
    1. 대기방에서 사용 가능
    2. 1명 이상의 온라인 상태인 친구가 있을 경우 사용 가능
  4. 편지 보내기
    1. 로비 / 대기방 / 상점에서 사용 가능
    2. 1명 이상의 친구가 리스트에 등록되어 있을 경우 사용 가능

도표 버전
  로비 대기방 인게임 상점 비고
친구 추가 가능 가능 가능 불가 친구 리스트에 여유 공간이 있어야 함
친구 삭제 가능 가능 가능 불가 1명 이상의 친구가 등록 되어야 함
친구 초대 불가 가능 불가 불가 1명 이상의 온라인 상태인 친구가 있어야 함
편지 보내기 가능 가능 불가 가능 1명 이상의 친구가 등록 되어야 함



위와 같이 도표로 정리 하는게 공간도 절약되고 보기도 편합니다.[각주:4]



직관적으로 기획서를 쓰기 위한 두 가지 조건을 언급 했습니다.

물론 해당 두 가지 사항은 기본적인 부분이면 부가적으로 더 많은것들이 있습니다.
(가령 데이터 구조 같은것들이 있겠죠.)

마지막으로 기획서에 꼭!! 무조건!! 절대적으로 들어가야 하는 부분이 있습니다.
바로 처리 순서(프로세스) 예외 처리 입니다.
이게 제대로 안 되어 있으면 시스템적인 버그가 발생 합니다.

가령 상호 동의하에 친구 추가가 되는 구조의 메신저(친구 리스트)라고 할 경우



맞아 죽기 딱 좋습니다.
개발팀이 온갖 쫑코를 다 줄겁니다.
예외 처리와 처리 순서가 다 빠져 있기 때문입니다.

조금 부족 하지만 저기에 살짝만 살을 덧붙여 보겠습니다.

클릭하면 확대 가능 합니다.
(Light TT EX 플러그인이 설치되어 있다면요)



https://t1.daumcdn.net/cfile/tistory/142CC5444EEF734B02

클릭 하시면 크게 볼 수 있습니다.


이렇게 어떤 순서로 처리를 해야 하는지와 예외적인 상황에서 어떻게 처리 할건지가 있어야 합니다.
뭐 위의 샘플에도 빠진 부분이 많습니다.[각주:5]
하지만 원래 기획서라는게 개발 하면서 틀린 부분이 발견 되면 그때 고치는게 제맛이죠.

이상으로 기획서의 (주관적) 정의와 작성 법을 마치겠습니다.

  1. 이건 제 칫솔을 걸고 장담 할 수 있습니다!! [본문으로]
  2. 기획서는 같은 기획자나 높으신분들, 마케터, QA가 봅니다. [본문으로]
  3. 하지만 설명이 너무 길어 지면 오히려 역효과를 가져 옵니다. [본문으로]
  4. 사실 저렇게 알록 달록하게 까지는 하지 않습니다.편의상 색상을 넣고 잘 보이라고 한거죠. [본문으로]
  5. 가령 상대방이 추가 요청 메시지를 받은 후 아무런 액션 없이 게임 종료가 된다거나 하는 부분이요 [본문으로]
반응형
,