RPG 게임에서 여러 스토리 스레드를 처리하는 방법은 무엇입니까?

여러 스토리 스레드가있는 RPG 게임을 설계했습니다. 즉, 사용자의 선택에 따라 일부 일이 발생하거나 발생하지 않을 수 있으므로 여러 가지 방법으로 동일한 일을 달성 할 수 있으며 결말이 다를 수 있습니다.

나는 잘 작동하지만 하나의 큰 결함이있는 간단한 결정 엔진을 구현했습니다. 결정을 내리는 순간 이야기는 즉시 결정에 영향을 미치므로 먼 미래에 영향을 줄 결정을 내릴 수 없습니다. . 스토리는 트리 구조의 분기처럼 전개되므로 다음 노드를 항상 알아야합니다. 후드 아래에서 결정은 대기열을 사용하여 구현됩니다. 각 노드는 이전 노드와 다음 노드에 대해 알고 있습니다 (또는 결정 노드 인 경우 사용자 입력이 다음 노드를 설정하기를 기다립니다).

복잡한 의사 결정 엔진이있는 많은 게임을 보았는데 어떻게 만들어 졌는지 궁금합니다. 물건을 정말 쉽게 만드는 특별한 디자인이 있습니까? 누구든지 비슷한 일을 하고이 문제를 해결하는 방법에 대한 힌트를 줄 수 있습니까?

업데이트 1 :

중요한 점은 스토리 코드를 어떻게 든 독립적으로 유지하여 외부 파일에서 조작 할 수 있도록하는 것입니다. 나는 이것을 엔진으로 사용할 계획이므로 가능한 선택조차도 외부 파일에서 가져와야합니다. 코드는 완전히 추상적이어야합니다.

또한 디자인 솔루션, 그것을하는 좋은 방법, 다른 사람들이 그것을 어떻게했는지, 어떻게했는지에 관심이 있습니다.

architecture rpg

— 발렌틴 라두
소스

중요한 결정이 내려지면, 전 세계적으로 접근 가능한 변수로 추적하십시오 (이러한 변수의 배열은 관리하기가 쉬워집니다). 이 변수들은 게임 프로그램의 후반부에서 참조하여 적절하게 행동하거나 표시 할 수 있습니다. 예를 들어, 플레이어는 작은 나무를 심기로 결정하고 나중에 그 나무는 매우 크게 보입니다. 나무를 심지 않으면 그 나무는 게임의 같은 시점에 전혀 존재하지 않습니다.

— Randolf Richardson

예, 처음에는 그렇게했지만 코드와 독립적이어야합니다. 즉, 스토리는 외부 파일에서 완전히 조작 할 수 있습니다. 따라서 방금 말한 것을 일반화하고 프로젝트에 대한 통제력을 느슨하게하지 않는 방식으로 결정을 내릴 수있는 방법을 찾아야합니다 (몇 가지 결정이 있습니다). 질문을 업데이트합니다. 감사!

— Valentin Radu

더 구체적으로 말하면, 이야기가 그 선택을 할 수도 있고 그렇지 않을 수도 있기 때문에 전역 변수를 확인 if (isTree)하거나 유지할 isTree수 없습니다. 무슨 말인지 알아? 여러 이야기를 제공하는 선택 엔진과 비슷합니다.

— Valentin Radu

또한 이것은 또 다른 문제가 있습니다. 사용자가 우리가 나무를 심기로 결정했다면 isTree=true나중에 학교 동료와 싸우는 것과 같은 다른 일을합니다. 그가 엉덩이를 차기 때문에 이제 트리의 존재에 영향을주는 2 개의 변수 isTree==true' and didFightBrat == false`가 있습니다. 무슨 말인지 알아? 그리고 사슬은 영원히 계속 될 수 있으며, 나무의 존재는 알려지지 않은 수의 요인에 의해 영향을받을 수 있습니다. 무슨 말인지 알아?

— Valentin Radu

그런 다음 해당 데이터를 디스크의 파일에 저장하십시오. 정보를로드하고 저장하기 위해 두 개의 서브 루틴을 생성 한 다음 필요에 따라 코드의 각 부분에서 해당 루틴을 사용해야합니다.

— Randolf Richardson

답변:

큐를 DAG (directed acyclic graph)로 일반화 할 수도 있습니다. Wikipedia에서 이것에 대해 읽을 수 있습니다. 기본적으로 각 노드는 "의존하는"하나 이상의 부모 노드를 가질 수 있습니다. 사이클이 허용되지 않습니다. 즉 A가 B에 의존하는 경우 B는 A에 의존 할 수 없습니다 (직접 또는 다른 노드의 간접 체인을 통해).

각 노드는 "활성"또는 "비활성"상태이며 모든 부모가 이미 활성 상태 인 경우에만 활성 상태가 될 수 있습니다. 그래프의 구조 (어떤 노드가 있고 어떻게 연결되어 있는지)는 게임 데이터의 일부이지만 활성 / 비활성 상태는 플레이어의 저장 데이터의 일부입니다.

이렇게하면 다음과 같은 것을 모델링 할 수 있습니다. 나무를 심을 때 "plantedTree"작업을 활성으로 표시합니다. 그런 다음 나중에 게임에서 다른 작업 "treeGrown"은 "plantedTree"와 다른 노드 (스토리의 일부)를 부모로 지정합니다. 그런 다음 "treeGrown"은 플레이어가 스토리의 해당 지점에 도달했을 때만 활성화되며 "plantedTree"도 활성화됩니다.

부모 중 하나가 활성화되면 활성화되는 노드 또는 한 부모가 활성화하고 다른 부모가 비활성화 한 노드 등의 다른 기능을 포함 할 수 있습니다. 여러 개의 상호 의존적 인 스레드로 스토리를 작성하기위한 매우 일반적인 프레임 워크입니다.

— 나단 리드
소스

아주 좋은 답변입니다. 감사합니다. 실제로 사용자 진행률 저장과 같은 다른 문제도 해결합니다. 이것이 내가 필요한 것입니다.

— Valentin Radu

@NathanReed 왜 이것이 주기적 일 수 없었습니까? 비순환은 일반적으로 기능이 아니라 그래프 디자인의 부산물입니다. 나는 그런 의도로 그것을 만들지 않을 것입니다. 예를 들어, 나무가 계절을 인식하도록했는지 상상해보십시오. 그것들은 본질적으로 주기적이며, 당신의 이야기는 한 시즌 동안 가능한 선택에 따라 동일 할 수 있습니다.

주기가있는 경우주기의 노드가 활성화 될 수 있는지 여부를 알아볼 때 무한 루프에 빠지기 때문에 비 주기적이어야합니다. 노드 자체를 포함하는 모든 조상을 재귀 적으로 검사하기 때문입니다. 계절과 같은 것을 모델링하고 싶다면이 그래프의 맥락에서 그렇게하지 않을 것입니다.

— Nathan Reed

@NathanReed Ah, 죄송합니다. 재귀 부분을 놓쳤습니다.

내가 이해하는 것에서, 당신이 원하는 것은 의사 결정 엔진뿐만 아니라 규칙 엔진입니다. 각 결정마다 해당 결정에 의해 정의 된 규칙의 하위 집합을 실행합니다. 이러한 규칙의 실행은 종종 트리 예제와 같은 특정 엔티티의 상태에 따라 다릅니다.

기본적으로 플레이어가 결정을 내릴 때 해당 결정을 검색하고 규칙을 실행 한 다음 다음과 같이 사용 가능한 다음 결정을 제공합니다. 그러나 규칙 중 일부는 이미 실행 된 다른 규칙에 따라 실행되기 때문에 동적입니다.

Wikipedia 에 대한 추가 정보 .

에서 자신의 할 때 사용 규칙 엔진 부제목 (강조는 나의 것입니다) :

문제는 전통적인 코드로는 너무 복잡합니다.
문제는 복잡하지는 않지만 문제를 만드는 강력한 방법을 볼 수는 없습니다.
문제는 명백한 알고리즘 기반 솔루션을 넘어선 것입니다.
해결하기가 복잡한 문제입니다. 명백한 기존 솔루션이 없거나 문제를 완전히 이해하지 못했습니다.
논리는 자주 바뀐다
논리 자체는 간단하지만 규칙이 자주 변경됩니다. 많은 조직에서 소프트웨어 릴리스는 거의 없으며 규칙은 합리적으로 안전한 방법으로 필요하고 예상되는 "민첩성"을 제공하는 데 도움이됩니다.
도메인 전문가와 비즈니스 분석가는 쉽게 구할 수 있지만 기술은 아닙니다.
도메인 전문가는 종종 비즈니스 규칙 및 프로세스에 대한 풍부한 지식입니다. 그것들은 일반적으로 비 기술적이지만 매우 논리적 일 수 있습니다. 규칙을 사용하면 논리를 자체 용어로 표현할 수 있습니다. 물론 그들은 여전히 비판적으로 사고하고 논리적 사고를 할 수 있어야합니다. 비 기술적 인 직책에있는 많은 사람들은 형식적인 논리에 대한 교육을받지 못하므로주의해서 작업하십시오. 비즈니스 지식을 규칙으로 체계화하면 비즈니스 규칙 및 프로세스가 현재 이해되는 방식에 빈틈이 생길 수 있습니다.

한 가지 주목할 점은 규칙 엔진은 단순화 된 도메인 별 "언어"또는 YAML과 같은 것을 사용하여 구현하는 것이 가장 좋습니다. 나는 XML을 제안하지 않을 것이다.

이벤트가 순전히 사용자 결정에 기초한 것은 아니라는 점을 고려해야합니다. 언급했듯이 일련의 결정 순서가 취해 지고 이틀 후와 같이 다른 것이 추가되면 일부 이벤트가 추가되어야합니다 .

내가 생각하는 것은 이벤트를 모델링하고 트리거하는 방법입니다. 첫 번째는 특정 사례와 더 밀접한 관련이 있지만 후자는 이벤트를 직접 또는 간접적으로 트리거하는 계층 적 상태 시스템 (HSM)으로 모델링 할 수 있습니다.

상태 머신은 계층 구조에 의해서만 완화되는 차원의 저주로 고통받습니다. 곧 HMS를 사용하여 상태의 복잡한 의미를 모델링해야하지만 쿼리 방법도 제공한다는 것을 이해하게 될 것입니다.

이 시나리오에는 HSM과 기본 이벤트 콜백 모두에서 처리되는 기본 이벤트 (사용자 결정, 시간, 날씨 변화 등)가 있습니다. HSM은 "메모리"에 대한 모델을 제공하고 콜백은 일련의 결정 / 외부 이벤트의 결과를 계산하기 위해 메모리를 사용해야하는 방법을 설명하는 방법을 제공합니다.

또한 계산해야 할 상태의 각 "종횡비"마다 하나씩 HMS의 디지털 (또는 다른 수집 구조)을 사용하게 될 수도 있습니다. 예를 들어 HMS 이벤트 관련 이벤트를 사용하고 이벤트를 트리거하기 위해 콜백이 내리는 결정에 하나를 사용할 수 있습니다.

이 모든 인프라는 인간 던전 마스터의 행동을 모방하는 목적으로 사용됩니다. 그는 일반적으로 플레이어의 결정과 환경 조건으로 인해 현재 상황 (HMS [ "외부"])을 정신적으로 기록합니다. 무언가가 추가 될 때, 그것은 정신 기록을 사용하여 결정을 내리고 어떤 상황이 추가되는 경우 비슷한 방식으로 반응하지 않도록하기 위해 내부 전략 상태 (HSM [ "internal"])도 기록 할 수 있습니다.

— FxIII
소스