시작하세요! Unity 3D 게임 프로그래밍 : 유니티를 활용한 3D 게임 개발

시작하세요!Unity 3D 게임

프로그래밍

iv

•목 차•

이 책을 쓰는 이유 ...........................................................................................xxv

전통적인 어드밴처 게임 .............................................................................. xxvi

유니티 게임 엔진에 대한 소개 ................................................................... xxvii

스크립트를 꼭 배워야 하나? .....................................................................xxviii

이 책의 기본 가정과 선행지식 ..................................................................... xxx

이 책에서 다루지 않는 내용 ......................................................................... xxx

이 책의 조판 관례 ......................................................................................... xxxi

소스 코드 ....................................................................................................... xxxi

01장 __ 장르 살펴보기 1역사적인 참고 자료 ............................................................................................1

그래픽 어드벤처 ..........................................................................................4

루카스아츠 타이틀 ......................................................................................6

실시간 게임으로의 빠른 변화 .....................................................................7

이 장르가 사람들을 끌어들이는 이유 ..............................................................8

흥미로운 장소와 재미있는 해결책 ................................................................ 14

스타일의 정의 ............................................................................................16

환경 나누기 ................................................................................................18

시차 효과 ....................................................................................................20

애니메이션 .................................................................................................21

도전 과제, 임무, 퍼즐 ................................................................................22

v

어드벤처 장르에 무슨 일이 일어난 걸까? ..................................................... 23

최근 어드벤처 게임의 성공 ............................................................................ 25

게임의 재미와 사람 성격의 본질 ................................................................... 25

왜 나만의 게임을 만들어야 하나?.................................................................. 28

다양한 역할 ................................................................................................28

인디 개발자에게 적합한 두 가지 게임 형식 ................................................. 29

1인칭 게임 ..................................................................................................29

캐릭터 .........................................................................................................30

두 게임 형식의 공통 요소 .........................................................................31

1인칭 게임의 디자인 고려 사항 ..................................................................... 32

이야기와 과제의 개발 ..................................................................................... 34

실시간 게임과 프리렌더링 게임의 비교 ....................................................... 36

정리 ................................................................................................................... 50

02장 __ 유니티 UI의 기본 — 시작하기 53유니티 설치와 시작 ......................................................................................... 53

새 프로젝트 또는 장면의 로딩과 생성 ......................................................... 54

레이아웃 ........................................................................................................... 58

장면 창 .......................................................................................................59

게임 창 ........................................................................................................60

vi

계층 뷰 ........................................................................................................60

프로젝트 뷰 ................................................................................................61

인스펙터 .....................................................................................................62

툴바 ................................................................................................................... 63

메뉴 ................................................................................................................... 65

파일 ...........................................................................................................65

편집 ...........................................................................................................65

에셋 ...........................................................................................................66

게임 객체 ....................................................................................................66

컴포넌트 메뉴 ............................................................................................67

지형 메뉴 ....................................................................................................67

창 메뉴 ........................................................................................................67

도움말 메뉴 ................................................................................................67

간단한 객체의 생성 ......................................................................................... 68

선택과 포커스 .................................................................................................. 73

객체의 변형 ...................................................................................................... 74

스냅 ................................................................................................................... 77

정점 스냅 ....................................................................................................78

장면 툴 .............................................................................................................. 79

스냅을 활용하지 않는 정렬.......................................................................80

조명 ................................................................................................................... 82

3D 객체 ............................................................................................................ 90

메시 ...........................................................................................................90

메시의 하위 객체 .......................................................................................90

매핑 ...........................................................................................................92

재료 ................................................................................................................... 98

정리 ................................................................................................................... 99

vii

03장 __ 스크립트에 발 담그기 101스크립트란? ................................................................................................... 101

스크립트의 구성 요소 ................................................................................... 103

함수 .........................................................................................................103

변수 .........................................................................................................113

게임에서 객체 집기 .................................................................................119

마우스로 집은 횟수 세기 .............................................................................. 124

조건과 상태 .................................................................................................... 125

조건문의 구조 ..........................................................................................129

계산 순서 ........................................................................................................ 130

정리 ................................................................................................................. 130

04장 __ 지형 생성 - 테스트 환경의 생성 133장면의 플라이쓰루 내비게이션 ..............................................................139

지형 ................................................................................................................. 139

페인트 텍스처 ................................................................................................ 144

트리 ................................................................................................................. 147

하늘 .........................................................................................................155

다시 트리로 ..............................................................................................159

패키지 .......................................................................................................159

세부 표현 ........................................................................................................ 170

커스텀 지형 에셋의 생성 ........................................................................175

내보내기 vs. 네이티브 형식 사용하기 ..................................................178

지형 설정 ........................................................................................................ 178

섀도우 ............................................................................................................. 180

안개 ................................................................................................................. 186

정리 ................................................................................................................. 187

viii

05장 __ 내비게이션과 기능 189내비게이션 ...............................................................................................189

플랫폼 가지고 놀기 .................................................................................216

충돌 벽 ......................................................................................................228

첫 번째 빌드 .............................................................................................248

정리 .........................................................................................................254

06장 __ 커서 제어 257커서 가시성 .................................................................................................... 257

커스텀 커서 .................................................................................................... 260

GUI 레이어 .................................................................................................... 261

텍스처 임포터 ..........................................................................................262

힌트 색상 ..................................................................................................273

커서 위치 ..................................................................................................273

GUITexture 커서의 관리 ........................................................................275

객체 간 통신 ................................................................................................... 278

마우스 오버 커서 변화 .................................................................................. 282

거리 확인 ..................................................................................................290

중간 빌드 ........................................................................................................ 294

마우스 오버에 대한 객체 반응 ..................................................................... 296

새 기능의 옵션화 ........................................................................................... 313

이동 도중 마우스 오버 기능의 제한 ............................................................ 316

정리 ................................................................................................................. 317

ix

07장 __ 액션 객체 319에셋 임포트 .................................................................................................... 319

임포트 ............................................................................................................. 322

FBX 임포터 .................................................................................................... 332

개별 객체에 대한 상세 제어....................................................................340

개별 변형 ..................................................................................................343

복잡한 계층 구조 .....................................................................................345

부모 지정 ..................................................................................................346

재료의 설정 .................................................................................................... 349

열쇠 .........................................................................................................349

나무 상자 ..................................................................................................356

꽃 .........................................................................................................360

섀도우 ............................................................................................................. 362

정적 객체 ..................................................................................................364

콜라이더 ......................................................................................................... 369

애니메이션 ..................................................................................................... 375

Store in Root 접근 ...................................................................................379

효과음의 추가 ................................................................................................ 385

두 상태 애니메이션의 설정 .......................................................................... 390

유니티의 애니메이션 뷰 활용 ...................................................................... 394

임포트한 애니메이션의 수정 ..................................................................406

다른 객체의 애니메이션 트리거 .................................................................. 411

한계점 ............................................................................................................. 416

정리 ................................................................................................................. 417

x

08장 __ 상태 관리 421가능성의 식별 ................................................................................................ 422

플롯에 대한 소개 .....................................................................................423

진행 과정 ..................................................................................................424

액션 아이템 ..............................................................................................426

스턴트 대역 ..............................................................................................427

플로우 차트의 개발 ....................................................................................... 428

상태 메타데이터 전환 행동의 분리 ........................................................430

상호작용 및 상태의 정의 .............................................................................. 431

상태 전환의 시각화 .................................................................................431

상태 다이어그램 ......................................................................................436

결과의 판단 .................................................................................................... 439

조회 테이블 .................................................................................................... 440

문자열 파싱 .................................................................................................... 443

객체 조회 스크립트 ....................................................................................... 445

액션 관련 메시지 ........................................................................................... 456

정리 ................................................................................................................. 458

09장 __ 객체 메타데이터 461상태 관련 메타데이터 .............................................................................462

존재 상태/위치 .........................................................................................464

가시성 타입 ..............................................................................................465

게임 참고 문서 .........................................................................................466

현재 상태 ........................................................................................................ 467

다시 살펴보는 마우스 집기 .......................................................................... 468

메타데이터의 추가 ........................................................................................ 473

정리 ................................................................................................................. 477

xi

10장 __ 메시지 텍스트 479GUI 스킨 ........................................................................................................ 480

운영체제 폰트 지원 .................................................................................483

텍스트 가시성 ................................................................................................ 492

객체 메타 데이터의 활용 .............................................................................. 497

액션의 처리 .................................................................................................... 502

실제 적용 ..................................................................................................509

오디오 관리 ..............................................................................................510

애니메이션의 처리 ..................................................................................512

시작 값의 로드 .........................................................................................517

폰트와 텍스트에 대한 상세 설명 ............................................................522

액션 메시지의 활성화 .............................................................................527

동적인 읽기 시간 .....................................................................................532

마지막 보정 ..............................................................................................534

정리 ................................................................................................................. 537

11장 __ 아이템 저장소 로직 539레이어 ............................................................................................................. 539

커서 변환 ........................................................................................................ 544

몇 가지 개선점 .........................................................................................549

아이템 저장소 화면 ....................................................................................... 552

조회 테이블의 확장 ....................................................................................... 564

디버깅 .......................................................................................................568

아이템 저장소 아이콘의 추가 ...................................................................... 569

2D 객체의 처리 ............................................................................................. 579

정리 ................................................................................................................. 585

xii

12장 __ 아이템 저장소 관리 587태그 ................................................................................................................. 597

아이템 저장소 레이아웃 ............................................................................... 600

아이템 저장소 오버플로우 ........................................................................... 604

한계 범위 설정 ............................................................................................... 611

아이템 그리드 저장소의 제한 .................................................................613

화살표 제한 ..............................................................................................617

아이템 저장소에서의 객체 추가 및 제거 .................................................... 620

아이템 저장소에서의 객체 제거 .............................................................620

아이템 저장소에 객체 추가.....................................................................624

아이템의 조합 ..........................................................................................626

잘못된 집기 ..............................................................................................628

정리 ................................................................................................................. 633

13장 __ 기본 기능 마무리 6353D 객체 가시성의 처리 ................................................................................. 635

키 프레임 없는 페이드 효과의 개발 .......................................................640

가시성 변경으로 인한 부작용 .................................................................642

콜라이더 처리 ..........................................................................................644

일치하는 커서가 없는 경우의 처리 ........................................................648

랜덤 응답 ........................................................................................................ 649

3D 장면에서의 커서 드롭 ............................................................................. 657

가시성 제어 함수의 개발 ........................................................................663

다시 살펴보는 액션 메시지.....................................................................666

페이드 효과의 재확인 .............................................................................671

객체 간 상호작용 ........................................................................................... 673

장면상의 객체 배치 .................................................................................680

xiii

특수 사례 ........................................................................................................ 685

확장 가능 코드 .........................................................................................685

상태 변화가 없는 응답 ............................................................................687

보물 상자 시퀀스의 활성화.....................................................................689

읽을 자료 ..................................................................................................699

메시지 숨기기 ..........................................................................................707

정리 ................................................................................................................. 709

14장 __ 게임 요구사항 다루기 711드롭 박스 ........................................................................................................ 711

꽃 살리기 ..................................................................................................722

절두체 컬링 ..............................................................................................727

묘약병 붓기 ..............................................................................................729

묘약병의 가시성 문제 해결.....................................................................732

마법 일으키기 ..........................................................................................732

게임 객체의 소멸 처리 ............................................................................738

프리팹의 활성화 ......................................................................................740

카메라 포커스 ................................................................................................ 742

카메라 위치 조정 메타데이터 .................................................................745

카메라 강제 위치 조정 스크립트의 작성 ...............................................748

최종 에셋의 임포트 ....................................................................................... 755

Structures 불러오기 ................................................................................755

재료와 광원 매핑 .....................................................................................758

지하 .........................................................................................................764

사원 속으로 ..............................................................................................770

홀로그램 이미지 ......................................................................................775

발코니 .......................................................................................................780

토피 열매 얻기 .........................................................................................782

재미 요소들 ..............................................................................................793

xiv

폭포 .........................................................................................................796

재단의 가디언 ..........................................................................................802

가디언 .......................................................................................................807

정리 ................................................................................................................. 814

15장 __ 미로와 최종 레벨 817미로의 기하 ..............................................................................................817

미로의 관리 ..............................................................................................823

드롭 지점 ..................................................................................................826

트랩 검사 ..................................................................................................831

빼앗긴 무기 ..............................................................................................834

나머지 가능성의 처리 ................................................................................... 837

사용자 재설정 ..........................................................................................837

서랍 활성화 ..............................................................................................840

이스터 에그 ..............................................................................................848

동굴 입구 ..................................................................................................851

최종 레벨 ........................................................................................................ 854

트리 생성기 ..............................................................................................854

서 있는 비석 .............................................................................................857

상급 .........................................................................................................859

바람의 손길 ..............................................................................................860

최종 지형 ..................................................................................................861

최종 시퀀스 ..............................................................................................867

환경 효과 ..................................................................................................872

애니메이션 이벤트 ..................................................................................876

반짝이는 효과의 추가 .............................................................................879

여러 개의 토피 열매 ................................................................................881

레벨 로드 ..................................................................................................887

정리 ................................................................................................................. 889

xv

16장 __ 메뉴와 레벨 891메뉴 접근 - 소메뉴 ....................................................................................... 891

확인 대화상자 .........................................................................................896

메뉴 모드의 추적 ....................................................................................899

메인 메뉴 .................................................................................................902

설정 메뉴 .................................................................................................907

플레이어 설정 .........................................................................................910

컨트롤 채우기 .........................................................................................913

색상 설정 ..................................................................................................917

오디오 마무리 ............................................................................................... 924

효과음 ......................................................................................................925

배경음 ......................................................................................................927

음악 ........................................................................................................929

음성 또는 대화 볼륨 ...............................................................................932

메뉴용 커스텀 스킨 ...................................................................................... 934

장면 이동과 장면 내 상호작용 중단 및 메뉴 마무리 ...........................938

실시간 배경 .............................................................................................941

시작 메뉴/레벨 ............................................................................................. 945

배경의 관리 .............................................................................................947

레벨 변경 .................................................................................................953

저장/불러오기 .............................................................................................. 955

게임 데이터의 저장 ................................................................................960

저장된 데이터의 로드 ............................................................................964

정리 작업 .................................................................................................970

마침내, 다시 처음으로 ................................................................................. 975

이제 게임이 완성됐나? ................................................................................ 986

최종 작업 ....................................................................................................... 990

퍼블리싱 ..................................................................................................991

퍼블리싱 ........................................................................................................ 992

정리 ................................................................................................................ 994

xvi

17장 __ 기본 지식 넘어서기 997추가 기능 ........................................................................................................ 997

HUD 점수/순위 .......................................................................................997

힌트/난이도 ..............................................................................................999

여러 번의 저장 기능 ..............................................................................1001

물리 이론과 발사체 ...............................................................................1002

데이터 보관 ............................................................................................1002

추가 콘텐츠 ............................................................................................1004

1인칭에서 3인칭으로의 전환 ..................................................................... 1004

캐릭터 .....................................................................................................1005

카메라 .....................................................................................................1007

캐릭터 대화 ............................................................................................1008

대화 트리 ................................................................................................1009

캐릭터 대안 ............................................................................................1014

모바일 플랫폼에 대한 디자인 고려사항 ................................................... 1015

라이선스, 하드웨어, 셋업 .....................................................................1016

스크립트 작성 ........................................................................................1018

내비게이션과 입력 ................................................................................1019

셰이더와 텍스처 ....................................................................................1021

다각형 개수 ............................................................................................1022

배치 처리 ................................................................................................1023

콜라이더 .................................................................................................1025

메뉴와 GUI ............................................................................................1026

기타 사항 ................................................................................................1026

디자인 문서 .................................................................................................. 1027

간략한 스토리 ........................................................................................1028

상세 스토리 ............................................................................................1028

게임의 목적 ............................................................................................1032

게임의 타깃 플랫폼 ...............................................................................1032

xvii

차별성과 시장성 ...................................................................................1032

조작과 장면 이동 ...................................................................................1032

게임 방식 ................................................................................................1033

평가 방식, 점수 계산, 게임에 이기는 법 ..............................................1035

레벨 설계 ................................................................................................1036

시각 스타일 ............................................................................................1036

사용자 인터페이스 ................................................................................1036

캐릭터와 액션 객체 ...............................................................................1037

환경과 비상호작용 객체 .......................................................................1038

효과음 .....................................................................................................1039

음악 .......................................................................................................1039

음성 .......................................................................................................1039

정리 ............................................................................................................... 1039

부록A _ SSE 셰이더 그래프 1043SSE BetterLightmap 셰이더 그래프 .......................................................... 1043

SSE Re�ectiveAlpha 셰이더 그래프 ......................................................... 1044

SSE Re�ectiveCutout 셰이더 그래프 ........................................................ 1045

부록B _ 키 코드 1049

찾아보기 1054

xviii

이 책을 쓰겠다는 얘기를 얼마나 오랫동안 하고 있었는지

내게 계속해서 상기시켜준 필립에게

xix

•옮긴이 글•

유니티 3D는 강력하고 사용하기 쉬운 엔진으로 프로그래밍에 익숙하지 않은 디자이너들조차도

손쉽게 게임을 만들 수 있게 도와준다. 하지만 게임을 만들다 보면 엔진의 지원 기능 부족보다는

스크립트 지식 부족으로 인해 개발에 어려움을 겪는 일이 많다. 이 책에서는 디자이너 관점에서

한 번에 조금씩 스크립트를 소개하고, 재사용할 수 있는 스크립트를 기반으로 유니티 3D를 대상

으로 하는 게임 프레임워크를 만든다. 또 줄거리가 있는 게임을 조금씩 완성해 가면서 어드벤처

게임을 통해 살펴볼 수 있는 다양한 이슈들(이를테면 아이템의 상태 관리, 아이템 저장소 기능,

레벨 변화 등)을 자세히 살펴보고, 새로운 이슈가 나올 때마다 프로그래머 관점이 아닌 디자이너

관점에서 손쉽게 문제를 해결하는 법을 알려준다.

캐주얼 게임이 대세인 요즘 어드벤처 게임이란 장르는 조금 거리감이 느껴질 수 있다. 하지만

어드벤처 게임은 그 방대한 스케일만큼이나 다양한 이슈들을 포괄하고 있으므로 게임 개발과

관련한 주제로 다루기 안성맞춤이다. 예를 들어 어드벤처 게임에서 자주 등장하는 아이템의 상

태 관리 로직은 캐주얼 게임이든, 1인칭 슈팅 게임이든, 플랫폼 점프 게임이든 모두 필요하다. 이

책에서는 다른 게임에서 충분히 재사용하고 확장할 수 있도록 메타데이터를 기반으로 게임의 상

태를 관리한다. 또 다양한 테스트 시나리오를 기반으로 디자이너나 프로그래머가 스크립트 기

능을 추가할 때 항상 테스트를 통과할 수 있게끔 해준다. 이 책을 통해 독자들은 직접 작성한 스

크립트와 직접 수행한 테스트를 통해 스크립트에 대한 감을 익힐 수 있음은 물론, 유니티의 모범

개발 기법인 프리팹을 활용해 여러 객체를 재사용하고, 궁극적으로 이를 기반으로 제 2, 제 3의

게임을 개발할 수 있는 토대를 마련할 수 있다.

이 책에서는 유니티 3D와 관련한 거의 모든 주제를 다룬다. 그중에는 유니티의 기본 사용법부

터 기초 스크립트 작성법, 실행 흐름, 3D 객체의 사용법, 콜라이더를 활용한 충돌 감지와 스턴트

대역을 활용한 효과적인 접근 방법 등 거의 모든 내용이 포함된다. 또 이 책의 문제 접근 방식은

유니티 3D 초보자가 처음 유니티 3D를 배울 때 겪기 쉬운 다양한 문제점을 짚어주고 이를 디자

xx

이너 관점에서 가장 쉽게 해결할 수 있는 해결책을 제시하는 방식으로 진행된다. 이 책은 유니티

3D 프로그래밍을 전문적으로 다루는 책은 아니지만, 이 책을 통해 독자들은 프로그래밍 배경

지식이 있든 없든 유니티 3D 게임을 개발할 때 필요한 스크립트 지식을 충분히 익힐 수 있다.

이 책의 대상 독자

이 책은 유니티 3D를 통해 게임을 개발하려고 하는 2D 또는 3D 디자이너, 다른 플랫폼에서 게

임을 개발한 경험이 있는 개발자, 게임 개발에 필요한 사항을 전체적으로 살펴보고 싶은 게임 기

획자, 그 외 유니티 3D를 통해 게임을 만들어 보고 싶은 모든 독자를 대상으로 한다. 이 책에서

는 스크립트 지식을 전혀 전제하지 않는 만큼 유니티 3D를 처음 접하는 독자나 프로그래밍 경험

이 전혀 없는 독자라도 책의 내용을 이해하는 데는 무리가 없다.

감사의 글

먼저 오랜 번역 기간에도 묵묵히 기다려준 위키북스 박찬규 사장님, 김윤래 팀장님께 감사드린

다. 그리고 사랑하는 가족과 하나님께도 감사드린다.

- 유윤선

xxi

•저자 소개•

수 블랙먼 (Sue Blackman)

수 블랙먼은 3D 아티스트이면서 인터랙티브 애플리케이션 개발자이

며, 남부 캘리포니아에서 강사로도 일하고 있다. 그녀는 Art Institute of

California 같은 최고 수준의 커뮤니티 칼리지와 사립 학교에서 10년 넘게

아티스트를 대상으로 3ds 맥스와 게임 수업을 가르쳤으며 액티비전의 자회

사 중 한 곳에서 게임 관련 3D 아티스트 리더로 근무했다. 그녀는 보잉, 레

이시언, 노스톱 그루먼 같은 포천 1000 기업에서 게임에 기반한 형식을 통해 기능성 게임과 훈련

프로그램을 개발하는 데도 참여했다. 수 블랙먼은 거의 10년째 실시간 3D 엔진의 상업용 개발

관련 일을 하고 있다. 그녀는 10년 넘게 여러 권의 3ds 맥스 책에서 아트워크 작업을 도와주거나

집필에 기여하는 작가로 활동했으며 업무용 3D 게임 프로그램의 교육 메뉴얼을 작성하는 등 왕

성한 활동을 하고 있다. 또 그녀는 자신이 가장 좋아하는 주제 중 하나인 기능성 게임에 대한 글

을 ACM Siggraph에 기고하기도 했다. 그녀의 웹 사이트는 www.3dadventurous.com이다.

xxii

•기술 감수자 소개•

피터 라리베르트 (Peter Laliberte)

피터 라리베르트는 유니티 3D를 중심으로 게임 개발을 가르치는 데

초점을 맞춘 burgzergarcade.com 웹사이트를 운영한다. 아이폰 개

발에 오브젝티브C를 사용해보고 약 2년 전 유니티 3D로 넘어온 후

로는 그 후로 오브젝티브C는 다시 쳐다보지도 않는다. 유니티 3D를

사용하는 것 외에 그는 C/C++, PHP, 자바 같은 일부 프로그래밍 언어에 대해서도 숙련된 지식

을 갖고 있다. 복잡한 게임 방식을 구현하다가 여가 시간이 조금 생기면 그는 자신의 두 살 난 아

들과 부인과 함께 밖에서 시간을 보내는 것을 좋아한다.

로버트 리드 (Robert Reed)

로버트 리드는 현재 아리조나 피닉스에 있는 콜린스 대학에서 게임

설계를 공부 중이며 2011년 3월 졸업할 예정이다. 로버트는 1년 만에

자바스크립트와 유니티 3D를 빠르게 배웠으며 이 책의 내용을 무척

이나 좋아한다.

xxiii

•감사의 글•

이 책의 게임 방식에 대해 많은 의견을 준 가브리엘 아코스타와 제니 웽에게 감사한다. 특히 제니

는 시작 메뉴와 비석에 대한 아이디어를 줘서 더욱 고맙다.

또 사원의 음악과 카메라 강제 위치 조절 코드에 도움을 준 브라이언 테일러와 바이너리 소나

타 스튜디오의 숀 맥커리에게 감사하고 사원을 지키는 가디언의 음성을 (세 가지 버전으로) 제공

해준 다니엘 버틀러에게도 감사하다.

자신의 게임 프로젝트를 진행하느라 바쁜 와중에도 시간을 내서 내게 도움을 준 모든 사람들

에게 감사를 드린다. 여러분이 준 에셋, 아이디어, 열정에 큰 고마움을 표한다.

xxiv

xxv

소개

이 책을 쓰는 이유

실시간 3D 게임이 나온 지도 10년이 훨씬 지났다. 우리는 지난 10년간 이런 게임을 즐기고, 좋아

하는 스타일대로 게임 에셋을 만들었으며, 일부 게임은 직접 수정하기도 했다. 하지만 최근까지

도 이런 고급 게임 엔진의 라이선스를 얻는 비용은 타이틀당 수십만 달러에서 수백만 달러에 달

했다. 이로 인해 자신만의 3D 게임을 만들겠다는 꿈은 이룰 수 없는 환상에 그치기 일쑤였다.

하지만 이제 시대가 변했다. CG(컴퓨터 그래픽)를 활용한 다양한 영화에서 볼 수 있듯이 이제

3D는 영화 산업뿐 아니라 게임 산업에도 깊숙히 침투하고 있다. 이제 캐주얼 게임마저도 2D가

아닌 3D 게임으로 바뀔 정도로 3D는 일반적인 추세다. 강력한 유니티 엔진을 무료 버전으로 제

공하는 과감한 시도와 더불어 고급 엔진의 가격 모델이 크게 낮아짐에 따라 게임 3D 산업은 큰

변화를 맞이했다. 이제 여러분의 멋진 아이디어를 실제 동작하는 프로토타입은 물론 마켓에서

팔 수 있는 상품으로 만드는 데 더 이상 3D 엔진의 비용이 걸림돌이 되지 못한다.

여러분이 캐주얼 게임에 관심이 있든 또는 더 큰 목표를 갖고 있든, 과거 스크립트 작성 경험이

없지만 아트워크와 게임 스토리를 실제 게임으로 구현하고 싶은 열정만은 가득찬 독자라면 이

책은 바로 여러분을 위한 책이다. 현대 게임 엔진에서는 무거운 프로그래밍은 모두 엔진에서 처

리하고 전통적인 프로그래밍 지식 대신 창의성을 갖춘 사람들이 게임 로직과 게임 방식만을 스

크립트로 처리하게 한다.

이 책에서는 3D 아티스트의 관점에서 게임을 개발하고 설계하는 접근 방식을 사용하고 게임

로직과 스크립트에 대해 조금씩 언급함으로써 아티스트와 초보 게임 디자이너, 초보 프로그래

머가 게임 엔진에 대한 개념도 함께 익힐 수 있도록 했다.

이 책은 프로젝트 기반으로 작성됐으므로 이 책을 통해 독자들은 다른 게임에 재사용할 수 있

는 게임 및 스크립트 자원뿐 아니라 개발 과정에서 필요한 설계 결정을 직접 경험할 수 있다. 이

책에서는 기본적인 내용부터 시작해 게임을 개발하고 기능을 추가하면서 게임을 다듬는다. 내

부 로직과 실시간 게임 개념에 대해서는 책의 내용이 진행되는 동안 계속해서 설명한다.

xxvi

이 책의 프로젝트는 1인칭 포인트 클릭 어드벤처 게임을 기반으로 하며 아이템 저장소, 상태

관리, 로드/저장 기능, 게임의 시각적 강조 요소를 모두 갖춘 게임이다. 독자들이 1인칭 슈팅 게임

매니아라 하더라도 이 책을 읽다 보면 재미있는 과제와 기능을 추가해 게임 장르를 어떻게 개선

할 수 있는지 배울 수 있을 것이다.

이 프로젝트의 목적은 설계 결정과 문제 해결의 논리적인 과정을 보여줌으로써 단순히 어드벤

처 게임 장르를 다루는 것보다 더 많은 것을 독자들이 배울 수 있게 하는 것이다. 이 과정을 통해

독자들은 게임을 개발하고 완성할 수 있는 기본 골격과 방법론을 배울 수 있다. 독자들은 기본

적인 유니티의 기능과 표준 에셋 활용법을 뛰어넘어 온라인 튜토리얼이나 다른 책에서는 거의 다

루지 않는 주제들을 배우게 될 것이다. 이 프로젝트를 완성하는 데 필요한 에셋은 모두 이 책에서

제공한다.

책에 대한 저자의 짧은 소개

최근 게임 수업에서 필자는 레이싱 게임, 1인칭 슈팅 게임, 플랫폼 점프 게임을 마친 후 마지막 프

로젝트로 전통적인 어드벤처 게임이 좋겠다고 판단했다. 그런데 필자의 수업을 듣던 학생들은 설

계 결정과 게임에 포함된 로직들에 대해 예상보다 훨씬 더 적극적인 반응을 보였다. 당시에는 어

드벤처 장르에 대한 튜토리얼이 없었으므로 우리는 처음부터 게임을 개발했고, 이전 프로젝트에

서 스크립트 코드를 빌려오고 일부 스크립트는 직접 만들기도 하면서 유니티 커뮤니티의 지식

기반을 점차 늘려갔다. 이 책은 이런 경험을 통해 나온 책이며, 다른 사람의 필요를 채우고 우리

가 겪은 모험을 공유하고자 집필하게 됐다.

전통적인 어드밴처 게임

이 책의 프로젝트에서는 전통적인 포인트 클릭 어드벤처 게임의 변종을 개발한다. 다양한 변종

이 존재하는 어드벤처 게임은 아티스트나 스크립트 작성 경험이 거의 없는 사람들이 게임 개발

을 시작하기에 더 없이 좋다. 이런 게임에서는 게임의 스토리와 아트 에셋, 애니메이션이 게임의

핵심 요소이며, 비교적 느린 게임 흐름으로 인해 빠른 플레이어 반응 시간이 필요한 게임과 달리

스크립트 최적화에 대한 부담이 적다.

어드벤처 게임에서 가장 재미있는 게임 요소 중 하나는 아이템을 모으고 여러 객체 조합을 사

용하는 것이다. 어드벤처 게임에서는 아이템 저장소와 상태 관리가 중요하므로 이 책의 몇 장은

xxvii

이에 대한 설계와 구현에 전 장을 할애하고 있다. 초보 유니티 개발자들은 커뮤니티 포럼에 이런

기능들을 어떻게 구현하는지 종종 질문을 남기곤 하지만 주제의 범위가 방대하므로 거의 답을

없지 못한다. 이 책을 다 끝마칠 즈음에는 이런 게임을 구현하는 데 필요한 스크립트와 기본 개

념, 경험을 충분히 쌓아 이 장르뿐 아니라 다른 장르의 게임도 충분히 만들 수 있을 것이다.

또 인터랙티브 어드벤처 게임은 인디 개발자들에게도 적합하다. 이들 게임은 다양한 플레이어

층이 좋아한다. Tell Tale Games의 원숭이 섬의 비밀이 올해 가장 많이 팔린 캐주얼 게임 중 하

나라는 사실은 루카스아츠 시리즈 원작을 통해 쌓은 어드벤처 게임의 인기를 다시 한 번 증명하

고 있다.

유니티 게임 엔진에 대한 소개

유니티는 소규모 스튜디오, 인디 개발자, 또 우리처럼 항상 자신만의 게임을 만들고 싶어 했던 사

람에게는 최선의 선택이다. 유니티의 넓은 사용자층(2011년 4월 기준 400,000명 이상)과 왕성한

사용자 커뮤니티 덕분에 새로 유니티를 시작하는 사람이든 유니티를 오래 사용한 베테랑이든

쉽고 빠르게 답을 얻고 정보를 공유할 수 있다.

유니티는 적절한 가격 정책으로 기능 균형을 맞춘 입문용 제품을 제공한다. 유니티의 무료 버

전은 사람들이 비용을 전혀 지불하지 않고 유니티를 실험하고, 배우고, 개발해 게임을 팔 수 있

게 해준다. 막강한 기능을 제공하는 프로 버전은 로얄티 프리 버전으로, 사람들이 최소한의 비용

만 지불하고 캐주얼 게임 마켓에서 게임을 팔 수 있게 해준다.

멀티 플랫폼 게임 시장, 특히 아이폰용 캐주얼 게임 시장은 현재 큰 인기를 얻고 있으며 유니티

의 크로스 플랫폼 지원은 이미 그 품질이 충분히 증명됐다. 본래 맥 기반의 저작 애플리케이션

으로서 맥과 윈도우용으로 배포가 가능했던 유니티는 2009년 봄 윈도우 버전을 발표했다. 이를

통해 PC 기반의 개발자와 아티스트에게는 새로운 기회가 열리게 된다. 이후 유니티는 계속적으

로 지원 기능을 추가해 아이폰, 안드로이드, 아이패드, 위(Wii)를 지원했으며 현재 Xbox 360과

PS3에 대한 지원 기능을 개발 중이다. 무료로 제공되는 유니티 웹 플레이어는 이미 설치 횟수가

3,500만을 넘어섰다.

유니티 엔진의 초기 사용자는 주로 플래시와 디렉터에서 넘어온 사용자로서, 유니티의 스크

립팅 환경이 익숙한 사람들이었다. 유니티 사용자 중 이와 같이 액션스크립트로 플래시 게임

을 만들던 사람들이 많은 게 사실이지만 이런 배경 지식이 꼭 필요하진 않다. 유니티에는 1인칭

xxviii

슈팅 게임, 레이싱 게임, 플랫폼 점프 게임 등 다양한 게임을 만들 수 있는 많은 재료가 있다. 설

사 다른 게임 제작에 관심이 있다 하더라도 이런 게임들을 만드는 법을 살펴보면 예상치 못한

곳에서 많은 도움이 되는 팁을 얻을 수 있다. 유니티 웹 사이트(www.Unity3D.com), 유니티 포

럼(forum.unity3d.com), 위키(www.unifycommunity.com/wiki), UnityAnswers(answers.

unity3d.com), 기타 유니티 엔진과 관련한 개인 웹 사이트에서 얻을 수 있는 자료들을 활용하는

것을 주저하지 말자.

유니티 문서에는 다양한 값진 정보가 담겨 있지만 고유 어휘를 사용하는 기술이 항상 그렇듯

때로는 찾는 정보를 바로 찾아내기가 쉽지 않다. 때로는 찾고 있는 단어 앞에 Unity3D를 붙이고

인터넷에서 단어를 검색하면 헷갈리기 쉬운 개념이나 기능을 가장 쉽게 찾을 수 있다. 이런 검색

은 Help 메뉴를 통해서도 할 수 있지만 때로는 온라인 도움말을 활용하는 게 더 빠를 수도 있다.

스크립트를 꼭 배워야 하나?

유니티로 자신만의 게임을 만들기 위해 꼭 프로그래머가 될 필요는 없다. 하지만 원하는 목적에

맞춰 수정할 부분을 파악하거나 특정 스크립트가 게임에 적합한지 판단할 수 있으려면 스크립

트가 하는 일 정도는 충분히 이해해야 한다.

대부분의 게임 플레이는 유니티에서 스크립트로 작성해야 하지만 이미 바로 재사용할 수 있는

스크립트가 수백 개나 나와 있다. 유니티에서는 유용하게 활용할 수 있는 스크립트 몇 종류를 기

본으로 제공한다. 또 포럼, 위키, UnityAnswers 등을 검색하면 더 많은 스크립트를 찾을 수 있다.

아울러 포럼에는 스크립트 작성에 익숙하지 않은 사용자들을 위해 간단한 스크립트를 직접 작

성해주는 사람들도 많이 있다. 포럼의 Collaboration 섹션에서는 아트 디자인을 제공해주는 대

가로 스크립트를 작성해줄 사람을 찾을 수도 있다. 이 책을 끝마칠 즈음 독자들은 유니티 커뮤니

티의 이런 다양한 자료를 폭넓게 활용하는 법을 배울 수 있을 것이다.

게임은 기본 정의상 사용자 상호작용과 관련 있다. 물리 이론에 의해 게임 내용이 결정되는 게

임이라 하더라도 로직에 기반해 인과 관계가 발생한다는 점에서 선형적인 플롯 중심의 수동적

미디어와는 차이가 있다. 가장 '아티스트적인' 게임 엔진이라 하더라도 기본적인 환경 설정을 넘

어서려면 스크립트가 필요하다. 이 책의 목적은 최대한 자주 시각적인 피드백을 제공함으로써

한 번에 조금씩이라도 독자들이 스크립트에 익숙해지게끔 하는 것이다. 이 책에서는 독자들이

아직 스크립트를 배우기로 마음먹지는 않았지만 게임 개발에 참여할 마음가짐은 충분하다고 가

정한다.

xxix

스크립트는 구문보다는 로직이다

많은 사람들이 새 언어를 배우는 게 어렵고 두렵다고 걱정하는데 이런 식으로 생각하면 어떨까?

35세 미만의 사람들은 대부분 글을 잘 쓴다. 글은 우리가 쓰는 모국어의 하위 단위다. 글은 어느

정도까지 자체 어휘와 구문을 갖고 있지만 전혀 새로운 언어라기보다는 우리가 쓰는 언어의 하위

단위라는 점에서 스크립팅 언어와 비슷한 면이 있다.

주된 차이점은 '언어'를 배우는 데 필요한 방법뿐이다. 글을 배울 때는 모국어를 배울 때처럼

학습하거나 언에 자체를 배우지 않는다. 대신 반복적인 접촉과 시행착오, 암기와 시험이 아닌 다

른 수동적인 방식을 통해 언어를 흡수하고, 실험하고, 마침내 익숙해진다. 이 책은 게임 설계 및

제작과 관련한 내부 로직을 다루는 책이므로 스크립트 작성을 게임 개발 과정에서 꼭 경험해야

할 사항으로 가정하며, 스크립트에 대한 지식을 포괄적으로 다룬다. 독자 여러분은 이런 스크립

트에 얼마만큼 참여할지 스스로 결정할 수 있다. 독자 여러분이 어떤 선택을 하든 이 책에서 개

발하는 메인 스크립트는 여러분이 이 책의 최종 게임을 개발하고 자신만의 아이디어와 아트 에

셋을 토대로 이를 확장할 수 있게 도와줄 것이다.

이와 별개로 스크립트에서 일어나는 동작을 이해하기 위해 알아야 할 주요 개념과 키워드는

몇 개에 지나지 않는다. 다행히 대부분의 스크립트 작성자는 코드에서 하는 동작을 잘 설명해주

는 주석을 충실히 작성하고 있으므로 전체 스크립트를 만드는 일도 생각보다 어렵지 않다.

이 책에서 개발한 스크립트는 장 단위로 제공되며 스크립트에 사용된 로직도 장 단위로 설명

한다. 하지만 필자는 여러분이 마치 어드벤처 게임의 주인공처럼 호기심을 발휘해 각 스크립트의

설명을 토대로 자신만의 스크립트 실험을 직접 해 볼 것을 권장한다.

수학에 대한 고민

우리가 3D 산업과 관련해 가장 많이 듣는 얘기 중 하나는 “수학이 쓸 데가 이렇게 많은 줄 알았

다면 수업 시간에 좀 더 집중할 걸” 하는 얘기다. 그럼에도 대부분의 아티스트와 디자이너는 자

신의 수학 실력을 가다듬기 위해 시간을 투자하기를 꺼려한다. 하지만 걱정하지 않아도 된다. 필

자의 주된 목적은 여러분이 게임을 만들 수 있게 하는 것이다. 이 책에서 만들 게임에 적용할 기

능 중 일부는 동작 방식을 전혀 모르더라도 쉽게 사용할 수 있는 것들이다. 우리 같은 사람들은

대부분 내부 연소 엔진의 동작 원리를 모르더라도 차를 운전하는 데 아무 지장이 없다. 스크립트

또한 마찬가지 방식으로 접근하면 된다.

xxx

이 책의 기본 가정과 선행지식

이 책에서는 여러분이 3D 에셋과 3D 공간에 대해서는 최소한 어느 정도 익숙하다고 가정한다.

하지만 이런 가정과 상관없이 책 전반에 이에 대한 짧은 개념 소개와 다양한 팁을 포함하고 있다.

이 책에서는 여러분이 스크립트 작성 경험이 많지 않지만 실제 게임을 만들기 위해 이를 배울

의사가 충분히 있다고 가정한다.

이 책에서는, 적어도 현재까지는, 여러분이 유니티 게임 엔진을 사용해본 경험이 거의 없다고

가정한다.

이 책에서는 여러분이 게임 제작을 거의 처음 해보지만 실시간 3D 게임을 만들고 싶은 욕심만

은 충분하다고 가정한다.

아울러 이 책에서는 전통적인 포인트 클릭 어드벤처 게임 이외의 장르를 고려 중인 독자라면

책에서 소개하는 다양한 기법을 다른 장르에 어떻게 접목할지 생각하면서 책의 내용을 살펴본

다고 가정한다. 캐주얼 게임 시장에서 어드벤처 게임, 1인칭 슈팅 게임, 다른 장르의 게임 요소를

적절히 혼합할 경우 사용자들이 이를 반길 뿐 아니라 매우 재미있는 오락 요소를 지닌 게임을 만

들 수 있다.

이 책에서 다루지 않는 내용

이 책은 일반적인 게임 설계와 관련한 책이 아니다. 이 책은 독자들이 게임의 필요를 분석하고 여

러 선택 사이의 경중을 따지는 습관을 들일 수 있도록 도와주는 책이다. 혼자 모든 게임을 구현

해야 하는 상황에서 방대한 디자인 문서를 작성하는 일은 어렵게 느껴질 수밖에 없으며, 게임 엔

진에 좀 더 익숙해지고 여러분 스스로 기능을 익히기 전까지는 이런 작업이 불가능에 가깝다. 이

책에서는 한 번에 조금씩 게임을 개발하고 책의 내용이 진행되는 동안 아이디어와 기능을 프로

토타입 형태로 구현한다.

이 책은 프로그래머가 되는 법을 알려주는 책이 아니며 모범 프로그래밍 기법을 알려주는 책

은 더더욱 아니다. 이 책의 스크립트는 프로그래머가 아닌 사람들이 최대한 쉽게 시각적인 피드

백을 확인할 수 있게끔 설계됐다. 이와 동일한 결과를 여러 가지 다른 방식으로도 얻을 수 있지

만 이 책에서는 아티스트나 디자이너 관점에서 가장 쉽게 읽고 이해할 수 있도록 스크립트를 작

성했다. 이 책에서 스크립트는 모국어 사용자가 언어를 익히는 것처럼 자연스럽게 제공한다. 독

xxxi

자들은 이런 언어 환경에 항상 노출돼 있고 기본적인 지식을 배울 때까지 천천히 언어를 사용하

는 법을 익히게 될 것이다. 이 과정에서 모든 내용을 기억하려고 애쓰지 않아도 된다. 일부 스크

립트는 프로젝트에서 내내 사용할 것이고 일부 스크립트는 나중에 참조하기 위해 메모만 해두면

된다.

이 책의 조판 관례

1. 지시문은 다음과 같다.

팁

이 형식을 따라 한다.

코드는 다음과 같이 표시한다.

function Update ()

플랫폼

이 책은 윈도우 7과 윈도우 XP 환경에서 유니티 3.x를 사용해 작성했다. 맥에서의 유니티 단축키

와 운영체제의 파일 저장소 차이는 이 책에서 별도로 언급한다.

소스 코드

이 책의 에셋 등 소스코드는 아래 Apress 출판사 사이트에서 내려받을 수 있다.

■ http://www.apress.com/downloadable/download/sample/sample_id/1163/

위키북스 홈페이지에서도 내려받을 수 있다.

■ http://www.wikibook.co.kr/wiki/Wiki.jsp?page=BeginningUnity3D

Beg

inni

ng 3

D G

ame

Dev

elop

men

t w

ith U

nity

1

01장르 살펴보기

소개에서 언급한 것처럼 고전적인 포인트 클릭 어드벤처 장르는 게임을 만들 수 있는 풍부한 환

경을 제공함은 물론 다른 유니티 게임 입문서에서 간과하기 쉬운 팁, 트릭, 기법을 살펴보기에도

적합하다.

1인칭 슈팅 게임 등을 한 번도 해본 적 없는 사용자를 비롯해 폭넓은 사용자층에게 어필한다

는 점에서 어드벤처 게임은 캐주얼 게임 시장을 이끌어갈 견인차가 되고 있다. 아울러 사람마다

이 장르에 대해 각기 다른 생각을 갖고 있다는 점에서 어드벤처 게임은 첫 번째 게임으로 만들기

에 딱 좋다.

역사적인 참고 자료

“여러분은 길의 끝에 서 있다...”

다소 논란의 여지가 있을 수는 있지만 모든 어드벤처 게임의 할아버지뻘 되는 게임은 1970년

대 중반 윌 크로우더가 설계한 텍스트 기반의 ‘어드벤처’라는 게임이다. 컴퓨터 게임의 주류가 퐁

과 팩맨이었던 당시에 손 기술이 좋은 사용자 대신 관찰력이 뛰어난 사용자를 대상으로 한 텍스

트 기반의 이 게임은 새로운 계시와도 같았다. Colossal Cave라고도 알려진 초기 버전에서 크로

우더는 두려움을 모르는 탐험가들이 거대한 지하 동굴을 탐험하며 아이템을 모으고 이따금씩

등장하는 괴물들과 싸울 수 있게 장면을 설정했다. 이 장면은 켄터키 주에 있는 거대 동굴을 모

방한 것으로 알려졌으며, 크로우더는 이 장면에서 자신이 직접 동굴을 돌아본 경험과 기존 조사

자료를 연계해 벡터 기반의 지도를 개발했다. 그림 1-1은 어드벤처 게임에서 플레이어가 모을 수

있는 아이템 몇 개를 보여준다.

2 l 시작하세요! Unity 3D 게임 프로그래밍

그림 1-1 ㅣ 어드벤처 게임에서 플레이어가 모을 수 있는 몇 가지 아이템

이 게임의 텍스트는 항상 아름다운 묘사어구로 이뤄져 있으며 게임에 사용된 어휘와 사용자

가 입력한 내용을 파싱하는 과정에서 가끔 매우 재미있는 모습을 보여주기도 한다. 돈 우즈는

1~2년 후 점수 제도와 판타지 분야의 캐릭터를 추가해 원작을 확장했다. 이들 두 요소는 당시 막

꽃을 피우던 어드벤처 장르에서 매우 중요한 첨가 요소가 됐다. 어드벤처 게임에 열정을 갖고 있

던 다른 사람들은 자신들의 소프트웨어 회사를 차렸다. 이 중에는 시에라 엔터테인먼트의 모태

가 된 회사를 설립한 로버타와 켄 윌리엄스 부부와 마크 블랭크, 데이브 르블링, 브루스 다니엘

스, 팀 앤더슨이 만든 조크(Zork) 시리즈라는 장르로 유명한 인포컴이란 회사가 있다.

인포컴의 조크 시리즈는 플랫헤드 왕국이라는 거대한 지하 제국을 우리에게 소개해줬고 이

왕국에서 사용하는 동전인 조크미드(그림 1-2)를 만들어냈다. 이 게임 시리즈는 “램프가 어두워

지고 있다”, “여기서는 그곳으로 갈 수 없다” 등 여러 유명한 어구를 만들어 냈다. 두려움이 뭔지

알고 있는 플레이어라면 이 게임에서 램프가 꺼지면 잡아 먹힐 수 있는 위험에 처한 것을 모두 알

고 있었다. 많은 어드벤처 게임의 퍼즐이 기계적인 수단을 활용하지만 FrobozzCo의 자회사인

Frobozz Magic Company는 다양한 마술 아이템을 도입했다.

01 장르 살펴보기 l 3

그림 1-2 ㅣ 유명한 조크미드 코인

대부분의 텍스트 어드벤처 게임의 공통된 특징으로 이동 수단을 들 수 있다. 게임에서 플레이

어의 위치를 표현하는 데는 플레이어가 환경을 탐험하면서 종이에 그릴 수 있는 동쪽, 서쪽, 남쭉,

북쪽, 위, 아래의 좌표계 방향으로 그려진 출구가 있는 방을 사용했다(그림 1-3 참고). 아이템 저

장소는 다양한 객체를 조합해 로직 기반의 퍼즐이나 기계 퍼즐을 풀어 게임을 진행시키는 데 꼭

필요한 요소로 사용됐다. 이런 아이디어는 큰 인기를 끌어 1980년대 중반에 TV에 방영된 리차드

딘 앤더슨 주연의 맥 가이버에서도 초기 텍스트 어드벤처 게임의 이런 퍼즐을 많이 차용했다.

그림 1-3 ㅣ 플레이어의 손으로 그린 텍스트 기반의 어드벤처 게임의 맵


그래픽 어드벤처

컴퓨터 그래픽이 등장하고 그래픽 품질과 해상도가 점차 발전함에 따라 텍스트 기반의 어드벤처

게임 장르는 인기가 시들었다. 결국 텍스트 기반의 초기 게임들은 스틸 이미지 형식 또는 시에라

온라인의 킹즈 퀘스트, 수많은 루카스아츠 게임들 그리고 인포컴의 조크 타이틀이 주도하는 그

래픽 어드벤처 장르에게 자리를 내주었다.

그래픽 어드벤처 게임은 플레이어가 명령이나 질문을 입력하는 형태의 게임 플레이를 없애고

대신 미리 정해진 간단한 동사와 마우스 집기를 통해 명령을 수행했다(그림 1-4 참고). 이로 인해

아무리 우스꽝스러운 단어라도 마구 입력해 프로그래머가 이런 단어들에 대한 응답조차도 미리

고려했는지 알아볼 수 있었던 초기 텍스트 어드벤처 게임의 묘미는 사라지게 됐다.

그림 1-4 ㅣ 루카스아츠의 인디아나 존스와 아틀란티스의 운명

또 새로운 그래픽 어드벤처 게임에 사용된 재료를 표현하기 위해 이제 작가와 프로그래머보다

더 많은 사람이 필요하게 됐다. 그래픽 어드벤처 게임의 등장으로 아티스트가 게임 제작에서 중

요한 위치를 차지하게 된 것이다. 해상도가 증가하면서 아트 에셋의 해상도도 증가하게 됐다. 그

래픽 게임은 보통 플레이어가 탐험하면서 유용한 객체들을 모으고 문제를 해결하고 최종 게임

목표에 따라 보물과 점수를 취할 수 있는 네 개의 레벨 또는 세계를 갖고 있었다. 레벨이 진행될

수록 더욱더 싸우기 힘든 적 캐릭터가 등장하는 오늘날 1인칭 슈팅 게임의 레벨과는 달리 어드벤

처 게임의 세계는 테마와 시각 스타일, 색상 스키마, 음악 등을 통해 크게 구분된다. 한 레벨을 클

리어할 경우 플레이어에게는 마치 환상 속에 들어온 것처럼 감각을 자극하도록 디자인된 새롭고

흥미로운 레벨 환경이 보상으로 주어진다.


1990년대 초반에 Rand와 Robyn Miller의 Myst는 게임 플레이를 사용해 스토리 자체를 드러

내는 개념을 도입하기 위해 기존 형식에 변화를 주었다. 아이템 획득과 아이템 저장소는 존재하

지 않았지만 상호작용과 퍼즐 해결 과정이 당시로서는 숨죽일 만큼 시각적인 효과를 보여줬다

(그림 1-5). 전통적인 아트워크 대신 3D 그래픽을 최초로 도입한 이들은 이 장르에 또 다른 변화

를 주었다. 이제 게임을 만드는 데 아티스트가 필요할 뿐 아니라 초기 3D 프로그램을 통해 아트

워크를 할 수 있는 아티스트들이 상당수 필요했다.

그림 1-5 ㅣ 3D 그래픽을 사용한 최초의 어드벤처 게임 중 하나인 Myst(Myst는 Cyan Worlds Inc의 독점

적인 자산이다. Copyright 1993, Cyan 2001 Worlds, Inc. All rights reserved. 이 그래픽은 사전 승인을

받고 사용됐다.)

1980년대 후반 액티비전이 인포컴을 인수하면서 Zork Nemesis는 3D 그래픽으로 바뀌지만 어

두워진 스토리와 분위기로 인해 플레이어들의 반응은 제각각이었다. 이 게임 자체는 플레이어들

이 좋아했지만 원작 시리즈와는 거의 연관성이 없었다. 이후 Zork Grand Inquisitor를 통해 스

토리를 원작으로 돌려놓으려고 했지만 일관성 없는 그래픽 품질로 인해 목적을 달성하지 못했다.

이 게임에서 가장 재미있는 부분은 3D 아티스트 에니 오켄이 만든 대학 레벨이다(그림 1-6).


그림 1-6 ㅣ 액티비전의 Zork Grand Inquisitor에서 에니 오켄의 3D 아트워크를 보여주는 장면

시에라 온라인은 킹즈 퀘스트를 통해 다른 방향으로 게임 장르를 이끌었다. 이들 게임에서는

판타지가 전통적인 동화보다 더 가까이 다가왔으며 가브리엘 나이트의 시리즈에서는 초능력 영

역을 주로 다뤘다.

루카스아츠 타이틀

의심할 여지 없이 그래픽 어드벤처 게임 장르의 초창기 시절 루카스아츠는 큰 역할을 차지했다.

전문 영화 제작 인력을 수없이 보유하고 있는 루카스아츠의 타이틀들은 멋진 이야기 전개와 최

고 수준의 그래픽, 그리고 환상적인 사운드트랙으로 인해 큰 인기를 끌었다. 이 중에서도 특히 원

숭이 섬의 비밀 시리즈가 큰 주목을 받았다. 샘과 맥스, Day of the Tentacle 같은 다른 타이틀과

마찬가지로 이들 게임의 재미는 유머, 팝 컬처의 응용, 그리고 터무니없는 이야기를 전개하는 센

스였다.

원숭이 섬의 비밀 3탄인 원숭이 섬의 저주는 전통적인 핸드 페인팅 백드롭과 셀 애니메이션을

사용한 루카스아츠의 마지막 작품 중 하나다(그림 1-7 참고). 하지만 이 게임의 스타일과 전개 방

식은 오래된 게임처럼 보이기보다는 시대를 초월한 듯한 재미를 준다.


그림 1-7 ㅣ 루카스아츠의 원숭이 섬의 비밀 3탄인 원숭이 섬의 저주, 1997년작.

실시간 게임으로의 빠른 변화

게임 산업 분야에서 다음 패러다임 변화는 실시간 환경과 장면 이동이 도입되면서 찾아왔다. 이

쯤 어드벤처 게임광들은 Myst의 후속작인 Riven(그림 1-8 참고) 같은 멋진 그래픽을 기대하게

된다. 당시에는 아직까지도 저해상도의 최저 수준의 그래픽 환경에서 실시간으로 이동하는 것보

다 프리렌더링된 아름다운 세계에서 힘들게 방향을 조정하는 편을 플레이어들이 더 선호했다.

이로 인해 그래픽 어드벤처 장르는 조금 더 오랫동안 살아 남을 수 있었지만 프리렌더링 형식은

결국 경제적인 문제로 인해 마지막 위기를 맞게 된다. 1990년 초기 거대 게임 제작사들은 ID의

둠과 그 후속작인 퀘이크 같은 실시간 1인칭 슈팅 게임에서 훨씬 더 적은 제작 비용을 들여 더 큰

수익을 얻을 수 있는 시장을 보게 된 것이다.


그림 1-8 ㅣ Cyan의 Riven. 프리렌더링 어드벤처 게임의 절정이 된 작품.(Riven(TM)은 Cyan Worlds Inc.

Copyright 1997, 2003 Cyan Worlds, Inc 의 고유 자산이다. 모든 권리는 저작권의 보호를 받으며 이 이미

지는 사전 허가를 받고 사용됐다.)

그로부터 10년이 지난 후 그래픽 품질은 마침내 프리렌더링 표준에 근접하기 시작했으며 다시

어드벤처 게임 장르가 되돌아오고 있다. 하지만 생각지도 못한 곳에서 부활하고 있다. 주요 제작

사(더불어 소프트웨어 회사)들은 이제 더 커졌지만 이제 수백만 카피가 팔리지 않는 게임에 돈을

쓰기를 주저하고 있다. 전통적으로 70,000에서 150,000개 정도가 팔린 다른 장르들은 하나둘

시장에서 천천히 사라졌으며, 이들 게임과 더불어 게임을 팔던 상점들도 하나둘 사라졌다.

어드벤처 게임 장르뿐 아니라 다른 특수 장르가 부활하는 데 영향을 미친 두 가지 요소는 온

라인 시장으로 게임 구매 패턴이 바뀜에 따라 개발자들이 거대 배포사를 거치지 않게 된 요인과

게임을 저작하고 생산할 수 있는 소프트웨어가 더 사용하기 쉬워졌고 가격도 많이 내린 데 있다.

아이폰과 다른 모바일 플랫폼의 등장으로 규모가 커진 캐주얼 게임 시장은 소규모 스튜디오도

성공할 수 있게 해주었고 이로 인해 동기 부여를 받은 개인 개발자들은 전에 없이 게임 시장으로

뛰어들고 있다.

이 장르가 사람들을 끌어들이는 이유

어드벤처 게임 장르가 계속해서 부활하는 이유는 이런 게임이 주는 재미에 대한 사람들의 수요

가 계속해서 있음을 반증한다. 물론 내부 원리를 이해하지 못한 채 어드벤처 게임의 퍼즐 형식


을 그대로 복사할 수는 있지만, 이렇게 만든 게임으로는 사용자를 만족시키기가 매우 어렵다. 하

지만 시간을 갖고 사람들이 어드벤처 게임을 플레이하는 동기를 분석하려고 하면 설계 단계에

서 많은 생각을 해야 한다. 이렇게 사용자들의 동기 분석을 마치고 나면 이후 설계와 개발 과정

은 놀라울 정도로 빨리 진행된다. 어드벤처 게임의 플레이어들은 분노를 표출하거나 게임 플레

이 기술을 가다듬거나 소셜 네트워크에서 새로운 온라인 자아를 만들기 위해 게임을 하는 게 아

니라고 가정할 수 있다. 이런 플레이어들의 동기를 파헤쳐보기 위해 좀 더 생각을 정리해 보자.

일반적으로 사람들이 어드벤처 게임을 플레이하는 이유는 우리의 현실보다 좀 더 재미있고 자

극적인 세계로 탈출하고 싶어서이다. 물론 이런 관측을 게임 제작에 사용하기에는 지나치게 일반

적이라고 볼 수도 있지만, 이런 관측을 시작점으로 삼아 게임 동기를 분석할 수는 있다.

우리는 시간이나 돈의 여유가 없어서 직접 체험할 수 없는 경험을 게임을 통해 하고 싶어 한

다. 원숭이 섬의 비밀은 우리가 쉽게 갈 수 없는 캐리비안 해변을 체험할 수 있게 해줬다. 수천

달러를 들여 실제 경험을 하더라도 만족스럽지 못한 경우가 생기는데, 이 게임에서는 우리가

Guybrush �reepwood를 플레이해 이국적인 문화를 체험하고 주변에 재미있는 장소들을 찾아

다니며 다양한 어려운 상황들에 직면할 수 있었다(그림 1-9 참고).

그림 1-9 ㅣ 루카스아츠의 원숭이 섬의 비밀 3탄(LUCASARTS, A DIVISION OF LUCASFILM

ENTERTAINMENT COMPANY LTD의 사전 승인을 받고 사용)


또 게임에서 우리는 물리적인 또는 사회적인 책임을 지지 않고 가상 체험을 할 수 있다. Fox

Network의 House, M.D.시리즈에서는 House를 ‘여러분이 증오하기 위해 사랑하는 의사’로 선

전한 적이 있다. House를 꼭 증오하지 않더라도 우리들 대부분은 사회적인 규범에 집착하지 않

는 그를 부러워한다. 어드벤처 게임에서 우리는 자유롭게 행동하며 게임의 목적을 이루기 위해

종종 사회적인 도덕을 버리기도 한다. 무단침입을 하거나 대도가 되거나 악당들의 두목이 되는

일은 게임을 끝내기 위해 종종 필요한 일들이다(그림 1-10 참고).

그림 1-10 ㅣ 금기에 대한 유혹. 저 안에 분명 중요한 물건이 있을 텐데...

지적인 자극은 어드벤처 게임광들에게 크게 어필하는 또 다른 요소다. 의심할 여지 없이 이런

특징은 인터랙티브 게임이 영화나 TV 같은 수동적인 미디어와 비교해 갖고 있는 주요 장점 중 하

나다. 최근 연구 조사들은 뇌의 노화를 막으려면 두뇌 활동과 뇌에 대한 자극이 얼마나 중요한

지를 보여주고 있다. 닌텐도 같은 게임 회사는 두뇌 훈련 게임으로 큰 성공을 거뒀으며 이런 두뇌

훈련 게임의 성공은 사람들이 두뇌 활동에 대한 욕구를 잘 대변해준다. 대부분의 사람은 단조로

운 환경에서 머리를 쓰지 않고 게임을 하는 것보다 실현 가능한 해결책이 있는 문제를 제공하는

환경에서 좀 더 노력한다는 사실을 잘 알고 있다. 전통적인 어드벤처 게임은 이런 사용자들의 욕

구를 충족시키는 수단 중 하나다.

이런 게임을 설계하는 과정에서 가장 어려운 점은 해결할 과제의 난이도를 정하는 것이다(그

림 1-11). 텍스트 기반의 단서나 힌트 외에 우리는 얼마나 많은 시각적인 및/또는 청각적인 힌트를

제공할지도 고려해야 한다. 플레이어들은 해결책이 너무 쉬울 경우 게임 치트를 사용한 듯한 느


낌을 받지만, 과제가 지나치게 어려워도 화를 낸다. 보통 인터넷에는 다양한 게임 치트와 해결 방

식이 나와 있다. 이들 정보는 주로 어려운 과제를 스스로 풀기보다는 게임을 빨리 진행하는 데 관

심 있는 사용자들을 위한 것이다. 목표로 하는 게이머들을 대상으로 전체적인 난이도를 어떻게

정할지 결정하는 것 외에 과제의 난이도 수준도 일관성 있게 유지하도록 노력해야 한다. 게임이

끝에 가까이 올수록 게임 난이도를 점차적으로 올릴 수도 있고, 전체 퍼즐 조각이 피날레에서 모

두 제 위치를 찾아 플레이어가 ‘아하!’ 하는 감탄과 함께 그동안 게임을 플레이한 보람을 느낄 수

있도록 모든 난이도를 지휘 조절할 수 있다면 더욱 좋다.

그림 1-11 ㅣ 시각적인 힌트와 텍스트 기반의 힌트 수준. 좌측 상단: ‘설명이 없는 멜론 크기의 바위.’

우측 상단: ‘어떤 글자의 일부가 희미하게 남아 있는 멜론 크기의 이상한 바위.’ 좌측 하단: ‘글자가 깊게 새겨

진 멜론 크기의 바위. 이 바위는 뭔가를 덮고 있는 것처럼 보인다.’ 우측 하단: ‘글자로 덮인 멜론 크기의 바위.

이 바위 주변에는 이상한 녹색 빛이 감돈다. 그 아래로 큰 열쇠가 보인다.’

지적인 자극 외에 우리는 물리적인 위험이나 불편을 감수하지 않고 새로운 경험을 하는 것을

좋아한다. 책, 영화, 텔레비전과 마찬가지로 우리는 극한의 기후 환경에서 자연과 맞서는 것을 상

상하지만 실제로 이런 끔찍한 더위나 몸을 다치게 하는 부상을 통해 물리적인 고통을 겪고 싶어

하지는 않는다(그림 1-12 참고).


그림 1-12 ㅣ 화씨 120도(섭씨 48.8도 정도의 온도다-옮긴이). 그런데도 여러분은 실제로 더위를 못 느낀다.

어드벤처 게임광들은 스스로 소파나 컴퓨터 앞에 편안히 앉아서 가상 세계를 체험하는 사람이

란 것을 인정하기를 꺼려하지 않는다. 1인칭 슈팅 게임팬들과 달리 우리는 현란한 키보드와 마우

스 동작으로 기술을 뽐내려는 게 아니다. 그렇다고 어드벤처 게임에서 괴물과 싸워 이겨야만 다

음 단계로 진행할 수 있는 스토리 전개를 사용할 수 없단 얘기는 아니다. 다만 두 번이나 세 번 노

력해 게임 과제를 해결하고 게임을 계속해서 진행할 수 있는 난이도 수준이 돼야 한다는 뜻이다.

초인만이 넘을 수 있는 절벽을 만나면 우리는 간단한 마우스 클릭으로 초인이 될 수 있어야 한다

(그림 1-13 참고). 이런 물리적인 과제는 키보드나 마우스, 기타 다른 입력 장치의 현란한 동작을

뽐내는 것보다는 스토리를 좀 더 흥미롭게 만드는 데 모든 초점을 맞춰야 한다.

그림 1-13 ㅣ 가능하면 한 번의 마우스 클릭으로 과제를 해결할 수 있게 만든다.


주변 환경을 감상할 시간도 없이 장면을 빠르게 이동하는 게 보통인 1인칭 슈팅 게임과 달리

어드벤처 게임이 사람들에게 관심을 끄는 데는 환경 자체의 풍부한 시각적 표현도 한몫을 한다.

Riven 게임에서는 거의 불가능한 수준으로 품질을 높이긴 했지만 이제 실시간 렌더링을 통한 시

각 품질은 실시간 환경을 사용할 수 있는 수준에 근접하고 있다. 하지만 시각적인 풍부함이 사진

과 같은 실사 묘사에 국한되는 것은 아니다. 나중에 출시된 원숭이 섬의 비밀 에피소드 같은 만

화 스타일의 게임에서 우리가 이상한 식물을 만나고 기발한 건물과 Rube Goldberg 타입의 기계

를 만나더라도 우리의 불신 유예는 그대로 유지된다.

환경이 재미있는 내용으로 채워져 있기만 하면 예술적인 스타일은 별도 요소로 치부된다. 게임

이 아트 누보 시대의 물건들로 가득 채워진 장소에서 진행되든 환상적인 스팀펑크 장면에서 시작

하든, 전쟁으로 폐허가 된 세기말 환경이든 장면을 적절한 소품과 모티브로 채우면 어드벤처 게

이머들은 게임을 진행시키는 것과 상관없이 주변 환경을 돌아다니며 살펴보고 싶어 한다(그림

1-14 참고).

그림 1-14 ㅣ 원숭이 섬의 비밀의 한 장면, TellTalesGames,2009.

스토리도 다양한 과제나 퍼즐을 해결하는 유일한 실마리가 될 수 있다는 점에서 어드벤처 게

임에서 큰 비중을 차지한다. 형식적인 스토리 주도의 전개 방식과 게임을 진행함에 따라 점차 게

임의 목적을 드러내는 전개 방식에 따라 게임의 장면이 다르게 설정될 수 있다. 처음에 뚜렷한 전

개 방식이 없는 게임에서는 계속해서 단기적인 과제를 해결하고 플레이어에게 동기를 부여해 게

임을 진행시킴으로써 플레이어가 여러 물건들의 사용법을 고민하는 과정을 통해 점차 게임에 빠

져들게 한다. 그에 반해 플롯 주도의 게임에서는 모든 조각이 예상한 결과와 일치하게 될 것이라

는 기대를 품고 플레이어가 게임을 한다. 이 장르에 속한 많은 게임이 기존 작가의 책이나 스토리

를 기반으로 하는 것도 놀라운 일이 아니다.


책이나 영화와 마찬가지로 메인 캐릭터에 대한 감정 이입은 우리가 이처럼 게임에 몰입해 게임

을 즐기는 데 있어 큰 부분을 차지한다. 추가로 1인칭 게임이든 3인칭 게임이든 캐릭터를 제어하

는 방식에 따라 게임에 좀 더 몰입할 수도 있다. 캐릭터와의 상호작용이 거의 없는 게임에서 우리

는 1인칭 형식의 프로타고니스트가 돼서 스토리가 전개됨에 따라 주인공이 한 행동과 결정에 대

해 책임을 진다. 성공적인 어드벤처 게임들은 온갖 종류의 캐릭터 상호작용에 크게 의존하는 한

편 시리즈가 추가될 때마나 단골로 등장하는 이상한 캐릭터들을 포함시키고 개발하는 경향이

있다.

예상할 수 있는 대화 내용 외에 이들 2차 캐릭터에게서 기대하는 재미는 스토리를 훨씬 더 풍

부하게 해준다.

흥미로운 장소와 재미있는 해결책

이제 사람들이 왜 이런 장르의 게임을 즐겨 하는지 더 잘 이해하게 됐으므로 이런 분석 결과가

갖고 있는 의미에 대해 좀 더 생각해 보자. 여러분이 50명으로 구성된 아티스트 팀과 게임을 개

발할 수 있는 시간으로 2년이란 시간을 갖고 있는 게 아니라면 성공을 거두기 위해 현명한 설계

결정을 내려야 한다. 스토리 라인, 콘셉트 아트, 상호작용, 그리고 어느 정도의 기능은 게임 엔진

과 무관하게 진행할 수 있다. 하지만 어느 순간에는 아무리 많은 맨먼스(man/month)를 잡아도

기술이 여러분이 상상하는 모든 것을 구현해주지는 못한다는 것을 깨닫게 될 것이다. 아티스트

에게 있어서 가장 어려운 부분은 어떤 부분을 희생할지 결정하는 것이다. 설계 단계에서는 약간

의 사전 기획만 있다면 흥미로운 장소와 재미있는 해결책을 시각화해 이런 과정을 덜 고통스럽

게 만들 수 있다(그림 1-15 참고).

영화 아바타는 가상 세계에 대한 우리의 기대 수준을 크게 높였다. 엄청나게 많은 수의 기하와

특수 효과를 사용한 아바타는 세계의 1프레임을 렌더링하는 데도 50시간이 걸렸다고 한다. 실시

간에서 우리는 초당 최소 30프레임을 기대한다. 그렇다면 분명 무언가는 희생을 해야 한다.

그림 1-16은 2003년에 프리렌더링을 사용한 세계로 150만 개의 다각형과 특수 효과만을 갖고

있다. 오늘날 이런 장면은 최적화 없이 실시간으로 렌더링하더라도 높은 프레임레이트를 사용할

수 있다.


그림 1-15 ㅣ 우리가 이제 캔사스에 있는 것 같지는 않다(Triberian Oasis, Sue Blackman, 2002).

그림 1-16 ㅣ 과거에는 프리렌더링을 통해서만 가능했던 장면들을 지금은 실시간으로 구현할 수 있다

(Swamp Scene, Sue Blackman, 2003).


실시간의 시각적 품질은 오늘날의 셰이더 및 이들 셰이더와 연동되도록 설계된 그래픽 카드 덕

분에 다양한 은폐 기술을 적용해 좀 더 효율적으로 활용할 수 있다. 아쉽게도 거대하고 아찔하

며, 실사 같은 환경을 빌드하는 데 드는 시간과 자원은 캐주얼 게임이나 막 시작하는 게임 개발자

로서는 감당하기 어려운 게 보통이다. 하지만 좌절할 필요는 없다. 표현하려는 수준에는 못 미치

는 대신 구현하기 쉬운 디자인 결정을 통해 이 문제를 우회할 수 있기 때문이다.

스타일의 정의

환경에 대한 스타일을 명확히 정의하면 사람들이 실제 구현할 수 없는 실사 수준을 기대하지 않

게 할 수 있다. 이 방식은 만화나 애니메이션 또는 잘 정의된 시각 언어를 사용하는 것처럼 겉으

로 드러날 수도 있고 아예 세계 자체를 환상 영역이나 외계 영역으로 설정해 미묘한 암시를 줄 수

도 있다. 비교할 실제 대상이 없을 경우 실사적인 표현에 들어 있는 결점을 찾아내기가 훨씬 더

어려워진다. 스타일을 정할 때는 색상, 모티브, 빛, 그리고 스타일을 시각적으로 정의하는 기타 요

소들에 대해 가장 특징적인 성격들을 목록으로 정리하는 것부터 시작하는 게 좋다. 어떤 스타일

을 택하든 최대한 스타일의 연속성을 유지하도록 주의해야 한다. 재미삼아 클래식 어드벤처 게

임에 단골로 등장하는 랜턴을 여러 가지 다른 스타일로 표현해 보자. 랜턴에 필요한 두 가지 기본

요소는 랜턴이 광원이 돼야 한다는 것과 바로 들고 다닐 수 있어야 한다는 것이다.

그림 1-17 ㅣ 왼쪽: 새 것이지만 고전적인 디자인. 오른쪽: 먼지가 쌓이고 녹이 쓴 디자인.


새 것이지만 고전적인 디자인(그림 1-17 좌측): 이 랜턴은 아무 상점에서나 살 수 있으며 지난

150년간 카탈로그를 통해 아무 때나 구매할 수 있었다. 사용한 흔적과 닳은 부분이 거의 없으므

로 이 랜턴은 메인 캐릭터가 첫 번째 모험에 사용할 랜턴이며 시대는 상당히 현대에 가까움을 알

수 있다. 색상은 시대상을 반영해야 한다.

낡고 녹이 쓴 디자인(그림 1-17 우측): 이 랜턴은 앞의 랜턴을 약 1세기 동안 방치한 후의 랜턴

이다. 이런 랜턴은 플레이어가 장면을 돌아다니다 우연히 찾아내거나 모든 것이 녹이 쓸고 몰락

한 세계 종말 이후의 스토리 구성 요소로 사용할 수 있다. 색상은 밝지 않은 색으로 대부분 회색

과 갈색을 쓰며 부서진 기술 잔해가 장면 이곳 저곳에 흩어져 있을 수 있다.

그림 1-18 ㅣ 왼쪽: 스팀펑크 오른쪽: 환상, 마술, 상상

스팀펑크(그림 1-18 좌측): 기계 시대에는 금속과 조립이 예술 형식 중 하나였으며 사용 빈도가

높았다. 이 스타일의 모티브는 특정 디자인보다는 기능적인 세부사항에 중점을 맞췄다. 이 스타

일은 당시의 최신 스타일로 사용할 수도 있고 재미있는 환경 묘사를 위해 여러 그런지 스타일과

혼용해 사용할 수도 있다. 이때 색상은 동, 구리, 쇠, 광택 금속을 제외하고는 밝지 않은 색상을

사용해야 한다.

환상, 마술, 상상(그림 1-18 우측): 장식과 금을 사용한 마무리, 마젠타, 사이언 등의 색상 사용

은 이런 스타일의 주된 요소다. 이때 모양은 흐르는 듯 하면서 기발해야 한다. 기계적인 세부 표

현은 생략할 수 있다.


그림 1-19 ㅣ 왼쪽: 만화 오른쪽: 외계

만화(그림 1-19 좌측): 주요 색상과 보조 색상 및 단순하거나 이상한 모양의 도형이 이 스타일

을 잘 나타낸다. 오늘날의 셰이더를 사용하면 실사와 만화 스타일을 결합해 이 랜턴 같은 하이브

리드 스타일도 만들 수 있다.

외계(그림 1-19 우측): 세계의 물리적인 영역과 관련한 그럴 듯한 연계성만 갖고 있다면 이 스

타일에서는 모든 것이 허용된다. 실제 외계에 살고 있다고 생각하고 여러분이 찾은 것을 활용해

보자. 이 랜턴에서는 랜턴의 두 가지 필요사항이 모두 반영되게 했다. 이 랜턴은 광원이어야 하며

바로 가지고 이동할 수 있어야 한다. 이 랜턴은 천연 재료를 사용해 빌드했다.

환경 나누기

어떤 게임 엔진이든 실행 중인 기기상에서 한 번에 화면에 그릴 수 있는 객체의 수는 제한돼 있

다. 아울러 기기도 한 번에 메모리에 담을 수 있는 텍스처와 메시의 수가 제한돼 있다. 왜 게임 레

벨이 존재하는지 묻는다면 수많은 게이머들은 다양한 이유를 내놓을 것이다. 그중 가장 주된 이

유는 과제 달성 여부를 확인할 수 있는 수단이 레벨이라는 것이다. 물론 게임 플레이나 스토리와

관련해서는 이런 이유도 타당하지만 실제 이유는 기술 제약 때문이다.

미래에는 스트리밍 데이터가 더 폭넓게 사용되겠지만 아직까지는 많은 기하와 텍스처를 메모

리에 로드할 경우 금세 한계에 부딪힌다. 물론 이런 제약은 플랫폼과 그래픽 카드에 따라 다르다

(그림 1-20 참고). 따라서 첫 번째로 결정할 사항은 게임을 실행할 수 있는 최소 플랫폼이다. 이

기준은 각 레벨을 얼마나 크게 정할지 결정하는 기초가 된다.


그림 1-20 ㅣ 각기 다른 플랫폼과 기술

하드웨어가 전체 레벨에 대한 제약 요소이기는 하지만 한 번에 화면에 그릴 객체의 수를 정할

때는 디자인이 가장 주된 요소가 된다. 이때 다각형과 아트 에셋의 주요 부분을 특정 시점에만

보이도록 하는 트릭을 사용해 환경을 디자인한다. 플레이어가 상호작용할 수 있는 도시 또는 영

역을 만들 때를 생각해 보자(그림 1-21 참고). 이때 벽을 가파르고 높게 만들면 옆에 있는 영역이

나 아트 에셋을 볼 수 없게 된다. 또 이 영역으로 들어가는 휘어진 입구는 많은 다각형을 사용한

다른 영역에 대한 시야를 방해한다.

그림 1-21 ㅣ 환경 디자인


건물 디자인도 거의 같은 방식으로 진행된다. 모든 내용을 렌더링해야 하는 길고 곧은 장면은

인접한 영역을 제외하고 사방이 막혀 있는 복도나 통로보다 훨씬 비경제적이다(그림 1-22 참고).

볼 수 있는 영역을 작은 공간으로 제한할 수 있다면 이 영역에 더 많은 객체를 채워 시각적인 정

교함을 더 높일 수 있다.

그림 1-22 ㅣ 건물 디자인

시차 효과

간단하지만 효과적으로 실시간 환경에서 시각적인 효과를 높일 수 있는 방법으로 시차 효과를

활용하는 법이 있다. 시차 효과는 카메라나 사람의 관찰 위치에서 멀리 떨어진 물체가 가까이 있

는 물체보다 더 느리게 움직이는 것처럼 보이는 효과다. 실시간 장면 이동에 지면이나 건물과 관

련해 각기 다른 품질을 사용하고 여러 개의 독립적인 거대 객체를 사용하면 3D 공간에 있다는

인식이 더 커지고 환경에 대한 사용자의 시각적인 경험을 점증적으로 개선하는 효과가 있다. 간

단히 말해 시차는 3D 안경의 도움 없이도 우리가 실제 3D 환경에 있는 것처럼 뇌를 속이는 데 도

움을 준다. 연속 스틸샷으로는 이 효과를 제대로 확인하기는 어렵지만 그림 1-23에 나와 있는 전

방 지면과 중간 지면, 배경 요소의 위치를 잘 살펴보자.


그림 1-23 ㅣ 시차: 뷰가 오른쪽 또는 왼쪽으로 패닝되므로

전방에 있는 물체는 뒤에 있는 물체보다 더 빠르게 움직이는 것처럼 보인다.

애니메이션

많은 경우 애니메이션은 사실감을 높여준다. 프리렌더링한 결과와 비교해 정교함이 떨어지는 재

료를 사용하고 다각형 개수가 적은 객체이더라도 효과적인 애니메이션을 사용하면 더 실제 같은

느낌을 준다. 인간의 뇌는 유기적인 애니메이션이나 캐릭터 타입의 애니메이션과 마찬가지로 기

계적인 애니메이션 시퀀스에서도 잘못된 점을 쉽게 집어낸다는 점을 기억하자. 실제 같은 느낌을


주고 사용자가 몰입하게 하려면 애니메이션의 품질이 매우 높아야 한다. 다행히 최고 수준의 애

니메이션도 보통 형편 없이 실행되는 애니메이션과 비교해 거의 같은 양의 리소스를 차지한다.

도전 과제, 임무, 퍼즐

앞에서 언급한 사항들이 여러 다른 장르에서 게임을 설계할 때 일반적인 기초가 되는 반면, 이

주제는 상호작용과 문제 해결이 핵심 기능인 어드벤처 장르에 좀 더 특화돼 있다.

과제를 설계할 때는 과제를 해결해 사용자가 만족하는 정도로는 부족하다. 한 사용자가 느끼

기에는 어렵고 버거운 과제도 다른 사용자에게는 지나치게 쉬울 수 있기 때문이다. 과제 해결 후

나오는 시퀀스는 항상 사용자를 압도할 만하고 재미있어야 하며 가능한 한 게임에 흥미를 더해

줘야 한다. 여기서 우리는 피터 셀러스의 코메디나 알프레드 히치콕의 서스펜스에서 한 가지 교

훈을 배울 수 있다. 즉, 해결책이 지나치게 쉬워 보인다면 뭔가 다른 일을 추가로 하고 사용자의

기대 심리를 유리하게 활용하라는 점이다. 이런 해결 과정에 예상치 못한 내용을 추가해 보자.

TellTale Games에서 배포하는 원숭이 섬 시리즈는 이런 부분에 특히 정통했다. 이 게임에서 대

다수 물체는 찾는 즉시 용도를 알 수 있는 것들이지만 실제로 사용할 때는 원래 생각한 용도와

더불어 예상치 못한 재미를 준다.

이런 과제의 목적은 플레이어가 올바른 행동이나 동작을 할 때 플레이어에게 상을 주기 위한

것이므로 플레이어가 게임 도중 화를 내지 않도록 하는 게 좋다. 플레이어가 올바른 해결책을 찾

았다고 생각하게 한 후 과제를 해결하려면 또 다른 추가 작업을 하게 만들어 플레이어를 실망시

킨다면 게임이 재미있을 리 만무하다. TellTale Games에서 내놓은 최근작 월래스와 그로밋 시리

즈는 이를 잘 보여준다. 이 게임의 스타일과 음악은 원작인 영화에 충실하고, 게임에 사용된 애니

메이션과 모델링, 아트 에셋의 텍스처 또한 최고 수준이다. 하지만 이 시리즈의 초기작에서 잘못

된 점은 플레이어가 영화의 월래스 캐릭터와 마찬가지로 계속해서 실패하도록 설정한 점이다. 사

용자가 보기에는 올바른 동작과 해결책이 계속해서 실패함에 따라 이 게임의 플레이어들은 다

음 번 문제를 해결하려는 흥미를 점차 잃어버렸다. 물론 월래스 캐릭터가 이리저리 좌충우돌하

는 것을 기대하기는 하지만 그건 어디까지나 영화를 통해서 볼 때 재미있는 것이고, 실제 우리가

월래스의 페르소나 속으로 들어와 원작 캐릭터의 한계 속에서 어려운 문제들을 해결하는 것과

는 별개의 문제다. 다행히 이 시리즈의 중간작 쯤에서 TellTale Games는 월래스 캐릭터에 충실

하면서 동시에 플레이어에게 보상을 할 수 있는 게임 플레이 방식을 고안해냈다. 이와 같은 연구

조사와 분석은 TellTale Games가 왜 캐주얼 어드벤처 게임 시장을 석권하는지 잘 보여준다.


좀 더 재미있는 게임이 되려면 캐릭터가 어려운 난관에 봉착해야 하지만, 게임의 캐릭터는 영리

한 판단과 기지, 그리고 약간의 운을 통해 이런 상황을 빠져나올 수 있어야 한다. 간단히 말해 플

레이어가 실패하게끔 설정하는 것은 피해야 한다. 만일 명확한 동작이 꼭 실패로 이어지도록 할

계획이라면 최소한 그 전에 플레이어에게 힌트를 줘야 한다.

어드벤처 장르에 무슨 일이 일어난 걸까?

지금까지 어드벤처 게임과 관련해 해야 할 일과 하지 말아야 할 일을 살펴봤다. 이쯤에서 문뜩

1990년대 초반 어드벤처 게임의 전성기 시대에서 인기가 떨어진 원인이 무엇일지 궁금할 것이다.

이 주제는 독자들이 자신만의 어드벤처 게임을 만들기에 앞서 꼭 살펴볼 만한 가치가 있다.

1990년대 초반 텍스트 기반의 어드벤처 게임은 인터랙티브 픽션으로 분류되며 역사상 그 위치

가 격하됐다. Myst와 Riven을 선두로 하는 최신 그래픽 어드벤처 게임들은 시각적인 즐거움을

느끼게 해줬다. 당연히 이런 그래픽을 만드는 데는 많은 비용이 들었다. 한번 성공이 있고 나면

값싼 실패작들이 나오기 마련이다. 일부 스튜디오는 이 장르에서 얻을 수 있는 수익을 보고 주류

에 편승해 어드벤처 게임 개발에 뛰어들었지만 아이디어를 구현할 예산이나 전문성이 없어서 결

국 실패했다.

아쉽게도 약한 스토리라인과 3류 그래픽이 시장에 넘쳐나면서 조잡한 게임들이 늘어나게 됐

다. 이에 소비자들은 ‘멋진 그래픽’ 또는 ‘흥미로운 세계’라는 선전 문구를 경계하기 시작했다. 사

용자들은 아웃소싱에 의해 정형화된 싸구려 어드벤처 게임들을 찍어내는 게임 배포 회사들에게

는 돈을 낭비하지 말아야 한다는 사실을 이내 깨달았다.

그렇다고 Riven 이후에 고품질의 게임이 나오지 않았다는 얘기는 아니다. 이후 등장한 게임 중

특히 ‘�e Longest Journey’와 ‘Syberia’는 주목할 만한 품질을 갖추고 있었다. 두 게임 모두 튼

튼한 스토리와 재미있는 위치 묘사, 멋진 아트 에셋, 상호작용을 통한 과제와 퍼즐 해결 과정이

모두 들어 있었다. ‘Syberia’ 게임에서는 작은 프랑스 마을의 제빵사가 브롱크스 억양을 갖고 있

는 점과 ‘�e Longest Journey’에서 필요한 대화가 조금 많다는 점을 제외하면 플레이어는 이들

게임을 진행하면서 충분히 불신의 유예를 유지할 수 있었다.

객관적으로 분석해 보면 어드벤처 장르가 텍스트 기반에서 그래픽 기반으로 바뀌면서 사용자

가 마음대로 입력하던 대화가 정해진 대화 선택 틀로 갇히게 됐고 이로 인해 상호작용이 줄어들

었으며, 플레이어들은 거의 선형적인 스토리라인에서 플레이한다는 느낌을 받게 됐다. 기존 텍스


트 게임에서 가장 좋은 부분은 객체에 아무 내용이나 입력해볼 수 있다는 점이었다. 하지만 그래

픽 어드벤처 게임에서는 모든 가능한 상호작용마다 애니메이션을 만드는 게 쉽지 않으므로 응답

결과 애니메이션의 개수를 줄이는 대신 그래픽 어드벤처 개발자들은 플레이어 상호작용의 시각

적인 결과를 매우 창의적으로 표현해야 한다. 텍스트 기반의 게임에서는 바위와의 상호작용(말

하기, 굴리기, 발로 치기, 던지기, 부수기 등)이 다양하고 재미있는 응답을 낳는 반면, 그래픽 게임

에서는 상호작용할 수 있는 동사가 ‘집기’와 ‘사용하기’로 크게 제약된다.

또 다른 단점은 실시간 어드벤처로 전환되면서 나타났다. 스틸샷으로 렌더링한 전통적인 포

인트 클릭 어드벤처 게임이 이번에는 장면 이동이라는 조금 더 적극적인 플레이어의 참여로 인

해 더 복잡해졌다. 한편으로 플레이어는 마침내 세계를 탐험하면서 자신의 방향을 유지할 수

있게 됐지만, 장면 이동 자체가 오히려 단점으로 부각됐다. 전통적인 슈팅 게임의 이동방식인

WASD(앞으로 가기, 왼쪽 회전, 뒤로 가기, 오른쪽 회전)와 마우스를 통한 보기와 방향 회전은

많은 기술과 연습이 필요할 뿐 아니라 장면 이동이 빠르게 이뤄지는 게임을 대상으로 개발돼 있

었다. 루카스아츠의 Grim Fandango(그림 1-24 참고) 같은 하이브리드 게임에서는 제한된 공간

내에서 캐릭터를 움직이게 했지만 각 방마다 일관성이 없는 카메라 변화를 계속해서 사용했다.

그림 1-24 ㅣ 루카스아츠의 Grim Fandango(LUCASARTS, A DIVISION OF LUCASFILM

ENTERTAINMENT COMPANY LTD의 사전 승인을 받고 사용).

논리적으로 어드벤처 장르가 나아가야 할 단계는 프리렌더링한 그래픽 형식을 실시간으로 전

환하는 것이었으므로, 어드벤처 게임의 인기를 떨어뜨린 또 다른 주요 요소는 바로 그래픽 품질


이었다. 실시간 게임의 초창기 시절 동안 아트 에셋의 품질은 기술적인 제약으로 인해 심각하게

떨어졌다. 하지만 스튜디오들은 앞으로 이 분야가 대세라고 판단해 어쩔 수 없이 신기술을 받아

들였고, 프리렌더링 스틸샷은 공룡처럼 멸망의 길을 걷게 됐다. 하지만 어드벤처 게임광들은 이

런 신기술로의 이전을 달가워하지 않았다. 아무리 멋진 이야기와 재미있는 게임 플레이 방식을

집어넣더라도 이 당시에는 기술적으로 떨어지는 그래픽 품질의 약점을 극복할 수 없었다. 하지만

기술은 이런 제약을 극복하며 발전했고 시각적인 그래픽 품질 또한 점차 나아졌다. 그럼에도 최

근까지만 하더라도 고급 그래픽을 보여줄 수 있는 장비는 하드코어 게이머들의 전유물이었다. 오

늘날 우리는 드디어 1인칭이 됐든 다른 장르가 됐든 풍부한 그래픽 환경을 보여주고 실행할 수

있는 그래픽 카드가 보급형 컴퓨터에 장착돼 있는 시대에 살고 있다.

최근 어드벤처 게임의 성공

당연히 요즘 부활한 전통 어드벤처 게임들은 실사 스타일보다는 다른 스타일을 택해 스튜디오에

서 스토리와 게임 플레이, 콘텐츠에만 집중함으로써 많은 제작비를 들이지 않아도 되는 전략을

따르고 있다. 이들 어드벤처 게임들은 인디 스튜디오와 더불어 큰 인기를 얻고 있다. 이런 인디 스

튜디오들은 거대 게임회사처럼 많은 비용이 들지도 않을뿐더러 백만 카피 이상을 팔지 않더라도

개발 비용을 충분히 회수할 수 있다.

또 캐주얼 게임 시작이 막 성장함에 따라 어드벤처 게임에 대한 관심이 지속적으로 늘어나는

것도 한몫하고 있다. 최근 트렌드에 맞춰 전체 길이의 게임을 내놓는 대신 장(chapter) 단위로 게

임을 배포함에 따라 제작 시간과 비용을 이전보다 더 잘 관리할 수 있게 됐고, 이로 인해 개발자

들은 충동 구매가 가능할 정도로 게임의 판매 비용을 낮출 수 있었다. 전통적인 4세계 형식도 이

런 장 또는 설치 형식에 잘 부합된다. TellTales Games의 원숭이 섬의 비밀이 2010년 가장 성공

적인 캐주얼 게임이었다는 사실은 이 장르의 계속되는 인기를 잘 보여준다.

게임의 재미와 사람 성격의 본질

무엇보다도 우리는 재미 때문에 게임을 한다. 수동적으로 텔레비전을 통해 영화를 보는 것과 달

리 인터랙티브 게임은 플레이어의 노력이 필요하다. 게임이 재미 없거나 뻔하다면 우리는 게임을

그만하고 다른 것을 한다. 재미보다는 좀 더 심각한 주제를 다루는 게임에서도 사람의 기본적인

성격은 정해진 패턴을 따른다.


페렝기의 법칙: 스타 트렉의 페렝기처럼 우리도 우리 것이 아니더라도 물건을 모으는 것을 좋

아한다. 이는 아주 오래전 옛날부터 내려온 우리의 생존 특징이라고 볼 수 있다. 아예 모을 수 없

는 아이템이 아니라면 우리는 이를 모아 훗날 필요할 날을 대비해 챙겨둔다. ‘가장 많은 장난감을

가지고 죽는 사람이 승자다’라는 범퍼 스티커의 문구는 오늘날의 맥락에서 이와 같은 감정을 전

달하고 있다(그림 1-25 참고).

그림 1-25 ㅣ 범퍼 스티커

일탈: 우리는 무례하거나 사회적으로 용납되지 않는 행동을 하는 환상을 꿈꾸는 것을 좋아한

다. 게임에서 우리는 친구들의 시선을 아랑곳하지 않고 기본적인 본능에 따라 행동할 수 있다. 또

때로는 게임을 전개하는 데 이런 행동이 필요하기도 하다(그림 1-26 참고).

그림 1-26 ㅣ 경비를 통과하려면 이 길뿐이다.

초능력: 우리는 체력적으로 강해져 위험을 무릎쓰거나 다년간의 훈련을 통해 쌓을 수 있는 기

술에 대해 환상을 갖고 있지만 1인칭 슈팅 게임을 하는 게이머들은 싫어한다. 우리는 복잡하고

현란한 키보드와 마우스 동작을 통해 멋진 게임 기록을 내는 것을 무의미하다고 생각한다(그림

1-27 참고).


그림 1-27 ㅣ 초능력: 이 게임에서 작은 스파키를 구출해내기 위해 현란한 플랫폼 점프 기술은 필요 없다.

예상치 못한 결과: 우리는 폭탄이나 그리네이드를 오랫동안 갖고 있을 때 어떤 일이 일어나는

지 궁금하다. 이 장르의 게임에서 사람들은 예상치 못한 일이나 재미있는 일들이 일어나기를 기

대한다(그림 1-28 참고).

그림 1-28 ㅣ 예상치 못한 결과: 우리는 예상하지 못한 일들이 일어나는 것을 즐긴다.


왜 나만의 게임을 만들어야 하나?

누구나 자신만의 게임 스토리와 아이디어를 갖고 있다. 여러분이 같이 일할 사람을 찾게 되더라

도, 그 사람은 분명 여러분과 다른 생각을 갖고 있을 것이다. 여러분이 개발 리더가 되더라도 팀

원 사이의 갈등과 팀이 해체될 위기는 끊임없이 나온다. 물론 여러분이 충분한 급여를 지불한다

면 얘기가 다를 수 있다. 하지만 보통 처음으로 게임을 개발하는 사람들은 직원들에게 급여를 지

불할 여력이 되지 못하는 게 대부분이다. 이렇게 자금 없이 공동으로 개발하는 팀에서는 팀이 해

체될 경우 게임이 끝내 나오지 못할 가능성이 있다. 하지만 여러분이 혼자 모든 책임을 지기로 하

면 여러분이 직접 게임을 만들고 개발할 수 있다. 여러분이 현재 갖고 있는 기술이 POC를 만들

정도의 수준밖에 되지 않더라도 이 버전을 완성하고 나면 여러분에 대한 신뢰는 그만큼 쌓이게

된다. 제대로 동작하는 프로토타입이 하나라도 있다는 말은 프로젝트에 대한 의지가 있음은 물

론 프로젝트 전체를 꿰뚫어 볼 수 있는 시야가 있음을 증명하기 때문이다.

과거에는 게임 저작 엔진들이 게임 단위로 라이선스 계약이 되는 언리얼 엔진처럼 고급 기능을

갖춘 상업 제품이거나 게임에서 필요로 하는 내용만 구현한 인하우스 엔진이었다. 하지만 캐주

얼 게임이 등장하면서 이제 수많은 게임 엔진을 사용해 자신만의 게임을 만들 수 있게 됐다. 하지

만 저사양의 게임 엔진들은 매우 특화된 경향이 있어서, 이런 엔진을 가지고 게임을 개발할 경우

대부분의 의사결정을 여러분이 주도할 수 없고, 결국 포함된 아트 에셋을 통해 만든 게임도 만족

스러운 결과와는 거리가 멀다.

다행히 지금은 고급 엔진에서 표준으로 사용되는 많은 기능을 제공하는 다양한 엔진이 나와

있다. 이들 엔진은 게임을 제작하려는 사람이라면 거의 누구나 구매 또는 라이선스 계약을 맺어

사용할 수 있다. 유니티 엔진은 다양한 고급 기능을 제공한다는 점과 무료 및 비용이 싼 프로 버

전을 제공한다는 점, 맥과 PC에서 실행된다는 점, 또 다양한 플랫폼으로 이전할 수 있다는 점에

서 게임 개발을 시작하기에 적합한 엔진이다.

다양한 역할

게임을 혼자 개발할 때 가장 큰 단점은 개발 과정에서 세 가지 옷을 모두 입어야 한다는 점이다.

우선 게임 플레이 방식, 스토리, 스타일을 설계하는 일은 물론 디자이너에게 좀 더 적합하긴 하지

만 대부분의 사람들이 할 수 있다. 두 번째로 게임에 사용할 아트 에셋에 대한 디자인은 당연히

아티스트가 담당할 부분이지만, 웹상에는 이런 디자인에 취약한 사람들을 위해 다양한 무료 에

셋이 나와 있다. 하지만 아티스트가 아닌 사람들의 경우 이런 아트 에셋을 통해 룩앤필의 일관성


을 유지하는 데 어려움을 겪는다. 세 번째로 스크립트 능력이 필요하다. 고급 상업 엔진에서는 이

부분이 주로 하드코어 프로그래머들의 영역이었지만 오늘날의 저작 엔진은 스크립트 작성 과정

을 재설계해 디자이너라도 미리 작성된 스크립트 애니메이션과 컴포넌트 스크립트를 사용해 원

하는 목적을 이룰 수 있게 했다.

이 책은 아티스트나 디자이너가 스크립트 작성 과정과 친해지게 도와줌으로써 비교적 복잡한

게임 또는 POC 수준의 게임을 만들 수 있게 하는 것을 염두에 두고 썼다. 이 책에서 살펴볼 예제

와 개념을 통해 독자 여러분이 여러분의 꿈을 실현하기를 바라고, 최소한 꿈을 향해 한 발자국

나아갈 수 있기를 희망한다.

사실 많은 사람들이 게임을 만들겠다는 얘기를 한다. 하지만 실제로 게임을 만드는 사람은 극

소수다. 이 책은 여러분이 게임을 만들고자 하는 꿈을 실현할 수 있도록 게임을 만드는 데 방해

가 되는 장애물을 제거하고 게임을 제작하는 과정을 쉽게 알려주기 위한 책이다.

인디 개발자에게 적합한 두 가지 게임 형식

이제 어드벤처 장르를 게임의 기본 장르로 선택했으니 본격적으로 게임 개발을 시작하기 전에

이 장르에 속한 게임의 두 가지 형식을 살펴보고 각자의 장단점을 비교해 보자.

1인칭 게임

이 게임 형식에서 플레이어는 게임 내내 1인칭 역할을 맡는다.

자유로운 플레이: 3D 세계에서 1인칭 형식의 가장 큰 장점은 아티스트 또는 프로그래머가 많

은 에셋을 만들지 않고도 지형과 환경을 만드는 데 들어간 시간을 충분히 보상받을 수 있다는 점

이다. 여러분이 직접 만든 세계를 마음대로 돌아다니다 보면 게임을 만들 때 들인 수고는 충분히

보상받고도 남는다. 이런 이동 방식의 단점은 플레이어가 장면에서 핵심이 되는 장소로 항상 이

동해야 함에도, 전통적인 1인칭 내비게이션 방식이 정교한 제어를 고려해 설계되지 않았고, 어드

벤처 게임 장르에 익숙한 사람들로서는 조작 기술이 부족할 수 있다는 점이다.

캐릭터 애니메이션: 이런 게임에서는 1인칭을 직접 보는 일이 없으므로 3인칭 형식처럼 방대한

캐릭터 애니메이션은 필요 없다. 또 플레이어가 있는 세계가 버려진 세계라는 기본 전제가 있는 1

인칭 형식의 게임에서는 캐릭터 상호작용조차도 필요 없다. 캐릭터 애니메이션을 배제할 수 있을

뿐 아니라 장면에 다른 캐릭터를 추가할 때 자주 등장하는 복잡한 대화 트리도 1인칭 게임에서


는 불필요하다. 상호작용이 불가능한 다른 캐릭터를 더 추가할 때는 플레이어가 다른 캐릭터와

마주치지 않도록 기본 AI를 제공해 플레이어의 움직임을 제한해야 한다.

기계 동작: 1인칭 형식의 게임에 자주 등장하는 또 다른 요소로는 기계 성격이 강한 과제 또는

퍼즐이 있다. 이런 기계적인 애니메이션은 아티스트나 프로그래머 모두 제대로 표현하기가 한결

수월하다.

캐릭터

여러분이 만들기에 적합한 또 다른 게임 종류로는 3인칭 형식의 게임이 있다. 이런 게임에서는

플레이어가 캐릭터의 이동과 행동을 제어할 때 장면 주위에서 캐릭터를 따라다닌다. 이 책의 메

인 프로젝트는 1인칭 형식을 기반으로 하지만 두 형식 사이의 차이를 비교해보는 것은 충분히

의의가 있다. 이 책의 마지막 장에서는 3인칭 게임으로 바꾸는 데 필요한 변경사항을 간략히 살

펴본다.

역할 플레이와 캐릭터 개발: 이 형식의 게임은 캐릭터의 역할을 플레이하고 캐릭터에 감정을

이입하게 해주는데, 이는 계속해서 인기를 얻고 있는 많은 어드벤처 게임 시리즈의 매력 요소 중

하나다. 또 이런 형식의 게임에서는 개발자가 향후 에피소드에 등장할 수 있는 보조 캐릭터들을

만들고 이들 캐릭터에 살을 붙여 이어지는 에피소드에 대한 기대를 높일 수 있다.

기술적인 요구사항: 캐릭터가 정해진 비헤이비어(휴식, 걷기, 뛰기, 총쏘기, 점프, 죽기)만 할 수

있는 1인칭 슈팅 게임과 달리 3인칭 형식에서는 필요한 객체 상호작용과 대화 시나리오를 모두

처리하기 위해 방대한 캐릭터 애니메이션이 필요하다. 또 대화 트리를 작성하는 것 외에 모든 대

화를 녹음할 성우들도 섭외해야 한다. 이런 방식을 우회하려면 인기있는 일본 인터랙티브 소설처

럼 캐릭터가 말하는 게 아니라 중립 상태에 있고 대화 풍선을 통해 대화가 이뤄지게 할 수 있다.

하지만 이런 방식은 전통 어드벤처 게임의 과제 중심의 성격에서 조금 벗어나 있는 만큼 이런 옵

션은 사용하지 않는 게 좋다.

카메라 고려사항: 3인칭 형식을 택할 때 또 다른 단점은 카메라 처리가 복잡해진다는 점이다.

경계가 정해진 공간 내에서 카메라와 벽과의 충돌은 문제를 일으키기 쉽다. 또 캐릭터가 건물이

나 다른 영역으로 들어가고 나갈 때마다 여러분은 건물을 열지 또는 캐릭터에 가깝게 카메라를

이동해야 할지 결정해야 한다. 이런 3인칭 형식의 변종 게임에서는 카메라가 캐릭터의 이동 영역

을 조심스럽게 제한하는 동시에 특정 범위 내에서 캐릭터를 따라다니는 방식을 사용한다. 이 경

우 캐릭터가 경계 영역과 충돌하면 다음 위치에서 새 카메라가 활성화된다. 이 방식의 단점은 과


거 프리렌더링 스틸샷 형식처럼 위치사이의 연계성이 가끔씩 부족하게 보인다는 점이다. 하지만

이 방식은 각 카메라 영역에 대한 어클루전 컬링(occlusion culling)을 매우 쉽게 할 수 있어, 게

임이 오래된 장비나 모바일 플랫폼에서도 빠르게 실행된다는 장점이 있다.

두 게임 형식의 공통 요소

다음은 이 장르를 정의하는 데 도움되는 몇 가지 특징이면서 두 형식에 공통으로 들어 있는 요소

들이다. 어드벤처 게임을 만들 때는 아래 요소들을 염두에 두면 도움이 될 것이다.

재미: 무엇보다도 어드벤처 게임은 재미가 우선이다. 이런 재미 요소가 유머러스한 인터랙션에

서 오든 재미있는 애니메이션 시퀀스에서 오든, 지적인 수수께끼에서 오든 게임 플레이와 환경은

플레이어가 게임을 계속하고 싶게끔 플레이어를 끌어들여야 한다.

스토리/목적: 게임은 거대한 퍼즐책이 아니다. 게임에 사용된 과제와 퍼즐은 게임 세계에 정해

진 특성과 관련해 최소한 논리적, 기계적, 또는 물리적인 연결 고리를 갖고 있어야 하며 게임의 전

제 조건에 부합되면 더욱 좋다.

객체 상호작용: 객체와의 상호작용은 이 장르의 특징에서 가장 두드러지는 것 중 하나다. 플레

이어가 객체를 모으든 손에 들고 있는 것을 바로 사용하든 전통적인 포인트 클릭 기능은 이런 어

드벤처 게임의 중심에 있다.

객체 간 상호작용: 어드벤처 게임에서 문제를 해결하는 부분 중 상당 부분은 플레이어가 여러

객체를 조합해 문제를 해결하거나 게임을 계속해서 진행시키는 데 필요한 메커니즘을 고칠 수 있

는 열쇠를 찾아내는 능력에 있다. 물론 모든 어드벤처 게임에서 이런 상호작용이 사용되는 것은

아니지만 이런 상호작용은 흔히 볼 수 있다.

아이템 저장소: 필수 항목은 아니지만 어드벤처 게임에서 많은 사랑을 받는 또 다른 요소로 아

이템 저장소 시스템이 있다. 플레이어가 무엇이든지 모을 수 있게 하려면 게임에서는 플레이어가

모은 아이템을 바로 사용할 수 있게 해줘야 한다. 복잡하고 규모가 큰 게임에서는 화면에서 아이

템 저장소의 내용을 모두 보여줄 수 없는 경우를 대비해 스크롤 기능도 제공해야 한다.

저장/불러오기: 오늘날의 많은 캐주얼 게임과 달리 간단한 어드벤처 게임조차 처음부터 가만

히 앉아서 플레이를 하는 경우는 거의 없다. 플레이어들은 저녁에 한 시간 정도 게임을 한 후, 게

임 진행이 막히면 게임을 그만두고, 머리가 좀 맑아지면 게임을 다시 시작한다. 게임 저장 기능은

플레이어들이 게임을 며칠 또는 몇 주 동안 즐길 수 있게 하는 데 꼭 필요한 기능이다.


음악과 효과음: 초기 그래픽 게임에서부터 사용한 효과음은 객체 상호작용을 더 강하게 하고

개선하는 데 도움을 준다. 음악은 개별 세계나 환경에 대한 분위기를 설정해주는 역할 뿐 아니라

게임에서 퍼즐이나 과제를 해결하는 데 도움을 주는 용도로도 자주 활용된다.

액션 객체: 다양한 어드벤처 게임에서 흔히 볼 수 있는 또 다른 요소로 인터랙티브 객체를 식별

하는 방식이 있다. 과거 텍스트 어드벤처 게임에서는 일반적인 방 설명 다음에 인터랙티브 객체

가 항상 나열돼 있었다. 하지만 그래픽 어드벤처 게임으로 넘어오면서 플레이어는 사용 가능한

인터랙티브 객체를 찾느라 화면을 1픽셀씩 살펴봐야 하는 경우도 생겼다. 한때는 앤티 앨리어싱

이 부족한 객체를 인터랙티브 객체로 사용하기도 하지만 기술이 발전하고 해상도가 높아짐에 따

라 마우스가 액션 객체 위에 올라올 때 커서를 바꾸거나 커서/액션 객체에 하이라이트를 주는 방

식이 보편화됐다.

1인칭 게임의 디자인 고려 사항

정리할겸 이 책에서 게임을 개발할 때 주의할 점을 최종적으로 정리해봤다.

열린 세계에서의 게임 플레이 힌트: 1인칭 형식의 게임처럼 게임의 세계가 열려 있고 그 규모가

크다면 어디가 중요한 위치인지 플레이어에게 힌트를 제공해야 한다. 플레이어가 자유롭게 이동

할 수 있는 세계 안에서 중요한 요소들을 찾도록 도와줄 때는 텍스처, 기하, 빛, 애니메이션, 텍스

트 힌트 등을 모두 활용할 수 있다. 핵심이 되는 객체들은 힌트를 주지 않은 채 숨기지 말아야 한

다. 이렇게 하지 않으면 과거 어드벤처 게임처럼 픽셀을 하나씩 찾는 수고를 실시간 게임에서 해

야 하므로 문제가 많다. 거듭 말하지만 게임은 지루하기보다는 재미가 있어야 한다.

텍스처로 만든 길이나 기하를 통해 표시한 길은 플레이어가 올바른 위치를 찾도록 도와주는

데 가장 많이 사용하는 방식이다. 멀리 떨어진 곳에서도 볼 수 있는 기하 표시는 또한 게임에서

재미있는 사건이 일어나는 위치를 암시하기도 한다. 이때 플레이어를 속이지 않도록 주의하자. 플

레이어의 관심을 끄는 물건을 플레이어가 실제로 살펴본 후에는 플레이어에게 보상으로 줄 뭔가

를 항상 포함시켜야 한다. 이런 물체가 퍼즐이나 임무와 관련이 없더라도 게임에서 다른 일을 하

는 데 단서로 활용될 수 있다.

빛과 색상도 플레이어의 시선을 사로잡아 플레이어가 특정 영역을 살펴보게 할 수 있다. 이때

는 색상 스키마를 미리 계획해서 사용함으로써 다른 색상을 통해 플레이어의 시선을 끌어야 한


다. 빛에 큰 변화를 주더라도 플레이어의 눈에 쉽게 띄며 플레이어가 살펴봐야 할 중요한 내용이

있다는 시각적인 힌트를 줄 수 있다. 이런 시각적인 힌트는 미묘한 것부터 재미있는 것까지 다양

할 수 있다.

플레이어를 특정 위치로 이끄는 데 오디오 효과를 사용할 수도 있다. 3D 사운드는 플레이어에

게 내용을 자세히 살펴볼 동기를 부여할 뿐 아니라 스테레오 스피커 사운드 시스템을 통해 플레

이어에게 방향을 알려주는 데도 도움을 준다.

내비게이션 고려 사항: 3D 세계에서의 내비게이션은 가장 어려운 부분 중 하나다. 플레이어의

기술 수준이나 게임 플레이 경험을 알 수 없는 상황에서 가장 효과적인 내비게이션을 적용하려

면 가능한 한 내비게이션을 투명하게 만드는 게 좋다. 이 게임에서는 게임 경험이 많은 사용자를

위해 WASD를 통한 장면 이동 기능을 제공할 뿐 아니라 나머지 플레이어들이 편하도록 화살키

를 통한 이동 방식도 제공한다. 이때 한 가지 절충해야 할 사항은 장면을 둘러보는 방식이다.

객체에 대한 마우스 클릭은 게임의 주요 상호작용 수단으로 꼭 필요하므로 전통적인 마우스

보기 기능은 게임에 방해 요소가 될 수 있다. 올바른 객체 위에 커서를 올려놓으려고 할 때 화면

이 정신 없이 돈다면 게임을 제대로 하기가 어렵기 때문이다. 따라서 이 게임에서는 사용자가 추

가 키를 사용하거나 마우스 버튼을 누른 경우에만 마우스 보기를 허용해야 한다.

또 특정 객체로 이동해 객체와의 상호작용 결과를 편하게 관찰할 수 있는 기능도 필요하다. 화

살키와 WASD를 통한 이동으로는 아날로그적으로 속도 변화를 줄 수 없으므로 때로는 게임에

서 이동 제어권을 가지고 플레이어를 최적의 위치로 움직여야 한다. 이 방식은 사람들이 근거리

에서 사물을 관찰하게 할 때도 사용할 수 있다. 플레이어의 현란한 기술을 요하지 않고 게임 캐

릭터의 신체적인 우수함을 표현하는 게임이나 슈팅 게임에서도 마찬가지 방식으로 게임을 진행

할 수 있다.

객체 상호작용: 또 한 객체가 다른 객체와 게임 내에서 또는 아이템 저장소 모드에서 어떻게 상

호작용하는지도 결정해야 한다. 추가로 사용자가 아이템 저장소로 어떻게 들어가고 나가는지,

아이템 저장소가 어떻게 확장되는지 등 아이템 저장소를 제어하는 방식도 결정해야 한다.

이처럼 어드벤처 게임을 개발하다 보면 흥미로운 사실들과 예상치 못한 결정을 수없이 만나게

된다.


이야기와 과제의 개발

아무리 간단한 게임이라도 게임 개발 과정은 간단하지 않다. 이 책을 통해 첫 번째 게임을 만들

때는 여기 적어놓은 팁과 트릭을 염두에 두면 도움될 것이다.

■ 규칙 #1. 여러분의 가장 좋은 아이디어를 첫 번째 게임에 모두 쏟아붓지 않는다. 기술은

열심히 익히되, 첫 번째 프로젝트는 배우는 과정이라고 생각한다.

■ 작업한 모든 내용에 대해 작업 시간을 기록한다. 작업 시간을 조사, 문서 작성, 스크립트

작성, 모델링, 매핑, 애니메이션 적용, 테스트 단계로 나눈다. 이렇게 하면 작업하는 데 실

제로 시간이 얼마나 걸리는지 알 수 있고 나중에 현실적인 개발 일정을 만드는 데도 도움

된다. 또 동료나 직원과 함께 작업해 궁극적으로 마일스톤을 세우는 데도 도움을 준다.

■ 소화할 수 있는 내용만 소화한다. 대부분의 크리에이티브 디자이너들은 디자인을 할 때

지나치게 세부 묘사에 치중하는 경향이 있다. 하지만 프로젝트 규모가 커지고 복잡해질

경우 이런 프로젝트는 완성될 확률이 크게 낮아진다. 성취 가능한 목표에 도달할 수 있게

완료 수준에 대해서 계획을 세우자. 마일스톤을 별도 게임 레벨이나 세계를 기준으로 세

우지 말고 전체 게임의 완성도나 정교함을 기준으로 세우자. 먼저 채워야 하는 기초적인

양이 있다고 생각하고 작업하자. 그런 다음 추가 기능 목록을 덧붙이거나, 시간이 더 있다

면 에셋의 품질을 개선하자. 끝으로 시간과 돈이 장애가 되지 않는다면 게임에서 꼭 개선

하고 싶은 개선점, 추가 기능, 보완점 등을 나열해 두자. 이런 식으로 작업하면 항상 지금

까지 완성된 수준으로 언제든 돌아갈 수 있고 지금까지의 노력 결과를 항상 옆에서 지켜

볼 수 있다.

■ 재미에 대한 질문. 과제나 게임 플레이에 대한 아이디어를 구현하기 전에 스스로에게 이

과제가 재미있는지 물어보자. 텍스트 어드벤처 게임이 더 복잡해지면서 플레이어는 세계

를 돌아다니다 음식을 먹거나 물을 마시지 않으면 힘이 약해져 결국 죽게 됐다. 물론 램프

의 기름을 가득 채워두는 일은 게임에서 재미를 줄 수 있지만 플레이어가 먹거나 마시지

않아 죽는 것은 게임을 더 지루하게 만들 뿐이다.

■ 실현 가능성에 대한 질문. 논리적이고 게임 세계에서 허용된다면 꼭 사실적이지 않아도 된

다. 세계의 전제와 세계 속의 사람들의 문화가 명확히 정의됐는지에 대해서만 고민하자.

■ 가장 빠른 길. 디자인을 잘 선택하면 개발을 앞당길 수 있다. 색상 스키마, 디자인 모티브,

지역 건물 재료를 초기에 설계해 두면 개별 에셋을 더 빠르게 디자인할 수 있을 뿐 아니라


시각적인 환경의 연속성도 유지할 수 있다. 예를 들어 지역 환경에 나무가 부족하고 등변

삼각형을 통해 신앙을 나타내는 문화권에 오래된 정착민들이 살고 있다면, 이 환경에서

대부분의 건물은 석재 건물일 테고 환경 전체적으로 삼각형 모티브를 사용할 것이다. 그

리고 나무는 중요한 물건에만 별도로 사용할 것이다. 이 영역의 한 공장에서 많은 양의 천

을 생산한다면 이 천의 색상이 원주민 옷의 주요 색상이 될 것이다. 이처럼 색상 스키마와

모티브에 대해 미리 생각해 두면 디자인 결정을 빨리 할 수 있을 뿐 아니라 환경 전체적으

로 많은 에셋을 재사용할 수 있다. 비록 플레이어가 이 마을의 내부적인 사정을 잘 알지

못하더라도 플레이어는 무의식적으로 이 마을이 좀 더 그럴듯하다고 믿을 것이다.

■ 대역. 스턴트 대역을 여러 과제에 사용하는 것을 두려워하지 말아야 한다. 스턴트 대역은

원본 객체를 복잡하게 하지 않고 다양한 과제에서 간단히 복제해 빠르게 사용하는 데 도

움을 준다.

■ 에셋. 무료, 구매, 처음부터 디자인? 시간과 재정 비용을 꼼꼼히 비교해 본다. 누가 만들더

라도 똑같아 보일 정도로 일반적인 객체라면 이미 나와 있는 것을 사용하는 편을 고려하

자. 그에 반해 때로는 구매한 에셋을 사용할 준비를 하고 수정하는 데 비용보다 더 많은

시간이 들 때도 있다. 이 객체가 게임이나 세계의 특징을 담고 있는 고유 객체라면 직접 만

드는 계획을 세우자. 하지만 때로는 기존 에셋에 새롭고 고유한 매핑을 적용하거나 약간

의 수정만으로도 이와 동일한 효과를 보는 경우도 있다.

■ 기술적인 고려 사항. 시작 단계에서부터 게임이 최신 기술을 필요로 하는지, 중간 수준의

기술을 요하는지, 또는 오래된 하드웨어에서도 실행될 수 있는지 결정하자. 고성능 장비

에서 게임을 개발 중이라면 프레임레이트와 필요한 제약사항에 대한 감이 잡힐 때까지 정

기적으로 배포 대상이 되는 장비에서 테스트하는 게 좋다.

■ 사용 가능한 기능. 현실적인 대체 방안이 없다면 여러분이 필요한 시점이 되면 핵심 기술

을 사용할 수 있을 거라는 막연한 기대를 갖고 설계하지 말아야 한다.

■ 디자인 대안. 현재 소프트웨어 기술이나 대상으로 하는 기기에서 여러분이 원하는 기능

이 실현 불가능한 경우에도 유연하게 대응한다. 프레임레이트나 하드웨어가 충분히 지원

하지 않는 상태에서 무리하게 고급 기능이 동작하게 하는 데 시간을 낭비하지 않는다.

■ 플랫폼 고려사항. 게임을 설계하기 전에 다양한 플랫폼의 요구사항과 제약 사항을 조사

한다. 여러 플랫폼을 대상으로 개발 중이라면 플랫폼 사이의 차이점을 분명히 인식한다.


■ 먼저 기획하고 테스트한다. 작업을 시작하기 전에 현재 가고 있는 방향이 어디인지 또 무

엇이 필요한지 분명히 인식한다. 기본적인 내용이 정리되고 필요한 사항을 분명히 이해하

기 전까지는 세부 사항에 얽매이지 않는다.

■ 종이 설계. 3D 에셋, 환경, 텍스처, 기타 아트 에셋에 대한 작업을 시작하기 전에 아이디

어, 환경 맵, 기타 생각을 종이에 스케치한다.

■ 프록시 객체. 목업, 테스트, 초기 POC에 사용할 프록시 또는 대역을 만들어 놓는다. 최종

에셋에 대한 작업을 시작하기 전에 기능을 분명히 정리해 둔다. 특정 아이디어를 제대로

구현하지 못할 경우 에셋의 요구조건이 크게 달라질 수 있다.

■ 일관성. 스타일, 세계, 콘텐츠에 대한 아이디어 조사를 한다. 테마를 선택하고 세계, 스타

일, 분위기, 색상 스키마를 정의한 후 이를 충실히 지킨다.

■ 베타 테스터. 모든 사람에게 여러분의 생각을 미리 알려줘서는 안 된다. 베타 테스터는 게

임에 대해 모르는 상태에서 테스트를 해야 한다. 베타 테스터 뒤에 서서 힌트를 제공하거

나 방향을 제시해서는 안 된다. 베타 테스터들이 올바른 길을 모르는 상태에서 어떻게 행

동하는지 가만히 지켜보기만 한다.

■ 상호작용. 실제 기능에 대한 작업을 하기 전에 각 객체가 어떻게 동작하고 어떻게 반응하

는지 정확히 매핑된 플로우차트나 다이어그램을 작성한다.

실시간 게임과 프리렌더링 게임의 비교

오래된 경력의 3D 아티스트도 처음 게임을 개발하다 보면 실시간 게임과 관련한 다양한 개념,

제약사항, 이슈를 만난다. 이런 단어 중 대부분은 이미 익숙한 것들이지만 이를 실제로 처리하는

과정은 어려울 수 있다. 아티스트가 에셋의 표현과 게임이 적당한 프레임레이트로 실행되게 하

는 물리적인 요구 조건 사이에서 절충점을 찾는 일은 때로는 매우 어려울 수 있다.

가장 많이 착각하는 내용은 다각형 개수가 프레임레이트를 결정하는 주 요소라는 점이다. 하

지만 실제로는 모든 사항이 프레임레이트에 영향을 준다. 다각형 개수뿐 아니라 프레임레이트는

장면에서의 빛의 수, 재료나 셰이더의 복잡도, 텍스처와 메시에서 차지하는 메모리 양, 물리 이

론, 애니메이션, 입자 시스템 등 모든 요소의 영향을 받는다. 실시간 게임에서 새로 도입된 대부

분의 개념은 프레임레이트를 개선하는 데 도움을 줄 수 있다.


이 절에서는 이런 다양한 용어들에 대해 간단히 설명한다. 이 절에서 이런 용어 설명보다 더 중

요한 내용은 왜 그리고 어떻게 이런 요소들이 프레임레이트에 영향을 주는지다.

DCC(디지털 콘텐츠 생성 애플리케이션): 이런 프로그램에는 3ds 맥스, 마야, 시네마4D, 블렌

더 등이 있다. 이들 프로그램 중 일부는 관련 실시간 엔진을 갖고 있기도 하지만, 대부분의 DCC

프로그램은 실시간 애플리케이션에서 사용할 에셋을 생성하거나 프리렌더링한 스틸샷 또는 영

화를 만드는 용도로 활용한다.

프레임레이트: 사람의 눈은 초당 30프레임 이상을 거의 보지 못한다. DCC 애플리케이션에서

애니메이션이나 최종 작업물은 영화용인지 또는 비디오용인지에 따라 초당 24프레임 또는 30프

레임으로 보는 게 보통이다. DCC 애플리케이션에서 객체에 애니메이션을 적용할 때는 타깃 미

디어에서 사용하는 프레임레이트에 따라 키프레임을 적용한다. 실시간 엔진에서는 프레임레이트

가 전혀 새로운 의미를 띈다. 실시간 엔진은 실행 도중 계속해서 프레임을 렌더링한다. 장면에 있

는 내용과 보이는 내용, 애니메이션이 일어나는 내용, 물리 이론의 사용 여부, 빛의 사용 여부, 기

타 다양한 요소들에 따라 프레임레이트는 끊임없이 변한다. 프로세서 속도를 높이고 그래픽 카

드를 추가해 보면 왜 타깃 사용자를 대상으로 프레임레이트를 가능한 한 빠르게 유지해야 하는

지 쉽게 알 수 있다.

게임을 2년 동안 준비해 최고 수준의 타이틀로 내놓을 수 있는 스튜디오 환경에서 프로젝트

시작 당시 최신의 컴퓨터에서 개발을 시작했다면 게임이 나오는 시점에서는 이 장비가 주류 컴퓨

터가 돼 있을 것이다. 그에 반해 인디 개발자들은 게임 하나당 2개월에서 6개월의 개발 기간을 갖

고 이에 맞춰 계획을 세워야 한다. 게임이 (보통 20프레임 정도까지 통용되는) 교육 프로그램이

아니라면 초당 30프레임을 최소 목표 범위로 설정해야 한다. 보통 사용하는 장비가 매우 빠르다

면 최소 프레임레이트를 100에서 150프레임으로 설정하는 게 좋다. 가능하다면 작업하는 장비

에서 프레임레이트 목표 값을 정확히 판단하기 위해 관련한 벤치마킹 테스트를 하는 게 좋다. 프

로젝트 시작 단계부터 게임에서 목표로 하는 시장과 이 시장에서 일반적으로 사용하는 하드웨

어에 주의하자.

내비게이션: DCC와 실시간 게임의 가장 큰 차이점 중 하나는 장면 내비게이션이다. 게임에서

3D 환경을 이동할 때 사용하는 제어 방식은 큰 부분을 차지한다. 실시간 게임이 처음 등장한 후

20년 가까이 지났지만 한 방에 20명의 게임 아티스트와 디자이너를 집어넣고 가장 좋은 게임 제

어 방식을 물으면 아마 20개의 각기 다른 의견이 쏟아질 것이다. 물론 게임의 종류가 이런 선택에

서 큰 부분을 차지하지만, 추가로 플레이어의 게임 기술 수준도 이런 선택에 큰 영향을 미친다.


많은 게임에서는 플레이어가 키를 재매핑하거나 지정할 수 있게 하는 반면, 다른 게임들은 다양

한 제어방식을 지원하는 대신 플레이어가 내비게이션에 직접 관여할 수 없게 하고 있다.

충돌: 실시간 게임에서 또 다른 주요 개념으로 충돌이 있다. 3D 세계에서 사용자가 원하는 곳

으로 자유롭게 이동할 수 있게 할 때는 플레이어가 울퉁불퉁한 지형이나 계단, 기타 장애물은

넘을 수 있게 하는 반면, 물리적인 장애물을 통해 벽은 넘을 수 없게 막아야 한다. 3D 엔진에서

는 보통 이런 담벽으로 보이지 않은 원시 객체를 사용하거나 메시 객체의 기하에서 직접 담벽을

가져오기도 한다. 이 중 프레임레이트와 관련해서는 첫 번째 방식이 더 효과적이다. 복잡한 메시

의 경우 충돌에 사용하기 위해 다각형 개수가 적은 스턴트 대역을 사용하기도 한다. 많은 게임 엔

진에서는 이런 작업을 대신 해준다.

다각형 : 이 용어는 애플리케이션에 따라 다양하게 사용한다. 실시간 게임에서 다각형은 보통

메시 객체의 삼각형 면을 말한다. 다각형 개수는 메시 객체에 있는 다각형의 개수 또는 전체 장면

의 다각형 개수를 나타낸다. 게임 개발을 처음 하는 사람들은 캐릭터의 다각형 수가 몇 개이어야

하는지 자주 묻는다. 이에 대한 대답은 장면에서 진행되는 다른 상황에 따라 다르다는 것이다.

매 프레임마다 동시에 그려야 할 기하가 많다면 캐릭터가 바위 위에 홀로 떨어져 있을 때보다 캐

릭터에 훨씬 더 적은 수의 다각형을 사용해야 한다. 이때도 앞에서와 마찬가지로 게임이 최종 실

행될 장비가 이를 결정하는 기준이 된다.

또 한 가지 중요하게 고려할 점은 객체가 얼마나 중요한지, 또는 객체를 얼마나 가까이서 볼지

다. 객체가 게임 줄거리나 플레이에 있어서 부수적인 객체라면 많은 다각형을 사용하지 않아도

된다. 플레이어가 화면 공간에서 200×200픽셀보다 큰 객체를 볼 일이 전혀 없다면 많은 다각형

을 사용한 세부 묘사는 생성 시간과 CPU 사용량 측면 모두에서 자원 낭비가 될 것이다.

단순 원시 도형 vs. 메시 객체: 원시 도형은 여러 파라미터로 정의된 객체다. 예를 들어 구는 반

지름, 높이, 너비 요소로 정의한다. 메시 객체는 객체의 변형축을 기준으로 정점의 정확한 위치

또는 오프셋을 지정해 정의한다. 대부분의 엔진은 간단히 사용할 수 있는 원시 객체를 최소 몇

가지씩 제공한다. 원시 객체는 디스크에서는 적은 용량을 차지하지만 게임에 일단 사용하고 나

면 다른 메시 타입 객체와 마찬가지로 메모리에 들어간다.


LOD(Level of Detail)(그림 1-29): 게임의 특정 시점에는 객체를 자세히 봐야 하고 많은 세부

표현이 필요하지만, 나머지 경우에는 이 객체가 멀리 있다면 엔진에 불필요한 부담을 주지 않기

위해 LOD 대역을 사용할 수 있다. LOD를 사용하면 특정 거리에서는 많은 다각형을 사용한 객

체가 숨겨지고 적은 수의 다각형을 사용한 스턴트 대역이 그 자리를 대신 차지해 프레임레이트를

올려준다. 일부 엔진에서는 엔진 자체에서 적은 수의 다각형을 사용한 버전을 생성해 미리 지정

한 거리에서 객체를 바꿔줌으로써 이를 자동으로 처리해준다. 다른 엔진을 사용하거나 중요 메

시를 사용하는 경우에는 아티스트가 LOD 버전(들)을 별도로 만들어 적용한다.

그림 1-29 ㅣ 객체의 각기 다른 버전의 다각형 수를 보여주는 LOD 적용 예

다각형 수가 적은 버전으로 종종 이미지를 사용한 알파 채널을 쓰기도 한다. 정적인 상태에서

는 이미지를 포함하는 두 평면이 교차해 X자 배치를 이룬다. 그러다 간혹 세 개의 평면이 사용되

기도 한다. 이 이미지는 항상 자체 완전한 조명을 받는다. 이런 동적인 버전은 항상 카메라를 바

라보도록 회전한 이미지로 이뤄진 단일 면으로 구성된다. 이 기법은 빌보딩(billboarding)이라고

부른다(그림 1-30 참고).


그림 1-30 ㅣ X-트리와 동일 이미지를 사용한 빌보드된 트리

거리 컬링: LOD와 관련해 거리 컬링은 특정 거리에서 객체가 장면상에 더 이상 그려지지 않음

을 뜻한다. 많은 다각형을 사용한 객체가 장면에서 몇 픽셀만을 차지할 경우 이는 자원을 낭비하

는 꼴이 된다. 보통 특정 거리에서는 다각형 개수가 적은 대역 객체를 사용하고, 특정 시점에서는

거리 컬링을 사용해 다각형 개수가 적은 대역조차 드로잉을 중단한다.


안개(그림 1-31): 환경에 더 큰 시각적 재미를 주는 것 말고도 안개는 거리 컬링과 함께 사용해

객체들이 안개 속으로 사라짐과 동시에 더 빨리 컬링될 수 있게 도와준다. 안개는 두 종류가 있

다. 객체가 뒤로 감에 따라 객체의 정점 색상이 더 영향을 받는 정점 안개와 더 일관성 있는 결과

를 제공하며 더 많은 자원을 사용하는 픽셀 안개가 있다.

그림 1-31 ㅣ 왼쪽: 안개 없음. 오른쪽: 정점 기반 안개

그림 1-32 ㅣ 카메라 클리핑과 함께 사용한 안개


절단면(그림 1-33): 카메라는 전방 절단면과 후방 절단면을 갖고 있다. 객체는 전방 절단면보다

가깝거나 후방 절단면보다 멀리 있으면 렌더링되지 않는다. 절단면을 안개와 함께 사용하면 장면

에서 렌더링할 객체를 효과적으로 제한할 수 있다(그림 1-32 참고). 객체의 경계 상자 중 일부분

이라도 뷰 절두체(화면에서 보이는 영역)와 카메라 절단면 내에 있는 경우 객체의 각 면을 검사해

렌더링 여부를 판단한다.

그림 1-33 ㅣ 카메라 절단면

드로잉 순서(그림 1-34): 장면이 렌더링될 때 객체는 장면에서 한 번에 하나씩 그려진다. 엔진의

설정 방식에 따라 엔진은 특정 타입의 객체를 다른 객체들보다 먼저 그릴 수 있다. 객체가 장면에

추가된 순서대로 그려질 경우 알파 드로잉 이슈를 만날 가능성이 있다. 이 이슈는 부분적으로 투

명한 객체가 자신보다 뒤에 있는 객체보다 먼저 그려질 때 생긴다. 드로잉 과정에서는 객체가 부

분적으로 가려지면, 가려진 영역이 드로잉되지 않는다. 하지만 이렇게 가려진 부분을 검사할 때

는 가리는 객체의 모든 불투명도를 검사하지는 않는다. 다만 객체가 가려지는지 또는 가려지지

않는지 여부만 판단할 뿐이다. 항상 투명 객체 뒤에 객체가 그려지게 하려면 반투명한 객체를 가

장 나중에 그려야 한다.

일부 엔진에서는 시작 시점에 장면을 파싱해 반투명한 객체의 위치를 판단함으로써 이들 객체

를 그릴 시점을 파악하고 이를 통해 이런 드로잉 이슈를 해결한다. 이 방식의 단점은 반투명한 객

체가 애니메이션을 통해 시작 위치에서 벗어날 경우 드로잉 순서가 잘못된다는 점이다.


예측 가능한 순서대로 장면에 객체를 드로잉하는 엔진에서는 엑스레이 기계를 만들어 드로잉

순서를 재미있게 가지고 놀 수 있다(그림 1-35 참고). 다른 엔진에서는 이와 동일한 효과를 얻으

려면 특수 셰이더를 사용해야 한다.

그림 1-34 ㅣ 드로잉 순서와 불투명도. 좌측 상단: 창이 가장 먼저 그려진다. 다른 객체들은 가려지지 않는

경우에만 그려진다. 우측 상단: 나머지 객체들을 모두 그린 후 창을 마지막에 그린다. 좌측 중앙: 바닥을 창

다음에 그린다. 우측 중앙: 암사자를 창 다음에 그린다. 좌측 하단: 벽과 암사자를 창 다음에 그린다.

우측 하단: 벽을 창 다음에 그린다.


그림 1-35 ㅣ 드로잉 순서를 활용한 엑스레이 기계

어클루전 컬링(그림 1-36): 어클루전 컬링은 장면에서 특정 객체를 렌더링하지 않음으로써 프

레임레이트를 더 올려주는 또 다른 방식이다. 자동 어클루전 컬링을 적용하면 객체의 큰 블록을

검사하기 위해 장면의 객체에 대한 데이터가 생성된다. 마을이나 거주지가 양쪽이 절벽인 깊은

협곡에 있는 경우 한 협곡에 여러분이 있다면 다른 협곡은 기본 정의상 가려지게 된다. 이때는 한

시점에서 이런 객체들을 볼 수 있는지 모두 검사하기보다는 마을의 전체 내용을 그리지 않아도

된다.

그림 1-36 ㅣ 어클루전 컬링에 대한 설계


게임 설계를 잘 하려면 이런 어클루전 컬링도 최대한 활용해 프레임레이트를 올리는 게 좋다.

수동 어클루전 컬링은 객체를 그룹으로 조직화하거나 태그를 표시해 쉽게 적용할 수 있다. 플레

이어가 특정 영역 안으로 들어오거나 이 영역을 벗어나면 모든 객체를 비활성화하거나 활성화할

수 있다.

빛: 3D에서는 GI(전역 조명)이 아닌 기본 조명이 정점 단위로 적용된다. 각 정점은 소위 정점

법선을 갖고 있다. 정점 법선은 면 또는 삼각형이 어떻게 빛을 받는지 정해준다(그림 1-37). 빛 광

선은 광원으로부터 정점까지 추적하고 둘 사이의 각도에 해당하는 입사각은 정점에서 받는 빛의

퍼센트를 계산하는 데 사용된다. 각 정점이 받는 빛은 정점 사이에서 평균 계산된다. 입사각이

작을수록 정점은 더 많은 빛을 받는다.

입사각

광원

정점 법선

그림 1-37 ㅣ 단일 면에 적용된 기본 빛

공유 또는 평균화된 정점(그림 1-38): 인접한 면이 정점을 공유하거나 정점 법선의 평균값을 사

용할 경우 그 결과는 부드러워진다. 정점이 공유되지 않거나 법선의 평균값을 사용하지 않는 경

우 빛의 양이 각 정점 단위로 계산되므로 거친 모서리가 나타난다. 대부분의 DCC 프로그램은

모델링을 더 쉽게 하기 위해 실제 정점의 수를 숨긴다. DCC 프로그램에서 모델링할 때는 정점이

8개이던 큐브가 실시간 엔진으로 임포트하고 나니 정점 수가 갑자기 24개로 많아지는 이유도 바

로 이 때문이다.


그림 1-38 ㅣ 부드러운(공유된) 정점 vs. 거친 모서리(공유되지 않음)

그림 1-39 ㅣ 뒤집힌 모서리: 면을 따라 각기 다른 방식으로 평균화된 조명

정점 조명 vs. 픽셀 조명: 앞의 예제는 소위 정점 조명을 사용한 것이다. 이 조명은 가장 빠른 조

명 타입이며 다각형 수가 적은 모델에서 매우 효과적이다(그림 1-39 참고). 아쉽게도 다각형 수가

적은 모델에서는 정점 사이의 빛 평균으로 인해 지저분하고 불규칙적인 결과가 나타난다. 물론

다각형 개수가 많을 경우 빛이 좀 더 균일하게 비춰지지만, 더 많은 정점에 대해 빛을 계산해야

하므로 연산 비용이 더 많이 든다. 그에 반해 픽셀 조명은 메시의 현재 화면 크기에 따라 더 많은

계산을 수행한다. 이 경우 장면에서 가까이 있는 객체는 장면에서 멀리 떨어진 동일 메시보다 렌

더링 시간이 더 든다.

픽셀 조명은 섀도우, 쿠키(투사된 마스크), 정점 법선에도 영향을 미치며 이로 인해 그만큼 연

산 부담이 늘어난다. DCC 프로그램에서는 이런 기능을 기본으로 가정하지만 실시간 게임에서는

이들 요소가 추가 자원을 사용하고 프레임레이트를 느리게 하는 원인이 된다. 유니티 게임 엔진에

서는 그래픽 카드가 픽셀 조명을 지원하지 않을 경우 조명이 자동으로 정점 조명으로 적용된다.


그림 1-40 ㅣ 법선 맵: 이 그림의 독특한 색상은 원본 메시의 방향 배치를 표현한다.

이 그림에서 빛의 패스는 다각형 수가 적은 메시의 정점 법선이 아니라 이 정보를 통해 만들어졌다.

법선 매핑(그림 1-40): 법선 매핑은 메시 표면의 디테일을 시뮬레이션 해 마치 실제 디테일이 있

는 것처럼 빛을 수행하는 것을 말한다. 법선 매핑을 사용하면 렌더링 과정에서 많은 자원을 절

약하지는 않지만 많은 다각형을 사용하는 부담을 크게 줄일 수 있다. 하지만 법선 매핑은 법선을

저장할 추가 저장 공간이 필요하다는 단점이 있다. 더불어 많은 디테일을 표현해야 한다면 법선

맵의 크기가 매우 커질 수도 있다. 대부분이 사람들이 법선 매핑을 통해 저해상도의 괴물 얼굴

이미지를 표현할 수 있다는 사실은 익히 알고 있지만 법선 매핑은 그림 1-41이나 1-42처럼 살아

있는 물체가 아닌 객체의 디테일을 표현하는 데도 유용하게 활용할 수 있다.

그림 1-41 ㅣ 법선 맵. 좌측 상단: 다각형 수가 적은 메시. 상단 중앙: 다각형 수가 많은 메시.

우측 상단: 광원맵 결과를 적용한 다각형 수가 적은 메시. 좌측 하단: 광원맵과 고해상도의 법선 맵을

적용한 다각형 수가 적은 메시. 하단 중앙: 저해상도의 법선 맵을 적용한 다각형 수가 적은 메시.

우측 하단: 고해상도 법선 맵을 적용하고 광원맵을 사용하지 않은 다각형 수가 적은 메시


그림 1-42 ㅣ 왼쪽에 빛을 비춘 법선(상단 이미지)과 오른쪽에 빛을 비춘 법선(하단 이미지).

상자의 오른쪽에 있는 스프링 객체의 빛을 주의해서 살펴보자.

셰이더: 3D에서는 메시 객체를 생성한 후 객체의 표면 속성을 시각적으로 표현하는 데 필요한

속성을 모두 담고 있는 재료를 메시 객체에 적용한다. 이런 속성에는 색상, 텍스처 또는 패턴, 부

드러운 정도, 반사도, 빛을 방사하는 품질 등 여러 가지가 포함된다. 전통적으로 렌더링은 일반적

으로 처리하고 렌더링 시점에 다루는 속성도 일부 속성으로 제한했다. 하지만 그래픽 카드가 발

전함에 따라 그래픽 카드를 통해 객체의 표면을 더 상세히 묘사할 수 있게 됐고, 지금은 각 재료

에 대해 어떤 일을 해야 하는지 그래픽 카드에게 알려주는 셰이더라는 코드를 사용하고 있다. 셰

이더는 빛과 마찬가지로 정점 렌더링 또는 픽셀 렌더링용으로 지정할 수 있다. 앞에서와 마찬가

지로 정점 셰이더는 픽셀 셰이더보다 더 효과적이지만, 픽셀 셰이더는 시각적인 품질이 더 우수

하고 더 많은 효과를 묘사할 수 있다(그림 1-43).


그림 1-43 ㅣ 픽셀 조명을 비춘 재료(가운데)는 정점 조명을 비춘 재료(오른쪽)보다 모서리의 기하가 좀 더

세밀하다. 정점 조명을 비춘 재료에서는 모서리가 거칠고 도드라져 보이는 것을 볼 수 있다.

보이지 않는 실제 경계: 실시간 게임에서 중요한 디자인 고려 사항 중 하나는 플레이어가 게임

영역을 벗어나는 것을 막는 방식이다. 물리적으로는 보이지 않는 충돌벽만 생성하면 된다. 하지

만 플레이어가 움직일 수 있는 경계 영역을 시각적으로 표현하는 방식은 여러 가지가 있다. 이 중

외부 환경에서 가장 많이 사용하는 해결책은 물로 둘러싸인 섬으로 환경을 표현하거나 산으로

둘러싸인 평지 또는 계곡을 사용하는 것이다. 도시 환경의 경우 담벽이나 도로 블록, 막다른 골

목 등으로 막을 수 있을 것이다. 게임의 환경이나 스토리에 부합된다면 늪이나 지뢰밭을 통해 플

레이어가 경계 영역을 벗어나지 못하게 할 수도 있다.

지형 생성기: 대부분의 현대 게임 엔진은 지형 생성 모듈을 제공한다. 게임 디자이너는 이런 지

형 생성기를 통해 언덕과 계곡, 호수를 만들어 지형의 모양을 그리고 내부 변위 맵(displacement

map)을 사용해 더 상세한 표현을 할 수 있다. 또 변위 맵 형태의 실제 지질 데이터도 사용할 수 있

다. 메시의 위치를 지정한 후 대부분의 엔진에서는 다양한 브러시 타입을 사용해 지형에 텍스처

를 그릴 수 있게 해준다. 이때 각 텍스처별로 마스크가 내부적으로 생성되며 그 결과가 위에 레이

어 형태로 쌓여 풍부하고 다양한 지형을 표현하게 해준다.

일부 지형 생성기는 나무, 숲, 기타 메시를 지형에 그리는 옵션도 제공한다. 나무와 묘목, 풀 등

은 종종 바람의 영향을 받으며 자동 LOD 메커니즘을 갖추고 있는 게 보통이다.

동적 테셀레이션(그림 1-44): 지형 생성기와 더불어 지형 메시 결과는 동적 테셀레이션

(tessellation)을 적용해 플레이어가 포커스된 상황에서 좀 더 세밀한 디테일을 보여주고, 플레이

어가 멀리 떨어졌을 때는 불필요한 자원 낭비를 줄이기 위해 덜 세밀한 묘사를 보여줄 수 있다.


그림 1-44 ㅣ 지형 메시의 테셀레이션

정리

이 장에서는 어드벤처 게임의 뿌리인 인터렉티브 텍스트 게임부터 초기 그래픽 어드벤처 게임,

그리고 3D 렌더링 시대와 오늘날 실시간 어드벤처 게임에 이르기까지 어드벤처 게임의 역사를

살펴봤다. 이 과정에서 우리는 스타일과 형식이 끊임없이 바뀌는 동안에도 이 장르가 계속해서

인기를 끌게 만든 요인들을 분석해 봤다. 두려움을 모르는 어드벤처 게이머들은 자신들의 현실

보다 더 흥미롭고 자극적인 세계를 체험해보고 싶어한다. 특별한 컴퓨터 기술이 없더라도 어드벤

처 게이머들은 육체의 한계를 뛰어넘기를 꿈꾸고 가질 수 있는 것은 무엇이든 모으려고 하며 사

회적인 책임에 얽매이지 않고 지적인 퍼즐을 풀고 싶어 한다.

또 이 장에서는 게임 개발과 관련한 설계 요소들을 살펴봤다. 이런 설계 요소에는 환경 레이아

웃 같은 물리적인 이슈부터 게임의 재미 요소와 같은 개념적인 고려 사항, 여러분의 최종 결정에

영향을 주는 기술적인 명세 등이 모두 포함됐다. 이어서 1인칭 형식과 3인칭 게임 형식의 장단점

을 살펴보고 1인칭 게임을 개발할 때 해야 할 일과 하지 말아야 할 일들을 목록으로 정리했다.

끝으로 3ds 맥스나 마야, 시네마 4D, 블렌더 같은 프리렌더 DCC 프로그램이 아니라 실시간

엔진의 관점에서 3D를 바라보는 법을 배웠다. 이 과정에서 게임을 제대로 실행하는 데 필요한 프

레임레이트는 다각형 개수, 빛의 타입, 재료, 다양한 컬링 타입 등 여러 요소의 영향을 받는다는

사실을 배웠다. 또 3D 게임의 장면 이동은 바닥과 벽과의 충돌 상호작용으로 인해 매우 독특한


성격을 갖고 있으며 해결해야 할 다양한 안고 있음을 배웠다. 내비게이션과 관련한 이런 해결 과

제들은 이 책의 내용을 진행하면서 계속해서 살펴볼 것이다.

다음 장에서는 유니티에 첫 발을 담근다. 우선 변형, 뷰포트, 에셋 관리와 관련한 기본 기능을

살펴보고 이어서 3D 전반에 대해 간단히 설명한다.

Beg

inni

ng 3

D G

ame

Dev

elop

men

t w

ith U

nity

53

02유니티 UI의 기본 — 시작하기

지금쯤 독자들은 유니티를 사용해 뭔가를 만들고 싶어 몸이 근질근질할 테니 유니티 UI(사용자

인터페이스)에 대한 소개는 가급적 짧게 하겠다. 이런 UI는 필요할 때마다 좀 더 깊게 들여다보

기로 하고, 지금은 기본적인 레이아웃과 개념을 익히는 데에만 집중하자. 책의 내용을 더 진행하

기 전에 UI에 대해서 더 깊게 알고 싶다면 유니티의 도움말 파일에 입문자가 보기에 적합한 내용

이 있으니 참고하자.

유니티 설치와 시작

http://unity3d.com/unity/download/를 통해 유니티를 내려받고 설치한다. 유니티를 처음 실행

하면 대화상자를 통해 제품을 등록해야 한다. 유니티를 설치한 컴퓨터가 인터넷에 연결돼 있지

않더라도 등록은 온라인을 통해 쉽게 할 수 있다. 컴퓨터가 인터넷에 연결된 경우에는 바로 등

록 페이지로 이동한다. 유니티 3D는 프로 버전의 30일 시험판을 제공한다. 이 책의 마지막 몇 장

에서는 프로 버전의 기능을 많이 사용하므로 프로 버전은 이 장들을 볼 때 사용하는 게 좋을 것

이다.

그림 2-1 ㅣ 유니티 아이콘


유니티를 시작하려면 바탕화면에 추가된 아이콘(그림 2-1)을 클릭하거나 윈도우 시작 메뉴

프로그램 Unity 또는 맥의 경우 Applications Unity에서 아이콘을 선택하면 된다.

새 프로젝트 또는 장면의 로딩과 생성

유니티에서 작업하려면 항상 새 프로젝트를 시작해야 한다.

팁

프로젝트와 관련해 생성 또는 선택하는 폴더 자체가 프로젝트가 된다. 프로젝트를 열 때는 개

별 콘텐츠가 아니라 프로젝트 폴더 자체를 선택해야 한다.

새 프로젝트를 생성하면 필수 파일들이 들어 있는 디렉터리 또는 폴더가 생성된다. 이 프로젝

트가 설치된 위치를 기억해 두거나, 다른 위치를 선택하기 위해 찾기 버튼을 사용한다. 그럼 프로

젝트에 포함시킬 에셋 패키지를 고르라는 대화상자가 나타날 것이다. 과거 버전의 유니티에서는

프로 패키지와 표준 패키지가 선택 항목으로 제공됐다. 하지만 지금은 패키지 컴포넌트 영역으

로 구분돼 있으므로 특정 게임 타입에 맞춰 에셋을 줄일 수 있다. 이 책에서는 사용할 수 있는 컴

포넌트들에 대한 감을 익힐 수 있게 거의 모든 패키지를 사용한다. 이때 무료 버전을 사용 중이라

면 프로 패키지를 로드할 수는 있어도 사용할 수는 없다는 점에 주의하자.

1. 유니티를 연다.

프로젝트 마법사 대화상자가 열리고 프로젝트를 선택하라고 한다.

2. 그림 2-2와 같이 Create New Project 탭을 선택한다.

팁

유니티가 이미 열려 있다면 File 메뉴에서 New Project를 선택한다.

3. Browse를 클릭하고 유니티 프로젝트를 보관할 위치로 이동한 다음 책의 프로젝트를 보

관할 새 폴더를 생성한다.

4. 폴더명을 BookProject로 지정한다.

02 유니티 UI의 기본 — 시작하기 l 55

5. Toon과 Standard Assets(모바일) 패키지, 프로 패키지(무료 유니티 버전을 사용 중이라

면)를 제외한 모든 패키지를 선택한다.

그림 2-2 ㅣ 프로젝트 마법사 대화상자

노트

이 책에서는 선택적으로 일부 프로 기능을 사용하기도 하지만 프로젝트의 최종 결과물을 얻기

위해 이런 프로 기능에 의존하지는 않는다. 유니티 프로 버전으로 업그레이드하거나 30일 시

험 버전을 사용 중이라면 Import 패키지 내의 Assets 메뉴를 통해 프로 패키지를 쉽게 임포

트할 수 있다.

6. Create를 클릭한다.

그럼 유니티가 종료되고 다시 열리면서 새로 생성한 BookProject를 보여줄 것이다.

유니티 프로에는 그림 2-3과 같이 업데이트된 ‘다크’ UI가 들어 있다. 이 책에서는 대다수 독자

가 무료 버전을 사용 중일 것이므로 캡처 화면이 이보다 밝은 버전인 원본을 사용하고 있다.


그림 2-3 ㅣ 유니티 다크 프로 스키마의 기본 설정

두 스킨 중 하나를 고르려면 그림 2-4와 같이 Edit 메뉴의 Preferences에 접근하면 된다.

그림 2-4 ㅣ 유니티 Preferences 대화상자

프로젝트 뷰의 Hierarchy 뷰와 Standard Assets 폴더에는 카메라가 있다(그림 2-5). 새 프로젝

트를 생성하면 Assets라는 폴더가 기기의 파일 시스템상에 생성된다. 이 폴더의 내용은 Project

뷰에서 볼 수 있다.


중요

에셋이 장면에 추가된 후에는 예를 들어 OS의 탐색기(윈도우)나 Finder(맥)를 사용해 이를 재

정렬하거나 조직화해서는 안 된다. 이렇게 하면 장면의 내부 경로와 메타데이터가 모두 훼손

된다.

그림 2-5 ㅣ 메인 편집 창의 새 프로젝트

작업을 더 진행하기 전에 장면을 저장하자. 이와 같은 장면은 하나의 레벨로 생각하면 된다. 프

로젝트는 여러 개의 장면을 포함할 수 있다. 이 중 일부 장면은 실제 레벨에 해당하고 다른 장면

은 메뉴나 스플래시 화면 등이 될 수 있다.

7. 파일 메뉴에서 Save Scene을 선택하고 장면을 TestScene1로 저장한다.

새로운 장면은 새 프로젝트를 시작할 때 생성한 폴더 중 하나인 Assets 폴더에 저장된다. 유니

티에서는 그림 2-6과 같이 프로젝트 뷰에서 장면이 유니티 게임 아이콘 바로 옆에 나타난다.

나중에는 이런 장면에 별도로 하위 폴더를 지정할 예정이지만, 지금은 장면이 잘 보이므로 이

렇게 놔둬도 무방하다. 프로젝트를 연 후 Hierarchy 뷰에 내용이 보이게 하려면 장면을 선택해

야 하는 경우도 종종 있다.


그림 2-6 ㅣ 새로운 장면

레이아웃

유니티 UI의 레이아웃을 재조정하는 방법에는 여러 가지가 있다. 이 책에서는 그림 2-7에 나온

표준 2×3 레이아웃을 사용하지만 독자들은 자신에게 편한 레이아웃을 얼마든지 사용해도 된

다. 그림 2-8과 같이 애플리케이션 창의 우측 상단 영역에서 Layout 드롭다운 메뉴를 선택하면

언제든 레이아웃을 바꿀 수 있다.


그림 2-7 ㅣ 유니티의 2×3 레이아웃 UI

그림 2-8 ㅣ 2×3 분할 레이아웃

장면 창

그림 2-9에 나온 장면 창은 장면의 시각적인 측면을 개발하는 곳이다. 즉 이곳에서 여러분의 아

이디어를 기획하고 직접 실행할 수 있다.


그림 2-9 ㅣ 카메라 아이콘과 그리드를 보여주는 장면 창

팁

장면 뷰에서 그리드를 보여주려면 Game Overlay 버튼을 꺼야 한다(그림 2-9).

게임 창

그림 2-10에 나온 게임 창은 런타임 환경에서 게임을 빌드하기 전에 게임을 테스트해 볼 수 있는

곳이다. 이 뷰에서는 객체를 선택할 수 없고 장면 뷰와 달리 기본 조명도 없다. 게임 창에서 객체

를 보려면 메인 카메라를 사용해야 한다.

계층 뷰

그림 2-11의 계층 뷰는 현재 활성화된 화면에 있는 대상들을 보여준다. 런타임 시에 동적으로 장

면에서 추가되고 제거되는 게임 객체들은 장면에서 활성화된 시점에 이 뷰에 나타난다.


그림 2-10 ㅣ 게임 창

그림 2-11 ㅣ 메인 카메라를 갖고 있는 계층 뷰

프로젝트 뷰

그림 2-12의 프로젝트 뷰는 현재 프로젝트에서 사용할 수 있는 모든 에셋과 더불어 완성된 게임

또는 애플리케이션에서 사용할 수 있는 모든 장면과 레벨을 포함한다. 이 뷰는 프로젝트를 보관


하는 Asset 폴더를 그대로 반영한다. 이 위치에서 에셋을 삭제하면 하드 드라이브에서도 에셋이

삭제된다. 탐색기를 통해 디렉터리에서 에셋을 삭제하면 프로젝트 뷰에서도 해당 에셋이 삭제되

므로 장면이 깨질 수 있다.

그림 2-12 ㅣ 프로젝트 뷰

인스펙터

인스펙터 뷰를 사용하면 계층 뷰나 프로젝트 뷰에서 선택한 객체와 관련한 다양한 속성과 컴포넌

트에 접근할 수 있다. 또 인스펙터에서는 장면과 관련한 기타 정보에도 접근할 수 있다. 현재 장면에

유일하게 포함된 메인 카메라를 계층 뷰에서 선택한 후 그림 2-13과 같이 인스펙터를 살펴보자.


그림 2-13 ㅣ 카메라가 선택된 상태에서의 인스펙터

툴바

메뉴 바 아래에는 툴바가 있다(그림 2-14). 툴바에는 다섯 개의 각기 다른 컨트롤이 들어 있다.

그림 2-14 ㅣ 툴바

그림 2-15에 보이는 변형 툴은 내비게이션(장면 이동)과 변형 기능을 제공한다. 가장 왼쪽에

있는 버튼인 팬 툴은 장면 뷰를 이동하고 조정하는 궤도 툴과 줌 툴이 되기도 한다. 뷰를 움직이

려면 클릭하고 드래그하면 된다(팬 툴 기능). 현재 뷰포트의 중심 궤도를 돌려면 Alt 키를 누른


상태에서 클릭하고 드래그하면 된다. 또 줌 기능을 사용하려면 Alt 키(윈도우) 또는 Cmd 키(맥)

를 누르고 오른쪽 마우스 버튼을 누르면 된다. 앞으로 실제 장면에 객체를 추가하면서 보겠지만

이런 작업을 수행할 때 다른 방식도 사용할 수 있다. 하지만 객체를 추가하기 전에는 이런 내비게

이션 기능을 미리 테스트하지 않는 게 좋다.

그림 2-15 ㅣ 장면 이동 툴

나머지 세 버튼은 편집 모드에서 장면상의 객체를 변형하기 위한 버튼이다. 지원하는 변형 기

능으로는 이동, 회전, 스케일 변형이 있다.

객체는 서로 다는 좌표계와 중심점을 기준으로 변형할 수 있다. 그림 2-16에 나온 내비게이션

툴 옆의 컨트롤들은 이런 선택 옵션을 켜고 끌 수 있게 해준다.

그림 2-16 ㅣ 중심점과 좌표계 툴

그림 2-17에 나온 가운데 컨트롤은 여러분이 마치 플레이어가 된 것처럼 실제 게임이 어떻게

동작하는지 확인할 수 있게 해주는 플레이 모드 버튼이다.

그림 2-17 ㅣ 플레이 모드 컨트롤

플레이 컨트롤 옆에는 레이어 드롭다운 메뉴(그림 2-18)를 볼 수 있다. 레이어는 유니티에서 어

떤 카메라나 빛을 비춰 객체를 렌더링할지 제어하는 용도로 사용한다.

그림 2-18 ㅣ 레이어 컨트롤

레이어 드롭다운 메뉴(그림 2-19)는 앞서 2×3 분할 레이아웃을 사용하면서 사용해본 적이 있

다. 유니티 UI의 대부분은 재설정하거나 커스터마이징할 수 있다. 레이어 드롭다운 메뉴는 기본

레이아웃과 미리 정의한 레이아웃으로 빠르게 전환할 수 있게 해준다.


그림 2-19 ㅣ 레이아웃 컨트롤

메뉴

일반적인 파일 처리 옵션 외에 메뉴에는 유니티와 관련한 다양한 개념과 기능이 들어 있다. 대부

분의 기능은 그림 2-20에 나온 메뉴에서 찾을 수 있다. 메뉴 아이템은 키보드 단축키를 통해서도

사용할 수 있다.

그림 2-20 ㅣ 유니티 메뉴

파일

파일 메뉴에서는 장면과 프로젝트를 로드, 생성, 저장할 수 있다. 또 이 메뉴는 실행 파일 또는 다

른 배포 형식으로 게임을 빌드하는 데 사용할 수 있다.

편집

편집 메뉴(그림 2-21)에는 잘라내기, 복사, 붙여넣기, 복제, 삭제 명령뿐 아니라 일부 런타임 명령

도 들어 있다. 하지만 실제 에셋의 편집은 인스펙터에서 이뤄진다. 이런 명령을 볼 때는 옆에 있는

키보드 단축키도 주의해서 보자.

계층 뷰나 프로젝트 뷰를 통해 접근할 수 없는 장면 설정이 몇 가지 있다. 렌더 설정과 더불어

프로젝트 설정(그림 2-21)은 장면의 많은 어트리뷰트를 접근할 수 있게 해준다. 이곳에서 옵션을

선택하면 관련 정보가 인스펙터 뷰에 나타난다.


그림 2-21 ㅣ 프로젝트 설정 옵션

에셋

에셋 메뉴에서는 Create 하위 메뉴를 볼 수 있다. 이 메뉴는 보통 DCC 프로그램을 통해 임포트

할 수 없는, 메시(mesh)에 속하지 않는 특수 효과, 물리적 재료, 스크립트 등의 자원을 생성하는

메뉴다. 또 이 메뉴는 커스텀 폰트를 정의하고 폴더와 프리팹으로 프로젝트를 조직화하는 곳이

기도 하다. 이 메뉴는 프로젝트 뷰를 마우스 오른쪽 클릭해서도 접근할 수 있다.

게임 객체

게임 객체 메뉴는 빈 게임 객체를 생성하게 해준다. 게임 객체는 객체, 스크립트, 기타 유니티 컴

포넌트의 기본 컨테이너다. 그룹과 마찬가지로 게임 객체도 자체 변형을 갖고 있으며 객체나 메


시처럼 조직화할 수 있는 논리적인 형태다. 가장 간단한 형태의 게임 객체는 스크립트, 콜라이더,

기타 컴포넌트만 포함할 수도 있지만, 게임 객체는 장면의 객체를 조직화하기 위한 부모 그룹이

나 폴더로 사용할 때 실제 진가를 발휘한다.

Create Other 하위 메뉴에서는 빛, 입자 시스템, GUI 2D 객체, 유니티 원시 객체 같은 다양한

객체를 생성할 수 있다. 맥스나 마야 같은 렌더 프로그램의 원시 객체와 마찬가지로 이들 객체는

공간상에서의 점 집합을 통해 정의된 게 아니라 여러 개의 파라미터를 통해 내부적으로 정의된

다는 점에서 임포트한 메시와는 차이점이 있다.

컴포넌트 메뉴

컴포넌트 메뉴에서는 사운드, 스크립트, 콜라이더, 미리 정의된 기능을 생성하거나 확장한 객체

및 에디터에 접근할 수 있다. 컴포넌트는 임포트한 메시에 물리적인 성격을 더할 수 있게 해주고

객체에 함수 커브 애니메이션을 추가할 수 있게 해주며 스크립트를 통해 게임이나 애플리케이션

을 움직여 인터랙티브한 기능을 부여할 수 있게 해준다.

지형 메뉴

지형 메뉴에서는 지형 에디터를 사용해 상세 지형을 생성하고 지형에 숲이나 바위, 기타 기능을

추가하기 전에 기본 파라미터를 정의할 수 있게 해준다. 또 이 메뉴는 지형에 쓸 높이맵을 불러오

고 내보낼 수 있는 메뉴이기도 하다.

창 메뉴

이름에서 알 수 있듯이 이 메뉴는 유니티에서 다양한 창과 에디터를 관리하는 메뉴다. 이 메뉴도

단축키를 제공한다.

도움말 메뉴

도움말 메뉴는 유니티의 다양한 도움말 메뉴얼에 접근할 수 있게 해주고 유니티 포럼과 릴리즈

노트, 버그 보고와 관련한 안내 문서를 제공한다.


간단한 객체의 생성

3D 애플리케이션에서 내비게이션을 실험할 때는 항상 화면에 뭔가를 두는 게 도움이 된다. 실제

게임에서는 대부분의 에셋을 임포트하겠지만, 앞으로 책을 보다 보면 유니티 게임 엔진에서 제공

하는 원시 객체가 유용한 경우도 많이 있음을 알게 될 것이다.

1. 그림 2-22와 같이 게임 객체 메뉴의 Create Other 항목에서 Cube를 선택한다.

그림 2-22 ㅣ GameObject Create Other 메뉴에서 Cube를 선택하는 화면

큐브는 장면의 뷰포트 중심에 생성된다. 뷰포트 내비게이션 툴을 사용해 봤다면 큐브가 아직

은 점보다 조금 커 보이는 정도일 것이다. 큐브를 게임 창에서 보면 작고 어두운 사각형 형태로 보

인다.

팁

아직 뷰포트를 이동해 보지 않았다면 내비게이션 툴 바에서 Move 버튼이 활성화돼 있어서 큐

브의 변형 장치를 볼 수 있을 것이다.


2. 마우스 휠 또는 맥에서 Cmd 버튼을 사용해 줌인한다. 그림 2-23처럼 장면 창에서 새로

만든 큐브를 줌인, 줌아웃한다.

그림 2-23 ㅣ 새로 생성한 큐브

게임 창에서 큐브를 더 자세히 보려면 카메라를 움직여야 한다. 이때 카메라를 움직이고 회전

하는 대신 큐브에 맞게 조정한 장면 뷰에 맞춰 카메라를 설정한다.

3. 계층 뷰에서 메인 카메라를 선택한다.

4. 게임 객체 메뉴에서 Align with View를 선택한다.

이제 큐브가 게임 창에서 보이고 장면 뷰의 미리보기에서도 보일 것이다(그림 2-24).


그림 2-24 ㅣ 게임 창의 카메라를 통해 본 큐브

조명 버튼이 꺼져 있으면 장면 창은 뷰포트를 직선으로 비추는 단일 조명인 기본 조명으로 비

춰진다. 이런 기본 조명으로 인해 포커스가 위치한 객체에는 항상 제대로 된 조명이 비춘다.

5. 기본 조명을 끄고 장면 조명을 켠다.

이번에는 큐브가 게임 창의 장면 주변광에 의해서만 비춰진다(그림 2-25).


그림 2-25 ㅣ 장면 조명을 켠 상태 - 아직 장면 조명이 없다.

장면 뷰포트의 이동은 카메라에 영향을 미치지 않는다. 뷰포트에서 Alt 키를 누른 상태로 커

서 위치를 바꾸거나 마우스 오른쪽 버튼을 누른 상태로 마우스를 앞뒤로 이동하면 뷰포트를 줌

인, 줌아웃할 수 있다. 맥에서는 줌을 클릭하고 드래그할 때 Cmd 키를 눌러야 한다

아직 뷰포트를 패닝(pan)해서는 안 된다.

6. 계층 뷰의 빈 영역을 클릭해 카메라를 선택 해제한다.

7. 큐브를 선택한다.

8. 큐브 주변의 뷰포트 궤도를 돌려면 뷰포트에 커서를 위치한 후 Alt 키와 마우스 왼쪽 버

튼을 누른 상태에서 마우스를 움직인다.


이렇게 하면 뷰가 뷰포트의 포커스 중심점을 기준으로 회전한다. 이때 게임 창에서 큐브를 관

찰하면 알 수 있듯이 큐브 자체는 회전하지 않는다.

뷰포트를 패닝하려면 Pan 버튼을 클릭하고 왼쪽 버튼을 누른 상태에서 뷰포트를 드래그한다.

이때 장면 창에 커서를 둔 후 마우스 가운데 버튼을 누른 상태로 마우스를 움직여도 된다.

9. 큐브에 기본 조명을 다시 비추기 위해 장면 조명을 끈다.

10. 큐브가 더 이상 중심에 위치하지 않도록 뷰 포트를 팬 이동한다.

11. Alt 키를 다시 사용해 궤도를 돌면서 어떤 방식으로 큐브가 아닌 현재 중심점을 기준으로

뷰가 이동하는지 살펴본다(그림 2-26).

그림 2-26 ㅣ 이제 큐브는 더 이상 장면 뷰에서 포커스가 위치해 있지 않다.

장면 뷰에서 뷰를 조절하더라도 게임 창에서 보이는 카메라 뷰에는 아무런 영향도 없다는 사실에 주의하자.


선택과 포커스

유니티에서 가장 중요한 내비게이션 개념 중 하나는 특정 객체나 영역으로 빠르게 줌인하는 것

이다.

뷰포트에서 큐브로 다시 포커스를 주거나 큐브를 찾으려면 다음과 같이 하면 된다.

1. 계층 뷰에서 큐브가 선택돼 있는지 확인한다.

2. 커서를 장면 창에 놓는다.

3. 키보드에서 F 키를 누른다.

그럼 뷰가 큐브의 중심으로 빠르게 이동한다.

이때 선택된 객체의 모서리가 어두운 녹색으로 보이는 것에 주의하자. 그림 2-27처럼 뷰 모드

의 드롭다운 메뉴를 사용하면 여러 모드에서 장면의 객체를 볼 수 있다.

그림 2-27 ㅣ 뷰 모드 드롭다운

4. 와이어프레임 모드를 사용해 본다.

이제 객체의 모서리만 보일 것이다.

5. 텍스-와이어 모드를 사용해 본다.

텍스-와이어 모드는 모서리를 갖춘 고체 객체를 보여주지만 텍스처 모드에서 선택된 객체와

달리 장면의 모든 객체에 텍스처와 모서리가 표시된다.


6. 다시 텍스처 뷰 모드로 돌아온다.

객체의 변형

3D 공간에서는 카테시안 좌표계라는 것을 사용한다. 오토데스크 제품을 사용해본 적이 있다면

Z가 세계에서 위쪽을 나타낸다는 사실에 익숙할 것이다. 이런 관행은 제도계에서 종이의 좌표가

X, Y였으므로 Z가 위가 될 수밖에 없었던 전통에서 유래했다. 유니티에서는 Y가 위쪽인데, 이는

X가 수평, Y가 수직을 나타냈던 초기 2D 모니터 공간으로부터 유래했다. 컴퓨터에 3D 공간이 생

겨남에 따라 Z는 모니터의 앞, 뒤 공간을 배정받았다. Z 심도에 대해서는 실시간 프로그램을 다

루면서 더 자세히 설명하겠다.

어느 쪽이 위쪽이든 상관없이 방향은 색상 RGB로 나타내며 이들 색상은 각각 X, Y, Z를 나타

낸다.

객체는 툴바의 좌측 상단에 있는 도구들을 활용해 장면에서 얼마든지 변형(이동, 회전, 스케

일 조정)할 수 있다(그림 2-28).

그림 2-28 ㅣ 변환(이동), 회전, 스케일 도구

1. 계층 뷰에서 큐브를 선택하거나 장면 뷰에서 큐브를 잡는다.

2. 이동 버튼을 선택한다.

그럼 큐브에 대한 변형 축이 나타난다.

3. 세 축 중 하나를 클릭하고 드래그한다.

이때 활성화된 방향은 노란색으로 변하고 이동이 해당 방향으로만 제한된다. 그림 2-29에서

볼 수 있듯이 객체는 게임 창에서도 움직일 수 있다.


그림 2-29 ㅣ 위치 변환한 (이동한) 큐브. 게임 창에서 볼 수 있듯이

카메라가 움직인 게 아니라 큐브가 움직였다는 사실에 주의하자.

4. 다음으로 회전 아이콘을 선택한다.

이 툴은 색상으로 표현된 원으로 이뤄져 있다.

5. 빨간색, 녹색, 파란색 원을 클릭하고 드래그해 어떤 결과가 나타나는지 확인한다.

이때 회색의 바깥쪽 원은 어느 쪽으로 궤도를 돌든지 상관없이 2D 화면 좌표에 따라 객체를

회전한다.

인스펙터에서는 객체의 변형을 직접 설정할 수 있다(그림 2-30).


그림 2-30 ㅣ 인스펙터에 보이는 대로 변형이 수행된다

6. 큐브의 변형 영역에서 Y 위치를 0으로, X 위치를 20으로, Z 위치를 10으로 설정한다.

7. F 키를 사용해 큐브의 새 위치로 뷰 포트의 포커스를 준다. 이때 장면 창에 커서를 먼저

위치시켜야 한다는 사실을 꼭 기억하자.

팁

유니티에서는 한 단위를 보통 1미터로 간주한다. 하지만 대부분의 3D 프로그램과 마찬가지

로 이런 스케일은 임의로 지정한 것이다. 그렇지만 앞으로 보겠지만 이런 기준 단위로부터

크게 벗어날 경우 빛이나 물리 이론 같은 기본 설정을 많은 부분 수정해야 하므로 주의해야

한다.

변형은 모두 부동 소수로 지정한다. 다시 말해 변형은 소숫점 이하 값을 통해 지정할 수 있다.

축 라벨 위에 커서를 옮긴 후 마우스 왼쪽 버튼을 누른 상태로 드래그해 숫자 값을 바꿀 수도

있다.

8. 마우스를 Y 스케일 라벨 위에 올리고 드래그한다.

그럼 큐브는 자체 축을 따라 스케일 조정되고 값이 인스펙터와 동일하게 바뀐다.


가운데 있는 작은 회색 사각형은 한 번에 한 축보다 많은 축을 조정할 수 있게 해준다. 스케일

툴과 더불어 이 사각형을 사용하면 세 축에 대해 동일하게 객체의 스케일을 조정할 수 있다.

9. 스케일 툴을 선택한다.

10. 스케일 툴의 가운데 있는 작은 회색 큐브를 클릭하고 드래그해 스케일을 균등 조정한다.

11. X, Y, Z 회전과 위치를 0으로 설정한다.

12. 스케일 X, Y, Z를 1로 설정한다.

13. F 키를 눌러서 뷰포트에 다시 포커스를 준다.

스냅

직접 장면 뷰에서 객체를 움직이거나 인스펙터에서 변형을 조정하는 것 외에 점차 양을 조절해

객체를 스냅시키거나 정점을 기준으로 객체를 서로 붙일 수도 있다.

1. 그림 2-31과 같이 편집 메뉴의 하단에서 스냅 설정 대화상자를 연다.

그림 2-31 ㅣ 스냅 설정 대화상자

이때 Move X, Move Y, Move Z가 모두 1로 설정된 것과 Rotation 스냅이 15도로 설정된 것에

주의하자. 점진적인 스냅을 사용하려면 Ctrl(윈도우) 또는 Cmd(맥) 키를 누른 상태에서 객체를

변형한다.


3. 변형 툴이 활성화돼 있는지 확인한다.

4. Ctrl 또는 Cmd 키를 누른 상태에서 장면 창에서 큐브를 천천히 움직인다.

그럼 큐브가 1단위씩 점진적으로 움직이는 것을 인스펙터를 통해 볼 수 있다.

5. Alt + 오른쪽 마우스 버튼을 사용하거나 마우스 스크롤 휠을 사용해 조금 줌아웃한다.


6. 스냅 설정 대화상자에서 이동량을 1에서 5로 바꾼다.

7. Ctrl 또는 Cmd 키를 여전히 누른 상태에서 큐브를 다시 움직인다.

8. 다시 이동량을 1로 설정한다.

이번에는 스냅이 좀 더 잘 눈에 띌 것이다.

회전 스냅은 객체의 방향을 바꿀 때 매우 유용하다. 회전 스냅은 위치 스냅과 같은 방식으로

동작한다.


2. 회전 툴이 활성화돼 있는지 확인한다.

3. Ctrl 또는 Cmd 키를 누른 상태에서 장면 창에서 큐브를 천천히 회전한다.

그럼 큐브가 15씩 점진적으로 회전할 것이다.

4. 스냅 설정 대화상자를 닫는다.

정점 스냅

점진적 스냅뿐 아니라 정점을 등록점으로 사용한 스냅도 가능하다. 이런 스냅 기능은 유기적인

환경에서도 유용하지만 도로나 트랙을 서로 붙일 때도 더 없이 유용하다.

1. 이동 툴을 활성화한다.


3. Ctrl + D를 사용해 큐브를 복제한다.

4. 큐브 중 하나를 선택하고 다른 큐브로부터 멀리 이동시킨다.

5. (정점을 나타내는) V 키를 누른 상태로 위치를 바꾼 큐브쪽으로 커서를 천천히 움직인다.

그럼 그림 2-32와 같이 커서를 움직임에 따라 변형 툴에서 큐브의 정점을 서로 붙여줄 것이다.


그림 2-32 ㅣ 변형 툴이 큐브의 정점 중 한 곳에 붙었다.

6. V 키를 계속해서 누른 상태로 왼쪽 마우스 버튼을 누른 채 다른 큐브의 원하는 정점에

붙을 때까지 큐브를 움직인다.

7. 나머지 큐브는 키보드에서 Delete 키를 누르거나 계층 뷰에서 큐브를 마우스 오른쪽 클릭

하고 메뉴에서 Delete를 선택해 제거한다.

스냅을 활용한 객체 위치 지정과 관련한 자세한 정보는 매뉴얼에서 ‘Positioning GameObjects’

를 참고하자.

장면 툴

지금까지는 뷰포트를 조절하고 시점 뷰포트에서 객체를 변형하기만 했다. 이 방식은 정확한 위치

를 알고 있거나 정확한 작업이 필요 없을 때는 유용하지만, 계속해서 뷰를 회전하거나 더 정확하

게 객체를 조절하려고 할 때는 효율적이지 않다. 그림 2-23에 보이는 장면 툴은 시점 뷰와 정사영

뷰를 서로 전환할 수 있게 해준다. 정사영 뷰(앞, 뒤, 상, 하)는 시점이 없으므로 위치와 스칼라 관

계를 파악하기 쉽다.


그림 2-33 ㅣ 장면 툴

1. 장면 툴 아이콘에서 Y 모양의 원뿔을 선택한다.

이렇게 하면 상단 뷰포트를 통해 볼 수 있다.

이 시점을 활용하면 화면-공간 변형 툴의 작업 내용을 좀 더 쉽게 이해할 수 있다.

2. 큐브를 선택하고 회전 툴을 활성화한다.

3. 바깥 원을 사용해 큐브가 정사영 방향에서 사라질 때까지 큐브를 25 내지 30도 회전한다.

4. 이동 툴을 활성화한다.

5. 좌표계를 전역에서 지역으로 바꾼다(그림 2-34).

그림 2-34 ㅣ 전역 좌표계에서 지역 좌표계로의 전환 및 객체 중심점의 전환

지역 좌표계에서는 고정된 장면 또는 세계 좌표계가 아닌 자신의 좌표계를 기준으로 객체를

변형할 수 있다. 이때 그림 2-34에 나온 것처럼 객체의 생성 중심점 대신 객체의 중심점을 사용할

수도 있다.

6. 이제 큐브를 지역 X 방향으로 움직인다.

7. 그런 다음 큐브의 회전값을 인스펙터에서 다시 0으로 설정한다.

이때 이동 툴 중간에 있는 작은 회색 사각형을 볼 수 있을 것이다. 이 사각형은 2축 이동을 가

능하게 해주며 정사영 뷰에서 매우 유용하다.

스냅을 활용하지 않는 정렬

객체를 다른 객체와 정렬할 때 게임 객체 메뉴의 옵션을 사용할 수도 있다.

1. 시점 뷰포트로 돌아가기 위해 장면 툴의 가운데 회색 상자를 클릭한다.


2. 큐브를 선택하고 F 키를 사용해 포커스를 주거나 찾는다.

3. 게임 객체 메뉴에서 Create Other Create a Sphere를 선택한다.

4. 스케일 툴을 활성화한다.

5. 가운데 노랜색 큐브를 사용해 구의 스케일을 큐브를 통해 볼 수 있도록 스케일을 동일하

게 조절한다(그림 2-35).

그림 2-35 ㅣ 구가 큐브와 동일한 위치에 생성됐다.

이 구는 큐브와 같은 지점에 생성됐다.

기존 객체를 정렬하려면 게임 객체 메뉴의 세 번째 정렬 옵션을 사용하면 된다.

1. 이동 툴을 선택한다.

2. 구를 큐브로부터 멀리 이동시킨다.

3. 큐브를 선택하고 뷰에서 큐브에 포커스를 준다.

4. 구를 선택한다.

5. 게임 객체 메뉴에서 Move to View를 선택한다.

이제 큐브가 뷰의 중심에 위치하므로 구가 다시 큐브와 같은 위치에 위치하게 된다.

6. 구를 계층 뷰에서 선택한 후 Delete 키를 누르거나 편집 메뉴에서 Delete를 선택하거나

Shi� + Delete를 눌러 제거한다.


조명

현재 장면 창에서는 빛을 비추고 있지만 게임 창에서 큐브는 어둡고 장면의 주변광만 받고 있다.

앞에서 창의 상단에 있는 Lighting 버튼을 눌러 기본 조명이 꺼지고 장면 빛이 켜지는 것을 볼 수

있었다. 하지만 아직 뷰포트에는 조명이 없으므로 게임 창에서 큐브는 어둡게 표현된다.

1. 장면 뷰에서 다시 큐브에 포커스를 주고 조금 줌아웃한다.

2. 게임 객체 메뉴에서 Create Other Create a Directional Light를 선택한다.

방향광은 장면에서 광원의 위치와 상관없이 평행한 빛을 발산한다.

3. 빛을 큐브로부터 멀리 떨어지게끔 위로 올린다.

4. 그림 2-36과 같이 큐브가 게임 창에서 빛을 잘 받을 때까지 장면 창에서 조명을 회전한다.

그림 2-36 ㅣ 큐브를 비추도록 방향을 설정한 방향광

5. Alt + 마우스 왼쪽 버튼을 사용해 그림 2-37과 같이 큐브에서 빛이 비추지 않는 면이 나

올 때까지 뷰포트를 궤도 회전한다.


그림 2-37 ㅣ 큐브에서 빛이 닿지 않는 면

디테일이 사라진 것을 볼 수 있다.

6. 빛 아이콘을 사용해 후면 빛을 끈다(그림 2-38).

그림 2-38 ㅣ 장면 빛을 끈 상태(기본 설정에서는 켜져 있다)


기본 빛은 뷰포트에 직접 비추므로 장면 창에서 뷰포트와 상관없이 모든 객체를 쉽게 볼 수 있

도록 해준다.

장면을 생성할 때는 장면 빛을 켜고 끄는 일이 자주 생길 것이다.

이쯤에서 인스펙터를 살펴보자. 그림 2-39에 인스펙터가 나와 있다.

그림 2-39 ㅣ 인스펙터에서 빛이 선택된 모습

7. 빛이 선택된 상태에서 빛 컴포넌트의 라벨 옆에 있는 박스를 선택 해제하고 다시 선택해

본다.

그럼 빛이 꺼졌다가 다시 켜질 것이다.

8. Color 라벨 옆에 있는 색상 팔레트를 클릭한다.

그림 2-40처럼 색상 대화상자가 열릴 것이다.


그림 2-40 ㅣ 색상 대화상자

9. Colors 이미지에서 클릭하고 드래그하면서 큐브에 비추는 빛의 색상이 어떻게 변하는지

관찰한다.

10. 은은한 색상을 선택한다.

11. 대화상자를 닫는다.

이번에는 기본 재료를 대체할 재료를 큐브에 추가해 보자.

1. 인스펙터에서 큐브를 선택한다.

2. 메시 렌더 영역에서 Materials 목록을 연다(그림 2-41).


그림 2-41 ㅣ 큐브의 기본 재료

한두 개의 예외를 제외하고 표준 에셋 패키지에서 미리 제공하는 재료들은 모두 특수 재료이

므로 여기서는 재료를 직접 생성한다. 재료를 보관하고 관리할 새 폴더부터 만들자.

3. 에셋 매뉴에서 Create Folder를 선택한다(그림 2-42).

4. 폴더명을 My Materials로 바꾼다.

팁

게임에 사용할 새 에셋을 생성할 때는 프로젝트 뷰가 지저분해지지 않도록 에셋을 조직화하는

게 중요하다. 이 책에서는 이런 용도로 사용하기 위해 여러 개의 폴더를 생성한다.

같은 메뉴를 프로젝트 뷰를 통해 직접 접근할 수도 있다.

5. 새로 만든 재료 폴더를 마우스 오른쪽 클릭하고 같은 Create 하위 메뉴에서 Material을

고른다(그림 2-43).


그림 2-42 ㅣ 새 폴더의 생성

그림 2-43 ㅣ 새 재료의 생성

그럼 새 재료 항목이 인스펙터에 나타난다.


그림 2-44 ㅣ 프로젝트 뷰와 인스펙터에 나와 있는 새 재료

6. 새 재료명을 TestBark로 지정한다.

7. 재료를 폴더에서 장면 창의 큐브로 드래그앤드롭한다.

8. 텍스처 썸네일 창(미리보기 창이 아니다)에서 선택 버튼을 고른 후(그림 2-44) Asset

Selector에서 슬라이더를 왼쪽 끝까지 밀고(그림 2-45) PalmBark를 고른다.

팁

에셋 선택 대화상자는 이미지, 애니메이션 클립, 사운드 클립을 컴포넌트, 셰이더, 장면의 기

타 파라미터로 로드할 수 있게 해준다. 이 대화상자를 사용하면 정확한 에셋 종류만 필터링할

수 있다는 장점이 있지만 해당 타입에 속하는 에셋을 모두 보여준다는 단점도 있다. 이후 우리

프로젝트에서는 프로젝트 뷰에서 에셋을 대상 파라미터로 직접 드래그하는 방식을 사용할 것

이다.


그림 2-45 ㅣ 에셋 선택 대화상자에서 PalmBark를 선택하는 화면

이제 큐브가 좀 더 멋진 텍스처를 갖게 됐다.

기본 셰이더는 간단한 디퓨즈 셰이더다.

9. 아래 화살표를 클릭하고 스페큘러 셰이더를 선택한다.

10. Shininess 슬라이더를 조금 조정한다.

각기 다른 셰이더를 실험하더라도 텍스처는 그대로 유지된다는 사실에 주의하자.

이제 우리가 만든 테스트 장면에 몇 개의 객체가 포함됐으니 결과물을 저장해 보자.

11. 파일 메뉴에서 Save Scene을 선택한 후 Save Project를 선택한다.

팁

장면과 프로젝트를 항상 저장해야 하는 것은 아니지만 이런 습관을 들이면 좋으므로 이 책에

서는 계속해서 이런 식으로 중간 작업물을 저장한다.


3D 객체

이 책이 주로 유니티 엔진과 게임 엔진 개념 전반을 배우고자 하는 디자이너를 대상으로 하고 있

긴 하지만 여기서는 3D에 익숙한 독자들을 위한 복습 겸, 2D 아트 디자이너들을 위한 초급 설명

겸 해서 3D를 조금 다른 시점에서 살펴보고 몇 가지 개념들이 실시간 이슈와 게임 관련 이슈와

어떤 관계를 갖고 있는지 알아보겠다.

오늘날 대다수 사람들은 3D 영화나 게임에 매우 익숙하다. 또 많은 사람들이 이런 영화나 게

임의 제작 과정을 다룬 다큐멘터리를 보고 이들 3D 작품에서 사용하는 배경 지식을 이미 갖추

고 있기도 하다. 앞 절에서 변형과 뷰포트 이동 개념을 이미 소개한 바 있으므로 여기서는 객체

자체에 대해 좀 더 자세히 살펴보겠다.

메시

겉으로 보기에는 지금까지 우리가 작업한 테스트 원시 객체와 전혀 다를 바 없어 보이지만 메시

의 저장 형식은 사뭇 다르다. 메시는 3D 객체를 생성하는 데 사용하는 파라미터 리스트 형태가

아니라 공간상에서의 점의 집합으로 저장된다. 따라서 메시는 무한히 다양한 모양을 가질 수 있

지만 하드 드라이브 공간도 그만큼 더 많이 차지한다. 메모리상에서 두 타입의 객체는 모두 같은

공간을 차지하므로 유니티에서 간단한 메시를 생성할지 또는 메시를 불러올지 판단할 때는 저장

공간과 다운로드 시간이 중요하다.

메시의 하위 객체

유니티에서는 메시의 하위 객체에 쉽게 접근할 수 없지만 스크립트를 사용하면 이런 하위 객체

에 영향을 줄 수 있으므로, 메시를 구성하는 하위 객체를 알아두면 도움이 된다.

■ 정점: 정점은 가장 작은 하위 객체로, 공간상에서의 점이다. 정점은 위치와 별반 다를 바

없으므로 그리지 않는다. 하지만 정점은 색상, 불투명도, 빛 등과 같은 정보를 포함할 수

있다.

■ 모서리: 모서리는 정점 사이의 직선이다. 대부분의 3D 프로그램에서 렌더링된 결과에는

진정한 의미의 곡선이나 표면이 포함되지 않는다는 사실을 주의해야 한다. 이런 표면은

오히려 작게 쪼갠 직선을 여러 개 합쳐 놓은 근사 값에 더 가깝다.


■ 면: 면은 삼각형(그림 2-46)으로 나타내며 메시에서 렌더링할 수 있는 가장 작은 영역이

다. 면은 세 개의 정점과 이들 정점을 연결하는 모서리, 이들 모서리가 이루는 표면에 의

해 정의된다. 면은 면의 어느 쪽을 렌더링해야 할지 엔진에게 알려주는 법선도 갖고 있다.

두 면을 모두 렌더링하도록 특별히 지정한 셰이더를 사용하지 않는 한, 면은 한 쪽만 그려

진다.

그림 2-46 ㅣ 면의 해부

면은 DCC 프로그램에서는 종종 다른 방식으로 처리한다. 예를 들어 3ds 맥스에서는 후면을

‘켠 채’ 작업하지만 렌더링과 익스포트 시점에는 후면을 계산에 포함시키지 않는다. 마야에서는

기본 설정상 후면을 생성하고 렌더링하며 익스포트한다. 이 경우 메시에 포함되는 정보의 양이

증가하며 렌더 시점에 숨겨진 면을 잘라내는 데 추가로 시간이 들어간다. 하지만 이런 방식은 실

시간 엔진에서는 피해야 한다. 게임에 사용할 자원을 모델링할 때는 후면을 항상 끄고 작업하는

습관을 들이는 게 좋다.

면의 법선을 정점의 법선과 헷갈려서는 안 된다. 정점의 법선은 면이 받게 될 빛을 계산하는 데

사용한다. 벡터는 빛에서 정점 법선까지 추적하고 입사각은 둘 사이의 각도로 정점에서 받는 빛

을 계산하는 데 사용한다. 입사각이 작을수록 빛을 받는 퍼센트도 커진다. 정점 법선의 수직 위

에서 빛이 비추는 정점은 입사각이 0도이며 가장 많은 빛을 받게 된다.

때로는 면의 법선이 뒤집히거나 정점 법선이 뒤집힘에 따라 그림 2-47 같은 이상한 결과를 볼

수 있다. 메시에 사용하는 캐드 데이터는 종종 면의 법선 정보를 아예 갖고 있지 않다. 면은 항상

양면을 그리는 경우가 많으므로 면에 대해 법선이 생성될 때 법선이 섞이는 경우가 종종 있다.


(1) (2)

(3) (4)

그림 2-47 ㅣ 면, 면의 법선, 정점 법선

■ 그림 상단 행: 면의 법선은 어느 쪽에 면을 그릴지를 결정한다.

y (1)왼쪽: 면의 법선

y (2)오른쪽: 면의 법선이 아래쪽을 향함(면을 그리지 않는다).

■ 그림 하단 행: 정점 법선과 입사각. 정점 법선이 잘못된 방향을 가리키는 면의 입사각이

큰 것에 주의하자.

y (3)왼쪽: 면의 법선과 정점 법선이 위를 가리킴.

y (4)오른쪽: 면의 법선은 위를 가리키지만 정점 법선은 아래쪽을 가리킴.

매핑

객체가 재료의 일부로 텍스처나 이미지를 사용하는 경우 객체는 객체의 표면에 이미지를 어떻게

적용해야 하는지 렌더러에게 알려주기 위한 매핑 좌표가 필요하다. 가장 간단한 형태의 매핑으

로는 평면 투영이 있고, 복잡한 매핑으로는 여러 개의 UV 언랩 같은 매핑도 있다.


매핑 좌표는 U, V, W 등으로 부르는데, 그림 2-48과 같이 U는 맵의 한 쪽면을 나타내고 V는

다른 모서리를 나타낸다. W는 면 법선의 축을 나타내며 이 축을 기준으로 맵을 회전할 때 사용

된다.

그림 2-48 ㅣ UVW 좌표

가장 많이 사용하는 매핑 타입으로는 그림 2-49와 같이 평면, 사각형, 원통형, 구형 매핑이 있다.

⑴ ⑵ ⑶ ⑷

그림 2-49 ㅣ 가장 흔한 매핑 타입 네 가지

■ (1)평면: 이미지가 선택 방향으로부터 메시를 통해 투영된다.

■ (2)사각형: 이미지의 평면 투영이 큐브 형태로 객체의 각 면에 배치된다.

■ (3)원통형: 이미지가 원통으로 감싸인 채 메시 안과 바깥쪽으로 투영된다. 이 매핑 타입에

서는 연결점이 눈에 띄지 않게 하거나 연결 위치를 볼 수 없게끔 모서리에 타일을 배치하

는 맵이 필요하다.

■ (4)구형: 이미지가 원통에 감싸인 채 상단과 하단에 배치된다. 이 매핑에서도 부드러운 연

결을 위한 타일 배치가 필요하다.


하나의 객체는 그림 2-50에서 볼 수 있듯이 여러 매핑 타입 조합을 갖출 수 있다. 이 객체에서

기둥은 원통형 매핑이고 표지판은 박스 매핑됐으며 꼭대기는 구형 매핑돼 있다.

⑴ ⑵

⑶ ⑷

그림 2-50 ㅣ 객체의 복합 매핑

■ (1)좌측 상단: 표지판의 기하

■ (2)우측 상단: 사각형, 원통형, 구형 매핑을 갖춘 표지판

■ (3)좌측 하단: 단일 텍스처로 매핑된 표지판

■ (4)우측 하단: 여러 개의 텍스처로 매핑된 표지판


하위 객체에 별도의 재료를 사용하지 않고 한 객체에 하나의 텍스처만 칠할 경우 이 객체는 언

랩(unwrap)됐다고 간주한다. 이때 매핑은 특정 종횡비, 보통 1:1, 정사각형 및 더 커스터마이징된

텍스처를 적용하기 위해 손으로 그린 조각에 맞게 정렬된다. 언래핑을 적용할 때는 그림 2-51처

럼 왜곡을 줄이려고 하면 그리기가 더 어렵고(작은 조각을 여러 개 사용) 왜곡을 늘리면 그리기

가 더 쉽다(큰 조각을 사용)는 사실 사이에서 적절한 균형을 찾는 문제가 가장 어렵다.

그림 2-51 ㅣ 구의 언랩 타협점 찾기

이때 단점은 커스텀 디테일을 위해서는 보통 해상도를 포기해야 한다는 점이다. 하지만 장점은

한 번만 사용할 객체의 경우 단일 재료가 게임 엔진에서 관리하기 훨씬 쉽다는 점이다. 추가로 유

니티에서는 보다 효과적인 처리를 위해 같은 재료를 사용하고 특정 정점 개수 미만을 사용하는

여러 객체는 내부적으로 결합 또는 배치 처리된다.

객체가 유기적이라기보다는 구조적인 성격을 띤 경우 그림 2-52와 같이 언랩 맵에 일반적인 매

핑과 재료를 렌더링해 손으로 그리는 과정을 생략할 수 있다. 이렇게 작업한 객체는 페인팅 프로

그램에서 손보거나 수정할 수도 있고 그대로 사용할 수도 있다.


그림 2-52 ㅣ 표지판의 매핑 전 모습, 매핑 언랩, 기존 재료와 매핑을 사용해 렌더링한 모습

보통 1회성 객체에는 빛 정보도 함께 포함시킨다. 이를 베이크한 빛이라고 부른다. 이런 빛은

실제 장면을 비추는 빛이 될 수도 있고 그림 2-53과 같이 주변 폐색 역할을 할 수도 있다(구석의

어두운 부분).


그림 2-53 ㅣ 별도의 빛을 사용하지 않은 채 빛을 자체적으로 포함한 표지판.

이런 광원맵을 사용할 때는 중첩되는 부분이 없어야 한다는 단점이 있다. 이 말은 동일한 매시

영역 또는 반사된 매시 영역을 이제 별도로 분리해야 한다는 뜻이다. 모든 부분은 맵 안에 들어

가게끔 크기를 줄여야 하는데 이로 인해 해상도의 손실이 발생한다.

이 문제에 대한 해결책 중 하나는 디퓨즈 텍스처와 광원맵별로 두 개의 UV 맵을 사용하는 방

법이다(그림 2-54 참고). 이 경우 렌더링 시간이 좀 더 걸리지만 디퓨즈 텍스처가 타일 배치 및/또

는 중첩이 가능하므로 더 큰 해상도를 수용할 수 있다. 광원맵은 보통 디테일이 많이 필요 없으

므로 매우 작은 크기로 사용하며 렌더 시점에 추가한다. 보통 대부분의 영역이 동일한 물리적 재

료로 돼 있는 건물과 기타 구조물은 이런 식으로 처리해 큰 광원맵이 전체 구조물을 비추고 하나

의 상세 텍스처 맵이 전체 타일로 배치된다. 이 기법은 베이크한 섀도우 맵을 실시간 섀도우로 런

타임 시점에 바꾸는 지형이나 게임 또는 애플리케이션에서 플레이어가 텍스처를 커스터마이징

할 수 있는 게임 설정에서도 매우 유용하다.


그림 2-54 ㅣ 별도의 디퓨즈 맵과 광원맵을 사용한 구조물과 광원맵을 통해 조율한 타일의 결과

재료

재료는 보통 DCC에서 쓰는 재료와 실시간 엔진에서 쓰는 재료가 다르다. 재료의 경우 바로 임포

트해 사용할 수 있는 재료는 디퓨즈 텍스처를 사용한 간단한 재료뿐이다. 재료를 엔진으로 임포

트한 후에는 엔진의 셰이더를 사용해 재료를 다시 만들 계획을 세워야 한다. 대부분의 게임 엔진

은 임포트한 텍스처를 다루는 작업과 관련한 모범 절차를 마련하고 있다.


현대 엔진들은 다양한 용도로 사용할 수 있는 셰이더를 갖추고 있으므로 텍스처와 마스크를

사용해 DCC 애플리케이션에서 만드는 복잡한 재료를 그대로 만들 수 있다.

정리

이 장에서는 유니티를 사용하는 법을 처음으로 살펴봤다. 먼저 새 프로젝트를 생성해 봤고 다섯

개의 메인 뷰도 하나씩 살펴봤다. 장면 뷰에서는 에셋을 편집하고 정렬할 수 있으며, 계층 뷰에는

현재 장면에 포함된 에셋이 나열돼 있다. 프로젝트 뷰에는 프로젝트에 포함된 모든 에셋이 들어

있으며, 게임 창에서는 플레이어를 볼 수 있고 플레이어와 상호작용할 수 있다. 끝으로 인스펙터

에서는 에셋 파라미터, 컴포넌트, 장면 또는 프로젝트 설정에 접근할 수 있다. 이 장에서 꼭 알아

둬야 할 핵심사항은 운영체제의 파일 관리자를 통해 프로젝트의 에셋 폴더에 있는 내용을 재정

렬하지 말아야 한다는 것이다.

다음으로 메뉴에 들어 있는 내용을 알아보기 위해 메뉴를 간단히 살펴봤다. 이 과정에서 유니

티 포럼, 유니티 Answers로 연결되는 도움말 메뉴를 특히 주의해서 살펴봤다.

이어서 유니티를 활용해 첫 번째 객체로 간단한 큐브를 생성하고 이를 테스트 대상으로 삼아

뷰포트 내비게이션, 객체 찾기와 포커스, 객체 변형(이동, 회전, 스케일) 등을 시험해 봤다. 이 과

정에서 방향광을 생성하고 카메라를 장면 뷰에 맞춘 후 게임 창에서 테스트 객체를 살펴보기도

했다. 이때 인스펙터에 선택된 객체의 파라미터와 기타 정보가 나타나는 것을 확인했고 인스펙

터에서 이들 값을 바꾸면 객체를 좀 더 정확하게 변형할 수 있다는 사실을 배웠다. 끝으로 프로

젝트 뷰에서 새 폴더를 생성하는 법을 배웠고 이 폴더 내에서 새로운 재료 에셋을 생성하는 법을

배웠다.

뷰포트, 객체, 변형의 3D 공간을 살펴본 후에는 3D의 고유 개념을 좀 더 깊게 들여다봤고 3D

메시를 구성하는 하위 객체들을 살펴봤다. 이 과정에서 빛을 어떻게 계산하는지 배웠고 메시의

모서리를 거칠지 않고 부드럽게 해주는 요소를 살펴봤다. 그런 다음 가장 간단한 매핑 타입부터

완전히 언랩되고 빛 매핑처리까지 된 매핑에 이르기까지 3D 객체의 매핑 타입을 배웠고, 언제 각

각을 사용해야 하는지도 살펴봤다. 끝으로 메시를 임포트한 후에는 대부분의 객체에서 최선의

결과를 이끌어내기까지 주의가 필요하다는 사실도 배웠다.

다음 장에서는 유니티의 스크립팅을 살펴본다. 먼저 객체가 큐에서 수행하는 매우 간단한 스

크립트부터 작성한 후 이어서 유니티의 표준 에셋 스크립트 한두 개를 분석해 스크립트 구문에

대한 감을 익혀볼 생각이다.

Beg

inni

ng 3

D G

ame

Dev

elop

men

t w

ith U

nity

101

03스크립트에 발 담그기

인터랙션의 핵심은 스크립트에 있다. 유니티에서는 모든 내용을 스크립트로 작성해야 한다. 다

행히 바로 사용할 수 있는 스크립트가 다양한 경로를 통해 현재 많이 나와 있다. 유니티에서

는 여러분이 바로 스크립트를 적용할 수 있게끔 수많은 유용한 스크립트를 기본으로 제공한다.

도움말에는 다양한 예제와 스크립트 코드가 나와 있다. 유니티3D 위키와 유니티 포럼, 유니티

Answers도 스크립트를 배우는 데 많은 도움이 된다. 또 유니티 웹 사이트에서 내려받는 튜토리

얼을 통해서도 필요한 내용을 배울 수 있다. 대부분의 튜토리얼 자료에는 코드에서 수행하는 작

업을 상세히 설명하고 있다. 유니티 스크립트는 자바스크립트, C#, Boo로 작성할 수 있지만 대부

분의 유니티 공식 튜토리얼이 자바스크립트로 작성돼 있는 만큼 여기서도 이런 관례를 따른다.

이 책은 스크립트를 가르쳐주기 위한 책은 아니지만 스크립트를 읽는 법을 배우고 각 스크립

트 영역에서 하는 일을 이해할 수 있다면 더 많은 작업을 할 수 있다. 많은 스크립트에 주석이 충

실히 달려 있지만 일부 스크립트에는 주석이 충분하지 않은 경우도 있다. 이 책에서는 게임 기능

을 개발하면서 핵심 부분을 설명하고 여러분이 최대한 쉽게 새로운 지식을 익힐 수 있도록 했다.

스크립트는 구문보다는 논리와 밀접히 연관된다는 사실을 기억하자. 즉 인터랙션을 주도하는 것

은 다름아닌 논리다.

스크립트란?

스크립트는 지시문의 집합 정도로 생각하면 된다. 이번 주말에 밀드레드 이모네서 벌어지는 파티

에 참석하기 위해 이모네 농장으로 가야 한다고 가정하자. 이 경우 구글이나 맵퀘스트를 사용해

길을 찾고 이를 출력한 다음 가야할 방향을 지정한 문장을 정리해둘 것이다. 여러분이 과자와 음


료수를 파티에 가져가기로 했다면 메모지 상단에 수퍼마켓에 들러 식료품을 사야 한다는 점도

적어둘 것이다. 또 여동생이 다른 사람들이 주차할 수 있게 마구간에서 먼 곳에 차를 주차해야

한다고 한 말도 적어둘 수 있고, 여러분의 형이 말한 것처럼 차가 아니라 오토바이로 올 예정이라

면 닭들이 위에 올라타지 못하게 덮개를 가져가야 한다는 말도 적어둘 것이다. 까먹을 수 있는 사

항들에 대비에 추가로 해야 할 일들은 방향 정리 메모지 뒷면에 모두 적어두어 파티와 관련한 내

용을 모두 한 곳에 정리해둘 것이다. 만일 여러 종이에 메모를 적었다면 메모지를 스테이플러로

찍어 한데 합치고 ‘밀드레드 이모의 파티’라는 제목을 상단에 적어둘 것이다.

스크립트에는 이처럼 다양한 정보와 지시문이 포함될 수 있다. 게임 엔진에서 이런 정보를 언

제 어떻게 사용할지 조직화하는 것은 여러분의 몫이다.

스크립트와 관련해 어려운 문제 중 하나는 어디에 스크립트를 작성할지 결정하는 것이다. 문

을 여닫는 등의 명령과 관련한 일부 스크립트의 경우 이런 결정을 쉽게 할 수 있다. 이때는 장면

에서 해당 기능을 하는 문에 바로 스크립트를 두면 된다. 마찬가지로 악어가 플레이어 캐릭터에

게 달려들게 하는 스크립트는 아마도 악어에 작성해 두면 될 것이다. 하지만 낮을 밤으로 바꾸

는 등의 역할을 하는 스크립트는 특정 객체와 직접적인 관련을 맺고 있지 않다. 이런 스크립트는

장면상의 여러 객체의 상태를 제어하므로 이런 명령을 언제 실행해야 할지 판단할 때는 플레이

어의 인터랙션을 고민할 때보다 더 오랫동안 생각해야 한다. 이 경우 대부분 특정 스크립트를 포

함하기 위한 용도로 빈 GameObject 객체를 생성하고 스크립트 목적에 맞게 객체명을 지정하는

방식을 사용한다.

유니티에서 객체는 장면 내의 다양한 스크립트에 의해 제어된다. 스크립트는 스크립트가 제어

하는 GameObject 내에 들어 있을 수도 있고 조명 스위치처럼 조명과 같은 다른 객체에 대해 액

션을 일으킬 수도 있다. 물론 객체가 필요한 정보와 기능을 모두 갖춘 단일 스크립트를 갖고 있을

수도 있지만 이 경우 스크립트가 지나치게 특화돼 재사용하기가 쉽지 않다. 이는 마치 10대 소녀

의 옷과도 비슷하다. 10대 소녀는 특정 옷에 맞춰 옷, 신발, 지갑, 스카프, 모자를 고른다. 하지만

이 경우 소녀는 다른 옷과 액세서리를 믹스매치하기가 쉽지 않다. 범용적인 스크립트는 마치 액

세서리와 같아서 매번 재사용할 수 있다. 작은 스크립트로 특정 작업을 수행하게 하면 접근이 어

렵다는 단점이 있지만 이식성이 늘어남에 따라 이런 단점을 충분히 보완할 수 있다.

지나치게 많은 스크립트 이론으로 머리가 복잡해지기 전에 이 과정을 단순화하고 실제 스크립

트 작성을 시작해 보자.

03 스크립트에 발 담그기 l 103

스크립트의 구성 요소

스크립트는 네 가지 주요 요소로 이뤄진다. 바로 함수, 변수, 방정식, 주석이다. 변수는 숫자부터

문자에 이르기까지 다양한 값이 될 수 있다. 함수는 뭔가를 하는데, 이때 보통 변수와 방정식을

함께 사용한다. 주석은 코드가 실행될 때는 무시된다. 주석은 코드가 하는 일을 알려주고 임시

로 코드를 비활성화하는 용도로 사용한다.

함수

유니티에서 함수는 크게 세 타입으로 분류할 수 있다. 바로 게임 관련 함수(시스템 함수, 입력 함

수, 네트워크 함수), 객체 관련 함수, 사용자 정의 함수다.

이 장에서 유니티를 다시 실행했다면 2장에서 작업한 장면인 TestScene1을 열어보자.

1. 프로젝트 뷰에서 TestScene1을 클릭한다.

2. 프로젝트 뷰에서 새 폴더를 생성한다.

3. 새 폴더명을 My Scripts로 지정한다.

4. 새 폴더를 선택한 상태에서 폴더를 마우스 오른쪽 클릭해 오른쪽 클릭 메뉴의 내용을 확

인한다. Create 하위 메뉴에서 JavaScript를 선택한다.

규칙

이 책에서 새 스크립트를 생성하라고 할 때는 항상 자바스크립트를 생성한다는 사실을 기억

하자.

이제 폴더에 NewBehaviorScript라는 새 스크립트가 추가됐을 것이다. 이 스크립트의 내용을

인스펙터(그림 3-1)를 통해 볼 수는 있지만 인스펙터에서는 바로 편집할 수 없다.


그림 3-1 ㅣ 새 스크립트

팁

새로 생성한 스크립트는 항상 편집 전에 이름을 수정하자.

5. 프로젝트 뷰에서 이름을 클릭해 이름 변경 모드가 될 때까지 기다린 후 이름을 변경한다.

6. 이 스크립트의 이름을 SimpleRotate로 지정하고 엔터를 눌러 이름 변경을 마친다.

7. 프로젝트 뷰에서 이름을 더블클릭하거나 인스펙터 상단에 있는 편집 버튼을 클릭해

UniSciTE 스크립트 에디터(맥에서는 Unitron)를 연다.

팁

맥에서 유니티를 사용 중이라면 Unitron 에디터가 스크립트 에디터가 된다. 이 에디터에서는

색상과 폰트가 화면과 조금 다르다.


그림 3-2 ㅣ 스크립트 에디터에서 새 스크립트를 연 모습

그림 3-2에서 볼 수 있듯이 새 스크립트에는 이미 코드가 일부 들어 있다. 이 코드에는 빈

Update 함수가 들어 있다.

function Update () {

}

함수의 분석

■ 정의: 함수. 함수는 소문자로 돼 있으며 유니티의 UniSciTE 스크립트 에디터에서 볼드체

로 나타난다. 함수는 다양한 명령을 수행한다.

■ 이름: Update. 함수명은 항상 대문자로 시작한다.

■ 인자: (). 함수가 호출될 때 함수로 전달되는 정보다. 여기서는 전달하는 정보가 없으므

로 괄호가 비어 있다.

■ 내용: {}. 내용 또는 지시문은 이 중괄호 안으로 들어간다. 이 함수의 경우 아직 지시문이

없다.

Update 함수는 모든 게임 엔진에서 가장 중요한 함수다. 이 시스템 함수는 실행할 작업이 있

는지 확인하기 위해 적어도 매 프레임마다 한 번씩 확인한다. 이 함수는 Transform을 통해 계속

회전을 하게 하거나 특정 조건에 부합되는지 확인하는 등 다양한 작업을 할 수 있다.

1. 여는 중괄호 다음에 커서를 두고 엔터를 몇 차례 눌러 코드를 입력할 공간을 마련한다.


2. 함수 내에서(중괄호 내에서) 탭을 누른 후 다음 명령문을 입력한다.

transform.Rotate(0,5,0);

팁

들여쓰기나 탭은 구문상 꼭 필요하진 않지만 더 많은 기능을 추가하고자 할 때 코드를 한결 읽

기 쉽게 해 준다.

이 코드 줄에서 하는 일은 다음과 같다.

■ transform은 객체가 어떻게 행동할지 정의하는 영역이다.

■ Rotate는 Rotate 함수(이 부분의 첫 글자가 대문자인 것에 주의하자)로서 transform 클

래스의 특정 작업을 나타낸다.

■ (0,5,0)는 Rotate 함수에서 필요로 하는 X, Y, Z 회전 파라미터를 나타낸다.

■ ; 는 작업 또는 코드 줄이 끝났음을 나타낸다.

이 코드에서는 점 표기법도 사용하고 있다(그림 3-3 참고). 점 표기법은 다양한 객체 및 작업에

서 사용할 수 있는 함수 및 변수(파라미터)에 접근하는 데 사용하는 방식이다.


객체 속성 동작명령 종료

점 표기법인자/변수

그림 3-3 ㅣ 점 표기법

스크립트는 큐브에 둘 것이므로 이 스크립트에서 회전시키는 객체는 스크립트가 속하는 객체

라고 가정할 수 있다. 따라서 이 때는 코드 줄 앞에 객체 자체를 포함시키지 않아도 된다.

이 코드는 Update 함수 내에 있으므로 이 객체는 매 프레임마다 5도씩 회전한다.

3. 저장 아이콘을 누르거나 File 메뉴 Save를 통해 스크립트를 저장한다.

스크립트는 유니티 애플리케이션으로 포커스를 옮기면 인스펙터에서 바로 업데이트된다.


4. 스크립트 에디터를 최소화(닫지는 않는다)하고 프로젝트 뷰에서 큐브로 스크립트를 드

래그한다. 이 작업은 계층 뷰에서도 할 수 있고 장면 창에서도 할 수 있다.

5. 계층 뷰에서 큐브를 선택하고 인스펙터에서 SimpleRotate 스크립트를 찾는다.

그림 3-4와 같이 스크립트는 (항상 가장 하단에 위치한) 재료(material) 바로 위에서 찾을 수

있다.

그림 3-4 ㅣ 스크립트 찾기

6. 에디터 상단에 있는 플레이 버튼을 클릭한다.

그럼 그림 3-5와 같이 에디터가 어두워지고 큐브가 장면과 게임 창 모두에서 회전할 것이다.


그림 3-5 ㅣ 어두워진 게임 모드

7. 다시 스크립트 에디터를 최대화하고 다음과 같이 5를 1로 바꾼다.


8. 변경 사항을 저장하고 에디터를 다시 클릭해 포커스를 갖게 한다.

이번에는 큐브가 천천히 회전할 것이다.

9. 플레이 버튼을 다시 클릭해 플레이 모드를 멈춘다.

이 회전은 매 프레임마다 발생하도록 설정했으므로 사용자들은 자신이 갖고 있는 장비의 프레

임레이트에 따라 각기 다른 속력으로 회전하는 결과를 보게 된다.

유니티 스크립트에서 다음으로 살펴볼 주요 개념으로 Time.deltaTime이 있다. Time.deltaTime

은 프레임이 아니라 초 기반으로 애니메이션을 할 수 있게 해준다. 이를 활용하면 다양한 장비

와 서로 다른 프레임레이트에 구애받지 않고 모든 장비에서 일정한 애니메이션을 보여줄 수 있

다. Time.deltaTime는 지난번 Update 함수를 호출한 후 지금까지 흐른 시간의 양을 반환하는

변수다.


10. 코드를 다음과 같이 수정한다.

transform.Rotate(0,5 * Time.deltaTime,0);

이렇게 하면 매 프레임마다 5도씩 회전하는 대신 매초 5도씩 회전하게 된다.

11. 플레이 버튼을 클릭한다.

이번에는 속도가 크게 달라진 것이 느껴질 것이다.

12. 각도를 5에서 50 정도로 수정하고 다시 저장하면 결과가 한결 자연스러워진다.

팁

스크립트를 수정한 후 결과를 확인하려면 스크립트를 꼭 저장해야 한다.

이번에는 Translate(이동)를 추가하고 구문이 올바르지 않을 경우 어떤 일이 일어나는지 확인

해 보자. 다음 코드에서 translate에 사용된 t가 소문자라는 것에 주의하자.

1. 다음 코드를 Update 함수에서 Rotate 줄 바로 다음에 추가한다.

transform.translate(2 * Time.deltaTime,0,0);

이 코드를 추가하면 게임 창 아래 상태 줄에 바로 에러 메시지가 나타난다(그림 3-6). 이 에러

메시지를 클릭하면 콘솔에서 에러 메시지를 확인할 수 있다(그림 3-7).

그림 3-6 ㅣ 상태 줄에 표시된 에러 메시지


그림 3-7 ㅣ 콘솔과 에러 메시지

이 에러의 경우 쉽게 인식할 수 있을 뿐 아니라 콘솔에 해결책도 함께 제시됐다.

2. 소문자 t를 대문자 T로 바꾸고 다시 저장한다.

이제 그림 3-8과 같이 에러 메시지가 사라질 것이다.

그림 3-8 ㅣ 에러를 수정한 모습

3. 콘솔을 닫는다.

4. 수정 사항을 저장하고 플레이 버튼을 클릭한다.


이제 스크립트에서는 큐브가 매초 2미터씩 움직이게 하고 있다. 하지만 큐브는 여러분이 기대

한 대로 움직일 수도 있고 그렇지 않을 수도 있다. 이 스크립트에서는 먼저 회전을 계산한 후 이어

서 이동/위치 변환을 큐브의 자체 축을 기준으로 계산한다.

만일 X 방향으로 곧바로 이동하는 동안 큐브가 회전하게 하려면 GameObject의 도움을 받아

이런 동작을 구현할 수 있다. 유니티에서는 기능의 순서를 정하고 장면의 에셋을 조직화하는 등

의 여러 목적으로 GameObject를 사용한다. 종종 이런 GameObject를 줄여서 GO라고 부르기

도 한다.

GameObject를 설정하기 전에 먼저 두 작업을 각기 다른 스크립트로 분리하자.

1. 플레이 버튼을 클릭해 플레이를 중단한다.

2. 스크립트 에디터의 편집 메뉴에서 Save As를 선택하고 복사본의 이름을 SimpleMove.js

로 지정한다.

이번에는 SimpleRotate의 이름이 바뀌었으므로 스크립트 에디터에서 원본을 다시 열어야 한

다. 이제 두 스크립트를 모두 프로젝트 뷰에서 볼 수 있고 바로 열 수도 있다.

3. SimpleRotate.js 스크립트를 연다.

그럼 그림 3-9처럼 각 스크립트별로 탭이 하나씩 있는 것을 확인할 수 있다.

그림 3-9 ㅣ 에디터에서 두 스크립트를 연 상태

1. SimpleRotate.js 스크립트에서 다음과 같이 변환 작업이 시작되는 코드 줄 앞에 두 개의


역슬래시를 추가한다.

//transform.Translate(2 * Time.deltaTime,0,0);

이렇게 하면 코드가 녹색으로 바뀌고 주석 처리되며, 코드를 무시한다는 사실을 알 수 있게

다른 폰트로 바뀌는 것을 볼 수 있다.

팁

여기서는 주석 메커니즘을 사용해 코드 실험을 하는 동안 코드가 실행되는 것을 막았다. 이런

주석은 실제 코드가 하는 작업을 알려주는 용도로도 활용할 수 있다. 이런 주석을 잘 활용하면

코드가 하는 일을 기억하기 쉽다. 또 주석은 다른 사람들이 코드를 더 쉽게 이해할 수 있게끔

해준다.

2. SimpleMove.js 스크립트에도 같은 과정을 반복해 다음과 같이 회전 작업을 주석 처리한다.

//transform.Rotate(0,50 * Time.deltaTime,0);

3. 이때 두 스크립트 모두 수정사항을 꼭 저장해야 한다.

4. 스크립트 에디터를 최소화한다.

5. 일반 에디터로 돌아와 GameObject메뉴에서 CreateEmpty를 선택한다.

6. 그림 3-10과 같이 새 GameObject의 이름을 Cube Parent로 지정한다.

그림 3-10 ㅣ 새로 생성한 GameObject인 Cube Parent

7. 계층 뷰에서 Cube를 Cube Parent로 드래그앤드롭한다.

8. 계층 뷰에서 프로젝트 뷰에서 Cube Parent 객체로 SimpleMove.js를 드래그앤드롭한다.

이제 Cube Parent를 선택하면 SimpleMove 스크립트가 인스펙터에 보일 것이다(그림 3-11 참고).


그림 3-11 ㅣ 인스펙터에 나타난 Cube Parent와 Simple Move 스크립트


그럼 큐브가 자체 X 축을 향해 움직이면서 천천히 회전할 것이다. 이때 실제 동작을 좀 더 자세

히 확인하려면 장면 뷰를 조금 줌아웃해야 한다.

변수

지금까지는 대부분의 수정을 스크립트에서 했다. 하지만 이런 스크립트를 테스트하려면 먼저 저

장해야 한다. 앞서 장면에서 여러 내용을 이미 수정했으므로 이쯤에서 스크립트를 저장해 두자.

1. Ctrl+S를 사용해 스크립트를 저장하거나 파일 메뉴에서 저장을 선택한다.

지금쯤 어떤 독자는 애니메이션을 게임에서 하드코딩하는 데 조금 거부감을 느끼고 있을 것이

다. 하지만 걱정하지 않아도 된다. 실제로 게임 객체에 애니메이션을 적용할 때는 이와는 다른 방

식을 사용할 것이기 때문이다. 앞서 변형을 스크립트로 지정해본 것은 단순히 스크립트 적용 효

과를 쉽게 확인하기 위한 의도일 뿐이다.

이번에는 변수를 살펴보자. 변수는 상태, 값, 텍스트, 그 외 많은 것들을 저장할 수 있게 해준

다. 변수는 정보를 저장하는 메커니즘이다. 유니티에서 이런 변수는 인스펙터에도 노출되므로

변수를 수정하기 위해 스크립트를 다시 열지 않아도 된다. 아울러 스크립트를 인스펙터에 노출

하면 스크립트를 범용적으로 활용해 각기 다른 객체의 설정에 동일한 스크립트를 사용할 수 있

다는 장점도 있다.

지금까지는 큐브의 회전 속력을 바꾸려면 회전 작업 내에서 사용된 숫자 값을 바꿔야 했다. 이

번에는 이 부분을 변수로 바꿔보자.


팁

변수에는 의미 있는 이름을 주되, 변수명 자체는 짧게 유지한다. 변수에 대한 전체 설명은 주

석을 통해 추가할 수 있다.

규칙

변수명은 숫자, 특정 특수 문자로 시작할 수 없고 공백을 포함할 수 없다. 아울러 변수명으로

사용할 수 없는 예약어도 몇 가지 있다. 필수사항은 아니지만 각 변수명은 소문자로 시작하는

게 좋다. 변수명에 대문자 단어가 사용된 곳마다 인스펙터에서는 공백이 나타난다.

2. SimpleRotate 스크립트의 코드를 다음과 같이 수정한다.

var myDegrees = 50;


transform.Rotate(0,myDegrees * Time.deltaTime,0);

}

3. 스크립트를 저장한다.

4. Cube Parent를 클릭해 자식인 Cube에 접근할 수 있도록 그룹을 연다.

5. Cube를 선택하고 인스펙터를 확인해 새 변수를 인스펙터에서 접근할 수 있는지 확인한

다(그림 3-12 참고).

인스펙터에서는 변수명에 대문자가 사용된 곳마다 공백을 사용하는 것을 볼 수 있다. 이런 표

기는 인스펙터에서 변수를 읽기 쉽게 해준다. 아울러 첫 번째 문자 또한 대문자로 표시된다.

6. 플레이 버튼을 클릭해 달라진 내용이 없음을 확인한다.

7. 장면 창에서 큐브를 더 오래 볼 수 있게 SimpleMove 스크립트에서 2를 0.5로 바꿔 큐브

의 애니메이션이 느리게 진행되게 한다.


그림 3-12 ㅣ 새로 노출된 My Degrees 변수

8. 스크립트를 저장하고, 아직 선택돼 있지 않다면 Cube를 선택한다.


10. 스크립트 에디터가 아니라 인스펙터에서 My Degrees 파라미터의 값을 50에서 200으로

바꾼다.

그럼 큐브가 더 빨리 회전하는 것을 확인할 수 있다.

11. 플레이 버튼을 한 번 더 클릭해 게임 플레이를 멈춘다.

그럼 값이 다시 50으로 재설정되는 것을 볼 수 있다.

규칙

유니티에서는 인스펙터에서 런타임 시에 수정한 내용은 모두 사라진다. 이 기능을 활용하면

아무 기능도 손대지 않은 채 값을 실험해 즉각적인 피드백을 받을 수 있다는 장점이 있지만,

이 말은 영구적인 수정을 하려면 항상 편집 모드로 돌아와야 한다는 뜻도 된다.


12. SimpleRotate 스크립트의 스크립트 에디터에서 변수의 값을 100으로 설정하고 스크립트

를 저장한다.

이때 인스펙터에서 원본 값 50은 그대로 남아 있는 것을 확인한다.


그럼 회전 작업에서 인스펙터의 느린 값을 사용하는 것을 볼 수 있다. 인스펙터의 값은 항상 스

크립트 자체에서 초기화한 값보다 우선시된다.

규칙

변수가 인스펙터로 한번 노출되고 나면 인스펙터의 값은 해당 변수가 선언된 및/또는 초기화

된 위치에서의 원본값을 항상 대체한다.

14. 플레이를 멈춘다.

15. 이제 더 이상 플레이 모드가 아니므로 인스펙터에서 파라미터 값을 200으로 수정한다.


이제 의도한 대로 회전이 빠르게 일어날 것이다.

17. 장면과 프로젝트를 저장한다.

주의

객체의 회전값을 지나치게 빠르게 설정하면 빠른 프레임레이트를 제공할 수 없는 기기에서는

회전이 느려지거나 거꾸로 진행되는 것처럼 보일 수 있다.

변수에 대해 알아야 할 내용이 몇 가지 더 남아 있다. 앞서 언급한 대로 변수의 타입은 몇 가지

가 있다. 회전 스크립트에서 myDegrees를 50으로 설정했을 때 이 변수는 자동으로 int(정수) 타

입으로 해석됐다. 만일 앞에서 50.0을 사용했다면 이 변수는 �oat(부동 소수)로 해석됐을 것이

다. 변수를 선언할 때는 대부분 타입만 선언하고 나중에 값을 대입하거나 초기화한다. 이번에는

SimpleMove 스크립트에 새로운 변수를 몇 개 더 추가해 보자.

1. SimpleMove 스크립트 상단에 다음 코드를 추가한다.


var mySpeed : float;

var someString : String = "This is a test";

var someSetting : boolean = true;

var someObject : GameObject;

2. 스크립트를 저장하고 Cube Parent를 선택해 새로 추가한 내용을 인스펙터에서 볼 수 있

는지 확인한다(그림 3-13 참고).

그림 3-13 ㅣ 새로 추가한 변수들

이들 변수를 좀 더 자세히 들여다 보자.

■ var mySpeed : �oat;은 �oat 타입의 변수를 선언하지만 값을 초기화하지는 않는다.

■ var someString : String = "�is is a test";는 String 타입의 변수를 선언하고 값을 초기

화한다. String은 항상 따옴표로 감싸며 UniSciTe 스크립트 에디터에서 보라색으로 표

시된다.

주의

워드프로세서에서 따옴표를 복사해 붙여넣으면 에디터에서 원하는 문자와는 다른 문자가 입

력될 수 있다. 이때 에러가 발생한다면 에디터에서 따옴표를 직접 입력하면 된다.

■ var someSetting : boolean = true;은 불리언 타입(true 또는 false)의 변수를 선언하고 초

기 값을 true로 지정한다. 인스펙터 불리언 변수는 체크박스로 표시된다.


팁

변수 값이 특정 타입에 명백히 속하는 한, 타입 선언은 어디까지나 선택 사항이다. 하지만 타

입을 선언하면 엔진에서 어떤 타입을 지정해야 할지 자동으로 판단하는 일을 하지 않아도 된

다. 아울러 iOS나 안드로이드 같은 모바일 플랫폼에서는 항상 타입을 선언해야 한다. 이 책에

서는 두 방식을 모두 사용해 독자들이 두 방식에 모두 익숙해질 수 있게 했다.

모든 변수가 var로 시작하는 것에 주의하자. 유니티에서 var는 public 변수로 가정한다. 다시

말해 이 변수는 항상 인스펙터에 노출된다.

3. someSetting을 var 대신 private var로 바꿔보자.

4. 그런 다음 스크립트를 저장한다.

5. 포커스를 전환하기 위해 에디터를 선택하고 인스펙터를 업데이트한다.

이제 인스펙터에 someSetting 파라미터가 더 이상 보이지 않을 것이다.

■ var someObject : GameObject; 대다수 프로그래밍 언어와 마찬가지로 유니티에서도 최

상위 레벨에 속하는 GameObject부터 변형이나 기타 속성 또는 객체 타입(Camera 또는

Light)에 이르기까지 구체적인 타입을 지정할 수 있다.

스크립트에서 다른 객체의 변수 및 함수에 접근하려면 해당 변수나 함수가 변수의 값으로 선

언돼 있어야 한다. 하지만 객체명은 단지 여러 속성 중 하나에 지나지 않으므로 객체는 좀 더 추

상적인 방식으로 접근해야 한다.

6. 장면에 있는 빛이나 카메라를 계층 뷰에서 인스펙터 내의 Some Object 파라미터로 드래

그해 보자.

이렇게 지정하고 나면 스크립트에서는 해당 객체의 파라미터뿐 아니라 해당 객체의 자식과 컴

포넌트의 파라미터에도 접근할 수 있다.

이 방식을 사용할 때는 유니티의 자체 내장 방식을 통해 접근이 허용되므로 부모나 자식을 별

도로 처리하지 않아도 된다.



게임에서 객체 집기

잠시 시간을 내서 1인칭 슈팅 게임과 전통적인 포인트 클릭 어드벤처 게임의 차이점을 생각해 보

자. 1인칭 슈팅 게임의 경우 인터랙션은 주로 근거리에서 일어난다. 예를 들어 여러분이 들고 있는

무기가 엘리베이터 버튼에 부딪치거나 문과 부딪치는 식이다. 또 적의 사정 범위 내에 여러분이

들어오면 적이 여러분을 향해 총을 발사하곤 한다. 또는 여러분이 총알을 사용해 나무상자들을

맞추면 물리 이론을 통해 나무상자 파편이 튀곤 한다.

그에 반해 전통적인 포인트 클릭 어드벤처 게임에서는 보통 충돌이나 물리 이론, 레이캐스팅

(ray casting) 등이 아니라 커서가 인터랙션의 수단이 된다.

1. 스크립트 도움말을 연다 (Help Scripting Reference).

2. ‘On Mouse Down’을 검색한다.

그럼 57개의 일치하는 검색어를 볼 수 있다. 이들 검색어를 살펴보면 두 번째 검색어가 우리가

찾는 내용에 가장 부합함을 알 수 있다.

3. MonoBehavior.OnMouseDown을 클릭한다.

이번에는 이 코드를 포함할 새로운 자바스크립트를 생성하자. 이 코드는 기존 스크립트에 추

가할 수도 있지만 다른 곳에 따로 빼놓을 수도 있다.

4. MyScripts 폴더를 선택하고 마우스 오른쪽 버튼을 클릭한 후 새 자바스크립트를 생성

한다.

5. 새 자바스크립트의 이름을 MousePick으로 지정하고 스크립트 에디터에서 연다.

6. 이 스크립트에서는 Update 함수가 필요 없으므로 스크립트 도움말에서 찾은 함수명과

마찬가지로 이름을 OnMouseDown으로 지정한다.

도움말에 있는 예제 코드는 새 장면을 로드하는 코드를 보여주고 있지만 현재 여러분이 알

고자 하는 내용은 플레이어가 집은 아이템을 추적할 수 있는지 여부다. Update 함수와 달리

OnMouseDown 함수는 이벤트가 일어날 때만 호출된다.

원하는 동작이 일어나는지 쉽게 확인하려면 프로그램에서 콘솔에 메시지를 출력해 보면 된다.

스크립트 도움말에서 ‘print to console’을 사용해 검색을 해 보자. 검색 결과를 간단히 살펴보면

Debug.Log를 사용해 메시지를 콘솔에 출력할 수 있음을 알 수 있다. 이를 선택해 어떤 구문을


사용해야 하는지 확인해 보자. 이 구문은 사실 매우 단순하다. 더불어 Debug.Log와 동일한 기

능을 하는 MonoBehaviour.print도 나중에 사용할 테니 함께 곁들여 살펴보자.

7. 다음 코드를 OnMouseDown 함수 내에 추가한다.

Debug.Log("�is object was picked");


도움말에 이 함수는 ‘GUIElement나 Collider상에서 사용자가 마우스를 누를 때 호출된다’고

나와 있는 점에 주의하자. 아직 장면에 GUI(그래픽 사용자 인터페이스)가 없으므로 지금은 콜라

이더(Collider)를 사용해야 한다.


인스펙터에서는 큐브가 항상 콜라이더를 갖고 있는 것을 확인할 수 있다.

팁

유니티에서 생성한 원시 객체들은 생성 시에 콜라이더 컴포넌트를 부여받는다.

큐브를 쉽게 선택하려면 Cube Parent에서 SimpleMove 스크립트를 비활성화해 큐브가 게임

뷰를 벗어나지 못하게 하는 게 좋다.

10. Cube Parent를 선택한다.

11. SimpleMove 스크립트를 선택 해제해 비활성화한다(그림 3-14 참고).

12. 이번에는 계층 뷰에서 MousePick 스크립트를 큐브로 드래그앤드롭한다.

13. 플레이 버튼을 누르고 큐브를 집는다.


그림 3-14 ㅣ 비활성화된 SimpleMove 스크립트

그럼 상태 줄에 다음과 같은 메시지가 나타날 것이다(그림 3-15 참고).

그림 3-15 ㅣ 상태 줄에 표시된 Debug.Log 메시지

팁

큐브를 집을 때 아무 일도 일어나지 않는다면 콜라이더가 없는 Cube Parent가 아니라 Cube

에 MousePick 스크립트가 적용됐는지 다시 한 번 확인한다.

14. 상태 줄을 클릭해 콘솔을 연다.

매번 큐브를 클릭할 때마다 콘솔에 메시지가 출력되는 것을 확인한다(그림 3-16).


그림 3-16 ㅣ 객체를 여러 번 집은 후 콘솔의 상태

객체를 집을 때 꼭 객체가 보이거나 렌더링될 필요는 없다. 이 원리를 잘 활용하면 여러 가지 창

의적인 방식으로 게임 환경을 만들 수 있다.

15. 큐브를 선택하고 게임 창에서 큐브가 어디에 있는지 확인한다.

16. 인스펙터에서 메시 렌더러를 선택 해제해 비활성화한다.

그럼 큐브가 게임 창에서 사라질 것이다. 하지만 장면 창에서는 큐브의 녹색 경계 상자를 계속

해서 볼 수 있다(그림 3-17).

그림 3-17 ㅣ 큐브의 비활성화된 메시 렌더러


17. 게임 창에서 큐브가 원래 있는 위치를 집는다.

그럼 여전히 콘솔을 통해 집기 동작이 인식된 것을 볼 수 있다(그림 3-18 참고).

그림 3-18 ㅣ 큐브가 보이지 않지만(렌더링되지 않지만) 여전히 집을 수 있다.

18. 메시 렌더러를 다시 켠다.

19. 이번에는 인스펙터 상단에 있는 체크박스를 선택 해제해 전체 객체를 비활성화한다(그림

3-19 참고).

그림 3-19 ㅣ 인스펙터에서 비활성화한 큐브


이렇게 하면 장면 창에서 콜라이더가 사라지고 객체가 계층 뷰에서 회색으로 표시되는 것을

볼 수 있다(그림 3-20 참고).

그림 3-20 ㅣ 계층 뷰에서 회색으로 표시된 비활성 큐브

20. 게임 창에서 큐브가 원래 있던 자리에서 큐브를 잡으려서 시도한다.

그럼 아무 일도 일어나지 않을 것이다.

21. 플레이를 중단하고 콘솔을 닫는다.


마우스로 집은 횟수 세기

포인트 클릭 어드벤처 게임에서 어떤 객체들은 여러 번 집어야 다음 상태 또는 동작으로 넘어갈

수 있다. 이번에는 객체를 집은 횟수를 추적할 수 있는 변수를 추가해볼 것이다.

1. 스크립트 에디터로 MousePick 스크립트를 연다.

2. MousePick 스크립트 상단에 다음 코드를 추가한다.

private var pickNum = 0;

다음으로 이 함수가 호출될 때마다 매번 pickNum 값을 1씩 증가시키기 위해 OnMouseDown

함수 내에 새 코드를 추가해야 한다.

3. 다음 코드를 Debug.Log 줄 다음에 추가한다.

pickNum = pickNum + 1; // 객체를 집은 횟수를 1씩 증가시킨다.


이때 코드에서 하는 일을 나중에도 알 수 있도록 주석을 활용하는 것에 주의하자. // 다음에 나

오는 내용은 모두 무시된다.

물론 Debug.Log를 사용해 집은 횟수를 출력할 수도 있지만 이번에는 아이템을 집은 횟수를

출력하도록 print구문을 사용해 보자. 이때 print는 앞 글자가 대문자가 아닌 것에 주의하자. 또

메시지에 변수를 추가하려면 문자열(따옴표 안에 있는 텍스트)을 +를 사용해 분리해야 한다는

점도 기억하자.

4. Debug.Log 줄을 다음과 같이 수정한다.

print("This object was picked " + pickNum + " times.");


6. 플레이 버튼을 클릭하고 큐브를 계속 집어 본다.

그럼 메시지가 마지막 클릭 횟수에 맞게 업데이트되는 것을 볼 수 있다(그림 3-21 참고).

그림 3-21 ㅣ 마우스로 집은 횟수를 나타내는 상태 줄

이따금씩 변수 값을 증가시키는 축약 구문을 보는 일도 있을 것이다. pickNum = pickNum + 1;

는 pickNum += 1;로도 줄여 쓸 수 있다.

7. 기존 코드를 다음과 같이 축약 버전을 사용해 대체해 보자.

pickNum += 1; // 객체를 집을 때마다 횟수를 1씩 증가시킨다.


9. 플레이 버튼을 클릭하고 테스트한다.

실행 결과는 동일하다.

조건과 상태

사용자가 몰입하게끔 하는 인터랙션의 핵심은 다양한 시나리오가 나올 수 있는 조건을 적절히

지정하는 데 있다. 전통적인 슈팅 게임에서도 객체가 파괴 상태로 전환하기 전까지 객체는 몇 차


례의 충돌을 거쳐야 한다. 프로그램에서는 객체가 충돌할 때마다 다음 동작을 일으키기 전에 특

정 조건이 충족됐는지 확인한다. 이런 조건 하나하나는 모두 상태로 생각할 수 있다.

전통적인 포인트 클릭 게임에서는 상태가 좀 더 중요하다. 보통 사용자와 상호작용할 수 있는

대상이라면 모두 자신의 상태를 알고 있어야 한다. 문을 클릭할 경우 문은 사용자에게 반응하기

전에 자신이 잠겨 있는지, 안 잠겨 있는지, 열려 있는지, 닫혀 있는지 알고 있어야 한다.

앞의 큐브를 계속 활용해 이번에는 회전을 켜고 끌 수 있는 두 상태로 이뤄진 간단한 상태 시스

템을 설정해 보자. 여기서는 회전을 제어해야 하므로 회전 스크립트에 OnMouseDown 함수를

추가할 것이다.

아울러 인스펙터에 노출되지 않게끔 private var를 사용한다. 이론적으로 이 변수는 두 상태

(온/오프 또는 true/false)만 갖고 있으므로 이 경우 메모리를 절약하기 위해 불리언을 사용할 수

도 있다. 하지만 대부분의 액션 객체가 둘 이상의 상태를 갖는 만큼 상태는 불리언보다는 숫자 형

태로 생각하는 버릇을 들이는 게 좋다 1 . 따라서 여기서는 정수를 사용한다.

1. SimpleRotate 스크립트를 연다.

2. 다음 변수와 주석을 스크립트 상단에 추가한다.

private var rotationState = 1; // 이 변수는 회전 상태를 추적한다

- 회전 상태의 온/오프. 값이 1일 경우 온, 0일 경우 오프.

팁

이런 변수와 함수가 스크립트 내에 등장하는 위치는 크게 중요하지 않다. 하지만 보통 정규 변

수는 (인스펙터에 나타나는 만큼) 상단에 배치해 조직화하고, 이어서 private var 변수를 선

언한다. 이 책에서는 각 설명마다 전체 스크립트를 모두 보여주지는 않는 대신 보통 새 코드를

기존 코드 상단 또는 하단에 작성하라고 설명하고 있다. 각 장의 최종 스크립트는 Apress 웹

사이트에서 책 페이지를 통해 내려받을 수 있다.

3. 다음 함수를 Update 함수 아래에 추가한다.

function OnMouseDown () {

1 　 (옮긴이) 상태를 불리언으로 저장하면 나중에 상태가 늘어날 경우 추가 상태 지정을 위해 별도의 불리언 플래그를 추가하거

나 아예 기존 코드를 수정해야 한다. 따라서 처음 기획 시점에 상태가 두 개뿐이라고 생각했더라도 향후 수정 가능성을 고려

해 확장성이 있는 숫자 상수를 사용해 상태를 저장하는 게 좋다.


if (rotationState == 1) {

rotationState = 0;

}

else if (rotationState == 0) {

rotationState = 1;

}

print("State = " + rotationState);

}

4. 수정한 스크립트를 SimpleRotateToggle.js로 저장한다.

팁

Save As를 사용해 스크립트를 컴퓨터에 저장할 때는 스크립트 에디터에서 형식을 알 수 있고

엔진에서 읽을 수 있도록 js 확장자를 꼭 붙여줘야 한다.

기존 SimpleRotate 스크립트 컴포넌트를 제거하고 새 버전을 추가하는 대신 인스펙터에서 스

크립트를 재지정할 수도 있다. 이 방식을 사용하면 인스펙터에서 지정한 변수 값을 그대로 유지

할 수 있다는 장점이 있다.

1. 계층 뷰에서 Cube Parent를 열고 Cube를 선택한다.

2. 인스펙터에서 로드된 스크립트 옆에 있는 찾기 아이콘을 클릭한다(그림 3-22 참고).


그림 3-22 ㅣ 기존 스크립트 컴포넌트의 교체

그럼 에셋 브라우저에서 프로젝트에 사용할 수 있는 스크립트 목록을 보여줄 것이다(그림

3-23 참고).

그림 3-23 ㅣ 사용할 수 있는 스크립트 목록

3. SimpleRotateToggle 스크립트를 선택한다.

이제 SimpleRotate 스크립트가 바뀌었지만 MyDegrees 설정은 그대로 유지된다.


조건문의 구조

if (rotationState == 1)

조건문의 괄호 안에는 중괄호 안에 있는 내용을 실행하기 위해 충족해야 하는 조건을 담고 있는

표현식이 들어 있다. 이때 주의해서 볼 부분은 두 개의 등호 기호다. 이 기호는 동등 연산자라 부

르며 변수 rotationState가 현재 1 값을 갖고 있는지를 판단한다. 이 조건에 해당할 경우 중괄호

내에서 rotationState 값을 0으로 업데이트하기 위해 rotationState = 0을 사용한다(단일 등호 기

호는 대입 연산자다). 이 조건에 해당하지 않으면 else if (rotationState == 0) 절로 이동하고 현재

rotationState 값이 0이므로 rotationState = 1을 통해 이 값을 1로 설정한다. 이와 같이 상태를

판단하고 업데이트한 후에는 print("State = " + rotationState)를 통해 결과를 콘솔에도 출력해

확인하는 게 좋다.

MousePick 스크립트의 메시지 결과는 상태 메시지 다음에 출력되므로 현 상태에서 플레이

버튼을 클릭하고 기능을 바로 테스트하려면 콘솔을 열어 결과를 확인해야 한다. 콘솔을 여는 대

신 MousePick 스크립트에서 print 줄을 비활성화할 수도 있다.

1. MousePick 스크립트를 열고 다음과 같이 두 개의 역슬래시를 print 줄 앞에 붙인다.

// print("State = " + rotationState);


3. 플레이 버튼을 클릭하고 기능을 테스트한다.

그럼 큐브를 집을 때마다 상태가 1과 0 사이에서 바뀌는 것을 확인할 수 있다. 이제 상태 추적

메커니즘이 제대로 동작하므로 회전을 켜고 꺼 보자.

4. SimpleRotateToggle 스크립트를 연다.

5. Update 함수에서 코드를 다음과 같이 바꾼다.


if (rotationState == 1) {

transform.Rotate(0, myDegrees * Time.deltaTime, 0);

}

}



7. 플레이 버튼을 클릭하고 기능을 테스트한다.

그럼 큐브의 상태에 따라 큐브가 회전을 시작하거나 멈출 것이다.


계산 순서

스크립트에서 해석 순서는 보통 수학식의 순서와 일치한다. 곱셈과 나눗셈은 먼저 계산하고, 이

후 덧셈과 뺄셈이 계산되며, 끝으로 비교 로직(and/or)이 계산된다. 괄호 안의 내용은 가장 안쪽

에 있는 것부터 바깥쪽 순서대로 계산이 수행된다.

정리

이 장에서는 유니티의 자바스크립트 구현체를 사용해 3D 객체를 제어하는 법을 살짝 맛 봤다.

이 장에서는 스크립트에 명령을 수행하는 함수가 있다는 사실과, 스크립트가 변수를 사용해 값

을 저장하고 바꾼다는 사실, 또 주석을 사용해 명령을 비활성화함은 물론 스크립트가 하는 일에

대한 설명을 달 수 있다는 사실을 배웠다.

또 런타임 시점에 매 프레임마다 호출되는 시스템 함수인 Update 함수에 대해 배웠고 Time.

deltaTime를 활용하면 프레임 기반이 아니라 초 기반으로 객체를 변형(이동, 회전, 스케일 조정)

할 수 있다는 점을 배웠다. 또 이동 및 회전의 적용 순서를 부모 객체를 통해 제어할 수 있다는 사

실도 배웠다.

아울러 스크립트 구문에서 대부분의 경우 대소문자가 매우 중요하다는 점을 익혔고, 가끔씩

콘솔에 나오는 에러 메시지가 문제를 일으킨 명령과 관련한 올바른 대소문자를 알려주는 데 도

움을 준다는 사실도 배웠다. 더불어 변수의 상태에 대한 정보, 특정 함수에서 코드를 읽는지 여

부, 그 외 기타 정보를 콘솔에 출력할 수 있다는 것도 배웠다.

또 장면에서 객체를 집으려면 집기 동작을 등록할 수 있도록 해당 객체가 콜라이더를 갖고 있

어야 하지만 이 객체를 꼭 메시 렌더러로 그리지는 않아도 된다는 사실도 새롭게 알았다. 하지만

인스펙터에서 객체를 비활성화하면 이 객체는 더 이상 장면에 남아 있지 않게 된다.


더불어 이 장에서는 변수의 타입이 정수, 문자열, 불리언, 부동 소수 등 다양하다는 사실도 배

웠다. 덧셈 연산자를 사용해 정수 타입 변수의 값을 늘리면 객체를 몇 번 집었는지 셀 수 있다.

이는 게임 개발 과정에서 두 가지 핵심 개념인 상태와 조건문으로 바로 연결된다. 이 장에서는 표

현식의 해석 결과나 나타내는 상태에 따라 각기 다른 명령을 실행할 수 있다는 사실을 새롭게 익

혔다.

이 장에서 다룬 함수:

■ Update (시스템 타입 함수)

■ OnMouseDown (이벤트 타입 함수)

■ print (다른 함수 내에서 다른 명령문과 함께 사용할 수 있는 범용 함수)

메서드 (객체 레벨 함수):

■ transform.Rotate(x,y,z)

■ transform.Translate(x,y,z)

Documents

시작하세요! Unity 3D 게임 프로그래밍 : 유니티를 활용한 3D 게임 개발