나무모에 미러 (일반/어두운 화면)
최근 수정 시각 : 2024-04-19 13:05:15

게임 엔진


||<-2><tablebordercolor=#000,#fff><tablealign=center><tablewidth=100%><tablebgcolor=#fff,#1c1d1f><bgcolor=#000,#fff> 게임 엔진 ||
{{{#!wiki style="margin:0 -10px -5px; min-height:calc(1.5em + 5px)"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-5px -1px -11px"		 메이저 상용 게임 엔진
파일:언리얼 엔진 로고.svg파일:언리얼 엔진 로고 화이트.svg 파일:유니티 로고.svg파일:유니티 로고 화이트.svg
언리얼 엔진 유니티
기타 엔진 목록 }}}}}}}}}

1. 개요2. 역사
2.1. 게임 소스 코드의 재활용: 1970년대 ~
2.1.1. 스크립트 언어
2.2. 게임 엔진 태동기: 1990년대 중반 ~2.3. 특정 기술/기능 라이브러리(미들웨어)의 등장: 1990년대 후반 ~2.4. 본격적인 게임 엔진의 등장: 2000년대 중반 이후
3. 기능4. 게임 엔진 목록
4.1. 오픈 소스 엔진4.2. 공개된 상용 엔진4.3. 비공개된 엔진
5. 자체 엔진
5.1. 오래된 엔진은 성능이 떨어진다?5.2. 자체 엔진은 성능이 좋다?
6. 포크7. 게임 엔진을 백엔드 프레임워크로만 사용하는 경우8. 미들웨어 종류/목록
8.1. 물리 엔진8.2. 사운드 엔진8.3. 모션8.4. 기타 미들웨어
9. 관련 문서

[clearfix]

1. 개요

비디오 게임, PC 게임의 개발에 기반이 되는 구성 요소들을 가진 필수 구성 요소들인 그래픽 엔진, 물리 엔진, 오디오 엔진, UI 시스템, 게임 플레이 프레임워크 등이 잘 융합된 상태의 소스 코드와 그 기능들을 디자이너들이 사용 가능한 툴을 겸비한 게임 개발 소프트웨어를 일컫는 말이다.

태초의 게임 엔진이 나무도막이나 모래상자 수준이었다면 현대의 게임 엔진은 자동차 생산 라인이라고 봐도 무방할 정도로 많은 기능을 제공한다.

2. 역사

2.1. 게임 소스 코드의 재활용: 1970년대 ~

1990년대 중반 이전에는 게임 엔진이란 명칭도 정립이 되지 않았고 전문적인 게임 엔진도 없던 시절이라 엔진과 결과물이 명확하게 구분되어 연결되지 않는다. 이는 대부분의 게임이 그 게임을 위한 코드 자체로 구성되어 다른 게임에 반복해서 이식될 일이 거의 없었기 때문이다. 당시 미국의 게임 개발자들도 '게임 엔진'과 '게임 라이브러리'를 명확하게 구별하지 않던 시절이었고, 개발자들 사이에서 유통되는 유료화된 라이브러리의 기능범위 역시 상당히 다양했다. 좁게는 화면에 그래픽을 출력하는 기능(나중으로 따지면 DirectX, OpenGL와 같은 역할)들을 잘 엮어서 엔진이라고 판매되는 경우부터, 규모가 있으면 메모리 관리나 데이터 리소스 관리 기능 정도가 포함되면 게임용 엔진으로서 가능한 거의 모든 기능을 포함할 수 있었다.

이때는 게임 엔진이라는 명확한 표현은 없었지만 일단 한번 게임을 성공적으로 개발할 경우 그 게임의 소스 코드를 재활용하여 후속작이나 비슷한 작품을 만드는데에 재활용 하는 것은 지극히 당연한 일이었다. 비단 형태가 비슷한 게임이 아닐지라도, 콘솔게임은 물론이고 IBM-PC 호환기종에서는 얼마나 많은 하드웨어를 지원하느냐에 따라 제작사의 실력이 갈리기도 했었는데, 이러한 하드웨어 제어 엔진 부분의 코드를 공통적으로 돌려쓰는 관습 또한 존재했다.

이를테면 1991년작 Winter Challenge 게임과 동일 개발사의 1992년작 Summer Challenge을 보면 윈터 챌린지에서 계절만 그대로 바꾼 게임이라는 것을 알 수 있다.

비슷하게 1993년작 정글 북과 동일 개발사의 1994년작 라이온 킹의 영상을 비교해도 대충 어떤 느낌인지 쉽게 알 수 있을 것이다.

게임보이 컬러용 루리루리 마작과 에반게리온 마작은 서로 다른 게임임에도 통신 대전이 가능하여 큰 화제를 불러왔는데, 이것은 그야말로 게임의 모든 소스 코드가 동일하고 그림만 다른 게임이라는 것의 증거이다.

이런 점들은 현대적인 게임 엔진이라기 보단, 현재 게임들이 캐릭터 스킨만 바꿔서 돌려막기 하는 것처럼 인기있는 장르의 게임을 그림만 바꿔 돌려막는 것에 더 가까웠다.

2.1.1. 스크립트 언어

그래도 일부 게임제작사들은 아예 특정 코드를 규격화 시킨뒤에 스크립트에 맞춰 코드를 짜면 이후 스크립트가 변환시켜주는 방식을 사용하기도 했다. 루카스아츠의 SCUMM이 대표적. 이런 스크립트 언어의 장점은 일단 해당 스크립트로 게임을 만들면 이후 각각의 플랫폼별로 변환기만 만들면 한번의 제작으로 여러 플랫폼에 게임을 출시할수 있다는 강점이 있어 시에라(AGI, SGI등), 루카스아츠 등의 제작사들이 자주 애용했다. 당시에는 단지 스크립트 언어 혹은 스크립트 엔진등으로 불렸으나, 게임 엔진이라는 말이 대중화 된 이후로는 이런 언어들도 게임 엔진이라 부르게 되었다. 이런 스크립트 언어는 지금도 여전히 중소형 게임 제작사들이 만들어 사용하는 경우가 종종 있는데, 에로게에서는 특히 자주 사용되고 있다.

2.2. 게임 엔진 태동기: 1990년대 중반 ~

게임 엔진이라는 용어의 존재는 현재의 총합패키지와 마케팅적 이미지가 씌워지기 전에도 존재했었다. 도스 게임 시절에는 윈도우와 달리 수많은 하드웨어 파편화에 대응하여 하드웨어를 직접 제어해야 했다. 거기서 제작사의 실력이 많이 갈렸는데, 그러다보니 사운드 블래스터 같은 디 팩토 표준 기기도 정해지게 되었고 같은 게임 제작사의 다른 게임 혹은 아예 완전히 다른 제작사의 다른 게임이라도 사전에 사운드와 그래픽 따위를 설정하는 부분이 비슷비슷해지는 경우가 많이 있었다. 그런 게임의 핵심 코드를 '엔진'이라고 부르고 사용하였다.

사실상 처음으로 xx 엔진[1]이라는 말이 등장하기 시작한 것은 고전 FPS 게임 둠이 id tech 엔진으로 그 후속작 둠 2 그리고 파생작인 헤러틱, 헥센 같은 게임들이 제작되며라고 볼 수 있을것이다. 이때에도 현대의 게임 엔진 모습과는 달리 하드웨어를 제어하고 그래픽을 렌더링하는 핵심 기반 소스 코드나 미들웨어 정도의 수준인 것들이 대부분이었으나, 그 자체가 이미 뛰어난 기술력을 보유한 것이었고, 곧 기술력을 자랑하는 마케팅 용도로도 사용되었으며, 타사에 라이센스를 주기도 했다.

본격적으로 게임 엔진이 엔진으로서 활약하게 된 것은 퀘이크가 나올때 부터인데 사실 퀘이크가 2까지 나올때에도 실질적으로 엔진을 사용하여 게임을 만든다는 개념이 그렇게 크지는 않았다. 그러나 그를 사용한 하프라이프가 나오고 대히트 하면서 상황이 반전되고, 에픽은 언리얼 게임을 내놓으며 이드 소프트웨어의 아성을 크게 위협하며 언리얼 엔진의 존재를 부각시켰다. 사실 이때까지도 이들 게임 엔진을 사용하여 만들어진 게임의 수는 손에 꼽을 정도로 적었으나 게임 엔진을 사용했다는 것 자체로 '우리 게임은 첨단 기술을 사용하여 제작되었다'는 마케팅이 되기도 하였다.

이러한 예를 일부 살펴보자면, 빌드 엔진은 1993년부터 1996년까지 3D 렐름에서 개발한 둠 스타일의 2.5D로 단순한 테스트 형태의 FPS 게임 소스와 툴을 담고 있었다. 빌드 엔진은 개발 도중 타사에 라이센스 되어 몇 가지의 FPS 게임들이 출시되었는데 빌드 엔진을 사용한 게임 중 특별한 3개의 게임들[2]은 빌드 엔진 개발자와 해당 게임 개발자가 협업하여 빌드 엔진을 각 해당 게임에 특화하여 변형시켰다. 자세한 사항은 빌드 엔진 문서 참고.

퀘이크 1, 2, 3의 id Tech 엔진은 본격적인 게임 엔진의 사용 사례로 하프라이프를 비롯한 당대의 유명한 3D FPS 게임들은 대부분 퀘이크 엔진을 이용하여 만들어 졌다고 해도 과언이 아니다.

언리얼 엔진은 기존의 다른 엔진들과 다른 유연한 구조와 뛰어난 에디터를 제공해서 소스 코드를 거의 손대지 않고서도 원본 FPS 게임에서 어느 정도 모양새가 다른 게임들을 개발할 수 있었다. 언리얼 엔진 2 부터는 FPS/TPS 뿐만이 아니라 MMORPG 게임을 만드는데도 사용되었다.

리스텍 엔진은 쇼고 모빌 아머 디비전과 블러드 2를 시작으로 주피터 엔진으로 이름을 바꿔 F.E.A.R.를 거쳐 가장 최신 게임인 모르도르까지 이름을 이어오고 있다.

2.3. 특정 기술/기능 라이브러리(미들웨어)의 등장: 1990년대 후반 ~

1990년대 중반 이후부터 본격적으로 3D 게임의 시대가 개막되면서 3D 게임 프로그래밍은 기존에 2D 게임 개발과는 비교 조차도 하기 힘든 수준으로 개발 난이도가 급상승되었고 이런 한계를 극복하고자 소수의 개발자들이 연합하여 3D 그래픽 구현에 관한 다양한 라이브러리를 작성해 인터넷상에 무료 배포했으며 관련 서적들을 출판하고 서적의 부록CD로 해당 3D 그래픽 라이브러리를 포함하는 등 3D 게임 기술의 상향을 위해 노력했었다. 당시 유명했던 것은 John De Goes의 Cutting Edge 3D Game Graphics Engine이다.

이 중 3D 그래픽 라이브러리의 개발 수준이 높아지고 어느 정도의 툴도 갖추면서 이것을 지속적으로 업데이트하며 게임 개발사들을 대상으로 판매를 개시(라이센스)하는 회사도 차차 등장하게 되었는데 당시 유명한 상용 그래픽 라이브러리로는 렌더웨어 그래픽스(RenderWare Graphics)와 넷이머스(Netimmerse) 등이 있었다.

여전히 오픈 소스에 무상으로 개발되는 것들도 있는데 오픈 소스 중 유명한 3D 그래픽 라이브러리로는 오우거 3D(Ogre 3D)가 있다.

이런 그래픽 라이브러리는 순수하게 3D 그래픽을 처리하는 부분의 소스 코드만 있고(또는 그 그래픽을 처리하는 데 필요한 일부 툴도 포함) 나머지 게임에 필요한 모든 파트는 프로그래머가 직접 구현해야 하므로 이런 것은 게임 엔진이라고 불리지는 않고 그래픽 엔진이라고 불렸다. 하지만 당시는 게임 엔진 등 용어에 대한 정립이 명확하게 되어 있지 않았으므로 이것들이 게임 엔진으로 불리기도 했고 또는 특정 게임의 소스를 활용한 것을 가지고 그래픽 엔진을 활용했다고 부르기도 했다.

3D 그래픽 라이브러리만 존재했던 게 아니라 네트워크 라이브러리, 오디오 라이브러리, 물리 연산 라이브러리(현재 물리 엔진이라고 불리는) 등 다양한 분야별 라이브러리가 별도로 개발되고 라이센스 되어 여러게임에 활용된 바 있다.

현대에도 여전히 이런 전문분야 라이브러리, 이른바 미들웨어들이 다양하게 등장했는데 그래픽 컬링만 처리하는 Umbra, GI 라이트맵을 생생하고 동적 객체에 유사 GI 효과를 내주는 Beast, 유사 실시간 GI 효과를 만들어주는 Enlighten, 게임의 UI/UX를 Flash로 처리해주는 Scaleform GFx[3], 다양한 나무를 생성해주는 SpeedTree, 캐릭터 애니메이션 처리를 위한 Morpheme, HumanIK, 페이셜 애니메이션과 립싱크 등을 위한 FaceFX, IKinema 등이 있으며, 뿐만 아니라 사운드 컬링/울림/공간감 등을 위한 오디오 엔진 FMOD, Wwise, 인공지능처리를 위한 A.I. Implant, Kynapse 등 분야별 다양한 라이브러리들이 현대에도 많이 제작되고 있다.

이런 라이브러리들은 개발하는 게임에 융합해서 사용하는 것 뿐만 아니라 현대에서 게임 엔진이라고 불리는 그 엔진들에도 융합되어 사용할 수 있으며 특히 언리얼 엔진에서 IPP(Integrated Partners Program)이라는 명칭으로 다양한 기술들이 통합되었다.

2.4. 본격적인 게임 엔진의 등장: 2000년대 중반 이후

현대의 게임 엔진은 완전한 통합 게임 개발 솔루션을 표방하며 2004년에 등장한 언리얼 엔진 3를 그 대표로 꼽을 수 있다. 언리얼 엔진 3는 엔진의 모든 기능을 커스터마이징이 가능하면서도 상호간에 유기적으로 융합되는 유연한 구조로 기술의 추가나 변형이 용이해 게임의 장르나 플랫폼에 관계없이 어떤 형태의 게임도 개발이 가능하며, 엔진 코드와 게임 코드의 완전한 분리, 필요한 기능만 선택적으로 사용 가능, 하나의 작업물에서 다양한 플랫폼으로 릴리즈, 모드 툴이나 더미 데이터의 포함 여부, 또는 별도의 모드 툴만 작성할 수 있는 한 빌드 시스템 등 하나의 엔진으로 게임 개발에 대한 모든 것이 가능함을 지향했다. 다만 미래지향적이며 새로운 개념이었던 만큼 첫 등장 후 초기 1~2년 간은 몇가지 문제점들을 가지고 있었으나 꾸준한 버전업을 통해 보완되어갔고 새로운 기술 및 툴이 도입되며 전반적인 성능이나 편의성이나 더욱 강화되었다.

언리얼 엔진 3는 프로그래머가 아닌 게임 디자이너 입장에서도 편의성을 크게 강조하기 위한 혁신성을 꾀하며 새로운 시도를 했다. 프로그래머 없이 아티스트가 셰이더를 작성할 수 있는 비주얼 머터리얼 셰이더 에디터, 프로그래머의 도움 없이 레벨의 스크립트를 작성할 수 있는 키스멧, 디자이너가 그래프 노드 기반으로 효과를 조합하는 포스트 프로세스 에디터, 사운드 큐 에디터, 실시간 조합형 파티클 에디터 캐스케이드, 실제 영화 감독의 기능 시뮬레이션 툴 마티네 등 시대를 앞선 여러가지 탁월한 기능들을 성공적으로 정착시켰다. 특히 2009년에는 UDK라는 것을 무료로 개방하고 부터 일반 사용자들에게도 게임 엔진의 저변을 확대하는 데에 크게 일조하였다.

언리얼 엔진 3는 그야말로 한 시대[4]를 지배하다시피 하며 유수의 명작과 대작 AAA급 게임부터 소규모 캐주얼, 인디, 모바일 게임까지, 게임의 규모, 장르, 플랫폼을 가리지 않고 여기도 언리얼, 저기도 언리얼, 너도 나도 언리얼인 세상을 만들어 버렸다. 언리얼 엔진 3를 사용했다고 이 엔진을 사용한 게임들의 느낌이 비슷하지도 않고 게임마다 완전히 다른 느낌으로 구현이 가능한데 초기에는 아웃풋이 다 비슷하다는 오해가 있기도 했다. 그 이유는 언리얼 엔진 항목의 언리얼 엔진 3에 대한 오해 항목 참고.

언리얼 엔진 3의 엄청난 성공 이후 기존 엔진들의 후속버전이나 신규로 등장하는 엔진들 역시 언리얼 엔진 3의 형태를 모방하여 비전 엔진 8, 토크 게임 엔진 어드벤스드, 유니진 엔진 등 다양한 엔진들이 등장했다. 그러나 워낙에 언리얼 엔진 3가 넘볼 수 없을 정도로 높은 수준이기도 하고 기타 엔진들을 사용할 메리트는 오직 가격 뿐이었는데 UDK가 등장하며 그 가격 정책에도 메리트가 사라져서 결국은 많은 게임 엔진들이 그대로 사장되었다. 언리얼 엔진 3의 엄청난 폭풍 속에서 유일하게 살아남은 것은 유니티 엔진 뿐이다.

유니티3D는 언리얼 엔진 3의 복잡성과 라이센스 비용에 대비하여 메리트를 가지고 있었고, 빠른 프로토타이핑에 유리, 에셋 스토어의 도입, 풍부한 사용자 커뮤니티를 통한 생태계 생성을 통해 소규모 인디 게임, 저예산 개발사들에게 큰 인기를 끌었다. 보통 유니티를 경쾌하고 조작성이 좋은 경차에 비유한다면 언리얼은 다재다능한 SUV에 비유한다.

이후 언리얼 엔진 4는 기존의 언리얼 엔진 3보다 훨씬 강화된 다양한 기술/기능에 더해 유니티의 강점이었던 직관성을 도입하며 역시 빠르고 꾸준한 업데이트와 사용자 피드백을 도입했다. 또한 과거 미진했던 소규모 개발자들에게 어필하기 위해 오픈 소스화와 소스 코드를 기여하는 방식으로 모두가 개발에 참여하는 정책으로 선회하고 라이센스 정책도 크게 변화시켰다.

유니티 5는 기존의 유니티의 단점을 보완하여 그래픽적으로 개선을 꾀하고 여러가지 최적화 및 개선사항을 추진하였다. 기존의 유니티가 강세를 보이던 분야인 소규모나 저사양 모바일 게임에서는 여전히 강세이나 모바일이 고사양화 되어가면서 모바일에서도 언리얼 엔진의 입지가 점점 더 커지고, 언리얼 엔진의 라이센스가 소규모 개발사에게도 매력적이게 바뀜에 따라 언리얼 엔진이 과거 유니티의 독점 분야였던 저사양, 인디, 모바일에서도 경합 중.

또한 자체적인 게임 엔진을 만들어 사내에서 돌려 쓰는 경우도 있다. EA DICE의 프로스트바이트 엔진이 그 대표적인 예. 한국은 로우레벨 프로그래머의 부족[5]으로 자체 엔진을 만들어 쓰는 회사는 거의 없고, 넥슨의 데브캣 스튜디오, 검은사막을 개발한 펄어비스 정도가 전부이다. 이마저도 넥슨은 사내에서 해당 엔진을 전사적으로 공유하는 것이 아니라 데브캣 내에서만 쓰는 중이다.

3. 기능


... 등등 여러 기능이 존재한다.

4. 게임 엔진 목록

당연하겠지만 이름조차도 공개되지 않은 엔진도 있어서 이게 모든 게임 엔진의 목록은 아니다. 공개/비공개의 구분은 기업은 물론 일반인도 자유롭게 접근해서 사용이 가능한가의 유무이다. 가령 데시마 엔진의 경우, 호라이즌 제로 던이나 데스 스트랜딩같은 여러 게임들에 사용 되었지만, 소니 파트너에게만 공개되어있으므로 비공개 엔진에 해당된다.

4.1. 오픈 소스 엔진

소스 코드 공개와 때에 따라 소프트웨어가 개량되는 걸 허용하는 엔진이 일부있다. '오픈 소스≠비용이 없다'는 성립할 수 없지만, 제약이 없다는 전제하에 서술한다. 오픈 소스 엔진 대부분 GitHub에 업로드하니 더 많은 엔진을 찾고 싶다면 참고할 것.

※ A: 아파치 라이선스 B: BSD 라이선스 M: MIT 허가서 G: GNU 일반 공중 사용 허가서 Z: zlib 라이선스 더이상 지원이 끊긴것은 취소선 표시.

4.2. 공개된 상용 엔진

4.3. 비공개된 엔진

5. 자체 엔진

대부분의 게임 회사들은 언리얼 엔진이나 유니티 같은 상용 게임 엔진을 사용하지만,[25] 상당수의 게임 회사들은 자체적으로 게임 엔진을 만들어서 게임 개발에 사용 하고 있다. 하지만 게임 엔진을 만드는 것은 게임을 만드는 것보다 몇 배는 어려운 일이기 때문에, 자체 엔진을 갖고 있다는 것은 기술력을 입증 받는 편이며 홍보 수단이 되기도 한다. 그러나 결국 기술력에 대응되는 영역이기에 개발사의 역량에 따라 자체 엔진 역시 천차만별일 수 밖에 없다.

먼저 자체 엔진을 만드는 이유를 알아야 하는데, 가장 큰 두가지 이유는 수익과 생산성이다. 언리얼이나 유니티 같은 상용 엔진을 사용 하면 일정 수익 이상부터는 전체 수익의 일정 비율을 로열티로 지불하거나, 로열티 지불을 하지 않기 위해서 억 단위의 커스텀 라이센스 비용을 지불(매출이 수십억 단위로 발생하는 게임들의 경우)[26] 계약하기도 한다. 물론 그 만큼 상용 엔진을 사용해서 생산성을 챙겼으므로 게임 개발시, 어떤 엔진을 사용하느냐는 수익 예측과 절감할 수 있는 개발비를 비교하여 결정 하게 된다. 또한 상용 엔진은 결국 다른 회사에서 범용적인 게임 개발을 위해 개발한 엔진이므로, 자사에서 개발하는 게임에 맞게 기능을 추가하거나 수정하는 등의 개조 과정을 거친다. 그러나 만들고자 하는 게임이 독특하면 독특 할 수록, 많은 기능 추가와 개조를 해야 하므로 엔진을 새로 만드는 것이나 다름 없다. 그러니 결국 게임 엔진을 직접 만들게 되는 것이다.

5.1. 오래된 엔진은 성능이 떨어진다?

그렇지 않다. 오래전에 개발된 게임 엔진이라도 얼마든지 개량하고 업그레이드 해서 최신 엔진에 버금가는 성능을 만들어낼 수 있다. 물론 게임 엔진이 오래전에 개발되었을 경우 최신 기능을 지원하지 못하는 등의 문제가 발생할 수는 있다. 결국 기능을 수정하고 업그레이드하면 해결이 가능하지만 한국에 엔진을 개발할 수 있는 로우레벨 프로그래머가 거의 없으므로 불가능에 가까운 이야기. 그렇기 때문에 오래된 엔진에 대한 사람들의 인식이 좋지 못한 것이다. 게임 성능에 있어서 게임 엔진보다 개발사의 최적화 능력이 더 중요하다.

그렇다면 왜 상당수의 개발사들은 기존의 오래된 엔진을 계속 사용하려고 할까. 이는 신뢰도 때문이다. 게임 엔진은 결국 프로그램이다. 사용할 수록 마모 되는 것이 아니므로, 오래 사용된 엔진은 결국 동작에 대한 신뢰도가 확보된 프로그램이란 말과 같다. 설령 고칠 수 없는 버그가 있다 하더라도 어떤 버그가 있는지 파악되어있는 것이 낫지, 파악 조차 안된 새 프로그램은 신뢰도가 바닥이다. 새로 만든 엔진이 정상적으로 오류 없이 동작할 가능성은 매우 낮으며, 차라리 기존에 정상적으로 동작하는 엔진을 개량해서 사용하는 것이 더 신뢰도가 높기 때문이다.

5.2. 자체 엔진은 성능이 좋다?

개발사의 역량에 따라 다르다. 자체 엔진이란 해당 개발사의 현재 기술력이라고 봐도 무방한 영역이고 상용 엔진과는 다르게 개발사가 추구하는 게임 방향성에 따라 기능을 추가하거나 개조할 수 있는 권한이 있기에 개발에 이를 활용할 수 있는 장점이 있다. 자체 엔진이 성능이 좋다는 인식도 상용 엔진을 뛰어넘는 성능을 보여 준 사례가 있기 때문이고 개발사에 따라 상용 엔진보다 성능이 좋은 자체 엔진도 있다는 것은 분명하다.

국내와 중국에서는 상용 엔진의 비중이 높지만, 해외의 대형 AAA급 개발사들은 자체 엔진을 활용하는 곳도 상당하다. 락스타 게임즈의 RAGE, 캡콤의 RE 엔진, 게릴라 게임즈의 데시마 엔진, 유비소프트의 앤빌과 스노우드롭 엔진 등 준수한 성능을 자랑하는 자체 엔진은 꽤나 많고 이름이 붙지 않은 엔진들까지 포함하면 그 수는 훨씬 더 많다. 대표적으로 소니 산하 퍼스트 파티 개발사들이 사용하는 엔진도 대부분 각 자사의 자체 엔진들이다. 다만 이는 충분한 인력과 자원을 갖춘 특출난 예시들이고 대부분의 자체 엔진들의 실상은 이보다 훨씬 열악하다.

제대로 된 개발이나 개량을 거치지 못한 엔진은 뒤쳐지기 마련인데, 게임 엔진 개발이 가능할 정도로 다방면에 월등히 뛰어난 프로그래머는 매우 희귀하다.[27] 그렇기에 이런 인재들을 많이 확보할 수 있는 대형 개발사, 혹은 에픽게임즈나 유니티가 좋은 성능의 게임 엔진을 개발하고 유지하는데 유리한 위치에 있는 것이다.

개발사의 역량이 부족하여 자체 엔진이 발목을 잡는 경우도 있다. 대표적인 사례는 사이버펑크 2077 개발 당시에 CD PROJEKT RED가 사용했던 자체 엔진 REDengine 4. 위쳐 시리즈와 같은 세미 오픈 월드를 만들 때는 문제가 없었으나, 사이버펑크 2077와 같은 하나의 거대한 오픈월드를 만들기에는 엔진이 너무 무거웠고 출시 직후에는 엄청난 버그를 내뿜으며 평가를 땅으로 쳐박히게 만들었다.[28] 스퀘어 에닉스의 자체 엔진인 루미너스 엔진 역시 초창기에는 뛰어난 성능을 자랑했지만, 해당 엔진을 다룰 줄 아는 사람들이 많지 않아 시간이 지날 수록 스퀘어 에닉스 내에서 루미너스 엔진을 제대로 다룰 줄 아는 기술자들은 파이널 판타지 XV의 제작진으로 좁혀졌고 이 때문에 아예 이들을 루미너스 프로덕션으로 분리해 새로운 스튜디오를 만들었다. 루미너스 엔진은 파이널 판타지 XV 시절에는 어느 플랫폼에서든 뛰어난 비주얼을 유지하면서도 준수한 최적화를 보였지만, 정작 프로덕션으로 분리된 후, 계속된 업그레이드를 거치면서 점점 엔진이 무거워지며 Forspoken 개발 시점에서는 최악의 최적화를 보이며 안 그래도 최악인 작품성에서 비주얼마저 살리지 못했다.[29]

라이센스 비용만 지불하면 되는 상용 엔진이 대세로 자리잡으면서, 이 정도의 수준을 유지하기 위해서는 에픽게임즈와 유니티에서 게임 엔진만을 만들기 위해 근무하는 수백~수천명의 뛰어난 인재들을 상대할 수 있을 정도로 막대한 자원을 쏟아부어야 한다. 더하여, 자체 엔진은 개발자들의 커리어(=기술 스택)에 큰 영향을 미치므로 이직이 잦은 게임 업계에서는 자체 엔진이 개발자를 구직하는 것에 악영향을 끼칠 수 밖에 없다. 따라서, 대형 게임사라고 할지라도 한계를 느끼고 퀄리티는 동등 이상인데 자원 소모는 적고 개발자 모집은 쉬운 상용 엔진을 선택하게 되는 것이다. 결국 2020년대 오면서 자체 엔진의 선천적인 한계로 인해 차츰 초대형 개발사가 아닌 이상 AAA급에서도 갈수록 상용 엔진을 선호하고 있다.

6. 포크

다른 엔진을 개량하는 것에서 출발하여 더이상 원래 게임 엔진의 코드가 남아있지 않을만큼 개조가 많이 되었을 때 독립적인 게임 엔진의 상표권을 출원하는 경우가 있는데 이를 포크라고 부르기도 한다.

아래는 이렇게 개량의 과정을 거치면서 신규 엔진으로 포크된 사례들.

7. 게임 엔진을 백엔드 프레임워크로만 사용하는 경우

게임 엔진의 모든 요소를 사용하지 않고, 최신 게임 엔진을 백엔드 프레임워크(Backend Framework)로만 사용하고 실제 게임은 과거의 프로그램(엔진 포함) 그대로 사용하는 경우가 드물게 있다. 화면에 보이지 않는 뒷단의 일을 처리하는 부분만을 활용하는 경우로서, 게임 엔진의 플랫폼 지원(Win, Linux, Mac, 콘솔, 모바일 등), 비디오(OpenGL, D3D, Vulcan 같은 API 및 엔진의 기본 셰이더 등)와 오디오(OpenAL 같은 API 및 FMOD, WWISE 등의 사운드 엔진과의 융합 처리)의 출력, 키보드, 마우스, 컨트롤러 등의 입출력을 제어를 관장하는 부분 등으로만 최신 게임 엔진을 활용하는 것이다.

이런 방식을 사용하는 이유는 과거의 게임을 최신 플랫폼(최신 PC, 콘솔 등)에서 과거의 게임을 안정적으로 돌아가게 하는 것이 주목적이다. 이 경우, 실제 게임이 돌아가는 엔진은 원래 과거의 엔진에서 돌아가게 된다. 다음은 몇 가지의 사례다.

8. 미들웨어 종류/목록

미들웨어의 종류는 그 분류도 매우 다양하고 나와있는 제품들도 매우 많다.

이런 미들웨어들은 언리얼 엔진이나 유니티 엔진 같은 게임 엔진에 컴포넌트나 플러그인 형식 또는 완전히 결합하여 사용 가능하다. 예로 PhysX 물리 엔진은 언리얼 엔진과 유니티 엔진에 기본 물리 엔진으로 탑재되어 있고 Wwise 같은 오디오 엔진은 추가 플러그인으로 결합 가능하며, 전문 AI 엔진인 Kynapse 같은 것들도 언리얼 엔진 3에 결합해서 사용한 예(메달 오브 아너 등)가 있다.

8.1. 물리 엔진

해당 문서 참고.

8.2. 사운드 엔진

8.3. 모션

8.4. 기타 미들웨어

9. 관련 문서

[1] 둠 엔진, 퀘이크 엔진 등, 해당 게임의 제목이 붙인 엔진으로 불렸고, 게임 엔진이라는 말로 불리지는 않았다.[2] 자사의 게임 2개인 듀크 뉴켐 3D와 쉐도우 워리어, 타사의 게임인 블러드.[3] 한때 데드 스페이스 시리즈 등에 쓰이는 등 붐이 일었으나 이후 Flash의 하향세와 함께 내리막길을 걸었다.[4] 플스 3, 엑스박스 360 세대.[5] 이 문제는 C# 스크립팅을 사용하는 유니티 엔진의 점유율 확대로 인해 더욱 심화되었다.[6] 사이트가 잠시 접속 불가능하다가 복구되었다.[7] Windows, Linux, macOS, 안드로이드, 어도비 플래시, HTML5 등에 크로스 컴파일 할 수 있다.[8] 단, Cocos 2d-x처럼 순수한 코딩을 해야 한다.[9] 1.6버전까지[10] 실리콘 스튜디오로부터 독립되어 더이상 실리콘 스튜디오가 이 프로그램을 지원하지 않는다. 다만, 기존에 개발을 담당했던 개발자들이 실리콘 스튜디오 업무와 별개로 유지보수 및 버전업을 해주어 프로그램 개발 생태계를 유지하기로 했다고 한다.[11] 패트론으로 후원받는 것 외에는 없다.[12] 채팅, pvp[13] 워게이밍의 자회사였으나 2022년에 라이엇게임즈에서 인수하면서 라이엇의 자회사가 되었다.[14] 워게이밍 3부작이 전부 이 엔진을 사용했지만, 월드 오브 탱크는 이후 독자 엔진으로 갈아탔다.[15] 앵그리 버드가 이 엔진을 사용하는 것으로 알려져 있다.[16] 그래서 해당 엔진을 기반으로 하는 게임 엔진이 많다.[17] 기본적으로 남아있던 크라이엔진의 소스 코드 제외[18] 화이트데이의 맵파일을 골드 소스 엔진 기반 게임에서 실행하면 오류 없이 실행된다, 다만 프롭 배치같은건 다른 시스템을 써서 완전히 불러오지는 못한다. 특이한점이라면 더미데이터로 남아있는 멀티플레이어 맵 하나를 하프라이프에서 실행한다면 무기나 사다리를 탈 수가 있다.[19] 어쌔신 크리드과 페르시아의 왕자: 타락한 왕의 개발에 사용된 게임 엔진.[20] 어쌔신 크리드 2, 어쌔신 크리드: 브라더후드, 어쌔신 크리드: 레벨레이션에서 사용.[21] 어쌔신 크리드 3, 어쌔신 크리드 4: 블랙 플래그, 어쌔신 크리드: 로그에서 사용.[22] 어쌔신 크리드: 유니티, 어쌔신 크리드: 신디케이트, 어쌔신 크리드 오리진, 어쌔신 크리드 오디세이, 포 아너, 레인보우 식스 시즈, 고스트 리콘 와일드랜드에서 사용.[23] 이하 P.T[24] 현재 서비스가 종료된 소드 코스트 레전드와 개발 진행 중인 Survived by는 유니티 엔진을 사용하였다.[25] 이 때문에 게임 개발자의 경우 재직 중인 회사가 자체 엔진을 사용하면 타 회사로 이직시 어려움을 겪을 수 있다고 한다.[26] 커스텀 라이센스의 경우에는 조건에 따라 다르지만 일반적으로 1개 프로젝트 당 약 3~5억 정도를 지불하는 대신 매출이 수십~수백억, 또는 그 이상 얼마가 나오더라도 로열티 지불이 없다. 한국/해외 대규모 온라인 게임이나 대형 콘솔/PC 패키지 게임 등은 당연히 커스텀 라이센스로 계약되며, 로열티를 지불하는 계약은 사실상 인디 게임 또는 정말 규모가 작은 소규모 개발사에나 국한되는 정도다.[27] C와 C++, 심지어는 어셈블리어로 프로그램의 밑바탕을 만들어야 되는건데 이걸 할 수 있는 괴물 프로그래머는 거의 없다.[28] 결국 새로운 위쳐 시리즈 작품을 비롯한 차기작들부터는 언리얼 엔진을 사용하는 쪽으로 노선을 바꿨다.[29] 결국 루미너스 프로덕션은 본사에 흡수되고 이 엔진의 정통은 파이널 판타지 XIV에서 쓰였던 파생 엔진이 이어나가는 거나 마찬가지인 상황이 되었다.[30] 퀘이크 3 엔진(초기) → 퀘이크 3 팀 아레나 엔진(중기) → 리턴 투 캐슬 울펜슈타인 엔진(후기)[31] 마치 Xbox나 PS의 대쉬보드처럼 게임 중 어디서나 불러올 수 있는 UI 메뉴[32] 1. 헤일로 1, 2. 헤일로 2, 3. 헤일로 3, 4. 헤일로 3: ODST, 5. 헤일로 4, 6. 헤일로 리치 싱글 및 멀티, 7. 헤일로 1 애니버서리, 8. 헤일로 2 애니버서리, 9. 헤일로 1 멀티, 10. 헤일로 2 멀티, 11. 헤일로 3 멀티, 12. 헤일로 4 멀티, 13. 헤일로 리치 멀티[33] 원래 FMOD를 사용하였으나, 2014년에 교체하였다.[34] 원래 이 회사는 과거 세가의 모기업이었던 CSK의 소프트웨어 연구개발 계열 자회사 중 하나였다(CRI라는 이름도 구 사명이었던 CSK 기술 연구소에서 따온 것). 그래서 ADX도 그렇고 이 회사에서 개발한 기술들은 모두 세가 하드웨어 독점으로만 제공했으나, 세가가 하드웨어 사업에서 철수, 구조조정, 사미와 합병하는 과정에서 해당 기업도 CSK에서 분리. 현재는 세가와 남남인 기업이 되었다. 그래도 여전히 세가 게임에서 많이 사용중이다.[35] 모바일은 페이트 그랜드 오더, 데레스테, 밀리시타, 방도리 등등, PC는 판타시 스타 온라인 2


파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는
문서의 r259 판
, 번 문단
에서 가져왔습니다. 이전 역사 보러 가기
파일:CC-white.svg 이 문서의 내용 중 전체 또는 일부는 다른 문서에서 가져왔습니다.
[ 펼치기 · 접기 ]
문서의 r259 판 (이전 역사)
문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

문서의 r 판 (이전 역사)

분류