언리얼 렌더링 아키텍처 해체신서

Appearance

언리얼 렌더링 시스템 분석(14) - 확장 장: 현대 렌더링 엔진의 진화 역사 1부(초기) ​

🌐 원문 링크: 剖析虚幻渲染体系（14）- 延展篇：现代渲染引擎演变史Part 1（萌芽期） (cnblogs.com/timlly)
📅 원문 발행일: 2022-04-03 ｜ ✍️ 저자: Timlly (00 / )

💡 시리즈 분류: History of Rendering ｜ 국내 업계 표준 용어 감수 및 수식/도해 복원 적용 완료

옛말에 '역사를 거울로 삼으면 나라의 부흥을 알 수 있다'는 말이 있습니다.

역사와 마찬가지로 기술도 마찬가지입니다. 현대 엔진의 진화 역사를 연구함으로써 엔진의 기술적 내부 이야기를 보다 체계적이고 자세하게 이해함으로써 기본 원리를 숙지하고 패턴을 발견하며 기술이나 산업의 미래를 예측할 수 있습니다. 저자는 이 기간 동안 1,000편이 넘는 논문과 다양한 유형의 문서를 섭렵하고 수백 건의 문서를 추출해 동료들의 유익을 위해 이 글로 요약했다.

14.1.1 게임 엔진 소개 ​

이 섹션에서는 게임 엔진의 정의, 기능, 모듈 및 기본 프레임워크에 대해 설명합니다.

게임에는 공통 기능이 많이 있는 경우가 많으며, 이러한 기능을 공통 기능으로 추상화하는 프레임워크를 만드는 것을 게임 엔진이라고 합니다. 보다 정확하게 말하면, 게임 엔진은 게임 개발 팀이 기술적인 콘텐츠보다는 제품의 게임 콘텐츠에 집중할 수 있게 해주는 일련의 모듈과 인터페이스입니다.

게임 엔진은 완성도에 따라 통합형과 모듈형의 두 가지 유형으로 구분됩니다. 통합 엔진은 GameMaker, RPGMaker 등의 엔진이고, 모듈형 엔진은 UE, Unity 등의 엔진을 의미합니다. 이 기사에서는 모듈식 게임 엔진에 중점을 둘 것입니다.

게임 엔진은 보편적인 게임이 의존하는 기능이나 모듈입니다. 게임 엔진은 게임의 다양한 작업에 대한 세부 정보를 구성하는 다양한 도구, 유틸리티 및 인터페이스 세트로 구성된 프레임워크입니다. 간단히 말해서 게임 엔진은 크게 수정하지 않고도 다양한 게임의 기반으로 사용할 수 있는 확장 가능한 소프트웨어로 정의할 수 있습니다.

최신 게임 엔진 아키텍처를 위한 공통 모듈.

컴퓨터 게임 장르는 다양하며, 주요 장르는 1인칭 슈팅 게임(FPS), 실시간 전략(RTS), 롤플레잉 게임(RPG)입니다. 모든 장르에는 싱글 플레이어 게임(인공 지능을 사용하여 다른 플레이어를 시뮬레이션하는 게임)이나 멀티 플레이어 게임(여러 플레이어가 컴퓨터 네트워크를 통해 동일한 가상 세계에서 상호 작용할 수 있는 게임) 또는 둘 다를 포함합니다. 그리고 특정 유형의 게임 제작에는 다양한 게임 엔진이 더 좋습니다. 예를 들어 Unreal Engine은 야외 FPS에 더 적합하고 Unity는 경량 모바일 게임에 더 적합합니다.

대부분의 현대 컴퓨터 게임은 게임 엔진, 게임 로직, 게임 아트의 세 부분으로 나눌 수 있습니다. 게임 엔진은 컴퓨터에서 실행되는 주요 실행 파일입니다. 게임 로직을 실행하는 환경은 물론 기본 수학, 그래픽, 오디오, 사용자 입력 및 네트워킹 기능을 제공합니다. 게임 로직은 스크립트, 가상 머신 바이트코드 또는 라이브러리(예: DLL) 형식일 수 있습니다. 게임 로직은 게임플레이를 제어하고 엔진을 사용하여 게임 아트를 적절하게 표시하는 역할을 합니다. 게임 아트에는 그림(게임 용어의 질감), 지도(가상 세계의 레이아웃), 모델(플레이어, 무기, 화분 등 세계를 채우는 사물의 3D 표현) 및 사운드가 포함됩니다.

게임과 게임 엔진의 관계.

게임, 게임 엔진, 컴퓨터의 추상적인 계층화.

게임 엔진 내의 공통 계층 구조 및 모듈.

최신 게임 엔진에 대한 모듈 세부정보입니다.

게임 엔진을 사용하여 게임 로직과 아트를 변경함으로써 다양한 컴퓨터 게임을 만들 수 있습니다. 경우에 따라 소스 코드를 사용할 수 있으면 게임 엔진 자체를 수정할 수 있습니다(예: Quake 2).

간단히 말해서, 게임 엔진은 게임 개발 팀에 게임 개발의 모든 측면을 제공하므로 게임 개발자는 프로그래밍 기술이 덜 필요하고 전문가 수준의 가상 콘텐츠를 빠르고 효율적으로 만들 수 있습니다. 게임 엔진의 크기, 모듈성, 휴대성의 증가와 이와 관련된 향상된 도구는 최초의 게임부터 오늘날까지 일반적인 추세로 간주됩니다.

게임 엔진을 사용하는 데는 여러 가지 목적이 있습니다.

  • 유연성. 기능을 중단하지 않고도 기본 API에서 수행할 수 있는 모든 작업을 수행할 수 있습니다.

  • 생산성. 네이티브 API보다 사용하기 쉽고, 코드가 적고, 정신적 부담이 적습니다.

  • 성능. CPU 프레임 시간은 손으로 작성한 네이티브 코드와 유사합니다.

  • 단순한. 인터페이스를 가능한 한 적게, 정확하게 유지하세요.

주류 상용 게임 엔진의 일부 기능.

게임 엔진을 사용하여 게임 및 기타 제품을 만들면 다음과 같은 이점이 있습니다.

  • 코드가 적다

  • 생산성 향상 = 시간 단축!

  • 사용성(사용의 용이성)

  • 설계 프로그램과의 호환성(통합)

  • 더 많은 도구, 더 많은 옵션

  • 플러그인 및 라이브러리

  • 크로스 플랫폼

물론 게임 엔진이 만능은 아니고, 한계도 많습니다. 예를 들어, 엔진이 기대하는 것과 다른 유형을 생성하는 것이 어려울 수 있습니다. 엔진이 예상치 못한 작업을 수행하도록 하는 것은 어려울 수 있습니다. 게임 개발자의 엔진 약점은 게임의 품질과 효율성을 제한합니다.

14.1.2 게임 엔진 모듈 ​

게임 엔진은 게임이나 시뮬레이션의 핵심 소프트웨어로, 게임 개발에 사용되는 코드 집합을 설명하는 데 사용됩니다. 화면에서 보고 게임 세계나 시뮬레이션 환경에서 상호 작용하는 모든 것은 게임 엔진에 의해 구동됩니다. 이를 통해 일반적인 게임 세부 정보 또는 시뮬레이션 관련 작업(예: 렌더링, 물리, 입력)을 추상화하고 수행할 수 있으므로 개발자는 게임의 모든 측면을 시뮬레이션 친화적으로 만드는 데 집중할 수 있습니다.

일반적인 게임 엔진 구성 요소 및 유형의 다이어그램.

게임 엔진은 유연성에 중점을 두고 설계되어 기능을 간단하게 확장할 수 있으며 메모리 등 특정 요소에 의해 제한되는 플랫폼에 맞게 쉽게 수정할 수 있습니다. 엔진은 프레임워크와 관리자라는 두 부분으로 나뉩니다. 프레임에는 게임의 반복적인 부분이 포함되어 있습니다. 즉, 여러 인스턴스가 있을 뿐만 아니라 기본 게임 루프 실행과 관련된 항목도 있습니다. 관리자는 게임 로직이 의존하는 싱글톤입니다. 아래 다이어그램은 엔진을 구성하는 다양한 부품을 보여줍니다.

게임 엔진의 가장 기본적인 모듈에는 시간 업데이트, 장면 관리, 렌더링(그래픽, 드로잉), 입력 이벤트 등이 포함되어야 합니다.

위의 기본 모듈을 갖춘 고급 게임 엔진에는 카메라, 화면 관리, 네트워크, 오디오, 물리, 애니메이션, 모델 등과 같은 더 복잡한 모듈도 있습니다.

애플리케이션은 이벤트를 사용하거나 이벤트를 다른 화면으로 전달할 수 있는 화면 맵을 유지 관리합니다.

렌더링 모듈은 엔진의 핵심 기능입니다. 이는 항상 게임 엔진의 최우선 과제였으며 업계 실무자가 정복해야 할 핵심 영역이기도 합니다. 게임 엔진의 성공 여부에 관계없이 렌더링 모듈은 매우 중요한 역할을 합니다. 렌더링 모듈의 가장 간단한 기능에는 카메라 설정, 모양 그리기, 모양의 재료 속성 설정 및 텍스트 그리기가 포함됩니다. 이를 통해 표준 그래픽 API 인터페이스를 생성하고 운영 체제 또는/및 드라이버를 통해 GPU에 그리기 명령을 보내고 실행합니다.

고급 게임 엔진에는 플레이어 제어, 플러그인 시스템, 편집기, 자동화 도구, 자산 관리 등과 같은 높은 수준의 일반 게임 모듈도 있는 경우가 많습니다. 게임 엔진은 크로스 플랫폼, 그래픽 API, 하드웨어 차이 등을 추상화하고 처리하는 역할도 담당합니다. 최신 게임 엔진에는 종종 하위 수준, 중간 수준, 상위 수준 모듈로 나눌 수 있는 더 복잡하고 다양하며 포괄적인 모듈과 도구 체인이 포함되어 있습니다. 세부사항은 다음과 같습니다:

  • 저수준 모듈

데이터 구조

배열, 연결리스트, 트리, 그래프, 해시 테이블

  • 알고리즘

정렬, 동적 프로그래밍, 병렬 루프

  • 수학

벡터, 행렬, 쿼터니언

  • 기하학적 계산

  • 임의의 숫자

  • 기타 수학 모듈

  • 메모리 관리

게임 엔진은 종종 사용자 정의 메모리 관리를 사용합니다.

  • 단편화를 피해야 한다

  • 계층적 메모리 관리

  • 어드레싱

  • 쓰레기 수거

  • 그래픽 카드 메모리 관리

  • 리소스 및 파일 IO

빠른 로딩

  • 어드레싱

  • 파싱

  • 파일 형식

-XML

  • 압축

  • 자원 포장

  • 입력 장치

제어판, 조이스틱

  • 키보드, 마우스

  • 특수 하드웨어(햅틱, 6-DOF)

  • 포스 피드백

  • 마이크

  • 카메라

  • 구성

  • 버튼 매핑

  • 교정

  • UI

기본 컨트롤

  • 사고관리

  • UI 애니메이션

  • 성능 모니터링

시간은 중요한 자원이다

  • CPU, 그래픽, 오디오, IO 등 각각 고유한 타이밍 및 성능 특성을 지닌 다양한 하드웨어

  • 정교한 분석기가 많이 존재함

  • 게임 내 예산 및 경고 게임 내 예산 및 경고

  • 게임 내 드로잉 게임 드로잉

  • 종합적인 분석을 위한 디버깅 도구

  • 중간 수준 모듈

렌더링

자세한 내용은 그래픽 하위 시스템을 참조하세요.

  • 오디오

3D 공간화: 팬, 도플러, Dolby Surround, HRTF(머리 관련 전달 함수)

  • 사운드 우선순위(소리) 관리

  • 리버브, 이펙트

  • 미디

  • 음악

  • 역동적인 음악

  • 스트림 CD/DVD(다중 스트림)

  • 음성

  • 텍스트

  • 충돌 감지

  • 물리학

  • 스크립트

  • 인터넷

  • 캐릭터 애니메이션

  • 영화 재생

  • 높은 수준의 시스템

장면 관리

  • 사용자 컨트롤

  • 카메라

  • AI(인공지능)

  • 게임 로직

  • 게임 흐름

  • 조명, 시각효과

  • 헤드업 디스플레이

  • 프론트엔드(사용자 인터페이스)

  • 그래픽 하위 시스템

렌더링

하드웨어 위에 레이어링

  • 일반적으로 사용되는 API: OpenGL, Direct3D, Vulkan, Metal

  • 다각형 메쉬 렌더링(목록 표시)

  • 조명

디퓨즈, 스페큘러 반사, AO, GI, IBL, PBR

  • 그래픽 상태

  • 행렬 및 뷰 변환

  • 셰이더

  • 특수 소재

피부, 머리카락, 안구, 2차원

  • 장면 관리

장면 그래프

  • 가속 구조 : KD 트리, 쿼드 트리, 옥트리, Portal, BVH 등

  • 데칼

-AI

  • 충돌

  • 컬

-LOD

  • 지형 렌더링

  • 캐릭터 리스킨

  • 입자 엔진

  • 효과(하늘, 물, 식물, 안개)

  • 도구

코드 개발 도구

컴파일러(Visual C++, SN Systems, CodeWarrior, GNU)

  • 디버거

  • 프로파일러

  • 편집

  • 개정 관리(CVS, SourceSafe, SVN)

  • 통합 개발 환경(IDE)

  • C++, 어셈블리, 스크립팅 언어

  • 그래픽 언어: 픽셀 및 버텍스 셰이더...

  • 설계 분석 도구

  • 문서, 표준

  • 미들웨어

렌더링: RenderWare, NDL, 내장, OGRE, OpenSceneGraph

  • 물리 엔진: ODE, Havok, PhysX, Newton

  • 수학 엔진

  • XNA, Bink, FMOD, ScaleForm

  • 예술 제작 도구

3D 모델링 및 애니메이션(Maya, 3D Studio)

  • 수출 수출 모듈 모듈

  • 자산 관리(AlienBrain)

  • 페인팅(2D 및 3D)(Photoshop, Z-Brush, DeepPaint)

  • 스캔(2D, 3D)

  • 모션 캡쳐

  • 게임 내 도구 및 편집기

  • 오디오 도구

녹음

  • 작곡가 (ProTools)

  • 음향효과(이유)

  • 공간 오디오 구성 도구

  • 게임 내 도구

  • 게임 디자인 도구

게임 내 도구

  • 레벨 레이아웃

  • 프로토타이핑 도구(Director, Flash)

  • 디자인 도구

  • 그래픽 사용자 인터페이스 도구

CEGUI, NGUI, UMG

오픈 소스 렌더링 엔진 OGRE와 통합된 CEGUI 편집기의 개요입니다.

게임이나 시뮬레이션 내에서의 상호작용은 매우 중요하며 전반적인 사용자 만족도에 가장 중요한 요소입니다. 각 게임/시뮬레이션에는 유형, 지원되는 컨트롤, 상호 작용에 대한 응답 시간, 상호 작용 응답이 얼마나 현실적인지에 따라 고유한 요구 사항이 있습니다. 각 응용 프로그램의 대상 그룹은 상호 작용 옵션을 크게 정의합니다.

가능할 때마다 마우스 이동 속도, 마우스 이동 속도 반전, 위 및 아래 축 반전, 다중 위 및 아래 축, 다중 모드 제어 모달 제어 등과 같은 상호 작용 매개변수를 사용자 정의하고 수정하는 사용자의 능력은 필수적이며 중요합니다. 일반적인 게임 실행 프로세스에는 다음 그림에 표시된 대로 창 메시지 처리, 스케줄러 실행, 배포 변경 및 실행 상태 감지가 포함됩니다.

일반적인 장면과 사물의 관계는 아래 그림과 같습니다. 각 시스템에는 하나 이상의 장면이 포함되어 있으며 각 장면에는 하나 이상의 개체가 포함되어 있습니다.

게임 엔진은 일반적으로 도구 모음과 런타임 구성 요소로 구성됩니다. 다음 다이어그램은 일반적인 3D 게임 엔진을 구성하는 모든 주요 런타임 구성 요소를 보여줍니다. 모든 소프트웨어 시스템과 마찬가지로 게임 엔진은 계층으로 구축되며 일반적으로 상위 계층이 하위 계층에 종속되지만 그 반대는 아닙니다. 순환 종속성은 하위 레이어가 상위 레이어에 종속될 때 발생합니다. 종속성 주기는 시스템 간의 잘못된 결합을 유발하고, 소프트웨어를 테스트할 수 없게 만들고, 코드 재사용을 방해할 수 있으므로 모든 소프트웨어 시스템에서 피해야 합니다. 그러나 이는 게임 엔진과 같은 대규모 시스템의 경우 특히 그렇습니다.

게임 엔진에 있는 공통 모듈의 세부 정보 및 기능입니다. 일반적으로 상위 계층이 하위 계층에 의존하고 그 반대의 경우도 마찬가지인 계층형 아키텍처가 채택됩니다. 그렇지 않으면 바람직하지 않은 순환 종속성이 발생합니다. ("게임 엔진 아키텍처 제3판"에서 찍은 사진)

게임 엔진의 도구 모음을 만드는 방법에는 여러 가지가 있습니다. 그 중 일부는 독립 실행형 소프트웨어일 수도 있고, 일부는 런타임 엔진에서 사용하는 일부 하위 계층 위에 구축될 수도 있고, 일부는 게임 자체에 구축될 수도 있습니다. 예를 들어 Quake와 Unreal 기반 게임에는 모두 개발자가 게임을 실행하는 동안 디버깅 및 구성 명령을 입력할 수 있는 게임 내 콘솔이 있습니다.

위: 독립적인 도구 아키텍처; 하단: 게임 간에 공유되는 프레임워크 도구입니다.

게임 엔진 계층 다이어그램.

플랫폼 관련 모듈.

핵심 시스템 관련 모듈.

게임 로직과 관련된 모듈입니다.

게임 엔진과 관련된 다양한 관리자는 아래 그림에 나와 있습니다.

게임 엔진의 공통 부분을 식별하는 방법은 무엇입니까? 이를 살펴보는 한 가지 방법은 게임 엔진을 콘텐츠를 제외한 모든 것으로 정의하는 것입니다. 모든 게임 엔진의 공통 부분은 다음과 같습니다.

  • 메인 루프(또는 대체 구조)

  • 게임 데이터 파일을 처리하거나 코드로 작성된 게임 데이터에 연결하는 모듈

  • 데이터 파일에 의해 지정될 수 있지만 반드시 지정될 필요는 없는 게임 로직을 처리하는 모듈

  • 플레이어로부터 입력을 받는 모듈

  • 플레이어에게 출력을 제공하는 모듈

  • 네트워킹, 메뉴 핸들링 등의 보조 모듈

14.1.3 게임 엔진 목록 ​

현재 시장에 나와 있는 게임 엔진의 수는 수백 개에 달합니다. 현재 전 세계적으로 인기를 끌고 있는 상용 엔진도 있고, AAA 게임을 많이 개발한 게임회사 내부 엔진도 있고, 학습이나 연구용으로 사용되는 오픈소스 렌더러도 있고, 한때 유명했지만 지금은 역사에서 사라진 엔진도 있습니다. 몇 가지 일반적인 게임 엔진이 아래에 설명되어 있습니다.

14.1.3.1 언리얼 엔진 ​

**Unreal Engine(UE)**은 그래픽 렌더링과 개발 키트를 통합한 상용 엔진입니다. 수십 년간의 개발과 축적 끝에 Baiqing 경쟁에서 두각을 나타내며 실시간 렌더링 분야를 선도하는 글로벌 범용 상용 엔진이 되었습니다. 게임, 디자인, 시뮬레이션, 영화 및 TV, 교육, 의학 및 기타 산업에서 널리 사용됩니다. 게임 회사 Epic Games에서 왔으며 원래 Tim Sweeney가 이끌었습니다. 이 버전은 20년 넘게 사용되었으며 1990년대 중반 이후 여러 차례 주요 버전의 반복을 거쳤습니다.

Unreal Engine 2는 오늘날의 주류 PC, Microsoft의 Xbox 게임 콘솔 및 Sony의 PlayStation 2를 위한 완전한 게임 개발 프레임워크입니다. Unreal Engine 2X는 Epic의 자체 제작 게임 Unreal Championship 2: The Liandri Contribute의 놀라운 비주얼을 뒷받침하는 고도로 최적화된 엔진입니다.

Unreal Engine 3은 차세대 콘솔과 DirectX9 탑재 PC를 위한 완전한 게임 개발 프레임워크로, 최고의 게임 개발자에게 필요한 풍부한 핵심 기술, 콘텐츠 제작 도구 및 지원 인프라를 제공합니다. 언리얼 엔진 3는 모더들에게 매우 개방적이지만, UE3를 사용하여 게임을 퍼블리싱하고 판매하는 능력은 엔진 라이선스로 제한됩니다. 2009년 11월, Epic은 UDK(Unreal Development Kit)라는 UE3 SDK 무료 버전을 공개적으로 출시했습니다.

Unreal Engine 4는 이전 버전에 비해 크게 개선되어 전 세계적으로 인기 있는 게임 개발 엔진으로 자리매김했습니다. Unreal Engine은 게임, 시뮬레이션, 시각화 구축을 위한 완벽한 통합 도구 세트입니다. 그 기능에는 실시간 사실적 렌더링, 시각적 스크립팅, 실시간 레이 트레이싱, 완전한 게임 프레임워크, 전문 애니메이션 및 컷씬, 완전한 도구 체인 등이 포함되지만 이에 국한되지는 않습니다.

Unreal Engine 5는 2020년 5월 13일에 차세대 게임 콘솔 PlayStation 5 및 Xbox Series X/S를 포함한 모든 기존 시스템을 지원하는 미리보기 영상을 공개했습니다. 이 엔진의 연구 개발은 출시 약 2년 전부터 시작되었으며, Early Access 버전의 소스 코드는 2021년 중반에 공개되었으며, 2022년에 정식 출시될 예정입니다. 언리얼 엔진 5는 두 가지 핵심 기술을 사용합니다.

  • 나나이트: 매우 세밀한 사진 소스 자료를 게임으로 가져올 수 있는 고급 기술로, 게임 장면에서 복잡한 기하학을 처리하는 데 사용할 수 있습니다.

  • 루멘: 게임의 전역 조명 세부 사항을 해결하는 데 사용되며 하드웨어 레이 트레이싱에 의존하지 않습니다.

위부터 아래 순으로 언리얼 엔진 1, 언리얼 엔진 3, 언리얼 엔진 5의 에디터 인터페이스입니다.

라이트 맵을 기반으로 한 초기 Unreal 조명 효과.

업계 최고의 범용 상용 게임 엔진인 언리얼 엔진은 게임 업계에서 널리 사용되고 있으며 뛰어난 그래픽을 갖춘 수많은 유명 게임을 개발해 왔습니다.

Unreal Engine으로 개발된 게임 스크린샷입니다. 위에서 아래로 UE3의 Batman: Arkham City, UE4의 Final Fantasy 7 Remake, UE5의 Black Myth Wukong입니다.

UE5의 Nanite, Lumen 및 기타 기술의 지원으로 실시간 인터랙티브 게임은 영화 및 TV 수준의 이미지 품질을 향해 발전하고 있습니다. Epic에서 공식적으로 공개한 Matrix 데모 데모가 가장 좋은 예입니다(아래 그림).

Epic이 UE5를 사용하여 개발한 Matrix 인터랙티브 데모의 스크린샷입니다. 화질은 게임과 영화의 구분이 불가능할 정도로 영화에 가깝습니다.

게임 산업 외에도 언리얼 엔진은 영화 및 TV, 시뮬레이션, 디자인, 라디오 및 TV, 과학 시각화 및 기타 분야에서도 널리 사용되고 있으며 지원 도구 체인과 생태 커뮤니티를 점차 개선해 왔습니다.

UE는 훈련 목적으로 훈련 및 시뮬레이터에 사용됩니다.

14.1.3.2 유니티 ​

Unity는 Unity Technologies에서 개발하고 유지 관리합니다. 강력한 편집기와 가장 인기 있는 상용 엔진 중 하나를 갖춘 크로스 플랫폼 게임 엔진입니다. 프로젝트 내에서 개발자는 모바일 장치, 웹 브라우저, 데스크톱 및 콘솔에 대한 전달을 제어할 수 있습니다. 기능이 매우 풍부하고 Javascript 또는 C#을 사용하여 스크립트를 작성하고 대규모 커뮤니티 지원을 제공하며 크로스 플랫폼 개발에 매우 ​​적합합니다.

Unity의 첫 번째 버전(1.0.0)은 저렴한 게임 엔진을 만들고 아마추어 게임 개발자를 위한 전문 도구를 제공하는 동시에 게임 개발 산업을 "민주화"한다는 목표로 2005년 6월에 출시되었습니다. 세 가지 모두 Apple Final Cut Pro 제품의 간단한 작업 흐름, 간단한 자산 파이프라인 및 드래그 앤 드롭 인터페이스에서 영감을 받았습니다. 처음 출시되었을 때 Unity는 Mac OS X에서만 사용할 수 있었기 때문에 개발자는 자신의 창작물을 소수의 플랫폼에만 배포할 수 있었습니다. 현재 버전은 Windows 및 Mac OS X와 ​​같은 최소 12개의 대상 플랫폼을 지원할 수 있습니다.

이전 버전의 Unity(버전 0.2)의 스크린샷입니다.

초기 Unity 게임 Gooball(2005)의 스크린샷.

14.1.3.3 크라이엔진 ​

CryEngine 시리즈 엔진은 독일 게임 개발사인 Crytek이 설계한 게임 엔진으로 모든 CryTek 게임에 사용되었습니다. 초기 버전은 Far Cry에서 사용되었으며 해당 게임의 새로운 콘솔과 하드웨어를 지원하기 위해 계속 업데이트되고 있습니다.

CryEngine은 2004년에 1세대 엔진을 출시했으며 현재 버전 V까지 20년 이상의 개발 경험을 갖고 여러 주요 버전을 반복했습니다. Ubisoft는 Far Cry 시리즈의 이후 버전에 사용하기 위해 Dunia Engine이라고 하는 원래 Far Cry CryEngine의 크게 수정된 사내 버전을 유지 관리합니다.

CryEngine과 그 트윈 엔진의 개발 역사입니다.

CryEngine의 전체 가계도 및 게임 목록입니다.

CryEngine 1은 2004년 Far Cry의 기술 시연과 함께 처음 출시되었으며 Shader Model 3.0, HDR 조명 및 기타 그래픽 기능을 지원했습니다. 대표적인 게임으로는 Far Cry, Aion 등이 있습니다.

CryEngine용 장면 및 지형 편집기(2004).

CryEngine(2004)의 동적 조명 효과.

CryEngine의 수역, 보트 및 캐릭터에 대한 대화형 렌더링 효과 및 편집기(2004).

Far Cry 게임 스크린샷.

CryEngine 2는 2007년에 출시되었으며 HDR 조명, 실시간 환경 매핑, 체적 구름, 동적 수역(수면 및 수중), 뎁스 오브 필드(DoF), 모션 블러, 동적 부드러운 그림자, 모션 캡처 얼굴 애니메이션, 지하 산란, 대화형 및 파괴 가능한 환경, 대화형 식물, 로프 물리학 및 기타 기능을 지원합니다. 대표작으로는 크라이시스(Crysis), 크라이시스 워헤드(Crysis Warhead) 등이 있다.

크라이시스 게임 스크린샷.

CryEngine 3은 2009년에 출시되었습니다. 이전 세대 엔진과 비교하여 엔진은 DirectX 9 및 10을 지원합니다. 11로 개발되었으며 많은 새로운 고급 그래픽, 물리 및 애니메이션 기술과 많은 게임 개선 사항이 추가되었습니다. 예: 실시간 간접 조명을 위한 계단식 빛 전파 볼륨, 부드러운 입자, 멀티 코어 동시성, 지연 조명, 자연광 및 동적 부드러운 그림자, 안개 효과(볼륨, 레이어링 및 시야 거리), SSAO, 다목적 셰이더, 인간 눈 적응, HDR 조명, 모션 블러, DOF, 표면 아래 산란, 고품질 물, 동적 체적 빔 및 광축 효과, 흐름 환경, 멀티 코어 물리 엔진, 대화형 및 파괴 환경, 고속 텍스처 렌더링 등. 대표작으로는 크라이시스2 등이 있다.

CryEngine3의 렌더링 효과.

Nexuiz는 CryEngine3에서 개발한 슈팅 게임입니다.

CryEngine(3.6–4)은 2013년에 출시되었습니다. Crytek은 CryEngine(버전 3.6.0부터 시작)의 이름을 "CryEngine"으로 변경했으며 다음 CryEngine은 버전 번호로 광고되지 않을 것이라고 발표했으며 이 새로운 엔진은 이전 CryEngine 버전과 거의 유사하지 않다고 주장했습니다.

CryEngine이 렌더링한 넓은 숲.

CryEngine V(5)는 2016년 3월에 출시되었으며 CryEngine 5.4는 2017년 9월에 출시되었으며 Vulkan API 렌더러를 베타 버전으로 추가하고 물리 통합 및 새로운 C# 템플릿, 자산 시스템 업데이트 및 새로운 앤티앨리어싱 기술을 포함한 기타 기능을 추가했습니다. 렌더링 측면에서 CryEngine V는 다음 기능을 지원합니다.

  • 지역 조명

  • 물리 기반 렌더링(PBR)

  • 테셀레이션

  • 효율적인 안티앨리어싱

  • 실시간 지역 반사

  • 복셀 기반 전역 조명(SVOGI)

  • 화면 공간 방향 폐색(SSDO)

  • 그래픽 기반 조명(IBL)

  • 체적 안개 그림자

  • DirectX 12 지원

  • 실시간 동적 물 부식성

  • 3D HDR 렌즈 플레어

  • 모션 블러 및 뎁스 오브 필드(DoF)

  • 실시간 식생

  • 객체별 그림자 맵.

  • HDR 필름 톤매핑

  • 입자 특수 효과 시스템

  • 병렬 시차 매핑

CryEngine 5.3 편집기.

CryEngine V 샌드박스 편집기.

CryEngine V의 렌더링 렌더링.

14.1.3.4 파멸/퀘이크/ID 기술 ​

Quake 엔진 제품군은 Medal of Honor와 같은 최신 게임으로 확장되는 계보를 통해 많은 게임을 만드는 데 사용되며 Quake 및 Quake II 엔진 소스 코드는 무료로 제공됩니다.

2004년경에 Quake 3는 표준 FPS 게임 제어 시스템인 마우스 스킨과 키보드를 사용했습니다. 마우스를 움직이면 플레이어의 시선 방향이 변경됩니다. 마우스 버튼은 일반적으로 앞으로 걷고 사격하는 데 사용되었습니다. 키보드의 다양한 키는 웅크리기, 점프, 후진, 기총소사, 무기 전환에 사용되었습니다. 키 바인딩이라는 프로세스를 통해 키를 다양한 게임 내 기능에 다시 매핑할 수 있습니다. Quake 3는 클라이언트-서버(CS) 통신 모델을 사용하는 네트워크 지향 게임입니다.

Doom, Quake, Unreal 등의 엔진은 FPS 계열의 게임에 능숙하다는 공통점이 있습니다. 다음은 FPS 게임 및 엔진의 상세한 개발 이력 차트입니다.

그중 ID Tech 3는 소프트 래스터 렌더링 포기를 지원하며 실행하려면 OpenGL 호환 그래픽 가속기가 필요합니다. 엔진의 그래픽 개념은 많은 표면의 모양이 "셰이더 스크립트"라는 텍스트 파일로 정의되는 "셰이더"(현재 머티리얼) 시스템을 중심으로 집중되었습니다. 또한 스플라인 기반 표면, 곡선 버텍스 애니메이션, 하위 모델 기반 애니메이션 분리, 체적 안개, 미러링, 포털, 동적 그림자 및 파형 기반 버텍스 섭동도 지원됩니다.

14.1.3.5 오우거 ​

OGRE는 OpenGL 및 DirectX 렌더링을 지원하는 비교적 성숙한 오픈 소스 다중 플랫폼 3D 그래픽 엔진입니다. LGPL 라이센스에 따라 C 및 C++로 작성되었습니다. OO 기반 디자인을 가지고 있으며 로드 가능한 코드 모듈을 지원합니다. 또한 계층화된 장면 그래프, 기본 물리 기능을 제공하고 일반 위젯과 트루타입 글꼴을 지원하는 내장 2D GUI 시스템을 갖추고 있습니다. 2000년대에는 대규모의 활발한 개발자와 사용자 지원 커뮤니티가 있었습니다. 그러나 게임 엔진이 아니며 그래픽 렌더링만 처리하므로 네트워킹이나 오디오를 지원하지 않으며 타사 라이브러리의 도입이 필요합니다.

ORGE와 함께 제작한 대표적인 게임으로는 루닉게임즈(Runic Games)의 토치라이트(Torchlight)가 있다. Torchlight는 Diablo와 유사한 스타일과 게임플레이를 갖춘 롤플레잉 게임입니다. 2010년 Game Developers Choice Awards에서 최우수 데뷔상을 수상했으며 디지털 배포를 통해 Windows 및 Mac에서 사용할 수 있습니다.

ORGE에서 개발한 독립형 다크 게임인 Torchlight의 게임 스크린샷입니다.

저자는 토치라이트가 처음 출시되었을 때 우연히 국내 1위 게임사에 근무하게 되었고, 토치라이트의 멋진 그래픽과 스킬 이펙트, 독특한 게임플레이에 깊은 매력을 느꼈습니다. 그 당시에는 996이 없었고, 나는 매일 퇴근 후 많은 시간을 보내어 그 어두운 마법의 세계를 탐험하는 데 빠져들었습니다.

2000년대에는 많은 국내 게임회사와 팀들이 중국에서 등장하여 ORGE를 기반으로 한 자체 개발 엔진의 마법적인 개조와 2차 개발을 진행했습니다. 가장 성공적인 사례는 Changyou의 Tian Long Ba Bu였습니다. 진용의 고대 무협 소설을 각색한 온라인 게임입니다. 한때 인기가 있었고 오늘날에도 여전히 운영되고 있습니다. Ogre Golf를 포함하여 OGRE 2차 개발을 기반으로 하는 엔진이나 오픈 소스 라이브러리가 많이 있습니다. ORGE의 최신 개발 기능에는 확장 가능한 프레임워크, 멀티 플랫폼, 장면 관리자, 리소스 관리자, 재료, 그리드, 애니메이션, 렌더러, 특수 효과, 셰이더, 플러그인 등이 포함됩니다.

14.1.3.6 게임브리오 ​

Gamebryo는 Emergent Game Technologies에서 개발하고 유지 관리합니다. 크로스 플랫폼 3D 게임 엔진입니다. 대표적인 게임으로는 Fallout 3(Bethesda), Civilization Revolution(Firaxis), Warhammer Online(EA Mythic) 등이 있습니다.

Gamebryo 엔진은 이전에는 NetImmerse로 알려졌습니다. NetImmerse의 개발은 몇 가지 설계 목표에 따라 진행되었으며, 그 중 가장 중요한 것은 속도였습니다. 이로 인해 개발자는 엔진 전체에서 간단한 기술을 사용하고 장면 그래프 데이터 구조에 크게 기반을 두어 플레이어에게 보이지 않는 게임 개체 컬링과 같은 다양한 성능 향상 기술을 허용했습니다.

다른 디자인 목표는 표준 그래픽 및 오디오 인터페이스와의 호환성을 제공하고 높은 수준의 프로그래밍 인터페이스를 제공하는 것이었습니다. 엔진 개발자들은 목표가 달성되었다고 주장하며, 엔진을 만들면서 얻은 결과 중 하나는 "고수준 프로그래밍 인터페이스에서는 성능 희생이 필요하지 않다"는 것입니다. 엔진은 개발자가 개발 비용을 줄일 수 있도록 높은 수준의 인터페이스를 제공하는 것이 중요하며, 엔진은 다양한 유형의 게임에 최적화되어야 합니다.

Gamebryo Lightspeed는 광범위한 게임 작업을 보유하고 있으며 신속한 애플리케이션 확장 프레임워크를 제공합니다. 또한, 분리된 아키텍처 설계를 통해 게임 팀을 쉽게 확장할 수 있습니다. Gamebryo는 사운드, 그래픽, 물리 및 멀티플레이어 게임을 처리하기 위한 다양한 기술과 게임플레이를 지원합니다. 시각적 충실도가 높으며 광대한 풍경과 복잡한 얼굴 세부 정보가 포함된 게임을 만드는 데 사용되었습니다. 또한 미국 정부 및 군사 프로젝트 개발은 물론 소방 및 수술 시뮬레이션에도 사용되었습니다.

14.1.3.7 빅월드 ​

BigWorld(Wargaming Sydney라고도 함)는 John De Margheriti가 2002년에 설립한 호주 회사로 대규모 멀티플레이어 온라인 게임(MMO) 및 가상 세계를 만들기 위한 미들웨어 개발 도구 제품군을 개발하고 라이선스를 부여합니다. MMO 시장을 위해 이러한 미들웨어 플랫폼을 개발한 최초의 회사입니다. 2007년에 BigWorld는 영국의 Development 매거진에 의해 업계 리더로 인정받았습니다. 2012년 8월 7일, Wargaming은 BigWorld 미들웨어 회사를 4,500만 달러에 인수했습니다.

BigWorld Technology는 게임 개발자가 MMO 및 온라인 게임을 구축하는 데 필요한 기본 소프트웨어 아키텍처를 제공합니다. 3D 클라이언트 기술은 Windows PC 및 브라우저용으로 구축되었으며 웹 API를 통해 iOS, Xbox 360 및 PlayStation 3에서 사용할 수 있습니다. 백엔드 서버 솔루션은 Python API 스크립팅 환경을 사용하여 Linux에서 구현됩니다. 도구 모음에는 콘텐츠 생성 도구, 서버 모니터링 도구 및 지원이 포함됩니다. BigWorld Technology는 또한 Umbra(폐쇄 컬링), Scaleform(사용자 인터페이스 생성), Speedtree(잎) 및 Vivox(VOIP)와 같은 다양한 타사 플러그인을 통합합니다.

주요 게임 걸작으로는 World of Tanks 시리즈, Tianxia 시리즈 등이 있습니다.

14.1.3.8 토크3D ​

초기 Torque3D 엔진에는 여러 버전이 있었으며 이에 대한 설명은 다음과 같습니다.

  • Torque Game Engine 1.0: 아틀라스 지형 생성 편집기, Torque GFX 그래픽 레이어, 사용자 정의 텍스처 재료, 최신 장면 그래프 및 배치 렌더링 엔진을 갖춘 TGE 1.5의 모든 기능에 더해.

  • Torque Game Engine 1.4: 이 이전 버전의 Torque는 여전히 3D 도구 세트, 지형 엔진, 네트워크 엔진 및 기타 기능을 갖추고 있습니다. Tribes 2에 사용된 기술을 기반으로 합니다.

  • Torque Game Engine 1.5: 통합 Torque Lighting Suite, ShowTool Pro, 추가 아트 자산 등을 갖춘 1.4.2의 주요 업그레이드입니다.

2010년 이전에는 인기 있는 게임 엔진이었지만, 이후 점차 쇠퇴하여 사람들의 시야에서 사라졌습니다.

토크 엔진 리버 에디터.

토크 지형 편집기.

토크 엔진 렌더링 효과.

14.1.3.9 소스 엔진 ​

소스 엔진은 Valve Software에서 개발하여 수상 경력이 있는 3D 게임 엔진입니다. 1994년에 처음 출시된 이 엔진은 Havok 엔진을 사용한 사실적인 시뮬레이션 물리학, 높은 동적 범위 조명을 포함한 DirectX 9.0 지원, 골격 애니메이션, 사운드 시스템 및 기타 여러 기능을 지원하는 시장에서 가장 진보된 게임 엔진 중 하나로 간주됩니다. 이는 성공적이고 잘 알려진 게임 Half-Life 2의 기반이 되는 엔진입니다.

Source 엔진에는 Half-Life 2 게임 소유자에게 무료로 제공되는 게임 모드를 구축하는 데 사용할 수 있는 Source SDK가 함께 제공되며 Half-Life 2 시리즈, Day of Failure 소스, Counter-Strike 소스, Portal 및 Team Fortress 2를 포함한 향후 게임을 만드는 데 사용되는 Valve의 자체 도구에 대한 액세스를 제공합니다. 또한 Ritual 제작자를 포함한 많은 독립 개발자가 사용합니다.

2010년경의 Source 엔진은 다음과 같은 기능을 사용하여 계산적이거나 렌더링 집약적인 게임을 렌더링하기 위해 빠르고 안정적이며 유연한 기술을 적용했습니다.

  • Direct3D(Windows 95 이상, Xbox 및 Xbox 360에서 렌더링).

  • OpenGL(Mac OS X 및 PS3에서 렌더링됨)

  • HDR(High Dynamic Range), HDR은 Half-Life 2의 싱글 플레이어 게임이 아닌 Half-Life의 Lost Coast에만 도입되었습니다.

  • 자동 립싱크 생성 기능을 갖춘 얼굴 애니메이션 시스템.

  • 게임을 수정하고 싶은 분들을 위한 소스코드입니다.

  • 하이브리드 골격 애니메이션 시스템.

  • 캐릭터가 다양한 셰이더에서 어떻게 보이는지 확인할 수 있는 모델 뷰어입니다.

  • 범프 맵, 텍스처 등을 배치하기 위한 머티리얼 시스템

소스 엔진 아키텍처 및 기능.

소스 엔진을 사용한 Vindictus 게임 스크린샷.

14.1.3.10 동상 ​

Frostbite는 EA Digital Illusions CE(DICE)에서 개발한 자체 게임 엔진입니다. Windows, PS 시리즈 및 Xbox 시리즈 X/S 시리즈에서 크로스 플랫폼 사용을 위해 설계되었습니다. 게임 엔진은 원래 Battlefield 게임 시리즈에 사용되었지만 이후 다른 1인칭 슈팅 비디오 게임 및 기타 다양한 장르로 확장되었습니다. Frostbite는 항상 Electronic Arts에서 출시한 게임에만 독점적으로 사용되었습니다. 현재까지 세 가지 주요 버전이 출시되었습니다. 대표 게임으로는 배틀필드 시리즈, FIFA 시리즈, 니드포스피드 시리즈, 플랜츠 vs. 좀비 시리즈, 스타워즈 시리즈 등이 있다.

Frostbite로 개발된 게임의 일부 스크린샷입니다. 위에서 아래로: Need for Speed ​​​​Heat, Battlefield 2042, Star Wars: Squadrons.

Frostbite는 DICE의 내부 엔진으로 외부에 출시되거나 승인되지는 않지만 Frostbite의 R&D 구성원은 Siggraph, GDC 등 국제 기술 서밋에서 활발히 활동하고 서밋에서 최신 렌더링 기술과 연구 결과를 자주 공유하며 게임 업계에서 잘 알려져 있습니다. Frostbite가 공개적으로 공유한 기술 기사 목록은 EA 기술 블로그에서 확인할 수 있습니다.

14.1.3.11 모루 ​

Ubisoft Anvil(2009년까지는 Scimitar, 2020년까지는 AnvilNext로 불림)은 Ubisoft Montreal에서 제작하고 2007년 게임 Assassin's Creed에 사용된 게임 엔진입니다. 여기에는 Scimitar, Anvil, AnvilNext, AnvilNext2.0 및 Ubisoft Anvil과 같은 분기가 포함됩니다. 이 엔진은 Microsoft Windows, Nintendo Switch, PlayStation 3, PlayStation 4, PlayStation 5, PlayStation Vita, Wii U, Xbox 360, Xbox One, Xbox Series X/S 및 Stadia에서 사용됩니다. 콘솔 게임 Assassin's Creed용으로 특별히 제작된 이 제품은 나중에 Assassin's Creed 시리즈, Tom Clancy's Ghost Recon 및 기타 게임에서 사용되었습니다.

Ubisoft 앤빌 아이콘.

추가된 기능에는 주야간 주기, 향상된 그리기 거리, Far Cry 2와 동일한 나뭇잎 기술, 향상된 조명, 반사 및 특수 효과, 새로운 옷감 시스템, 새로운 AI 및 NPC 네비게이션 시스템.

AnvilNext는 새로운 천공계를 사용하여 고정된 천공기법을 사용하여 IV중에서 자체적으로 개발했습니다.。회 ，렌더링(Render)로써 효율 지원 외부포스트 프로세스，로써 렌더링(Render)3000개 의 color。 마지막으로 AnvilNext는 Far Cry 4의 기술을 추가하여 보다 역동적인 샌드박스 환경과 새로운 물 기술을 지원합니다. 여기서 게임 세계는 플레이어의 행동과 진행 상황에 따라 시간이 지남에 따라 바뀔 수 있습니다. 또한 Assassin's Creed Unity를 시작으로 AnvilNext는 특정 디자인 규칙과 템플릿을 따르면서 유연하고 자동화된 방식으로 구조를 생성할 수 있어 예술가와 디자이너가 복잡한 도시 환경을 만드는 데 필요한 시간과 노동력을 줄여줍니다. AnvilNext는 AI를 사용하는 것이 불가능합니다.

렌더링을 위해 엔진은 사전 베이킹된 전역 조명, 반사 매핑, 체적 안개, 동적 날씨, 동적 나뭇잎 등은 물론 물리 기반 렌더링(PBR)도 지원하여 재료, 개체 및 표면이 조명, 그림자 및 음영 처리를 보다 현실적으로 보고 반응할 수 있도록 합니다. 또한, 체적 기술이 추가되면서 전역 조명 시스템이 더욱 현실감 넘치고, 물리 기반 객체가 더욱 현실적으로 반응하며, 의상이 주인공, 환경 및 기타 캐릭터에 대해 더욱 현실적으로 동작합니다. 이제 세계는 더 큰 땅, 더 많은 물체, 더 큰 건물, 로딩 화면 없이 접근 가능한 건물 내부 및 시각적 충실도, 몰입도 및 게임 플레이를 향상시키는 기타 많은 추가 기능을 지원합니다.

대표작으로는 For Honor, Tom Clancy's Rainbow 등이 있습니다.

Assassin's Creed Valhalla의 전투 장면 스크린샷.

14.1.3.12 데스티니 엔진 ​

Destiny 엔진은 게임 회사 Bungie가 개발한 게임 엔진으로 자체 Destiny 시리즈 게임을 개발하는 데 사용됩니다.

2013년에는 지식, 게임 엔진, 다양한 환경 및 임무를 포함하여 데스티니의 기반 작업 대부분이 완료되었습니다.

Destiny 1 게임은 대부분의 Halo 게임에서 사용되는 엔진을 기반으로 하는 Tiger Engine이라는 새로운 게임 엔진을 사용하며 전역 조명과 실시간 동적 조명을 동시에 실행할 수 있습니다. 또한 Bungie는 Destiny가 Xbox One 및 PlayStation 4에서 기본적으로 1080p로 그래픽을 렌더링하는 것을 목표로 하고 있습니다. Bungie의 "Funnel" 기술 혁신은 Halo 매치메이킹 시스템의 중추로서 더 나은 플레이어 페어링을 통해 협력 또는 경쟁 멀티 플레이어 모드에서 보다 자연스러운 경험을 만들 수 있습니다. 그러나 번지 개발자들은 새로운 엔진이 게임의 온라인 특성에 적합하지 않다고 비판했습니다. 엔진의 리소스 집약적 특성으로 인해 지도에 사소한 변경이라도 밤새 렌더링 및 컴파일 프로세스가 필요합니다. 새로운 지도와 임무를 개발하는 것은 "힘든 일"입니다.

또한 Destiny의 멀티스레드 병렬 기술이 완벽하게 사용되어 장면 렌더링의 모든 단계에 도입되었습니다.

데스티니 엔진의 장면 렌더링 병렬화 범례.

데스티니 가디언즈 게임 스크린샷.

14.1.3.13 RE 엔진 ​

RE Engine(전체 이름: Reach for the Moon Engine)은 Capcom에서 만든 비디오 게임 엔진입니다. 원래 Resident Evil 7: Biohazard용으로 설계되었지만 나중에 Devil May Cry 5 및 Monster Hunter Rise와 같은 회사의 다양한 게임에 사용되었습니다. 이 엔진은 Capcom의 이전 엔진인 MT Framework의 후속 엔진입니다.

RE 엔진은 새로운 앤티앨리어싱 및 체적 조명 기능을 포함하여 MT 프레임워크에 대한 다양한 개선 사항을 제공합니다. 또한 이 엔진을 사용하면 개발자는 사진 측량을 사용하여 이전 버전에 비해 향상된 VR 지원을 포함하여 멀미를 방지하는 데 필요한 높은 프레임 속도를 달성할 수 있고, 모듈식 리깅, 모션 매칭, 절차적 애니메이션 및 모션 리디렉션과 같이 애니메이션을 더 빠르게 만드는 도구 지원, 보다 사실적인 잔해를 허용하는 다양한 새로운 물리 시뮬레이션 옵션을 포함하여 더 높은 품질의 자산을 만들 수 있습니다.

대표작으로는 레지던트 이블 시리즈, 몬스터헌터, 귀신과 도깨비의 부활 등이 있습니다.

레지던트 이블 빌리지 게임 장면 스크린샷.

14.1.3.14 레드엔진 ​

RedEngine은 CD Projekt에서 개발하고 유지 관리합니다. 주로 3A급 콘솔 게임의 연구 개발을 목표로 하고 있습니다. 이름은 거의 알려지지 않았지만, 개발한 게임은 잘 알려져 있습니다. 대표적인 게임으로는 더 위쳐 시스템(The Witcher System), 사이버펑크 2077(Cyberpunk 2077) 등이 있다.

사이버펑크 2077 게임 스크린샷.

14.1.3.15 분노 ​

RAGE는 Rockstar Advanced Game Engine의 약자이며 Rockstar Games의 Rockstar San Diego 스튜디오 사업부인 RAGE Technology Group에서 개발한 독점 게임 엔진입니다. Rockstar Games의 사내 스튜디오는 2006년 Xbox 360 및 Wii용으로 출시된 첫 번째 게임인 Rockstar Games Presents Table Tennis 이후 이 엔진을 사용해 콘솔과 컴퓨터용 최첨단 오픈 월드 게임을 개발해 왔습니다.

초기 RAGE 기능에는 캐릭터 애니메이션 엔진, 물리 엔진, 대규모 스트리밍 세계 처리 기능, 복잡한 AI 배열, 날씨 효과, 빠른 네트워크 코드 및 다양한 게임 스타일, DirectX 11 지원 및 PC용 입체 3D 렌더링은 물론 더욱 강력한 그리기 거리, 텍스처 필터링, 향상된 그림자 매핑 및 테셀레이션 품질이 포함됩니다.

2018년 Red Dead Redemption 2 출시와 함께 RAGE는 물리 기반 렌더링, 볼륨 클라우드 및 안개 값, 미리 계산된 전역 조명, Windows 버전의 Vulkan 렌더러에 대한 지원을 통해 더욱 향상될 것입니다. 또한 고급 AI와 향상된 게임 물리학 및 애니메이션, HDR 렌더링 및 DLSS(Deep Learning Super Sampling) 지원을 생성할 수 있습니다.

대표적인 게임으로는 Red Dead Redemption 시리즈, Grand Theft Auto 시리즈 등이 있습니다.

Red Dead Redemption 2 게임 스크린샷.

14.1.3.16 PhyreEngine ​

PhyreEngine은 무료로 사용할 수 있는 라이센스만 부여된 Sony의 게임 엔진으로 PlayStation 시리즈 플랫폼, Windows(OpenGL, DirectX 11), Android 및 iOS와 호환됩니다.

PhyreEngine은 자체 유연한 사용 라이선스에 따라 제공되는 전체 소스 코드와 Windows 도구를 포함하는 설치 가능한 패키지 형태로 Sony 라이선스 사용자에게 독점적으로 배포되므로 모든 PlayStation 게임 개발자, 게시자, 도구 및 미들웨어 회사가 모든 플랫폼에서 PhyreEngine의 일부 또는 전부를 기반으로 소프트웨어를 만들 수 있습니다. 이 엔진은 PS3 유닛 브로드밴드 엔진의 코프로세서 유닛(SPU)에 최적화된 정교한 병렬 처리 기술을 사용하지만, 다른 멀티 코어 아키텍처로 쉽게 이식 가능합니다.

낮은 수준의 PS3 LibGCM 라이브러리 외에도 PhyreEngine은 OpenGL 및 Direct3D도 지원하여 Havok, PhysX, Bullet 및 기타 물리 엔진에 대한 지원을 포함하여 모든 기능을 갖춘 "게임 템플릿"을 소스 코드로 제공합니다.

PhyreEngine은 여러 게임 스튜디오에서 채택되었으며 200개 이상의 게시된 게임에서 사용되었습니다. 대표적인 게임으로는 파이널 판타지 시리즈, 영웅전설 시리즈 등이 있습니다.

14.1.3.17 이르리히트 ​

Irrlicht 엔진은 OpenGL, DirectX 또는 소프트웨어를 사용하여 렌더링할 수 있으며 Windows 및 Linux에서 실행됩니다. 기술적으로 Irrlicht는 장면 관리를 위해 계층적 장면 그래프를 사용하고 기본적인 2D GUI 기능을 갖추고 있습니다.

Irrlicht는 당시의 다른 엔진보다 규모가 작고 주요 개발자가 한 명뿐이었지만 당시에는 대규모 팬 지원 커뮤니티가 있었습니다. 또한 기본적인 물리 루틴을 제공하지만 네트워킹 기능이 부족합니다. 또한 Irrlicht는 다른 소프트웨어에 비해 그래픽 품질과 렌더링 속도가 떨어지는 것으로 알려져 있으며, 개발 용이성으로 상쇄되며 종종 이상적인 초보자용 엔진으로 간주됩니다.

Irrlicht 엔진 렌더링 화면의 스크린샷.

14.1.3.18 XNA ​

Microsoft의 XNA Game Studio는 플레이어가 자신만의 게임을 만들고 온라인 게임 커뮤니티와 공유하도록 장려하기 위해 설계된 사용하기 쉽고 접근성이 뛰어난 게임 개발 플랫폼입니다.

XNA는 C# 및 CLR(공용 언어 런타임)을 기반으로 합니다. 기본 개발 환경은 Visual Studio 또는 소스 코드부터 게임 자산까지 모든 것이 관리되는 무료 Visual Studio Express입니다. XNA를 사용하면 개발자는 PC, Xbox 360 콘솔용 게임을 만들 수 있습니다. Microsoft는 본질적으로 비용이 전혀 들지 않는 훌륭한 도구를 제공함으로써 일반 사람들이 새로운 게임을 만들 수 있도록 수문을 여는 일을 훌륭하게 해냈습니다.

XNA(2019)에서 개발한 Barotrauma 게임 스크린샷.

14.1.3.19 기타 엔진 ​

2004년경 FPS 장르에는 세 가지 주요 게임 엔진 제품군이 있었으며 각각은 서로 다른 개발자로 구성되었습니다. id Software의 Doom 3 및 Quake 3 엔진, Valve Software의 Half Life 및 Half Life 2 엔진, Unreal Tournament(UT) 및 Epic Games의 Unreal Tournament 2004(UT2004) 엔진입니다.

Doom 3, Half-Life 2 및 UT2004는 모든 개발자의 최신 세대를 대표했으며 당시 사용 가능한 최고의 게임 엔진이었습니다. Quake 3, UT 및 Half Life는 이전 세대 엔진입니다. Half Life 엔진은 Quake 및 Quake 2 엔진을 기반으로 한다는 점에 유의해야 합니다.

이러한 엔진은 모두 완벽한 기능을 갖추고 있으며, 더 기본적인 기능을 제공하는 위의 오픈 소스 엔진 대부분과 달리 각 엔진을 기반으로 하는 하나 이상의 완전한 게임이 존재합니다. 플레이 가능한 게임을 만들기 위해 오픈 소스 엔진을 다른 라이브러리 및 툴킷과 결합해야 하는 경우가 많습니다. Quake 3는 다른 엔진과 달리 개발자가 크게 수정할 수 있다는 점에서 특별히 언급할 가치가 있습니다. 언급해야 할 또 다른 엔진은 GarageGames의 Torque입니다. 저렴한 상업용 엔진입니다.

또한 Cocos2d 시리즈, Panda 3D, OpenSceneGraph, Delta3D, Blender Game Engine, GameMaker, Godot, bgfx, Unigine, Delta3D 등과 같은 엔진 또는 렌더러가 있습니다.

Blender Game Engine 편집기 및 렌더링 렌더링.

다음은 기타 엔진 기능에 대한 설명입니다.

다음 표는 일부 게임 엔진에 대한 설명입니다.

이름 회사 허가 대표작 비고

4A 엔진 4A 게임 헌신적인 메트로 2033, 메트로: 라스트 라이트, 메트로 엑소더스

A-프레임(VR) 구글 MIT

  • 오픈 소스 엔터티 구성 요소 시스템 WebVR 프레임워크

알라모 암각화 게임 헌신적인 스타워즈

모루 유비소프트 헌신적인 어쌔신 크리드, 톰 클랜시의 레인보우 식스

빅월드 빅월드 테크놀로지 헌신적인 탱크의 세계, 세계

블렌더 게임 엔진 블렌더 스튜디오 GPL-2.0+ 요 프랭키!, 신텔 더 게임 2D/3D 게임 엔진은 3D 모델에 패키지되어 있으며 총알 물리 라이브러리를 통합합니다.

Cocos2d 다중 MIT 지오메트리 대시 국내는 Cocos2d-x/3d 엔진입니다.

창조 엔진 베데스다 게임 스튜디오 헌신적인 엘더스크롤, 폴아웃

크라이엔진 크라이텍 헌신적인 크라이시스, 파 크라이

다크 엔진 유리공방 헌신적인 도둑: 다크 프로젝트, 시스템 쇼크 2, 도둑 II: 메탈 시대 고급 AI 및 사운드 기능(소리 전파를 완벽하게 제어)

데시마 게릴라 게임 헌신적인 데스 스트랜딩, 호라이즌 제로 던, 킬존: 섀도우 폴, 새벽까지, 새벽까지: 블러드 러시

두니아 엔진 유비소프트 헌신적인 디비전 크라이엔진 기반

자아 코드마스터 헌신적인 F1 시리즈 주로 레이싱 게임에 사용

에센스 엔진 유물 엔터테인먼트 헌신적인 에이지 오브 엠파이어 4, 워해머, 컴퍼니 오브 히어로즈 3

폭스 엔진 코나미 헌신적인 라이브 축구

동상 유비소프트 주사위 헌신적인 배틀필드, FIFA, 스타워즈

게임브리오 게임베이스 헌신적인 공각기동대: 인디펜던스 컴플렉스, 메이플스토리 2

게임메이커 스튜디오 요요 게임 헌신적인 경찰 이야기, 죽음의 계략

빙하 아이오아이 헌신적인 Hitman 시리즈, Freedom Fighters, Mini Ninjas, Kane 및 Lynch 시리즈

고도 아르헨티나 MIT Cruel Squad, Hardcoded, Dump Kingdom, Keen in Keen Dreams 3.0+에는 모듈 및 GDNative를 통해 C# 스크립팅 및 기타 언어, PBR 및 전역 조명이 추가됩니다.

히어로엔진 시뮤트로닉스 헌신적인 스타워즈: 구 공화국

id Tech 아이디소프트웨어 헌신적인 Doom, Quake, Fury, Wolfenstein: The New Order, Wolfenstein: The Old Blood, The Evil Within Doom과 Quake에서 개발된 초기 버전은 부분적으로 오픈 소스였습니다.

이를리히트 니콜라우스 게브하르트 zlib 마인테스트

IW 엔진 인피니티 워드 헌신적인 콜 오브 듀티 시리즈 원래 id Tech 3를 기반으로 제작되었습니다.

제이드 유비소프트 헌신적인 Rayman Mini, Space Junkies, Tom Clancy's Ghost Recon Breakpoint

키네티카 소니 헌신적인 전쟁의 신

모노게임/XNA 마이크로소프트 마이크로소프트 퍼블릭 쇼군의 해골, 테라리아, 바스티온, 타워폴, 트랜지스터, 페즈, 액시엄 엣지

오디세이 엔진 바이오웨어 헌신적인 스타워즈: 구공화국 기사단, 스타워즈: 구공화국 기사단 II: 시스 군주

오우거

  • MIT 토치라이트 켄시

OGRE-다음

  • MIT
  • OGRE의 차세대 엔진

팬더3D

  • BSD 카툰 시티 온라인, 캐리비안의 해적 온라인

파이어엔진 소니 전용, 무료 영웅전설: 환상에 돌입하다, 스카이: 빛의 아이들

실제 가상 보헤미아 GPL-2.0+ ARMA 2, ARMA 3, 데이Z

레드엔진 CD 프로젝트 헌신적인 더 위쳐 2: 킹 오브 어새신즈, 더 위쳐 3: 와일드 헌트, 사이버펑크 2077

분노 레이지 테크 헌신적인 Red Dead Redemption 1 및 2, Grand Theft Auto

RPG 메이커 아스키 헌신적인 마녀의 집, 캐즘에서 탈출하다

세이지 웨스트우드 스튜디오, EA 헌신적인 반지의 제왕 시리즈, 커맨드 앤 컨커 시리즈

시바 시바 테크놀로지스 헌신적인 페르시아의 왕자 2: 그림자와 불

사일런트 스톰 엔진 니발 인터랙티브 헌신적인 침묵의 폭풍, 야간 감시, 망치와 낫, 주간 감시 턴제 전술 게임의 경우

출처 밸브 헌신적인 Half-Life 2, Counter-Strike: Source, Left 4 Dead, Portal, Team Fortress 2, Dota 2, Laboratory, Artifact, Half-Life: Alyx Source 2를 사용한 최초의 게임인 Dota 2는 원래 Source 엔진에서 포팅되었습니다. The Lab의 미니 게임 중 하나인 Robot Repair는 Source 2 엔진을 사용하고 나머지 7개는 Unity의 엔진을 사용합니다.

토시 푸른 혀 헌신적인 쥬라기 공원: 제네시스, 니켈로디언, 리베라의 모험, 마블 슈퍼 히어로 스쿼드

토크3D 차고 게임 MIT 마블 블래스트 골드, 트라이브스 2, 블록랜드 멀티플레이어 네트워킹 코드, 원활한 실내 및 실외 렌더링 엔진, 골격 애니메이션, 드래그 앤 드롭 GUI 생성, 내장 월드 편집기, C와 유사한 스크립팅 언어가 포함됩니다.

UbiArt 프레임워크 유비소프트 몽펠리에 헌신적인 레이맨 오리진, 레이맨 레전드, 빛의 차일드, 발리언트 하츠: 워

유니진 유니진 헌신적인 듀얼 유니버스 대규모 개방형 장면에 중점: 64비트 정밀 좌표, 지리적 좌표 지원, 둥근 지구 모델, 주로 기업 및 전문 시뮬레이터에 사용됩니다.

유니티 유니티 기술 헌신적인 스카이 블레이드, 원신 임팩트, 파이널 판타지, 왕의 영광, 하스스톤

언리얼 엔진 에픽게임즈 헌신적인 피스 엘리트, 흑신화 오공, 배트맨, 파이널 판타지 리메이크 UnrealScript가 UE4에서 제거되었습니다.

위의 엔진은 일부에 불과합니다. 자세한 내용은 게임 엔진 목록을 참조하세요.

14.1.4 게임 엔진의 간략한 역사 ​

컴퓨터 게임은 1962년의 우주 전쟁부터 21세기 최대 미디어 중 하나로 자리매김할 때까지 많은 발전을 이루었으며, 총 수익 측면에서 영화 산업을 능가하기도 했습니다. 기술적으로 컴퓨터 게임은 다른 컴퓨터 프로그램과 마찬가지로 소스 코드 모듈로 구성됩니다. 누군가는 게임 엔진을 게임 콘텐츠, 즉 행동이나 환경과 분리된 모듈식 부분으로 정의합니다. 자동차의 엔진과 마찬가지로 게임 엔진은 게임의 기술적인 핵심이며, 게임의 콘텐츠는 그 위에 구축됩니다.

"게임 동작(게임 로직)이나 게임 환경(레벨 데이터)을 직접 지정하지 않는 시뮬레이션 코드 모듈의 모음"으로 정의되는 게임 엔진의 정확한 의미에 대해 약간의 혼란이 있습니다. 엔진 모듈 내에는 게임 세계의 입력 처리, 출력(3D, 2D 및 사운드), 일반 물리 및 역학이 있습니다. 게임 엔진은 입력, 오디오, 그래픽, 역학, 이벤트 루프 등 게임의 실제 콘텐츠에 영향을 주지 않는 모듈 역할을 합니다.

소프트웨어 구성 요소를 설계하고 개발하는 것은 비용과 시간이 많이 소요되는 프로세스이므로 게임 개발자는 자체 엔진을 개발하는 것보다 기성 엔진에 투자하는 것이 재정적으로 더 나은 경우가 많습니다. 고품질 부품을 재사용하면 전체 제품의 전반적인 품질도 향상됩니다. 새로운 소프트웨어를 구축하려면 필연적으로 "바퀴 재발명"이 필요하며, 이전에 만든 소프트웨어에 비해 코드 중복이 85%나 높은 것으로 추정됩니다.

실제로 게임 엔진은 특정 게임의 콘텐츠 스타일에 맞춰 조정되는 경우가 많아 다양한 스타일의 게임에서 엔진의 재사용성을 저해합니다. 대부분의 엔진은 특정 플랫폼에서 특정 게임을 실행하도록 설계되었으며, 엔진이 일반화될수록 특정 플랫폼에서 특정 게임을 실행하는 데 최적화가 덜 됩니다. 보다 일반적으로 재사용 가능한 소프트웨어 구성 요소를 만드는 데는 일회용 구성 요소를 만드는 것보다 3배 더 많은 노력이 필요합니다. 따라서 기존 게임 엔진을 재사용하는 데는 상당한 가치가 있지만, 모든 사람이 자신만의 재사용 가능한 엔진을 구축하거나 모든 게임 엔진을 재사용할 수 있는(또는 게임의 나머지 부분과 분리하는 것조차) 것은 타당하지 않습니다.

1980년대 이전에는 게임 엔진이 없었기 때문에 각 게임은 바퀴를 다시 만들어야 했고 사용된 특정 하드웨어에 맞게 제작되어야 했습니다. 여러 퍼블리싱 플랫폼은 게임을 처음부터 다시 작성하는 것을 의미했으며, 이는 게임 개발 팀에게 여러 번의 반복적인 작업을 의미했습니다.

1980년대에는 Pinball Construction Set(Bill Budge)를 예로 들며 게임 엔진의 전신 컨셉이 등장하여 30만 장 이상 판매되었습니다.

핀볼 구성 세트 게임 화면(1982).

Pinball Construction Set은 IDE, 명령줄 인터페이스, 스프라이트 편집기, 모델 편집기, 지도/장면 편집기 등을 포함한 게임 구성 시스템 등 새로운 유형의 제품을 정의합니다.

1990년대에는 게임 제작 시스템이 사실상 게임 엔진이었습니다. 게임 엔진이라는 용어가 공식적으로 나타나기 시작했으며, id Software에서 소개하고 FPS 게임 Wolfenstein 3D(Wolfenstein 3D)에서 선보였습니다. 엔진 이름은 Fast 3D Engine(실제로는 2.5D)이었습니다.

초기 게임 엔진이 겪은 3단계.

이후 id Software는 게임 엔진 Doom 및 Quake 시리즈의 공식 버전을 출시했습니다. Doom 엔진의 기능에는 텍스처 매핑, 비직교 벽, 빛 감쇠/광원, 가변 높이 바닥 및 천장, 환경 애니메이션 및 변형, 팔레트 전환, 멀티 플레이어 등이 포함됩니다. Quake 엔진은 속도를 높이기 위해 3D 복잡성을 줄이고, 조명 및 그림자(라이트 맵)를 사전 계산하고, 속도를 높이기 위해 맵을 분할하고, 빠른 렌더링, 렌더링 순서, 하드웨어 3D 가속, 온라인 게임 등을 지원합니다.

원래 Quake 엔진의 최소 시스템 요구 사항 및 렌더링 그래픽.

이후 1999년에 Quake 엔진이 GPL로 출시되었으며, 이로 인해 거대한 Quake 엔진 제품군이 탄생했습니다. (아래 사진)

id Tech 엔진 가계도.

스타독 게임 엔진 개발 내역입니다.

1990년대부터 현재까지 게임 엔진은 30년 넘게 빠른 속도로 발전해 왔습니다. 그들은 여러 세대의 고전적인 기술과 아키텍처를 파생시켰으며 많은 범용 엔진과 내부 엔진이 등장했습니다. 이는 수많은 게임 개발팀과 회사에 도움이 되었고 친숙한 게임 작품도 많이 만들어냈습니다.

1990년대의 게임 엔진은 여전히 ​​혼란스럽고 초기 단계에 있었습니다. 많은 게임 개발 팀에서는 아직 게임 엔진을 사용하지 않았습니다. 그들은 기본 및 공통 모듈을 부분적으로만 추상화하고 다양한 프로젝트 간에 복사했습니다. 이 모델은 확장성, 유지 관리성 및 사용 편의성은 물론이고 낮은 수준에서도 재사용됩니다.

게임 엔진의 도움이 없었고 게임 기술과 하드웨어의 한계가 결합되어 당시의 게임 그래픽은 제한된 색상 비트 깊이, 심각한 픽셀 부족, 완전한 입자성 등으로 극도로 거칠었습니다. (아래 사진)

위: 파괴 공작원 II(1989); 중간: 제논 2(1990); 하단: 페르시아의 왕자 2(1995).

1990년대에는 ID의 Doom, Quake 시리즈 엔진과 Epic의 Unreal 엔진이 등장하기 시작했습니다. 많은 공통 기능 모듈, 눈길을 끄는 게임 그래픽, 비교적 사용하기 쉬운 편집기 등이 당시 주류 게임 엔진으로 자리 잡았습니다. (아래 사진)

1990년대 Doom, Quake 및 Unreal 엔진의 게임 그래픽.

초기 게임 엔진 편집기 인터페이스.

2000년경에 Quake와 Unreal 엔진이 3세대로 발전했습니다. 일부 게임 엔진 개발에 대한 설명과 타임라인은 다음과 같습니다.

Doom, Quake 및 Unreal 엔진의 더 자세한 타임라인은 다음과 같습니다.

점점 더 많은 핵심 엔진 모듈이 있으며, 특히 엔진 렌더링, 파티클 및 기타 효과가 개선되어 게임이 더욱 멋집니다.

누리엔엠스타온라인은 UE3로 개발된 뮤직게임으로 2008년 출시되었습니다.

그 후 몇 년 동안 비가 내린 후 버섯처럼 다양한 게임 엔진이 생겨났습니다. 기존의 Quake, Unreal, CryEngine 외에도 Torque, BigWorld, Gamebro, Irrlicht, OGRE 등의 엔진도 탄생하여 바칭전쟁의 서막을 촉발시켰습니다. 이런 추세는 중국에도 확산됐다. 거의 모든 게임회사에는 자체 개발 엔진이나 외국 엔진의 2차 개조 작업을 수행하는 엔진팀이 있습니다. 당시 많은 엔진 프로그래머들은 개인용 게임 엔진을 갖는 꿈을 갖고 있었습니다.

게임 품질 요구 사항이 증가함에 따라 엔진 기술 및 도구 체인에 대한 요구 사항도 점점 더 높아지고 있습니다. 기술적인 기반이 취약한 많은 팀들은 점차 수요를 충족시키지 못하고 패배하며 역사의 무대에서 사라져가고 있습니다. 점차적으로 강력한 기술력을 갖춘 소수의 베테랑 게임 엔진이 지배적인 위치를 형성했고, 엔진의 세계는 그들에 의해 분열되고 지배되었습니다.

그중 떠오르는 것은 유니티(Unity) 엔진으로, 컴팩트함과 크로스 플랫폼, 단순성과 사용 편의성으로 유명해 모바일 게임과 웹 게임에 널리 사용되고 있다. Unity는 Entity-Component의 씬 객체 구조를 핵심으로 사용하여 씬 노드 관리를 단순화하고 확장성을 개선하며 과거 상속 기반 유형의 폭발적인 성장을 방지합니다. 이후 Entity-Component를 기반으로 ECS(Entity-Component-System)로 발전했습니다.

Unity의 GameObject-Component 모드.

Unreal 상속 및 Entity, Component 조합 모드.

게임 객체들은 다양한 방식으로 서로 연관되어 있으며, 이러한 관계를 설명하는 다이어그램을 그릴 수 있습니다. 이러한 다이어그램은 이벤트 배포 채널 역할을 할 수 있습니다.

ECS와 함께 인스턴스, 구성 요소 및 시스템을 명확하게 구분하고 각각의 임무를 수행하기 위해 객체 지향 설계(OOD)에서 데이터 지향 설계(DOD)로 전환됩니다. 특정 구성 요소 집합을 가진 엔터티에 적합한 코드 형성 시스템은 SoA(Structure-of-Arrays)의 데이터 레이아웃과 결합되어 선형 순회를 사용하여 메모리 액세스 효율성과 캐시 적중률을 향상시켜 효율성을 향상시킵니다.

메모리 레이아웃의 OOD와 DOD의 차이점.

SOA 메모리 레이아웃 다이어그램.

기능이 향상되고 기술이 발전함에 따라 최신 엔진은 도구 모음과 런타임 구성 요소로 구성됩니다. 엔진 아키텍처에서 하드웨어는 계층화된 설계를 기반으로 고급 애플리케이션으로 확장되어 재사용과 테스트 가능성을 극대화하기 위해 순환 종속성을 피합니다.

게임 엔진 아키텍처 다이어그램. 게임 관련 하위 시스템, 핵심 시스템, 리소스 관리자, 렌더링 엔진, 프런트 엔드, 플랫폼 추상화, 하위 수준 구성 요소, 타사 라이브러리 및 기타 레이어를 포함하는 계층형 모델이 채택됩니다.

렌더링과 밀접한 관련이 있는 위의 레이어 또는 모듈은 렌더링 엔진으로, 이는 낮은 수준의 렌더러, 장면 그래프 관리, 시각 효과, 프런트 엔드 및 기타 수준으로 구분됩니다.

저수준 렌더러는 가시성, 그래픽 장치 관련 인터페이스(그래픽 장치 액세스 및 열거, GD 초기화, 버퍼 설정 등), 기하학적 프리미티브 표현, 카메라 인터페이스 추상화, 재료 시스템, 동적 조명 시스템, 텍스트 및 글꼴 등에 관계없이 가능한 한 빠르고 풍부하게 프리미티브를 렌더링하는 데 중점을 둡니다.

저수준 렌더러에 대한 모듈 세부정보입니다.

장면 그래프는 렌더링을 위해 제출된 기본 요소의 수를 제한하고 프러스텀 컬링(표시 화면 외부의 항목을 제거)을 사용하며 공간 분할 구조(BSP, 쿼드트리, 옥트리, kd-트리)를 사용합니다.

장면 그래프의 모듈 세부정보입니다.

씬 그래프의 예.

시각 효과에는 입자 시스템, 데칼 시스템, 조명 매핑, 동적 그림자, 전체 화면 포스트 프로세스 및 기타 모듈이 포함됩니다.

프런트 엔드에는 HUD, 메뉴, 캐릭터 조작을 위한 GUI, 컷씬을 위한 풀 모션 비디오 등이 포함됩니다.

또한 DCC 도구 및 자산의 데이터 흐름은 아래 그림에 나와 있습니다.

대규모 게임의 경우, 관련된 자산이 매우 크고, 많은 양의 데이터를 저장하고 관리할 수 있는 방법이 필요합니다. 일부 회사에서는 관계형 데이터베이스(MySQL 또는 Oracle)를 사용하고 일부 회사에서는 버전 제어 소프트웨어(SVN, Perforce 또는 GIT)를 사용하며 일부 회사에서는 맞춤형 소프트웨어를 사용합니다. 예를 들어 Naughty Dog는 Builder라는 사용자 정의 GUI를 사용합니다.

독립적이고 통합된 방법의 도구 아키텍처 다이어그램.

또한 다양한 목적(자산 관리, 일정 관리, 오류 관리)을 위한 웹 기반 도구도 포함되어 있습니다. 이 도구는 구축하기 쉽고 종종 독립 실행형 애플리케이션보다 구축하기 쉽고 강제로 다시 설치하지 않고도 쉽게 업데이트할 수 있으며 표 형식의 데이터만 표시하고 표가 필요한 경우 웹 인터페이스를 사용합니다.

Integrating Architecture Soar 워크숍에서는 다양한 엔진의 아키텍처 설계와 기술 스택 연구를 통합하는 방법에 대해 논의했습니다. (하단 사진)

네트워크 기술의 발전으로 게임 엔진의 네트워크 모듈의 성능이 향상되어 대규모 멀티플레이어 온라인 게임이 번창하고 놀라운 성과를 거둘 수 있게 되었습니다. 가장 대표적인 예가 그룹 카피의 일일 운영을 개척한 블리자드의 월드 오브 워크래프트(World of Warcraft)이다. (아래 사진)

사진은 월드 오브 워크래프트 게임의 대규모 이벤트를 보여주며, 수천 명의 플레이어가 같은 장소에서 실시간으로 소통하고 교류하는 모습입니다.

2010년경에는 모바일 장치 지능화 추세가 뚜렷했습니다. iOS 모바일 시스템과 iPhone 4 하드웨어 장치는 전 세계적으로 널리 인기를 끌었습니다. 이때부터 모바일 기기 지능화의 역사적 과정이 시작되었습니다. 스마트 모바일 기기의 주요 기능인 게임은 자연스럽게 국내외 게임 제조사들의 타깃이 되면서 모두 모바일 게임 개발로 전환하고 있다.

2008년부터 2012년까지의 게임 점유율 전설, 모바일 게임의 비중이 해마다 증가하고 있습니다.

2017년 모바일 게임 비중은 29%입니다.

유니티는 작지만 세련된 대표주자로서 모바일 측의 사업 기회를 예리하게 인식하고 있기 때문에 이미 PC에 존재하는 많은 오래된 게임 엔진과의 경쟁을 피하고 모바일 측의 연구 개발에 집중하고 있습니다.

Unity는 2012년부터 이미 모바일 개발을 지원합니다.

동시에 단일 코어 CPU 무어의 법칙이 점차 한계점에 가까워지면서 CPU 제조업체는 멀티 코어 방향으로 발전하고 있습니다. 따라서 게임 엔진도 멀티 코어 병렬화 개발에 적응하고 있습니다.

1970년부터 2014년까지의 CPU 코어, 주파수, 성능 및 트랜지스터 동향 차트.

동시 엔진 아키텍처 수준. 위에서 아래로 엔진 시스템 계층, 커널 계층, 프레임워크 계층, 운영 체제 계층으로 구분됩니다.

동시 엔진의 루프 단계에 대한 개략도.

또한, 성능에 매우 민감한 모바일 기기의 특성상 병렬화 역시 그 트렌드 중 하나입니다. 모바일 장치의 다중 CPU 코어의 이점은 모바일 측의 다중 코어 CPU 기술이 SMU 및 ARM 아키텍처 CPU와 NV의 Tegra 2 GPU에서 병렬 작업을 공동으로 완료하여 성능을 최대화하고 전력을 절약할 수 있는 방법을 설명합니다.

듀얼 코어 ARM Cortex A9 MPcore 아키텍처.

듀얼 코어 CPU의 전압 및 주파수 확장 이점.

멀티코어 장치를 사용하면 주류 게임 엔진이 멀티스레딩을 최대한 활용하고 많은 병렬 작업을 완료할 수 있습니다. 다음 그림은 일부 게임 엔진의 스레드 수를 보여줍니다.

아래 그림은 Dungeon Defender 게임이 NVIDIA Tegra 프로세서의 두 코어를 사용하는 것을 보여줍니다.

같은 시기의 Frostbite는 기본 하드웨어 플랫폼이 제공하는 만큼의 스레드를 사용할 수 있는 기능과 함께 작업 기반 병렬성을 사용하는 게임 엔진의 또 다른 예였습니다. 엔진은 GPU에서 주요 게임 및 렌더링 작업을 수행하고 기타 시스템 관련 작업을 작업으로 나눕니다. 각 작업에는 일반적으로 15,000~200,000줄의 C++ 코드가 포함되며, 평균 작업 크기는 약 25,000줄의 코드입니다. 이들 중 대부분은 독립적으로 작동하는 반면, 멀티스레딩을 사용하는 일부 게임은 서로 종속된 두 개의 CPU 코어를 사용합니다. 게임의 각 프레임에는 일반적으로 200~300개의 작업이 포함되며 엔진은 사용 가능한 모든 하드웨어 코어에 작업을 배포합니다.

Frostbite 엔진의 작업 수준 병렬 처리.

위 그래프의 각 색상은 Frostbite가 시작한 작업을 나타냅니다. 데이터는 AFR 모드의 쿼드 코어 CPU와 2개의 GPU가 있는 PC 시스템에서 Frostbite Timing View 소프트웨어를 사용하여 수집되었습니다. 게임 엔진이 작업 처리를 위해 사용 가능한 모든 코어를 효과적으로 사용한다는 것을 그래프에서 쉽게 알 수 있습니다. 결과적으로 이러한 게임 엔진은 두 개의 NVIDIA Tegra CPU 코어와 ULP GeForce GPU 코어를 효과적으로 활용하고 비교할 수 없는 콘솔 스타일 게임 경험을 제공할 수 있습니다. 이 병렬 기술은 Battlefield: Bad Company와 같은 게임에서 성공적으로 사용되었습니다.

멀티 코어를 활성화하면 Quake 엔진의 프레임 속도를 1.6배 이상 높일 수 있으며, Dungeon Defender 게임의 프레임 속도를 2배 이상 높일 수 있습니다. (아래 사진)

렌더링 기술 측면에서는 블리자드의 네이티 호프만(Naty Hoffman), 디즈니의 브렌트 벌리(Brent Burly), 에픽게임즈의 브라이언 카리스(Brian Karis) 등 업계 연구진이 실시간 렌더링에 PBR 기술을 적용하는 시도에 앞장섰다.

PBR에 관련된 연설 중 일부는 다음과 같습니다.

Naty Hoffman: 영화 및 게임 제작을 위한 물리적 기반 셰이딩 모델

Brent Burly: Disney의 물리적 기반 셰이딩

Brian Karis: 언리얼 엔진 4의 실제 셰이딩

다음은 주류 엔진이 PBR을 지원하는 일정입니다.

  • Unreal Engine 4: "Unreal Engine 4의 실제 셰이딩", SIGGRAPH 2013

  • Unity 5: "Unity의 물리적 기반 셰이딩", GDC 2014

  • Frostbite: Frostbite를 PBR로 이동, SIGGRAPH 2014

  • Cry Engine 3.6: "Cry Engine의 물리적 기반 셰이딩", 2015

그 후, PBR 기술은 점차 주류 렌더링 엔진에서 대중화되었으며 실시간 인터랙티브 게임의 표준 기술 및 표준 워크플로우가 되었습니다.

위부터 아래로: Naty Hoffman의 인기 있는 PBR 기술, Disney 원칙의 PBR 매개변수화된 미리보기, UE4의 PBR 효과.

2015년경 현대화를 기반으로 한 차세대 그래픽 API가 등장했는데, 대표적인 것이 Vulkan과 DirectX 12입니다. 이들의 공통적인 특징은 많은 제어 권한을 드라이버에서 애플리케이션 계층으로 이전한다는 것입니다. 구체적으로 새로운 그래픽 AP의 기능은 다음과 같습니다.

  • 다중 스레드 명령 버퍼 로깅을 허용합니다.

  • 런타임/드라이버 작업 부하를 줄입니다.

  • 런타임 검증을 줄입니다.

  • 작업을 초기화/로딩 시간으로 이동합니다(예: 파이프라인 설정).

  • 하드웨어에 대한 보다 명확한 제어.

  • 편의사양을 줄입니다.

  • 메모리를 정확하게 관리하세요.

DX12의 리소스 관리 범례.

이러한 변경으로 인해 게임 엔진은 궁극적인 렌더링 최적화를 달성하기 위해 그래픽 API를 제어할 수 있는 더 많은 기회를 제공합니다. 병렬 명령 기록, 멀티스레드 렌더링, 정밀한 메모리 관리, 풀 프레임 최적화(프레임 그래픽이라고도 함) 기반 렌더링 등의 기술이 탄생했습니다.

Frostbite 엔진은 프레임 그래프를 사용하여 디퍼드 렌더링 시퀀스 및 종속성 그래프를 구현합니다.

렌더링 품질을 추구하는 베테랑 게임 엔진인 UE는 2018년에 원래 시장 구조를 바꾸었습니다. Steam 플랫폼에 따르면 약 25%의 게임이 이를 사용하여 제작되며, 단숨에 Unity를 제치고 1위 자리를 확고히 차지했습니다. (아래 사진)

Steam에 출시된 게임에 사용된 게임 엔진(2018-12-20 데이터).

또한 최신 그래픽 API 및 GPU 렌더링 파이프라인의 발전으로 GPU 기반 렌더링 파이프라인, 클러스터 기반 렌더링, 레이 트레이싱, 실시간 전역 조명 등과 같이 이전에 제한되었던 일부 렌더링 기술이 번창할 수 있게 되었습니다.

GPU 기반 렌더링 파이프라인 개요.

래스터라이제이션, 컴퓨팅 셰이더 및 레이 트레이싱을 위한 하이브리드 렌더링 파이프라인.

Surfel 전역 조명을 기반으로 한 표면 시각화입니다.

위 기술의 강력한 지원으로 현재 게임은 영화 및 TV 수준의 화질에 도달했습니다. 가장 눈에 띄는 것은 UE5의 Nanite 및 Lumen 기술을 사용하여 개발된 "Matrix" 데모와 게임 과학 "Black Myth: Wukong"입니다.

최근 몇 년 동안 그래픽 API 표준은 인공 지능을 지원했습니다. Nvidia는 RTX 시리즈 GPU 칩에 Tensor Core를 통합하는 데 앞장섰습니다. 이에 따라 레이 트레이싱 노이즈 감소, DLSS, 지능형 NPC AI, 스타일라이즈드 렌더링 등 그래픽 렌더링과 게임 엔진에도 딥러닝 기반 인공지능 기술이 널리 도입되고 있다.

DLSS 끔(왼쪽)과 켠(오른쪽) 비교, 프레임 속도가 71% 증가했습니다.

일부 AAA 게임의 DLSS 가속 비율 차트입니다.

또한, PC, 콘솔 등 기존 실시간 렌더링 플랫폼 외에도 모바일, XR, 웹, 클라우드 렌더링 등의 분야에서도 큰 발전을 이루었습니다.

2018년 VR, 모바일 및 기타 플랫폼을 지원하는 주류 비즈니스 엔진 표.

2020년 모바일 시장 점유율은 미화 770억 달러에 이르렀으며, 새로운 왕관의 안개에도 불구하고 여전히 추세를 거스르며 전년 대비 13.3% 성장했습니다.

그 중에서도 XR 기기는 일반 모바일 기기에 비해 대역폭, 전력, 성능에 더 민감하기 때문에 포비티드 렌더링, 멀티뷰 렌더링, 가변 쉐이딩 레이트, 보간, 예측, 타임워핑, 멀티스레딩 등의 최적화 기술이 탄생했습니다.

VR과 같은 렌더링을 최적화하는 데 사용되는 MultiView 비교 차트입니다. 위: MultiView 모드 없이 렌더링, 두 눈 각각 그리기 지침을 제출합니다. 중간: 기본 MultiView 모드, 제출 지침을 재사용하고 GPU 레이어에 추가 명령 목록을 복사합니다. 하단: DC, 명령 목록 및 형상 정보를 재사용할 수 있는 고급 MultiView 모드.

Arm은 UE에서 포비티드 렌더링을 위해 4뷰 멀티뷰를 사용하므로 렌더링 작업량을 65% 줄일 수 있습니다.

14.1.5 콘텐츠 요약 ​

이 기사는 시간을 주요 내용으로 삼아 여러 부분으로 나눕니다.

  • 신흥기(1999년 이전)

  • 성장기(2000~2009)

  • 개화시기(2010~2015)

  • 결과기간(2016~2021)

콘텐츠는 주로 게임 엔진의 아키텍처 및 렌더링 부분을 중심으로 진행되지만 이에 국한되지는 않습니다. 또한 저자가 주목할 가치가 있다고 생각하는 관련 모듈이나 콘텐츠도 포함됩니다.

14.2 신흥 기간(1999년 이전) ​

게임 엔진은 1990년대 중반, 특히 Doom(아래)과 Quake 게임으로 대중화되었던 1인칭 슈팅 게임(FPS)과 같은 3D 게임과 관련하여 시작되었습니다. 다른 개발자들은 처음부터 작업하는 대신 소프트웨어의 핵심 부분에 대한 라이선스를 받고 자신만의 그래픽, 캐릭터, 무기 및 레벨을 디자인했습니다.

왼쪽: Doom 게임 스크린샷; 오른쪽: Doom 3 게임 스크린샷.

게임 엔진이라는 용어는 1990년대에 처음 사용되었지만 Sierra의 AGI 및 SCI 시스템, LucasArts의 SCUMM 시스템, Incentive Software의 Freescape 엔진과 같이 게임 엔진으로 간주되는 1980년대의 일부 오래된 시스템도 있었습니다. 그러나 대부분의 최신 게임 엔진과 달리 이러한 게임 엔진은 타사 제품에 사용된 적이 없습니다. Quake III Arena 및 Epic Games의 1998 Unreal과 같은 최신 게임은 엔진과 콘텐츠가 별도로 개발되는 방식을 염두에 두고 설계되었습니다. 최소한 재사용 가능한 엔진을 사용하면 게임 속편을 더 빠르고 쉽게 개발할 수 있으며 이는 경쟁이 치열한 컴퓨터 게임 산업에서 귀중한 이점입니다.

왼쪽: Unreal의 Skaarj 캐릭터 스크린샷; 오른쪽: Unreal 3의 Berserker 캐릭터 스크린샷.

PC 게임 개발 초기에 가장 간단한 게임 루프는 다음과 같았습니다. (Windows 개발을 공부한 학생들이라면 접해봤을 겁니다.)

cpp
// 루프
MSG kMsg;
while ( TRUE )
{
    // 처리(Process)
    if ( PeekMessage(&kMsg,(HWND)0,0,0,PM_REMOVE) )
    {
        if ( kMsg.message == WM_QUIT )
            break;
        HACCEL hAccel = (HACCEL)0;
        if ( !TranslateAccelerator(hWnd,hAccel,&kMsg) )
        {
            TranslateMessage(&kMsg);
            DispatchMessage(&kMsg);
        }
    }
    else // 루프
    {
        // 드로우/렌더(Draw)호출(Call)
        Draw();
    }
}

위의 Draw 함수 그리기 프로세스(예: OpenGL)의 가장 간단한 구현은 다음과 같습니다.

cpp
void Draw()
{
    // 버퍼 컬러
    glClear(GL_COLOR_BUFFER_BIT);
    // 설정(Set)렌더링(Render)상태
    glDisable(GL_CULL_FACE);
    // 설정(Set)모델 까지 의 변환(Transform)
    glMatrixMode(GL_MODELVIEW);
    glPushMatrix();
    glMultMatrixf(gs_afMatrix);
    // 드로우/렌더(Draw)
    glBegin(GL_POLYGON);
    glColor3f(gs_afColor0[0],gs_afColor0[1],gs_afColor0[2]);
    glVertex3f(gs_afVertex0[0],gs_afVertex0[1],gs_afVertex0[2]);
    glColor3f(gs_afColor1[0],gs_afColor1[1],gs_afColor1[2]);
    glVertex3f(gs_afVertex1[0],gs_afVertex1[1],gs_afVertex1[2]);
    glColor3f(gs_afColor2[0],gs_afColor2[1],gs_afColor2[2]);
    glVertex3f(gs_afVertex2[0],gs_afVertex2[1],gs_afVertex2[2]);
    glEnd();
    // 복구 의 변환(Transform)
    glMatrixMode(GL_MODELVIEW);
    glPopMatrix();
    // 버퍼 ，버퍼 까지 버퍼
    SwapBuffers(gs_hWindowDC);
}

물론 위의 내용은 Hello World와 같은 장면을 그리는 등의 간단한 경우에만 해당할 수 있습니다. 복잡한 장면의 경우 더 많은 기술을 도입하고 더 많은 호출을 추가하여 더 복잡한 게임 메인 루프를 형성해야 합니다. 다음 그림은 3D Game Engine Architecture에서 언급한 장면 노드의 상호 작용 다이어그램입니다.

공간 클래스, 노드 클래스, 기하학 클래스 및 렌더링 클래스 간의 상호 관계.

당시 장면의 노드 구성 구조는 주로 상속을 기반으로 했으며(Entity-Component 및 ECS는 아직 등장하지 않음) 개체의 데이터 구조는 Entity를 노드로 사용했습니다.

초기 게임 장면의 엔터티 노드 구조 범례.

게임 초반 장면의 엔터티 노드 구조 그림 2.

시간이 지남에 따라 다양한 최신 렌더링 기술과 하드웨어 발전(예: 텍스처 매핑, 앤티앨리어싱, 픽셀 및 버텍스 셰이딩, 향상된 그림자 생성, 증가된 메모리 대역폭, 증가된 채우기 속도 등)으로 인해 게임 환경이 더욱 현실감 있게 만들어졌으며 더욱 복잡하고 화려해졌습니다. (아래 사진)

시대에 맞춰 id가 개발한 게임의 진화 모습을 담은 그림입니다. 왼쪽 위에서 오른쪽 아래로 Wolfenstein 3D(1991), DOOM(1994), Quake(1996), Quake 3(1999), DOOM 3(2004)입니다. 화질의 향상은 육안으로도 확인할 수 있습니다.

객체와 광원의 수가 증가함에 따라 렌더링 기술은 점점 더 복잡해지고 효율성을 높이기 위해서는 렌더링 상태의 복잡한 관리가 필요합니다. 다음 그림은 3D Game Engine Architecture에서 설명하는 렌더링 상태 업데이트 기술입니다.

렌더링 상태 상황을 업데이트 중입니다. 게임 엔진은 트리 구조를 통해 종속성과 렌더링 상태를 쉽게 수집할 수 있습니다.

조명 측면에서 이 시기의 게임은 조명 효과를 얻기 위해 다중 텍스처를 사용하는 경우가 많았습니다. (아래 사진)

어둡고 밝은 이미지를 위한 다양한 텍스처. 왼쪽 위: 나무의 메인 텍스처, 오른쪽 위: 메인 텍스처와 결합된 보조 텍스처, 왼쪽 아래: 어두운 이미지, 가운데 아래: 하드 오버레이를 사용한 밝은 이미지, 오른쪽 아래: 소프트 오버레이를 사용한 밝은 이미지.

CryEngine1은 태양 그림자에 대한 그림자 맵과 객체별 그림자를 제공합니다. 성능을 향상시키기 위해 식물 그림자가 미리 계산되지만 메모리는 매우 흐릿한 텍스처로 제한됩니다. 고급 하드웨어 구성의 경우 CryEngine1은 식생에 대한 그림자 맵을 추가하지만 이를 사전 계산된 솔루션과 결합하는 것은 여전히 ​​문제가 있습니다.

CryEngine1은 더 간단하고 효율적인 솔루션을 위해 포인트 라이트에 스텐실 그림자를 사용합니다. CPU 스키닝을 사용하면 CPU에서 그림자 윤곽선을 추출한 다음 GPU에서 템플릿 그림자를 렌더링할 수 있습니다. 분명히 이 기술은 CPU 스키닝에 의존하고, 추가 CPU 계산이 필요하고, GPU에 업로드하고, 에지 데이터 구조를 위한 추가 메모리가 필요하고, 예측 가능한 성능 특성이 거의 없기 때문에 더 자세한 개체를 렌더링하려는 경우 문제가 됩니다. 이 기술은 알파 블렌딩이나 테스트된 그림자 캐스터에 대한 지원이 부족하기 때문에 야자수(아래)에서도 작동하지 않습니다.

Far Cry 게임 스크린샷은 미리 계산된 부드러운 그림자와 실시간 그림자를 결합한 솔루션을 사용합니다.

이 단계에서 메쉬의 LOD 기술이 탄생했습니다. 다음 그림은 동일한 메시의 두 LOD에 대한 삼각형의 모양과 개수를 보여줍니다.

더 넓은 시야각, LOD 전환, 특수 텍스처 필터링(예: 이중선형, 이방성) 및 안개 효과를 통해 지형 렌더링도 구체화되기 시작했습니다.

이 단계에서는 입자 특수 효과와 멀리 있는 물체의 시뮬레이션에 사용되는 빌보드 기술도 등장했습니다.

14.2.1 그래픽 API ​

14.2.1.1 다이렉트X ​

DirectX는 Microsoft에서 맞춤화한 그래픽 API 표준입니다. 오늘날 가장 인기 있는 주류 그래픽 API 표준 중 하나입니다. 이는 Microsoft 플랫폼에서 멀티미디어 관련 작업, 특히 게임 프로그래밍 및 비디오를 처리하는 데 전념하는 API(응용 프로그래밍 인터페이스) 세트입니다. 처음에 이러한 API의 이름은 Direct3D, DirectDraw, DirectMusic, DirectPlay, DirectSound 등과 같이 모두 "Direct"로 시작했습니다. DirectX라는 이름은 이러한 모든 API의 약어로 만들어졌으며(X는 특정 API 이름을 나타냄) 곧 컬렉션의 이름이 되었습니다.

버전에 따라 변경되는 DirectX 아이콘.

Microsoft는 1995년에 DirectX 1.0을 처음 출시한 이후 거의 1년에 한 번 출시 비율을 유지해 왔습니다. 1999년 현재 DirectX 7.0으로 개발되었다. 1996년에 Microsoft는 DirectX 2와 3의 두 가지 주요 버전을 출시했습니다. 또한 특별한 이유로 DirectX 4는 공개적으로 출시된 적이 없습니다. (아래 사진)

DirectX 3.0 그래픽 기능에는 하드웨어 수준 가속 비트맵, 표면 및 선 그리기, 높은 비트맵 색상 심도 지원, MMX를 지원하는 래스터라이저가 포함됩니다.

DirectX 3.0으로 개발된 게임의 스크린샷.

DirectX 5.0의 그래픽 기능에는 다각형 정보를 하드웨어에 직접 전송하는 새로운 DrawPrimitive 인터페이스, 절차적 메시 및 향상된 애니메이션, 정렬 독립적 앤티앨리어싱, 범위 기반 안개, 이방성 텍스처 필터링, 버퍼 없는 숨겨진 표면 제거 등이 포함됩니다.

그래프 TD A(스티플 테스트) --> B(Z-버퍼) B --> C(단일 텍스처에서 텍셀을 가져옵니다. 최종 텍스처 색상으로 필터링합니다.) C --> D(텍스처 블렌드) D --> E(반사광 추가) E --> F(안개 적용) F --> G(알파 블렌드) G --> H(프레임 버퍼에 쓰기)

DirectX 5.0 고정 렌더링 파이프라인.

DirectX 5.0으로 개발된 게임의 스크린샷입니다.

DirectX 6.0의 그래픽 기능에는 더 빠른 성능, 더 나은 조명 및 변형을 위한 더 나은 지오메트리 엔진, 하드웨어 3D 가속기를 사용하는 사용자를 위한 더 빠른 소프트웨어 래스터라이저, 멀티 텍스처링, 범프 매핑, 텍스처 압축, 스텐실 버퍼 및 W 버퍼 지원이 포함됩니다.

DirectX 6.0 큐브 환경 매핑 효과.

DirectX 6.0으로 개발된 게임의 스크린샷.

DirectX 7.0의 그래픽 기능에는 다중 텍스처(라이트 맵과 같은 두 개 이상의 텍스처 맵 결합), 큐빅 환경 맵, 하드웨어 변환 및 조명, 버텍스 블렌딩(GPU 뼈 스키닝) 등이 포함됩니다.

DirectX 7 라이트맵 효과.

DirectX 7 큐브 환경 맵 효과.

DirectX 7의 버텍스 블렌딩(GPU 뼈 스키닝) 효과. 이미지의 왼쪽에는 버텍스 블렌딩이 없고, 이미지의 오른쪽에는 버텍스 블렌딩이 활성화되어 있습니다.

14.2.1.2 OpenGL ​

**OpenGL(Open Graphics Library)**은 플랫폼 독립적인 2D 및 3D 시각화 사양 표준입니다. 1992년 Silicon Graphics Inc에 의해 출시되었습니다. ARB(Architectural Review Board) 연합이 개발을 담당합니다. 주요 소프트웨어 및 하드웨어 제조업체(ATI, NVIDIA, Intel, Microsoft 등)가 회원으로 구성되어 있습니다. 2006년에는 크로노스 그룹(Khronos Group)이 공동으로 개발을 인수했습니다. OpenGL의 특징 중 하나는 느린 개발입니다. 표준화는 그래픽 집약적인 응용 프로그램 개발자를 크게 방해하는 느린 프로세스이기 때문입니다.

1999년 이전에 OpenGL이 출시한 버전과 기능은 다음 표에 나와 있습니다.

버전 시간 특징

1.0 1992년 6월 확장을 지원하는 일련의 기본 기능

1.1 1997년 3월 텍스처 객체, 버텍스 어레이

1.2 1998년 3월 3D 텍스처, BGRA 및 압축 픽셀 형식, 이미징 하위 집합

1.2.1 1998년 10월 ARB 확장 개념 추가

OpenGL 개발 확장 키트 GLFW는 데스크탑에서 OpenGL, OpenGL ES 및 Vulkan 개발을 위한 오픈 소스 다중 플랫폼 라이브러리입니다. 창, 컨텍스트 및 표면을 생성하고 입력 및 이벤트를 수신하기 위한 간단한 API를 제공합니다. 다음과 같은 특징이 있습니다.

  • OpenGL, OpenGL ES, Vulkan 및 관련 옵션, 플래그 및 확장을 지원합니다.

  • 폴링이나 콜백을 통해 키보드, 마우스, 게임패드, 시간 및 창 이벤트 입력을 지원합니다.

  • 다중 창, 다중 모니터, 높은 DPI 및 감마 매핑을 지원합니다.

  • 기존 애플리케이션에 쉽게 통합할 수 있습니다.

두 개의 함수 호출만으로 창과 OpenGL 컨텍스트를 제공합니다.

  • 튜토리얼, 가이드, 참조 문서, 예제 및 테스트 프로그램이 함께 제공됩니다.

  • 커뮤니티는 다양한 언어에 대한 바인딩을 유지했습니다.

  • C언어로 작성되었습니다.

Windows, OS X 및 많은 Unix 계열 시스템(Linux, FreeBSD)을 기본적으로 지원합니다.

  • OSI 인증 라이센스가 있는 오픈 소스로 상업적 사용이 가능합니다.

네이티브 개체 및 플랫폼별 기능에 액세스하기 위한 컴파일 시간 옵션입니다.

GLFW 외에도 GLEW, GLUT, gl3w, Glad 등과 같은 확장 라이브러리도 있습니다. 자세한 목록은 OpenGL 관련 툴킷 및 API를 참조하세요.

14.2.2 하드웨어 아키텍처 ​

1995년 Nvidia는 100만 개의 트랜지스터를 탑재하고 16비트 컬러, 최근접점 필터링, 50,000개의 삼각형, 100만 픽셀 및 초당 픽셀을 처리하는 성능을 갖춘 NV1 그래픽 카드를 출시했습니다.

1996년 3dfx사는 최초의 3D 가속 카드(4MB RAM, 50Mhz)인 Voodoo 1세대 GPU를 출시했으며, 3D 시각화만 지원하고 추가 2D 비디오 카드가 필요하여 시장에서 큰 성공을 거두었습니다. 아이디어는 2D 변환이 인기 있는 Matrox 비디오 카드와 같은 빠른 2D 그래픽 카드에 의해 수행되는 반면 3D 변환은 Voodoo 카드에 의해 수행된다는 것입니다. Voodoo의 하드웨어는 소프트웨어 렌더링보다 더 빠른 계산이 가능합니다.

일반적인 Voodoo 그래픽 PCI 확장 카드에는 DAC, 프레임 버퍼 프로세서, 텍스처 매핑 장치, 4MB의 EDO DRAM이 포함되어 있으며 DRAM 및 그래픽 프로세서는 50MHz에서 실행됩니다. 3D 가속만 제공하므로 컴퓨터에는 기존 2D 소프트웨어를 처리하기 위한 기존 비디오 컨트롤러도 필요합니다.

Voodoo 1 칩을 탑재한 그래픽 카드의 모습.

같은 해에 NVIDIA와 ATI(나중에 AMD에 인수됨)는 Nvidia(NV1, RIVA 128, Geforce 256), ATI의 3D Rage, Rage Pro, Rage 128 등과 같은 자체 GPU 시리즈를 시작했습니다. 그래픽 카드는 출시되자마자 합리적인 가격, 폭넓은 판매 채널, 게임 및 운영 체제(주로 Windows) 지원으로 인해 즉시 인기를 얻었습니다.

향후 2년 동안 3dfx는 Voodoo Rush, Voodoo 2 및 기타 칩을 연속적으로 출시했습니다. Voodoo Rush는 추가 2D 프로세서 없이도 2D와 3D를 통합합니다. 하지만 Voodoo Rush는 2D와 3D 간의 대역폭 경합으로 인해 제대로 작동하지 않습니다.

또한 Rush 칩셋은 PCI 버스에 직접 존재하지 않지만 2D 칩의 링크 레지스터를 통해 프로그래밍되어야 합니다. Voodoo Graphics와 마찬가지로 인터럽트 메커니즘이 없으므로 드라이버는 Rush를 폴링하여 명령이 완료되었는지 확인해야 합니다. 2D 구성 요소를 통한 간접 참조는 여기에 상당한 오버헤드를 추가하고 PCI 인터페이스의 트래픽을 백업하는 경향이 있습니다. Voodoo Graphics에 비해 일반적인 성능 저하가 약 10%이며, 창 모드에서는 더욱 악화됩니다. Voodoo Rush 카드의 판매는 매우 저조했고 카드는 1년 이내에 중단되었습니다.

1998년 3월 Voodoo 2가 출시되었습니다. 아키텍처는 1세대와 유사했지만 한 번에 두 개의 텍스처 그리기를 지원하기 위해 두 번째 텍스처 유닛이 하드웨어에 추가되었습니다. Voodoo 2에는 3개의 칩과 별도의 VGA 그래픽 카드가 필요하며, 같은 시기의 다른 제품보다 성능이 좋지만 일부 제한 사항도 있습니다. Voodoo2는 두 개의 Voodoo2 보드가 서로 연결되어 각각 화면 스캔 라인의 절반을 그리는 SLI(스캔 라인 인터리빙)를 도입했습니다. SLI는 지원되는 최대 해상도를 1024×768로 늘립니다. 3개의 개별 그래픽 카드(2개의 Voodoo 2 SLI와 범용 2D 그래픽 어댑터)를 사용하는 데 따른 높은 비용과 불편함 때문에 Voodoo 2 SLI 접근 방식은 전체 시장 점유율에 거의 영향을 미치지 않았으며 재정적으로 성공하지 못했습니다.

몇 달 후, 2D/3D 칩셋이 통합된 Nvidia RIVA TNT(아래 그림)가 출시되어 Voodoo2의 패권에 약간의 도전을 제기했습니다. RIVA TNT는 두 번째 픽셀 파이프라인을 추가하여 렌더링 속도를 두 배로 높이고 메모리를 더 빠르게 사용합니다. Voodoo2와 달리 32비트(트루 컬러) 픽셀 형식, 3D 모드의 24비트 깊이 버퍼, 8비트 스텐실 버퍼 및 1024×1024 픽셀 텍스처에 대한 지원도 추가되었습니다. 또한 새로 추가된 삼선형 필터링 지원을 포함하여 개선된 밉매핑 및 텍스처 필터링 기술은 최대 16MiB SDR SDRAM에 대한 지원도 추가한 TNT의 이전 제품에 비해 품질을 크게 향상시킵니다. RIVA 128과 마찬가지로 RIVA TNT는 단일 칩 솔루션입니다.

Nvidia RIVA TNT 칩 모습.

1999년에는 Nvidia의 GeForce 256(NV10)이 출시되었습니다. 고정 파이프라인, DirectX7.0 지원, 하드웨어 및 좌표 변환 및 조명, 큐빅 환경 맵, 범프 맵, 2x 이방성 필터링, 삼선형 필터링, DXT 텍스처 압축 및 기타 기능 지원이 특징입니다.

1990년대에는 그래픽 카드의 구성 요소와 레이아웃이 비교적 단순했습니다. 가장 눈에 띄는 것은 방열 장치였습니다. 1998년에는 그래픽 카드에 몇 개의 방열판만 필요했습니다. 2003년에는 열을 방출하기 위해 팬이 필요했습니다(아래 그림).

그래픽 카드의 물리적 구성 요소가 개선된 것 외에도 처리 속도와 대역폭도 급격하게 증가하여 무어의 법칙 곡선을 보이거나 초과하고 있습니다. 다음 그림은 TNT(1998)에서 GeforceFX 6800(2004)까지 초당 처리된 삼각형 수에 대한 NVidia의 그래프입니다.

그래픽 API 표준과 GPU 하드웨어의 개발은 게임 엔진을 더욱 강력하게 만들었고 이 시대에는 개발 여지가 더 커졌습니다.

14.2.3 엔진 개발 ​

인류 역사상 최초의 컴퓨터 게임은 일반적으로 1962년의 Spacewar로 간주됩니다. 이 게임에는 원시적인 2D 모니터에 두 대의 플레이어가 제어하는 우주선이 표시되었지만 더 이전에도 더 간단한 게임이 존재했습니다. 초기 컴퓨터 게임은 저해상도 화면의 단순한 2D 그래픽으로 구성되었으며 이러한 추세는 1990년대까지 계속되었습니다.

1962년 컴퓨터 게임 Spacewar는 일반적으로 인류 역사상 최초의 컴퓨터 게임으로 간주됩니다.

초기 게임을 실행하는 데 필요한 하드웨어는 매우 제한적이어서 개발자는 어셈블리 언어로 게임을 프로그래밍하는 등 시스템에서 모든 처리 능력을 짜내야 했습니다. 과거의 게임 엔지니어링은 주로 낮은 수준의 최적화에 관한 것이었습니다. 제한된 하드웨어로 인해 초기 컴퓨터 게임에는 이벤트 루프, 상태 테이블 및 그래픽 루틴만으로 구성된 아키텍처가 거의 없었습니다. 이러한 게임은 재사용 가능한 요소를 거의 공유하지 않으므로 새로운 게임이 처음부터 프로그래밍되는 경우가 많습니다.

초기 엔진과 유사한 아키텍처의 힌트는 초기 어드벤처 게임에서 볼 수 있으며, 그 중 첫 번째인 Colossal Cave Adventure는 텍스트 기반 인터랙티브 픽션 장르의 시작을 알렸습니다. 이 장르의 게임플레이는 설정의 텍스트 표현을 읽고 간단한 명령을 입력하여 설정과 상호 작용하는 것으로 구성되었습니다. 텍스트 기반 모험은 초기 게임에서 매우 인기가 있었습니다. 이후 그래픽의 결합으로 그래픽 어드벤처형 아키텍처가 탄생했지만 상태 테이블 형태의 게임 로직과 최소한의 레벨 데이터, 거의 알아볼 수 없는 이벤트 관리자만 있을 뿐 구조는 매우 단순했다.

Adventure의 아키텍처는 단순하지만 게임 엔진의 전형적인 데이터 기반 디자인 요소를 명확하게 볼 수 있습니다. 즉, 게임 콘텐츠가 코드와 명확하게 분리되어 있습니다. 원칙적으로는 데이터를 변경하고 코드만 남겨두면 수정된 버전의 게임을 만드는 것도 가능합니다.

Adventureland(Adventure International, 1978), Zork(원래 1977년 MIT의 몇몇 학생에 의해 작성되었으며 나중에 Infocom에서 1980~1982년에 세 가지 다른 게임으로 출시됨) 및 Mystery House(1980)를 포함하여 Adventure의 후속작 중 일부는 이 게임의 영향을 많이 받았습니다. Adventureland의 메커니즘은 원래 Adventure와 거의 동일하지만 Zork와 Mystery House는 어드벤처 게임 개발에서 두 가지 분야를 탄생시켰습니다. Zork 및 기타 Infocom 게임은 여전히 ​​텍스트 전용이었지만 명령 구문 분석기가 크게 개선되었으며, Mystery House는 기본 그래픽(플레이어 명령은 여전히 ​​텍스트로 입력됨)을 특징으로 하여 그래픽 어드벤처 게임 장르를 개척했습니다. 그럼에도 불구하고 Infocom의 텍스트 기반 게임은 한동안 더 인기를 끌었고, 나중에 업계 관계자는 제한된 하드웨어에서 사용할 수 있는 그래픽 처리로 인해 게임 플레이가 제공할 수 있는 깊이가 사라졌다고 언급했습니다.

왼쪽: 미스터리 하우스(1980) 오른쪽: 원숭이섬의 비밀(1990).

1980년대 스페이스 패닉은 캐릭터가 화면 주위를 이동하며 외계인을 피하고, 오르내리고** 땅에 구멍을 파는 단일 화면 게임이었습니다. Donkey Kong(Nintendo, 1981)과 같은 게임에는 점프 능력과 같은 추가 기능이 추가되었습니다. 단일 화면 메커니즘을 횡스크롤 메커니즘으로 대체하고 다른 기능을 추가한 Super Mario Bros.(Nintendo, 1985)와 같은 게임에서 추가 개발이 이루어졌습니다.

왼쪽: 스페이스 패닉(1980); 오른쪽: 슈퍼 마리오 브라더스(1985).

1980년대 중반에는 소규모 플랫폼 게임을 개발하는 여러 소규모 독립 비디오 게임 스튜디오가 있었습니다. 이 게임에는 일반적으로 게이머가 정적 및 움직이는 플랫폼과 선반에서 달리고 점프하여 적으로 가득 찬 레벨에서 캐릭터를 탐색하는 방식이 포함되었습니다(아래 이미지). 이러한 게임은 큰 성공을 거두어 전 세계 게이머들을 기쁘게 했습니다.

원숭이 다윈 게임 스크린샷.

초기 게임 아키텍처의 경우(어드벤쳐 장르의 게임 제외)와 마찬가지로 초기 플랫폼 아키텍처에 관한 문헌은 드물습니다. Blow(2004)는 1990년대 2D 게임의 일부 모듈(스트리밍 파일 I/O, 사운드, 메인/기타, 시뮬레이션, 빠른 2D 그래픽)의 이름을 지정하는 동시에 다른 유형의 게임에는 AI를 얻고 빠른 그래픽 노드를 잃을 수 있는 부분과 같은 다른 부분이 포함될 수 있다는 점을 지적하면서 통찰력을 제공합니다.

1990년대 이전에는 성숙한 게임 엔진이 없었기 때문에 게임 개발이 극도로 어려웠습니다. 유사한 기능이 많이 반복되어 생산성이 낮아지고 그래픽이 거칠어집니다.

게임을 개발하는 과정에서 일부 게임 스튜디오에서는 각 게임의 바퀴를 재창조합니다. 그 결과 게임 개발 시간이 점점 길어지고 있으며, 경쟁사들의 게임 개발 시간도 점차 단축되고 있는 것으로 나타났다. 게임 개발 주기를 단축하는 스튜디오는 재사용 사고 방식을 채택합니다. 모든 게임과 모든 플랫폼 게임에 공통된 많은 속성과 기능을 특정 게임에서 추출할 수 있으며, 이전 프로젝트를 재사용 가능하거나 기본 모듈로 추상화하여 다음 게임 프로젝트에서 빠르게 사용할 수 있으므로 게임 개발 시간이 지속적으로 단축됩니다.

이들 스튜디오는 최초의 공통 구성 요소 중 일부를 발견했을 뿐만 아니라 거의 모든 게임의 보편적인 구성 요소를 인식하고 이를 다양한 게임을 만드는 데 재사용할 수 있는 단일 시스템에 통합했습니다. 그들은 게임의 모양과 소리가 다르기 때문에 게임 콘텐츠(그래픽 및 사운드)를 게임별로 생성해야 할 수도 있다는 것을 알고 있지만, 이 콘텐츠를 지원하기 위한 프레임워크(또는 인프라)가 존재하며 이것이 대부분 추상화 가능하다는 것도 알고 있습니다. 이 프레임워크 또는 시스템을 게임 엔진이라고 합니다.

1990년대에는 시스템을 갖춘 게임 엔진 시리즈가 두 개 있었는데, 하나는 ID의 Doom과 Quake 시리즈였고, 다른 하나는 Epic Games의 Unreal 시리즈였습니다.

많은 사람들은 컴퓨터 게임(특히 게임 엔진)의 전환점이 FPS 장르의 탄생이라고 생각합니다. id Software가 Wolfenstein 3D(1992)와 Doom(1993)을 출판했고, 특히 Doom은 게임 매니아들 사이에서 널리 인기를 얻었습니다.

Doom의 아키텍처도 주목할 만합니다. Doom의 핵심 소프트웨어 구성 요소(예: 그래픽 렌더링, 충돌 감지, 오디오)를 게임 콘텐츠(예: 아트 자산, 게임 세계, 게임 규칙)에서 분리한다는 것은 사용자가 새로운 레벨, 모델 및 기타 자산을 게임에 추가하여 효과적으로 자신만의 새로운 게임을 만들 수 있음을 의미합니다. Doom은 최소한으로 프로그래밍 가능하고 Doom에서 파생된 게임은 원래 게임처럼 계속 플레이되지만 여러 회사에서 자체 상용 게임을 만들기 위해 id Software의 Doom 엔진에 라이선스를 부여했습니다. 따라서 데이터 기반 아키텍처를 사용한 최초의 게임은 아니었지만 인기를 Doom에 돌리는 것은 아마도 무리가 아닐 것입니다.

둠 렌더링(1993).

Doom의 뒤를 이어 진정한 3D 그래픽과 클라이언트/서버 아키텍처로 Doom의 기능을 계승한 Quake(id Software, 1996)가 나왔습니다. Quake는 또한 레벨 편집기와 QuakeC(게임 동작을 변경할 수 있는 스크립팅 언어)를 포함하여 진정한 게임 독립적인 게임 엔진을 제공합니다. 이는 게임 실행 파일에 데이터 파일을 추가하는 Doom의 방법에 비해 크게 개선되었으며 프로그래밍 기능이 최소화되었습니다. Quake의 엔진은 클라이언트와 서버의 두 부분으로 구성됩니다. 모든 입력(키보드, 마우스, 조이스틱)과 출력(3D 렌더링, 2D 드로잉 및 사운드)이 클라이언트에서 발생하며, 플레이어 이동 및 물리 시뮬레이션, AI 및 QuakeC 스크립팅과 같은 모든 실제 게임플레이가 서버에서 발생합니다. 클라이언트는 플레이어로부터 입력을 받아 서버로 보냅니다. 서버는 고정된 시간 동안 게임을 처리한 다음 게임 상태를 클라이언트로 다시 보내 플레이어에게 시청각 출력을 제공합니다.

Quake III Arena 렌더링(1999).

Quake의 싱글 플레이어 게임과 멀티 플레이어 게임 모두 이 아키텍처를 기반으로 구축되었습니다. 멀티플레이어 게임에서는 여러 클라이언트가 네트워크 계층을 통해 단일 서버(일반적으로 서로 다른 시스템에서 실행됨)와 통신하는 반면, 단일 플레이어 게임은 공유 메모리 버퍼를 사용하여 통신하며, 각 처리 프레임은 클라이언트에서 입력을 받는 것, 서버에서 게임을 처리하는 것, 클라이언트에서 출력하는 것 사이에서 분할됩니다.

멀티플레이어 게임의 동기화 문제를 단순화하는 것 외에도(모든 플레이어가 자신의 게임 시뮬레이션을 실행하고 컴퓨터가 동기화되는 Doom과 비교하여) 클라이언트-서버 아키텍처는 모듈식 설계를 적용하여 디버깅을 단순화하고 싱글 플레이어와 멀티플레이어 코드를 동일하게 유지합니다.

Quake에 이어 Quake II(id Software, 1997)와 Quake III Arena(id Software, 1999)가 이어졌습니다. 엔진이 Quake 1 엔진에서 세 번째 반복(Quake 3)으로 진화하면서 SLOC(소스 코드 줄) 및 소스 코드 모듈의 수에 따라 크기도 커졌습니다. 첫 번째 버전의 소스 코드 파일은 하나의 폴더에만 존재했지만 후속 버전에서는 소스 파일을 하위 폴더 트리로 구성했기 때문에 엔진은 시간이 지남에 따라 더욱 체계화되었습니다. 다음 엔진 버전에는 여러 모듈이 있습니다:

  • 공통 기능 모듈.

  • 게임 로직 모듈.

  • 서버별 기능 모듈.

  • 클라이언트 기능 모듈.

  • 사운드 및 비디오 출력 모듈(향후 버전에서는 분리 예정)

연구에서 분석된 모든 엔진은 C 프로그래밍 언어로 작성되었지만 엔진의 네 번째 버전인 id Tech 4는 C++ 및 객체 지향 패러다임을 사용하여 완전히 재설계되었습니다.

1990년대 퀘이크(Quake) 시리즈 이야기를 마치고, 다시 같은 시기의 언리얼 엔진에 대해 이야기해보겠습니다.

1991년의 ZZT는 기본적으로 게임이 내장된 게임 엔진이었습니다. 엔진은 매우 기본적이지만 작은 게임을 스크립팅하는 데 사용할 수 있는 완전한 스크립팅 언어인 작은 스크립팅 언어를 제공합니다. 몇 번의 키 입력으로 앞뒤로 전환하고, 레벨을 추가하고, 플레이 테스트하고, 반복할 수 있는 레벨을 생성하기 위한 실시간 WYSIWYG 대화형 편집기가 있습니다. 이 대화형 워크플로우가 실제로 핵심입니다.

ZZT의 게임 모드 및 편집 모드.

Turbo Pascal은 코드를 생성하고 컴파일하는 데 사용하기 쉬운 편집기입니다. 몇 초 동안 코드를 입력하면 컴파일되어 실행할 수 있습니다. 이러한 코딩 방식을 사용하면 이전에 사용했던 어떤 것보다 훨씬 더 사용자 친화적인 것을 만드는 반복 프로세스가 가능해졌습니다.

터보 파스칼 편집기.

그 후 Epic Games의 Tim Sweeney는 ZZT와 Turbo Pascal에서 영감을 받아 Unreal 엔진 개발 여정을 시작했습니다. 언리얼 첫 버전의 핵심 기능은 대부분 ZZT와 비슷했고, 에디터도 터보 파스칼과 비슷했습니다.

Visual Basic을 사용하는 1998 Unreal Ed 편집기.

그 후 몇 년 동안 기술의 발전과 함께 Unreal 에디터는 Visual Base, wxWidget, Slate 등의 UI 프레임워크를 잇달아 시도했으며 점차적으로 오늘날의 에디터 스타일과 상호 작용 방식을 형성했습니다. 후속 Unreal Engine에는 Game Play 프레임워크가 추가되어 개발자에게 사용 가능하고 확장 가능한 기반을 신속하게 제공할 수 있습니다.

Unreal Engine 게임 플레이 프레임워크 다이어그램.

이 기간 동안 Quake와 Unreal 외에도 다른 게임 엔진의 개발도 있었습니다. 예를 들어 TerraForm3D Plasma Works 3D 엔진 및 USGS Terrain Modeler에서는 간단한 엔진(Plasma Works Engine)을 설계하는 방법을 언급합니다. Plasma Works Engine의 목표는 3D 엔진 설계, 객체 기반 렌더러, 다양한 특수 효과 실험은 물론 고품질 이미지 렌더러, 사용자 중심 이미지 처리 등을 통해 양측의 요구를 충족시키는 것입니다.

Plasma Works 엔진 렌더링 렌더링.

구조적으로는 단일 엔진, 동일한 아키텍처 기반, 오픈 소스 및 독점의 문제였지만 이제는 두 개의 별도 엔진, 서로 다른 아키텍처 및 OpenGL 고유 확장(GLUT)이 되었습니다.

Plasma Works 엔진 아키텍처 다이어그램. 객체(Object)와 렌더러(Renderer)로 구분되며, 다양한 리소스와 객체를 의미합니다.

Plasma Works 엔진 초기화 및 루프 흐름도.

데이터 흐름 측면에서 클라이언트는 명령 기반 메커니즘을 채택하여 개체와 렌더러를 구동하고 마지막으로 그림 픽셀과 광원 정보를 렌더링합니다.

Plasma Works Engine의 지형 모델러에는 많은 패키지 인터페이스가 포함되며, 이들의 상호 작용 관계는 다음과 같습니다.

지형 생성 및 처리에는 병렬 분산 아키텍처가 채택됩니다.

아래 그림은 지형 편집기 인터페이스입니다.

다음 그림은 지형 병렬 처리를 위한 인터페이스입니다.

오늘날 관점에서 보면 다소 초보적인 수준이지만 당시에는 병렬 처리가 쉽지 않았고 IO, 텍스처 대역폭, 동기화, 디자인 모델 등 많은 문제에 직면했습니다.

1995년 Architectural Blueprints - The "4+1" View Model of Software Architecture에서는 4+1 보기 소프트웨어 구조를 언급했습니다.

  • 객체 모델을 설명하는 논리적 뷰.

  • 프로세스 뷰(Process View)는 동시 프로세스 및 동기화 문제를 처리합니다.

  • 물리적 보기(Physical View)는 "소프트웨어를 하드웨어에 매핑하고 분산된 측면을 반영하는 것"을 설명합니다.

  • 개발 환경에서 소프트웨어의 정적 구성을 나타내며 구성 요소 개념, 인터페이스 및 상호 연관된 구성을 추가하는 개발 뷰입니다.

  • 시나리오는 개체와 프로세스 간의 상호 작용 순서를 설명합니다. 이는 건축 요소를 식별하고 건축 설계를 설명하고 검증하는 데 사용됩니다. 또한 아키텍처 프로토타입 테스트를 위한 출발점으로도 사용할 수 있습니다. 이 보기를 사용 사례 보기라고도 합니다.

4+1 보기의 소프트웨어 구조.

이러한 관점의 소프트웨어 아키텍처는 게임 엔진의 아키텍처 설계에도 도입될 수 있습니다. 예를 들어, 엔진의 핵심 클래스를 드러내는 UML 다이어그램은 논리적 뷰, 엔진의 툴 체인은 개발자 뷰, 리소스 파일의 로딩 계층화 및 배포 방법은 물리적 뷰입니다.

이 단계의 엔진은 대략적인 형태를 갖추었으며 아키텍처의 구성 요소는 대략 다음과 같습니다.

각 모듈을 세분화하면 아래 그림과 같다.

새로운 세기에는 많은 새로운 렌더링 엔진이나 구성 요소가 탄생했으며 그 중 Ogre가 대표적인 예입니다. Ogre의 파생 엔진인 Ogre Golf는 Orge를 기반으로 많은 확장을 수행하고 많은 기능과 타사 라이브러리를 도입했으며 닌자, 로봇, 소화전, 성, 흑마법사 및 기타 개체가 포함된 대형 미니 골프 코스와 같은 대표적인 게임을 개발했습니다. 이 게임은 멀티 플레이어 네트워크 상호 작용을 지원합니다.

오우거 골프 렌더링.

같은 기간 동안 Irrich, Delta3D, Panda, OSG와 같은 엔진도 각각 고유한 특징을 가지고 등장했습니다. 엔진의 다양한 기능(렌더링, 기능, 장면, 지형, 비전, 크로스 플랫폼 등)에 대한 지원 정도는 다음 표와 같습니다.

이 단계에서 엔진의 논리 루프와 렌더링 루프는 다음과 같습니다.

cpp
// 로직 루프
while (true)
{
    for (each frameListener)
    {
        frameListener.frameStarted();
    }
    renderCurrentScene();
    for (each frameListener)
    {
        frameListener.frameEnded();
    }
    finalizeSceneAndSwapBuffers();
}

// 렌더링(Render)루프
while (!quit)
{
    // 수정 。
    updateCamera();
    // 수정 의 。
    updateSceneElements();
    // 렌더링(Render)의 。
    renderScene();
    // 프레젠트 스왑체인 （활성화(Enable)버퍼 의 ）。
    swapBuffers();
}

이 시점에서 마침내 게임 엔진의 초기 단계가 성공적으로 완료되었으며 기본 모듈, 아키텍처 및 렌더링 기술이 점차 형성되었습니다.

  • 이 글은 아직 끝나지 않았으며 계속됩니다.

특별 지침 ​

  • 모든 참고문헌의 저자에게 감사드립니다. 일부 사진은 참고 자료와 인터넷에서 가져온 것이므로 삭제되었습니다.

  • 이 시리즈의 기사는 저자가 직접 작성한 것이며 블로그에만 게시됩니다. 이 글의 링크를 공유하셔도 좋지만 무단 전재는 허용되지 않습니다!

  • 계속되는 일련의 기사. 전체 목록을 보려면 콘텐츠 개요를 클릭하세요.

  • 계속되는 일련의 기사. 전체 목록을 보려면 콘텐츠 개요를 클릭하세요.

  • 계속되는 일련의 기사. 전체 목록을 보려면 콘텐츠 개요를 클릭하세요.

📚 참고 자료 및 공식 링크 (References) ​

🔗 연관 지식 베이스 (Wiki & Tools) ​

Based on the legendary technical series by Timlly (0向往0 / 毛星云)

Copyright © 2026 Unreal Rendering Architecture Teardown Knowledge Portal