재생 시스템 : 입력 또는 이벤트 기록?


9

나는 이것을 읽었습니다 : 재생 시스템을 디자인하는 방법 그러나 그것은 실제로 내 질문에 대답하지 않습니다.

내 게임은 서버 "모델"및 "컨트롤러"와 별도의 프로그램으로 게임의 클라이언트 "보기"를 사용하여 빌드됩니다. (mmo 또는 약간의 멀티 플레이어 게임과 같은 방식). 서버 측은 항상 게임의 "진실"이며, 클라이언트로부터의 입력 및 출력 이벤트 및 "현재 상태"메시지로만 액션 요청을 수락합니다.

게임 모델과 규칙은 고정 된 "틱"업데이트 주기로 완전히 결정적이므로 서버 측에서 클라이언트보기로 전송 된 이벤트와 작업 요청을 모두 기록 할 수 있습니다. 둘 다 특정 사이클 번호와 관련이 있습니다.

문제는 : 이 경우 재생 시스템을 설정하려면 입력 또는 사용자 작업 요청 (여기에서 제안) 또는 이벤트를 사용해야합니까?

둘 다 정확히 동일한 출력을 줄 것으로 보입니다. 내가 볼 수있는 유일한 차이점은 다음과 같습니다.

  • 이벤트는 실제 출력을 제공하지만 이벤트를 제공하려면 조치 요청을 처리해야합니다.
  • 작업 요청은 기록 할 데이터가 훨씬 적을 수 있습니다.

고려해야 할 다른 것들이 있습니까?

답변:


5

결정 론적 시스템이 주어지면 논리적으로 동일하므로 요약이 매우 정확합니다. 그러나 출력 이벤트보다 입력 동작을 기록하는 데 도움이되는 두 가지가 더 있습니다.

  1. 액션을 저장하면 이벤트를 재생하는 것보다 더 많은 코드를 사용하므로 나중에 테스트 데이터로 사용할 수 있습니다. 이것은 크래시 버그를 진단하고 빌드 사이의 행동 회귀를 찾는 데 도움이 될 수 있습니다.
  2. 나중에 특정 작업에 대해 보내는 이벤트를 변경하거나 어떤 이유로 다른 클라이언트에 다른 이벤트를 보낼 수도 있습니다. 이 경우 재생이 유효하지 않거나 불완전해질 수 있습니다. 이론상 동일한 문제가 입력에 적용될 수 있지만 일반적으로 입력 도메인이 출력보다 더 제한되어 있으므로 변경 될 가능성이 적으며 이전 버전과의 호환성으로 쉽게 수용 할 수 있습니다. (입력은 플레이어 및 기타 입력 소스 (예 : 난수 생성기)가 수행 할 수있는 작업으로 제한되는 반면, 출력에는 이러한 입력의 모든 결과와 게임 힌트에 의해 생성 된 다른 출력 (예 : 프리젠 테이션 힌트,주기적인 서버)이 포함됩니다. 사이드 이벤트 등)

좋은 점, 특히 첫 번째 점. 나는이 사용을 잊었지만 매우 도움이됩니다.
Klaim

빙고, 특히 # 1. 입력 기록 시스템을 만들 시간이 있다면 모든 단일 테스트를 기록하고 재현하기 어려운 버그를 잡을 수 있습니다. 이러한 "희귀 사례"로그를 다시로드 할 수있게되면 코드를 단계별로 진행할 때 버그를 쉽게 발견 할 수 있습니다.
ChrisC

1

고려해야 할 몇 가지 사항이 있지만 모두 작동합니다.

먼저 시간 정보를 기록해야합니다. 다양한 프레임 속도의 게임에서는 특히 까다로울 수 있습니다. 리플레이 데이터가 게임이 원래 시뮬레이션에 사용한 정확한 타이밍 정보를 제공 할 수 있는지 확인해야합니다.

또한 게임 동작에 대한 조정을 고려해야합니다. 당신이 입력을 기록하고 경우 조정할 하나를 입력 처리 방법, 물리 해결 방법 등의 일부 기록이 무효화됩니다. 게임 이벤트를 기록하더라도 해당 이벤트가 해석되는 방식의 일부가 변경되면 문제가 발생합니다.

재생을 원할 경우 타이밍 정보와 함께 플레이어 엔터티의 특정 위치 및 회전 목록을 기록하는 것이 좋습니다. 재생을 실행하는 동안 최대한 많은 물리 및 기타 게임 플레이 로직을 비활성화하십시오. 이것이 얼마나 쉬운 지 또는 가능한지는 동기화해야하는 다른 개체 수에 따라 다릅니다.


질문에서 나는 게임 모델이 완전히 결정적임을 지정합니다. 물리학은 없으며 프레임 속도 변화는 클라이언트 쪽에서 만 볼 수 있으며 "틱"에 전적으로 의존하는 게임 모델에서는 볼 수 없습니다.
Klaim
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.