Como você cria um sistema de gravação / repetição para um jogo que muda frequentemente?

Estou trabalhando em um MMORPG gratuito e tenho um problema.

Estou (com outras pessoas) desenvolvendo um sistema de gravação de vídeo para o jogo. A idéia é basicamente: registramos todos os pacotes enviados e recebidos com registros de data e hora, além de alguns dados locais do cliente e depois os despejamos em um arquivo. Para reproduzir o vídeo, apenas simulamos tudo o que está no arquivo. Também temos a opção de exportar o vídeo para avi com ffmpeg.

O problema é: quando alternamos entre as versões do jogo, é difícil manter a compatibilidade com versões anteriores do vídeo (comandos adicionados / removidos, alterações de função, etc.). Existe uma boa maneira de lidar com esse problema? em vez de ter vários jogadores diferentes e escolher o caminho certo para cada versão do arquivo de vídeo?

Seria útil saber como outros jogos lidam com essa situação.

Obrigado pela ajuda, desculpe pelo meu inglês.

— Marco
fonte

Como um pouco mais de alimento para pesquisar / pesquisar: A maneira como você faz isso é exatamente como o Quake Games da id gravou Demos capturando Pacotes de Servidores. Tanto quanto sei, eles simplesmente nunca resolveram os problemas de compatibilidade.

— Michael Stum

Eu mudei o título desta pergunta - não se trata realmente de MMOs, exceto que os MMOs são os jogos que mudam com mais frequência.

Respostas:

Nossa regra básica é nunca alterar um tipo de pacote existente. Tudo é adicionado no final de um existente ou um novo comando. Isso também torna muito menos provável que duas pessoas pisem no trabalho uma da outra.

— coderanger
fonte

Neste jogo, acontece. Pacotes são adicionados, removidos, movidos (por exemplo, há algum tempo atrás, decidimos mover todos os pacotes relacionados aos comandos do GM para um "pacote estendido"; isso provavelmente aconteceria novamente quando reescrevéssemos o sistema de guildas .. Editar comandos / funções (alterar sua funcionalidade) é menos provável, mas esse não é o ponto.Você diz que de agora em diante não devemos remover nenhum pacote, excluir comandos, apenas deixá-los inacessíveis no servidor? para sua resposta!

— Marco

Sim, deprecie e deixe-os lá. Eventualmente, coisas antigas podem ser removidas, mas isso geralmente ocorre depois de um ano ou dois.

— Coderanger

Além disso, algum planejamento extra ajudaria. Quanto melhor você planejar seus pacotes agora, menos alterações precisará fazer no futuro.

— Kylotan

O problema é que o jogo está sempre mudando. Adicionamos um novo pacote quase todo mês (adicionamos novos recursos). E, no entanto, temos que fazer muitas alterações nos pacotes antigos, reescrevendo recursos e assim .. Mas acho que podemos deixar os métodos lá e esperar um ano para removê-los.

— Marco

Usar tipos de pacotes mais genéricos ajudaria bastante aqui. Você não precisa adicionar novas mensagens para cada novo recurso implementado.

— Kylotan

Não é inconcebível, especialmente em um PC, que eles apenas modifiquem o código da jogabilidade e aumentem a versão quando fazem uma alteração que afeta o sistema de repetição. Se o arquivo de reprodução estiver marcado com a versão do código de jogo com o qual ele foi criado e o cliente ainda tiver acesso a essa versão, ele deverá funcionar corretamente.

— U62
fonte

Foi assim que vi isso na prática: armazene o número da versão no log do jogo. Então, é claro, você também precisa manter as versões anteriores do software para reproduzir logs anteriores, por exemplo, em um repositório de código-fonte, mas você provavelmente deveria estar fazendo isso de qualquer maneira.

— Ian Schreiber

Obrigado pela sua resposta, o jogo é gratuito (licenciado pela GPL), para que qualquer pessoa possa acessar versões antigas do jogo e até compilar o cliente para que não seja um problema ter todas as versões diferentes. Isso é muito usado, nem todos os servidores alternativos usam as versões mais recentes, existem servidores que executam versões a partir de 2004 ..

— Marco

@ Marco: Eu suspeito que o SC2 funciona é que ele coloca quase todo o código em uma DLL. Quando carrega uma reprodução, verifica a versão, carrega a DLL para essa versão e é executada. É um pouco mais complicado, mas o usuário precisa apenas de uma instalação e um exe pode executar todos os replays antigos.

— quer

Uma maneira de resolver isso é na linha de um jogo chamado "Heroes of Newerth". (que muda a cada +/- 2 semanas) Pelo que posso dizer, eles:

Use o patch do diff para o jogo e replays.
Todos os replays são armazenados na nuvem. Eles finalmente expiram.
Se o usuário quiser assistir a uma reprodução antiga baixada, precisará usar o botão "Compatify" primeiro.
Parece que isso remota difere para a versão mais recente; ou caso a reprodução não seja mais armazenada, faça o upload e faça a comparação remota.

Como não trabalho na S2, claramente não posso dizer que é definitivamente assim que funciona. No entanto, notei uma tendência de tamanho de download associada à idade da reprodução.

Ou isso, ou eles adicionam patches de entidade ao replay (por exemplo, o feitiço X tem efeito Y em vez de Z). Se as informações relacionadas aos pacotes também forem armazenadas na configuração da entidade, esse hot-patch da entidade também permitirá que você entenda os pacotes mais antigos.

Definitivamente, eu não armazenaria um comportamento histórico no cliente, porque isso pode ficar enorme muito rapidamente. Especialmente quando o cliente está atualizando, por exemplo, 10.1.0 para 10.2.0 (pois eles precisam fazer o download de cada patch entre as duas versões, em vez do patch final).

O Google Protobuf é uma boa idéia como uma camada de serialização, pois suporta coisas como essa por design.

— Jonathan Dickinson
fonte