내러티브 (또는 적어도 비 시공간적) 중심 엔진 / 프레임 워크가 있습니까? [닫은]

편집 (2) : 두 가지 대답이 있고 그중 하나를 받아들이지 않았으므로 여기에서 대답을 고려할 동기를 부여 할 것이라고 생각했습니다. 그러한 접근 방식을 강력하게 제안하는 것은 불가능하거나 전혀 유용하지 않을 것입니다. 대안 적으로, 텍스트 어드벤처 게임 / 대화 형 소설을 넘어서 적어도 다소 일반적인 그러한 시스템의 연구 (필드) 또는 예에 대한 언급.

내가 더 심층 조사를 한 척하지는 않았지만 내가 본 모든 게임 엔진 / 프레임 워크는 두 가지 형태의 모양 / 엔터티를 말하는 의미에서 영광스러운 그래픽 엔진과 같은 것으로 보입니다. 또는 "일치 된"어떤 형태의 동시성 모델을 갖는 3 차원 유클리드 공간은 이들 "엔티티"에 부착 된 어떤 형태의 논리를 지정할 수있게한다.

그런 다음 게임 "규칙"과 이야기는 이러한 기본 요소 위에 다소 임시 (엔진과 관련하여) 방식으로 작성됩니다.

분명히 위의 설명은 다소 간단합니다 (일부 형태의 퀘스트 / 서술 시스템을 포함하는 무한대 엔진과 같은 더 전문화 된 엔진을 사용하십시오).이 모델이 꽤 잘 작동 할 수 있음을 알고 있습니다 (많은 사람들이 그것을 사용한 것 같습니다) .

그러나 게임 규칙 / 논리 또는 서술 (또는 게임의 공간이 아닌 측면 )에 대한 (높은 수준의) 설명과 같은 개념을 기본으로하는 엔진 / 프레임 워크를 만들려는 시도가 궁금합니다. 기초?

편집 (4) : 이것은 게임이 공간 / 그래픽 측면을 포함하지 않는다는 것을 의미하지는 않습니다. 단지 논리를 연관시키는 공간 엔티티를 가지기보다는 음모 개념 (또는 게임 플레이 또는 "보드 게임 규칙")이 있습니다. )에서 그래픽 인터페이스에 대해 설명합니다.

특히 나는 실제 구현에 유용한 방식으로 합리적으로 큰 클래스의 게임에 대한 일종의 (반) 공식 의미를 캡처하려는 선언적 접근법에 관심이 있습니다 (예를 들어 독점적 인 프레임 워크와는 반대) 게임 / 내러티브의 질적 분석).

내가 본 것은 페트리 네트 기반 모델을 이용한 모델링 / 분석 서사에 대한 조사 와 대화 형 소설을 작성하기위한 언어에 대한 흥미로운 접근법입니다 .

편집 (1) : 나는 설명하기 위해 장난감 예제를 추가 할 것이라고 생각했습니다.

포인트 앤 클릭 스타일 어드벤처 제작에 관심이 있다고 가정 해보십시오 (SCUMM 게임 생각). 이러한 상황은 시작 상황에서 끝까지 다소 선형적이고 불연속적인 진행 개념에 기초한 것으로 분석 할 수 있습니다 .

불 연속적 진행이라는 개념에 중점을두고 비선형 성을 허용하기 위해 (경계 된) DAG 이론을 기본 이론으로 선택할 수 있습니다 . (이 이론에 상대적으로)이 유형의 게임을 가장 추상적 인 형태로 지정하면이 이론에 대한 추가 공리를 추가하는 것과 일치합니다 (이론은 이론이 특정 그래프를 지정 하거나 단순히 사람을 포착하는 데 필요한 모든 것을 포착하기에 충분 함). "음모").

이것을 실제 게임으로 바꾸는 것은 이제이 이론을 연주 가능한 것으로 임베드하는 HCI / 인터페이스 디자인 문제로 바뀝니다. "게임 지정"으로

위의 가상 시나리오에서 라이브러리에서 캡처 할 수있는 최소한 세 가지를 볼 수 있습니다. 첫째, 일반적으로 DAG 또는 그래프에 대한 변환 / 추론 도구가 필요합니다. 둘째, 사용자 인터페이스 라이브러리는 게임을 플레이 할 수있는 게임으로 그래프를 표현하는 것이 실제로 그래프를 모델링하는지 확인하는 데 도움이 될만큼 영리합니다. . 마지막으로 그래프를 지정하기위한 상위 레벨 라이브러리 모음을 제공 할 수 있습니다. 캐릭터를 표현하기위한 라이브러리와 그와 같은 관점에서 상호 작용하고 그래프의 일부를 생성하는 라이브러리 등이 있습니다.

일부 도움말 라이브러리가있는 저수준 구현이 아닌 DAG의 "중간"이론을 유지하는 이유는 무엇입니까? 정식 의미론의 일반적인 이유는 모두 정답입니다. 공식적인 토대를 결정 했으므로 게임의 특정 속성을 확인할 수 있습니다. 낮은 수준의 인터페이스 라이브러리에서 최적화와 같은 것에 대해 추론 할 수 있습니다 (우리가 원하는 것을 수행 할 수있는 DAG를 모델링하는 한) 높은 수준의 설명 (문자 / 대화 등)과의 비 호환성에 대해서는 걱정하지 마십시오. 이러한 설명은 이러한 구조를 설명해야합니다.

나는 위의 접근법이 특정 방식으로 작동한다는 것을 결코 암시하지 않으며, 아이디어는 DAG가 실제로 메모리에 보관되어 있어야한다는 것이 아닙니다 (오히려 람다 미적분학과 같은 계산 형식과 비슷한 것을 형성합니다) 그러나 이것이 내가 궁금한 접근 방식을 보여주기를 바랍니다.

요컨대,이 질문에 대한 다른 제목 은 Dijkstra가 어떻게 컴퓨터 게임을 만들었 을까요?

이야기와 게임 규칙에 대한 간단한 참고 사항 : 대화 형 소설에서는 게임이 분기 이야기의 그래프를 통과하는 것이라고 주장 할 수 있지만 궁극적으로 게임 메카닉 외부의 이야기는 읽을 수없는 무언가로 대체 할 수 있습니다. 그러나 게임을 완료하는 단계 (또는 플레이 할 때지는 단계)는 정확히 같습니다. 이것은 개발자가 다른 하나에 맞게 변경하기로 선택한 경우를 제외하고 이야기는 게임 플레이와 관련이 없음을 의미합니다. 게임에서 내러티브는 본질적으로 그 역학을 파사드로하여 그 내러티브를 즐기는 플레이어에게 역학을 더 강하게 만들 수 있지만, 그게 전부입니다. 내러티브가 엔터테인먼트의 기본 형태이며 게임 메커니즘이 대부분 과도하게 작동하는 일부 게임 (일부는 게임이라고 부르지 않지만)이 있습니다.Esther에게 , 그러나 개발자는 소설 작가보다 더 많은 이야기를하기위한 공식적인 방법이 필요하지 않으므로 이야기를 더 이상 고려하지 않을 것입니다. 일반적으로 말하자면, "플레이어 블 내러티브"처럼 보이는 게임은 내러티브없이 존재할 수 있고 의미있게 논의 될 수있는 게임 이벤트의 트리 또는 그래프입니다.

나는 내가 본 모든 게임 엔진 / 프레임 워크가 2 차원 또는 3 차원 유클리드 공간에서 모양 / 엔티티를 말하는다는 점에서 영광스러운 그래픽 엔진과 같은 것으로 보인다는 것을 알아 차렸다.

그렇습니다. 대부분의 "게임 엔진"은 분명히 "비디오 게임 엔진"이며, 시간이 지남에 따라 주요 역할은 게임 쪽이 아닌 비디오 게임의 소프트웨어 엔지니어링 쪽을 용이하게하는 것이 었습니다. 아마도 이것이 가장 새롭고 가장 비싸고 따라서 가장 위험한 측면 인 소프트웨어 엔지니어링이기 때문에 이치에 맞습니다. 이에 비해 추상적 인 의미의 게임 디자인은 도구를 사용하지 않고 수천 년 동안 수작업으로 이루어졌으며, 이는 왜 그런지에 대한 이유를 어느 정도 설명해 줄 수 있습니다.

게임 규칙 / 논리 또는 서술에 대한 (높은 수준의) 설명 (또는 적어도 게임의 비 공간적 측면)과 같은 개념을 기본으로하는 엔진 / 프레임 워크를 만들려는 시도는 무엇입니까?

내가 아는 한, 심각한 시도는 거의 없었지만 성공하지 못했습니다.

Storytron 은 하나입니다. "전통적인 대화 형 소설과는 달리 Storyworld는 게임 세계 지리 나 그것을 채우는 평범한 물건보다는 배우의 행동과 반응, 감정과 성향을 모델링하는 데 더 관심이 있습니다." 그것은 실제로 성공하지 못한 Erasmatron이라는 이전의 노력을 따르며 Storytron은 실제로 성공하는 것처럼 보이지 않습니다. 다음 기사는 이것에 대해 잘 읽었습니다. 용을 쫓는

덜 야심 찬 수준에서 간단한 게임을 표현하는 간단한 방법을 생각 해낸 사람들이 많이 있습니다. : 많은 중 하나 개 논문은 이것이다 보드 게임을 설명하는 매우 높은 수준의 언어 - Multigame는 (링크는 로그인 뒤에이지만, 당신이 그것을 검색 할 수 있습니다)하지만 마지막에있는 모든 가능의 컴퓨터로 읽을 수있는 세트입니다 상태, 상태 전이 및 승리 조건 또는 점수 유지 기능-체스와 같은 개별 보드 게임 또는 포커와 같은 카드 게임에는 적합하지만 대량의 연속 상태가있는 게임 또는 의미가 더 큰 의미가있는 게임에는 일반화되지 않습니다 시뮬레이션 (예 : 슈팅 게임) 또는 스포츠 (예 : 레이싱 게임). 이러한 게임은 단순한 게임 상태 트리를 통해 적절하게 표현할 수 없습니다.

이보다 복잡한 시스템에 대한 이해에 접근하는 한 가지 방법은 기존의 각 메커니즘을 여러 기본 형태 중 하나로 분류 한 다음 모든 게임 플레이가 이들 기본 유닛 또는 이들의 조합으로 구성 될 수있다. Dan Cook은 " What Is Game Mechanics ?" 라는 기사를 가지고 있습니다. 그리고 후속 " 게임 디자인의 화학"이것은 게임 디자인에 대한 이러한 구성 적 접근 방식을 문서화하려고 시도합니다. 이론 상으로는 그 위에 선언적 시스템을 구성하는 것이 가능할 수도 있지만 실제로는 역학이 게임의 작은 부분만을 형성하기 때문에 결과적으로 출력이 제한 될 것입니다 프리젠 테이션 프레임 워크 내에서 대부분의 게이머의 관심을 끌 정도로 유연하지 않습니다.

게임 디자인 개념을 공식화하려는 다른 시도는 종종 "게임 문법"이라고 불립니다. 그러한 기사 중 하나는 " 멀티 플레이어 게임 아톰 (Multiplayer Game Atoms) "이지만 이전의 다양한 작품을 다시 언급합니다.

포인트 앤 클릭 스타일 어드벤처 제작에 관심이 있다고 가정 해보십시오 (SCUMM 게임 생각). [...] 하나의 기본 이론으로 (바운드 된) DAG의 이론을 선택할 수 있습니다. [...] 먼저 DAG 나 그래프에 대한 변환 / 추론 도구가 필요합니다. 둘째, 사용자 인터페이스 라이브러리는 게임을 플레이 할 수있는 게임으로 그래프를 표현하는 것이 실제로 그래프를 모델링하는지 확인하는 데 도움이 될만큼 영리합니다. . 마지막으로 그래프를 지정하기위한 상위 레벨 라이브러리 모음을 제공 할 수 있습니다. 캐릭터를 표현하기위한 라이브러리와 그와 같은 관점에서 상호 작용하고 그래프의 일부를 생성하는 라이브러리 등이 있습니다.

여기서 문제는 컴퓨터가 프로세스에 많은 것을 추가하지 않는다는 것입니다. 이와 같은 게임 디자이너는 종종 게임을 통한 흐름을 보여주는 디지털 또는 물리적 형태의 그래프를 정확하게 그릴 것입니다. 이론적으로 게임을 완료 할 수 있는지 여부를 확인하는 것은 쉽지 않습니다. 포인트 앤 클릭 모험을 진행하기위한 다양한 규칙을 인코딩하는 것조차 간단합니다. 어려운 부분은 흥미로운 이야기를 따르고, 매력적인 세계를 설정하고, 게임과 인터페이스를 올바르게 묘사하기위한 예술 및 사운드 자산을 만들고,이를 모두 포함하는 다양한 소프트웨어 엔지니어링 작업을 수행하는 것입니다. 게임을 통한 중요한 상태의 방향 그래프는 일반적으로 비교적 사소합니다. 문제는 주변의 모든 것입니다. 그리고 이것이 그다지 관심이없는 이유입니다.

저는 개인적으로 현재 Storybricks 라는 제품에 대해 팀과 협력하고 있습니다다양한 규칙을 지정하여 재미있는 게임 플레이를 만들려고 시도하며 이러한 규칙은 사람의 초기 상태, 요구 등을 나타낼 수 있습니다. 이러한 규칙을 취하고 사람의 요구를 충족시킬 수 있는지 여부와 확인 방법을 확인하면 게임 내에서 완료해야하는 작업을 선언적으로 만들 수 있습니다. 그러나이 게임 자체가 본질적으로 재미있는 게임 플레이를 만들지는 않습니다. 일단 "X는 Y를 가져와야합니다."수준까지 추상화하면 플레이어는 패턴을 발견하고 즐기기를 중단하기 때문입니다. 예를 들어, 사람들은 Skyrim에서 자동 생성 된 퀘스트에 빠르게 지쳤습니다. 디자이너가 만든 미션에 비해 절차 상 생성 된 미션에는 고유 한 의미가 없다는 것을 알 수 있었기 때문입니다. ) 따라서 우리의 임무는 AI 방법을 사용하여 이러한 상황을 더욱 흥미롭게 만드는 것입니다. 이것이 우리가 여전히 연구하고있는 것입니다. (Storybricks는 아직 초기 알파 단계에 있습니다). 그러나 우리의 연구에 따르면 이와 같은 것을 시도하는 사람은 거의 없으며 매우 어려운 문제입니다.

선언적 접근 방식의 또 다른 문제는 그 기능을 사용할 수 없다는 것입니다. 과학자들은 상황을 해결할 수 있거나 일련의 논리 규칙이 일관성이 있음을 증명하기 위해 처리하기 쉽기 때문에 그것을 좋아합니다. 그러나 실제 세계에서는 컴퓨터 게임 프로그래머 나 최종 사용자 모두 일반적으로 결과에 초점을 맞춘 선언적 표현만큼이나 결과에 초점을 맞춘 선언적 표현에 익숙하지 않습니다. 현재 상위 10 개 프로그래밍 언어는 모두 필수적 이며, 실제 명령은 일반적으로 케이크를 굽는 방법 이나 가구를 만드는 방법에 관계없이 필수적입니다. 스펙트럼의 양쪽 끝에서 이러한 열의가 부족하다는 것은 현대 게임에 대한 공식적인 사양을 만들려는 상업적 인센티브가 없다는 것을 의미하며, 가까운 시일 내에 변경되지 않을 것으로 보입니다.

한동안 답장하는 방법을 고려하고 있는데 어떻게 넣을 지 잘 모르겠습니다.

좋은 질문입니다. 불행히도 대답의 종류는 게임 엔진은 물론 이런 식으로 프로그래밍하는 것이 이치에 맞지 않거나 이미 이런 종류의 것들이라는 것을 의미합니다.

객체의 물리적 존재를 정의하는 방법이 필요하기 때문에 그래픽에 대한 강조가있는 것 같습니다. 우리가 실제로 이야기하고있는 것은 차원의 표현이기 때문에 이것이 존재하기 시작하는 곳입니다. 그러나 지금은 이것을 무시합시다. 요점은 이것이 실제로 매우 관련이있는 것입니다. 공간의 표현을 허용하는 것은 본질적으로 게임 엔진의 프로그래밍을 많이 차지하는 것입니다. 그리고 디자이너가 멋진 장면을 만들고 싶다면 물건 배치 방법을 많이 제어해야합니다. 그래픽에 대해 많은 것을 보게 될 것입니다.

그래서 그것은 저수준 측면입니다. 누군가는이 모든 작은 기술적 문제에 대해 깊이 생각해야합니다.

내러티브와 게임 규칙에 관한 한? 그것은 게임 엔진이해야 할 일의 범위를 벗어났습니다. 이것은 개발 그룹이 들어오는 부분입니다.

또한 프로그래밍을 통해 아이디어를 표현하는 방법에 대해 많은 생각을하지 않은 것과는 다릅니다. 즉 컴퓨터 과학의 역사는 무엇 정말 입니다 . 그리고 이것이 게임 엔진이 종종 고급 언어에 대한 인터페이스를 갖는 이유입니다. 그것들을 통해 생각을 표현하는 것이 더 쉽습니다.

이를 염두에두고 이야기를 강조하는 게임을 위해 특별히 언어를 만들 수 있을까요? 아마 그렇지 않을 것입니다. 다시 말하지만이 모든 것이 대표적이다. 언어는 컴퓨터가 처리 할 내용을 컴퓨터가 알고있는 방식으로 세부 사항을 설명 할 수 있어야합니다. 게임 제작에 특정한 언어를 만드는 것이 목적이라면 모든 디자인 결정이 그 중심에 있어야합니다.

그리고 다시 말하지만, 많은 언어 선택이 있습니다. 그리고 게임 업계의 사람들보다 더 많은 사람들이 개발하고 있습니다. 일반적으로 그 중 하나를 사용하는 것이 좋습니다.

요약하면 흥미롭지 만 매우 어려운 질문을했습니다. 그리고 그것이 무엇인지, 또는 실제로 대답했는지 확실하지 않습니다.

* 편집 : 가늠할 때, 나는 그것이 존재하는 유일한 것처럼 3D 게임 엔진 만 고려하고 있다는 것을 알고 있습니다. 일부 게임에는 물리적 공간에서 행동하는 사람이 전혀 없습니다. 그러한 경우에는 게임 엔진이 많은 기여를 할 지 확신 할 수 없습니다.

취미 컴퓨팅의 역사 초기 (80 년대)에는 텍스트 및 스프라이트 기반 게임에 사용할 수있는 일부 상용 게임 개발 키트가있었습니다. 스프라이트 기반의 것은 현재 "그래픽 엔진"과 매우 흡사합니다.

다른 유형에는 자연어 구문 분석기와 같은 것들이 포함되었습니다. 이 유형은 현대의 "레벨 편집자"에있는 것 같습니다. 그것들의 대부분은 Lua 또는 Python 스크립팅과 같은 것을 지원하는 것으로 보입니다. 또한 오픈 소스 레벨 편집에서 많은 활동을 보지 못하지만 이러한 문제는 대개 해당 게임의 세부 사항과 매우 밀접하게 연관되어 있기 때문입니다. 저는 Elder Scrolls 구성 세트와 같은 것에 대해 여기서 생각하고 있습니다.

Kinect는 파서를 다시 가져올 수 있습니다. 오래된 텍스트 기반 어드벤처 게임의 팬으로서 베데스다의 방향에 대해서도 흥분합니다. 그것은 확실히 독점적이지만 어쩌면 젊은 천재 일 것입니다 ...