게임 개발자가 기존 엔진을 사용하는 대신 자체 엔진을 작성하는 이유는 무엇입니까?

나는 크고 잘 알려진 많은 게임 개발자들이 종종 자체 엔진을 개발하는 것을 관찰했습니다. 예로는 Valve, Crytek, Ubisoft, Epic Games 및 Square-Enix가 있습니다.

단순히 기존 엔진이 충분한 요구 사항을 충족하지 못하여 자체 개발할 수 있기 때문일 수 있습니까? 특정 엔진이 필요한 게임은 거의 상상할 수 없습니다. 유니 티나 언리얼 같은 것만으로도 모든 종류의 게임을 만들 수 있습니다. 그렇지 않더라도 소스 코드가있어 특별한 요구를 충족시키기 위해 수정할 수 있습니다.

게임 개발자가 기존 엔진을 사용하는 대신 자체 엔진을 작성하는 이유는 무엇입니까?

스튜디오가 기술을 "구입"하는 대신 "구축"을 선택하는 데는 몇 가지 이유가 있습니다.

• 레거시 기술; 스튜디오는 기존의 실행 가능한 미들웨어가 있기 전에 자체 툴체인을 구축하기 시작했을 수 있습니다.
• 특정 요구 사항; 스튜디오에는 기존 미들웨어에 적합하지 않은 특정 요구 사항 모음이 있거나
• 예산 문제; 스튜디오는 기존 미들웨어의 비용이나 계약 의무를 감당하지 못할 수도 있습니다.
• "여기서는 증후군이 아닙니다." 스튜디오의 기술 리더십은 그들이 구축하지 않은 기술에 대해 (합리적으로 또는 비합리적으로) 조심할 수 있으므로 완전히 이해하지 못할 수 있습니다.

일반적으로 비즈니스 성공에 중요한 것을 소유하고 제어하고 그렇지 않은 것을 아웃소싱하는 것이 좋습니다.

일부 스튜디오의 경우 게임의 디자인 또는 스토리 텔링 측면이 성공을 위해 활용할 것으로 예상되는 중요한 리소스 일 수 있습니다. 이러한 스튜디오의 경우 디자이너가 적절한 비전을 실현할 수있는 기술을 구입하는 것이 좋습니다.

다른 사람들에게는 기술이 성공의 기초가 될 수 있습니다. 예를 들어 MMO를 구축하는 스튜디오는 일반적으로 인프라 스트럭처가 성공에 중요하므로 자체적으로 인프라를 구축해야합니다. 기존 미들웨어는 일반적으로 적어도 "AAA"타이틀에는 적합하지 않습니다.

귀하가 기재 한 일부 스튜디오 (특히 Crytek 및 Epic)는 기본적으로 게임 시장에서 직접적으로 지배력을 행사하려는 시도를 중단 했으며, 게임 개발자보다 미들웨어 공급 업체보다 훨씬 더 많은 것을 확인했습니다.

Josh Petrie가 말한 것처럼 :

" 여기에 세워지지 않은 증후군 ;"

나는 또한 내 자신의 엔진을 작성하고 있으며 그 이유는 모든 개발자마다 그 이유가 다를 것이라고 생각하지만 실제로는 일반적으로 다른 사람들의 코드에서 일하는 것을 좋아하지 않습니다. 나는 내가 스스로 그것을 만들 수 있다고 생각한다면, 다른 어떤 것에도 정착 할 필요가 없다는 점에서 강박 적입니다 .

Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre 등 다양한 유형의 게임 엔진, 렌더링 API 등을 테스트했습니다. 더 많은 ... 게임을 시작하고 싶었습니다. 잘 문서화 된 진입 점 ...

그러나 내 문제는 당시 엔진 아래에서 무슨 일이 일어나고 있는지 전혀 몰랐습니다. 나는 좋은 통제력을 원했고 내 손등과 같은 프레임 워크를 원했습니다. "HEY! 내가 어떻게 작동하는지 배우고 이해할 수 있는 유일한 방법 은 내 엔진을 완전히 처음부터 완전히 구축 하는 것 입니다. 내 프로그래밍 역사의 대부분은 웹과 프로세싱 솔루션을 사용했습니다. -이것은 완전히 새로운 공 게임이었습니다.

내가 끝낸 것입니다.

그래서 이미 C #을 알고 XNA를 설정하기로 결정했으며 시작 방법 또는 위치에 대해 생각하기 시작했습니다. 아이디어가 필요했습니다.

무엇을하든 3D로 바로 들어가기 로 결정했습니다 .

아래로 기초를 얻는 것은 시원했다 - 스프라이트 배치 물건,하지만 진행으로 나는 새로운 장벽과 장애물을 발견하고 결국 -되는 첫 진짜 배치 제한 . 저의 목표는 언제든지 뷰 프러스 텀에서 최소 10000 개의 개체를 렌더링 할 수있는 게임을 구축하는 것이 었습니다.

Shader Based Instancing을 구현하는 새로운 여정에 착수했습니다 (그리고 HLSL을 배우는 동안 배웠습니다). 대신 XNA의 Model and Effect 객체를 사용하여 대체품을 작성했습니다. 처음에는 VBO 스트림을 이해하는 데 어려움이있었습니다. 나는 일을 망쳤습니다. 온라인에서 인스턴스화에 관한 질문을하고 GPU가 무엇을하는지 마침내 이해할 때까지 계속 유지했습니다. 그것은 지불했다; 이제 며칠 동안 PIX (dxsdk)로 VBO를 디버깅 한 후 뷰포트에서 2 만 개가 넘는 테스트 엔터티가 확대되었습니다.

이제 파이프 라인 렌더링 방식에 대한 "일부"아이디어가 있었지만 아직 완료되지 않았습니다. 결국 자체 게임 상태, 카메라, 포스트 효과 및 엔터티 오브젝트를 생성하고 XNA 컨텐츠 파이프 라인에서 자신 만의 고유 한 빌드를 생성했습니다. 로더 (XNB에 대한 개인적 싫어함)는 복잡한 깊이 정렬 및 혼합 상태로 분리 된 지오메트리 체인을 만들었으며, 스프라이트와 텍스트를 모두 게임 장면에 투영했습니다.

나는 거의 일년 내내 이것을 지속적으로 추가, 수정, 변경 및 실험했습니다. 결국, 그것은 꽤 나왔다. 나는 이제 내 아기를 창조했기 때문에 후드 아래에서 무슨 일이 일어나고 있는지 이해했습니다.

이제 내 엔진은 대부분 안정적이었고 거의 완성되었습니다. 완벽하지는 않습니다. 스크립팅이 불분명하고 GUI가 전혀 좋지 않았습니다. 그러나 나는 여전히 그것을 좋아했습니다. 수천 줄의 코드, 자산 및 미디어-개인 2GB git 저장소에 구멍이 뚫려 있었고 이전에는 결코 해 보지 못한 유형의 개발을 시도하는 데 어려움을 겪었습니다. 내가 극복 한 모든 장애물은 교훈과 구호였습니다.

나는 내가 원하는 거의 모든 것을 꺼내었다.

그러나 결국-나는 그녀를 내려 놓을 시간이라고 결정했습니다. 많이 나 자신이 인터넷에서 조언을 자신에 의해 이러한 거대한 엔진을 쓰는 만족 및 기타 gamedev 친구, 나는 내가 모든 것을 다시 그것을 할거야 결정으로 - 더 나은 그것을 - 지금이 시간 내가 있기 때문에 대부분 알고 내가하고있는 것.

그 프로젝트는 여전히 내 GIT 저장소에 자리 잡고 있습니다.

새로운 엔진 (이번 MonoGame)을 작성하는 두 번째 과정은 잘 진행되고 있습니다. 문제가 발생하면 해결하기가 더 쉽습니다. 덜 혼란. 나는 내 코드에 조금 '너무'붙어있는 경향이 있기 때문에 올해 내 게임을 공개적으로 보여줄 수 있기를 바랍니다.

결국 내 엔진을 작성하는 방법은 어떻게 '어떻게'배웠는지, 모든 구성 요소의 역할과 작동 방식을 정확히 알고 이해한다고 말할 수 있습니다. 실제로 다른 사람들의 코드, 특히 대규모 문서화되지 않은 프로젝트를 읽는 것을 싫어합니다. 나는 내가 사용하는 모든 것이 나에 의해 만들어지기를 바란다.

그래도 이건 나야 나는 미리 만들어진 엔진을 사용하지 않을 것입니다. 아마도 다른 사람의 코드를 완전히 다루고 앉아 처리하는 것보다 내 프레임 워크를 작성하는 것이 더 재미 있다고 생각하기 때문일 것입니다.

자신의 엔진을 작성하는 절대적인 핵심 이유는 (아직 아무도 이것을 부르지 않은 것이 놀랍습니다) 디버깅 입니다.

크고 복잡한 게임을 작성했고 여기에 충돌 버그가 있고 소스 코드가 있고 (소스 코드를 작성하여 해당 소스 코드에 친숙한 경우) 디버거를 프로세스가 충돌을 일으키는 원인을 찾으십시오. 끝난.

다른 사람의 상용 엔진을 사용하고 있고 해당 엔진의 소스 코드가없는 경우 (보통 그렇지 않은 경우) 자체 코드 내부에서도 발생하는 문제를 디버깅하는 중입니다. 엄청나게 더 어렵습니다. 엔진 자체에 버그가 발생하면 스스로 해결할 수 없습니다. 출시일로부터 일주일을 보내고 사용중인 엔진에서 충돌 버그를 발견하게하려면 어떻게해야합니까? 크래시 버그는 소유하지 않은 독점 엔진 내부에 있기 때문에 해결할 수 없습니다. 소스 코드가 있습니까? 이 문제가 발생했습니다. 공급 업체에 긴급 지원 요청을 접수하고 문제를 해결하는 동안 문제를 해결할 수 있기를 희망합니다.

게임 개발은 어렵지만 디버깅은 훨씬 어렵습니다. 필자의 책에서 게임 개발을 어렵게 만들지 만 디버깅이 더 쉬운 것은 큰 순이익이다.

여기에는 매우 좋은 답변이 있지만 중요한 추가 사항이 누락되었습니다.

오늘날 사용 가능한 많은 엔진이 전용 엔진으로 시작되었습니다 .

유비쿼터스이므로 Unreal을 예로 들어 봅시다.

오늘날 언리얼을 생각할 때 자신이 직접 빌드 할 필요없이 라이센스를 부여하고 사용할 수있는 엔진을 생각하는 경향이 있지만 항상 그런 것은 아니며 언리얼 엔진은 별도의 실체.

옛날 옛적에 언리얼 이라는 게임 이있었습니다 . 그것의 개발자들은 기존 엔진을 라이센스하기보다는 그들 자신의 엔진을 구축하기로 결정했다 . 여러 번의 반복을 통해 그 엔진은 오늘날 우리가 알고있는 언리얼 엔진이됩니다.

요점은 이것이 닭과 계란 문제라는 것입니다. 라이센스를받을 수있는 모든 미들웨어는 어딘가에서 시작되어 미들웨어로 시작되지 않는 경우가 종종 있습니다 (때로는 미들웨어가 되려는 의도 로 작성되지 않았으며 현재 상태는 사실상 사고 임). 사람들 은 궁극적으로 누군가 엔진을 작성해야하기 때문에 자신의 엔진 을 작성합니다. 오늘날의 전용 엔진은 미래의 라이센스 가능한 미들웨어가 될 수 있습니다.

스튜디오가 기술을 "구입"하는 대신 "구축"을 선택하는 다른 이유는 다음과 같습니다.

• 새로운 플랫폼 : 새로운 모바일 OS, 콘솔 또는 컨트롤러. 도약, 구글 글래스 등에 대해 생각하십시오. 플랫폼 간 지원이 어렵습니다.
• 새로운 게임 메커니즘 및 / 또는 게임 내 에디터 : 몇 년 전 FEZ에 대해 생각해보십시오 (2D 대 3D)
• 좋은 무료 오픈 소스 게임 에디터 부족 . 기존 게임의 기존 소스에 대한 좋은 문서가 부족합니다.
• 스튜디오 툴체인 의 툴 진화 (또는 새로운 툴 추가)
• 엔진 가격 및 라이센스 전쟁

또한 특정 요청 / 필요 및 엔진 가격 및 라이센스 전쟁으로 인해 일부 스튜디오에서 일부 엔진을 출시해야한다는 데 동의합니다.

다른 엔진을 "구매"또는 "사용"하는 좋은 동기는 다음과 같습니다.

• 코드 재사용 : 다른 게임에서 이미 사용 된 엔진은 테스트를 거쳤으며보다 안정적이며 첫날부터 필요한 대부분의 기능을 수행 할 수 있습니다.
• 확장 : 일부 오픈 소스 엔진을 확장 할 수 있습니다.
• 무료 : 또는 거의 무료입니다 . 무료 오픈 소스 엔진조차도 배우려면 약간의 개발자 시간이 필요합니다.

역사적 이유 (주로).
가격과 관련이 있습니다.

지난 몇 년 동안 Unreal 또는 CryEngine을 실행하는 것을 본 모든 게임은 막대한 금액을 지불해야했습니다. 특히 소스 코드를 얻으려는 경우 (예 : UDK가 아닌 UE를 원함)

그러나 이것은 바뀌었다. 이제 가격 경쟁이 시작되면서 모든 사람이 더 큰 엔진을 구입할 수 있습니다.
그 의미는 ...

• UE4와 CryEngine을 모두 사용하여 훨씬 더 많은 게임을 볼 수 있습니다.
  그러나 그들은 예전처럼 AAA 게임이 아닙니다.
• 각 프로젝트에 대한 맞춤형 요구 사항과 요구 사항은 사라지지 않습니다.
  Relic의 Warhammer40k / COH 엔진 또는 EA에서 장군이 사용한 엔진을 참조하십시오.
  따라서 더 큰 엔진을 감당할 수있는 사람이라도 반드시 더 나은 선택을 제공하지는 않습니다.
• 시장에 다른 사람들이 있습니다. 화합처럼.
  사람들은 사용 편의성, 빠른 성능 및 거대한 자산 저장소로 인해이를 좋아합니다.
  물론 Unity는 거의 모든 플랫폼에 배포 할 수 있습니다.

그래 과거의 요구, 가격 등.

팀 조직은 어떻습니까?

디버그 항목 뒤에는 문서 및 지원이 있으며 코드는 없습니다. 결국 건물 그룹이 내 엔진 코드에 닿기를 원하지 않기 때문입니다. 엉망이 될 수 있습니다.

이를 위해서는 지원 그룹이 필요합니다. 그러나 비용이 증가합니다. 더 많은 사람, 더 많은 장소, 더 많은 전화, 더 많은 관리 등 ...

이에 대한 한 가지 해결책은 미들웨어 회사에 아웃소싱하는 것입니다. 게임을 만드는 비즈니스, 즉 크리에이티브 그룹과 작가에게 리소스를 제공합니다.

신생 회사의 경우 사용하고 구축하지 않는 것이 나쁜 옵션은 아닙니다. 그리고 중요한 수입을 얻은 후에는 아마도 자신의 엔진을 만들고 싶을 것입니다 ...

잘. 개발자가 만든 자체 엔진을 사용하는 대부분의 게임. 자주. 타사 엔진으로는 할 수 없습니다. 그들은 자신의 게임 개발을보다 쉽게하기 위해 스스로 만들었습니다. 또는 가능합니다.

일반적으로 자체 엔진을 사용하는 많은 게임. 더 잘 작동합니다. 그들은 더 관습적이고 그들의 작업에 100 % 적합하기 때문입니다. 게임 자체는 다르게 느낍니다. 게임을하기가 정말 쉽다고합니다. 언리얼 엔진 또는 무엇이든. 일반적으로 더 많은 맞춤 엔진이 있으며 독특한 느낌의 게임이 만들어 져야합니다. 독창적으로 보이고 독창적으로 작동하며 사전 제작 된 엔진에서 제작 된 게임보다 성능이 뛰어납니다.

내 답변은 기존 답변과 다르므로 늦었지만 추가합니다.

질문이나 Witcher 시리즈에서 Valve 예제를 보면 프로세스는 다음과 같습니다.

• 엔진 라이센스
• 목적에 맞게 엔진 수정 / 적응
• 게임 출시 및 돈 창출
• 다음 게임을위한 자체 엔진 만들기

자체 엔진을 개발하는 거의 모든 재정적으로 합리적인 개발자가 동일한 접근 방식을 취합니다. 엔진을 수정하면 엔진 작동 방식에 대한 지식을 쌓고 라이센스가 부여 된 엔진으로 인한 설계 제약 조건이 발생합니다. 결국 그들은 엔진을 만드는 데 필요한 사내 지식, 엔진을 만드는 데 필요한 자금 및 전용 엔진의 혜택을받는 프로젝트를 갖습니다. 그 시점에서 엔진을 만드는 이유는 다음과 같습니다. 똑똑한 일이기 때문입니다.

저의 프로그래밍 교사는 API / 메서드 / 클래스 / 함수 만 사용하십시오.

당신이 그것을 빌드하는 방법을 모르고 다른 사람의 작업 기회를 사용하고 있다면 그것이 어떻게 작동하는지 알지 못하고 무언가가 어떻게 작동하는지 알지 못하면 오류와 문제가 발생하기 쉽고 혼란에 빠지기 쉽습니다.

복잡한 것을 배우면 이상한 문제가 생길 수 있습니다. 특히 게임 엔진을 사용하여 게임을 실행해야 할 때 예상치 못한 결과와 문제를 일으킬 수있는 게임 엔진과 같은 복잡한 것은 물론입니다.

게임 엔진은 논리 코드 나 다른 논리를 만들 때이를 따르지 않습니다. 예상 할 수있는 것이 있지만 실제로는 프로그래밍 언어에 대한 다른 사람들의 이해와 지식 또는 일부 시스템 작동 방식을 기반으로 모든 것이 만들어 질 것입니다.

예를 들어 수학 방정식을 작성하기로 선택하면 다항식, 미분 미적분학 또는 기본 기하학 또는 대수 또는 나에게 적합한 것을 표현할 수있는 많은 방법을 쓸 수 있지만 때로는 원하는 형태 / 형식으로 쓰려고합니다. 정점 조작을 많이 할 계획이라면 쉽게 사용할 수있는 것을 조작 할 수 있도록 기본 기하학을 사용 하여이 수학적 모델을 작성할 수 있지만 그래디언트를 사용하여 곡선을 변경하려면 미분 미적분에 초점을 맞출 수 있습니다. 쉽게 그라디언트 등을 조작하고 내가 쉽게 액세스 할 계획이라면 무엇이든 간다.

때로는 현재 게임 엔진이 내가 원하는 일의 유연성을 제공하지 않거나 어쩌면 당신에게 그 옵션을 제공 할 수도 있지만 게임 엔진이 주요 힘의 움직임과 조작의 원천으로 물리력에 초점을 맞추기 때문에 그렇게하기가 매우 어렵습니다. 게임의 객체

어쨌든 나는 내가 지적하려고하는 것을 분명히하기를 바랍니다.