비디오 게임의 개발에 기반이 되는 구성 요소들을 가진 필수 구성 요소들인 그래픽 엔진, 물리 엔진, 오디오 엔진, UI 시스템, 게임플레이 프레임워크 등이 잘 융합된 상태의 소스 코드와 그 기능들을 디자이너들이 사용 가능한 툴을 겸비한 게임 개발 소프트웨어를 일컫는 말이다. 태초의 게임 엔진이 나무도막이나 모래상자 수준이었다면 현대의 게임엔진은 자동차 생산 라인이라고 봐도 무방할 정도로 많은 기능을 제공한다.

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

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

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

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

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

이러한 소스코드 재활용을 나쁘게 생각하는 유저들도 있으나, 그것은 눈으로 보이는 것밖에 볼 줄 모르는 유저들의 옳지 않은 생각이다. 게임을 하나 개발하는데에는 막대한 금액의 투자가 필요하며, 비용을 회수하기 위해 들이는 노력을 가볍게 폄하해 버려서는 안된다. 그래픽만 바꾸는데에도 어마어마한 돈이 들고, 보이지 않는 부분을 수정, 개량하는 노력 또한 필요하기 때문이다. 더욱이 이렇게 코드를 재활용해도 1-2년만 지나면 또 새로운 기술이 나오고 그것을 적용해야 하는데 돈이 들어가기에 이는 결코 게으름에서 나온 요령이 아니다. 특히 이러한 코드의 핵심부분은 보통 그 팀 또는 코드 제작그룹의 최고 전문가가 어셈블리 코드로 최적화한 고도의 루틴이 들어가 있는 관계로 쉽게 갈아치울 만한 것이 못 되었다.

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

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

사실상 처음으로 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.를 거쳐 가장 최신 게임인 모르도르까지 이름을 이어오고 있다.

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

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

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

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

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

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

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

현대의 게임 엔진은 완전한 통합 게임 개발 솔루션을 표방하며 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]으로 자체 엔진을 만들어 쓰는 회사는 거의 없고, 넥슨의 데브캣 스튜디오, 검은사막을 개발한 펄어비스 정도가 전부이다. 이마저도 넥슨은 사내에서 해당 엔진을 전사적으로 공유하는 것이 아니라 데브캣 내에서만 쓰는 중이다.

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

대부분의 게임 회사들은 언리얼이나, 유니티 같은 상용 게임 엔진을 사용 하지만, 상당수의 게임 회사들은 자체적으로 게임 엔진을 만들어서 게임 개발에 사용 하고 있다. 하지만 게임 엔진을 만드는 것은 게임을 만드는 것보다 몇 배는 어려운 일이기 때문에, 자체 엔진을 갖고 있다는 것은 기술력을 입증 받는 편이며 홍보 수단이 되기도 한다. 문제는 게임 엔진에 대한 이해도가 부족한 상태에서 업계인 및 게임 유저들은 이에 대한 잘못된 환상을 품기도 한다.

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

그렇지만도 않다. 게임 엔진은 자동차 엔진처럼 물리적으로 존재하는 것이 아니므로, 얼마든지 개량하고 업그레이드 해서 최신 엔진에 버금가는 성능을 만들어낼 수 있다. 물론 게임 엔진은 프로그래밍 언어로 개발 하므로, 핵심 기능이 너무 오래전에 개발 되었을 경우, 최신 기능을 지원하지 못한다던가 등의 문제가 발생 할 수 있다. 결국 기능을 수정하고 업그레이드 하면 해결 가능하지만 한국에 엔진을 개발 할 수 있는 로우레벨 프로그래머가 거의 없으므로 불가능에 가까운 이야기. 그렇기 때문에 오래된 엔진에 대한 사람들의 인식이 좋지 못한 것이다.
그렇다면 왜 상당수의 개발사들은 기존의 오래된 엔진을 계속 사용 하려고 할까. 이는 신뢰도 때문이다. 게임 엔진은 결국 프로그램이다. 사용 할 수록 마모 되는 것이 아니므로, 오래 사용된 엔진은 결국 동작에 대한 신뢰도가 확보된 프로그램이란 말과 같다. 설령 고칠 수 없는 버그가 있다 하더라도 어떤 버그가 있는지 파악되어있는 것이 낫지, 파악 조차 안된 새 프로그램은 신뢰도가 바닥이다. 새로 만든 엔진이 정상적으로 오류 없이 동작할 가능성은 매우 낮으며, 차라리 기존에 정상적으로 동작하는 엔진을 개량해서 사용 하는 것이 더 신뢰도가 높기 때문이다.

그렇지만도 않다. 오히려 앞에서 말한 오래된 엔진의 성능은 타당하기라도 하지, 이건 더 현실성이 떨어진다. 게임 엔진 개발이 가능한 뛰어난 실력의 로우레벨 프로그래머는 전세계를 뒤져봐도 턱없이 부족하며, 한국은 더더욱 없다. 그나마 개발이 가능한 뛰어난 실력의 프로그래머들 대부분은 대기업이나 해외로 빠져나가는 편이다.
업계 종사자들 사이에서도 자체엔진이 좋게 평가받는 것은 손에 꼽을 정도이다. 게임 기획자의 경우, 업계가 언리얼 엔진이나 유니티 엔진을 사용하는 곳이 많은데 재직중인 회사가 자체 엔진을 사용하면 경력에 도움이 안 된다. 더군다나 자체 엔진은 일단 돌아가야 하므로 대부분 기능 개발의 우선도가 높은데, 따라서 상용 엔진에 비해 사용 편의성이 엄청나게 떨어진다. 즉, 배우기도 힘들고, 성능도 떨어지는 것이다.
그럼에도 불구하고 자체 엔진을 만듦으로써 이로운 점은, 해당 엔진에 문제가 있거나 기능 추가나 개선이 필요할 때, 엔진 개발자가 같은 회사에 있으므로 긴밀한 협조를 얻을 수 있다는 점 정도이다. 즉, 다른 개발자에겐 그런 정도 외엔 이로운 점이 거의 없다.

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

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

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

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

해당 문서 참고.