게임 프레임 워크와 게임 엔진의 차이점은 무엇입니까?

게임 프레임 워크 (예 : C #을 사용하는 XNA, c ++를위한 SDL)와 게임 엔진의 차이점은 무엇입니까?

게임 프레임 워크는 엔진을 사용합니까? 게임 엔진은 물리 엔진, 파티클 엔진 등과 같은 하위 엔진을 캡슐화합니까? 그것들을 함께 사용해야합니까, 아니면 상호 배타적이어야합니까?

2D와 3D를위한 별도의 엔진이 있다고 생각합니까?

"엔진"또는 "프레임 워크"에 대한 엄격한 정의는 없습니다.

일반적으로 엔진은 프레임 워크보다 "더 많은 일을"하거나 더 많은 도구와 관련 지원을 제공하는 것으로 간주되는데, 이는 종종 자체 통합 API를 통해 노출되는 관련 기능의 느슨한 모음 일뿐입니다.

이를 위해 엔진이라고 주장하는 것은 기능을 달성하기 위해 프레임 워크라고 주장하는 것을 사용할 수 있지만 항상 그런 것은 아닙니다. 마찬가지로, 게임 엔진이라고 주장하는 것은 그것이 구성 요소 (물리 및 렌더링 등)가 물리 엔진 또는 물리 프레임 워크로 구현되었다고 주장 할 수 있습니다. 두 용어에 의해 언급 된 종류의 기술은 상호 교환 적으로 사용될 수 있거나 사용되지 않을 수있다.

물리, 사운드, 예, 심지어 2D 또는 3D 그래픽 등 거의 모든 것을위한 "엔진"또는 "프레임 워크"가 있습니다.

실제로는 용어 문제 일 뿐이며 일반적으로별로 중요하지 않습니다. 기능적 관점에서 게임 제작에 중점을 둔 관점은 문제의 기술이 게임 제작에 필요한 것을 제공하는지 여부입니다. 엔진 자체인지 프레임 워크인지에 관계가 없습니다.

내가 사용하는 간단한 정의 : 프레임 워크에서 엔진을 만들 수는 있지만 엔진에서 프레임 워크를 만들지는 않습니다. 하나는 건축과 프로그램 흐름을 결정하는 골격이고 다른 하나는 작업을 수행하는 근육입니다.

구체적인 예를 들어, Artemis는 컴포넌트 시스템을 구축하기위한 깔끔한 작은 프레임 워크이지만 결코이를 엔진이라고 부를 수는 없습니다. Artemis Systems 및 표준 구성 요소를 빌드하여 엔진을 작성할 수 있습니다.

프레임 워크는 (보통) 낮은 수준의 라이브러리와 도우미 (그래픽, 사운드 등)를 원하는대로 수행하는 데 사용할 수있는 도우미 항목의 모음입니다. 일반적으로 게임에서 공통적 인 작업을 수행하도록 최적화되거나 설계된 프레임 워크를 제외하고는 프레임 워크와 관련하여 게임과 관련된 것은 없습니다.

예 : 엔진을 사용하면 각각지도에 위치가있는 엔티티 목록을 가질 수 있습니다. 프레임 워크를 사용하면 특정 위치에서 3D 객체를 렌더링 할 수 있습니다.

따라서 각 엔티티에 3D 객체를 제공하여 연결하고 필요할 때 렌더링합니다.

그리고 따다, 당신은 게임이 있습니다.

자세한 설명을 보려면 Jason Gregory의 유일한 성경 게임 엔진 아키텍처 를 읽는 것이 좋습니다 . 나는 그것이 출판 된 이후이 주제에 관한 가장 완전한 작품이라고 생각합니다. 그것은 C ++ 부분을 처리 할뿐만 아니라 모든 게임 엔진 프로그래머에게 이론 / 아키텍처 뒤에 중요한 역할을합니다. 언어와 무관 한 좋은 출발점입니다. 우리가 이야기하고있는 것에 대한 개요를 얻으려면 이 이미지가 책에서

질문에 대답하려고 노력하겠습니다.

당신이 무엇을 작성하든 수년간의 경험을 쌓은 후에는 코드 :-)가 될 것입니다. 필요한 것과 필요한 방법을 쓰거나 필요한 것을 제공하는 것을 사용하십시오.

용어 엔진 및 프레임 워크는 다른 용어와 함께 소프트웨어 아키텍처에서 왔습니다. 기본 용어부터 시작하여 위로 이동합시다.

도서관

일반적인 예 : 수학 계산 (Vector, Matrix, ...) 또는 jpeg 또는 png 이미지 작성 기능을 제공하는 이미지 (jpeg 또는 png)를위한 모든 기본 유형 및 함수를 제공하는 수학 라이브러리

Unity 3D에서 Math 는 수학 라이브러리입니다.

이론 : libray는 주제 (예 : 수학)와 관련된 전용 기능을 제공 하며 필요할 때 프로그래머가 호출합니다 .

미리보기 : 프레임 워크 라이브러리 인 프레임 워크를 보유하는 라이브러리가있을 수 있습니다.

뼈대

이론 : 프레임 워크는 반전 제어를 도입합니다 . 즉, 개발자는 대부분 프레임 워크 메서드를 호출하지 않지만 프레임 워크는 개발자 코드를 호출합니다. 코드에 프레임 워크 라이브러리를 통합하고 프레임 워크를 시작해야하는 경우는 예외입니다. 프레임 워크 라이브러리는 전용 사용법으로 프레임 워크에 대한 모든 메소드와 함수 및 인터페이스를 제공합니다. 따라서 프레임 워크는 라이브러리에있을 수 있습니다.

전형적인 예 : Unity 3D MonoBehaviour 는 Awake, Start, OnUpdate와 같은 메소드를 제공합니다. 개발자는 이러한 메소드를 구현 한 다음 이 메소드를 (게임 오브젝트 관리) 프레임 워크에서 호출합니다 (제어의 역전입니다) . OnCollisionEnter, OnCollisionExit 메소드와 동일합니다. 그것들은 같은 Monobehaviour에 있지만 물리 프레임 워크에 의해 호출됩니다.

미리보기 : 엔진, 런타임, 편집기, SDK

엔진이라는 용어는 항상 애매 모호하고 여전히 기술적 인 발전으로 더 나아지지 않기 때문에 미리보기 설명입니다.

엔진이라는 용어는 여러 가지로 사용되며 어떤 것이 옳은지를 고유하게 말할 수는 없습니다. 2004 년에 처음으로 게임 엔진 작성과 접촉했을 때도 모호했습니다. 사전 정의 된 데이터를로드하는 일종의 코드를 의미하는 게임 엔진이 있으며 게임을 할 수 있습니다. 사전 정의 된 데이터를로드하기 때문에이를 데이터 구동 엔진이라고합니다. 한 번 컴파일하면 외부 데이터가 다시 컴파일되지 않고 다른 게임이 될 수 있습니다. 어느 시점에서 이것은 런타임과 동일했습니다.

에디터는 분명하다. 엔진 / 런타임에 의해로드 된 사전 정의 된 데이터를 정의 할 수 있습니다.

편집기가있는 엔진을 SDK (예 : Hammer SDK)라고합니다.

그런 다음 전용 엔진이있었습니다. 물리 엔진, 렌더링 엔진, 사운드 엔진, 게임 오브젝트 관리 엔진, 네트워크 엔진, ...

내 개인적인 견해로는 엔진이 아닙니다 (특히 렌더링 엔진은 렌더링 만하 기 때문에 게임 엔진이 아닙니다). Google 게임 엔진을 사용하면 게임 엔진이 아닌 90 % 순수 렌더 엔진이 결과에 포함됩니다. 모든 라이브러리를 호출하지만 사전 정의 된 데이터를로드 할 수 있기 때문에 데이터 구동 엔진이라는 용어와 일치합니다.

우리가 세부 사항에 들어가기 전에 마지막 짧은 쪽지 : 나는 컴퓨터 과학 석사 학위를 성공적으로 졸업했습니다. 제 석사 논문은 "게임 엔진의 핵심을 개발하는 방법"이라는 주제를 다루었습니다. 다른 모든 엔진을 하나로 묶는 코드의 일부를 의미하며 게임 객체 관리, 게임 루프 등을 수행합니다.

마스터 논문을 짧은 책으로 출판했습니다. 구매자 / 리더의 아마존에 대한 유일한 의견은 몇 년 후입니다. 이것은 게임 엔진에 관한 것이 아닙니다. 성공적으로 졸업하고 3 명의 숙련 된 프로그래머 (게임 및 대화 형 응용 프로그램에 전념 한 2 명)에 대한 논문을 방어 한 이후로 게임 엔진을 작성했다고 생각합니다.

편집자

쉬움 : 다른 부분에 필요한 형식으로 데이터를 정의 할 수 있으므로 해당 파일을 직접 작성하거나 외부 도구를 사용하여 만들 필요가 없습니다.

이것이 Unity 3D 편집기의 기능입니다.

실행 시간

이 용어는 종종 엔진과 동일하게 사용됩니다 (올바르거나 올바르지 않을 수 있음).

런타임은 생성 된 데이터를 실행하고 데이터와 관련된 작업을 수행합니다. 예를 들어 게임을 보여주고 게임을 할 수 있습니다. 게임 자체를 수정할 수 없다는 의미에서 데이터를 만들지 않습니다 (게임 저장 제외).

Unity 웹 플레이어는 웹 브라우저 내에서 Unity 게임을 플레이 할 수있는 런타임입니다.

동일한 런타임으로 여러 개의 다른 게임을로드하고 실행할 수 있습니다.

Unity 3D 스크립팅 API의 경우 게임에서 작동하는 기능과 편집기 내에서만 작동하는 기능이 잘려 있습니다.

SDK

이 용어는 종종 프레임 워크라고도합니다 .

당시 SDK는 편집기, 프로그래머를위한 IDE (통합 개발자 환경), 데이터 형식을위한 수출 업체 및 런타임 / 엔진과 같은 도구 번들이었습니다.

따라서 SDK / 프레임 워크는 사전 정의 된 워크 플로우 및 유틸리티를 제공하며 게임을 쉽게 만들 수있는 방법을 잘 보여줍니다.

기본적으로 Unity 3D 엔진은 SDK 방향에 더 적합하기 때문에 잘못되었습니다. 그러나 유니티는 그보다 더 새로운 단어 / 정의가 필요하기 때문에 더욱 그러합니다.

어쨌든 다른 용어를 소개하기 위해 SDK / 프레임 워크는 미리 정의 된 게임 개발 파이프 라인 (자산 파이프 라인뿐만 아니라 Unity, 자산, 논리, 빌드, 배포를위한 파이프 라인 등)을 제공합니다.

엔진

sarcasm on 라이브러리, 프레임 워크 또는 게임뿐만 아니라 완벽한 엔진을 작성하여 모든 사람이 시원하기를 원하기 때문에 모든 것에 사용됩니다. 빈정 거림

아래로 트리거 해 봅시다 :

엔진

1. 코드 / 소프트웨어입니다
2. 여러 프로젝트에서 재사용하는 것을 목표로합니다 (한 게임에 대해서만 게임 엔진을 작성할 수도 있습니다)
3. 게임 엔진을 재사용하기 위해 재사용 가능한 부분을 게임 특정 부분과 분리시킵니다.
4. 재사용이 가능하기 때문에 (재사용 의도에 따라) 외부 데이터를로드 하는 데이터 중심 엔진 과 같은 다양한 특징이 있습니다.

엔진은 다른 여러 엔진으로 구성 될 수 있습니다 (현재 모든 것이 엔진이라고 함). 게임 엔진은 다음을 포함 할 수 있습니다

• 렌더링을 수행하는 렌더 엔진 (AGAIN : god, damn, hell : 렌더링 만 수행하는 코드는 게임 엔진이 아님)
• 물리를 수행하는 물리 엔진 (게임 엔진이 아닌 물리 엔진 임)
• AI를 처리하는 AI 엔진 (게임 엔진이 아닌 AI 엔진 임)
• 네트워크 작업을 수행하는 네트워크 엔진 (예 : RakNet) (게임 엔진이 아닌 네트워크 엔진 임)
• 오디오 작업을 수행하는 오디오 엔진 (게임 엔진이 아니라 오디오 엔진 임)

컴포넌트 기반 게임 오브젝트 관리 모델에서 모든 것을 하나로 묶기위한 플러그인 기반 프레임 워크를 제공하는 코어 엔진 기반 애플리케이션의 예입니다. 각 하위 엔진 (렌더링 오디오)은 플러그인으로 게임 엔진에 추가 된 모듈입니다. 각 구성 요소는 하위 엔진 / 모듈의 일부일 수 있습니다. (컴포넌트 기반) 게임 오브젝트 관리는 분리 된 모듈 간의 연결 링크입니다.

게임 엔진에 가장 가까운 정의

게임 엔진 의 일부입니다 소스 코드를 게임의 모든 기능이 제공 되어 재사용 할 목적으로 여러 게임을 건너 당신에게 할 코드 및 실행 게임을. 따라서 라이브러리, 프레임 워크 또는 전용 엔진 (렌더링, 물리학 등) 인 코드의 다른 모든 부분 (렌더링, 오디오, 물리학, 게임 객체 관리, 네트워킹)을 함께 단서합니다 .

게임 엔진은 중간에 혼란입니다.

@Josh가 이미 언급했듯이 프레임 워크 또는 엔진에 대한 엄격한 정의는 없지만 개념 상 두 가지 모두 매우 다른 도구입니다.

프레임 워크에는 기본 API abastraction이 포함되어있어 성능, 호환성 등을 (일반적으로) 걱정하지 않고 플랫폼 또는 기능과 상호 작용할 수있는 사용자 하 이거 레벨 도구를 제공합니다. 제공 한 예제에서 SDL은 프레임 워크입니다. 플랫폼에 대한 욕설을 피하고 창 관리, OS 관련 사항 등을 걱정하지 않고 해당 계층 뒤에 소프트웨어를 구축 할 수 있습니다. 전체 소프트웨어를 구축하려면 미디어를 관리하기 위해 다른 프레임 워크가 필요합니다. 물리학을 관리하는 플랫폼, Box2D 등

엔진이 다릅니다.이 경우 도구는 개발에 필요한 모든 것을 제공하며 물리 엔진은 물리를 관리하는 데 필요한 모든 것을 제공하고 사용하기 쉬운 API를 제공하므로 물리 시뮬레이션을 구축하려는 경우 다른 타사 라이브러리가 필요하지 않습니다. 엔진은 프레임 워크, 기타 엔진, 인터페이스, 스 니펫 및 일반 코드 모음에 지나지 않아 다른 타사가 필요하지 않고 하위 레벨에 대한 걱정없이 프로젝트를 완료하는 데 필요한 모든 것을 제공합니다.