1.1 게임 팀 구성

보통 게임 스튜디오는 크게 엔지니어, 아티스트, 기획자, 프로듀서, 기타 관리 지원(마케팅, 법률, 기술지원, 인사 관리 등) 다섯 부서로 구성된다.

1.1.1 엔지니어

엔지니어는 게임을 만드는 데 쓰이는 소프트웨어와 제작 도구를 디자인하고 구현한다.

• 런타임 프로그래머: 엔진과 게임을 개발
• 툴 프로그래머: 다른 개발 팀들이 효율적으로 일하는 데 필요한 오프라인 도구들을 만듦.

1.1.2 아티스트

• 콘셉트 아티스트
• 3D 모델러
• 텍스처 아티스트
• 광원 아티스트
• 애니메이터
• 모션 캡처 배우
• 사운드 디자이너
• 성우
• 작곡가

1.1.3 기획자

기획자(게임 디자이너)는 사용자가 게임에서 얻을 수 있는 경험, 즉 게임플레이를 설계한다.

• 고참 기획자: 게임의 줄거리나 게임의 진행, 궁극적인 게임의 목적 등을 설계. 관리자 역할.
• 일반 기획자: 게임 월드의 지형이나 레벨을 다루며, 배경 배치, 적 출현 위치와 시점 결정, 아이템 배치, 퍼즐 설계 등.
  이외에 고도로 기술적인 작업을 하며 엔지니어와 긴밀하게 협업하거나 스크립트 언어등을 직접 작성하는 기획자도 있다.

1.1.4 프로듀서

스튜디오마다 역할이 다르다.
어떤 회사에서는 일정 관리와 인력 관리를, 어떤 경우에는 상급 기획 업무를 맡는다.
다른 부서와의 매개자 역할을 맡기도 한다.
작은 스튜디오의 경우는 프로듀서가 없는 경우도 있다.

1.1.5 지원 부서

게임 생산에 직접적으로 참여하는 사람들을 지원하는 부서(스태프)
경영 관리, 마케팅, 관리, IT 기술 지원(개발 하드웨어 소프트웨어를 구매, 관리)

1.1.6 퍼블리셔

게임을 판매, 제조, 배포

1.2 게임이란?

이 책에서는 한정된 사용자들로 이뤄진 2차원 또는 3차원 가상 세계를 지칭하는 게임의 개념에만 집중한다.
이 책의 주된 관심사는 FPS, 3인칭 액션, 레이싱, 파이팅 게임 등을 만드는 게임 엔진이다.

1.2.1 덜 엄격한 실시간 시뮬레이션으로서의 게임

대부분 2차원 또는 3차원 게임은 컴퓨터 과학적인 용어로 '덜 엄격한 실시간 상호적 행위자 기반 컴퓨터 시뮬레이션(soft-real-time interactive agent-based computer simulations'이라고 부를 수 있다.
비디오 게임은 컴퓨터가 다룰 수 있게 실세상을 수학적으로 모델화한다.
모델화 할때는 근사화와 단순화가 필요하다. 이를 잘 활용하면 실세상의 세세함을 잃지 않으면서도 큰 재미를 주는 게임을 만들 수 있다.

모든 비디오 겜은 시간적인 시뮬레이션이다. 가상 세계는 고정된 것이 아니라 시간이 지나거나 이야기가 진행됨에 따라 동적으로 변한다. 또한 예측 불가능한 사용자의 동작에 대비되어 있어야 한다. (Interactive 한 시간적 시뮬레이션)

모든 실시간 기반 시스템은 시간 제약(deadline)이라는 핵심 개념이 들어있다.

최소 초당 24번 업데이트를 해야 한다.
대부분 초당 30 또는 60번 화면을 그리는데, NTSC 모니터의 재생 빈도의 배수이기 때문.
물리 엔진이 초당 120번 업데이트 해야한다, 오디오 시스템이 초당 60번 버퍼를 채워야 한다 등

덜 엄격한 실시간 시스템이란 뜻은 시간 제약을 지키지 못해도 치명적인 결과가 발생하지는 않는다는 뜻. (반대의 예는 자율주행 자동차나 미사일 추적 요격 시스템등이 있을 것이다)

수학적 모델은 분석적(analytic) 모델과 수치적(numerical) 모델로 나뉜다.

• 분석적 모델:
  변수의 값만 있으면 언제든 겨로가를 계산할 수 있는 모델.
• 수치적 모델:
  비디오 게임과 같이 사용자의 입력을 예측할 수 없는 경우 전체 게임을 분석적 모델로 나타내는 것은 불가능.

수치적 시뮬레이션은 보통 반복적 계산을 통해 각 이산(discrete)시간 단계의 시스템 상태를 찾게 구현한다. 컴퓨터 게임이 바로 이 방식으로 동작한다.

1.3 게임 엔진이란?

'게임 엔진'이라는 말은 1990년대 인기를 끌었던 이드 소프트웨어의 '둠(Doom)'등의 1인칭 시점 슈터(FPS) 게임에서 유래했다.
둠은 핵심 소프트웨어(3D 그래픽 엔진, 충돌 검출 시스템, 오디오 등)와 사용자가 보는 게임 요소(그래픽 자원, 게임 월드, 게임플레이 규칙 등)이 뚜렷하게 구분되도록 설계되었다.
이를통해 모드(mod) 커뮤니티 등의 발달하게 되었고 퀘이크3 아레나와 언리얼처럼 처음부터 재사용이나 모드 제작을 염두에 두고 설계된 게임이 등장했다. 처음부터 핵심 엔진 요소를 개발하는 경우보다 경제적이다.

어디까지가 게임 엔진이고 어디서부터 게임인지 딱 잘라 말하기는 쉽지 않다.

어떤 게임 소프트웨어가 게임 엔진인지 아닌지를 구분할 때는 그 소프트웨어가 데이터 주도적으로 설계됐는지를 보는 것이 일반적이다.
게임 규칙이나 게임 객체를 그리는 부분이 하드 코딩돼 있다면 그 소프트웨어를 다른 게임을 만드는 데 사용하기는 매우 어렵다.
따라서 게임 엔진이라는 용어는 핵심적인 변화 없이도 다른 게임을 만들 수 있는 확장 가능한 소프트웨어를 가리키는 데만 쓰는 게 옳다.

모든 게임을 만들 수 있는 게임엔진은 존재하지 않는다.
대체로 게임 엔진의 범용성이 커질수록 최적화는 떨어진다고 말할 수 있다. (trade off)

1.4 장르별 게임 엔진

보통 게임 엔진은 특정한 장르의 게임을 위해 만들어진다. 그럼에도 공통된 요소가 많은 것도 사실이다.(키보드 마우스 조이스틱 입력 처리, 3D 메시를 그리는 부분, HUD, 텍스트 렌더링, 오디오 등)
예를들어 언리얼을 이용해 FPS가 아닌 전혀 다른 장르의 게임을 만들어 성공한 사례가 많다.

1.4.1 1인칭 시점 슈터

퀘이크, 언리얼 토너먼트, 하프 라이프, 배틀필드, 데스티니, 타이탄폴, 오버워치 등의 게임에 의해 확립되었다.
현대 FPS는 넓은 실외 환경이나 한정된 공간을 가리지 않고ㅗ 온갖 다양한 가상 세계를 배경으로 한다.

1인칭 시점을 사용하는 게임은 보통 기술적으로 가장 만들기 힘든 게임 중 하나다. (3인칭 시점 슈터 액션, 플랫포머, MMO만이 여기에 견줄만 하다). 1인칭 시점 게임에서 특히 많은 기술적인 혁신이 일어나는 것이 이 때문이다.

FPS가 중요시하는 기술:

• 광활한 3D 가상 세계의 효율적인 렌더링
• 즉각적인 카메라 조작과 조준
• 매우 사실적인 캐릭터의 팔과 무기 애니메이션
• 다양한 종류의 소형화기 구현
• 캐릭터 움직임과 충돌 구현 (캐릭터가 떠다니는 것 같은 느낌 없이)
• 매우 사실적인 NPC 애니메이션과 인공지능
• 작은 규모의 멀티플레이 지원(보통 64인 이하), 데스 매치라 불리는 플레이어 간 결투 기능

FPS에 쓰이는 렌더링 기술

• 실내 배경:
  • BSP 트리
  • 포털
• 실외 배경:
  • 차폐 선별(occlusion culling) 등의 렌더링 최적화 기법
  • 오프라인에서 미리 시야를 계산(수동 또는 자동)

1.4.2 플랫포머와 다른 3인칭 시점 게임

플랫포머란 여러 발판 사이를 뛰어다니는 일이 주된 게임플레이인 3인칭 시점 게임.
슈퍼마리오64, 크래시 밴디 쿳, 레이맨 2, 소니 더 헤지훅 등...
기술적으로는 저스트 코즈 2, 기어즈 오브 워, 언차티드 등을 한데 묶어 생각할 수 있다.
FPS와 다르게 캐릭터 전신을 그려야 한다.

플랫포머에서 가장 중요한 기술:

• 움직이는 발판, 사다리, 밧줄, 창살 등의 흥미로운 이동 방식
• 퍼즐이 가득한 배경
• 메인 캐릭터를 따라 다니며 주로 사용자의 조이스틱이나 마우스로 회전이 가능한 3인칭 시점 카메라
• 시야를 보장하고자 시점이 절대 배경이나 물체에 가리거나 뚫고 들어가지 않게 하는 카메라 충돌 시스템

1.4.3 격투 게임

격투 게임은 보통 플레이어 2명이 링같이 제한된 장소에서 각자 사람 형태의 캐릭터를 조정해 서로를 공격하는 게임.
소울 칼리버, 철권 등...

격투 게임에서 중요한 기술:

• 풍부한 격투 애니메이션
• 정확한 타격 감지
• 버튼과 조이스틱으로 이뤄진 복잡한 입력을 처리할 수 있는 시스템
• 궁중과 대체로 정적인 배경
• 표면하 산란(subsurface scattering)과 땀 효과를 구현한 스킨 쉐이더를 포함한 뛰어난 캐릭터 그래픽
• 매우 사실적인 캐릭터 애니메이션
• 물리 기반 의복과 머리카락 시뮬레이션
• 포토-리얼리스틱 조명과 입자(particle) 효과

1.4.4 레이싱 게임

레이싱 게임은 주로 자동차를 비롯한 탈것을 몰고 길을 달리는 게임.
시뮬레이션을 강조한 레이싱게임, 아케이드 레이싱 게임 등 여러 하위 장르가 있음.

레이싱 게임에서 중요한 기술:

• 먼 곳의 배경을 그리기 위해 다양한 눈속임(나무나 언덕, 산 등을 빌보드로 그리는 등)을 사용한다.
• 트랙을 단순한 2차원적인 구획들로 나눠 처리하는 경우가 많은데, 이런 자료구조는 렌더링 최적화나 시야 결정을 비롯해 AI, 길 찾기 등 다양한 기술적 문제를 해결하는 데 쓰인다.
• 카메라는 3차원 시점으로 탈것의 뒤를 쫒아가나 운전석 안에 위치해 1차원 시점을 제공
• 터널 등 좁은 트랙을 달릴 때 카메라가 배겨오가 부딪히거나 뚫지 않게 각별한 노력을 들인다.

1.4.5 전략 게임

전략 게임의 기원은 듄2 라고 할 수 있다. 워크래프트, 커맨드 앤 컨커, 에이지 오브 엠파이어, 스타크래프트 등의 이에 속한다.
전략 게임에서는 먼 곳을 보기 위해 카메라의 각도를 마음대로 바꿀 수 없게 하는 것이 보통이기 때문에 전략 게임 렌더링 엔진에는 여러 최적화의 여지가 있다.

현대식 전략 게임은 원근 투영(perspective projection)과 진짜 3D 월드를 사용하기도 하지만, 유닛과 빌딩의 정렬을 위해 여전히 그리드 기반 시스템을 사용하는 경우도 있다.

전략 게임에서 즐겨 사용하는 기술:

• 유닛들은 상대적으로 디테일이 낮아서 한 번에 많은 수의 유닛이 화면에 나와도 문제없게 한다.
• 게임을 디자인하고 플레이하는 배경이 되는 지형을 높이 필드(height field)를 통해 구현하는 경우가 많다.
• 병력을 조종하는 기능과 새로운 건물을 지을 수 있는 기능이 있다.
• 유저 입력은 마우스 클릭이나 드래그를 받고 메뉴와 툴바를 통해 명령, 장비, 유닛 타입, 빌딩 타입등을 표시한다.

1.4.6 대규모 멀티플레이어 온라인 게임

대표적 MMO 에는 에버퀘스트, 월드 오브 워크래프트, 스타워즈 갤럭시 등이 있다.
이 장르의 핵심은 동시에 수천명에서 수만 명의 게이머들이 넓으면서 지속적인 가상 세계에서 게임을 한다는 것이다.
지속적인 가상 세계란 가상 세계의 상태가 일반적인 게임보다 길게 유지된다는 뜻이다.

MMO의 핵심에는 막강한 성능을 가진 게임 서버들이 있다. 게임서버는 게임 월드의 상태를 책임지고 유지하며, 게임 로그인과 로그아웃을 담당하고, 게이머 간 문자 또는 음성 대화를 매개한다.

그래픽 측면에서 MMO는 여타의 게임들보다는 다소 떨어진다고 볼 수 있는데, 이는 엄청나게 큰 게임 월드와 한꺼번에 처리해야 할 게이머 수 때문이라고 할 수 있다.

1.4.7 플레이어 제작 콘텐츠

요즘의 게임 디자인 추세는 플레이어 제작 콘텐츠 수용이다. 미디어 몰큘의 리틀빅플래닛.
가장 우명한 것으로는 마인크래프트가 있다.

1.4.8 가상, 증강, 혼합 현실

AR, AR, MR 은 3D 워ㅗㄹ드에 청자를 몰입시키는 것이 목적이다.

1.4.8.1 가상 현실

VR은 몰입적 멀티미디어 또는 컴퓨터ㅗ 시뮬레이션 현실.
실제 존재하는 현실의 장소나 가상의 세계에 사용자의 존재를 시뮬레이션 하는 것.
컴퓨터 그래픽만으로만 가상 세계를 만들어 낸다.

1.4.8.2 증강 및 혼합 현실

AR과 MR은 명확히 구분하기 힘든 경우가 많고 혼용해 사용하는 경우도 흔하다.
사용자에게 컴퓨터 그래픽으로 보강한 현실 세계를 제공한다는 공통점이 있다.

1.4.8.3 VR/AR/MR 게임

게임 업계는 이 기술들을 어떻게 적용할지 실험 중이다. 기존의 3D 게임을 VR로 이식한 경우도 있는데 그다지 혁신적이지는 않았다.
VR/AR/MR 기술 없이는 불가능한 게임 경험을 제공할 새로운 게임 장르가 형성되고 있는 중인 것 같긴 하다.
잡 시뮬레이터, 베케이션 시뮬레이터 등

1.4.8.4 VR 게임 엔진

기존의 1인칭 슈터 엔진과기술적으로 유사하고 유니티나 언리얼 같이 FPS 제작용 엔진들이 VR를 자체적으로 지원하기도 한다. 그러나 VR게임은 FPS 게임과 중요한 차이가 있다.

• 스테레오스코픽 렌더링(stereoscopic rendering):
  VR 게임은 각 눈마다 한 번씩 두 번 렌더 해야한다. 그려야 할 그래픽 기본 단위(primitive)들이 두 배가 되지만 두 눈의 거리가 매우 가깝기 때문에 시야 선별(culling) 등의 그래픽 파이프라인은 프레임당 한 번만 하면 된다. 따라서 VR 게임 렌더링은 한 게임을 화면 분할해서 그리는 것만큼 비싸지는 않지만 각 프레임마다 2개의 조금 다른 가상 카메라에서 보는 것을 그려야 하는 점은 변함 없다.
• 매우 높은 프레임 레이트:
  연구에 따르면 90FPS 보다 낮은 VR 게임은 어지러움, 메스꺼움을 비롯한 여러 부작용을 낳는다.
• 움직임 문제:
  FPS 게임에서는 패드나 WASD 키만 갖고도 플레이어가 게임 월드를 돌아다닐 수 이싿. VR 게임의 움직임은 게이머가 물리적으로 움직임으로써 일더나는데, 안전하게 몸을 움직일 수 있는 범위는 매우 작은 편이다. 플레이어가 먼 거리를 이동할 때는 선택한 지점으로 순간 이동시키는 것이 보통이다. VR 사용자가 이동할 때 제자리에서 걸을 수 있도록 하는 여러 장비가 개발되고 있기도 하다.
  

1.4.8.5 위치 기반 게임

포켓몬 고 등의 게임은 사용자의 폰과 태블릿의 움직임에 반응한다.

1.4.9 기타 장르

• 스포츠 게임
• 롤 플레잉 게임
• 파퓰러스나 블랙 앤드 화이트 같은 신(god) 게임
• 심시티 등의 건설 시뮬레이션과 심즈 등의 소셜 시뮬레이션 게임
• 테트리스 등의 퍼즐 게임
• 고전 게임을 컴퓨터 겡미화한 게임 (체스, 카드게임 등)
• 웹 게임(EA의 pogo.com 등)

1.5 현존하는 게임 엔진

1.5.1 퀘이크 계열 엔진

FPS의 효시는 보통 캐슬 울펜슈타인 3D 라고 본다.
이드 소프트웨어는 후에 둠, 퀘이크, 퀘이크 2, 퀘이크 3를 만들었다.
여기에 사용된 엔진들은 구조가 매우 비슷하기 때문에 앞으로 퀘이크 계열 엔진이라고 부르기로 한다.
이 기술들은 다른 게임이나 다른 게임 엔진을 만드는 데 활용되었다.

• 퀘이크 3
• Sin(Ritual)
• F.A.K.K. 2(Ritual)
• 메달 오브 아너: 얼라이드 어설트
• 메달 오브 아너: 퍼시픽 어설트

벨브 사의 소스엔진도 먼 근원은 퀘이크에 있다고 할 수 있다.
퀘이크와 퀘이크2 의 소스코드는 공개돼 있고, C로 짜여 있긴 하지만 구조적으로 상당히 완성도 있고 깔끔하게 만들어져 있어, 공부하는데 도움이 될 수 있다.

1.5.2 언리얼 엔진

1.5.3 하프라이프 소스 엔진

1.5.4 다이스의 프로스트바이트

1.5.5 락스타 어드밴스드 게임 엔진

1.5.6 크라이엔진

1.5.7 소니의 파이어엔진

1.5.8 마이크로소프트의 XNA 게임 스튜디오

1.5.9 유니티

1.5.10 기타 상용 엔진

1.5.11 비공개 자체 개발 엔진

1.5.12 오픈소스 엔진

오픈소스 엔진 중 오거(OGRE) 3D 엔진은 구조가 잘 짜여 있으면서 배우기 쉽고 쓰기 쉬운 3D 렌더링 엔진이다.

• 판다3D
• 야케(Yake)
• 크리스탈 스페이스
• 토크(Torque)와 일리히트(Irrlicht)
• 럼버야드 (엄밀하게 오픈소스는 아님)

1.5.13 비프로그래머를 위한 2D 게임 엔진

1.6 런타임 게임 아키텍처

게임 엔진은 크게 제작 도구(툴)와 런타임 구성 요소로 나뉜다.

게임 엔진도 계층적으로 구성된다. 상위 계층은 하위 계층에 의존하지만 그 반대는 아니다. 하위 계층이 상위 계층에 의존할 때 순환 의존(circular dependency)라고 한다. 선형 의존은 시스템 간 불필요한 결합을 생기게 하고 테스트를 어렵게 만들며 재상을 저해하기 때문에 어떤 소프트웨어라도 피해야한다.

1.6.1 목표 하드웨어

컴퓨터나 콘솔 시스템을 의미.
윈도우, 리눅스, 맥, 아이폰/아이패드, 안드로이드, 플레이스테이션, XBOX, 닌텐도 등...

1.6.2 디바이스 드라이버

운영체제나 하드웨어 제조사에서 제공하는 로우레벨 구성 요소.
하드웨어를 관리하고 운영체제나 다른 상위 계층 소프트웨어에서 불필요한 하드웨어 욧인들을 신경 쓰지 않게 하는 역할.

1.6.3 운영체제

운영체제는 게임과 같은 애플리케이션들을 조율하는 일을 한다.

초창기의 콘솔에서 운영체제는 게임 실행 프로그램에 같이 컴파일되는 단순한 라이브러리 계층에 불과했다. 이런 시스템에서는 게임이 실행되면 하드웨어를 완전 독점하다.
그러나 최신 콘솔 시스템에서는 운영체제가 게임 실행을 정지시키거나 특정 자원을 다시 가져갈 수 있다.

1.6.4 서드파티 SDK와 미들웨어

대부분의 게임 엔진은 다양한 서드파티 소프트웨어 개발 도구(SDK)와 미들웨어를 적극 이용한다.
SDK가 제공하는 함수 또는 클래스 형태의 인터페이스를 애플리케이션 프로그래밍 인터페이스(API)라고 한다.
DirectX, OpenGL, Havok, PhysX, Boost++, STL, Kynapse, Euphoria 등등...

1.6.4.1 자료 구조와 알고리듬

외부라이브러리 예시

• 부스트(Boost): STL과 유사한 뛰어난 자료구조 및 알고리즘 라이브러리. (문서가 공부에 도움이 된다)
• 폴리(Folly): 페이스북에서 쓰는 라이브러리. 표준 C++라이브러리와 부스트에 기능을 더해 확장하는 것이 목표.
• 로키(Loki): 매우 강력한 제네릭 프로그래밍 템플릿 라이브러리. 매우 복잡.

1.6.4.2 그래픽스

게임 렌더링 엔진은 다음과 같은 하드웨어 인터페이스 라이브러리 위에 동작. (예전것도 있다)

• 글라이드: 부두용 3D 그래픽 SDK (예전것임)
• OpenGL
• DirectX
• libgcm: 소니에서 만든 PS3의 RSX 그래픽 하드웨어용 SDK. OpenGL보다 성능 개선을 목표.
• Edge: 너티 독과 소니가 만든 PS3용 고성능 렌더링, 애니메이션 엔진
• Vulcan

1.6.4.3 충돌과 물리

충돌 감지와 강체 역학(게임에서는 보통 그냥 물리 라고 부른다) 기능을 제공하는 SDK

• Havok: 인기 있는 고성능 물리, 충돌 엔진
• PhysX: 엔비디아에서 만든 역시 인기 있는 고성능 물리, 충돌엔진
• ODE(Open Dynamics Engine): 널리 알려진 오픈소스 물리, 충돌 패키지

1.6.4.4 캐릭터 애니메이션

• Granny: RAD Game에서 만든 인기 있는 SDK. 마야와 맥스를 비롯한 주요 3D 모델링 및 애니메이션 제작 도구를 위한 모델, 에니메이션 내보내기 도구를 지원. 작가의 사견으로는 사용 SDK와 비공개 SDK를 통틀어 가장 잘 설계되고 놀리적인 애니메이션 API. 특히 시간에 대한 개념이 잘 정립되어 있음.
• 하복 애니메이션: 캐릭터를 점점 사실에 가깝게 만들어 감에 따라 물리와 애니메이션 간 구분이 점점 모호해지고 있다. 하복 애니메이션은 물리 SDK를 통해 성공을 거둔 하복에서 물리를 보완하려고 만든 SDK.
• OrbisAnim: PS4용 고성능 애니메이션 엔진이자 효율적인 렌더링용 지오메트리 처리 엔진.

1.6.4.5 생체 역학적 캐릭터 모델

• Endorphin and Euphoria: 인체의 움직임을 첨단 생체 역학적 모델로 분석해 캐릭터 애니메이션을 만들어내는 패키지이다.

캐릭터 애니메이션과 물리 사이의 경계가 점점 모호해지고 있다. 맥스와 마야 같은 도구로 애니메이션을 만든 다음 런타임에 물리를 이용해 보강하는 방식을 많이 쓰는데, 대표적으로 하복 애니메이션이 있다. 최근 Natural Motion이라는 회사가 내놓은 제품들은 게임과 여타 디지털 미디어에서 캐릭터 애니메이션을 취급하는 방식을 근본적으로 바꾸려고 시도한다.

엔드르핀은 마야 플러그인으로, 캐릭터를 생체 역학적으로 시뮬레이션한 결과를 마치 사람이 직접 애니메이션처럼 내보낼 수 있는 툴이다. 무게 중심, 무게 분포, 중력과 다른 힘의 작용하에 실제 사람이 균형을 잡고 움직이는 방식 등에 대한 생체 역학적 연구를 바탕으로 한다.

유포리아는 엔도르핀의 실시간 버전으로 예측 불가능한 힘의 작용하에서도 물리적으로나 생체 역학적으로 정확한 캐릭터 움직임을 만들어내는 것을 목표로 한다.

1.6.5 플랫폼 독립적 계층

대부분 게임 엔진은 적어도 1개 이상의 하드웨어 플랫폼에서 동작해야 한다.
따라서 대부분의 게임 엔진은 플랫폼 독립적 계층을 둔다.
이 계층은 하드웨어, 드라이버, 운영체제, 기타 서드파티 소프트웨어 위에서 동작하는데, 플랫폼에 상관없이 게임 프로그래머가 제어할 수 있는 함수들로 특정한 인터페이스 함수들을 wrap해서 엔진이 하부 플랫폼의 세부적인 내용까지 몰라도 동작할 수 있게 한다.

1.6.6 코어 시스템

게임 엔진을 비롯해 규모가 큰 모든 C++ 소프트웨어는 적재적소에 쓸 수 있는 소프트웨어 유틸리티들이 필요하다. 이 책에서는 이런 것들을 코어 시스템이라고 부르기로 했다.
(모듈 스타트업과 셧다운, 어서션, 유닛 테스트, 메모리 할당, 수학 라이브러리, 문자열과 해시 문자열 ID, 디버그 프린트와 로그 등...)

• Assertion: 논리적인 프로그램 에러를 검출하고 프로그래머가 코드를 작성할 때 전제 조건으로 삼았던 조건들이 어긋나지 않았는지 점검하는 코드. 최종 버전에서는 보통 제거된다.
• 메모리 관리: 사실상 모든 게임 엔진은 메모리 할당과 해제의 효율성, 메모리 단편화 방지를 위해 전용 메모리 시스템을 구현한다.
• 수학 라이브러리: 게임 엔진은 태생적으로 수리 연산을 중시한다. 그래서 보통 한두 개 정도 수학 라이브러리를 포함하고 있다. 수학 라이브러리는 벡터, 행렬, 사원수(quaternion), 삼각함수뿐만 아니라 선, 빛, 구, 절두체(frustum) 같은 기하 연산, 스플라인(spline) 곡선, 수치 적분, 방정식 계산 등 게임 프로그래머가 사용하는 모든 연산을 제공한다.
• 독자적 자료 구조와 알고리듬: STL같은 외부 패키지에 전적으로 의존하지 않는 이상 기본적인 자료 구조(연결 리스트, 동적 배열, 이진 트리, 해시 맵 등)와 알고리듬(검색, 정렬 등)을 처리하기 위한 도구가 필요하다. 대상 플랫폼에서 효율적인 메모리 사용과 최적의 성능을 내기 위해 이런 도구는 직접 작성하는 것이 일반적이다.

1.6.7 자원 관리자

자원 관리자(resource manager)는 게임 엔진의 모든 자원과 여타 엔진 데이터에 접근하는 데 일관된 인터페이스를 제공하며 형태는 다르더라도 모든 게임 엔진에는 자원 관리자가 있다. 언리얼의 패키지와 오거의 ResourceManager 클래스가 이런 형태다.

1.6.8 렌더링 엔진

렌더링 엔진은 게임 엔진에서 제일 복잡하고 광범위한 부분 중 하나다. 렌더링 엔진의 설계 방식은 굉장히 다양하다. 표준적 설계 방식이 있는 것은 아니지만, 앞으로 살펴볼 내용처럼 렌더링 엔진은 3D 그래픽 하드웨어이 특성에서 기인한 몇 가지 근본적인 디자인 철학을 공유한다.

1.6.8.1 로우레벨 렌더러

렌더링 엔진에서 가장 기초적인 부분이다. geometric primitive를 가능한 빠르게 그리면서 다양한 방식을 지우너하는 데 중점을 두며, 화면의 가시성 등 좀 더 추상적인 문제에는 관여하지 않는다.

그래픽 디바이스 인터페이스

그래픽 하드웨어를 찾아내고 초기화한 후 렌더 표면(후면 버퍼, 스텐실 버퍼 등)을 설정하는 것과 같은 간단한 일을 하는 데도 상당히 긴 코드를 짜야 한다. 이런 부분을 이 책에서는 그래픽 디바이스 인터페이스라고 부르기로 한다.

기타 렌더러 구성 요소

로우레벨 렌더러와 나머지 부분들은 메시, 선 리스트, 점 리스트, 입자, 지형 조각, 문자열 등 상위 계층에서 전달하는 기하학적 기본 단위(렌더 패킷이라고도 한다)를 처리하고 가능한 빨리 그리기 위해 협업해야 한다.

1.6.8.2 장면 그래프와 추려내기 최적화

로우레벨 렌더러는 전달된 기하학적 단위들이 실제 보이든 그렇지 않든 상관하지 않고 무조건 그린다. 시야 결정(visibility determination)을 통해 보이는 부분과 그렇지 않은 부분을 가려내 그릴 기하학적 기본 단위 수를 줄이는 일은 보통 더 상위 계층에서 담당한다.

로우레벨 렌더러는 사용된 공간 분할 방식이나 장면 그래프 종류에 전혀 영향을 받지 않는 것이 가장 이상적이다. 이 경우 같은 기본 단위 인터페이스를 사용하면서도 보일 가능성이 있는 집합(PVS)을 반단하는 시스템은 각 개발 팀이 원하는 것을 사용할 수 있는 이점이 있다.

1.6.8.3 시각 효과

오늘날 게임 엔진은 여러가지 시각 효과를 사용하는데

• 파티클 시스템 (연기, 불, 물이 튀는 현상 등)
• 데칼 시스템 (총알 자국, 발자국 등)
• 조명 매핑과 환경 매핑
• 동적 그림자
• 풀 스크린 후처리 효과 (전체 화면이 그려진 후에 효과가 적용됨)

풀 스크린 후처리 효과의 예를 들어보면

• HDR 조명과 블룸(bloom)
• 풀 스크린 안티에일리어싱 (FSAA)
• 색 교정과 색 옮김(color shift) 효과, 블리치 바이패스(bleach bypass), 채도(saturation)효과, 채도 감소(de-saturation)효과 등

일반적으로 이펙트 시스템을 따로 둬 입자, 데칼, 그 외의 시각 효과를 전담하는 경우가 많다.
입자와 데칼은 렌더링 엔진 안의 구분된 시스템으로 분리돼 직접 로우레벨 렌더러에 입력을 주는 경우가 많고, 이와 대조적으로 조명 매핑, 환경 매핑, 그림자는 렌더링 엔진 안에서 처리된다. 풀 스크린 후처리 효과는 렌더러에 포함해 구현할 수도 있고, 아니면 렌더러의 결과물을 갖고 따로 동작을 하는 별개의 시스템으로 만들 수도 있다.

1.6.8.4 전단부 (front-end)

대부분의 게임은 3D 그래픽 외에 그 위에 덧씌워지는 2D 그래픽을 사용한다.

• HUD
• 게임 메뉴, 콘솔, 기타 개발 툴
• 캐릭터의 인벤토리 등 GUI

텍스처를 입힌 사각형(또는 삼각형 2개)을 직교 투영해 그리기도하고, 아니면 진짜 3D 빌보드에 그린 후 항상 카메라를 향하게 구현하기도 한다.

풀 모션 비디오 시스템과 인게임 시네마틱 시스템도 이 계층과 관련이 있다.

1.6.9 프로파일링과 디버깅 툴

실시간 시스템의 특성 때문에 게임은 최적화를 위해 프로파일링을 해야 하는 경우가 종종 있다. 또 대부분의 경우 메모리가 부족하기 때문에 메모리 분석 툴도 함께 사용해야 한다.
디버그 정보 그리기, 게임 메뉴 또는 콘솔, 게임 플레이 기록 및 정확한 재현을 위한 시스템 등을 모두 포괄하는 계층.

시중의 훌륭한 범용 디버깅 툴

• 인텔의 VTune
• IBM의 Quantify와 Purify
• 파라소프트(Parasoft)의 Insure++
• 줄리안 시워드(Julian Seward)와 밸그린드(Valgrind)개발팀의 밸그린드

대부분의 게임 엔진은 자체적으로 프로파일링과 디버깅 툴을 구현한다.

• 코드를 수동으로 인스트루먼테이션(Instrumentation) 하는 시스템 (소요된 시간을 정확히 측정하는데 필요)
• 게임 화면에서 실시간으로 프로파일링 수치를 보여 주는 기능
• 성능 값을 텍스트 파일이나 엑셀 스프레드시트 파일로 뽑아내는 기능
• 게임 엔진과 각 하부 시스템이 사용 중인 메모리 양을 측정하는 기능
• 메모리 사용량, 최고 사용량, 메모리 누수 통계 등을 게임이 종료될 때나 게임플레이 중 파일로 뽑아낼 수 있는 기능
• 디버그 메세지를 코드 어느 곳에서나 출력할 수 있고 필요한 항목마다 켜고 끄는 기능을 가진 툴, 또한 어늦 ㅓㅇ도로 자세하게 출력할 지 조정할 수 있는 툴
• 게임플레이를 녹화하고 재현하는 기능

1.6.10 충돌과 물리

충돌 체크는 모든 게임에서 중요하다. 제대로 된 충돌 체크 없이는 게임 월드에서 어떤 일도 제대로 해내기 힘들다. 이보다 한발 더 나가 매우 사실적이거나 사실에 근사한 역학 시뮬레이션을 구현하는 게임도 있다. 보통 물리 시스템, 정확히는 강체 역학이다.

보통 충돌과 물리는 밀접한 연관이 있다.
오늘날에는 직접 충돌 및 물리 엔진을 만드는 개발사는 거의 없고 대개 외부 SDK를 사용한다.

• Havok: 업계에서 가장 널리 사용되는 물리 엔진. 풍부한 기능, 다양한 플랫폼 지원
• 엔비디아의 PhysX: 언리얼 엔진에 통합돼 있음, 개별 제품으로 PC용은 무료. Ageia 사의 물리 가속 하드웨어용 인터페이스로 개발됐었는데, 지금은 엔비디아에서 소유하고 배표.

1.6.11 애니메이션

생명체나 그 유사한 형태로 움직이는 물체가 나오는 게임이라면 반드시 애니메이션 시스템이 있어야 한다.

게임에서 사용하는 가장 기본적인 다섯가지 애니메이션 방식

• Sprite/texture 애니메이션
• Rigid body hierachy 애니메이션
• skeletal 애니메이션
• vertex 애니메이션
• morph target

뼈대 애니메이션은 애니메이터가 비교적 단순한 본은 움직여 캐릭터 메시를 움직이는 방식, 뼈대 애니메이션이야 말로 오늘날 가장 널리 쓰이는 애니메이션 방식.

1.6.12 휴먼 인터페이스 장치

모든 게임에는 사용자 입력을 받는 HID가 있는데,

• 키보드 마우스
• 조이패드
• 기타 특수 컨트롤러 (운전대, 낚시대, 댄싱 패드, 위모트 등)

어떤 떄는 플레이어에게 출력을 보내는 경우도 있기 때문에 I/O라고부르기도 함(포스 피드백, 진동, 위모트 소리 등)

1.6.13 오디오

퀘이크 엔진의 오디오 시스템은 무척 단순,
언리얼 엔진 4는 어느정도 괜찮은 오디오 렌더링 엔진을 갖추고 있지만 기능이 제약적,
DirectX 플랙폼용으로는 XAudio2가 있음.
EA가 개발한 비공개 고급 오디오 엔진이 있는데 이름이 SoundR!OT이다.
소니 인터렉티브 엔터테인먼트가 너티 독 등 퍼스트파티 개발사들과 갭라한 Scream도 있다.

1.6.14 온라인 멀티플레이어와 네트워킹

• 단일 스크린 멀티 플레이어: 조이스틱 여러개, 한 게임기, 한 화면, 게이머들은 같은 공간에 있지만 카메라는 단 1대 뿐이라 모두 같은 화면을 본다. 스매시 브라더스 등
• 분할 화면 멀티플레이어: 조이스틱 여러개를 한 게임기에 연결, 화면 분할, 각자 시점
• 네트워크 멀티플레이어: 네트워크 통해 연결, 각 기계는 1명의 플레이어가 사용
• 대규모 멀티플레이어 온라인 게임 (MMOG): 수천, 수만 명의 게이머가 동시에 광대하고 지속적인 온라인 가상 세계에서 게임을 즐긴다. 가상 세계는 여러대의 서버가 구현한다.

개발을 시작할 때 부터 멀티 플레이어 기능을 미리 고려하는 편이 좋다.
완성된 멀티플레이어 게임을 싱글플레이어 게임으로 바꾸는 것은 의외로 간단하다.

1.6.15 게임플레이 기반 시스템

게임 내에서 하는 행동, 게임 규칙, 플레이어 캐릭터의 능력, 플레이어의 목표 등.
따로 추상적인 스크립트 언어를 사용하는 경우도 있음.

1.6.15.1 게임 월드와 객체 모델

• 정적인 배경: 빌딩, 길, 지형 등
• 동적인 단단한 물체들: 바위, 음료수 캔, 의자 등
• 플레이어블 캐릭터(PC)
• NPC
• 무기
• 발사체(projectile)
• 탈것
• 빛 (런타임에 실시간 조명에 사용되기도 하고 오프라인에서 정적 조명 계산에만 사용되기도 한다)
• 카메라
  등...

게임 객체 모델은 소프트웨어 객체 모델과 밀접한 관계가 있음
게임 엔진에서 소프트웨어 객체 모델은 다음과 같은 문제들과 관련있음

• 엔진 디자인이 객체지향적인가?
• 어떤 개발 언어를 사용할 것인가?
• 클래스 구조는 어떤 형태를 띨 것인가?
• 템플릿과 정책 기반 디자인을 사용할 것인가? 아니면 전통적 다형성?
• 객체에 접근할 때는 어떤 방식 사용? 포인터, 스마트 포인트, 핸들...
• 서로 다른 객체를 어떻게 고유하게 분별? 물리적 주소, 이름, GUID...
• 객체의 수명은 어떻게 관리?
• 시간적 흐름에 따라 각 객체의 상태는 어떻게 시뮬레이션?

1.6.15.2 이벤트 시스템

게임 안의 객체들은 서로 소통해야 하는데, 그 방식은 무척 다양.

1.6.15.3 스크립트 시스템

게임 규칙과 콘텐츠를 쉽고 빠르게 개발하기 위해 많이 사용됨.

1.6.15.4 인공지능 기반 시스템

점점 인공지능 시스템에도 공통적인 패턴이 등장하기 시작했고 서서히 게임 엔진에 통합되는 추세.
Kynogon사가 개발한 미들웨어 SDK인 Kynapse는 상용 게임 수준의 AI에서 사용되는 대부분의 로우레벨 기술을 지원.

1.6.16 게임 특화 하부 시스템

게임플레이 기반 계층과 여타 로울벨 엔진 요소들이 갖춰지면 비로소 게임플레이 프로그래머와 디자이너가 게임 자체의 기능들을 구현할 수 있다.
플레이어 메카닉, 카메라 시스템, NPC 인공지능, 무기 시스템, 탈것 등...

1.7 도구와 자원 파이프라인

1.7.1 디지털 콘텐츠 생성 도구 DCC

3D 메시, 텍스처 비트배, 애니메이션 데이터, 오디오 파일 등 다양한 자원이 게임 엔진에 사용된다. 모든 자원은 아티스트가 만들어 내고 다듬어야 하는데, 이런 작업을 하는 데 사용하는 툴을 디지털 콘텐츠 생성 프로그램이라고 한다.

오토데스트 마야, 3ds 맥스, 포토샵, 사운드 포지...

월드 제작은 보통 게임 엔진 자체적인 월드 제작 툴을 사용.

1.7.2 자원 다듬기 파이프라인

DCC에서 만든 데이터를 바로 게임 엔진에서 사용할 수 없다.

• DCC의 자원 메모리 모델은 게임 엔진에서 쓰기엔 필요 이상으로 복잡.
• DCC 프로그램의 데이터 파일 형식은 읽어 들이는 데 시간이 너무 많이 걸리고 저작권이 걸린 경우도 있다.

표준 포멧이나 다른 포멧으로 export 후, 가공해야 함.

1.7.2.1 3D 모델/메시 데이터

게임에서 보이는 기하 형태의 대부분은 삼각형 메시로 만들어짐.
일부 오래된 게임 중에서는 볼륨 형태의 기하 형태인 브러시를 사용하기도 함.

1.7.2.2 뼈대 애니메이션 데이터

스켈레탈 메시는 애니메이션을 하기 위해서 뼈대 구조에 연결되는 특수한 형태의 메시다. 스킨이라고도 부르기도 하는데, 메시가 보이지 않는 뼈대를 감싼 피부 같은 역할을 하기 때문에 붙여진 이름.
스켈레탈 메시의 각 정점에는 뼈대의 어느 관절(joint)들에 연결되는지를 나타내는 정보가 담겨 있다. 이와 함께 각 뼈대의 영향을 어마만큼 받는지를 나타내는 가중치도 함께 갖는 것이 일반적이다.

스켈레탈 메시를 그리기 위해서는 세 가지 데이터가 필요하다.

• 메시
• 뼈대 구조 (관절 이름, 부모-자식 관계, 뼈대를 생성할 때의 기본 포즈)
• 뼈대가 어떻게 움직이는지를 나타내는 애니메이션

1.7.2.3 오디오 데이터

오디오 클립은 보통 사운드 포지 등의 오디오 제작 도구로부터 가져옴
WAV가 흔하고, 플레이스테이션의 ADPCM(.vag)등도 흔히 쓰인다. 오디오 클립들은 뱅크(bank)로 묶어서 쓰는 경우가 흔한데, 관리나 로딩, 스트리밍 등의 편의성 때문이다.

1.7.2.4 파티클 시스템 데이터

오늘날의 게임 엔진에서는 복잡한 파티클 효과가 쓰인다. 이것들은 시각 효과를 전문으로 하는 아티스트에 의해 제작된다.
후디니 등의 서드파티 도구를 사용하면 영화 수준의 효과를 만들 수 있다.
대부분의 엔진은 성능상의 문제로 전용 파티클 효과 편집 도구를 따로 만드는 경우가 많다.

1.7.3 월드 에디터

게임 엔진의 모든 것이 한데 모이는 곳이 게임 월드다.

• 퀘이크 기반 대부분의 게임 엔진들은 Radiant 게임 에디터의 변종들을 사용
• 하프라이프 2 소스 엔진은 Hammer라는 월드 에디터를 제공.
• 언리얼 에디터는 언리얼 엔진 원드 에디터
• 크라이 엔진의 월드 에디터는 Sandbox다.

1.7.4 자원 데이터 페이스

게임 엔진이 처리해야 하는 자원의 종류는 매우 많은데, 렌더링용 기하 형상에서부터 머티리얼, 텍스처, 애니메이션 데이터, 오디오까지 다양하다.
예를들어 마야에서 애니메이션 클립을 하나 제작한 경우 메타데이터는 자원 다듬기 파이프라인과 최종적으로 게임 엔진에 다음과 같은 정보를 제공한다.

• 런타임에 애니메이션을 식별할 수 있는 고유 ID
• 소스 마야(.ma 또는 .mb) 파일의 이름과 디렉토리 경로
• 프레임 범위-애니메이션이 시작되고 끝나는 프레임
• 애니메이션이 반복하는지 아닌지
• 애니메이터가 지정한 압축 기법과 압축 레벨

게임엔진은 게임의 자원에 연계된 모든 메타데이터를 관리하기 위한 일종의 데이터베이스가 필요하다.
관계형 데이터베이스 MySQL 또는 오라클을 사용해 구현할수도 있고,
아니면 그냥 텍스트 파일들을 Subversion, Perforce, Git 같은 버전 컨트롤 시스템을 통합해 관리하는 식으로 구현할수도 있다.
이 책에서는 이 같은 메타데이터를 자원 데이터베이스라고 부르기로 한다.

1.7.5 툴 구조에 대한 접근 방식

툴은 독자적 소프트웨어인 경우도 있고, 엔진과 일정한 하위 계층을 공유하기도 한다. 어떤 경우는 툴이 아예 게임 안에 포함되는 경우도 있다.
언리얼 엔진의 경우는 게임에 완전히 통합된 형태다.

1.7.5.1 웹 기반 사용자 인터페이스

특정 게임 개발 도구에서는 웹 기반 사용자 인터페이스가 빠르게 보편화되는 추세다.

웹 앱은 따로 설치할 필요가 없고 호환되는 웹 브라우저만 있으면 된다.
유지 보수가 쉽고 빠르다.