Executando o servidor e o cliente dentro do mesmo processo

Questão

Comecei a trabalhar com o Lidgren e a rede pela primeira vez e percebi que é possível executar o servidor e o cliente no mesmo processo.

Essa prática é desencorajada por qualquer motivo?

Contexto

A razão pela qual estou perguntando é que teorizei que esse conceito poderia me permitir tratar os modos singleplayer e multiplayer como um e o mesmo, o que seria muito útil.

Seguindo minha linha de pensamento, esta é a distribuição que eu tinha em mente:

• Singleplayer - 1 servidor + 1 cliente no mesmo processo. Qual a velocidade das comunicações?
• Multiplayer - Igual ao singleplayer para o host + 1 cliente adicional para cada outro jogador.

O fluxo de execução que estou visualizando é para os clientes receberem a entrada do usuário e enviarem uma notificação ao servidor. Em seguida, o servidor valida e transmite uma ação a ser executada por todos os clientes. Não importa se existe apenas um cliente (por exemplo, singleplayer) ou vários clientes (por exemplo, multiplayer).

Esta é basicamente uma questão de processo versus thread, ambos não são muito diferentes, às vezes os threads são chamados de processos leves. A maior diferença é que um processo separado tem seu próprio espaço de endereço, mas existem outras diferenças (1):

Por processo

• espaço de endereço
• Variáveis ​​globais
• Abrir arquivos
• Processos filho
• Alarmes, interrupções e manipuladores de sinais pendentes

Por segmento

• Contador de programa
• Registros
• Pilha
• Estado

Com base nessas diferenças, pode ser útil ter um encadeamento de servidor e cliente no mesmo processo para que você possa compartilhar identificadores de arquivo e variáveis ​​globais. Esse seria um argumento para a abordagem 'no mesmo processo'; outro (pequeno) argumento seria que você só recebe um pop-up do 'Firewall do Windows' por processo. Um argumento para a abordagem de 'processo diferente' seria que uma pessoa pode executar vários servidores sem precisar executar vários clientes. Isso seria ideal para um host dedicado, como a configuração, e é uma abordagem comumente vista nos atiradores em primeira pessoa.

Agora, quanto à ideia de ter um processo ou thread de servidor, mesmo para jogar off-line (e talvez até para um jogador), essa é uma ótima idéia que é muito usada na prática. Você pode dizer que muitos jogos fazem isso olhando para a tela de carregamento; pequenas dicas como 'receber' o distribuirão. É lógico fazer isso, pois se você for um multi-jogador, a maioria das regras do jogo será governada pelo servidor, então por que não tê-lo como jogador único? Isso reduz o código que você precisa escrever e oferece uma separação mais clara entre cliente e 'jogo', o que melhorará a qualidade do seu código.

Agora, que tal se comunicar entre processos e threads? A comunicação entre processos pode ser feita de várias maneiras, pipes (nomeados), memória compartilhada, COM, realmente depende da tecnologia que você está usando. No entanto, se você estiver criando um servidor, provavelmente desejará usar uma variante de rede usando soquetes e algo como TCP, é claro que é aí que o LIDGREN será útil.

Muitas dessas técnicas também são válidas para comunicação entre threads. Mas isso depende ainda mais das técnicas que você está usando. Você pode novamente usar o TCP, mas talvez um sistema ainda mais simples seja eventos e algum tipo de organização, embora isso possa tornar seu jogo não determinístico (2).

Fontes

1. Projeto e implementação de sistemas operacionais (o livro MINIX), 3ª edição por Andrew S. Tanenbaum
2. Corrija seu timestep por Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/