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