서버의 게임 로직! 좋거나 나쁘거나?

저는 현재 간단한 온라인 멀티 플레이어 게임을 계획하고 있습니다. 그리고 여기 질문이 있습니다. 서버에서 전체 게임 로직을 만들고 클라이언트에서 서버로 입력을 보내는 것이 합리적입니까? 장단점은 무엇입니까, 아니면 그렇게하지 말아야 할 이유가 있습니까?

플레이어 입력을 서버로 보내지 않으려 고합니다. 플레이어가 원하는 것을 추상적으로 표현한 다음 서버에 로직을 실행하는 것이 좋습니다.

마찬가지로 클라이언트가해야 할 모든 것을 다시 돌려주고 싶지는 않습니다. 예를 들어 "NPC X 사망"이라는 메시지를 보낼 수 있으며 클라이언트는 재생할 애니메이션 / 사운드를 결정합니다. 그런 것들.

요령은 사람들의 부정 행위를 막아 대역폭과 처리 능력 (서버의)이 뒤처지는 라인을 찾는 것입니다. 일반적으로 서버에서만 모든 종류의 게임 변경 정식 결정을 내리고 모든 부수적 인 시각적 내용을 클라이언트에 남겨 둡니다.

사이트 전체에서이 주제에 대해보다 구체적인 질문이 많이 있습니다. 예를 들면 다음과 같습니다.

클라이언트 / 서버간에 충돌 감지가 서버 측 또는 협력 적으로 수행되어야합니까?

MMO에서 AI 계산은 누구입니까?

게임 호스트가 권한 또는 다른 멍청한 클라이언트 여야합니까?

글쎄, 당신은 답변을 받았지만 당신의 실제 답변은 "자신을 시도"입니다. 게임마다 다릅니다.

일부 분산 네트워크 게임 디자인 과정에서 몇 가지 멀티 플레이어 게임을했습니다. 가장 어려운 것은 많은 플레이어들이 참여하고 지옥 같은 입력을 보내는 실시간 액션 게임을하는 것이 었습니다. 그 시점에서 모든 것이 문제가됩니다. Tetrat가 보낸 첫 번째 링크를 볼 때, 담합을 결정하는 것조차 문제가됩니다. 그리고 당신은 지연, 보간, 외삽, 예측과 같은 단어들을 읽을 것입니다. 그러나 만약 당신이 처음부터 코딩을 시도하지 않았다면, 당신은이 단어들을 받아 들일 것이고 그것들이 실제로 무엇을 의미하는지 모를 것입니다.

내 추천은 :

1 단계
지금 당장 완전히 인증 된 서버 기반 설계로 시작하십시오. 당신이 말했듯이, 서버에 사용자 입력을 보내고 서버가 모든 것을하고 클라이언트가 결과를 얻도록하십시오. 게임은 완전히 일관성있게 작동합니다. 그러나 당신이 당신의 고객을 볼 때, 당신은 약간의 지연, 일부 텔레포트 문제, 부드러운 움직임이 아니라는 것을 알 것입니다 ... 요법.

2 단계
클라이언트 측 문제 해결을 시작합니다. 예를 들어 순간 이동 문제. 당신의 캐릭터는 (0,0)에 있었고 서버는 이제 당신이 (100,100)에 있다고 말했습니다. 캐릭터는 단지 (100,100)으로 순간 이동합니다. 보간이 있습니다. 클라이언트 측에 문자를 (0,0)에서 (100, 100)으로 부드럽게 이동시키는 코드가 있어야합니다. 예, 캐릭터를 (0,0)에서 (100,100)으로 이동하지만 얼마나 빠릅니까? 지금은 각 서버 업데이트 간의 시차를 사용할 수 있습니다. 서버가 1 초에 10 개의 패킷을 보내는 경우 각 패킷간에 100ms 지연이 발생합니다.

3 단계
이제 게임은 (1-50) ms 지연되는 고속 네트워크에 적합합니다. 그러나 패킷 손실, 높은 대기 시간 또는 서버에서 계산 시간이 오래 걸리면 파산됩니다. 이러한 상황에서 왼쪽 화살표를 누르면 200ms의 지연으로 캐릭터가 왼쪽으로 움직이는 것을 볼 수 있습니다. 당신의 패킷 사이의 지연은 서버에 계산 시간과 마지막 위치와 함께 당신에게 돌아옵니다. 이것은 서버 인증 설계의 최악의 단점입니다. 플레이어는 왼쪽을 누를 때마다 캐릭터가 왼쪽으로 움직이기를 원하므로 기다릴 수 없습니다. 운 좋게도 클라이언트는 서버와 동일한 코드를 가지고 있으므로 클라이언트에서 즉시 실행하고 서버의 응답으로 최종 결과를 수정하십시오. 그것이 기본적으로 입력 예측입니다. 고객이 왼쪽을 누르면, 옆에있는 코드가 그를 왼쪽으로 이동시킵니다. 얼마 후 200ms라고 말하면 실제 위치는 서버에서 나오고 클라이언트는 서버의 위치를 ​​수정합니다. 모든 것이 올바르게 진행되면 고객은 아무 것도 알지 못합니다. "2 단계"도 도움이됩니다.

net에는이 주제에 대한 많은 자습서와 내용이 있습니다. 그러나 내가 정말로 좋아하는 2가 있습니다 :

정말 좋은, 다크 스팟을 커버 : 밸브 소스 엔진 멀티 네트워킹
종류의 역사, 재미 읽을 가치가 그것의 : 28.8 1500 궁수 ,

장점 :

• 이 접근 방식은 더 많은 불법 복제 증거입니다
• 업데이트를 더 쉽게 적용 할 수 있습니다
• 중앙 집중식 커뮤니티

단점 :

• 큰 대역폭 요구 사항
• 일부 사용자는 그러한 접근 방식 (개인 정보 및 물건)을 싫어할 수 있습니다
• 로컬 게임 플레이 문제 (LAN 파티), 싱글 플레이어

서버 측 로직은 또한 확장 성 문제를 발생시킵니다. 서버의 모든 클라이언트에 대해 모든 작업을 수행해야합니다. 각 클라이언트가 전체 작업에 대해 자체적으로 공유하도록합니다.

만들려는 게임과 게임의 일부에 따라 다릅니다. RTS (또는 잠금 단계 모델이있는 게임)를 개발하는 경우 입력과 수신 된 시뮬레이션 단계 만 보내야합니다.

사수를하고 싶다면 입력 기능과 추상 기능을 모두 사용할 수 있습니다. Unreal Tournament 3를 예로 든다면, 그들은 주로 복제 된 함수 호출을 통해 멀티 플레이어를 만들었습니다.
이동을 위해 플레이어 입력 (각 동작에 대해 단일 비트로 압축) 델타 회전, 가속 및 타임 스탬프를 가져와 서버로 보냅니다.
무기와 같은 다른 목적을 위해 사격 할 때 동기화합니다 (AFAIK, 아직이 부분을 자세히 살펴 보지 않았습니다).
상태와 같이보다 정적이고 덜 자주 변경되는 값의 경우 프로그래머가 지정한 내용에 따라 변수를 클라이언트 또는 서버로 보냅니다.

RTS가 아닌 게임의 경우 클라이언트 예측을 기억하십시오.