게임 엔진 및 데이터 기반 디자인

데이터 기반 디자인에 대해 들었고 한동안 연구하고 있습니다. 개념을 얻기 위해 몇 가지 기사를 읽었습니다.

이 기사 중 하나는 Kyle Wilson이 작성한 데이터 기반 디자인입니다.. 그가 설명했듯이 응용 프로그램 코드 (예 : 메모리, 네트워크 ...와 같은 리소스를 제어하기위한 코드)와 게임 논리 코드는 분리되어야하며 게임 논리 코드는 외부 데이터 소스에 의해 구동되어야합니다. 이 시점에서 개발자는 게임 내 오브젝트에 대한 외부 데이터 (예 : 캐릭터 정보, 무기 정보,지도 정보 등)를 허용하는 일종의 게임 편집기를 작성한다고 상상할 수 있습니다. 시나리오 설계는 게임 디자이너가 게임 객체 내에서 상호 작용을 만들 수 있도록 프로그래머가 작성한 사용자 지정 언어 / 도구로 스크립팅됩니다. 게임 디자이너는 기존 / 사용자 지정 스크립팅 언어를 사용하여 게임용 스크립트를 작성하거나 도구를 끌어서 놓아 게임 세계를 만듭니다. 내가 생각할 수있는 툴 접근의 예는 월드 에디터로, 보통 Bliizard의 게임과 함께 제공됩니다.

그러나 또 다른 기사는 데이터 중심 설계 (데이터 중심 설계 의 경우) 사용에 대한 것 입니다. 저자는 게임 디자이너가 프로그래밍에 대한 부담을 가지고 있기 때문에 게임을 개발하는 데 더 많은 시간이 걸리기 때문에 데이터로 구동되는 게임 디자인을 허용하지 말 것을 제안합니다. 대신 스케치 디자인에서 자유롭게 게임을 프로그래밍하는 게임 프로그래머가 있으며 게임 프로그래밍이 완료된 후 게임 디자이너가이를 확인합니다. 그는 이것을 프로그래머 중심이라고 부릅니다. 이 방법에 대해 내가 생각하는 것은 내가 사용했던 방식과 비슷합니다. 게임 로직은 위의 아이디어에 따라 응용 프로그램 자체이며 응용 프로그램은 게임 편집기이며 실제 게임은 도구를 기반으로 설계되었습니다.

많은 프로젝트에서 게임 구성 요소를 재사용 할 수 있기 때문에 첫 번째 방법이 더 합리적인 것 같습니다. 데이터 기반 디자인에 반대하는 두 번째 방법에서는 게임 코드가 해당 게임에만 속합니다. 이것이 Warcraft가 원래 Warcraft 및 다양한 사용자 지정 맵과 같은 가장 많은 게임 장르와 실제로 새로운 장르를 정의하는 가장 유명한 DOTA 중 하나라고 생각하는 이유입니다. 이런 이유로 사람들이 월드 에디터라고하는 것이 게임 엔진이라고 들었습니다. 이것이 게임 엔진이 어떻게되어야 하는가?

따라서이 모든 후, 나는이 아이디어 (데이터 구동, 프로그래머 구동, 스크립팅 등)에 대한 나의 이해에 결함이 있는지 확인하고 싶습니다.

게임 (또는 모든 소프트웨어 제품) 데이터를 구동하는 것은 거의 항상 이점입니다. 유일한 단점은 관련 시스템을 구축하는 데 약간의 시간이 더 걸릴 수 있다는 것입니다. 그래도 프로그래머로서의 나머지 경력에 대해 보상을 줄 것입니다 (동일한 시간 동안 동일한 시스템을 재사용하지 않더라도 시스템을 구축하는 데 사용한 기술을 재사용하게됩니다).

당신이 연결된 두 기사의 분리가 플레이에 들어오는 곳 도전, 그리고이며, 무엇을 당신이 데이터를 넣어하도록 선택할 사람 이 해당 데이터에 대한 액세스 권한을 부여 선출. 기본적으로 데이터 중심 설계 및 개발은 정보를 외부 저장소에 저장하고 런타임에 해당 정보를로드하고 그에 따라 행동한다는 것을 의미합니다. 응용 프로그램 코드는 최종 결과가 생각되는 것을 직접 수행하는 응용 프로그램 코드를 작성하는 대신 외부 데이터가 알려주는 내용을 수행합니다. 복잡한 생각이 아닙니다.

복잡한 "컴포넌트 구동 아키텍처"를 구축 할 필요는 없습니다 (요즘 유행처럼). 텍스트 파일에 물리학 (중력, 복원 계수)을 조정하기위한 상수를 넣는 것은 데이터를 기반으로합니다. 스크립트 (루아 등)는 데이터 중심입니다. 레벨 데이터를 XML로 설명합니다. 그런 것.

데이터로 소프트웨어의 모든 구성 요소를 구동 할 수 있으며 원하는 구성 요소를 선택하여 선택할 수 있습니다. 개발자 시간은 비싸다. 특히 프로그래머 시간. 행동과 데이터를 외부 저장소에 저장하고 작은 변화가있을 때마다 게임을 다시 컴파일 할 필요가 없어서 당신이나 다른 프로그래머의 시간을 절약 할 수 있다면, 당신은해야합니다. 비용을 절감하고 더 빨리 일을 처리 할 수 ​​있습니다.

또한, "디자이너 디자인"을 시도하고 프로그래머가 "그 디자인을 현실화"하도록하는 데 큰 위험이 따릅니다. 프로그래머가 디자이너의 작업을위한 반복 루프에 존재하게해야합니다. 그는 코드 원숭이 일 뿐이며, 디자인에 대한 사소한 작은 조정을 끊임없이하고 있습니다. 이는 디자이너의 대리가 아닌 흥미로운 기술적 문제에 대해 작업하려는 대다수의 프로그래머에게 큰 타격을 줄 수 있습니다.

구체적인 질문이있는 경우 :

이것이 게임 엔진이 어떻게되어야 하는가?

"게임 엔진"에는 실제로 고정 된 정의가 없습니다. 일반적으로 게임을 만드는 데 사용되는 기본 기술의 통합 모음으로, 일반적으로 여러 관련 도구 (따라서 데이터 기반)가 지원합니다. 그러나 상황에 따라 상당히 다양합니다.

따라서이 모든 후, 나는이 아이디어 (데이터 구동, 프로그래머 구동, 스크립팅 등)에 대한 나의 이해에 결함이 있는지 확인하고 싶습니다.

구성 요소 기반 시스템과 데이터를 통합하여 데이터 기반 설계 및 개발이 무엇인지 지나치게 복잡하게 만들고 있지만 올바른 과정을 어느 정도 수행하고있는 것 같습니다.

두 번째 게시물의 저자로서 몇 가지 요점을 명확히하고 싶습니다.

1. Josh Petrie가 제안한 바와 같이 코드를 하드 코딩하는 대신 데이터를 사용하도록 코드를 구성하면 모든 것이 항상 승리합니다. 나는 다른 것을 제안하지 않았다. 나는 디자이너에게 모든 것을 밀어 넣는 것은 좋은 생각이 아니라고 지적했다. "데이터 중심 디자인"이라는 용어는 사람들마다 다른 것을 의미하므로 원래 기사를 쓸 때 더 구체적이었을 것입니다.
2. 내가 일한 모든 곳에서 엔진으로 조정할 수있는 데이터 구조를 만듭니다. 변경하기 위해 게임을 다시 컴파일 할 필요가 없습니다. 런타임에 숫자를 동적으로 변경할 수 있습니다. 데이터 구조는 종종 코드로 저장되지만 누가 변경하고 있는지에 따라 "데이터 파일"에서 쉽게로드 할 수 있습니다.
3. 대부분의 개발 환경은 C / C ++에 대해 특정 형식의 편집 및 계속 또는 모듈 재로드를 지원합니다.
4. 대부분의 게임 개발 스튜디오에는 게임 플레이 프로그래머가 있습니다. 그들의 작업은 종종 재미있는 경험을 만들기 위해 디자이너와 협력하는 것입니다. 그들의 주요 관심사는 기술적 인 문제가 아니라 코드에서 재미를 만드는 것입니다. 저는 수년간 게임 플레이 프로그래머로 일해 왔으며 기술적 인 문제를 해결하는 것보다 더 흥미 롭습니다. 저의 책임은 다양하지만 구현을 담당 할 때 가장 만족스러운 작업을 발견했으며 디자이너와 함께 멋진 무언가를 만들어 내고 있습니다. 디자이너 코딩 또는 스크립팅의 문제점은 프로그래머가 종종 버그를 분류해야한다는 것인데, 이는 프로그래머가 할 수있는 가장 재미있는 일 중 하나입니다.
5. 스튜디오에 가장 적합한 것은 게임에 따라 다릅니다. 게임을 만드는 데 오랜 시간이 걸리고 모드 커뮤니티에 게임 레그를 제공하고 범위가 큰 무언가를 만들고 싶다면 완전히 데이터 기반의 게임을 만드는 것이 합리적입니다. 많은 게임에는 그러한 목표가 없습니다. 그들은 2 년 안에 새로운 게임을 만들어 내야하며, 프랜차이즈가 없다면 이전의 게임과 다른 유형의 게임 일 것입니다
6. "디자이너"는 스튜디오마다 다를 수 있습니다. 다른 스튜디오에서 게임 플레이 프로그래머를 고용하고 디자이너라고 부르며 게임 동작을 스크립트로 작성하는 개발 스튜디오에 대해 들었습니다. 이것은 프로그래밍 코딩 / 스크립팅에 대해 교육을받지 않은 사람들을 갖는 문제를 회피합니다.
7. 게임 로직 코드와 엔진 코드 사이에는 항상 경계가 있어야합니다. 또한 일반적으로 객체 배치를위한 일종의 시각적 편집기가 필요합니다. 적의 위치가 하드 코딩 된 스튜디오에서 일한 적이 없습니다. 이들은 편집기에 배치됩니다. 내가 말하는 것에 대한 예를 제안하겠습니다. 디자이너가 적을 생각한다고 가정 해 봅시다. 디자이너는이 새로운 적 유형의 행동을 스크립트하는 것보다? 이것이 바로 데이터 중심 설계 (팀 모스가 쓴 것에 관한 관점)입니다. 내가 제안하는 방식으로, 프로그래머는 디자이너와 함께 일하고, 조정 가능한 매개 변수와 함께 재미있는 적을 만들고 나서 레벨에 배치됩니다.
8. 프로그래머가 작성한 기본 코드는 프로그래머가 작성한 스크립트보다 런타임에 더 빠르게 실행되며 기술에 정통하지 않은 사람이 작성한 스크립트보다 빠르게 실행됩니다. 이 성능은 어떤 종류의 게임을하고 있고 무엇을하고 있는지에 따라 중요하거나 중요하지 않을 수 있지만 고려해야 할 사항입니다.
9. 어떤 방법을 선택하든 게임간에 게임 코드를 공유 할 수 있습니다. 나는 당신 이이 시점에서 무엇을 얻고 있는지 확실하지 않습니다. 스크립트 언어 또는 시각적 도구를 사용하여 일부 동작을 정의하지 않더라도 게임 플레이 코드를 최대한 재사용 가능한 구성 요소로 구성해야합니다. 다음 게임에는 적용 할 수없는 것들이 항상있을 것입니다. 그러나 다음 게임을 시작할 때 내가 일했던 모든 장소는 후속작이 아니더라도 이전의 코드베이스로 시작합니다. 그런 다음 말이되는 내용을 유지하고 게임 관련 내용을 제거합니다.

결국, 옳고 그른 대답은 없습니다. 그것은 당신과 당신의 동료들이 편안하게 일하는 방법에 관한 질문입니다. 내가 그 블로그를 얼마 전에 썼을 때, 모든 작업이 디자이너들에게 어떻게 전달되어야하는지에 대해 많은 이야기가 있었고, 내가 알고있는 성공적인 게임 회사가 얼마나 다른 균형을 찾았는지에 대해 쓰고 싶었습니다.

또한, 참고로, 내 블로그 항목은 5 살입니다. 훨씬 더 많은 스튜디오가 스크립팅 언어로 이동하고 있으며 요즘은 아니지만 디버깅을위한 성숙한 도구를 만들고있는 것 같습니다. 이것이 나의 주요 불만이었습니다. 이 글을 쓸 때, 내가 사용하지 않은 Unreal Kismet이 존재하지 않았다고 생각하지만 스크립팅을 단순화하려고하는 것 같고 디버거가있는 것 같습니다. (어떻게 작동하는지 잘 모르겠습니다)

소규모 게임의 경우, 당신이 기술에 스크립팅 언어 또는 유사한 기능을 시도하고 롤링하고 싶지 않다고 생각하지만, 큰 팀과 기술에 헌신 할 시간이 많은 경우이 작업을 수행 할 수 있습니다 개발팀의 작업 방식에 따라 적절한 시간과 투자가 합리적 일 수 있습니다. 개인적으로 가비지 수집과 같은 "기능"을 자주 시도하고 해결해야하기 때문에 가장 쉽고 빠르기 때문에 가능한 한 오랫동안 C ++에 집착 할 것입니다.

BitSquid Tech Engine을 찾아야합니다 . DOD 개념을 사용하여 빌드됩니다. Niklas Frykholm 의 블로그 는 매우 흥미 롭습니다. 이 엔진의 설계 방법에 대한 많은 기사가 있습니다.

GDC 2011에서 Niklas는 Data Driven Renderer 에 대한 프레젠테이션을했습니다 .