Fiz isso em um jogo comercial de corrida PSP, que funcionava tanto em uma rede ad hoc quanto em um ponto de acesso sem fio. (Ou para um servidor estático na Internet, se desejado)
Por causa do ponto 2, o sistema não precisa ser complexo no que diz respeito à otimização
Na minha experiência, isso não é verdade. Dispositivos sem fio (especialmente portáteis pequenos) não são como computadores com conexões de rede com fio - smartphones e consoles de jogos sem fio tendem a ter interfaces de rede lentas para fins de jogos.
Não me interpretem mal - a taxa de transferência é geralmente boa (ou seja, a quantidade de dados por segundo; ótima para streaming de filmes ou etc.), mas a latência na entrega de um pacote específico pode ser extremamente ruim e pode ser altamente variável que é difícil estimar quanto tempo um pacote individual levará para ser entregue. Essa variação se torna ainda pior à medida que mais dispositivos sem fio são agrupados em uma área geral, pois seus sinais começam a interferir entre si. Como resultado disso, passei muito do meu tempo reduzindo o número de pacotes que precisavam ser enviados, para que tivéssemos menos colisões de pacotes. (Observe que isso é um pouco menos problemático no caso de um hotspot de rede ativado, em vez de ter os dispositivos conversando diretamente através de uma rede ad hoc)
Como exemplo desse tipo de otimização, nosso jogo de corrida ocorreu em um mundo que tinha semáforos. Milhares deles. E precisávamos garantir que seus sinais estivessem sincronizados entre todos os jogadores em uma sessão de rede. Em vez de tentar enviar pacotes informando a todos quais luzes estavam em que estado, definimos um cronograma estático para todos os semáforos e apenas garantimos que todos os clientes concordassem com a "hora do jogo" atual. Como todos conheciam a hora do jogo e todos os estados dos semáforos podiam ser determinados a partir da hora do jogo, sincronizamos todos esses dados de estado sem enviar dados especiais. Essa mudança fez uma enorme diferença para o desempenho da nossa rede.
O que foi dito, estabelecer uma sincronização confiável de relógio entre vários dispositivos sem fio (com tempos de ping muito variados devido principalmente à perda de pacotes) foi um grande desafio. É um prazer falar mais sobre isso, se você tiver interesse.
Cada cliente pode ser uma fonte autorizada de dados sobre ele e seu ambiente imediato (por exemplo, marcadores).
Foi isso que fizemos e funcionou bem para nós em nossa situação (carros). A parte problemática, é claro, é quando um objeto deixa de estar mais próximo do jogador 'a' do que do jogador 'b' e, portanto, sua propriedade é transferida de um jogador para outro.
Essa é realmente uma negociação surpreendentemente complexa entre os jogadores, onde o jogo 'a' propõe o jogo 'b': "Acho que esse objeto está mais perto de você. Você deve assumir o controle dele". E então o jogo 'b' pode aceitar, ou pode recusar, com base em sua própria visão da situação. As diferenças no estado de jogo percebido entre 'a' e 'b', e a mudança no tempo entre o envio e o recebimento da solicitação e resposta fazem desta uma negociação particularmente desagradável para se tornar confiável, e pode facilmente degenerar em um jogo de "batata quente", com a propriedade do objeto oscilando continuamente entre vários jogadores. E mesmo quando funciona corretamente, quando visto do ponto de vista do jogo 'c', existe '
Minha intuição é que esse tipo de abordagem de "propriedade de objetos" provavelmente será muito complicada para objetos pequenos e de vida curta, como balas. Nós o usamos para carros de tráfego e corredores de IA, que tendiam a viver na simulação por um tempo relativamente longo. Parece que uma abordagem mais eficiente, se você estiver disposto a confiar nos clientes, seria fazer com que o jogo de cada jogador possuísse sua posição e seus projéteis e declarasse quando esse jogador foi atingido pelo projétil de outra pessoa. (Assim como no "jogo A", sou responsável por dizer onde estão os projéteis do jogador A e do jogador A, mas o jogador B é responsável por dizer se eu bati no jogador B). Com algumas boas estimativas, você deve conseguir um comportamento bastante razoável de um sistema como esse.
