두 개의 별도 그래픽 라이브러리에서 동일한 게임 로직

게임 로직을 다시 코딩 할 필요없이 어떤 코드 철학 / 추상화 / 프로그램 설계 구조로 게임을 2D 및 3D 그래픽 (별도)과 함께 사용할 수 있습니까?

동일한 코드를 사용하여 최소한의 것을 변경하는 것 (예 : 2D 자산의 파일 이름을 3D 자산의 파일 이름으로 교환)과 제네릭 / 템플릿 당 기본 클래스의 몇 가지 전문화를 꽂을 수 있습니다.

실제 상황에 맞는 실제 상황에서 : 정말 좋은 게이머 리그를 보유한 플레이어를위한 최고의 성능, 배고픈 3D 클라이언트가있는 LAN 멀티 플레이어 게임을 상상해보십시오. 누군가 다락방에서 발견 한 먼지가 많은 상자. 그러나 그것은 여전히 ​​같은 게임입니다-같은 이벤트가 등록되고 (누군가가 동전을 줍습니다), 동일한 네트워크 프로토콜이 사용되며 세계는 비례합니다.

MVC 상황에 놓으려면 : 컨트롤러는 완전히 동일합니다 ( "Up"키를 누르면 플레이어 가속이 3.5 단위 / 초로 설정 됨). 뷰는 완전히 다르며 (2D 대 3D) 모델은 동일합니다 그래픽과 직접 관련된 모든 것을 제외하고 (환경에 대한 충돌 검사는 5 초마다 수행되며 동일한 알고리즘을 사용합니다. 이는 2D 버전의 모든 게임 오브젝트에 대해 Z 좌표가 있음을 의미하지만 예를 들어 플레이어가 공중에있을 때 더 왼쪽에 표시되는 그림자와 같은 다른 방식으로 사용자에게 무시되거나 표시됩니다.

이를 매혹적인 주제로 삼는 것은 개발자가 자신의 데이터가 어떻게 구성되어 있고 제어 흐름이 어떻게 진행되는지에 대한 명확한 아이디어를 가질 수 있어야한다는 것입니다. 이것은 SDL, D3DX 또는 OpenGL과 같은 그래픽 라이브러리 이외의 것을 사용하는 것을 의미하지 않습니다. 게임 엔진이 없습니다!

이것은 대부분 이론적 인 질문이므로 프로그래밍 언어는 사용하지 않겠습니다.하지만 예제를 제공하려면 원하는 언어, C ++을 사용하고 싶거나 Brainfuck이라고 생각하는 경우 사용하십시오. 도전에 이르기까지 (추상적 인 답변뿐만 아니라 추상적 인 답변도 높이 평가됩니다!).

나는 당신이 필요로하는 모든 것 (?)이 당신의 그래픽 라이브러리를 감싸는 추상화 층이라고 생각한다. 사용하려는 각 라이브러리마다 새로운 라이브러리가 필요하며 각 라이브러리에는 동일한 외부 API가 있어야합니다.

문자열의 현지화를 생각해보십시오. 문자열 "인벤토리"를 게임에 하드 코딩하는 대신 (맞춤식으로 제작 된) 현지화 라이브러리를 호출합니다.이 라이브러리는 상황에 따라 일부 프로세스를 수행하고 적절한 문자열을 반환합니다. 게임.

같은 방식으로 그래픽 엔진에 대한 모든 호출 은 래퍼를 통해 이루어집니다 .

이 작업에서 그래픽 엔진에 제공 할 수있는 명령을 제한 / 제한합니다. 몇 가지 필수 사항은 다음과 같습니다.

1. (위치)에서 (그래픽 객체) 그리기
2. (그래픽 객체)의 (알파, 회전 등) 속성 수정
3. (그래픽 객체)를 (위치)로 이동
4. (레벨 이름 / 데이터 구조)의 빌드 맵

프로젝트에서 작업 할 때 찾을 수있는 다른 것들도 있습니다.

엄격한 유형의 객체 지향 언어를 사용하는 경우 위 명령을 래퍼가 모두 구현할 인터페이스 를 호출합니다 . 바람직하게는, 이들은 유일한 비보호 / 공용 방법 일 것이다.

이제 각 그래픽 라이브러리에 대해 새 랩퍼를 작성 하고 API를 구현하십시오 . __에서 __ 을 그리는 명령 이 제공되면 코드를 사용하여 스프라이트 또는 모델을 작성하고 환경에 그려야합니다. 주어진 심볼에 의해 다른 시간에 다시 액세스 할 수 있도록 각 스프라이트를 해시에 저장하는 것과 같은 약간의 속임수가 필요할 수 있습니다.

맵을 작성하는 경우 가장 효율적인 방법은 각 그래픽 엔진에 대해 각 맵을 사전 빌드하고 조회하는 것입니다. 또는 사용자 정의 데이터 구조에 맵을 저장 한 다음 랩퍼를 사용하여 해당 데이터 구조에서 맵을 빌드 할 수 있습니다.

희망이 당신이 시작하는 데 도움이 =]

디스플레이 코드를 완벽하게 추상화 할 수 있도록 MVC에 가까운 패러다임으로 게임 아키텍처를 구축하는 것은 대규모 프로젝트에서 매우 어려울 것입니다. 그러나 2D 및 3D 클라이언트를 모두 지원하는 게임을 만드는 데 가장 큰 장애는 두 클라이언트가 모두 동일한 능력을 갖춘 게임을 설계하는 것 같습니다.

두 클라이언트를 만들고 지원하려는 의도로 게임 디자인을 시작해야하며 모든 게임 기능을 2D 클라이언트에 적합한 것으로 제한하는 것이 가장 안전 할 것입니다.

함정의 예로, 제한된 기능 세트로 설계하지 않은 경우 중요한 정보 나 객체가 특정 각도에서만 보이는 수준을 만들 수 있습니다. 2D 클라이언트가 각각의 중요한 객체를 볼 수있는 시야각을 명시 적으로 지원하지 않는 한 360도 자유롭게 시청할 수있는 3D 클라이언트에게는 문제가되지 않지만 클라이언트 사용자는 손상시킬 수 있습니다.

2D 클라이언트 (8 또는 16 이상)에 대해 특정 수의 시야각을 설정하고 이러한 제약 조건에 맞도록 모든 컨텐츠를 개발하는 것이 가장 좋습니다. 불행히도 특정 각도에서만 볼 수 있도록 설계된 레벨과 객체가있는 경우 3D 클라이언트 내에서 매우 이상하게 보일 수 있습니다.

제 생각에는 동등한 기능을 가진 2D 및 3D 클라이언트를 허용하는 게임 디자인을 선택하는 것이 좋지 않을 것입니다. 비대칭 게임 플레이 옵션을 디자인하고 각 클라이언트가 강점을 활용할 수 있도록 리소스를 더 잘 사용하는 것이 좋을 것 같습니다. 예를 들어 2D 클라이언트가 주로 게임 세계에서 전략적 수준의 관점에 초점을 맞추고 3D 클라이언트가 전술 수준의 게임 플레이에 사용되는 경우.

나는 당신이 당신 자신의 질문에 거의 대답했다고 생각합니다.

MVC 상황에 놓으려면 : 컨트롤러는 완전히 동일합니다 ( "위"키를 누르면 플레이어 가속도는 3.5 단위 / 초로 설정 됨). 뷰는 완전히 다르며 (2D와 3D) 모델은 동일합니다. 그래픽과 직접 관련된 것을 제외하고.

따라서 입력, 게임 로직 등과 그래픽간에 적절한 추상화를 제공하면 문제를 해결할 수 있습니다.

이는 기본적으로 MVC 모델의 요점입니다. 특히 데스크톱 및 웹 응용 프로그램과 관련되어 있습니다. 동일한 데이터에 액세스하고 조작하는 여러 클라이언트가있을 수 있습니다 (예 : 웹 인터페이스, 모바일 클라이언트 및 전자 메일 용 데스크톱 클라이언트).

간단하게 원한다면 간단하게 유지하십시오. 렌더링과 관련된 데이터를 저장하지 마십시오. -게임 데이터의 상태를보고 그릴 수있는 기회를주는 렌더러를 작성하십시오.

이를 위해 다소 복잡한 프로그래밍 기술을 사용할 수 있습니다. 필요한 것은 각 게임 오브젝트에 대해 렌더링해야하는 "추가"데이터를 얻는 방법입니다. 가장 간단한 방법은 추가 데이터가 전혀 필요하지 않습니다! 게임 개체가 "마법사"인 경우 마법사를 그립니다.

좀 더 복잡한 방법이 필요한 경우 다형성, 메멘토 패턴, 해시 테이블, void * 포인터 등을 고려하십시오. 너무 많이 엔지니어링하지 마십시오 (대부분의 방법은 오버 엔지니어링되었습니다).