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

10

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.

mmo multiplayer video game-recording patching 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:

8

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
1
Sim, deprecie e deixe-os lá. Eventualmente, coisas antigas podem ser removidas, mas isso geralmente ocorre depois de um ano ou dois.
Coderanger
1
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
3
Usar tipos de pacotes mais genéricos ajudaria bastante aqui. Você não precisa adicionar novas mensagens para cada novo recurso implementado.
Kylotan
5

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
1

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:

  1. Use o patch do diff para o jogo e replays.
  2. Todos os replays são armazenados na nuvem. Eles finalmente expiram.
  3. Se o usuário quiser assistir a uma reprodução antiga baixada, precisará usar o botão "Compatify" primeiro.
  4. 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