Come si progetta un sistema di registrazione / riproduzione per un gioco che cambia di frequente?

Sto lavorando in un MMORPG gratuito e ho un problema.

Sto (con altre persone) sviluppando un sistema di registrazione video per il gioco. L'idea è fondamentalmente: registriamo tutti i pacchetti inviati e ricevuti con i timestamp, oltre ad alcuni dati locali dal client, e poi li scarichiamo in un file. Per riprodurre il video, emuliamo semplicemente tutto ciò che è nel file. Abbiamo anche un'opzione per esportare il video in avi con ffmpeg.

Il problema è: quando si passa da una versione all'altra del gioco, è difficile mantenere la compatibilità con le versioni precedenti del video (comandi aggiunti / rimossi, modifiche delle funzioni, ecc.). C'è un buon modo per gestire questo problema? invece di avere un sacco di giocatori diversi e scegliere quello giusto per ogni versione del file video?

Sarebbe utile sapere come altri giochi gestiscono questa situazione.

Grazie per l'aiuto, scusate il mio inglese.

— Marco
fonte

Proprio come un po 'più di cibo per googling / ricerche: il modo in cui lo fai è esattamente come Id Quake Games ha registrato le demo, catturando i pacchetti server. Per quanto ne so, semplicemente non hanno mai risolto i problemi di compatibilità.

— Michael Stum

Ho cambiato il titolo di questa domanda, non si tratta proprio di MMO, tranne che gli MMO sono i giochi che cambiano più frequentemente.

Risposte:

La nostra regola di base è di non modificare mai un tipo di pacchetto esistente. Tutto viene aggiunto alla fine di uno esistente o un nuovo comando. Ciò rende anche molto meno probabile che due persone calpestino il lavoro reciproco.

— coderanger
fonte

In questo gioco succede ... I pacchetti vengono aggiunti, rimossi, spostati (per esempio, qualche tempo fa, abbiamo deciso di spostare tutti i pacchetti relativi ai comandi GM in un "pacchetto esteso", questo probabilmente accadrebbe di nuovo quando riscriviamo il sistema di gilde .. Modificare i comandi / le funzioni (cambiando le sue funzionalità) è meno probabile, ma non è questo il punto. Dici che da ora in poi, non dovremmo rimuovere alcun pacchetto, eliminare i comandi semplicemente lasciarli irraggiungibili sul lato server? Grazie per la tua risposta!

— Marco,

Sì, deprecare e lasciarli lì. Alla fine le cose vecchie possono essere rimosse, ma di solito dopo un anno o due.

— coderanger,

Inoltre, una pianificazione aggiuntiva sarebbe di aiuto. Meglio pianifichi i tuoi pacchetti ora, meno modifiche dovrai apportare in futuro.

— Kylotan,

Il problema è che il gioco è in continua evoluzione. Aggiungiamo un nuovo pacchetto quasi ogni mese (aggiungiamo nuove funzionalità). Eppure, dobbiamo apportare molte modifiche alle vecchie funzionalità di riscrittura dei pacchetti e così .. Ma immagino che possiamo lasciare lì i metodi e aspettare un anno per rimuoverli.

— Marco,

L'uso di tipi di pacchetti più generici ti aiuterebbe molto qui. Non è necessario aggiungere nuovi messaggi per ogni nuova funzionalità implementata.

— Kylotan,

Non è inconcepibile, specialmente su un PC, che eseguano la versione del codice di gioco e aumentano la versione quando apportano una modifica che influisce sul sistema di riproduzione. Se il file di riproduzione è taggato con la versione del codice di gioco con cui è stato creato e il client ha ancora accesso a quella versione, dovrebbe funzionare correttamente.

— U62
fonte

È così che l'ho visto in pratica, memorizzare il numero di versione con il registro di gioco. Quindi, naturalmente, devi anche mantenere le versioni precedenti del software per riprodurre i registri precedenti, ad esempio in un repository di codice sorgente, ma probabilmente dovresti farlo comunque.

— Ian Schreiber,

Grazie per la tua risposta, il gioco è gratuito (con licenza GPL), quindi chiunque può accedere alle vecchie versioni del gioco e persino compilare il client in modo che non sia un problema avere tutte le diverse versioni di esso. Questo è molto usato, non tutti i server alternativi usano le versioni più recenti, ci sono server che eseguono versioni dal 2004 ..

— Marco,

@Marco: sospetto che SC2 funzioni che mette quasi tutto il codice in una DLL. Quando carica un replay, controlla la versione, carica la DLL per quella versione ed esegue. È un po 'più complicato, ma l'utente ha bisogno solo di un'installazione e un exe può eseguire tutti i replay precedenti.

— Mooing Duck,

Un modo per affrontarlo è sulla falsariga di un gioco chiamato "Heroes of Newerth". (che cambia ogni +/- 2 settimane) Da quello che posso dire loro:

Usa patch diff per il gioco e i replay.
Tutti i replay sono archiviati sul cloud. Alla fine scadono.
Se l'utente desidera guardare un vecchio replay scaricato, deve prima utilizzare il pulsante "Compatibile".
Sembra che questo differisca da remoto all'ultima versione; o nel caso in cui il replay non sia più memorizzato, lo carica e quindi fa il diff remoto.

Perché non lavoro in S2, chiaramente non posso dire che sia decisamente così. Tuttavia, ho notato un marcato andamento delle dimensioni del download associato all'età del replay.

O quello, o aggiungono patch entità al replay (es. L'incantesimo X ha l'effetto Y invece dell'effetto Z). Se anche le informazioni relative ai pacchetti sono archiviate nella configurazione dell'entità, questo hot patching consente di comprendere anche i pacchetti più vecchi.

Sicuramente non memorizzerei il comportamento storico sul client perché ciò può diventare enorme molto rapidamente. Soprattutto quando il client si aggiorna ad es. Da 10.1.0 a 10.2.0 (poiché devono scaricare ogni patch tra le due versioni, anziché la patch finale).

Google Protobuf è una buona idea come livello di serializzazione perché supporta elementi come questo in base alla progettazione.

— Jonathan Dickinson
fonte