달력

10

« 2018/10 »

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
2012.10.10 09:51

라그나로크 온라인 개발 비화 - 1 dev_logs2012.10.10 09:51

라그나로크를 개발한지도 어언 10년이 되어가는데, 그 시간동안 별다른 게임을 만들어 내놓지 못했다는 것이 나의 함정. 개발자는 게임으로 말해야 하거늘, 놀고 있는 요즘 늘어놓을 게임이 없으므로 생각날때마다 한두개씩 심심풀이 + 추억팔이 썰 풀기나 해볼까 한다.

 

라그나로크 초반 직업

라그나로크 개발 초기, 원작 만화에 나오는 캐릭터를 기반으로 직업(영웅)을 가져갈 것인지, 아니면 그 세계를 이루고 있는 또 다른 모험가들의 이야기를 가져갈 것인지 의견이 갈렸던 적이 있었다. 하지만 PD의 결정으로 MMO에 맞게 불특정 다수의 모험가를 아바타로 삼는다는 컨셉이 잡히게 되어 '모험가들'이라는 전제 하에 직업 구분을 잡기 시작했다. 눈치 챈 사람이 있을지 모르겠지만, 초보자를 비롯해 검사/마술사/복사/도둑/궁사/상인은 대부분 당시 빠져있던 게임인 Final Fantasy Tactics에서 차용해 온 것들이 많다. 특히 상인의 경우는 FFT의 아이템사를 참조하였는데, 커뮤니티 관련 기능 중심으로 디자인 되었었기에 전투 관련 스킬을 고민할때는 좀 난감한 부분이 있기도 했다. 하지만 돈발라치기 같은 스킬을 FFT와 똑같음에도 불구하고 돈으로 먹고사는 상인의 특성을 그대로 살릴 수 있을 것 같다는 판단 하에 집어넣어 나름 재화 소모의 깔때기 구조를 만드는데 일조하기도;;;;

 

앉아서 회복하기

다른 게임보다도 라그나로크에서 처음 도입했던 것 같지만.. 어쨌든 당시로썬 획기적이였던 기능. 커뮤니티의 활성화 및 동인용 스토리텔링에 상당히 많은 역할을 했는데, 사실은 노림수를 갖고 만든 기능은 아니였고 하려던게 안되어서 다른 방법으로 풀려다보니 들어가게 된 경우였다.

원래는 리니지처럼 집 안이나 강가 같은 특정 위치에 머물러 있으면 HP의 회복 속도가 빨라지는 기능을 구현하려 했으나, 당시의 온라인 개발 경험부족 및 기능 구현 상 커뮤니케이션 미스 등이 어울어져 해당 기능을 의도한 방식대로 구현할 수 없게 되었다. (자세힌 기억이 안나지만 아마도 어떤 속성셀 위에 도착했을 때 시작과 끝 타이밍을 동기화 해 체크하는 부분에서 어려움이 있었던 듯 싶기도 하고) 어떻게 할까 고민고민을 하다가 캐릭터 디자이너였던 blind군이 지 꼴리는대로 상상의 나래를 펼쳐 찍어놓은 주저앉은 캐릭터 모션을 보게 되었고, 그럼 앉아서 쉬면 회복되는 것으로 하면 어떨까 프로그래머에게 의견을 물었다. 프로그래머는 행동의 시작과 종료를 능동적으로 체크하고 제어할 수 있다는 점에서 ok 사인을 줬고, 그에 맞춰서 집어넣었으나.. 초반에는 앉은 상태에서 다양한 상황 발생 시 (예를 들어 앉아있을때 선공몹에게 쳐맞는다든지) 처리해야 할 케이스를 명확히 다 구조화하지 못해 조금 버그가 많기도 했었던...

 

(to be continue..)

 

Posted by JC Shin quvelab
2012.05.04 23:00

영상으로 기획하기 - 2012.05. dev_logs2012.05.04 23:00

프리-프로덕션은 사전영상화로 시작하자고 주절거리던 일개 개발자로써 열심히 실천해보고 있는데, 이야기와 콘티를 던지고 그에 대한 결과물을 받아보면 확실히 서로 간의 시각차이나 의도의 재해석과 추가개입이 드러난다. 하지만 이렇게 피드백을 주고받다보면 전원기획을 의도하지 않았음에도 서로가 조금씩 이해하면서 함께 정리하고 기획하게 되는 것 같다.


이렇게 만들어진 영상이 있다보니, 기획서를 쓴다고 할때 흔히 쓰는 워드나 파워포인트, 엑셀의 형태일 필요가 없겠다는 생각이 든다. 그렇게 하자면 문서 쓰고 공유하고 함께 리뷰하고 수정하고 하는 과정을 거쳐야 할텐데, 모아놓고 떠들기엔 가뜩이나 기력 딸리고 발음도 그닥 좋지 않은 상태인지라 만들어진 영상을 최대한 활용하는 쪽으로 작업 방식 변경해서 진행하고 있다. 아직 소규모이고 프리-프로덕션 이전의 초기 준비 단계인지라 가능한 것이겠지만..


만들어진 영상을 게임플레이에서 어떻게 전달되는지 보고 알 수 있도록 포토샵으로 GUI 만들고 프리미어를 이용해 얹어서 편집한 후, 사운드나 성우 같은 것 전혀 없지만 (내가 발음이 안되니 녹음할수도 없고) 어쨌든 설명을 위해 smi로 자막을 추가하는 식으로 작업을 하고 있는데, 프리미어에서는 GUI 연출 표현의 한계가 있는지라 애프터이펙트나 플래시도 쓰면 좋겠지만서도.. 둘다 내 자산에는 없는 소프트웨어고, 새로 구매신청하자니 좀 비싸서 눈치(?) 보이고..


이렇게 플레이어블 클라이언트가 없는 상태로 영상으로만 만들기 시작하다보니 시야의 최대/최소 범위와 그에 따른 캐릭터의 위치, 카메라가 쫓아가는 임계범위 등을 먼저 고려하지 못한 채 시작하게 되어 게임플레이 시점처럼 만들기 어려운 부분이 있다. 지금은 해당 기능을 확인해보기 위해 버티컬슬라이스 방식으로 그 부분만 먼저 데모 클라이언트 형태로 병행 작업을 하고 있는데, 그 결과물이 사전영상화 작업과 어떻게 교차되어 합쳐질지 조금 더 살펴봐야 할듯 싶다.


어쨌든, 영상 기획서 자체가 해당 시스템이 어떻게 동작하고 그것이 어떤 흐름으로 연결되는지를 매 상황마다 연동되어 보여지는 GUI를 포함해 가상으로 만들어 본 무비클립인지라, 좋은 점이라면 그냥 보고 이해하기 쉬운 결과물이 된다는 것이고 나쁜 점이라면 수정하기가 귀찮고 시간이 걸린다는 것..?

의외로 처음 만들때의 시간은 오피스를 이용하는 것과 별반 차이는 없는데, 3D 게임 화면 위에 올려지는 2D GUI 조작 영상을 애프터이펙트 없이 작업하려다보니 프레임 단위 편집도 많아지고.. 애펙 쓰듯 하려고 시퀀스로 가져가자니 애초에 연결된 레이어들이 너무 많아서 시퀀스를 나누기도 애매하고, 그러다보니 레이어는 레이어대로 늘어나고.. 레이어 늘어날수록 복붙하는데 매번 레이어마다 락 걸기도 귀찮고..


덕분에 게임 UX 기획 마지막편 - 프로토타이핑에 쓸 경험담이 몇줄 더 추가할 수 있을 것 같다.


Posted by JC Shin quvelab
2012.02.08 20:58

게임 이미지 단상 - 2012.02. dev_logs2012.02.08 20:58

약 10여년 전, 지금처럼 차세대급의 시스템이 갖춰져 있지 않던 패키지 게임 시절에는 다른 무엇보다도 스토리가 우선되어 기획되는 경우가 많았다. 그래픽적인 표현에는 한계가 컸고, UI라던지 시스템의 유저경험 흐름도 현재의 게임들처럼 유연한 절차적 구조를 지닌 경우가 많지 않았다. 그럼에도 불구하고 좋은 스토리는 플레이어에게 깊은 인상을 전달할 수 있는 무기이자 상상력을 자극하는 도구였다. 이런 스토리들은 오히려 단순한 그래픽에 재해석의 여지를 남겨, 전통적인 JRPG 강자였던 파이널판타지 시리즈나 드래곤퀘스트 시리즈는 아마노요시타카와 토리야마아키라의 일러스트를 통해 플레이어가 좀더 다양한 자기만의 해석으로 상상하고 몰입할 수 있게 만들어 주기도 하였다. 이는 다양한 원소스멀티유즈로 발전해 프로덕트의 생명력을 늘리면서 그 부가가치를 높여주기도 했다.

필자가 참여했던 악튜러스라는 게임의 경우에도 실제 게임에는 수많은 도트 애니메이션으로 연출되는 2D 캐릭터와 대화창 일러스트가 등장할 뿐이지만, 광고와 게임 패키지에는 석정현(stone) 작가와 임학수(maxxsoul) 작가의 게스트 일러스트를, 게임용 오프닝 영상(양철집 제작)에는 이온플럭스의 피터정 감독과 작업한 애니메이션을 도입했던 바 있다. 이런 일련의 작업을 통해 실제로는 조금 어두운 스토리를 갖고 있음에도 게임 그래픽 자체가 밝은 편이라 잘 전달되지 못했던 컨셉 이미지를 좀더 유연하게 전달하고자 했다. 덕분에 게임의 스크린샷만 보던 일반 유저들에게 아래 같은 일러스트는 다양한 재해석의 여지를 끌어내 이슈를 만들기도 했고, 오프닝 영상에서는 제시된 인물 관계 속 스토리를 피터정 감독이 너무나도 창의적으로 재해석 해 논란이 되기도 했다. 스토리보드에서부터 마리아가 엘류어드의 채찍질에 단발머리로 컷트!!때문에 조금은 당혹스럽기도 했지만 절대 수정을 안해주던..

Arcturus ⓒ Gravity&Sonnori / Guest Illustration by Maxxsoul

이 방식은 이후 라그나로크 온라인 개발에도 적용되어, 원작자인 이명진 작가와 스튜디오 소속의 일러스트레이터를 비롯해 팬아트 공모전을 통해 알게된 국내 작가들 중 일부를 게스트 일러스트레이터로 초빙해 함께 작업했었고, 게임용 오프닝 영상(매드하우스/drmovie 제작)에서는 천공의 에스카플레너의 노부테루유키 작감, 블러드:더라스트뱀파이어의 기타구보히로유키 감독과 함께 제작한 애니메이션으로 프로모션 하기도 했다. 당시 구현 한계 상, 영상처럼 박진감 넘치는 파티 전투는 게임에 없었지만 ㅠ_ㅠ 이후 이러한 시도는 일본에서의 흥행을 바탕으로 해 라그나로크:디애니메이션으로 연계되기도 했다. 게임은 정말 단순한 캐릭터의 움직임으로 유저들 각자의 모험을 표현해주었지만, 그 하나하나에 캐릭터를 부여하고 스토리를 집어넣어 또 다른 이야기로써의 세계를 만들어 낸 것이다.

근래 게임들의 이미지들을 보면 대부분 3D 렌더링 화면을 멋지구리하게 배치해 쓰는 경우가 대다수인 것 같다. 그려진 일러스트레이션은 2D 애니메이션 스타일이 아닌 이상 많이 찾아보기 힘들기도 하고. 그게 아니더라도 인-게임은 이미 사진만큼 디테일한 고퀄리티의 비주얼을 연신 뿜어내고, 영화 같은 연출과 화려한 볼거리로 흥미를 유발한다. 이제 2D냐 3D냐를 굳이 나누는 것이 무의미 할 정도로 그 자체가 완성된 하나의 씬이다. 하지만 그만큼 상상의 나래를 펼칠만한 개입은 막아버리는 것 같다.
지금도 여전히 스토리로써 그 뒤에 숨겨진 내러티브에 대한 상상을 자극할 수는 있겠지만, 예전처럼 몇 프레임 안되는 모션만으로도 온갖 이미지를 떠올리며 꿈을 꾸게 하던 그 시절이 왠지 아쉽기도 하다.


Posted by JC Shin quvelab
2012.02.07 12:00

라그나로크 GUI 작업기 - 2005.02. dev_logs2012.02.07 12:00

원문 : http://quve.egloos.com/1010508

이미 한참 오래된 게임이 되어버렸긴 했지만, 첫 게임 GUI 기획작이자 실 디자인까지 맡았던 라그나로크 온라인의 작업에 대한 기록을 예전 이글루스에 남겨놓긴 했었는데, 백업을 위해 그대로 옮겨올까 하다가 기억을 더듬어 좀더 수정해 정리.

2000년 어느 날 라그나로크의 개발이 시작되고 난후 액션RPG 타입이 될지 택틱스RPG타입이 될지도 확정하지 못하고 갈등할 무렵, 레벨디자인 작업과 인터페이스 작업을 겸하고 있던 내게 김학규 사장님이 A4 종이에 낙서하듯 그린 인터페이스 레이아웃을 건네 주었다. 그 초기 시안은 그때까지 벤치마킹을 위해 찾고있던 리니지나 디아블로 같은 구성의 레퍼런스들과는 전혀 다른 것이였고, (개인적으로 느끼기엔) 게임에 있어 전에 없이 파격적인 구조와 디자인을 가지고 있는 것으로 보였다. 그 종이에 그려진 것은 바로 winamp 타입의 플로팅 윈도우형 GUI.

당시엔 대부분 리니지, 디아블로, 울티마 같이 이미 고정된 레이아웃의 GUI에 정해진 위치에 띄워지는 프레임 윈도우 방식이 대다수였기 때문에, 지금은 온라인 게임에 있어 일반적이 되어버린 플로팅 윈도우형 인터페이스 자체도 생소했었던 시기였다. 일단 요구 의도 자체는 '게임 화면을 최대한 가리지 않았으면 하기에, 필요할 때 꺼내쓰고 넣는 방식이 되었으면 한다'가 있었기에, 그에 위해 winamp가 다른 미디어플레이어들에 비해 가진 장점들을 찾아보게 되었다.

- 학습을 최소화 한 심플한 기능과 사용성
- 필요한 기능만 호출해 사용 가능
- 모든 기능을 한번에 불러 멀티태스킹 가능
- 작은 형태와 일반 형태로 변형 가능
- 변경 가능한 스킨
- 각 윈도우 간 스냅 달라붙기
- 최종 좌표를 저장하는 플로팅 윈도우

찾아보면 뭐 더 있겠지만 위와 같은 사항들이 우선 정렬되었다. 하지만 이것을 게임에 어떻게 적용해야 할지가 문제였는데, 그때까지는 콘솔 게임처럼 아예 시간을 정지하고 인터페이스를 호출해 보는게 아닌 이상, 온라인 게임은 중지할 수 있는 실시간 환경임을 고려하여 이미 보여지고 있는 UI 화면 내에서 중요한 파라메터값은 기본 표기하면서 하위 기능을 바로 호출할 수 있게 돼있었기 때문이였다.
때문에 이미 이런 낮은 뎁스의 인터페이스 네비게이션에 익숙해진 유저들에게 한단계 뎁스를 추가해 호출하도록 하는 것은 좋지 않은 선택이였기에, 결국 최초로 표기되는 UI 윈도우 패널 자체를 통합형으로 만들지 않고 메인윈도우/채팅윈도우/맵윈도우로 분리해 화면 내 배치하고 서브윈도우를 종속 호출하되 일정한 크기를 유지해 스냅하는 것으로 정리하였다.

하지만 당시 시간적으로 완전한 객체지향적 인터페이스 구조를 구현하기에 할애된 시간은 적었던데다 변경 가능한 스킨이라는 기능 때문에 디자인 자체도 컴포넌트 타입으로 단순 구조화해야 했기에, 기획/디자인/구현을 병행하면서 상당한 시행착오 + 끊이지 않는 버그를 겪게 되었다. 출시 이후 홍보에서는 윈도우즈 방식의 유저지향성 인터페이스를 채용했다고 대놓고 강조하긴 했지만, 일부에 있어서 그 사용성만 차용한 것 뿐이고 기획적으로나 디자인적으로나 구현적으로나 해당 방식의 UX에 대한 본질적인 접근은 하지 못했기에 상당히 애매하면서도 민망한 느낌도 있었다;;

어쨌든 이러한 사항을 바탕으로, 기획이 준비하고 있었던 시스템들과 파라메터들이 하나둘씩 정리되어 카테고리로 묶이기 시작했고, 각 기능 윈도우의 항목들이 시스템맵으로 정리되어갔다. 이렇게 내용을 채워넣다보니 최초의 A4 스케치와는 많은 부분이 달라지게 되었는데, 창의 기본 사이즈가 문제가 되기 시작했다. 애초부터 인벤토리창과 채팅창을 제외하고는 스킨의 디자인적 개입을 최대화하고자 기본적인 컴포넌트의 사이즈를 winamp와 거의 유사하게 고정했었는데, 각 기능마다 내용을 넣다보니 창의 크기가 너무 협소했던 것이다. 물론 좌우나 상하로 움직일 수 있는 스크롤바가 있었지만, 내용 부분을 프레임으로 나눠 include하는 형태로 렌더하는 방식이 아니였기에 불가능한 부분이 더 많았다. 하지만 결국 이 부분은 당시의 일정 상 포기할 수 밖에 없었고, 결국 일부를 제외한 대부분의 윈도우는 각자 렌더해 통째로 뿌리는 방식이 되어 스킨 만들기에 용이하도록 유지되었다.
덕분에 몇몇 윈도우의 경우에는 기능이나 파라메터가 추가될 때마다 레이아웃이 깨지게 되었고, 특정 언어에서는 정해진 영역에 구겨넣다보니 글자 폰트 자체가 너무 작아지거나 뭉게져 가시성을 해치는 결과까지 낳았다. 게다가 요즘 게임들처럼 해상도와 UI 크기를 분리하는 기능 없이 해상도가 변경되어도 UI의 크기는 변하지 않도록 했기 때문에, 고해상도에서는 UI가 모두 작아져 특정 버튼을 조작하기 어렵거나 텍스트 자체를 알아보기 힘들 정도로 불편해지기도 했다.

당시에는 이러한 부분들을 충분히 고려하지 못한 채 디자인만 중시해 접근하다보니 많은 부분을 놓치게 된 것 같다. (그래봤자 스킨 샘플로 급히 추가한 scribbling kids의 디자인 빼면 osx의 aqua 스타일의 흉내내기만;;) 하지만 이러한 나름의 고민과 무식한 결과물이 일본 동인을 중심으로 유저 제작 스킨이라는 측면에서는 큰 반향을 일으켜 짧은 시간 내 정말 많은 변형형을 만들어내자;; 되돌이킬 수 없는 상황- 제작된 유저 스킨이 호환되어야하니, 현 GUI 시스템이나 디자인의 구조 개선은 하지 말자 -이 되어버려 좋으면서도 한편으론 아쉽기도 했던 것 같다.




Posted by JC Shin quvelab
2012.02.01 10:27

fake HDR 구현기 - 2010.03. dev_logs2012.02.01 10:27

원문 : http://quve.egloos.com/4362207

이전에 겜브리오 2.0을 써서 만들었던 모 프로젝트에서 어떻게 하면 가장 적은 비용으로 가장 좋은 때깔을 뽑을 수 있을까~ 고민하다가 도입했던 방법. (프로젝트는 드랍되었지만;;)
일단 목표로써 참고했던 비주얼은 마리오갤럭시와 소닉언리쉬드. 이 중 소닉언리쉬드는 나름 차세대 비주얼. 이 작업 때문에 소닉언리쉬드의 디렉터가 해외웹진에 남겼던 후기 리포트를 개발팀 내 공유를 위해 일년전쯤 번역해놨는데, 어디뒀는지 찾아야하므로 그건 나중에 생각나면 올리기로 하고;; (그래서 딴거 찾아 추가 : 니시카와 젠지의 소닉언리쉬드 그래픽 강좌 링크)

예~전에 진행하다 드랍되었던 액션RPG 프로젝트에서 그래픽 퀄리티 올린답시고 초기 스펙 붕괴시켜가며 멋모르고 따라하다 가랑이 찢어지며 얻었던 교훈을 실증-명확한 기술 스펙과 구현 목표가 있으면 기한 내 실제로 구현할 수 있다- 할 수 있는 기회를 얻을 수 있었다.

차세대 비주얼의 주요 특징 (일부)
- 시야 범위의 톤에 따른 디테일의 묘사력 : HDR을 위시한 톤 매핑이 시야 상황에 맞춰 표현력을 보장
- 화면 전체에 빛과 그림자의 색감과 표현력이 풍부 : 구세대 라이트맵/버텍스칼라링한 결과물과는 차원이 다름
- 캐릭터가 빛을 받는다는 느낌이 확실 : 쉐이더빨, 색상/재질이 반영된 빛 반사, 밝은 빛 영역의 번짐의 묘화
- 캐릭터와 배경이 일치된 공간 하에 있음의 표현 : 캐릭터와 배경에 드리우는 빛과 그림자 방향이 일치, 주변 색감의 영향력

구현 이슈 도출
1. HDR을 도입할 것인가? 아니면 동적 표현은 없지만 표현 스펙트럼을 넓힌 유사 HDR? 아님 걍 때깔만 흉내?
2. 레이 트레이싱을 어떻게 할 것인가? 걍 인게임 라이트맵 쏘기? 실시간? 아님 V-Ray나 Mental Ray? Beast 같은 미들웨어?
3. 쉐도우 캐스팅의 디테일은? 액터/오브젝트 내 셀프 쉐도우를 쓸 것인가?
4. 카메라/빛 방향 계산한 림쉐이더? 아님 흉내만 낸 가라 림쉐이더? 아님 Fabric 쉐이더?
5. 빛 번짐 표현을 위한 Bloom은 어떻게 구현할 것인가? Fog의 처리는?
6. 액터/오브젝트에 사용할 재질감 표현의 수준은?
7. 액터/오브젝트/배경이 모두 동일한 빛의 영역 내에 있도록 표현할 방법은?
8. 바닥에 드리운 그림자를 비롯, 주변 환경광의 영향을 받고 있음을 표현할 방법은?

우리가 목표한 스펙
- 겜브리오 2.0의 기본 랜더링 범주에서 크게 벗어나지 않게
- 지포스 8xxx대의 중저사양에서 돌아갈 수 있도록 쉐이더 떡칠과 실시간 라이팅은 자제
- 위에서 살펴본 주요 특징이 내고 있는 결과물을 최대한 흉내낼 수 있도록
- 프로그래밍부터 쉐이더 셋업까지, 실제 아웃풋 도출까지 목표한 기간은 약 2달 (1 마일스톤)

표현을 위해 고려한 방법
- 기본 렌더링 재료 : GI(Global Illumination)를 통한 배경의 하이라이트 + 림쉐이더를 통한 캐릭터 하이라이트 
                            + 스펙큘러의 반사광 + 포그를 통한 원경 명도값 상향을 통해 화면 내 밝은 영역을 강조해 구분
- 기술적 처리 요소 : 위의 화면에서 렌더링 패스 딸때 일정 명도 이상만 영역을 구하고 그걸 블러링해 그리도록 블룸을
                            수정해 밝은 부분만 빛나듯 번져나가게 표현

스펙에 맞춘 구현 이슈 변경
1. 시간이 없다. 소닉언리쉬드를 최대한 참고하여 때깔을 흉내내는 fake nextgen visual을 목표로 하자.
2. 미들웨어 도입까지 테스트할 시간이 없다. 가장 사용하기 편리하면서 효과가 좋았던 (라이센스도 있던) V-Ray로
   GI 맵 굽자. 밝은 부분은 스펙큘러맵까지 동원해 카메라에 따라 명도 블룸(아래 5번)이 확실하게 그 번짐을
   반영할 수 있도록.
3. 게임이 매우 동적이고 카메라웍이 다양하므로 실시간 쉐도우 캐스팅은 필요. 셀프 쉐도우는 스펙 상 바로 포기.
4. 마리오갤럭시 식 림쉐이더는 좀 무겁지 않을까? Fabric은 좀 싸보이고.. 걍 (최초 고정된) 광원 위치만 계산해 반사광
   태워주는 가라 림쉐이더로 ㄱㄱ
5. 버텍스 그로우 느낌의 블룸은 너무 뿌옇기만 하고 이쁘지가 않다. 빛을 받는 부분만 밝게 빛이 산란하는 느낌을 위해서
   랜더링 시 pass 딸 때 주어진 명도값 이상만 태우도록 구현. 림쉐이더와 함께 어울려 빛 받는 느낌을 강조해주도록.
6. 일단 완료되어있는 캐릭터나 배경이 단순 디퓨즈맵만 사용하고 있었고, 게임 특성 상 노말맵까지는 필요없을 것이라
   판단하여 재질감 및 빛 반사 표현을 위해 스펙큘러맵만 사용하기로.
7. 겜브리오 기본 라이트를 꺼버리고, 디렉셔널썬라이트라 명명한 1개의 라이트(사실 카운터라이트도 있었지만..)를
   맵에 배치하면 그 위치에 맞춰 림쉐이더 광방향이 설정되도록 셋팅. 대신에 이 썬라이트는 GI 구울 때 광원의 방향과
   일치하게끔 수동 작업. (캐릭터가 축을 돌아 회전할 때 광방향이 변해야 하니까)
8. 소닉언리쉬드처럼 앰비언트큐브를 응용한 형태의 라이트필드를 사용했음 좋았겠지만, 일단 싸게 만들고자 했으므로
   바닥 라이트맵 칼라링을 피킹해 액터에 오버레이하는 식으로.

기간 내 실제 구현된 결과물
- 뽑아낸 GI맵을 여러번 합성하고 리터칭해 빛 받은 부분의 따스함과 더불어 그림자 부분도 차가운 톤의 칼라를 포함하게끔
  수정하고, 가장 밝게 빛나야 할 부분에 스펙큘러맵을 동원해 화면 상에서 높은 명도로 표현되게 했다.
  이와 더불어 원거리가 될 수록 짙어지는 포그값 역시 밝은 명도로 표현하되 투명도를 더해, 명도값에 따른 블룸을
  적용했을 때 번져나가는 표현으로 하여금 빛의 느낌을 표현해냈다.
- GI 라이트맵의 빛 방향과 디렉셔널썬라이트가 반영된 림쉐이더의 빛 방향이 일치되었고, 그에 따른 실시간 쉐도우
  캐스팅을 통해 광원의 높이와 반사광의 효과가 위화감 없이 표현되었다.
- 라이트맵 칼라 피킹해 앰비언트~디퓨즈에 오버레이하는 개념은 개발 시간 관계 상 도입하지 못하였다.
  그래도 소닉언리쉬드에서 구현한 앰비언트큐브 응용 방식의 라이트필드 개념은 상당히 괜찮은 발상이였던 듯.

Posted by JC Shin quvelab