KGDC 2001 Making of Whiteday Postmortem (revised)

1. Korea Game Developers Conference 2001 / Planning & Design Session 화이트데이 개발기: 미궁 속의 천일야화 Making of WhiteDay: 1001 Nights in the Labyrinth (주)로커스홀딩스 손노리 게임사업본부 NEW팀 디렉터 이은석 2001-11-03

2. 발표자 프로필 • 이은석 – 1975년생 – 1998년 여름 손노리 입사, 화이트데이 엔진 프로토타입 개발 – 1999년 말부터 화이트데이 디렉터/기획 역임 • professional gamography – 1994-1996: 불기둥 크레센츠 / S&T 온라인 – 1996-1997: 가이스터즈 / 퀘이사 스튜디오 – 1998-2001: 화이트데이 / 손노리 • hobby works – 1994: 85되었수다! – 1997: 삭제되었수다! 2

3. 본 강연의 주제와 성격 • 강연 주제 – 화이트데이의 목표와 진행과정 – 화이트데이의 기획, 기술, 그래픽적 특성 • 화이트데이 개발팀 내 디렉터의 역할 – 개발 후기에 역할의 개념이 정립 – 상위의 프로듀서와 짝을 이루어 팀을 지휘 – 컨텐츠 결정권자 / 소프트웨어 개발 책임 – 스케쥴 및 작업관리는 프로듀서와 분담 3

4. 게임 스크린샷 4

5. 게임의 초기 비전 • 98년 가을, 6인의 파트타임 프로젝트 팀 출범 • 한국산 호러 어드벤처의 제작 • 퀘이크 스타일의 실내 3D 엔진 개발 • 배경은 학교, 매력적인 캐릭터들이 다수 등장 • 세계관과 시놉시스는 명확하지 않았음 • 미친 살인마, 흑마술 오컬트 등의 초기 설정도 있었음 • "퀄리티 있는 한국게임을 만들어보자" • 초기 목표 개발기간 10개월 • 포부는 높았으나 절대적인 경험부족 5

6. 게임의 장르 • main / 호러 액션 어드벤처 • <바이오 해저드>나 <사일런트 힐>과 비슷한 장르 • 어드벤처로서 어느 정도의 사고력과 추리력이 필요 • 플레이어를 조작하고 적을 피해다니는 반사신경도 필요 • sub / 학원 청춘물 • 고등학교가 배경. 교복차림 소녀 캐릭터들이 주로 등장. • 주로 10-20대 남성 유저들에게 어필하는 설정. • *심령학원생존게임이란? • 어드벤처라는 장르로 알려지면 상업적 실패가능성이 높아서 다른 장르를 표방해 붙인 이름. 6

7. 게임의 타겟 유저 (PC, 국내) • 연령 – 고등학생이나 대학생 정도의 연령층. (심의는 12세 이용가 희망  어린 유저들의 플레이중 사고를 염려해 15세로 변경) • 성별 – 남학생의 시점에서만 진행되므로 여자 유저들에겐 흥미도가 떨어질 수 있음. (약간은 미소녀물 게임 같은 느낌도 든다) • 게임 취향 – <바이오 해저드>정도의 액션과 어드벤처가 버무러진 게임을 소화할 수 있는 유저. – 1인칭 시점에 액션성이 있으므로 초보자에겐 어려울 수도 있음. – 섬뜩한 장면도 나오므로 공포물을 싫어하는 사람들에겐 적합치 않다. 7

8. 호러게임의 3가지 요소 • 재미 • 게임으로서 가장 기본적으로 갖추어야 하는 요소 • [기본]인만큼 재미에서의 실패는 가장 치명적 • 공포 • 호러게임의 유저들이 원하는 것 • 개발자로서 도전해보고 싶은 욕심 • 상업성 • 너무 무서워도 상업성에서 실패할 가능성 – 데모버전을 너무 무섭게 만든것을 후회 • 재미와 매력적인 요소들을 균형잡히게 배치 8

9. 칙센트미하이의 몰입(flow)경험 3요소 • 명확한 목표 – 게임시작에서 엔딩까지 플레이어가 <내가 뭘 해야하지?>라는 의문이 들지 않도록, 항상 목표를 제시하려 함. – 명확한 거시목표  목표달성을 막는 장애물  장애물의 극복이 다 시 세부목표가 되고 작은 장애물이 주어진다 • 즉각적인 피드백 – 긍정적 진행의 보상 : 게임의 진행, 밝혀지는 미스테리, 소녀 NPC들의 호의적 반응 – 부정적 진행의 대가 : 무참히 얻어맞음, 무서운 경험 – 게임 속의 세계(NPC, 오브젝트)와 즐거운 상호작용 배려 • 적절한 난이도 – 직관적이고 손쉬운 인터페이스를 만들기 위해 노력 – 초보부터 고수까지 여러 종류의 난이도를 마련 – 스스로 생각해서 풀 수 있도록 퍼즐 힌트를 (친절할 정도로) 제공 9

10. 게임의 주요특징 • 당시의 지배적인 분위기는 호러게임 = 바이오 해저드 클론. 유혈낭자한 좀비 총격물. – 심지어 호러 게임의 원조인 '어둠속에 나홀로'의 신작(2001) 조차 바이오 해저드와 너무 흡사해졌다. • '또 하나의 클론게임'을 만들 생각은 없었다. • 1인칭 시점 풀 3D – 몰입감, 현장감, 자기동일시의 극대화 목적 • 고교 학원물 • 동양식의 공포 – 무혈(無血) 호러를 지향 • '링'에서 가능성을 발견 – 귀신의 등장 • 좀비보다는 역시 소복입은 귀신이 무섭다 일본영화 <링>의 걸작 장면. 게이머들에게 강렬한 충격을 게임 도중 이 씬의 오마쥬가 나온다. 주었던 '머리귀신'의 원본사진. – 공격수단이 없다 사진제공 : (주)CNC미디어 10

11. 공포와 긴장의 장치들 • 가장 무서운 것은 플레이어 자신의 상상력 – 보이지 않는 대상이 가장 무섭다 • 분위기가 무섭다 – 한 밤의 학교라는 배경 자체가 공포 – 음악과 사운드로 분위기 조성 • 소리의 중요성 – 내가 내는 소리에 조심하고, 남이 내는 소리에 귀를 기울여야 함 • 적들의 존재 – 수위를 순찰시켜 '복도'를 위험한 공간으로 만듦 – 잘 보이지 않는 귀신의 추격, 버블보블의 유령 같은 역할 – 저항수단은 없음. 살고 싶으면 도망쳐라. 11

12. 한국식 어드벤처 만들기 • 한국 게임의 정체성에 관한 고민 • 미국게임의 자유도 / 일본게임 스토리성 절충 • 하프라이프  미국게임의 장점 (합리적인 자유도) • 파이널판타지  일본게임의 장점 (매력적인 캐릭터, 스토리) • 스토리 진행여부에 상관없이 적들은 독자적으로 행동 – <일방향성>과 <자유도>의 공존을 위해 눈에 보이지 않는 룰이 존재 • 리얼타임 진행 • 어떤 일을 하든(또는 하지 않든) 시간은 흐르고 적들도 움직인다 – 퍼즐을 풀기위해 생각하는 도중에도 주변에 주의를 기울여야 함 – 인벤토리 화면을 조작하는 순간조차 게임 월드의 pause 상태가 아니다 • 여러 장르의 특성 혼합 • 한데 버무려 '비빔밥' 게임 만들기 12

13. 기본 진행 시스템 • 장애물을 해결해가며 '플레이영역'을 넓혀가는 어드벤처 게임의 기본구성 위에 독특한 호러요소를 혼합 • 플레이 무대는 복도와 방으로 구성된 것이 특징 • 복도: '내가 노출되는' 위험한 곳. • 복도를 따라서 수위가 주기적으로 순찰중 • 이동을 위해서는 어쩔수 없이 거쳐야하므로 주변에 수위가 있는지 들려오는 소리에 신경을 써야한다 • 방: 안전한 곳이긴 하지만... • 수위가 인지하는 이상흔적(문을 열어둔다, 불을 켜둔다)을 남겨두면 위험하다  역으로 유인 가능 • 근처에 수위가 있을때 소리를 내거나 주의를 끌어서는 안된다 • 시간을 너무 지체해도 안됨 – 교내에서 어딘가 1초에 10cm씩 '머리귀신'이 다가오고 있다 – 자정을 넘기면 해피엔딩 불가 13

14. 캐릭터 설정 • 주인공 – 플레이어의 자기 동일시를 노림 – 감정이입에 거부감이 느껴지지 않도록, 성격없는 '백지' 상태로 만듦 – 최소한의 말만 내뱉으며, 대사와 행동 선택의 재미 – 모든 대사는 핀잔형/매너형/소심형 같은 2-3개중에 택일 – 약간 바보같은 이미지가 되었으나 결과적으로 주효하게 작용함 • 3인의 소녀 NPC – 소영, 지현, 성아 – 초기의 혼성 7인에서 여성 3인으로 축소 – EVA의 레이, 신지, 아스카 3인의 성격구도에서 모티브를 따옴 – 연애 시뮬레이션적 요소 존재 • 적과 보스 NPC – 각기 자기의 역할을 잘 하고 있음 14

15. 사운드 • 고가의 라이브러리 사용 – Sound Idea’s General 6000 series & ext, etc... – MILES sound system • 분위기 표현에 주력 – 플레이어가 잘 느끼지 못하는 많은 소리들 (ambient sound 등) – 3D positional audio의 적극 활용 – 장소와 상황에 맞는 적절한 이펙트 프로세싱 (reverb/chorus, low-pass 필터링 등. 실시간은 아닌 전처리) • 풀 음성 지원 • 성우의 캐스팅과 디렉팅에 만전을 기울임 – 사전 미팅과 자세한 시청각 자료 제공 – 상황을 적절히 파악하고 연기할 수 있도록 콘티 준비 – 대개의 성우들은 '수입물 재더빙' 경험은 많으나, 리퍼런스가 존재하 지 않는 '오리지널 창작 녹음' 경험이 많지 않으므로 퀄리티 컨트롤에 유의해야함 15

16. 음악 • 기성곡 사용 • 국산 게임 음악의 고정관념 탈피 노력 – 황병기, 이동준, 레이니선, 동물원 등의 곡 사용 • 동양적 색채에 주력 • 황병기 <미궁> – 가야금의 거장이 연주한 <영혼이 담긴 음악> – 단순히 무섭고 괴기스러운 소리가 아닌, 인간사의 여러가지 모습을 담 고 있는 전위적 작품 – 총 18분의 길이에 다양한 주제의 7개의 장으로 구성됨 • 이동준 <Run I> – <은행나무 침대>에 삽입된 곡. 오케스트라와 동양식 비트의 긴장감. 16

17. 인터페이스 디자인 • 마우스 기본 컨트롤을 중시 – PC 게임의 기본은 마우스라고 생각 – 스타크래프트, 디아블로처럼 '마우스로 모든 것을 할 수 있지만 숙련자는 키보드를 혼용'할 수 있는 설계 • 커서 액션 시스템 – 2D 어드벤처의 마우스 커서 커맨드를 1인칭 시점 3D로 옮겨옴 – 1 오브젝트에 1 커맨드로 단순한 원칙 설계 17

18. 현장 자료 수집 • 학교 탐방 – 4-5개의 학교에서 사진/비디오 자료 수집 – 게임 속의 학교 모델로 곳곳에 적용됨 – 깜깜한 교내에서 벌어지는 실제 상황 체험 – 엄밀히 말하면 무단침입, 지금 같으면 제 정신으로 못함 – 사운드의 중요성을 실감 – 화장실에 소리내지 않고 숨는 긴장감을 실제로 맛봄 – 문닫기, 불 안켜기 등의 원칙은 FPS의 대인(對人)전술에서 착안 18

19. 레벨 디자인 • 닭과 달걀의 딜레마 – 엔진과 기술 스펙, 시스템 디자인, 레벨 디자인, 시나리오… 무엇이 먼저인가? – 화이트데이는 건축 설계사의 도면을 바탕으로 레벨 디자인 시작  다른 부분의 요구사항에 맞추어 필요할 때마다 반복적 수정 19

20. 레벨 디자인 • 인력 및 경험 부족으로 상 세한 설정자료가 없었음. • 이 정도 러프한 설정으로 도 아트 디렉터와의 커뮤 니케이션이 가능해서 배 경 모델링까지는 문제가 없었음. • 그러나 스크립터가 실제 시나리오를 구현하는 과 정에서 예기치 못한 기술 적 문제가 많이 발생함. • 장면 별로 상세한 설정 스 케치가 있었고 이를 통해 커뮤니케이션 했으면 결 과적으로 시간을 단축할 수 있었을 것임. 20

21. 시나리오 작성 – 기본적인 세계관은 음양오행 사상과 귀신 이야기 – 거시적인 목표는 학교 탈출 – 건물별 목표는 5개의 진(陣)을 해제하는 것 – 캐릭터들 사이의 관계와 갈등구조 작성 – 金木土水火 5각형 모양의 상극(相剋)의 순서대로 사 건을 해결 – 2000년 11월, 대화 및 비주얼 씬 전면 개편 시작 – A, B 2개의 진행루트가 있어서 자주 마주치는 캐릭터와 공개되 는 미스테리가 달라지도록 구상 – 복잡한 영화적 줄거리보다는 '학원 드라마 납량특집편' 정도 느낌의 줄거리를 의도했다 • 긴 볼륨을 만들 여력이 없었기 때문 • 이런 요구사항에 시나리오 라이터가 적절하게 맞추어주었다. 21

22. 게임이 재미없다? • 2000년 11월 팀 전체회의에서 긴 토론 – 스탭들이 "개발은 재미있는데, 게임이 아직 재미없다. 무 섭지도 않다"라는 의견.  디렉터로선 마음 아팠으나 스 탭들이 자발적으로 느껴주길 바라던 내용이었음. • 무엇이 문제일까? 대안은? – 게임이 짧음, 내용을 알면 재미 없음  수위 AI가 미구현 상태, 리플레이성, 불규칙성 보충 – 완전 1인칭 이벤트 진행의 단조로움  이벤트시 3인칭 비주얼 신으로 변경 결정 (고통의 시작) 22

23. 엔진 개발 – BSP 레벨 모듈 • 기본적인 BSP 엔진의 기능 • leaf가 공간구성의 최소단위 • line segment-to-BSP 충돌검사의 응용 • 다중 light map 사용, 스위치 ON/OFF 처리 • 여러가지 아이디어로 후반 퍼포먼스 향상 – visiblity object grouping – manual portal 설정. 23

24. 엔진 개발 – 캐릭터 모듈 • ASE file (from 3DS MAX) import • CS physique multi-blend transform support • motion blending, transition support • 실수1 : CS motion flow 프로세스의 이용 – 모션 단위로 개별파일을 쓰는 쪽이 효율적이었다 • 실수2 : 애니메이션 타이밍을 초(sec) 단위 변환 – 1frame = 1/30 sec 으로, 깨끗이 나누어 떨어지지 않아 여러가지 오차가 누적됨 24

25. 오브젝트 라이팅 모델 • leaf 마다 strongest light의 인덱스 소유 • 기본 방식은 ambient + 1 parallel-point light (per leaf, diffuse only, no specular) • 배경과 오브젝트의 라이트 조화가 어려웠다 – (예: 어두운 복도와 불켜진 방 경계선상의 문) – 오브젝트 수직 아래의 바닥 라이트맵 컬러를 ambient로 사용  콘트라스트가 낮아져 밋밋해졌지만 조화가 잘 되었다 25

26. 툴 개발 – WangEd • BSP 레벨 위에 오브젝트 배치 • event area 설정 • VIS group 설정 • path-finding waypoint 설정 • manual portal 설정 • visual macro scene 제작 • auto update 기능 (버전 동기화) 26

27. 툴 개발 – Puppet Master • ASE(source), PMP(project), PET(output) 3종류의 파일이 사용 • OBB설정 (culling용, collision detection용) • motion list 작성 • shadow type 설정 • 변경 가능한 텍스처 등록 (표정 등) • 작은 텍스처 모으기(atlas) 여부 설정 • check-out warning 기능 (SourceSafe 경고) 27

28. 스크립트 시스템 • 한글지원 – 글로벌 변수 작업자 실명제 ($신관_세환_도플아야 = 0;) • C와 비슷하지만 자유로운 type 사용 및 변환 • 실수1 : 프로그래머만 작성 가능 – instance 변수 등의 어려운 개념, 너무 딱딱한 메시지 기반 • 실수2 : run-time interpreting only – byte code가 필요없을 것이라 생각했음 – 속도문제로 고급 AI구현의 발목을 잡음 • 실수3 : no reloading – C++ hard cording보다 불편해질 때도 있음 – (오히려 C++쪽이 런타임 수정 디버깅 가능) 28

29. 수위의 인공지능 • 화이트데이 재미의 백미 • simple state-based FSM(유한상태기계) • 미리 설정된 waypoint를 이용해 경로탐색 • 느린 스크립트 속도로 고민 • 스테이트 전환시에 음성을 내어 힌트를 준다 (음? / 으음.. / 삐익 등 – 실은 디렉터의 육성녹음) 29

30. 다양한 기술들 • 발자국 소리 – 바닥종류, 성별, 걷기/달리기, 좌우 조합으로 80여종 • 그림자 (4종류) • 립싱크 – 자막에서 모음을 추출한뒤 수작업으로 타이밍 설정 • 한글폰트 출력 – 한글 타이포그라피를 말끔하게 구현한 최초의 게임 • Interactive BGM – 소영엔딩 루트의 최후 미궁맵에서 사용, 게임 진행상황에 따라서 마디별로 분기와 루프가 존재 30

31. 특수효과 – 파티클 시스템 – 출렁이는 물 – 불과 폭발 – 현기증시 잔상 – BSP의 특성이용, 배경만 front-to-back 으로 overwriting pixel 없이 alpha로 그림. RTT 없이 저사양 하드웨어에서도 동작. – 특수 라이트맵 모드 – 일반적인 light map x difffuse map (multiply) 대신 미궁에선 light map + difffuse map (add) 사용으로 환상적 분위기 31

32. 리얼타임 컷신 • 후반작업 중 가장 시간을 많이 지체 • 어째서 리얼타임 렌더링으로? • 3ds max 제작 vs. 자체 툴 제작 비교 • 생산성 향상을 위해 모델과 모션 분리 • 정해진 모션 재생과 AI 커맨드의 혼합방식 • 절대적 경험부족 / 기술적 고난도 • 개념과 프로세스 정립 / 프리뷰 방법 / 툴 제작 / 문제 해결 등에 많은 시간 소비 32

33. 리소스 버전관리 (asset management) • SourceSafe – C++ 소스와 스크립트 파일 관리 • winCVS – 공개된 소스, 무료 사용 – 데이터 파일들(asset) 관리 – 2000여개의 텍스처, 800여개의 음성 포함 총 8000여개의 파일들. – 문서 관리 – 각종 기획서, 설정자료 등. • 문제점 – 용량이 크다는 이유로 그래픽 소스파일(MAX, PSD 등)은 소스컨트롤 안 함  훗날 파일 버전 혼란, 파일 분실 등의 문제가 발생함 33

34. 비주얼/사운드 스타일링 컨셉 • 하프라이프 느낌의 조명과 텍스처링 • 캐릭터는 실사와 애니메이션의 중간형 • 음성 역시 리얼함과 애니메이션의 중간톤 – 라디오 드라마, 다큐멘터리 녹음, 연극 발성, 애니메이션 더빙 등 여러가지 스타일에서 고민끝에 얻음 • 건물별 스타일 컨셉과 모티브 – 본관 : 긴 나무복도가 있는 전형적인 낡고 무서운 학교. 협소공 포증을 유도. – 신관 : 본관과는 반대로 깨끗하고 현대적인 스타일로 어둡고 거대한 홀을 등지고 선 광장공포증을 유도. (여고괴담2, 샤이닝, 라마와의 랑데뷰에서 모티브) – 강당 : 영화 캐리, 패컬티, 분노의 역류에서 모티브 34

35. 폴리건 예산 계획 • 개발 기간이 길어지면서 낙후된 부분 • 99년 당시 ‘화면에 총 3000개 이내’가 목표 – 캐릭터에 900개, 배경에 2000개 정도 – 텍스처는 가능한 128x128 이내로 • 2000년 캐릭터당 1200개로 – 표정변화는 텍스처 교체, 립싱크는 jaw bone 1개로 • 2001년 캐릭터당 2300개까지 증가 – 립싱크는 여러 개의 bone을 이용, 몇 개의 기본 자모음 을 이용하지만 no blending 35

36. 캐릭터 설정과 모델링 변천사 36

37. 모션 캡처 • 3-4 군데 정도의 업체를 컨택. (가격, 2인 동시 캡처 여부, 액션 유효 면적 등을 고려) • 총 15분 정도의 분량을 사용. • 준비는 부족했지만 분량이 많지 않아서 하루 안에 끝남. • 캐릭터(figure)와 실제 액터의 신체 비례가 많이 차이나면 후작업이 힘들어짐. • CS에서 bip포맷 사용  배트, 장검 등 하위 오브젝트의 모 션 데이터가 없으므로 앞으로 고려해볼 문제. • 여자액터는 스포츠댄스 수강생 아르바이트 • 남자액터는 디렉터가 직접 연기해서 예산과 커뮤니케이션 비용을 절감 37

38. GUI 스타일링 • neat & modern • 일반적인 호러물의 거칠고 지저분한 스 타일과는 반대로 <그란투리스모>같은 모던하고 깔끔한 이미지를 추구 • 고해상도 대응 • 1280x960 기준으로 소스 제작 • 한글 타이포그라피 • '깔끔하고 수준높은 한글 게임'으로 만 들기 위해 노력함. • HY견고딕, 16-gray anti-aliased bitmap, 장평 100%, 좁은 자간, 완성형 2350자 + 영문자와 한자 약간 • 시스템 메모리 상에서 합성해, 가로 256px 단위의 텍스처로 업로드 38

39. 2006년 추가: 재능과 열정있는 스탭들 • 프로젝트가 끝나갈 때쯤에는 스탭들이 많이 모임 • 프로그래밍, 그래픽, 사운드, 시나리오, QA등 각각의 포지션에서 우수한 인재들이 열정적으로 맡은 일을 해주었다 • 최고의 게임을 만들겠다는 혈기와 사명감을 갖고 프로젝트 진행에 임함 • 당시 국내 PC 패키지 게임 제작팀 중에서는 최고 수준이었다고 생각 • 치프급 중간관리자의 위상을 제대로 세워주지 못 한 것은 디렉터의 불찰, 관리경험 부족 39

40. 2006년 추가: 아쉬운 점 (1) • 흥행성적 – 결과적으로 손해본 정도의 프로젝트는 아니었지만, 상업적 성공에 대한 구체적 비전이 부족했던 것은 사실 – 와레즈 피해가 아니었어도 애초에 국내 PC시장이 너무나 열악 – 가난한 열정만으로는 고급인재를 유지할 수 없고 산업이 발전할 수가 없다. – 상업적 성공 없이 우수한 컨텐츠의 지속적 창작은 불가 – 데모버전을 지나치게 무섭게 만든 것도 후회 • 게임의 볼륨이 적다 – 다른 게임들에 비해 많이 짧은 플레이 시간 – 경험과 기술부족으로 컨텐츠 볼륨을 늘릴 수가 없었기에 그 정도가 아슬아슬한 한계 – 보스전을 좀 더 재미있는 게임 플레이로 풀어내지 못한 점도 아쉬움 40

41. 2006년 추가: 아쉬운 점 (2) • 지나치게 길어진 개발기간 – 경험부족, 기술부족, 자원(인력/자금)부족 – 당시 회사의 어려운 사정 • 예: 악튜러스, 강철제국 후반작업 지원으로 6개월 이상 중간 공백기 발생 – 컨텐츠와 피처를 유지한 채 사람, 시간, 돈 3가지를 모두 줄일 수는 없다. • 하나가 줄어들면 하나는 올라간다 • 이 프로젝트의 경우 컨텐츠를 줄여도 사람과 돈이 없어서 시간이 늘어난 경우 – 엔진/툴/기획이 완성돼 있고, 팀이 셋업돼 있는 상태라면 1년 정도로 개발 가능했을 것임 • 플랫폼과 시장의 몰락 – 싱글플레이 패키지 게임의 사장. 3개월후 마그나카르타가 종지부를 찍음. – 일본시장을 노리고 동시개발 진행중이었던 드림캐스트의 몰락. 41

42. 감사합니다. 42

KGDC 2001 Making of Whiteday Postmortem (revised)

Esté a ler uma amostra.

Confira estes a seguir

KGDC 2001 Making of Whiteday Postmortem (revised)

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (8)

Semelhante a KGDC 2001 Making of Whiteday Postmortem (revised) (20)