Design do mecanismo de jogo: servidores multijogador e de escuta [fechado]


10

No momento, meu mecanismo de jogo consiste em uma parte para um jogador que funciona. Agora estou começando a pensar em como fazer a parte do multiplayer.

Descobri que muitos jogos na verdade não têm um modo singleplayer real, mas quando jogamos sozinhos, você também hospeda um servidor local e quase tudo funciona como se você estivesse no multiplayer (exceto que os pacotes de dados podem ser transmitidos em uma rota alternativa para obter melhor desempenho)

Meu mecanismo precisaria de grande refatoração para se adaptar a este modelo. Existem três modos possíveis: cliente dedicado, servidor dedicado e cliente-servidor (modo de escuta)

  • Com que frequência o modelo de servidor de escuta é usado na indústria de jogos?
  • Quais são as (des) vantagens disso?
  • Que outras opções eu tenho?

4
A primeira pergunta é bastante irrelevante. Por que deveria importar como a indústria faz isso? Eles não fazem tudo da melhor maneira.
The Duck Comunista

Respostas:


11

Vou ver se consigo responder da melhor maneira possível:

Com que frequência o modelo de servidor de escuta é usado na indústria de jogos?

Quando se trata da maioria dos jogos online, você verá que a grande maioria dos jogos usa uma arquitetura cliente-servidor, embora nem sempre da maneira que você pensa. Tome qualquer jogo da fonte, por exemplo. A maioria usará um servidor-cliente padrão com uma arquitetura de servidor mestre (para listar os jogos disponíveis), em que uma pessoa hospedará um servidor dedicado e qualquer pessoa com um cliente poderá ingressar nele.

No entanto, você tem alguns jogos e serviços, por exemplo, Left 4 Dead, League of Legends e alguns jogos do Xbox Live, que adotam uma abordagem um pouco diferente. Todos eles usam uma arquitetura cliente-servidor com um servidor de controle. A idéia principal aqui é que alguém crie um servidor dedicado que não esteja "executando" nenhum jogo. O servidor de controle criará uma espécie de "lobby" e, quando o jogo for iniciado, o servidor de controle os adicionará a uma fila e, quando for a vez desse lobby, ele selecionará um servidor dedicado correspondente (em termos de localização / velocidade, disponibilidade, vários fatores) e designe os jogadores para esse servidor. Somente então o servidor "executará" o jogo. É a mesma ideia, mas um pouco simplificada, pois o cliente não precisa "escolher" um servidor,

Obviamente, o maior modelo cliente-servidor é o modelo MMO, onde um ou muitos servidores administram um mundo persistente que lida com quase todos os dados e lógica. Alguns dos jogos mais famosos que usam esse modelo são World of Warcraft, Everquest, qualquer coisa assim.

Então, onde um servidor de escuta se encaixa aqui? Para ser honesto, não muito bem, no entanto, você ainda encontrará muitos jogos usando-o. Por exemplo, a maioria dos jogos Source permite a criação de servidores de escuta, e muitos jogos do XBox Live permitem (já faz um tempo, mas acredito que o Counter Strike o fez, assim como o Quake 4 e muitos outros). Em geral, porém, eles parecem desaprovados devido às vantagens do modelo cliente-servidor, o que nos leva ao próximo ponto.

Quais são as (des) vantagens disso?

Primeiro e mais importante: desempenho. Em um modelo cliente-servidor, o cliente manipulará alterações locais (como entrada, gráficos, sons etc.) em cada ciclo do jogo. No final do ciclo, ele agrupará dados relevantes (como, o jogador se moveu? Se sim, para onde? Para onde ele está olhando agora? Velocidade? Eles atiraram? Se sim, informações sobre a bala. Etc) e envie-o ao servidor para processamento. O servidor coletará esses dados e determinará se tudo é válido, como, se o usuário está se movendo de uma maneira que indica invasão (mais sobre isso mais tarde), é a movimentação válida (algo que está no caminho?), O aviso do jogador 1 jogador atingido 2? E mais. Em seguida, o servidor empacota isso e envia para os clientes, que atualizam o que for necessário, como ajustar a saúde se o jogador foi baleado, chutá-lo se for determinado que eles estão hackeando etc.

Um servidor de escuta, no entanto, deve lidar com tudo isso ao mesmo tempo. Como presumo que você esteja familiarizado com a programação, você provavelmente percebe quanta energia um jogo pode roubar de um computador, especialmente um mal projetado. Adicionando processamento de rede, processamento de segurança e muito mais , além de o jogo do cliente, você pode ver onde o desempenho seria afetado seriamente, pelo menos no que diz respeito apenas ao processamento padrão. Além disso, a maioria dos servidores roda em redes rápidas e são projetados para suportar o tráfego de rede. Se a rede de um servidor de escuta estiver lenta, o jogo inteiro sofrerá.

Segunda segurança , como declarado anteriormente, uma das principais coisas que um servidor fará é determinar se um jogador está explorando o jogo. Você pode ter visto isso como Punkbuster, VAC, etc. Há um conjunto muito complicado de regras que executam esses programas, por exemplo, determinando a diferença entre um hacker e apenas um jogador muito bom. Seria muito ruim para o seu jogo se você não fosse capaz de capturar hackers, mas ainda pior se executasse uma ação contra um acusado falsamente.

Um servidor de escuta geralmente não será capaz de lidar com o jogo do cliente, o processamento do servidor e a detecção de hackers. Na maioria dos casos, detectores como o Punkbuster são muito difíceis, se não impossíveis, de rodar em um servidor de escuta, porque é dificilmente funcione corretamente sem o poder de processamento necessário, pois geralmente a lógica do jogo é priorizada em relação à segurança e, se o detector não puder processar um quadro, poderá perder os dados necessários para convencer alguém.

Por fim, jogabilidade . O principal dos servidores é que eles são persistentes, o que significa que, mesmo que todos saiam, o servidor continuará sendo executado. Isso é útil se você tiver um servidor popular que não tem muita atividade durante a noite, as pessoas ainda podem entrar quando estão prontas para jogar e não precisam esperar que ele volte a ficar online.

Em um servidor de escuta, a principal desvantagem é que, assim que o cliente que hospeda o servidor de escuta sai, o jogo deve ser transferido para outro jogador (criando um lul no jogo que pode durar alguns minutos em alguns casos) ou deve terminar completamente . Isso não é preferível em um servidor grande, pois o host deve permanecer on-line (desperdiçando um slot no servidor e a energia do computador, o que também pode atrasar o jogo) ou terminar o jogo para todos.

No entanto, apesar desses problemas, os servidores de escuta têm algumas vantagens.

Fácil de configurar : a maioria dos servidores de escuta nada mais é do que clicar em "Novo jogo" e deixar as pessoas entrarem. Isso é fácil para pessoas que querem apenas brincar com seus amigos e não desejam tentar encontrar um servidor dedicado vazio ou jogar com outras pessoas.

Bom para teste : se alguém possui um servidor dedicado e deseja alterar sua configuração, geralmente é uma idéia melhor testara configuração primeiro. O usuário precisaria criar um backup do servidor dedicado e entrar cegamente nas alterações, com a única opção de reverter se algo der errado, criar um novo servidor dedicado para testá-los ou criar um servidor de escuta simples para testá-los. E no ponto 1, esses geralmente são mais fáceis de iniciar e configurar. Isso é especialmente verdade, pois a maioria dos servidores dedicados não está dentro do acesso imediato dos administradores (a maioria dos servidores dedicados é alugada em um local remoto). Leva muito mais tempo para enviar as alterações de configuração, bem como os comandos para reiniciar, etc., para um local remoto do que uma máquina na qual o administrador está atualmente.

Menos recursos : Na maioria dos servidores dedicados, um usuário com o mesmo IP não pode se conectar ao servidor dedicado (ou seja, o cliente deve hospedar o servidor ou executar, eles não podem fazer as duas coisas). Se o cliente desejar jogar em seu próprio servidor, normalmente precisará de uma segunda máquina para hospedar o servidor ou comprar ou alugar um servidor dedicado para que ele possa realmente jogar nele. Um servidor de escuta requer apenas uma máquina, que pode ser a única coisa que o cliente pode usar.

Em ambos os casos, ambos têm vantagens e desvantagens, e você precisa ponderá-los com o que deseja projetar e implementar. Pela minha experiência, acredito que, se você implementasse um servidor de escuta, ele seria usado, por nada mais do que alguns usuários que desejam brincar com os amigos ou testar configurações.

Por último:

Que outras opções eu tenho?

Esta é uma lata industrial de minhocas. Na realidade, qualquer tipo de arquitetura de rede pode ser aplicada aos videogames. No entanto, pelo que vi, como a maioria das comunicações pela Internet, a maioria se resume a alguma forma de modelo cliente-servidor.

Entre em contato se eu não responder à sua pergunta ou se você precisar de algo expandido, e verei o que posso fazer.


"Na maioria dos servidores dedicados, um usuário com o mesmo IP não pode se conectar ao servidor dedicado (ou seja, o cliente deve hospedar o servidor ou jogar, eles não podem fazer as duas coisas)." WAT? Onde? Por quê? Se alguns servidores tiverem essa limitação arbitrária aparentemente sem sentido, isso não significa que ele seria forçado a fazer o mesmo quando escrever uma ...
o0 '.

É um artefato de jogos mais antigos, de quando os computadores não conseguiam lidar com algoritmos de servidor, cálculos gráficos e lógica de jogo de uma só vez. Muitos modelos de servidor dedicados impediriam que um cliente que tentasse se conectar da mesma máquina se conectasse com êxito, e essa prática ainda é aplicada em alguns jogos atualmente. Eu nunca disse que isso se aplica a todos os modelos, nem disse que ele tinha que modelá-lo para esse paradigma em particular. No entanto, tecnicamente, permitir conexões com o mesmo host derrota o objetivo do servidor dedicado, e o único benefício é deixar o servidor ativo ao desconectar.
shmeeps
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.