Atualmente, estou planejando um simples jogo multiplayer online. E aqui está a questão. Faz sentido criar toda a lógica do jogo no servidor e apenas enviar a entrada do cliente para o servidor? Quais são os prós e os contras ou há alguma razão para eu não fazer isso?
Respostas:
Você não deseja enviar a entrada do player para o servidor. O que você provavelmente quer fazer é enviar uma representação abstraída do que o jogador deseja fazer para o servidor e, em seguida, executar a lógica.
Da mesma forma, você não deseja necessariamente enviar tudo o que o cliente precisa fazer. Por exemplo, você pode enviar algum tipo de mensagem dizendo "NPC X morreu" e o cliente determina que animação / sons reproduzir. Coisas assim.
O truque é encontrar a linha na qual a largura de banda e o poder de processamento (no servidor) são superados, impedindo que as pessoas trapaceiem. Geralmente, você toma qualquer tipo de decisão autoritativa de mudança de jogo apenas no servidor e deixa todo o material visual auxiliar para o cliente.
Existem muitas perguntas mais específicas sobre esse tópico em todo o site. Por exemplo:
A detecção de colisão deve ser feita no servidor ou em cooperação entre cliente / servidor?
Quem faz os cálculos de IA em um MMO?
O host do jogo deve ser a autoridade ou outro cliente burro?
Bem, você tem respostas, mas sua resposta real é "tente você mesmo". As coisas diferem de jogo para jogo.
Eu fiz alguns jogos multiplayer para algum curso de design de jogos em rede distribuído. O mais desafiador foi fazer um jogo de ação em tempo real, onde muitos jogadores se envolveram e enviaram informações como o inferno. Quando chega a esse ponto, tudo se torna problema. Como você vê o primeiro link enviado pelo Tetrat, até determinar um conluio se torna um problema. E você lerá termos como lag, interpolação, extrapolação, previsão ... Mas se você nunca se tentou codificar do zero, apenas aceitará essas palavras e não saberá o que elas realmente significam.
Minha recomendação é:
Etapa 1
Comece agora com um design baseado em servidor totalmente autorizado por enquanto. Como você disse, basta enviar as entradas do usuário ao servidor e deixar o servidor fazer tudo e os clientes obterem os resultados. Seu jogo funcionará totalmente consistente. Mas quando você olha para seus clientes, notará alguns atrasos, alguns problemas de teletransporte, não movimentos suaves ... etc.
Etapa 2
Comece a corrigir os problemas no lado do cliente. Os problemas de teletransporte, por exemplo. Seu personagem estava em (0,0) e o servidor disse que agora você está em (100,100). Seu personagem irá se teleportar para (100.100), o que não é legal. Aí vem a interpolação. Você deve ter um código no lado do cliente que deslize o caractere de (0,0) para (100, 100) de maneira suave. Sim, você moverá seu personagem de (0,0) para (100,100), mas com que rapidez? Por enquanto, você pode apenas usar a diferença de horário entre cada atualização do servidor. Se o seu servidor enviar 10 pacotes em um segundo, o que significa um atraso de 100 ms entre cada pacote.
etapa 3
Agora seu jogo já é bom para redes rápidas, onde há um atraso de (1 a 50) ms. Mas fica condenado se houver perda de pacotes, alta latência ou cálculo demorar muito no servidor ... ect. Nessas situações, você notará que quando pressionar a seta esquerda, verá seu personagem se movendo para a esquerda com um atraso de 200 ms. O atraso entre o pacote vai para o servidor, o tempo de cálculo e volta para você com sua última posição. Isso é ruim, a pior desvantagem do design autorizado pelo servidor. O jogador quer que seu personagem se mova para a esquerda assim que ele pressiona para a esquerda, você não pode fazê-lo esperar. Felizmente, o cliente também tem o mesmo código que o servidor. Por que não executá-lo no cliente imediatamente e corrigir o resultado final com a resposta do servidor? Isso é o que basicamente é a previsão de entrada. O cliente pressiona para a esquerda, o código ao seu lado o move para a esquerda, depois de algum tempo digamos 200 ms, a posição real vem do servidor e o cliente corrige sua posição com ele. Se tudo der certo, o cliente não notará nada, a "etapa 2" também nos ajudará com isso.
Bem, a net tem muitos tutoriais e coisas sobre esse assunto. Mas existem 2 que eu realmente gosto:
Realmente bom, cobre manchas escuras: rede multijogador do mecanismo da fonte de válvulas
Tipo de história, diversão para ler e vale a pena: 1500 arqueiros em 28,8 ,
Prós:
Contras:
A lógica do servidor também cria problemas de escalabilidade - você precisa fazer todo o trabalho para todos os clientes em seu servidor - versículos permitindo que cada cliente faça sua própria parte do trabalho total.
Depende do jogo que você deseja criar e qual parte do jogo. Se estiver desenvolvendo um RTS (ou qualquer jogo com um modelo com bloqueio de bloqueio), você definitivamente deve enviar apenas a entrada e qual etapa de simulação a entrada foi recebida.
Se você quiser fazer um jogo de tiro, poderá usar as funções de entrada e abstratas. Se você tomar o Unreal Tournament 3 como o caso, eles criaram o multiplayer principalmente por meio de chamadas de função replicadas.
Para o movimento, eles pegam a entrada do jogador (compactada em um único bit para cada ação) rotação delta, aceleração e carimbo de data e hora e enviam para o servidor.
Para outros fins, como a arma que eles sincronizam quando você dispara (AFAIK, ainda não analisamos essa parte em profundidade).
Para valores mais estáticos / menos alterados, como integridade, eles enviam a variável ao cliente ou servidor, dependendo do que o programador especificou.
E para jogos não RTS, lembre-se da previsão do cliente.