베어 OpenGL은 소규모 개발자에게 프레임 워크 / 엔진에 비해 어떤 이점이 있습니까? [닫은]

인디 개발자들이 프레임 워크와 엔진에서 벗어나 OpenGL을 사용하거나 SDL / SFML2와 결합하여 사용하는 경향을 보았습니다. 인디 개발자로서 저급 OpenGL이 별도의 엔진 또는 프레임 워크에 제공 할 수있는 것을 볼 수 없습니다.

대부분의 괜찮은 엔진과 프레임 워크는 필요한 기능을 제공하며 절대 방해하지 않습니다. 또한 OpenGL을 직접 처리하는 옵션을 열 수도 있습니다. 일부는 크로스 플랫폼을 컴파일하는 기능도 제공합니다!

나는 후드 아래에서 일어나는 일을 배우려는 열망을 이해하지만 OpenGL이 엔진이나 프레임 워크를 통해 인디 개발자 에게 제공 할 수있는 단점을 볼 수 없습니다 .

OpenGL을 사용하여 게임을 처음부터 만드는 이유를 설명해 주시겠습니까?

이것은 주로 의견 기반 질문 / 응답이므로 실제로이 플랫폼에 이상적이지는 않지만 어쨌든 :

인디로서 프레임 워크 / 엔진이없는 이유는 무엇입니까? 여기 내 두 센트가 있습니다 :

• 예산 부족 : 아마도 대부분의 소규모 / 인디 개발자에게 가장 큰 포인트 일 것입니다. 많은 프레임 워크 또는 엔진을 사용하면 더 비싼 버전을 구매하지 않고 (저렴하거나 무료 버전을 사용할 수 있다고 가정 할 때) 제품을 게시하거나 로열티를 지불 할 수 없으며, 소규모 프로젝트에서는 항상 고려해야 할 사항입니다. 때로는 플랫폼 당 한 번만 지불해야 할 수도 있습니다.
• 복잡성: 대부분의 엔진 또는 프레임 워크는 다음 두 가지 범주 중 하나에 속합니다.
  • 그들은 하나의 특별한 장르에 대해 매우 제한적입니다. RPG Maker 가 전형적인 예입니다).
  • 또는 어쨌든 사용하지 않을 많은 것들 (예 : Unity )이 너무 일반적입니다 .
• 독점 코드 : 대부분의 엔진은 오픈 소스가 아니며 실제 소스를 얻으려면 더 많은 비용을 지불해야합니다 (가능한 경우). 실제 소스 코드없이 다른 플랫폼으로 포팅하는 것은 어렵거나 불가능할 수 있습니다 (다시, RPG Maker 는 완벽한 예입니다).
• 멍청함 : 이것은 내 개인적인 견해이지만, 적어도 나에게 이것은 종종 작은 게임을 만들 때 미리 만들어진 엔진과 프레임 워크를 고려할 때 다소 큰 실망입니다. 누가 200KB 정도의 작은 휴식 게임을 원하지만 50MB의 런타임을 제공합니까?
• 언어 선택 : 일부 엔진 및 프레임 워크는 자체 코드에서 사용할 라이브러리를 제공하지 않습니다. 대신 자체 스크립트 언어 또는 일부 설정 언어 (예 : Javascript 또는 C #)를 사용하는 프레임 워크 또는 런타임을 제공합니다. 고유 한 사용자 정의 엔진을 작성하는 경우 선택한 언어를 자유롭게 사용할 수 있습니다.
• 작업 보호 : 엔진 또는 프레임 사용하는 경우 다른 사람이 코드 나 자산을 변경하거나 디 컴파일하는 데 훨씬 더 쉬운 시간이있을 가능성이 높을 수 있습니다. 깨끗한). 사용자 지정 코드 및 자산 처리는 특히 기본 코드로 컴파일 할 때 훨씬 더 큰 장애물을 추가합니다.
• 브랜딩 : 이는 많은 사람들에게는 미미하지만 일부 엔진과 프레임 워크는 로고나 광고를 보여 주어야합니다. 본질적으로 누가 / 무엇을 홍보할지 자유롭게 선택할 수 있습니다. 물론 이것은 종종 실제 라이센스, 라이센스 비용 등에 의존합니다.
• 라이센스와의 비 호환성 : 엔진을 선택할 때 많은 사람들이 고려하지 않아도되지만 원하는 작업에 따라 중요한 요소가 될 수 있습니다. 엔진을 구입하더라도 소스 나 관련 자료를 공개하지 못할 수 있습니다. 이와 같이하면 사용자가 할 수 있기를 원하더라도 모딩이 불가능할 수 있습니다. Valve의 소스 엔진 ( Half-Life 2 , Team Fortress 2 등)을 예로 들어 보자 : 그들은 모더가 자신의 프로젝트에 엔진을 사용할 수 있도록합니다. 이러한 게임이 (예를 들어) 언리얼 엔진을 기반으로한다면 라이센싱 조건에 의해 제한되는 한계로 인해 불가능할 것입니다.

대부분의 괜찮은 엔진과 프레임 워크는 필요한 기능을 제공하며 절대 방해하지 않습니다.

그들은 할? 오히려 그것은 그래픽으로 말해서 당신이 무엇을하고 있는지에 달려 있습니다.

많은 종류의 게임에는 그래픽 질문에 대한 표준 답변이 있습니다. 예를 들어, 평균 2D 게임은 XNA / MonoGame과 같은 2D 기술로 잘 처리 될 수 있습니다. 그것은 단지 스프라이트로, 지형을 위해 배치로 나올 수 있고, 회전 할 수 있습니다.

그러나 게임이 어떤 경우 로 사용 평균 2D 게임, 당신은 화면에 깊이 상대의 외관이 사기꾼을 구축하는 높이 맵을 사용하는 등, 멋진 기술에 대해 읽어보십시오. 그리고 당신은 그것을하고 싶습니다.

이제 일반 매핑과 시차 매핑을 사용하고 있습니다. "렌더링 스프라이트"와 같은 맥락에서 많은 순수한 2D 엔진이 필요합니다. 특히, 다중 텍스처 "스프릿 블리 팅"이 필요합니다. 이는 많은 2D 엔진이 할 수있는 일이 아닙니다.

엔진이 적응할 수 없다면 어떻게해야합니까? 즉, 노멀 맵을 통해 색상과 조명에 대해 여러 패스를 수행해야합니다. 그러나 색상 조회에 시차 매핑을 적용하려면 노멀 맵의 높이 필드가 필요하기 때문에 작동하지 않습니다. 그래서 ... 지금 뭐? 투명성을 위해서는 알파가 필요하므로 알파를 훔칠 수 없습니다. 그리고 엔진은 다중 텍스처를 지원하지 않습니다.

따라서 다음 중 하나를 선택해야합니다.

1. 아이디어를 포기하십시오. 이것은 게임이 엔진에 의해 기능적으로 제한됨을 의미합니다.
2. 다중 텍스처를 갖도록 엔진을 해킹하십시오. 소스 코드에 액세스 할 수 있다고 가정하면 이제 다른 사람의 코드를 찌르기 위해 직접 소스 코드를 사용하고 있습니다. 이것은 또한 당신이 그것을 유지 하고 걸림돌로 그것을 깨뜨리지 않아야 함을 의미합니다 .
3. 엔진의 한계 내에서 최선을 다하십시오. 따라서 노멀 맵에서는 시차를 얻을 수 있지만 색상에서는 시차를 얻을 수 없습니다. 정확히 원하는 것이 아닐 수도 있지만 아무것도 아닌 것보다 낫습니다.

예를 들어, Geometry Wars를 보자. 대부분의 2D 엔진은 이러한 종류의 비주얼을 빨아 들일 것입니다. 대부분의 라인은 선이 아닌 스프라이트 그리기 주위에 만들어지기 때문입니다. 매우 특수한 종류의 렌더러가 필요한 게임입니다.

하루가 끝나면 게임 의 요구에 중요한 게임 요소를 책임 져야합니다 . 게임의 시각적 모양이 특정 효과가 아닌 사용하는 이미지 및 모델의 아트 스타일로 주로 개발 된 경우 사전 패키지 솔루션을 사용하는 것이 좋습니다. 그러나 게임의 비주얼 스타일이 커스텀 렌더링 코드에 의해 크게 정의된다면, 상자 밖에서 일을하기로 결정하면 표준 엔진이 심각한 제한이 될 가능성이 높습니다.

또한, 매우 실용적인 문제가 있습니다 : 모든 게임 엔진이 똑같이 이식성이있는 것은 아닙니다.

최근 모바일 플랫폼의 등장으로 게임 시장은 수많은 OS 및 사용자 인터페이스 장치에 퍼져 있습니다. 모든 엔진이 모든 장치에서 작동하는 것은 아닙니다. 엔진이 플랫폼에서 작동하지 않는 경우에, 당신은 확실히 시간이 걸릴하지 않을거야 만드는 것이 하나의 작업을. 결국 , 처음에 엔진을 사용하는 이유입니다 .

특정 플랫폼에서 게임 기능을하는 것이 중요하다면 다시 책임을 져야합니다. 그리고 성공을 보장하는 "가장 쉬운"방법은 직접 수행하는 것입니다. 여러 하위 플랫폼에서 작동 할 수있는 엔진을 구축하기 위해 일부 하위 수준의 세부 사항을 처리해야하는 경우 더 간단한 플랫폼 별 프레임 워크를 사용합니다. 그렇게하면, 그것이 깨지면 그것은 당신의 코드입니다. 당신은 그것을 고칠 수있는 가장 좋은 사람입니다.